Coders Conquer Security: Share & Learn Series - NoSQL Injection
NoSQL-Datenbanken werden immer beliebter. Es ist schwer, ihre Geschwindigkeit und Leichtigkeit im Umgang mit unstrukturierten Daten zu verleugnen, besonders wenn Entwicklerteams mit zunehmend agilen Methoden arbeiten.
Es dauert seine Zeit, bis Entwickler Schwachstellen und andere Herausforderungen in neuen Technologien ausmerzen können. Erst nachdem sie eine Zeit lang in Produktionsanwendungen eingesetzt wurde, beginnen Probleme an die Oberfläche zu sprudeln.
NoSQL-Datenbanken sind ähnlich. Es gibt wichtige Risiken, die Entwickler kennen sollten, damit sie ihre Anwendungen sicher halten können. Ein solches Risiko ist NoSQL-Injection.
Lassen Sie uns einen Blick darauf werfen, was NoSQL-Injection ist, welchen Schaden sie verursachen kann und wie man sie behebt:
NoSQL-Injektion verstehen
NoSQL-Injection wird durch viele der gleichen Injektionsschwachstellen wie XML- oder SQL-Injection verursacht.
NoSQL-Injection erlaubt es Angreifern, beliebige Befehle in eine NoSQL-Abfrage zu platzieren. Dadurch können sie Daten stehlen und sogar Änderungen an der Datenbank vornehmen, wenn ihre Berechtigungen hoch genug sind.
Wenn eine Anwendung benutzergesteuerte Daten direkt in einen NoSQL-Abfrageausdruck setzt, nehmen diese Ausdrücke oft Funktionen an oder haben eingebaute Operatoren, die manipuliert werden können, um Daten zu stehlen oder zu verändern. Und wenn so etwas in böswilliger Absicht ausgeführt wird, kann das schlimme Folgen haben.
MongoDB-Datenbanken sind eine der beliebtesten Spielwiesen, um diese Sicherheitslücke auszunutzen. "$ne: ""'ist der Operator, der in der SQL-Welt 1=1 entspricht. Ein Angreifer könnte also beispielsweise die Zeichen "$ne: ""' in die Felder für den Benutzernamen und das Passwort einer Benutzeroberfläche eingeben. Wenn der Code anfällig für NoSQL-Injection ist, sucht die Datenbank nach allen Datensätzen, bei denen Benutzername und Passwort nicht gleich einem leeren String sind. Mit anderen Worten: alle. Igitt.
Wenn diese Datenbank unverschlüsselt ist, könnte der Angreifer die Benutzernamen und Kennwörter jedes einzelnen Benutzers darin stehlen. Dazu gehören auch die Benutzernamen und Passwörter der Administratoren, wodurch sie einen All-Access-Pass für die gesamte Datenbank erhalten.
Angreifer versuchen oft, Werte einzuschleusen, die immer wahr sind. Ein weiterer häufiger Angriff besteht darin, bösartigen Code in Eigenschaften zu injizieren, die auf Funktionen gesetzt sind.
MongoDB verwendet z. B. eine Find-Funktion, die ein Objekt mit einer Eigenschaft namens $where annimmt. Die Eigenschaft "$where" wird auf eine Funktion gesetzt, die als wahr oder falsch ausgewertet werden soll. Wenn diese Funktion in irgendeiner Weise durch Benutzereingaben geändert wird, lauert dort wahrscheinlich eine NoSQL-Injektion.
Für einen schön detaillierten Blick auf die Feinheiten der NoSQL-Injektion, schauen Sie sich diesen InfoQ-Artikel an.
Wissen, warum NoSQL Injection gefährlich ist
NoSQL-Injection ist vor allem deshalb so gefährlich, weil sie noch nicht die Aufmerksamkeit der Sicherheitsgemeinde erhalten hat, die sie verdient.
Die Auswirkungen von NoSQL-Injection sind ähnlich wie bei der traditionellen SQL-Injection. Daten können gestohlen oder geändert werden, Konten können durch Datendiebstahl kompromittiert werden und, vielleicht am bösartigsten, Daten können komplett gelöscht werden, wenn ein Löschbefehl erfolgreich erteilt wird.
Die Quintessenz ist, dass MongoDB und andere NoSQL-Datenbank-Engines anfällig für Angriffe sind. "Kein SQL" bedeutet nicht, dass es keine Injektionen gibt.
Glücklicherweise nehmen einige in der Community dies zur Kenntnis und sprechen es aus. Mehr Entwickler müssen sich selbst weiterbilden, damit sie ihre Anwendungen vor wenig bekannten Bösewichten schützen können, die zu großen Kopfschmerzen führen können, wenn sie ausgenutzt werden.
NoSQL-Injection besiegen
NoSQL-Injection kann schwer zu besiegen sein. Leider gibt es nicht die Möglichkeit von parametrisierten Abfragen wie bei SQL-Injection. Es ist jedoch nicht unmöglich. Es gibt ein paar Optionen, die Ihnen helfen können:
- Fuzzers können als eine Methode zum Aufspüren von Schwachstellen verwendet werden. Obwohl, wie es bei vielen Dingen im Leben der Fall ist, kann der einfachste Ansatz der effektivste sein. Hier ist das gute alte Code-Review Ihr stärkster Verbündeter.
- Suchen Sie bei der Überprüfung des Codes nach möglichen Stellen, an denen Benutzereingaben den Wert eines Ausdrucks setzen oder eine Funktion ändern könnten. Lassen Sie nicht zu, dass Benutzereingaben Ihre Abfragen ändern.
- Vergewissern Sie sich, dass die Benutzereingabe in ihre richtige Klasse umgewandelt wird. Wenn es eine Zahl ist, wandeln Sie sie in eine Zahl um, wenn es eine Zeichenkette ist, wandeln Sie sie in eine Zeichenkette um und so weiter.
- Verwenden Sie niemals $where oder ähnliche eval-Funktionen zusammen mit Benutzereingaben. In den meisten Fällen können Sie das Problem umgehen, indem Sie das Datenmodell oder Schema ändern.
- Versuchen Sie, Mongoose als Ihren MongoDB-Treiber zu verwenden. Mongoose ermöglicht es Ihnen, ein Schema für Ihre NoSQL-Datenbank zu definieren. Wenn Sie Mongoose mitteilen, dass Ihre Eingaben Zeichenketten sind, werden diese in Zeichenketten umgewandelt. Alle Objekte, die von einem Angreifer übergeben werden, werden also nicht als Objekte, sondern als Strings behandelt.
- Härten Sie Ihre DB! Legen Sie Benutzerkonten mit geringen Rechten an, maximieren Sie die Ausführungszeit für Abfragen und befolgen Sie stets die für Ihr Unternehmen geltenden bewährten Sicherheitsverfahren.
Ein Nachteil der Benutzerfreundlichkeit von NoSQL-Datenbanken ist die Tendenz von Entwicklern, sie einfach aufzustellen und zu benutzen, ohne an die Sicherheit zu denken.
Es ist wichtig, dass Sie sich die Zeit nehmen, um zu lernen, wie man eine NoSQL-Datenbank sicher aufbaut und sich vor NoSQL-Injections schützt.
Die MongoDB Enterprise Edition verfügt beispielsweise über erweiterte Funktionen zur Zugriffskontrolle. Die Durchsetzung von "Least Privilege" kann eine gute Defense in Depth (DiD)-Strategie sein, für den Fall, dass jemand eine Schwachstelle in Ihrer Anwendung findet.
Zusammenfassend lässt sich sagen, was wir haben:
- Bereinigen Sie Ihre Eingaben, bevor Sie sie in einem NoSQL-Abfrageausdruck verwenden
- Verwenden Sie Treiber, die Ihnen helfen, wie Mongoose
- Durchführung von Code-Reviews, die speziell die Verwendung von Eingabedaten in Abfragen untersuchen
- Verwenden Sie Fuzzers und Scanner, um Schwachstellen in Ihrem Code zu finden.
NoSQL ist nicht No Injections
NoSQL-Datenbanken erfreuen sich aufgrund ihrer skalierbaren Funktionen und der Geschwindigkeit der Einrichtung schnell wachsender Beliebtheit. Die Neuheit der Technologie kann Entwickler dazu verleiten, NoSQL-Datenbanken zu verwenden, ohne sich Gedanken über deren Absicherung zu machen.
NoSQL-Datenbanken können für Injection-Attacken genauso anfällig sein wie SQL-Datenbanken, also handeln Sie mit Vorsicht und achten Sie auf Ihre Abfragen. Wenn Sie mehr erfahren möchten, sehen Sie sich unsere Lernressourcen an oder testen Sie Ihre Kenntnisse mit unserer kostenlosen Demo.
Bereiten Sie sich im Voraus vor und Sie müssen sich keine Sorgen mehr über NoSQL-Injections in Ihren Anwendungen machen. Zu einfach!
Denken Sie, Sie sind bereit, NoSQL-Injektionen sofort zu lokalisieren, zu identifizieren und zu beheben? Betreten Sie die sichere Code-Arena, Krieger:
Und das ist ein Wrap für 2018! Dies wird unser letzter Beitrag für dieses Jahr sein, aber wir werden am 10. Januar 2019 mit dem nächsten Coders Conquer Security Guide zurück sein. Bis bald!
NoSQL-Datenbanken werden immer beliebter. Es ist schwer, ihre Geschwindigkeit und den einfachen Umgang mit unstrukturierten Daten zu leugnen, aber mit der zunehmenden Verbreitung kommen unweigerlich auch mehr Schwachstellen ans Tageslicht.
Jaap Karan Singh ist ein Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchen
Jaap Karan Singh ist ein Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.
NoSQL-Datenbanken werden immer beliebter. Es ist schwer, ihre Geschwindigkeit und Leichtigkeit im Umgang mit unstrukturierten Daten zu verleugnen, besonders wenn Entwicklerteams mit zunehmend agilen Methoden arbeiten.
Es dauert seine Zeit, bis Entwickler Schwachstellen und andere Herausforderungen in neuen Technologien ausmerzen können. Erst nachdem sie eine Zeit lang in Produktionsanwendungen eingesetzt wurde, beginnen Probleme an die Oberfläche zu sprudeln.
NoSQL-Datenbanken sind ähnlich. Es gibt wichtige Risiken, die Entwickler kennen sollten, damit sie ihre Anwendungen sicher halten können. Ein solches Risiko ist NoSQL-Injection.
Lassen Sie uns einen Blick darauf werfen, was NoSQL-Injection ist, welchen Schaden sie verursachen kann und wie man sie behebt:
NoSQL-Injektion verstehen
NoSQL-Injection wird durch viele der gleichen Injektionsschwachstellen wie XML- oder SQL-Injection verursacht.
NoSQL-Injection erlaubt es Angreifern, beliebige Befehle in eine NoSQL-Abfrage zu platzieren. Dadurch können sie Daten stehlen und sogar Änderungen an der Datenbank vornehmen, wenn ihre Berechtigungen hoch genug sind.
Wenn eine Anwendung benutzergesteuerte Daten direkt in einen NoSQL-Abfrageausdruck setzt, nehmen diese Ausdrücke oft Funktionen an oder haben eingebaute Operatoren, die manipuliert werden können, um Daten zu stehlen oder zu verändern. Und wenn so etwas in böswilliger Absicht ausgeführt wird, kann das schlimme Folgen haben.
MongoDB-Datenbanken sind eine der beliebtesten Spielwiesen, um diese Sicherheitslücke auszunutzen. "$ne: ""'ist der Operator, der in der SQL-Welt 1=1 entspricht. Ein Angreifer könnte also beispielsweise die Zeichen "$ne: ""' in die Felder für den Benutzernamen und das Passwort einer Benutzeroberfläche eingeben. Wenn der Code anfällig für NoSQL-Injection ist, sucht die Datenbank nach allen Datensätzen, bei denen Benutzername und Passwort nicht gleich einem leeren String sind. Mit anderen Worten: alle. Igitt.
Wenn diese Datenbank unverschlüsselt ist, könnte der Angreifer die Benutzernamen und Kennwörter jedes einzelnen Benutzers darin stehlen. Dazu gehören auch die Benutzernamen und Passwörter der Administratoren, wodurch sie einen All-Access-Pass für die gesamte Datenbank erhalten.
Angreifer versuchen oft, Werte einzuschleusen, die immer wahr sind. Ein weiterer häufiger Angriff besteht darin, bösartigen Code in Eigenschaften zu injizieren, die auf Funktionen gesetzt sind.
MongoDB verwendet z. B. eine Find-Funktion, die ein Objekt mit einer Eigenschaft namens $where annimmt. Die Eigenschaft "$where" wird auf eine Funktion gesetzt, die als wahr oder falsch ausgewertet werden soll. Wenn diese Funktion in irgendeiner Weise durch Benutzereingaben geändert wird, lauert dort wahrscheinlich eine NoSQL-Injektion.
Für einen schön detaillierten Blick auf die Feinheiten der NoSQL-Injektion, schauen Sie sich diesen InfoQ-Artikel an.
Wissen, warum NoSQL Injection gefährlich ist
NoSQL-Injection ist vor allem deshalb so gefährlich, weil sie noch nicht die Aufmerksamkeit der Sicherheitsgemeinde erhalten hat, die sie verdient.
Die Auswirkungen von NoSQL-Injection sind ähnlich wie bei der traditionellen SQL-Injection. Daten können gestohlen oder geändert werden, Konten können durch Datendiebstahl kompromittiert werden und, vielleicht am bösartigsten, Daten können komplett gelöscht werden, wenn ein Löschbefehl erfolgreich erteilt wird.
Die Quintessenz ist, dass MongoDB und andere NoSQL-Datenbank-Engines anfällig für Angriffe sind. "Kein SQL" bedeutet nicht, dass es keine Injektionen gibt.
Glücklicherweise nehmen einige in der Community dies zur Kenntnis und sprechen es aus. Mehr Entwickler müssen sich selbst weiterbilden, damit sie ihre Anwendungen vor wenig bekannten Bösewichten schützen können, die zu großen Kopfschmerzen führen können, wenn sie ausgenutzt werden.
NoSQL-Injection besiegen
NoSQL-Injection kann schwer zu besiegen sein. Leider gibt es nicht die Möglichkeit von parametrisierten Abfragen wie bei SQL-Injection. Es ist jedoch nicht unmöglich. Es gibt ein paar Optionen, die Ihnen helfen können:
- Fuzzers können als eine Methode zum Aufspüren von Schwachstellen verwendet werden. Obwohl, wie es bei vielen Dingen im Leben der Fall ist, kann der einfachste Ansatz der effektivste sein. Hier ist das gute alte Code-Review Ihr stärkster Verbündeter.
- Suchen Sie bei der Überprüfung des Codes nach möglichen Stellen, an denen Benutzereingaben den Wert eines Ausdrucks setzen oder eine Funktion ändern könnten. Lassen Sie nicht zu, dass Benutzereingaben Ihre Abfragen ändern.
- Vergewissern Sie sich, dass die Benutzereingabe in ihre richtige Klasse umgewandelt wird. Wenn es eine Zahl ist, wandeln Sie sie in eine Zahl um, wenn es eine Zeichenkette ist, wandeln Sie sie in eine Zeichenkette um und so weiter.
- Verwenden Sie niemals $where oder ähnliche eval-Funktionen zusammen mit Benutzereingaben. In den meisten Fällen können Sie das Problem umgehen, indem Sie das Datenmodell oder Schema ändern.
- Versuchen Sie, Mongoose als Ihren MongoDB-Treiber zu verwenden. Mongoose ermöglicht es Ihnen, ein Schema für Ihre NoSQL-Datenbank zu definieren. Wenn Sie Mongoose mitteilen, dass Ihre Eingaben Zeichenketten sind, werden diese in Zeichenketten umgewandelt. Alle Objekte, die von einem Angreifer übergeben werden, werden also nicht als Objekte, sondern als Strings behandelt.
- Härten Sie Ihre DB! Legen Sie Benutzerkonten mit geringen Rechten an, maximieren Sie die Ausführungszeit für Abfragen und befolgen Sie stets die für Ihr Unternehmen geltenden bewährten Sicherheitsverfahren.
Ein Nachteil der Benutzerfreundlichkeit von NoSQL-Datenbanken ist die Tendenz von Entwicklern, sie einfach aufzustellen und zu benutzen, ohne an die Sicherheit zu denken.
Es ist wichtig, dass Sie sich die Zeit nehmen, um zu lernen, wie man eine NoSQL-Datenbank sicher aufbaut und sich vor NoSQL-Injections schützt.
Die MongoDB Enterprise Edition verfügt beispielsweise über erweiterte Funktionen zur Zugriffskontrolle. Die Durchsetzung von "Least Privilege" kann eine gute Defense in Depth (DiD)-Strategie sein, für den Fall, dass jemand eine Schwachstelle in Ihrer Anwendung findet.
Zusammenfassend lässt sich sagen, was wir haben:
- Bereinigen Sie Ihre Eingaben, bevor Sie sie in einem NoSQL-Abfrageausdruck verwenden
- Verwenden Sie Treiber, die Ihnen helfen, wie Mongoose
- Durchführung von Code-Reviews, die speziell die Verwendung von Eingabedaten in Abfragen untersuchen
- Verwenden Sie Fuzzers und Scanner, um Schwachstellen in Ihrem Code zu finden.
NoSQL ist nicht No Injections
NoSQL-Datenbanken erfreuen sich aufgrund ihrer skalierbaren Funktionen und der Geschwindigkeit der Einrichtung schnell wachsender Beliebtheit. Die Neuheit der Technologie kann Entwickler dazu verleiten, NoSQL-Datenbanken zu verwenden, ohne sich Gedanken über deren Absicherung zu machen.
NoSQL-Datenbanken können für Injection-Attacken genauso anfällig sein wie SQL-Datenbanken, also handeln Sie mit Vorsicht und achten Sie auf Ihre Abfragen. Wenn Sie mehr erfahren möchten, sehen Sie sich unsere Lernressourcen an oder testen Sie Ihre Kenntnisse mit unserer kostenlosen Demo.
Bereiten Sie sich im Voraus vor und Sie müssen sich keine Sorgen mehr über NoSQL-Injections in Ihren Anwendungen machen. Zu einfach!
Denken Sie, Sie sind bereit, NoSQL-Injektionen sofort zu lokalisieren, zu identifizieren und zu beheben? Betreten Sie die sichere Code-Arena, Krieger:
Und das ist ein Wrap für 2018! Dies wird unser letzter Beitrag für dieses Jahr sein, aber wir werden am 10. Januar 2019 mit dem nächsten Coders Conquer Security Guide zurück sein. Bis bald!
NoSQL-Datenbanken werden immer beliebter. Es ist schwer, ihre Geschwindigkeit und Leichtigkeit im Umgang mit unstrukturierten Daten zu verleugnen, besonders wenn Entwicklerteams mit zunehmend agilen Methoden arbeiten.
Es dauert seine Zeit, bis Entwickler Schwachstellen und andere Herausforderungen in neuen Technologien ausmerzen können. Erst nachdem sie eine Zeit lang in Produktionsanwendungen eingesetzt wurde, beginnen Probleme an die Oberfläche zu sprudeln.
NoSQL-Datenbanken sind ähnlich. Es gibt wichtige Risiken, die Entwickler kennen sollten, damit sie ihre Anwendungen sicher halten können. Ein solches Risiko ist NoSQL-Injection.
Lassen Sie uns einen Blick darauf werfen, was NoSQL-Injection ist, welchen Schaden sie verursachen kann und wie man sie behebt:
NoSQL-Injektion verstehen
NoSQL-Injection wird durch viele der gleichen Injektionsschwachstellen wie XML- oder SQL-Injection verursacht.
NoSQL-Injection erlaubt es Angreifern, beliebige Befehle in eine NoSQL-Abfrage zu platzieren. Dadurch können sie Daten stehlen und sogar Änderungen an der Datenbank vornehmen, wenn ihre Berechtigungen hoch genug sind.
Wenn eine Anwendung benutzergesteuerte Daten direkt in einen NoSQL-Abfrageausdruck setzt, nehmen diese Ausdrücke oft Funktionen an oder haben eingebaute Operatoren, die manipuliert werden können, um Daten zu stehlen oder zu verändern. Und wenn so etwas in böswilliger Absicht ausgeführt wird, kann das schlimme Folgen haben.
MongoDB-Datenbanken sind eine der beliebtesten Spielwiesen, um diese Sicherheitslücke auszunutzen. "$ne: ""'ist der Operator, der in der SQL-Welt 1=1 entspricht. Ein Angreifer könnte also beispielsweise die Zeichen "$ne: ""' in die Felder für den Benutzernamen und das Passwort einer Benutzeroberfläche eingeben. Wenn der Code anfällig für NoSQL-Injection ist, sucht die Datenbank nach allen Datensätzen, bei denen Benutzername und Passwort nicht gleich einem leeren String sind. Mit anderen Worten: alle. Igitt.
Wenn diese Datenbank unverschlüsselt ist, könnte der Angreifer die Benutzernamen und Kennwörter jedes einzelnen Benutzers darin stehlen. Dazu gehören auch die Benutzernamen und Passwörter der Administratoren, wodurch sie einen All-Access-Pass für die gesamte Datenbank erhalten.
Angreifer versuchen oft, Werte einzuschleusen, die immer wahr sind. Ein weiterer häufiger Angriff besteht darin, bösartigen Code in Eigenschaften zu injizieren, die auf Funktionen gesetzt sind.
MongoDB verwendet z. B. eine Find-Funktion, die ein Objekt mit einer Eigenschaft namens $where annimmt. Die Eigenschaft "$where" wird auf eine Funktion gesetzt, die als wahr oder falsch ausgewertet werden soll. Wenn diese Funktion in irgendeiner Weise durch Benutzereingaben geändert wird, lauert dort wahrscheinlich eine NoSQL-Injektion.
Für einen schön detaillierten Blick auf die Feinheiten der NoSQL-Injektion, schauen Sie sich diesen InfoQ-Artikel an.
Wissen, warum NoSQL Injection gefährlich ist
NoSQL-Injection ist vor allem deshalb so gefährlich, weil sie noch nicht die Aufmerksamkeit der Sicherheitsgemeinde erhalten hat, die sie verdient.
Die Auswirkungen von NoSQL-Injection sind ähnlich wie bei der traditionellen SQL-Injection. Daten können gestohlen oder geändert werden, Konten können durch Datendiebstahl kompromittiert werden und, vielleicht am bösartigsten, Daten können komplett gelöscht werden, wenn ein Löschbefehl erfolgreich erteilt wird.
Die Quintessenz ist, dass MongoDB und andere NoSQL-Datenbank-Engines anfällig für Angriffe sind. "Kein SQL" bedeutet nicht, dass es keine Injektionen gibt.
Glücklicherweise nehmen einige in der Community dies zur Kenntnis und sprechen es aus. Mehr Entwickler müssen sich selbst weiterbilden, damit sie ihre Anwendungen vor wenig bekannten Bösewichten schützen können, die zu großen Kopfschmerzen führen können, wenn sie ausgenutzt werden.
NoSQL-Injection besiegen
NoSQL-Injection kann schwer zu besiegen sein. Leider gibt es nicht die Möglichkeit von parametrisierten Abfragen wie bei SQL-Injection. Es ist jedoch nicht unmöglich. Es gibt ein paar Optionen, die Ihnen helfen können:
- Fuzzers können als eine Methode zum Aufspüren von Schwachstellen verwendet werden. Obwohl, wie es bei vielen Dingen im Leben der Fall ist, kann der einfachste Ansatz der effektivste sein. Hier ist das gute alte Code-Review Ihr stärkster Verbündeter.
- Suchen Sie bei der Überprüfung des Codes nach möglichen Stellen, an denen Benutzereingaben den Wert eines Ausdrucks setzen oder eine Funktion ändern könnten. Lassen Sie nicht zu, dass Benutzereingaben Ihre Abfragen ändern.
- Vergewissern Sie sich, dass die Benutzereingabe in ihre richtige Klasse umgewandelt wird. Wenn es eine Zahl ist, wandeln Sie sie in eine Zahl um, wenn es eine Zeichenkette ist, wandeln Sie sie in eine Zeichenkette um und so weiter.
- Verwenden Sie niemals $where oder ähnliche eval-Funktionen zusammen mit Benutzereingaben. In den meisten Fällen können Sie das Problem umgehen, indem Sie das Datenmodell oder Schema ändern.
- Versuchen Sie, Mongoose als Ihren MongoDB-Treiber zu verwenden. Mongoose ermöglicht es Ihnen, ein Schema für Ihre NoSQL-Datenbank zu definieren. Wenn Sie Mongoose mitteilen, dass Ihre Eingaben Zeichenketten sind, werden diese in Zeichenketten umgewandelt. Alle Objekte, die von einem Angreifer übergeben werden, werden also nicht als Objekte, sondern als Strings behandelt.
- Härten Sie Ihre DB! Legen Sie Benutzerkonten mit geringen Rechten an, maximieren Sie die Ausführungszeit für Abfragen und befolgen Sie stets die für Ihr Unternehmen geltenden bewährten Sicherheitsverfahren.
Ein Nachteil der Benutzerfreundlichkeit von NoSQL-Datenbanken ist die Tendenz von Entwicklern, sie einfach aufzustellen und zu benutzen, ohne an die Sicherheit zu denken.
Es ist wichtig, dass Sie sich die Zeit nehmen, um zu lernen, wie man eine NoSQL-Datenbank sicher aufbaut und sich vor NoSQL-Injections schützt.
Die MongoDB Enterprise Edition verfügt beispielsweise über erweiterte Funktionen zur Zugriffskontrolle. Die Durchsetzung von "Least Privilege" kann eine gute Defense in Depth (DiD)-Strategie sein, für den Fall, dass jemand eine Schwachstelle in Ihrer Anwendung findet.
Zusammenfassend lässt sich sagen, was wir haben:
- Bereinigen Sie Ihre Eingaben, bevor Sie sie in einem NoSQL-Abfrageausdruck verwenden
- Verwenden Sie Treiber, die Ihnen helfen, wie Mongoose
- Durchführung von Code-Reviews, die speziell die Verwendung von Eingabedaten in Abfragen untersuchen
- Verwenden Sie Fuzzers und Scanner, um Schwachstellen in Ihrem Code zu finden.
NoSQL ist nicht No Injections
NoSQL-Datenbanken erfreuen sich aufgrund ihrer skalierbaren Funktionen und der Geschwindigkeit der Einrichtung schnell wachsender Beliebtheit. Die Neuheit der Technologie kann Entwickler dazu verleiten, NoSQL-Datenbanken zu verwenden, ohne sich Gedanken über deren Absicherung zu machen.
NoSQL-Datenbanken können für Injection-Attacken genauso anfällig sein wie SQL-Datenbanken, also handeln Sie mit Vorsicht und achten Sie auf Ihre Abfragen. Wenn Sie mehr erfahren möchten, sehen Sie sich unsere Lernressourcen an oder testen Sie Ihre Kenntnisse mit unserer kostenlosen Demo.
Bereiten Sie sich im Voraus vor und Sie müssen sich keine Sorgen mehr über NoSQL-Injections in Ihren Anwendungen machen. Zu einfach!
Denken Sie, Sie sind bereit, NoSQL-Injektionen sofort zu lokalisieren, zu identifizieren und zu beheben? Betreten Sie die sichere Code-Arena, Krieger:
Und das ist ein Wrap für 2018! Dies wird unser letzter Beitrag für dieses Jahr sein, aber wir werden am 10. Januar 2019 mit dem nächsten Coders Conquer Security Guide zurück sein. Bis bald!
Klicken Sie auf den unten stehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenDemo buchen
Jaap Karan Singh ist ein Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.
NoSQL-Datenbanken werden immer beliebter. Es ist schwer, ihre Geschwindigkeit und Leichtigkeit im Umgang mit unstrukturierten Daten zu verleugnen, besonders wenn Entwicklerteams mit zunehmend agilen Methoden arbeiten.
Es dauert seine Zeit, bis Entwickler Schwachstellen und andere Herausforderungen in neuen Technologien ausmerzen können. Erst nachdem sie eine Zeit lang in Produktionsanwendungen eingesetzt wurde, beginnen Probleme an die Oberfläche zu sprudeln.
NoSQL-Datenbanken sind ähnlich. Es gibt wichtige Risiken, die Entwickler kennen sollten, damit sie ihre Anwendungen sicher halten können. Ein solches Risiko ist NoSQL-Injection.
Lassen Sie uns einen Blick darauf werfen, was NoSQL-Injection ist, welchen Schaden sie verursachen kann und wie man sie behebt:
NoSQL-Injektion verstehen
NoSQL-Injection wird durch viele der gleichen Injektionsschwachstellen wie XML- oder SQL-Injection verursacht.
NoSQL-Injection erlaubt es Angreifern, beliebige Befehle in eine NoSQL-Abfrage zu platzieren. Dadurch können sie Daten stehlen und sogar Änderungen an der Datenbank vornehmen, wenn ihre Berechtigungen hoch genug sind.
Wenn eine Anwendung benutzergesteuerte Daten direkt in einen NoSQL-Abfrageausdruck setzt, nehmen diese Ausdrücke oft Funktionen an oder haben eingebaute Operatoren, die manipuliert werden können, um Daten zu stehlen oder zu verändern. Und wenn so etwas in böswilliger Absicht ausgeführt wird, kann das schlimme Folgen haben.
MongoDB-Datenbanken sind eine der beliebtesten Spielwiesen, um diese Sicherheitslücke auszunutzen. "$ne: ""'ist der Operator, der in der SQL-Welt 1=1 entspricht. Ein Angreifer könnte also beispielsweise die Zeichen "$ne: ""' in die Felder für den Benutzernamen und das Passwort einer Benutzeroberfläche eingeben. Wenn der Code anfällig für NoSQL-Injection ist, sucht die Datenbank nach allen Datensätzen, bei denen Benutzername und Passwort nicht gleich einem leeren String sind. Mit anderen Worten: alle. Igitt.
Wenn diese Datenbank unverschlüsselt ist, könnte der Angreifer die Benutzernamen und Kennwörter jedes einzelnen Benutzers darin stehlen. Dazu gehören auch die Benutzernamen und Passwörter der Administratoren, wodurch sie einen All-Access-Pass für die gesamte Datenbank erhalten.
Angreifer versuchen oft, Werte einzuschleusen, die immer wahr sind. Ein weiterer häufiger Angriff besteht darin, bösartigen Code in Eigenschaften zu injizieren, die auf Funktionen gesetzt sind.
MongoDB verwendet z. B. eine Find-Funktion, die ein Objekt mit einer Eigenschaft namens $where annimmt. Die Eigenschaft "$where" wird auf eine Funktion gesetzt, die als wahr oder falsch ausgewertet werden soll. Wenn diese Funktion in irgendeiner Weise durch Benutzereingaben geändert wird, lauert dort wahrscheinlich eine NoSQL-Injektion.
Für einen schön detaillierten Blick auf die Feinheiten der NoSQL-Injektion, schauen Sie sich diesen InfoQ-Artikel an.
Wissen, warum NoSQL Injection gefährlich ist
NoSQL-Injection ist vor allem deshalb so gefährlich, weil sie noch nicht die Aufmerksamkeit der Sicherheitsgemeinde erhalten hat, die sie verdient.
Die Auswirkungen von NoSQL-Injection sind ähnlich wie bei der traditionellen SQL-Injection. Daten können gestohlen oder geändert werden, Konten können durch Datendiebstahl kompromittiert werden und, vielleicht am bösartigsten, Daten können komplett gelöscht werden, wenn ein Löschbefehl erfolgreich erteilt wird.
Die Quintessenz ist, dass MongoDB und andere NoSQL-Datenbank-Engines anfällig für Angriffe sind. "Kein SQL" bedeutet nicht, dass es keine Injektionen gibt.
Glücklicherweise nehmen einige in der Community dies zur Kenntnis und sprechen es aus. Mehr Entwickler müssen sich selbst weiterbilden, damit sie ihre Anwendungen vor wenig bekannten Bösewichten schützen können, die zu großen Kopfschmerzen führen können, wenn sie ausgenutzt werden.
NoSQL-Injection besiegen
NoSQL-Injection kann schwer zu besiegen sein. Leider gibt es nicht die Möglichkeit von parametrisierten Abfragen wie bei SQL-Injection. Es ist jedoch nicht unmöglich. Es gibt ein paar Optionen, die Ihnen helfen können:
- Fuzzers können als eine Methode zum Aufspüren von Schwachstellen verwendet werden. Obwohl, wie es bei vielen Dingen im Leben der Fall ist, kann der einfachste Ansatz der effektivste sein. Hier ist das gute alte Code-Review Ihr stärkster Verbündeter.
- Suchen Sie bei der Überprüfung des Codes nach möglichen Stellen, an denen Benutzereingaben den Wert eines Ausdrucks setzen oder eine Funktion ändern könnten. Lassen Sie nicht zu, dass Benutzereingaben Ihre Abfragen ändern.
- Vergewissern Sie sich, dass die Benutzereingabe in ihre richtige Klasse umgewandelt wird. Wenn es eine Zahl ist, wandeln Sie sie in eine Zahl um, wenn es eine Zeichenkette ist, wandeln Sie sie in eine Zeichenkette um und so weiter.
- Verwenden Sie niemals $where oder ähnliche eval-Funktionen zusammen mit Benutzereingaben. In den meisten Fällen können Sie das Problem umgehen, indem Sie das Datenmodell oder Schema ändern.
- Versuchen Sie, Mongoose als Ihren MongoDB-Treiber zu verwenden. Mongoose ermöglicht es Ihnen, ein Schema für Ihre NoSQL-Datenbank zu definieren. Wenn Sie Mongoose mitteilen, dass Ihre Eingaben Zeichenketten sind, werden diese in Zeichenketten umgewandelt. Alle Objekte, die von einem Angreifer übergeben werden, werden also nicht als Objekte, sondern als Strings behandelt.
- Härten Sie Ihre DB! Legen Sie Benutzerkonten mit geringen Rechten an, maximieren Sie die Ausführungszeit für Abfragen und befolgen Sie stets die für Ihr Unternehmen geltenden bewährten Sicherheitsverfahren.
Ein Nachteil der Benutzerfreundlichkeit von NoSQL-Datenbanken ist die Tendenz von Entwicklern, sie einfach aufzustellen und zu benutzen, ohne an die Sicherheit zu denken.
Es ist wichtig, dass Sie sich die Zeit nehmen, um zu lernen, wie man eine NoSQL-Datenbank sicher aufbaut und sich vor NoSQL-Injections schützt.
Die MongoDB Enterprise Edition verfügt beispielsweise über erweiterte Funktionen zur Zugriffskontrolle. Die Durchsetzung von "Least Privilege" kann eine gute Defense in Depth (DiD)-Strategie sein, für den Fall, dass jemand eine Schwachstelle in Ihrer Anwendung findet.
Zusammenfassend lässt sich sagen, was wir haben:
- Bereinigen Sie Ihre Eingaben, bevor Sie sie in einem NoSQL-Abfrageausdruck verwenden
- Verwenden Sie Treiber, die Ihnen helfen, wie Mongoose
- Durchführung von Code-Reviews, die speziell die Verwendung von Eingabedaten in Abfragen untersuchen
- Verwenden Sie Fuzzers und Scanner, um Schwachstellen in Ihrem Code zu finden.
NoSQL ist nicht No Injections
NoSQL-Datenbanken erfreuen sich aufgrund ihrer skalierbaren Funktionen und der Geschwindigkeit der Einrichtung schnell wachsender Beliebtheit. Die Neuheit der Technologie kann Entwickler dazu verleiten, NoSQL-Datenbanken zu verwenden, ohne sich Gedanken über deren Absicherung zu machen.
NoSQL-Datenbanken können für Injection-Attacken genauso anfällig sein wie SQL-Datenbanken, also handeln Sie mit Vorsicht und achten Sie auf Ihre Abfragen. Wenn Sie mehr erfahren möchten, sehen Sie sich unsere Lernressourcen an oder testen Sie Ihre Kenntnisse mit unserer kostenlosen Demo.
Bereiten Sie sich im Voraus vor und Sie müssen sich keine Sorgen mehr über NoSQL-Injections in Ihren Anwendungen machen. Zu einfach!
Denken Sie, Sie sind bereit, NoSQL-Injektionen sofort zu lokalisieren, zu identifizieren und zu beheben? Betreten Sie die sichere Code-Arena, Krieger:
Und das ist ein Wrap für 2018! Dies wird unser letzter Beitrag für dieses Jahr sein, aber wir werden am 10. Januar 2019 mit dem nächsten Coders Conquer Security Guide zurück sein. Bis bald!
Inhaltsübersicht
Jaap Karan Singh ist ein Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen für den Einstieg
Benchmarking von Sicherheitskompetenzen: Optimierung von Secure-by-Design im Unternehmen
Die Secure-by-Design-Bewegung ist die Zukunft der sicheren Softwareentwicklung. Erfahren Sie mehr über die wichtigsten Elemente, die Unternehmen berücksichtigen müssen, wenn sie über eine Secure-by-Design-Initiative nachdenken.
DigitalOcean verringert Sicherheitsverschuldung mit Secure Code Warrior
DigitalOceans Einsatz von Secure Code Warrior hat die Sicherheitsverschuldung deutlich reduziert, so dass sich die Teams stärker auf Innovation und Produktivität konzentrieren können. Die verbesserte Sicherheit hat die Produktqualität und den Wettbewerbsvorteil des Unternehmens gestärkt. Mit Blick auf die Zukunft wird der SCW Trust Score dem Unternehmen helfen, seine Sicherheitspraktiken weiter zu verbessern und Innovationen voranzutreiben.
Ressourcen für den Einstieg
Reaktive versus präventive Sicherheit: Prävention ist das bessere Heilmittel
Der Gedanke, Legacy-Code und -Systeme zur gleichen Zeit wie neuere Anwendungen mit präventiver Sicherheit auszustatten, kann entmutigend erscheinen, aber ein Secure-by-Design-Ansatz, der durch die Weiterbildung von Entwicklern durchgesetzt wird, kann die besten Sicherheitsverfahren auf diese Systeme anwenden. Dies ist für viele Unternehmen die beste Chance, ihre Sicherheitslage zu verbessern.
.png)
Die Vorteile eines Benchmarking der Sicherheitskompetenzen von Entwicklern
Der zunehmende Fokus auf sicheren Code und Secure-by-Design-Prinzipien erfordert, dass Entwickler von Beginn des SDLC an in Cybersicherheit geschult werden, wobei Tools wie Secure Code Warrior's Trust Score dabei helfen, ihre Fortschritte zu messen und zu verbessern.
Wesentlicher Erfolg für Enterprise Secure-by-Design-Initiativen
Unser jüngstes Forschungspapier „Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise“ ist das Ergebnis einer umfassenden Analyse echter Secure-by-Design-Initiativen auf Unternehmensebene und der Ableitung von Best-Practice-Ansätzen auf Grundlage datengesteuerter Erkenntnisse.
Vertiefung: Navigieren durch die kritische CUPS-Schwachstelle in GNU-Linux-Systemen
Entdecken Sie die neuesten Sicherheitsprobleme, mit denen Linux-Benutzer konfrontiert sind, indem wir die jüngsten hochgradigen Sicherheitslücken im Common UNIX Printing System (CUPS) untersuchen. Erfahren Sie, wie diese Probleme zu einer möglichen Remote Code Execution (RCE) führen können und was Sie tun können, um Ihre Systeme zu schützen.
