Lidt $_GET sikkerhed og andet!

Tags:    php

<< < 123 > >>
Hej udviklere

Jeg er igang med at lave et community system til Travian.dk, men før jeg offentliggøre det hele, vil jeg gerne have sikkerheden i orden.

Her på Udvikleren har jeg læst lidt om sikkerhed, og læste også om noget jeg ikke har hørt om før - at man kan få ødelagt en hel del, ret simpelt i $_GET. Hvis vi nu siger jeg har et artikelsystem der kører på "artikel.php?id=tal", fik jeg at vide at man kan skrive noget ala:
"artikel.php?id=DROP TABLE artikler;" eller sådan noget, og så ryger det hele jo.
Hvordan kan man undgå dette?

Og har også læst lidt om SQL injections med brugerinputs. Men nogle snakker om addslashes, og andre om et eller andet ala mysql_real_escape_string eller sådan noget. Men er addslashes da ikke nok?

Og så vil jeg lige høre:
Alt i alt, vil I så sige at det er fin sikkerhed ved at community med at jeg md5(sha1()) password, gør det der med $_GET med artikel og det med addslashes? Er det nok sikkerhed, synes I? Eller mangler der noget?

ALT hvad der har med sikkerhed at gøre, kom med det. Gerne bare LIDT forklaring, og ellers bare et eksempel.

MVH
Alexander :-)






21 svar postet i denne tråd vises herunder
4 indlæg har modtaget i alt 7 karma
Sorter efter stemmer Sorter efter dato
Ikke helt korrekt. md5 er det mest normalt brugte. md5 kan desuden nemt omgås.


Hverken md5 eller sha1 er særligt gode i denne sammenhæng, da de ikke er beregnet til at sikre passwords på denne måde. Desuden er det en second line of defence. Er en cracker først kommet ind i databasen, kan han lige så nemt ændre passwordet til et han kender i forvejen.

At gøre det på den anden måde, med addslashes, sikrer bagudkompatibilitet. mysql(_real)_escape_string er forholdsvis ny. Bortset fra at mysql_escape_string findes i PHP4, i de ret tidlige versioner. Men jeg har flere gange været ude for webhoteller der kørte med tidligere versioner af PHP4.


mysql_real_escape_string
(PHP 4 >= 4.3.0, PHP 5, PECL mysql:1.0)

mysql_escape_string
(PHP 4 >= 4.0.3, PHP 5, PECL mysql:1.0)

Så selvom mange webhoteller kører PHP4, så virker de stadigvæk



Ikke helt korrekt. md5 er det mest normalt brugte. md5 kan desuden nemt omgås.


Hverken md5 eller sha1 er særligt gode i denne sammenhæng, da de ikke er beregnet til at sikre passwords på denne måde. Desuden er det en second line of defence. Er en cracker først kommet ind i databasen, kan han lige så nemt ændre passwordet til et han kender i forvejen.


Det er muligt, men isåtilfælde sikrer man i det mindste sin bruger mod at hans password, som han sikkert bruger mange andre steder, bliver afsløret. Den sikkerhed vil jeg mene at man som bruger på ethvert system har krav på.


At gøre det på den anden måde, med addslashes, sikrer bagudkompatibilitet. mysql(_real)_escape_string er forholdsvis ny. Bortset fra at mysql_escape_string findes i PHP4, i de ret tidlige versioner. Men jeg har flere gange været ude for webhoteller der kørte med tidligere versioner af PHP4.


mysql_real_escape_string
(PHP 4 >= 4.3.0, PHP 5, PECL mysql:1.0)

mysql_escape_string
(PHP 4 >= 4.0.3, PHP 5, PECL mysql:1.0)

Så selvom mange webhoteller kører PHP4, så virker de stadigvæk


Jeg har været ude for webhoteller der har helt ned til PHP 4.0.1 eller PHP3. Og det indenfor nyere tid.





Det er jeg dog ikke enig i. Da jeg kryptere mine brugeres password, giver jeg dem en ekstra sikkerhed, for så kan hackeren i hvertfald ikke komme til at få fat i passwordet. For selv bruger jeg da nogle gange samme passwords på forskellige sites, da jeg ikke gider finde på nye hele tiden, og dette ville jeg alligevel ikke kunne huske.

Men altså, vil det sige at i forslår at jeg bruger mysql_real_escape_string ellre hvad den nu hed?



Indlæg senest redigeret d. 25.03.2007 17:52 af Bruger #11195
Det er jeg dog ikke enig i. Da jeg kryptere mine brugeres password, giver jeg dem en ekstra sikkerhed, for så kan hackeren i hvertfald ikke komme til at få fat i passwordet. For selv bruger jeg da nogle gange samme passwords på forskellige sites, da jeg ikke gider finde på nye hele tiden, og dette ville jeg alligevel ikke kunne huske.

