Säkerhetskoll med undantag

För närvarande har jag en funktion som kollar igenom alla variabler i POST och GET efter otrevliga tecken som skulle kunna innebära problem. Det är visserligen fullt möjligt att jag missar några :o eftersom jag inte är helt säker på vad hackers eg gör... men jag täpper i alla fall igen för allt jag känner till. Problemet är att vissa tecken även kan användas fullt legitimt.

För att vara helt säker för SQL Injections stoppade jag på detta sätt användandet av ' direkt. Men en användare som vill skriva tex "don't" i sin kommentar fastnar då i säkerhetskollen! :r (Engelsk sida.) Jag trodde jag löste problemet genom att inte alltid köra kollen, men har just insett att jag förbisåg en (nödvändig) koll som körs och således stoppar folk. Alltså måste jag ha en bättre lösning. Och då behöver jag lite hjälp eftersom det är så mycket jag inte vet om säkerhetsaspekterna...

1. Med PHP och magical_quotes_gpc on kanske man aldrig behöver bry sig om ' ?

2. Löser jag problemet om jag frankt sätter om alla variabler i POST och GET till html_entities(respektive) i stället?

3. Om ja på 2 så: Det innebär ju i så fall att det som lagras i databasen blir tex & lt (utan mellanslag!) istället för < osv, och skulle man inte lagra strängen i oförändrat skick och bara ändra vid utskrift? Spelar det någon roll? Varför?

4. Finns det någon bättre väg att gå? Hur gör ni?

Vad menar du med "fastnar i säkerhetskollen", får man ett felmeddelande om man skrivit ett sådant tecken? Vore det inte smidigare att bara escapa de farliga tecknen istället för att slänga felmeddelanden på folk i tid och otid (ta en titt på http://se.php.net/add_slashes)?

1. Med magical_quotes_gpc så körs add_slashes på all indata (Get/Post/Cookie) automatiskt.

2. Det går att lösa så, men som du själv säger så är det att rekommendera att ha den "råa" datan i databasen och manipulera den på utvägen istället.

4. Kör med en funktion som kollar om magic_quotes är på (get_magic_quotes_gpc()), är den inte det så kör jag add_slashes på all indata.

Peeer skrev:

Vad menar du med "fastnar i säkerhetskollen", får man ett felmeddelande om man skrivit ett sådant tecken? ...

Användaren får ett ganska surt meddelande och jag får ett mail om att någon gör något potentiellt "skumt". Eftersom det inte är meningen att man ska kunna få detta meddelande med mindre än att man ändrar på värden man borde ge fan i. Åtminstone var det tänkt så... Just nu funkar det tyvärr inte så... :r

Vore det inte smidigare att bara escapa de farliga tecknen istället för att slänga felmeddelanden på folk i tid och otid ?

Jo. Fast add_slashes() löser ju inte allt. Det hindrar ju tex inte folk att skriva in kod som genererar pop-up-rutor och letar efter info om andra... vad 17 heter det? Något som fick wF att göra om de privata uppladdningsareorna här för några månader sen... Nåt med cross... (tror jag). Dvs jag vill inte ha in HTML-kod heller eller möjligheten för någon att slänga med en javascript tag... tex.

1. Med magical_quotes_gpc så körs add_slashes på all indata (Get/Post/Cookie) automatiskt.

Men den indata som "escape:as" är väl bara ' och "? Eller? Det kanske tar mer?

2. Det går att lösa så, men som du själv säger så är det att rekommendera att ha den "råa" datan i databasen och manipulera den på utvägen istället.

Jag har läst det här på wF. Men jag fattar inte varför? Vad är skillnaden? :q

4. Kör med en funktion som kollar om magic_quotes är på (get_magic_quotes_gpc()), är den inte det så kör jag add_slashes på all indata.

Smart! :D

aasah skrev:

Vore det inte smidigare att bara escapa de farliga tecknen istället för att slänga felmeddelanden på folk i tid och otid ?

Jo. Fast add_slashes() löser ju inte allt. Det hindrar ju tex inte folk att skriva in kod som genererar pop-up-rutor och letar efter info om andra... vad 17 heter det? Något som fick wF att göra om de privata uppladdningsareorna här för några månader sen... Nåt med cross... (tror jag). Dvs jag vill inte ha in HTML-kod heller eller möjligheten för någon att slänga med en javascript tag... tex.

Jo när du skriver ut datan till besökarna så ska du naturligtvis se till så det inte finns någon otrevlig htmlkod i utdatan (funktionen htmlentities() är väl rätt lämplig för det ändamålet).

1. Med magical_quotes_gpc så körs add_slashes på all indata (Get/Post/Cookie) automatiskt.

Men den indata som "escape:as" är väl bara ' och "? Eller? Det kanske tar mer?

"When magic_quotes are on, all ' (single-quote), " (double quote), \ (backslash) and NUL's are escaped with a backslash automatically."

2. Det går att lösa så, men som du själv säger så är det att rekommendera att ha den "råa" datan i databasen och manipulera den på utvägen istället.

Jag har läst det här på wF. Men jag fattar inte varför? Vad är skillnaden? :q

Om vi tar wF som exempel. När du postar ett inlägg här så använder du dig kanske av smilies (små bildfiler). Tänk om vi helt plötsligt får för oss att skaffa en ny smiley, om vi då hade kört alla inlägg genom wFs smileyfunktion (den som ersätter ":)" med " :)") när man postar sitt inlägg istället för när det visas för besökare. Då hade vi varit tvungna att gå igenom wFs alla 972485 poster och infoga den nya smileyn lite här och var. Likadant om vi av någon anledning skulle ändra sökvägen till mappen med smileysarna, bara att gå igenom alla poster...

Ok, det var kanske inget bra exempel, men ändå :e

Peeer skrev:

aasah skrev:

Peeer skrev:

2. Det går att lösa så, men som du själv säger så är det att rekommendera att ha den "råa" datan i databasen och manipulera den på utvägen istället.

Jag har läst det här på wF. Men jag fattar inte varför? Vad är skillnaden? :q

Om vi tar wF som exempel...

Ok, det var kanske inget bra exempel, men ändå :e

Jag förstår vad du menar. Fast när det gäller säkerhetskollar är det väl mindre troligt att man vill ta bort dem. Fast det enda som MÅSTE kollas före lagring i databasen är alltså saker som add_slashes resp magic_quotes_gpc fixar? :q Stämmer det? :q

Tacksam för svar. :)

aasah skrev:

Fast det enda som MÅSTE kollas före lagring i databasen är alltså saker som add_slashes resp magic_quotes_gpc fixar? :q Stämmer det? :q

Det enda som måste kollas är vad jag vet att sql-satsen inte påverkas på något sätt, dvs genom att oskadliggöra apostrofer... Så jag svarar ja på den frågan.