Die rasante Entwicklung neuer Technologien hat den Unternehmen nicht nur einen Wettbewerbsvorteil und einen Rentabilitätsschub verschafft, sondern auch ein großes Problem mit der Cybersicherheit. Heutzutage können Hacker sowohl manuelle als auch automatisierte Angriffe durchführen, die von Tag zu Tag raffinierter werden. Das Komische daran ist, dass einige der beliebtesten Software-Schwachstellen zwar bekannt sind und leicht erkannt werden können, aber immer noch aktiv ausgenutzt werden.
So wurde beispielsweise die SQL-Injektion erstmals 1998 entdeckt und ist laut OWASP immer noch das größte Sicherheitsrisiko in Webanwendungen. Darüber hinaus sind SQL-Injektionen zusammen mit Brute-Force-Methoden und der Verwendung gestohlener Anmeldedaten für sage und schreibe 80 % der weltweiten Datenschutzverletzungen verantwortlich.
In Anbetracht der weiten Verbreitung dieser Webschwachstelle haben wir einen umfassenden Leitfaden zu SQL-Injektionen zusammengestellt, der die folgenden Fragen enthält:
In diesem Artikel behandeln wir:
Was ist eine SQL-Injektion?
Bevor wir uns mit der Definition der SQL-Injektion befassen, sollten wir zunächst über SQL selbst sprechen. SQL (Structured Query Language) ist eine Programmiersprache, die für den Zugriff auf und die Bearbeitung von Datenbanken verwendet wird.
SQL wird von einigen der beliebtesten Datenbankverwaltungssysteme wie MySQL und Microsoft SQL verwendet.
SQL-Injection (SQLi) ist ein Angriff auf die Cybersicherheit, der auf Websites und Webanwendungen abzielt, die SQL-Datenbanken verwenden. Es handelt sich dabei um eine Technik zur Code-Injektion, bei der bösartige SQL-Anweisungen über Web-Eingaben platziert werden. Mit anderen Worten, ein Bedrohungsakteur oder der “Bösewicht” probiert eine Reihe von SQL-Befehlen aus, um die Datenbank zu manipulieren und eine Antwort zu erhalten, die hoffentlich einige sensible Daten enthüllt.
Im Falle einer erfolgreichen SQL-Injektion kann der Hacker eines der folgenden Dinge tun:
- Umgehen der Authentifizierung
- Die Identität eines Benutzers, einschließlich einer Führungskraft, zu stehlen
- Abrufen, Hinzufügen, Ändern oder vollständiges Löschen von Datensätzen in der Datenbank
- Sich als Administrator ausgeben
- Andere manipulative Verhaltensweisen ausführen
SQL-Injections sind deshalb so häufig, weil viele Websites SQL-Datenbanken verwenden und die Implementierung relativ einfach ist.
Kostengünstig
Leicht durchführbar
Hohe Attraktivität des Ziels (sensible, hochwertigeDaten)
auf einmal betroffen
Wie funktioniert die SQL-Injektion?
SQL-Injektionen sind möglich, wenn auf einer Website oder in einer Webanwendung kein angemessener Prozess zur Bereinigung von Eingaben vorhanden ist. Einfach ausgedrückt, verhindert die Eingabesanitisierung, dass Hacker Sonderzeichen verwenden, um bösartigen Code in das Dateneingabefeld einzuschleusen.
Eine legitime SQL-Abfrage ist nichts anderes als eine Interaktion zwischen dem Benutzer und der Datenbank. Durch die Eingabe eines Benutzernamens und eines Kennworts fordert der Benutzer beispielsweise Zugriff auf die Software an. Wenn einige der eingegebenen Zeichen nicht mit den auf dem Server gespeicherten Anmeldedaten übereinstimmen, wird der Zugang verweigert.
Wenn die Entwickler jedoch unvorsichtig waren und es versäumt haben, eine strenge Eingabensanitisierung zu implementieren, kann der Hacker Eingabeformulare verwenden, um seine eigenen Anfragen an die Datenbank zu senden, indem er Strings mit ausführbarem SQL-Code eingibt.
Bevor wir zeigen, wie man eine SQL-Injektion durchführt, wollen wir zunächst die Typen der SQL-Injektion erläutern, um die Prinzipien, die diesen webbasierten Angriff ermöglichen, besser zu verstehen.
Typen der SQL-Injektion
Je nach den Absichten des Angreifers und den Sicherheitskontrollen des Systems werden unterschiedliche SQL-Injectionstechniken angewandt. Gehen wir einige der gängigsten Arten von SQL-Injektionen durch, um die Szenarien zu erkennen, die Hackern grünes Licht geben.
Klassische SQL-Injektionen
Die klassische SQL-Injektion, auch bekannt als In-Band-Injektion, stützt sich auf einen Kommunikationskanal, um sowohl den Angriff durchzuführen als auch die Daten zu sammeln. Sie gilt als die am einfachsten zu implementierende Methode, über die Daten exfiltriert werden können:
- Fehlermeldungen. In diesem Fall gibt der Hacker absichtlich eine Eingabe ein, die zu einem Fehler führt, um Einblicke in die Datenbankstruktur zu erhalten. Sicherlich kennen Sie diese verwirrenden Fehlermeldungen, die für den Endbenutzer wertlos sind, aber wichtige technische Details enthalten – genau das, was Hacker herauszufinden hoffen.
- UNION-Operatoren. Hacker können das UNION-Schlüsselwort verwenden, um ihre ursprüngliche Abfrage zu erweitern, indem sie zwei oder mehr SELECT-Anweisungen kombinieren. Diese Art von Angriff ermöglicht die Durchführung tabellenübergreifender Abfragen.
Blinde SQL-Injektionen
Diese Art der Injektion erfordert mehr Geduld seitens des Hackers, da keine Daten auf der Webseite angezeigt werden und die Datenbankaufzählung Zeichen für Zeichen erfolgt. Sie ist anwendbar, wenn die Datenbank nur allgemeine Fehlermeldungen anzeigt, der Code aber dennoch angreifbar sein kann. Blinde SQL-Injektionen erfordern einige Brute-Force-Techniken und unzählige Anfragen; dieser Prozess kann jedoch dank Tools wie SQLMap auch automatisiert werden. Blinde SQL-Injektionen werden weiter unterteilt in:
- Inhaltsbasiert Der Bedrohungsagent stellt eine Reihe von richtigen oder falschen Fragen und bestimmt anhand der unterschiedlichen Antworten der App, ob die Aussage richtig oder falsch war.
- Zeitbasiert Der Hacker verwendet verschiedene zeitbasierte Funktionen von SQL-Datenbanken, um herauszufinden, welche Art von Datenbank verwendet wird, da verschiedene Datenbanken unterschiedliche Funktionen für dieselben Vorgänge verwenden. Durch die Verwendung von sleep oder ähnlichen SQL-Befehlen können sie außerdem leicht feststellen, ob die Abfrage richtig oder falsch ist: sofortige Antwort – falsch; die Datenbank antwortet mit der genannten Verzögerung – richtig.
Out-of-Band SQL-Injections
Diese Art der SQL-Injektion ist weniger häufig, da sie von der Fähigkeit des Servers abhängt, DNS- oder HTTP-Anfragen zu erstellen, um Daten an den Hacker zu übertragen. Die letztgenannten Funktionen sind möglicherweise nicht bei allen Datenbankservern von Anwendungen aktiviert, was die Erfolgsquote dieses bösartigen Vorhabens einschränkt.
Out-of-band-SQL-Injektionen werden so genannt, weil der Hacker nicht denselben Kanal zur Durchführung eines Angriffs verwenden kann. Wenn zum Beispiel die Antwort des Servers zu langsam oder instabil ist, wird es schwierig, mit inferentiellem SQLi zu arbeiten.
Beispiel für einen SQL-Injection-Angriff
Es ist zwar immer eine gute Idee, sich mit theoretischem Wissen auszustatten, aber noch vorteilhafter ist es, sich praktisches Wissen über die zu untersuchende Frage anzueignen.
Ohne weiter auszuschweifen, lassen Sie uns einen Blick auf die Grundlagen werfen, die Ihnen ein besseres Verständnis dafür vermitteln, wie man eine SQL-Injection durchführt.
SQLi Code Beispiele
SQLi-Typen gibt es in der Tat viele; die einfachsten und populärsten drehen sich jedoch um Manipulationen mit den Anweisungen UPDATE, INSERT und SELECT sowie den WHERE- und ORDER BY-Klauseln.
Die folgenden Beispiele decken die Grundlagen ab und sind nur möglich, wenn es keine Sicherheitskontrollen gegen die Eingabe gefährlicher Syntax in Eingabefelder gibt.
Abrufen von Daten mit WHERE-Klausel
Nehmen wir an, Sie surfen auf einer E-Commerce-Website und bleiben in der Rubrik Zubehör stehen. Eine typische URL würde in diesem Fall etwa so aussehen:
https://e-commerce-website.com/products?category=Accessories
Was unter der Haube passiert, sieht etwas anders aus:
|
1 2 3 |
SELECT * FROM products WHERE category = 'Accessories' AND released = 1 |
Hier stellt die Webanwendung eine SQL-Abfrage an die Datenbank, um dem Endbenutzer nur das verfügbare Zubehör anzuzeigen. Diese Abfrage kann leicht geändert werden, indem eine “intelligente” SQL-Syntax wie z. B. doppelte Bindestriche eingefügt wird, um einen Teil der Abfrage auszukommentieren und sie somit irrelevant zu machen.
https://insecure-website.com/products?category=Accessories’––
Hier ist der SQL-Code für die gleiche Abfrage:
|
1 2 3 |
SELECT * FROM products WHERE category = 'Accessories'--' AND released = 1 |
In diesem Fall kann der Hacker auch alle nicht freigegebenen Elemente sehen, da die Einschränkung released=1 deaktiviert ist.
Die Schwachstelle kann weiter missbraucht werden, indem Eingaben hinzugefügt werden, die immer wahr sind, wie z. B. OR 1=1.
https://insecure-website.com/products?category=Accessories’+OR+1=1––
Die Datenbank erhält folgende Informationen:
|
1 2 3 |
SELECT * FROM products WHERE category = 'Accessories' OR 1=1--' AND released = 1 |
Im obigen Fall liefert die Datenbank alle Artikel, sowohl freigegebene als auch nicht freigegebene, aus allen anderen Kategorien.
Anmelden ohne Anmeldeinformationen
Ein weiterer Anwendungsfall für die Verwendung der intelligenten Syntax ist der Zugriff auf eine Anwendung, für die man nur einen Benutzernamen zur Verfügung hat. Die Strategie ist dieselbe: Verwenden Sie die Doppelstrich-Sequenz, um einen Teil des Codes auszublenden.
Hier ist der grundlegende SQL-Code, der die Benutzeranmeldung ermöglicht:
|
1 2 3 |
SELECT * FROM users WHERE username = 'john' AND password = 'johndoe123' |
Hier ist die injizierte Version der gleichen Abfrage:
|
1 2 3 |
SELECT * FROM users WHERE username = 'administrator'--' AND password = '' |
Wenn der Hacker annimmt, dass der Benutzername “administrator” oder “admin” ist, was immer noch der Fall sein kann, und den SQL-Kommentarindikator vor dem Passwortteil der Abfrage verwendet, kann er sich als der tatsächliche Administrator oder der Benutzer, der zufällig diesen Benutzernamen hat, anmelden.
Noch schockierender ist, dass in einigen Fällen nicht einmal der Benutzername erforderlich ist.
|
1 2 3 |
SELECT * FROM Users WHERE Name ="" or ""="" AND Pass ="" or ""="" |
Indem er die Anwendung mit immer-wahr-Aussagen austrickst, z. B. dass eine leere Zeichenkette immer gleich einer anderen leeren Zeichenkette ist, kann sich der Hacker erfolgreich anmelden, ohne irgendwelche Anmeldedaten zu haben.
Maximierung des Gewinns
Wenn ein erster SQLi-Angriff erfolgreich war und die App mit den tatsächlichen Daten aus der Zieltabelle antwortet, ist dies eine Gelegenheit, die sich Hacker nicht entgehen lassen dürfen. Höchstwahrscheinlich werden sie mit einem UNION-Angriff fortfahren.
Hacker können die Fähigkeiten des UNION-Schlüsselworts ausnutzen, indem sie beispielsweise eine oder mehrere zusätzliche SELECT-Abfragen ausführen und die Ergebnisse an die ursprüngliche Abfrage anhängen, um auf Daten aus anderen Tabellen zuzugreifen.
Für einen UNION-Angriff müssen bestimmte Kenntnisse der Datenbankstruktur und andere Voraussetzungen erfüllt sein. Wenn wir jedoch davon ausgehen, dass ein Bedrohungsagent die Anzahl der Spalten, die die ursprüngliche Abfrage zurückgibt, die Art der Daten, die sie enthalten können, den Namen der Tabelle und ihre Spalten kennt, kann er davon ausgehen
|
1 2 3 |
SELECT name, description FROM products WHERE category = 'Accessories' |
hierzu
|
1 2 3 |
' UNION SELECT username, password FROM users--, |
die es ihnen ermöglicht, nicht nur die Produkte und ihre Beschreibungen, sondern auch die entsprechenden Benutzernamen und Passwörter abzurufen.
SQLi Beispiele aus der Praxis
Um zu beweisen, dass wir die tatsächliche Bedrohung durch SQLi nicht übertreiben, haben wir eine Liste der jüngsten SQLi-Angriffe und der schweren Verluste zusammengestellt, die die betroffenen Unternehmen erlitten haben oder hätten erleiden können, wenn es keine White Hat Hacker gegeben hätte.
3,7 Mio. gehashte Passwörter entwendet
Einfacher Google-Hack zum Auffinden von DB-Schwachstellen
Vielleicht fragen Sie sich auch, woher die Hacker wissen, welche Website (von fast 2 Milliarden) sie angreifen müssen, um ihre Chancen auf einen erfolgreichen SQLi-Angriff zu erhöhen. Nun, es gibt eine spezielle Technik, die als Google-Hacking oder Google-Dorking bekannt ist. Letzteres wird verwendet, um alle Arten von sensiblen Informationen abzurufen – von E-Mail-Adressen und Zahlungskartendaten bis hin zu anfälligen Servern und ungeschützten Internetkameras.
Das Google-Hacking wurde 2002 ins Leben gerufen, als Johnny Long, ein anerkannter Computersicherheitsexperte, beschloss, erweiterte Google-Suchanfragen zu dokumentieren, die anfällige Systeme oder sensible Informationen enthielten. Im Laufe der Jahre ist die anfängliche Liste der Google Dorks, also der fortgeschrittenen Suchanfragen, zu einer ganzen Datenbank angewachsen, die heute von Offensive Security gepflegt wird.
Die Verwendung von Google Hacking zum Auffinden von SQLi ist nur eine kleine Teilmenge dessen, was Sie mit dieser erweiterten Suchtechnik tun können. Und so kann man es machen.
Nehmen wir an, wir gehen zu Google und geben etwas wie dieses ein:
|
1 2 3 |
site:com inurl:id "You have an error in your SQL syntax" |
Mit dieser Abfrage wird die Suchmaschine aufgefordert, alle .com-Websites zu durchsuchen, die irgendeinen Syntaxfehler in ihrem SQL-Code aufweisen. Bei diesen Syntaxfehlern handelt es sich wahrscheinlich um absichtlich platzierte Injektionen.
Zu bedenken ist auch, dass Google nicht die einzige Suchmaschine ist, die die erweiterte Suche unterstützt. Sie können die gleichen Ergebnisse mit Bing, Yahoo oder DuckDuckGo erzielen; der einzige Unterschied liegt in der Syntax der Suchoperatoren, die sich bei den verschiedenen Suchmaschinen leicht unterscheidet.
Wie kann man SQL Injection verhindern?
Nach all diesen erschreckenden Informationen über die Gefahren von SQLi stellt sich die berechtigte Frage, wie man SQL-Injection verhindern kann. Da es diesen Angriff schon seit einiger Zeit gibt, haben die Sicherheitsexperten gelernt, wie man ihn bekämpft und Webanwendungen gegen verschiedene SQLi-Typen zukunftssicher macht.
Zwar ist jeder Fall einzigartig und erfordert eine professionelle Untersuchung durch Sicherheitsberater und Pentester, aber diese bewährten Sicherheitspraktiken werden für die meisten Unternehmen ausreichen und das SQLi-Risiko erheblich verringern.
Hier sind einige der bekannten Techniken zur Verhinderung von SQL-Injektionen, die tatsächlich funktionieren.
Refactor Legacy Code
Legacy-Software ist dafür bekannt, dass sie eine Reihe von Problemen verursacht, wobei die Sicherheit eines der schädlichsten ist.
Der Grund, warum Legacy-Anwendungen für Hacker ein leichtes Opfer sind, liegt darin, dass sie aufgrund von Inkompatibilität oder anderen technischen Einschränkungen keine wirksamen Sicherheitskontrollen integrieren können. Wenn die Anwendung also nicht vollständig neu geschrieben und auf den modernen Stack migriert werden kann, sollte zumindest eine teilweise Umstrukturierung der anfälligsten Module in Betracht gezogen werden.
Serverseitige Eingabevalidierung verwenden
Jede Dateneingabe erfordert eine Validierung, damit der Benutzer Zugang erhält oder andere Aktionen durchführen kann. Die clientseitige Validierung wird oft als schnelle Erstüberprüfung im Browser angesehen, die es dem Benutzer ermöglicht, Eingabefehler schnell zu erkennen. Unabhängig davon, ob HTML5 integriert ist oder mit Javascript angepasst wurde, ist die clientseitige Validierung leicht zu umgehen und gilt als unsicher und unzuverlässig.
Daher kann eine starke Eingabevalidierung nur auf der Serverseite erfolgen. Darüber hinaus wird die serverseitige Eingabevalidierung weiter unterteilt in eine Positivliste (allowlist) und eine Negativliste (blocklist). Erstere gilt als wirksamer im Kampf gegen SQLi.
Die serverseitige Validierung von Eingaben funktioniert folgendermaßen: Der Server akzeptiert nur die Daten, die als gut und akzeptabel definiert wurden. Die Überprüfung der Angaben zur Kreditkartennummer kann beispielsweise Schritte wie die Überprüfung der erwarteten Anzahl von Ziffern, die ausschließliche Eingabe von Zahlen und das Bestehen der Luhn-Formel umfassen.
Darüber hinaus sollte die serverseitige Validierung sowohl auf syntaktischer (Korrektheit von Datums- und Währungssymbolen) als auch auf semantischer Ebene (Validierung der Eingabe in Bezug auf den Geschäftskontext) erfolgen.
Auch wenn die Zulässigkeitsliste recht umfassend sein kann, sollte die serverseitige Eingabevalidierung nicht als primäre Sicherheitsmaßnahme gegen SQLi angesehen werden, sondern eher als zusätzlicher Schritt in einem mehrschichtigen Sicherheitsprogramm.
Datenbankbenutzerrechte einschränken
Das Prinzip der geringsten Privilegien (POLP) ist im Bereich der Informationssicherheit sehr bekannt. Und es ist ziemlich einfach: Beschränkung des Datenbankzugriffs auf der Grundlage einzelner Benutzerrollen und ihrer täglichen Funktionen.
Normalerweise muss nur eine begrenzte Anzahl von Personen etwas in der Datenbank erstellen oder löschen. Daher muss sichergestellt werden, dass die Mehrheit der Benutzer nur den für ihre Tätigkeit unbedingt erforderlichen Lesezugriff und partielle Tabellenansichten erhält.
Ein weiterer wichtiger Faktor ist, dass Sie die Standard-DBMS-Berechtigungen auf “eingeschränkt” ändern müssen, damit der Hacker auch bei einem erfolgreichen SQLi-Angriff keine vollständige Kontrolle über das System erhält.
Wenn mehrere Anwendungen dieselbe Datenbank nutzen, benötigt jede Anwendung ein eigenes Datenbank-Benutzerkonto mit unterschiedlichen Zugriffsrechten. Auch dieser Ansatz trägt dazu bei, den durch potenzielle SQLis verursachten Schaden zu minimieren.
Alles in allem sollten Sie Ihre Zugriffsrichtlinien so granular wie möglich gestalten, um einen Schneeballeffekt zu vermeiden, wenn der Hacker über SQLi die Root-Rechte erlangt.
Vorgefertigte Anweisungen mit parametrisierten Abfragen verwenden
Laut OWASP ist die Verwendung von vorbereiteten Anweisungen mit parametrisierten Abfragen der wichtigste Schutz gegen SQLi. Vorbereitete Anweisungen sind deshalb so wirksam gegen SQLi, weil sie es der Datenbank leicht machen, eindeutig zwischen dem Code und der vom Benutzer eingegebenen Information zu unterscheiden.
Eine typische vorbereitete Anweisung folgt einem einfachen Algorithmus:
- eine SQL-Anweisungsvorlage wird erstellt und an die Datenbank gesendet
- Die SQL-Abfrage wird geparst und auf ihre Semantik hin überprüft.
- die SQL-Abfrage wird mit Platzhaltertext kompiliert (Bindung)
- die Platzhalter werden durch die vom Benutzer eingegebenen Daten ersetzt
- die Abfrage wird im Cache gespeichert
- die Datenbank führt die Anweisung aus
Wie aus diesen Schritten ersichtlich, können die vom Benutzer bereitgestellten Daten die Absicht einer Abfrage nicht beeinflussen, da sie vom ausführbaren Code getrennt sind und immer als einfache Zeichenfolge interpretiert werden.
Hier stellt sich eine weitere Frage: Wenn vorbereitete Anweisungen so sicher sind, warum haben wir dann immer noch so viele SQLi-Vorfälle? Das Problem ist, dass vorbereitete Anweisungen in bestimmten Fällen die Leistung der Anwendung beeinträchtigen können, weshalb sich die Entwickler dafür entscheiden, sie nicht zu verwenden und auf andere, weniger effektive Sicherheitstechniken zurückzugreifen.
Stored Procedures richtig implementieren
Eine gespeicherte Prozedur ist ein vorbereiteter SQL-Code, der gespeichert und in der Zukunft mehrfach verwendet werden kann. Der Unterschied zwischen einer gespeicherten Prozedur und einer vorbereiteten Anweisung besteht darin, dass der SQL-Code für erstere in der Datenbank selbst definiert und gespeichert ist: Wenn die Abfrage ausgeführt werden muss, wird sie einfach von der Anwendung aus aufgerufen.
Gespeicherte Prozeduren gelten als ebenso effektiv wie vorbereitete Anweisungen, sofern sie sicher implementiert sind. Andernfalls sind auch sie für SQLi anfällig.
Entwickler müssen darauf achten, kein unsicheres dynamisches SQL in die gespeicherte Prozedur aufzunehmen. Wenn die Erzeugung von dynamischem SQL innerhalb einer gespeicherten Prozedur unvermeidlich ist, empfehlen wir, die Abfragen innerhalb der gespeicherten Prozedur zu parametrisieren, anstatt die Parameter zu verketten.
Alle benutzerdefinierten Eingaben abbrechen
Dieser Ansatz ist ein ziemlich verzweifeltes Mittel: Er sollte nur verwendet werden, wenn nichts anderes machbar ist. Ein typischer Anwendungsfall wäre der Schutz von Legacy-Software und ein begrenztes Budget für eine vollwertige Eingabevalidierung.
Escape funktioniert folgendermaßen: Die Escape-Funktion kodiert Sonderzeichen wie “/”, “?”, “$”, damit die Datenbank die vom Benutzer eingegebenen Zeichen nicht mit dem Code des Entwicklers verwechseln kann.
Obwohl jedes DBMS sein eigenes Escape-Schema hat, ist der Zweck derselbe – zu verhindern, dass die vom Benutzer eingegebenen Zeichen als ausführbarer Befehl interpretiert werden.
Auch diese Technik kann keinen 100%igen Schutz gegen SQLi garantieren. Im Idealfall sollte die Anwendung unter Verwendung von parametrisierten Abfragen oder gespeicherten Prozeduren von Grund auf neu geschrieben werden.
Eine weitere Escape-Methode ist die Hex-Codierung aller vom Benutzer eingegebenen Daten. Dieses Szenario setzt voraus, dass nicht nur Sonderzeichen, sondern alle Zeichen der Eingabe verschlüsselt werden, bevor sie in die SQL-Abfrage aufgenommen werden.
Datenbankfehler verbergen
Was den Datenbankfehler verursacht hat, ist für den Entwickler sehr nützlich, aber nicht für den Endbenutzer. Es ist wichtig, dass die Fehlermeldungen keine sensiblen Informationen preisgeben, die ein Hacker nutzen könnte.
Anstatt beispielsweise die SQL-Anweisung anzuzeigen, aus der hervorgeht, wo genau der Fehler aufgetreten ist, sollten Sie allgemeine, kundenorientierte Popup-Fenster anzeigen, wie z. B. “Leider sind technische Probleme aufgetreten. Bitte versuchen Sie es später noch einmal”.
Sensible Daten verschlüsseln
Streng vertrauliche Daten im Klartext zu hinterlassen, ist nie eine gute Idee. Aus diesem Grund haben so viele Unternehmen, vor allem im Finanz-, Gesundheits- und Mediensektor, die Datenverschlüsselung in ihre Systeme integriert – die Kosten einer Datenpreisgabe sind einfach zu hoch (im Durchschnitt etwa 4 Mio. USD).
Ein weiterer wichtiger Faktor ist, dass Verschlüsselung allein kein Allheilmittel ist. Angenommen, ein Unternehmen hat ein Hashing-Verfahren für Passwörter eingeführt, d. h. die eigentlichen Passwörter werden nie gespeichert, sondern nur ihre gehashten Entsprechungen. Wenn sich die Benutzer jedoch nicht die Mühe gemacht haben, sichere Passwörter zu erstellen, was häufig der Fall ist, können ihre Anmeldedaten mit Hash- oder Rainbow-Tabellen, die Schlüssel auf Werte abbilden können, leicht kompromittiert werden.
Das Salzen der verschlüsselten Hashes würde eine zusätzliche Sicherheitsebene darstellen. Vereinfacht ausgedrückt bedeutet Salting, dass dem Kennwort vor dem Hashing ein zufälliges Datenelement hinzugefügt wird. Gesalzene Kennwörter verringern die Wahrscheinlichkeit, dass schwache Benutzerkennwörter in einer Hashtabelle gefunden werden.
Regelmäßige Code-Inspektion durchführen
SQLi ist oft das Ergebnis schlechter Softwareentwicklungspraktiken. Daher ist es nur vernünftig, den Präventionsplan am Quellcode anzusetzen, indem man Sicherheitsexperten von Drittanbietern eine unvoreingenommene Codeprüfung durchführen lässt.
Ebenso wichtig ist die Durchführung regelmäßiger Penetrationstests, um rote Fahnen zu erkennen und die von Scannern und Fuzzern übersehenen Schwachstellen zu entdecken. Für einen erfahrenen Penetrationstester ist die Entdeckung einer SQLi-Schwachstelle eine leichte Aufgabe; außerdem kann er die Folgen anderer potenzieller oder bestehender Angriffe erläutern und einen Plan zur Beseitigung von SQL-Injection anbieten, der dem Status quo des Unternehmens entspricht.
Resümee
SQL-Injection ist eine Sicherheitslücke, die so alt ist, dass es beschämend ist, dass sie immer noch eine Bedrohung für moderne Websites und Anwendungen darstellt. Sie ist aufgrund der relativ einfachen Implementierung, der weiten Verbreitung von SQL-DBMS und des immensen Werts der Geschäftsdaten sehr beliebt. Die gute Nachricht: Es ist vermeidbar. Alles, was Sie tun müssen, ist, Ihre technischen Bemühungen mit den neuesten Sicherheitspraktiken, kontinuierlicher Überwachung und Inspektion sowie unabhängigen SQL-Injection-Tests in Einklang zu bringen, um alle verbleibenden Lücken zu schließen.
Welche Erfahrungen haben Sie bei der Bekämpfung von SQLi gemacht? Bitte teilen Sie uns diese per E-Mail oder in den Kommentaren mit!