Men altså, vil det sige at i forslår at jeg bruger mysql_real_escape_string ellre hvad den nu hed?


Hvis du er ligeglad med om dit script kan bruges på ældre versioner af PHP, så er det klart den bedste løsning. Hvis du vil have bagudkompatilitet, er det nok ikke.

Ellers, så bare kør med mysql_real_escape_string. Det er tvivlsomt at du får brug for bagudkompatilitet. Det er kun sådan nogle som mig som kan lide forældede PHP-versioner der laver sådan noget ^^

EDIT: Bemærk iøvrigt at en person der bryder din sikkerhed og forsøger at tilrane sig oplysninger/lægge siden ned, ikke er en hacker, men derimod en cracker. En hacker er, i sin allermest simple forstand, en person der ved rigtig meget om computere. En cracker kan godt samtidig være hacker, men de to ting er ikke det samme.



Indlæg senest redigeret d. 25.03.2007 17:56 af Bruger #8223
if ($variabel > 0) { DO STUFF HERE }
else { DO STUFF HERE }

Det er forkert, tror jeg.

Stringen "3; DROP TABLE artikler;" vil blive fortolket som tallet 3 (ikke testet). Hvis du vil være sikker, er du nødt til at lave variablen om til et tal:

$variabel = (int) $variabel;



Okay. Men.. mysql magic quotes? Hvad er dette? Er det noget jeg selv skal slå til/fra, eller er det min webudbyder der skal gøre dette?

Men hvad betyder $id = (int) $_GET[id]; - altså, hvad betyder det "(int)". Betyder det 'kun tal'?



(int) betyder "lav om til et tal"

I PHP betyder det: (eksempel)
"1234" -> 1234
"abc1234" -> 0
"1234abc" -> 1234
"abc" -> 0

Altså: Hvis teksten indeholder et tal i begyndelsen, bliver denne del lavet om til et tal, ellers bliver teksten lavet om til nul.

magic_quotes er en funktion i PHP, der kan sikre scripts for folk, der ikke kan finde ud af sikkerhed. Det har en række uhensigtsmæssigheder, der efter min mening gør det dumt at bruge. Hvis funktionen er slået til (det er den som standard) vil VISSE variable være klargjort til at blive puttet ind i en database, og du skal derfor ikke bruge addslashes på disse variable. Til gængæld skal du bruge stripslashes, hvis du vil bruge dem andre steder, fx hvis du vil udskrive dem på siden.

Husk på at det kun er VISSE variabler, der er beskyttet (hvilke afhænger af konfigurationen), og du selv skal holde styr på hvilke det er. Derfor synes jeg det er bedst at slå magic_quotes fra og i stedet selv sørge for sikkerheden i sine sammensatte SQL queries.

EDIT: hvis du bruger et webhotel kan magic_quotes slås fra i en .htaccess fil.



Indlæg senest redigeret d. 26.03.2007 22:12 af Bruger #3143
Jeg har undersøgt det lidt nærmere, men der er en på php.net der forslår man bruger "ctype_digit"

Fold kodeboks ind/udKode 


Alser hvis det er en php kode som aligevæl laver linksne, så skulle der ikke opstå problemer på andre platforme. Ellers kan jeg forstille mig den "returns false" hvis tallet er i et andet format.

jeg er selv i gang med at afprøve "ctype_digit", det var helt rigtigt at min IF statement fra før ikke virkede som jeg ville have den til.

sagen er den at det er en variabel jeg med 100% sikkerhed hved skal indholde et tal, så man kunne jo teoretisk godt tjekke om der er en som prøver på noget han ikke burde, og så derved øjeblikligt opratte en logfil over det og banlyse personens ip. Det begynder at hjælpe på det :lol: Menn jeg holder mig nok til at vise en besked om at siden ikke kan vises.



sagen er den at det er en variabel jeg med 100% sikkerhed hved skal indholde et tal, så man kunne jo teoretisk godt tjekke om der er en som prøver på noget han ikke burde, og så derved øjeblikligt opratte en logfil over det og banlyse personens ip.


Hvorfor bandlyse IP'en? Der kan være en god grund til at brugen har prøvet med en forkert URL. Det kunne være du selv havde lavet en fejl i dit link eller det kunne være brugeren havde fået et forkert link. Mange forummer tager fx punktummet med i en adresse som denne:

Besøg siden http://www.example.com/page.php?id=1.


Selvom det måske ikke var meningen.



Indlæg senest redigeret d. 27.03.2007 20:10 af Bruger #3143
Okay. Men vil da lige slå det fra. Men hvor vil .htaacces fypisk ligge? Altså, i hvilken mappe? Har fundet den før, men er blevet svært med alle de filer jeg har på min side. ^.^



<< < 123 > >>
t