Coders Conquer Security: Share & Learn Series - NoSQL Injection

Veröffentlicht 20. Dez. 2018
von Jaap Karan Singh
FALLSTUDIE

Coders Conquer Security: Share & Learn Series - NoSQL Injection

Veröffentlicht 20. Dez. 2018
von Jaap Karan Singh
Ressource anzeigen
Ressource anzeigen

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!

Ressource anzeigen
Ressource anzeigen

Autor

Jaap Karan Singh

Sie wollen mehr?

Tauchen Sie ein in unsere neuesten Erkenntnisse über sichere Kodierung im Blog.

Unsere umfangreiche Ressourcenbibliothek zielt darauf ab, die menschliche Herangehensweise an eine sichere Weiterbildung im Bereich der Programmierung zu stärken.

Blog ansehen
Sie wollen mehr?

Holen Sie sich die neuesten Forschungsergebnisse zur entwicklergesteuerten Sicherheit

Unsere umfangreiche Ressourcenbibliothek ist voll von hilfreichen Ressourcen, von Whitepapers bis hin zu Webinaren, die Ihnen den Einstieg in die entwicklungsorientierte sichere Programmierung erleichtern. Erforschen Sie sie jetzt.

Ressourcendrehscheibe

Coders Conquer Security: Share & Learn Series - NoSQL Injection

Veröffentlicht 20. Dez. 2018
Von Jaap Karan Singh

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!

Wir bitten Sie um Ihre Erlaubnis, Ihnen Informationen über unsere Produkte und/oder verwandte Themen der sicheren Codierung zuzusenden. Wir werden Ihre persönlichen Daten immer mit äußerster Sorgfalt behandeln und sie niemals zu Marketingzwecken an andere Unternehmen verkaufen.

Um das Formular abzuschicken, aktivieren Sie bitte "Analytics"-Cookies. Sie können die Cookies wieder deaktivieren, sobald Sie fertig sind.