Het beschermen van Innocent MySQL vanuit SQL Injection
Auteur:
Ashfaq Ansari

Beoordeeld door:
Rating:
5
Op Oktober 19, 2012
Laatst gewijzigd:Januari 18, 2013

Overzicht:

Gedetailleerde handleiding over hoe je MySQL injectie in PHP voorkomen. Codebeveiligingsprocedures regels en functies om SQL-injectie te voorkomen.

Introductie

 

Dit is een korte handleiding over hoe te beschermen uw onschuldige MySQL database SQL-injectie aanvallen.
 

Wat is SQL Injection?

 

Zoals de naam al doet vermoeden, SQL Injection treedt op wanneer de gebruiker injecteert SQL-instructies in uw toepassing.
 
Hoe gebeurt dit?
 
Zeggen dat we een simpele login formulier met een gebruikersnaam en wachtwoord neemt, en valideert de database. Als de gebruikersnaam en het wachtwoord wordt gevalideerd, de gebruiker is ingelogd in het systeem.
 

De code hiervoor zou er ongeveer zo uitzien:
 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<?php
// krijgen de gebruikersnaam en het wachtwoord van de POST-aanvraag
$USER_NAME = $_POST[ 'Username' ];
$wachtwoord  = $_POST[ 'Wachtwoord' ];

$vraag = "SELECT voornaam, last_name, ACCOUNT_NUMBER FROM USERS_TABLE WHERE username = '$USER_NAME'AND wachtwoord ='$wachtwoord' ";

$gevolg = mysql_query( $vraag );

// controleren of mysql iets gevonden, en krijgen het record als het gelukt
indien ( mysql_num_rows( $gevolg ) > 0 ) {
    $gegevens = mysql_fetch_assoc( $gevolg );
    echo 'Welcome' . $gebruiker . '!';
    echo 'Uw rekeningnummer is: ' . $gegevens[ 'ACCOUNT_NUMBER' ] . '';
} //Print de errorr bericht
anders {
    echo 'Gebruikersnaam of wachtwoord niet geldig! Probeer het opnieuw!';
}
?>

 

Het bovenstaande script werkt prima en het zal toestaan ​​dat de echte gebruikers hun gebruikersnaam en wachtwoord in te voeren om hun bankrekeningnummer te zien.
 

Laten we aannemen dat ik binnenkom “demonstratie” als mijn gebruikersnaam, en “demopass” als mijn wachtwoord, dan is de SQL-query die wordt doorgegeven aan de MySQL zal er als volgt uit:
 

1
SELECT first_name, last_name, ACCOUNT_NUMBER UIT USERS_TABLE WAAR gebruikersnaam = 'Demo' EN wachtwoord = 'Demopass' ;

 

Als onze input data met succes is gevalideerd in de databank, dan zullen we zijn aangemeld in het systeem en we zullen worden gepresenteerd met het rekeningnummer anders zullen we niet de toegang tot het systeem te krijgen en we zullen worden gepresenteerd met een foutmelding “Gebruikersnaam of wachtwoord niet geldig! Probeer het opnieuw!
 

Het probleem wanneer een kwaadwillende gebruiker andere tekens die zijn bedoeld om de SQL-instructie te beëindigen binnenkomt.
 

Laten we aannemen dat een gebruiker probeert in te loggen als gebruikersnaam dem'o en het wachtwoord als demopass.
 

Nu, laten we eens kijken hoe de SQL-instructie ziet eruit als.
 

1
SELECT first_name, last_name, ACCOUNT_NUMBER UIT USERS_TABLE WAAR gebruikersnaam = 'Het'de'AND wachtwoord ='demopass' ;

 

Bij MySQL is de uitvoering van de verklaring, het zal alleen behandelen “de” zoals de gebruikersnaam en wanneer het andere tegenkomt ‘de', dan behandelt ‘de‘ als een SQL-opdracht en het zal gooien en foutmelding als het niet herkent ‘de‘ als een geldige SQL-opdracht.
 
FOUT 1064 (42000): Je hebt een fout in uw SQL-syntaxis; Raadpleeg de handleiding die overeenkomt met uw MySQL serverversie voor de juiste syntaxis te gebruiken in de buurt 'o’ en wachtwoord =”demopass”; ” op lijn 1
 

Ontzagwekkend. De bovenstaande foutmelding staat dat er een aantal fouten in SQL syntax. Indien Magic Quotes werden ingeschakeld, dan kunnen we misschien niet dat bovenstaande foutmelding hebben gekregen.
 

