Beskyttelse Innocent MySQL fra SQL Injection
Forfatter:
Ashfaq Ansari

Anmeldt af:
Rating:
5
On Oktober 19, 2012
Sidst ændret:Januar 18, 2013

Resumé:

Detaljeret vejledning om, hvordan man forhindrer MySQL injektion i PHP. Sikker kodning regler og funktioner til at forhindre SQL injektion.

Indledning

 

Dette er en kort guide til hvordan du beskytter din uskyldige MySQL database fra SQL injektion angreb.
 

Hvad er SQL Injection?

 

Som navnet antyder, SQL Injection opstår, når brugeren tilfører SQL-sætninger i din ansøgning.
 
Hvordan sker det?
 
Sige, at vi har en simpel login-formular, der tager et brugernavn og en adgangskode, og validerer mod databasen. Hvis brugernavn og password er valideret, brugeren er logget ind i systemet.
 

Koden til dette kunne se noget som dette:
 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<?php
// få brugeren og password fra sendeanmodningen
$USER_NAME = $_POST[ 'Brugernavn' ];
$adgangskode  = $_POST[ 'Password' ];

$forespørgsel = "SELECT first_name, last_name, ACCOUNT_NUMBER FROM users_table WHERE brugernavn = '$USER_NAME"OG password = '$adgangskode' ";

$resultere = mysql_query( $forespørgsel );

// kontrollere, om mysql fundet noget, og få posten, hvis det lykkedes
hvis ( mysql_num_rows( $resultere ) > 0 ) {
    $data = mysql_fetch_assoc( $resultere );
    echo 'Velkommen' . $bruger . '!';
    echo 'Din konto nummer er: ' . $data[ 'ACCOUNT_NUMBER' ] . '';
} //Print ud errorr budskab
ellers {
    echo 'Brugernavn eller Password er ikke gyldigt! Prøv venligst igen!';
}
?>

 

Ovenstående script virker fint, og det vil give de ægte brugerne at indtaste deres brugernavn og adgangskode for at se deres bankkontonummer.
 

Lad os antage, at jeg træder ind “demo” da mit brugernavn, og “demopass” som min adgangskode, derefter SQL forespørgsel, der ledes til MySQL vil ligner dette:
 

1
SELECT first_name, last_name, ACCOUNT_NUMBER FRA users_table HVOR brugernavn = 'Demo' OG adgangskode = 'Demopass' ;

 

Hvis vores input data er valideret med succes i databasen, så vil vi blive logget ind i systemet, og vi vil blive præsenteret med kontonummeret ellers vil vi ikke få adgang til systemet, og vi vil blive præsenteret med en fejlmeddelelse “Brugernavn Password er ikke gyldigt! Prøv venligst igen!
 

Det problem, når en ondsindet bruger indtaster andre karakterer, der er beregnet til at opsige SQL.
 

Lad os antage, at en bruger forsøger at logge ind som brugernavn dem'o og password som demopass.
 

Nu, lad os se hvordan SQL-sætningen ser ud som.
 

1
SELECT first_name, last_name, ACCOUNT_NUMBER FRA users_table HVOR brugernavn = 'The'Den"OG password = 'demopass' ;

 

Når MySQL er fuldbyrdende redegørelsen, det vil kun behandler “Den” som brugernavn, og når det støder på en anden ‘Den', så det behandler ‘Den‘ som en SQL-kommando, og det vil kaste og fejlmeddelelse, da den ikke anerkender ‘Den‘ som en gyldig SQL-kommando.
 
ERROR 1064 (42000): Du har en fejl i din SQL-syntaks; tjekke manualen, der svarer til din MySQL server version for retten syntaks at bruge nær 'o’ og password =”demopass”; ” på linje 1
 

Awesome. Ovenstående fejlmeddelelse, at der er nogle fejl i SQL-syntaks. Hvis Magic Quotes blev aktiveret, så har vi måske ikke har fået at ovennævnte fejlmeddelelse.
 

