[emilv]

Ursprungligen postat av Ara

SQL-injection, det va vär typ 7-8 år sedan det funkade? Eller är folk/siter fortfarande kassa på att skydda sig?

Wordpress hade en ett hål senast i höstas som gjorde att en utomstående kunde byta lösenord på admin-kontot med hjälp av en SQL-injektion. Ja, folk har fortfarande sådana problem.

real_escape-funktionerna (som faktiskt pratar med MySQL för att utföra arbetet) är väl inte heller särskilt gamla? Många använder nog fortfarande mysql_escape_string som ju är välkänt osäker.

[eliasson]

Ursprungligen postat av Ara

SQL-injection, det va vär typ 7-8 år sedan det funkade? Eller är folk/siter fortfarande kassa på att skydda sig?

Det handlar väl främst om att språket måste utvecklas och hantera detta korrekt, vilket det gör genom PDO.
Nybörjare är alltid nybörjare, eller hur?

[taz76]

Codeigniters funktion XSS_Clean kanske är något..

[patrikweb]

Ursprungligen postat av Ara

SQL-injection, det va vär typ 7-8 år sedan det funkade? Eller är folk/siter fortfarande kassa på att skydda sig?

Tar under 5 min hitta någon sida att göra SQL injection på, finns även en hel del kritiska sidor det funkar utmärkt på.

Så är fortfarande jävligt illa.

[Lando]

Bra svar allihopa! Ska sätta mig ner och koda ihop en funktion utefter alla svar.

Självklart är detta fortfarande ett problem. Speciellt om man är nybörjare. En grej jag förlitat mig på innan var detta:
http://php.net/manual/en/security.magicquotes.php

Men många webbhotell kör inte på det.

[emilv]

Ursprungligen postat av Lando

Bra svar allihopa! Ska sätta mig ner och koda ihop en funktion utefter alla svar.

Självklart är detta fortfarande ett problem. Speciellt om man är nybörjare. En grej jag förlitat mig på innan var detta:
http://php.net/manual/en/security.magicquotes.php

Men många webbhotell kör inte på det.

Du ska aldrig lita på magic_quotes_gpc.
* Det är en inställning man kan stänga av så även om du förlitar dig på det måste du skriva en egen funktion som gör samma sak ifall du tänker hosta din kod på servrar utanför din kotnroll (till exempel webbhotell).
* Magic_quotes_gpc är inte säker. Den missar många tecken, särskilt Unicode-tecken som knäckare gärna använder sig av.
* Det är drygt om man faktiskt tänkt använda datat direkt och inte i en databas.

Av ovanstående anledningar är magic_quotes_gpc på utdöende. I kommande versioner av PHP kommer funktionen att plockas bort helt och hållet så det är lika bra att börja göra det på egen hand på en gång, till exempel med PDO eller mysqli_real_escape_string.

[Holger]

Skulle rekommendera att hämta alla in-parametrar med filter_input.
Det, tillsammans med mysql_real_escape_string, hjälper en hel del.

[Norman]

prepared statements

och vill man kan man ju köra php sanitize libbet om man känner sig extra paranoid.
Kan styra och ställa i allt vad som tillåts som indata, undika XSS och liknande.

[Draqir]

PHP-kod:

mysql_real_escape_string(htmlentities(XSS_CLEAN(filter_input('INPUT_POST', $str, FILTER_SANITIZE_ENCODED )), ENT_QUOTES), $dbobj)); 


Kom ihåg: Att städa är mycket roligt...

[SimonP]

Som en del redan nämnt, glöm inte av att skydda er mot XSS.

I dagläget är det nog mer vanligt med XSS-hål än med SQL-injection hål, även större företag missar XSS:en, det finns t.ex en svensk bank som har ett XSS-hål som innebär att man kan sno sessions-cookien :|

I PHP är htmlspecialchars() är det första steget man bör använda för att skydda sig mot XSS. Beroende på applikationen kan man även behöva komplettera med fler skydd.