Nu, laten we eens kijken wat er gebeurt als de kwaadwillende gebruiker invoert gebruikersnaam als (‘ OR '1' = '1) en het wachtwoord als “demopass“.

De SQL-query ziet er als volgt:

1
SELECT first_name, last_name, ACCOUNT_NUMBER UIT USERS_TABLE WAAR gebruikersnaam = '' OR '1 '='1 ' EN wachtwoord = 'Demopass' ;

 

Wat betekent het bovenstaande SQL-query betekenen? Het vertelt MySQL om alle rijen te vinden met een gebruikersnaam die gelijk is aan “” (blank) of (1= 1) en een wachtwoord dat gelijk is aan “demopass“.
 

Laten we vertegenwoordigen de bovenstaande SQL-query meer logisch om te begrijpen wat er eigenlijk mis is met de SQL-instructie:
 

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

Nu, we weten al dat 1 = 1 zal altijd waar te zijn. Vandaar, de gebruiker in staat om in te loggen op het systeem zijn als het wachtwoord correct is en de gebruikersnaam is verkeerd.
 

Laten we het analyseren meer erger scenario met een andere aanval snaar.
 

Attack String: ‘ OR 1 = 1–
 

Houdt u er rekening mee dat ( en #) worden gebruikt SQL-instructie te beëindigen. Laten we de aanval tekenreeks in een SQL-query en zie hoe de uiteindelijke SQL-instructie zal zien.
 

Nu, we zullen aannemen dat de aanvaller niet eens weet het wachtwoord.
 

1
SELECT first_name, last_name, ACCOUNT_NUMBER UIT USERS_TABLE WAAR gebruikersnaam = '' OR 1=1--'AND wachtwoord =' ​​idonotknow ' ;

 

Zie hoe de SQL-instructie wordt geïnterpreteerd door MySQL.
 

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

Let op in de bovenstaande verklaring. Zoals we weten dat is een verklaring terminator in SQL en 1= 1 altijd TRUE, na de verklaring terminator rest van de SQL-query niet zal worden uitgevoerd.
 

Vandaar, ALLE records in de tabel krijgt terug en de gebruiker wordt aangemeld bij het systeem. Aanvaller in staat om het rekeningnummer van de eerste record te zien in de database zal zijn.
 

Laten we de hulp onschuldig MySQL
 

Magic Quotes

 

Magic Quotes is een controversiële kenmerk van de scripttaal PHP, waarin speciale tekens worden prep-afgesloten met een backslash voordat wordt doorgegeven.
 

Magic Quotes werden standaard ingeschakeld in nieuwe installaties van PHP3 en PHP4, en aangezien hun werking is achter de schermen en niet meteen duidelijk, ontwikkelaars kunnen zich niet bewust van hun bestaan ​​en de mogelijke problemen die ze kunnen introduceren.
 

We moeten op de zetten Magic Quotes in php.ini bestand in de web-root van de website.
 

Hoe Magic Quotes helpt?

 

We moeten ontsnappen aan deze aanhalingstekens ( zowel enkele als dubbele aanhalingstekens, evenals backslashes).
Dit gebeurt door een schuine streep voor hen.
 

So usename = dem'o wordt dem 'o , en MySQL kunnen trainen met dat aanhalingsteken zoals het is “beschermd” Door de schuine streep.
 

Laten we eens kijken wat er gebeurt als Magic Quotes ingeschakeld. Laten we eens zien hoe de aanvaller wordt getroffen met Magic Quotes.
 

1
SELECT first_name, last_name, ACCOUNT_NUMBER UIT USERS_TABLE WAAR gebruikersnaam = '\' OR 1 = 1 - ' EN wachtwoord = 'Idonotknow' ;

 

De gebruikersnaam wordt geïnterpreteerd als: \’ OR 1 = 1–

Dat is een perfect ontsnapte SQL-query, niets kan krijgen geïnjecteerd. magic_quotes_gpc ontsnapt aan de gevaarlijke enkele offerte voor ons. Vandaar, de aanvaller niet in staat zijn om in te loggen in het systeem.

Problemen met Magic Quotes

 

Magic quotes alleen plaatst u een backslash voor een paar personages, niets. Dit beschermt ons tegen SQL injectie slechts in enkele bijzondere gevallen zoals hierboven en alleen door toeval. Als we display_errors ON, we net de aanvaller erg blij met uw database gegevens uitgestuurd recht voor zijn ogen. Zelfs als je dat niet doet, er nog steeds een mogelijkheid van blind SQL injectie en met vooraf SQL injectie methoden is het mogelijk te omzeilen magic_quotes_gpc functie.
 
Dus, we moeten een manier om te ontsnappen gegevens die niet crappy, is niet zo gevoelig voor tekenset kwesties, en is niet gevoelig voor magie fokken drastisch quotes.
 
In November 2005 de kern PHP-ontwikkelaars besloten op grond van deze problemen die de magic quotes functie zou van PHP worden verwijderd 6.
Nadat de Magic quotes functies wordt ingetrokken, dan is er gaat worden een aantal grote problemen opduiken.
 

SQL Injection Mitigation
 

Er zijn een aantal manieren om te voorkomen MySQL injecties binnen PHP. De meest voorkomende manieren gebruikt functies zoals addslashes() en mysql_real_escape_string().
 

addslashes()

 

addslashes() zal een string met een backslash terugkeren voordat tekens die moeten worden gesaneerd in de database queries. Deze karakters zijn enkele aanhalingstekens (‘ = ’) dubbele aanhalingstekens (” = ”) en nullbyte (%00 = \0).
 

addslashes() werkt alleen als de query string is verpakt in quotes. Een tekenreeks als de volgende zou nog steeds kwetsbaar voor een SQL-injectie:
 

1
2
3
$USER_NAME = addslashes( $_POST[ 'Username' ] );
$wachtwoord  = addslashes( $_POST[ 'Wachtwoord' ] );
$vraag = "SELECT voornaam, last_name, ACCOUNT_NUMBER FROM USERS_TABLE WHERE username = '$USER_NAME'AND wachtwoord ='$wachtwoord' ";

mysql_real_escape_string()

 

mysql_real_escape_string() is een beetje krachtiger dan addslashes() als het bibliotheekfunctie MySQL's noemt mysql_real_escape_string, die backslashes Voegt de volgende tekens: \x00, \n, \r, \, ', ” en x1a.
 

Zoals addslashes(), mysql_real_escape_string() werkt alleen als de query string is verpakt in quotes. Een tekenreeks als de volgende zou nog steeds kwetsbaar voor een SQL-injectie:
 

1
2
3
$USER_NAME = mysql_real_escape_string( $_POST[ 'Username' ] );
$wachtwoord  = mysql_real_escape_string( $_POST[ 'Wachtwoord' ] );
$vraag = "SELECT voornaam, last_name, ACCOUNT_NUMBER FROM USERS_TABLE WHERE username = '$USER_NAME'AND wachtwoord ='$wachtwoord' ";

 

sprintf()

 

sprintf() kan worden gebruikt met conversiespecificaties zodat de dynamische argument wordt behandeld de manier waarop het veronderstellen behandelen. Bij voorbeeld, Als een oproep voor de gebruikers-ID-nummer waren in de string, %s zou worden gebruikt om ervoor te zorgen het argument wordt behandeld als een tekenreeks. Een voorbeeld hiervan is als volgt:
 

1
2
3
$USER_NAME = $_POST[ 'Username' ];
$wachtwoord  = $_POST[ 'Wachtwoord' ];
$vraag = sprintf("SELECT voornaam, last_name, ACCOUNT_NUMBER FROM USERS_TABLE WHERE username = '%s'AND wachtwoord ='%s' ", $USER_NAME, $wachtwoord);

 

htmlentities($was, ENT_QUOTES)

 

htmlentities() in combinatie met de optionele tweede parameter quote_style, maakt het gebruik van ENT_QUOTES, die zowel dubbele en enkele aanhalingstekens zal omzetten. Dit werkt in dezelfde zin als addslashes() en mysql_real_escape_string() met betrekking tot aanhalingstekens, echter, in plaats van prepending een backslash, het zal de HTML-entiteit van het aanhalingsteken gebruiken.
 

Naast het gebruik ENT_QUOTES binnen htmlentities(), een derde parameter kan worden ingesteld die het gebruik van een tekenset binnen conversie dwingt. Dit zal helpen stoppen met onvoorspelbare resultaten van het gebruik multibyte personages in tekensets zoals BIG5 en GPK.
 

Het volgende is een voorbeeld van code die zouden helpen voorkomen SQL-injectie in PHP.
 

1
2
3
4
5
$USER_NAME = $_POST[ 'Username' ];
$USER_NAME = htmlentities( $USER_NAME, ENT_QUOTES, 'UTF-8' );
$wachtwoord  = $_POST[ 'Wachtwoord' ];
$wachtwoord  = htmlentities( $wachtwoord, ENT_QUOTES, 'UTF-8' );
$vraag = "SELECT voornaam, last_name, ACCOUNT_NUMBER FROM USERS_TABLE WHERE username = '$USER_NAME'AND wachtwoord ='$wachtwoord' ";

 

Optimaliseren SQL Code

 

Databaseservers zijn complex beesten en ze hebben veel meer functionaliteit dan u nodig heeft. Wat de veiligheid betreft, meer is nooit beter. Bijvoorbeeld, de xp_cmdshell uitgebreide opgeslagen procedure in MS SQL geeft toegang tot de shell en dat is precies wat een hacker dromen. Dit is waarom je deze procedure en alle andere functionaliteit uit te schakelen,, die gemakkelijk kunnen worden misbruikt. Gewoon verwijderen of op zijn minst uit te schakelen elke functionaliteit die je kunt doen zonder.
 

Disable Standaard SQL Error Message

 

Foutmeldingen zijn nuttig om een ​​aanvaller, want ze geven meer informatie over de database en SQL queries. En alle SQL-aanvallen zijn meestal gebaseerd op de soort fout die door SQL, het betekent dat type fout beslist de aanpak hackers voor het hacken van de website of applicatie. Een betere oplossing is dat niet de veiligheid in gevaar brengt zou zijn om een ​​weer te geven generische foutmelding dat zegt gewoon een fout is opgetreden.
 

Bewaar Database Geloofsbrieven veilig

 

Om de schade in geval van een minimum te beperken SQL-injectie aanval, altijd slaan databasereferenties in een apart versleuteld bestand. Nu zelfs als een hacker erin slaagt om te breken in, hij of zij zal niet veel voordeel als hij niet veel kan doen in uw database.
 

Gebruik Least Privilege Principe

 

Het principe van de minste privilege is zeer gunstig en dit geldt voor SQL-injecties evenals. Denk altijd of kijk tweemaal over wat voorrechten u verleent aan gebruiker of object. Stel dat je wan om moderator toegang te bieden tot een aantal gebruikers, dus alleen hem te voorzien van de toegang van die tafels die hij / zij nodig heeft, eerder dan bewijzen hem de toegang van hele gegevensbank. Als je moet toegang verschaffen tot een systeem, het beter om creëren gepartitioneerde tabel ruimten binnen-databank, en alleen toegang tot specifieke tabel ruimte. Deze techniek zal drastisch verminderen van de aanval oppervlak.
 

Uitschakelen Shells

 

Veel databanken bieden toegang shell naar de database die in wezen is wat een aanvaller of een hacker behoeften. Vanwege deze moet je deze open lacune te dichten. Elke provider heeft andere methode om de uitvoering van schelpen uitschakelen op hun database. Dus je Database documentatie te raadplegen over hoe shell toegang voor uw specifieke database of tabel ruimte of bepaalde tabel uitschakelen.
 

Gebruik SQL Injection Tools Naar controleren kwetsbaarheden

 

Laatste maar niet de minst, denken als hacker. Hoe een hacker kan mijn gegevensbestand hacken via SQL-injectie, welke hulpmiddelen en technieken die hij kan gebruiken om de mazen te vinden. Je moet altijd een droge run van SQL-injectie hack tools zoals SQLi, Haviz, SQL injectme etc.. Meer als je kunt veroorloven netvlies vulnerability scanner vervolgens haar te goed. Omdat het bestaat uit alle nieuwste blootgesteld kwetsbaarheden.

Heel hartelijk bedankt. Ik hoop dat jullie moeten allemaal hebben genoten. Geef commentaar zodat we kunnen meer beter doen aub.

 
 

28,923 totaal aantal vertoningen, 22 aantal vertoningen vandaag

De volgende twee tabbladen te veranderen hieronder inhoud.

Ashfaq Ansari

Beveiliging Onderzoeker
Ashfaq Ansari is de oprichter van HackSys Team codenaam "Panthera". Hij is een security-onderzoeker met ervaring in verschillende aspecten van informatiebeveiliging. Hij is auteur "HackSys Extreme Kwetsbare Driver" en "Shellcode of Death". Hij heeft ook geschreven en publiceerde diverse whitepapers op een laag level software uitbuiting. Zijn belangrijkste interesse ligt in "Low Level Exploitation", "Reverse Engineering", "Programma Analyse" en "Hybride Fuzzing". Hij is een fanboy van Kunstmatige Intelligentie en Machine Learning. Hij is het hoofdstuk voorsprong van null Pune.

Laatste berichten van Ashfaq Ansari (bekijk alle)

Laat een reactie achter

Uw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd *