injecție și sql protecție împotriva acestora, shublog
Astăzi, voi atinge pe lung a promis un subiect despre SQL Injection (mai puțin de șase luni au trecut ... sau ... -. Nn). Voi încerca să le descrie cât mai simplu posibil și să arate tehnicile de bază de protecție a acestora (cu excepția cazului în care, desigur, voi descrie, pot fi descrise ca metode).
injecție SQL este foarte frecvente, oarecum similar cu XSS-atacuri (în detaliu în articolul „Cum de a proteja împotriva atacurilor XSS și repara vulnerabilitatea“), iar acestea se bazează pe introducerea unui SQL-cod arbitrar în orice cerere (chiar complet inofensive), în rezultând într-un atacator obține din baza de date necesară pentru el informații secrete (bine, sau pur și simplu șterge totul pentru a edronoy bunica -. nn).
SELECT * FROM utilizatori WHERE autentificare = "$ _POST [ 'conectare']" și passw = "$ _POST [ 'passw']"
Atunci când nu sunt verificate parametrii trecut, poți face orice vrei. De exemplu, în loc de conectare, puteți introduce admin „/ * precum și parola pe care le place (du-te să nu intre nimic), atunci cererea va arăta astfel .:
SELECT * FROM utilizatori WHERE de conectare = "admin" și / * passw = ""
Protecție împotriva SQL injection
Start simplu, cu un șir numeric. Dacă vom trece un număr, astfel că nimic nu este pus în aplicare, este necesar ca toate simbolurile cu excepția numerice, au fost aruncate. Două moduri:
Arătăm un scenariu că numărul dat este numărul.
Mai puțin de această metodă (sau un minus, ca oricine) următoarea - în cazul în care nu a trecut la numerele din numărul $ variabila devine deget de la picior. Nu este nimic teribil, dar doar în cazul, dacă nu există nici un secret de înregistrare la zero. Cu toate acestea, puteți rescrie întotdeauna script-ul verificând dacă valoarea este zero.
Înlocuirea o expresie regulată, care este tăiat totul cu excepția cifre.
$ Number = preg_replace ( "/ [^ 0-9] /", "", $ _POST [ 'număr']);
Cu șiruri de text nu este atât de simplu. Desigur, dacă aveți nevoie doar de numere și litere, toate caracterele rămase aveți posibilitatea să taie în condiții de siguranță de pe regexps:
$ String = preg_replace ( "/ [^ a-zA-Z0-9] / i", "", $ _POST [ 'string']);
Dar, uneori, tot felul de paranteze, căpușe sunt cu adevărat necesare. Ce să fac?
Există unele caractere care nu sunt în nici un caz nu ar trebui să fie permisă. Cel puțin în mod direct, puteți rula întotdeauna sezonul regulat pe text și să înlocuiască simbolurile lăsate pe simboluri speciale. Vorbeste despre personaje rele.
ghilimele simple și duble. Acestea sunt utilizate în cererile de alocare. Cred că mai mult din exemplul de mai sus, este clar de ce este necesar să le interzică. În orice caz, pentru a deranja cu ei de la sine, și nu, există întotdeauna htmlspecialchars și addslashes.
Semnul egal. S-ar părea o pictogramă inofensiv obișnuit, dar poate juca o glumă. De exemplu, avem cererea:
$ Sql = 'SELECT * FROM utilizatori WHERE id =' $ id .;
Dă ca parametru 1 OR name = "admin". Ca urmare, cererea va arata ca
SELECT * FROM utilizatori WHERE id = 1 OR name = "admin"
Cred că este clar că, dacă interzice un simbol al egalității, în loc de nume = „admin“ va fi numele de „admin“, iar acest lucru va cauza o eroare și cererea nu va funcționa.
SELECT * FROM utilizatori
Unde nume = $ id
Și o parolă = $ trecere
În plus față de întinderea și ștergerea informațiilor prin metodele de mai sus, vă puteți îmbina cu ușurință toate informațiile și baza de date într-un fișier sau pentru a efectua site-ul desfigurare. Și se pare că acest lucru
SELECT * ÎN outfile 'file.php'
Deci, vă puteți crea propriul script de pe site-ul și trebuie să danseze pe ea. Și dacă fișierele script sunt disponibile pentru toate intrările, putem face o desfigurare:
SELECT 'TU hacked!'ÎN outfile' index.php "
Pentru ziua de azi. Ai grija de scripturile din spiritele rele. Mult noroc!
Dragoste articole pe aceste teme, dar aici ca un pic pictat. Ne pare rău blog-ul meu ar conduce, pictat mai multe metode de protecție, și are deja două metode de lucru care a trebuit să scrie din cauza unor oameni curioși voi împărtăși unul dintre ei.
$ Url = html_entity_decode (urldecode ($ _SERVER [ 'QUERY_STRING']));
$ Url = str_replace ( "", "/", $ URL);
în cazul în care ((strpos ($ url '<' ) !== false) || (strpos( $url, '>„)! == false) || (Strpos ($ URL-ul, '„ ')! == false) || (strpos ($ url,' ./ ')! == false) || (strpos ($ url,' ../')! == false) || (strpos ($ url-ul, '\' „)! == false))
if (!! $ _GET [ 'mod'] = "editnews" sau $ _GET [ 'action'] = "lista") die ( "Bună, ce faci nu se întâmplă nimic :(?");
$ Url = html_entity_decode (urldecode ($ _SERVER [ 'REQUEST_URI']));
$ Url = str_replace ( "", "/", $ URL);
în cazul în care ((strpos ($ url '<' ) !== false) || (strpos( $url, '>„)! == false) || (Strpos ($ URL-ul, '„')! == false) || (strpos ($ url, '\' ')! == false))
die ( "Bună, ce faci nimic :( se întâmplă?");
Și se conectează funcția în sine:
În funcție de modul în care te uiți - am dat elementele de bază și un ghid de acțiune, dar nu a dat exemple complet gata.
Privit de la codul, mi-a placut testul, mai ales în directorul de nivel superior (../), vreau sa spun ca, chiar într-un fel nu cred că este prea merită.
Eu, de modul în care, în general, a placut ceea ce a fost făcut în plugin pentru WP anti-XSS-atac, care atârnă pe zona de verificare admin. Poate că nu este cel mai bun, dar cu sarcina de a face față. Sensul de bază față de HTTP_REFERER gazdă din gazda curentă.
De fapt, există într-adevăr modalitate ușoară de a scăpa de injecție: cripta toate datele din base64 am decripta de intrare și de ieșire. Este acolo pentru a scăpa de căpușe ...
În general, se confruntă cu XSS, dar cu SQL - nu ...
Hmm, n-am auzit de o astfel de opțiune. pur și simplu nu înțeleg cu adevărat, se pare a fi doar etichetele taie atunci când codificare, și tot felul de citate și slash-uri sunt, nu-i așa?
Despre codificare în base64 l-am cunoscut, acesta este un stadiu trecut. Acest lucru a fost mult timp apărat ... am mai mult de 3 ani în curs de dezvoltare o protecție pentru CMS, și în fiecare zi am invata ceva nou ..
Împărtășiți mai mult din orice chip, nu a menționat mai sus, în beneficiul cititorilor și proprietarul blogului? =)
Mai aproape de ieșire, forțele de tip) și pentru a semna nimic mai mult)
Vă mulțumesc, vom aștepta!)
În detrimentul cererii:
SELECT * FROM utilizatori WHERE id = 1; DELETE FROM utilizatori
Nu merge acest design, astfel de cereri sunt separate printr-un „;“ în phpMyAdmin, să trăiască același sistem, nu eksplodit cere virgulă, care ar efectua apoi le într-un ciclu, sau modul în care acestea vor lucra cu rezultatele interogării. ea konsnruktsiya mysql_query nu acceptă această opțiune.
I yuzayu mysql_real_escape_string (), scapă de citate și alte Backslash paraziți și norma