Sql injectie

  • Hallo, weet iemand hoe ik kan controleren of mijn site die ik aan het maken ben beveiligd is tegen sql injectie? Ik heb wel op internet gelezen dat je zoiets (" or "" =") in het inlogscherm of paswoord scherm moet zetten, maar dat werkt helemaal niet en de site is niet beveiligd dat weet ik zeker.
    Welke codes zou ik dan in het inlogscherm moeten plaatsen, want er zijn er meerdere en moet het ook in username en wachtwoord of is 1 van de twee al goed?

  • Als je een 'penetration test' wilt uitvoeren, raad ik je aan eens te kijken naar het Kali OS, welke meerdere tools bevat om website's te pentesten, waaronder (My)SQL injecties. Ik raad je echter wel sterk af dit op websites te gebruiken buiten localhost, of op websites van andere mensen :).


    Verder, om er echt zeker van te zijn, begin je te programmeren met beveiliging in mind (en niet met de mind set 'Komt later wel'). Elke input dat door een user gegeven word, door een user aangepast kan worden of door iets anders kan worden aangepast worden (waarvan jij zelf niet 100000% zeker weet of 't is wat je verwacht dat 't is), dient escaped te worden. Als je dat voor elkaar hebt, is de kans op (My)SQL-injecties relatief klein.

  • Ik ben ook zeker niet van plan om dit bij andere mensen te gebruiken, alhoewel ik het vaak genoeg in het verleden heb gehad dat andere dat wel bij mij deden. ZO was ik een aantal jaar geleden bezig om een source bugvrij te maken en was nog niet begonnen met de beveiligen. En toen was er ook iets gebeurd ik helemaal opnieuw kon beginnen.
    Ik heb ook wel eens samen met een vriend gekeken naar mysql injecties omdat ik hem voor hem moest beveiligen. Toen hebben we ook wat codes gebruikt op zijn website bij het inloggen en toen kwamen we er wel in, alleen weten we tot de dag van vandaag niet hoe de database gegevens aangepast kunnen worden door zo een injectie. Maar als ik het op mijn eigen site probeer kom ik er echter niet in, terwijl ik zeker ben dat er nog geen beveliging opzit. Vandaar ook de vraag.
    En weet je dan niet welke codes er gebruikt moeten worden in zo een input veld?
    Waar vind ik dan iets over die injecties? Want ik zie alleen maar images dingen.

  • Kali OS, waarbij OS voor 'Operating System' staat. In andere woorden, het gaat hier om een volledig besturingssysteem (gebasseerd op Linux) wat vol met zulke tools zit (o.a. voor wifi testen / kraken, etc.). Downloaden en op een VM installeren lijkt me de beste manier om ermee te beginnen. Hoe het precies werkt, kan ik je niet uitleggen. Mogelijk dat je hiervoor even zelf moet gaan googlen en kijken hoe en wat.


    Over wat een MySQL injectie precies is en hoe je deze uitvoert, gebruik google. Er zijn enorm veel websites die uitleggen wat dit precies is, wat er gebeurd en hoe je dit doet.

  • Het begint inderdaad met het begrijpen wat SQL-injectie nu precies is.


    Een query ziet er vaak als volgt uit (abstract):

    Code
    [SQL][DATA][SQL][DATA]etc.

    Waarbij [SQL] gewone SQL is en [DATA] variabele data is die uit een externe bron komt ("van buiten de database"). Doordat de uiteindelijke query dynamisch van aard is waarbij de [DATA]-plaatsen min of meer als placeholders gebruikt worden stelt dit je ook in staat om dynamische content of zelfs complete webpagina's te genereren met de resultaten hiervan.


    Het gedrag van zo'n query ligt vaak wel vast: deze heeft een zeker voorgeschreven werking. Indien dit soort dynamische queries niet goed beveiligd zijn kan men de werking van de query manipuleren. Dit is dan mogelijk doordat de [DATA]-delen als SQL geïnterpreteerd kunnen worden. Dit is normaal gesproken natuurlijk nooit de bedoeling, vaak wordt deze manipulatie-ruimte misbruikt om queries naar je hand te zetten en ofwel gevoelige informatie te stelen of rechtstreeks controles te omzeilen. Dit is wat SQL-injectie in feite is: het injecteren van DATA in een query die vervolgens als SQL geïnterpreteerd wordt.


    Hoe voorkom je SQL-injectie? Dit doe je door de DATA te ontdoen van enige mogelijke speciale betekenis die deze DATA heeft binnen SQL. Concreet: door deze DATA te escapen. Er zijn verschillende manieren om dit te doen, dus het hangt er een beetje vanaf wat je gebruikt. MySQLi? PDO? Iets anders?


    Iets wat wel belangrijk is is het volgende: escaping is gekoppeld aan character encoding. Of liever gezegd, voor een correcte werking van escaping is het zaak dat je character encoderingen in de pas lopen.


    Daarnaast moet ook niet blindelings vertrouwd worden op enkel de escaping-functionaliteit. Deze functies escapen alleen bepaalde karakters, er wordt niets ge-escaped als er niets te escapen valt! Zo zou bijvoorbeeld het uitvoeren van een real_escape_string() functie of methode op het volgende stuk DATA geen enkel effect hebben:

    Code
    OR 1=1

    En daarmee is mogelijk een SQL-injectie geslaagd.


    Als je dus enkel escaping-functionaliteit gebruikt en verder niets is dit dus vaak onvoldoende om SQL-injecties te voorkomen!


    Eigenlijk dien je in andere (of liever gezegd ALLE) contexten precies hetzelfde te doen: in de HTML-context escape je ook (user) DATA met behulp van functies als htmlspecialchars() (en deze functie heeft ook een parameter voor een character encoding!) om ervoor te zorgen dat deze niet als HTML geïnterpreteerd wordt of als JavaScript die mogelijk uitgevoerd kan worden.


    En dit alles valt eigenlijk weer onder het bredere motto Filter Input, Escape Output. Eigenlijk zou je bij elk stuk data wat uit een externe bron komt jezelf af moeten vragen of er een reden is om het niet te escapen, en dat anders gewoon altijd doen. Zelfs als (user) DATA is weggeschreven naar de database is data nog steeds niet veilig, omdat je niet altijd op voorhand kunt zeggen in welke context deze gebruikt gaat worden en wat er dan ge-escaped dient te worden.


    Escaping-on-input (alles vantevoren onschadelijk maken door er bijvoorbeeld allerlei escaping-functionaliteit overheen te gooien voordat je dingen naar de database wegschrijft) is ook geen goede oplossing, omdat je dan mogelijk dingen op den duur moet un-escapen. Ook is het gewoon veel makkelijker om er vanuit te gaan dat iets niet ge-escaped is en dat dan altijd net voor gebruik (weergave op een pagina of gebruik in een query) te doen.


    Dit zorgt gewoon voor een super consequente werkwijze waar de kans op fouten vrij klein is, mede door de continue realisatie dat je met onbetrouwbare (user) DATA bezig bent, en natuurlijke de rechtstreekse escaping op het moment dat dit nodig is, je kunt dit direct zien en je hoeft je dan dus ook niet af te vragen of dit ergens anders wellicht is gebeurd.

Participate now!

Heb je nog geen account? Registreer je nu en word deel van onze community!