Nu, lad os se hvad der sker, hvis den ondsindede brugeren indtaster brugernavn som (‘ Eller 1 = '1) og password som “demopass“.

SQL-forespørgslen vil se sådan ud:

1
SELECT first_name, last_name, ACCOUNT_NUMBER FRA users_table HVOR brugernavn = '' OR '1 '='1 ' OG adgangskode = 'Demopass' ;

 

Hvad betyder ovenstående SQL-forespørgsel betyde? Det fortæller MySQL at finde alle rækker med et brugernavn svarende til “” (blank) eller (1= 1) og et password lig “demopass“.
 

Lad os repræsentere ovenstående SQL-forespørgslen mere logisk at forstå, hvad er faktisk galt med SQL-sætningen:
 

brugernavn = “” OR “1= 1” AND password = “demopass”
 

Nu, vi allerede ved, at 1 = 1 altid vil være TRUE. Derfor, brugeren vil være i stand til at logge på systemet, hvis adgangskoden er korrekt, og brugernavn er forkert.
 

Lad os analysere mere værre scenarie med en anden angreb snor.
 

Attack String: ‘ OR 1 = 1–
 

Bemærk, at ( og #) anvendes til opsige SQL-sætning. Lad os sætte angrebet snor i en SQL-forespørgsel, og se, hvordan det endelige SQL vil se.
 

Nu, Vi vil antage, at angriberen ikke engang kender adgangskoden.
 

1
SELECT first_name, last_name, ACCOUNT_NUMBER FRA users_table HVOR brugernavn = '' OR 1=1--'AND password =' ​​idonotknow ' ;

 

Se hvordan SQL-sætningen fortolkes af MySQL.
 

brugernavn = “” OR 1 = 1– AND password = “idonotknow”
 

Bemærk i ovenstående opgørelse. Som vi ved, at er en erklæring terminator i SQL og 1= 1 er altid sandt, efter opgørelsen terminator resten af ​​SQL forespørgsel ikke vil blive henrettet.
 

Derfor, ALLE poster i tabellen vil blive returneret, og brugeren vil blive logget ind i systemet. Angriberen vil kunne se kontonummer den første post i databasen.
 

Lad os hjælpe uskyldige MySQL
 

Magic Quotes

 

Magic Quotes er et kontroversielt element i PHP scriptsproget, hvori specialtegn prep-sluttede med en backslash inden de føres videre.
 

Magic Quotes blev aktiveret som standard i nye installationer af PHP3 og PHP4, og da deres operation er bag kulisserne og ikke umiddelbart indlysende, udviklerne kan være uvidende om deres eksistens og de potentielle problemer, som de kan indføre.
 

Vi bliver nødt til at tænde Magic Quotes i php.ini fil i web-roden af ​​hjemmesiden.
 

Hvor Magic Citater hjælper?

 

Vi skal være undslippe disse citationstegn ( både enkelt og dobbelt anførselstegn, samt skråsteg).
Dette gøres ved at sætte en skråstreg foran dem.
 

So usename = dem'o bliver DEM 'o , og MySQL kan træne med at anførselstegn, som det er “beskyttet” ved en skråstreg.
 

Lad os se hvad der sker, når Magic Quotes tændes. Lad os se, hvordan hackeren er påvirket med Magic Quotes.
 

1
SELECT first_name, last_name, ACCOUNT_NUMBER FRA users_table HVOR brugernavn = '\' OR 1 = 1 - ' OG adgangskode = 'Idonotknow' ;

 

Den brugernavnet er fortolket som: \’ OR 1 = 1–

Det er en perfekt undslap SQL-forespørgsel, intet kan blive injiceret. magic_quotes_gpc undslipper den farlige enkelt tilbud for os. Derfor, hackeren vil ikke være i stand til at logge ind i systemet.

Problemer med Magic Quotes

 

Magic citater kun indsætte en backslash før nogle få tegn, intet mere. Det beskytter os mod SQL-injektion kun i nogle bestemte tilfælde som ovenfor, og kun ved at co-incidens. Hvis vi har display_errors ON, vi lige gjort angriberen meget tilfreds med din database detaljer udsendes lige før hans øjne. Selv hvis du ikke, der stadig er en mulighed for blind SQL-injektion og ved hjælp af forskud SQL injektion metoder er det muligt at omgå magic_quotes_gpc Funktionen.
 
Så, Vi har brug for en måde at undslippe data, der ikke er crappy, er ikke så tilbøjelig til tegnsæt spørgsmål, og er ikke tilbøjelig til magiske avl skåret citater.
 
I November 2005 de centrale PHP udviklere besluttet på grund af disse problemer, magiske citater funktion vil blive fjernet fra PHP 6.
Når Magic citater features trækkes tilbage, så der kommer til at være nogle store problemer dukker op.
 

SQL Injection Mitigation
 

Der er en række måder at forhindre MySQL injektioner indenfor PHP. De mest almindelige måder bruger funktioner såsom addslashes() og mysql_real_escape_string().
 

addslashes()

 

addslashes() vil returnere en streng med en omvendt skråstreg før tegn, der skal desinficeres i databaseforespørgsler. Disse tegn er enkelt anførselstegn (‘ = ’) anførselstegn (” = ”) og nullbyte (%00 = \0).
 

addslashes() vil kun fungere, hvis søgestrengen er pakket ind i anførselstegn. En streng som følgende vil stadig være sårbar over for en SQL injektion:
 

1
2
3
$USER_NAME = addslashes( $_POST[ 'Brugernavn' ] );
$adgangskode  = addslashes( $_POST[ 'Password' ] );
$forespørgsel = "SELECT first_name, last_name, ACCOUNT_NUMBER FROM users_table WHERE brugernavn = '$USER_NAME"OG password = '$adgangskode' ";

mysql_real_escape_string()

 

mysql_real_escape_string() er en lille smule mere kraftfuld end addslashes() da det kræver MySQL bibliotek funktion mysql_real_escape_string, der foranstiller backslashes til følgende tegn: \x00, \n, \r, \, ', ” og X1A.
 

Som med addslashes(), mysql_real_escape_string() vil kun fungere, hvis søgestrengen er pakket ind i anførselstegn. En streng som følgende vil stadig være sårbar over for en SQL injektion:
 

1
2
3
$USER_NAME = mysql_real_escape_string( $_POST[ 'Brugernavn' ] );
$adgangskode  = mysql_real_escape_string( $_POST[ 'Password' ] );
$forespørgsel = "SELECT first_name, last_name, ACCOUNT_NUMBER FROM users_table WHERE brugernavn = '$USER_NAME"OG password = '$adgangskode' ";

 

sprintf()

 

sprintf() kan anvendes med konvertering specifikationer for at sikre, at den dynamiske argument behandles den måde, det er vel at blive behandlet. For eksempel, Hvis en opfordring til brugere ID-nummer var i strengen, %s ville blive anvendt til at sikre argumentet behandles som en streng. Et eksempel på dette er som følger:
 

1
2
3
$USER_NAME = $_POST[ 'Brugernavn' ];
$adgangskode  = $_POST[ 'Password' ];
$forespørgsel = sprintf("SELECT first_name, last_name, ACCOUNT_NUMBER FROM users_table WHERE brugernavn = '%s"OG password = '%s' ", $USER_NAME, $adgangskode);

 

htmlentities($var, ENT_QUOTES)

 

htmlentities() i forbindelse med den valgfri anden quote_style parameter, tillader anvendelse af ENT_QUOTES, som vil konvertere både dobbelt-og enkeltværelser citater. Dette vil arbejde på samme måde som addslashes() og mysql_real_escape_string() i forhold til anførselstegn, dog, i stedet for at prepending en omvendt skråstreg, den vil bruge den HTML enhed i anførselstegn.
 

Ud over at bruge ENT_QUOTES inden htmlentities(), en tredje parameter kan indstilles som tvinger anvendelsen af ​​et tegnsæt inden konvertering. Dette vil hjælpe med at stoppe uforudsete resultater fra at bruge flerbyte tegn i tegnsæt såsom BIG5 og GPK.
 

Det følgende er et eksempel på kode, som ville hjælpe til at forhindre SQL injektion i PHP.
 

1
2
3
4
5
$USER_NAME = $_POST[ 'Brugernavn' ];
$USER_NAME = htmlentities( $USER_NAME, ENT_QUOTES, »UTF-8 ' );
$adgangskode  = $_POST[ 'Password' ];
$adgangskode  = htmlentities( $adgangskode, ENT_QUOTES, »UTF-8 ' );
$forespørgsel = "SELECT first_name, last_name, ACCOUNT_NUMBER FROM users_table WHERE brugernavn = '$USER_NAME"OG password = '$adgangskode' ";

 

Optimer SQL-kode

 

Databaseservere er komplekse bæster, og de har meget mere funktionalitet end du har brug for. Med hensyn til sikkerheden er bekymret, mere er aldrig bedre. For eksempel, Den xp_cmdshell udvidet lagret procedure i MS SQL giver adgang til skallen og det er lige hvad en hacker drømme om. Det er derfor, du bør deaktivere denne procedure, og alle andre funktioner, som let kan misbruges. Bare fjerne eller i det mindste deaktivere nogen funktionalitet du kan undvære.
 

Deaktiver Standard SQL Error Message

 

Fejlmeddelelser er nyttige for en angriber, fordi de giver yderligere oplysninger om database og SQL-forespørgsler. Og alle SQL angreb er normalt baseret på type fejl udstedt af SQL, betyder det, at type fejl afgør hackere metode til hacking hjemmesiden eller anvendelsen. En bedre løsning, der ikke kompromittere sikkerheden ville være at vise en generisk fejlmeddelelse der simpelthen hedder er opstået en fejl.
 

Opbevar Database legitimationsoplysninger Trygt

 

For at minimere den skade i tilfælde af en SQL-injektion angreb, opbevar altid database legitimationsoplysninger i en separat krypteret fil. Nu selv om en hacker formår at bryde ind, han eller hun vil ikke gavne meget, som han ikke kan gøre meget i din database.
 

Anvend Least Privilege Princip

 

Princippet om mindst privilegium er yderst gavnligt, og det gælder for SQL injektion samt. Altid tænke eller tjek om to gange, hvad privilegier du leverer til bruger eller objekt. Antag, at du wan at give moderator adgang til nogle bruger, så kun give ham adgang af disse tabeller, som han / hun har brug for, snarere end at bevise ham adgang hele databasen. Hvis du nødt til at give adgang til et system, sin bedre at skabe inddelte tablespaces inde database og giver kun adgang til specifikke bordplads. Denne teknik vil drastisk at reducere angrebet overfladen.
 

Deaktiver Shells

 

Mange databaser tilbyder shell adgang til databasen, som hovedsageligt er, hvad en hacker eller hacker behov. På grund af dette skal du lukke denne åbne smuthul. Hver udbyder har anden metode til deaktivere udførelsen af ​​skaller på deres database. Så konsultere din Database dokumentation om, hvordan du deaktiverer shell adgang til netop din database eller tabel rum eller bestemt tabel.
 

Bruger SQL injektion redskaber til at kontrollere Sårbarheder

 

Sidst men ikke mindst, tænke som hacker. Hvordan en hacker kan hacke min database via SQL injektion, hvilke værktøjer og teknikker, han kan bruge til at finde smuthuller. Du bør altid have en tør løbe af SQL-injektion hack værktøjer som SQLI, Haviz, SQL injectme etc.. Mere, hvis du har råd til nethinden sårbarhed scanner derefter sin alt for godt. Da det består af alle nyeste udsatte sårbarheder.

Mange tak. Jeg håber, du alle skal have nydt. Bedes du give kommentarer, så at vi kan gøre mere bedre.

 
 

28,921 samlede antal visninger, 20 visninger i dag

De følgende to faner ændre indhold under.

Ashfaq Ansari

Sikkerhed Forsker
Ashfaq Ansari er grundlægger af HackSys Team opkaldt kode "Panthera". Han er en sikkerhed forsker med erfaring i forskellige aspekter af Information Security. Han har forfattet "HackSys Extreme Sårbar driver" og "Shellcode of Death". Han har også skrevet og udgivet forskellige hvidbøger om software udnyttelse lavt niveau. Hans centrale interesse ligger i "Low Level Udnyttelse", "Reverse Engineering", "Program Analysis" og "Hybrid fnugdannelse". Han er en fanboy af kunstig intelligens og Machine Learning. Han er kapitlet føringen null Pune.

Seneste indlæg af Ashfaq Ansari (se alle)

Efterlad et svar

Din e-mail adresse vil ikke blive offentliggjort. Krævede felter er markeret *