En SQL-injection behöver inte vara enkel

Jag läste precis artikeln "Hålet bakom hackarvågen" (http://www.idg.se/2.1085/1.141415) och blir som vanligt lite irriterad på hur säkerhetsexperter och media lägger fram sql-injections. Direkt det pratas om sql-injections så är det nått otroligt enkelt som vilken person som helst kan göra. Nu vet jag iof inte hur attackerna som diskuteras i artikeln gick till men de behöver inte varit enkla därför att man har injekterat sql-kommandon till databasen.

"En sql injection betyder att utvecklaren bakom webbapplikationen har glömt – eller struntat i – att kontrollera den data som användaren kan skicka via formulär eller adressfältet."

Det finns absolut ingenting som säger att de har struntat eller glömt att filtrera datan. En sql-injection kan vara riktigt knepig. De kan beror på dålig filtrering som går att komma förbi. De kan bero på att att två funktioner efter varandra slår ut grundfiltreringen. Det kan bero på att i php, t.ex mbstring är påslagen på en funktion och inte på den andra. De kan bero på hur webservern tolkar inputdatat. Det kan bero på att folk förlitar sig på trasiga filter som t.ex mod_security. Det kan bero på olika charsets i webservern och databasen, de kan beror på de tusentals bypasses som finns tack vare unicode. I PHP kanske de använder ereg felaktigt? De kanske försöker typa input-datan och inte riktigt förstår vad som händer i bakgrunden? (http://www.secweb.se/en/blog/mysql-and-dangerous-cast/). Det finns så otroligt många bypasses, felkonfigurationer, trasiga funktioner osv och en injection behöver inte vara enkel bara därför att den kan vara enkel.

Jag har spelat tusentals wargames och jag minns en level jag aldrig kommer att glömma. Input-datan var riktigt bra filterad för endast \(\)a-z0-9\s, själva injectionen låg i en insert into a values(type int(1), hacker_input int(1)) och type och hacker_input var sammansatta till en annan tabell så det enda man kunde stoppa in som resultat var type (1-3) och hacker_input (1-9), målet var att ta fram en md5()-sträng som låg i en annan tabell som varchar(32). Enkelt? nej, men det gick.

Solklart finns det en del krångligare varianter - charsets som stödjer multibyte characters osv., men jag har svårt att tro att sådant använts i några av de här fallen.

Du får gärna elaborera på de hål som finns i unicode? Något jag har missat, och jag använder unicode i mina webbprojekt


Och sedan måste du givetvis dela med dig av lösningen på wargamet

Edit: Eller ännu hellre - en länk dit så man kan spendera ett par veckor åt att lösa det själv

Hur löste du wargame-scenariot då? Don't leave us hangin'

Jo det har du rätt i finns många lösningar för att säkra ett hål men finns även många sätt att knäcka det .

Du får gärna elaborera på de hål som finns i unicode? Något jag har missat, och jag använder unicode i mina webbprojekt

Är det inte bara att köra parameterfrågor och glömma SQL-injects ?

/DM

[IDG Snipp]
Nu är det dags att börja se sig om efter andra säkerhetslösningar än användarnamn och lösenord, menar hon. OpenID, lösningen som Yahoo nyligen ställde sig bakom, eller den mer standardiserade Shibboleth, kan vara vägen att gå. Båda gör det möjligt att ha ett enda konto hos en betrodd leverantör som kan användas på många webbplatser.
[\IDG Snapp]

Äntligen, hacka en och få 300 på köpet (endast id(a)g)

En bra början är att läsa http://unicode.org/reports/tr36/


Nej. Tyvärr är det inte alltid så enkelt. Att skydda sig kräver tanke och det kan även handla om design, inställningar, flöde och tillfällighet. Jag skulle säga att prepared statements är det "bästa" enkla sättet att skydda sig på men det säger absolut inte att det inte går att komma runt. Förövrigt tycker jag prepared statements är overkill och tycker det ska undvikas där det inte behövs.


Yep, visst är det så.


Det kanske är dags att förstå att internet inte är ett säkert ställe och så länge inte alla chefer, utvecklare och användare är säkerhetsexperter så kommer hackare ligga steget före.


Jag har länge gått och tänkt på att börja skriva wargames igen. Och när jag väl tar tag i det så kommer ett av webspelen innehålla den leveln

Nu är jag, för tredje gången idag, way out of my league. Men det här vill jag hemskt gärna förstå.

unicode utf-8 skriver "\" som %5C, men det kan även representeras som %C1%9C i "non-shortest form".

Hade det varit så enkelt punkt och slut tänker jag mig att man kunant göra något i stil med

%C1%9C%27

När det sedan körs genom en säkerhetscheck läggs en backslash till citationstecknet, men säkerhetschecken förstår inte vad %C1%9C är, och lämnar det orört. Strängen som skickas till databasen blir då, i klartext

\\'

Jag testade detta på min egen server, och fick mycket skumma resultat. Strängen körs genom mysql_real_escape_string innan den sätts in i SQL-frågan.

MySQL reagerar inte alls - varken ett felmeddelande som säger att frågan är felaktig, eller att datan sätts in i databasen som den ska. Inget händer öht.

Vilket är skitskumt - antingen det borde mysql säga att där är ett citationstecken som är fel, eller så borde datan sättas in i databasen?! Det här förstår jag inte alls.

Jag printade queryn efter att den säkrats, och mycket riktigt skickas tecknet med:


Kan någon förklara varför mysql reagerar på detta sättet?

Edit: Kan vara värt att påpeka att allt körs via UTF-8, klient-apache-mysql, alles är utf-8