Coders Conquer Security OWASP Top 10 API Series - Fehlende Zugriffskontrolle auf Funktionsebene
Diese Blogserie konzentriert sich auf einige der schlimmsten Schwachstellen im Zusammenhang mit Application Programming Interfaces (APIs). Diese sind so schlimm, dass sie es in die Liste der Top-API-Schwachstellen des Open Web Application Security Project(OWASP) geschafft haben. Wenn man bedenkt, wie wichtig APIs für moderne Computerinfrastrukturen sind, sind dies kritische Probleme, die Sie um jeden Preis aus Ihren Anwendungen und Programmen heraushalten müssen.
Die fehlende Zugriffskontrolle auf Funktionsebene ermöglicht es Benutzern, Funktionen auszuführen, die eingeschränkt werden sollten, oder auf Ressourcen zuzugreifen, die geschützt werden sollten. Normalerweise werden Funktionen und Ressourcen direkt im Code oder durch Konfigurationseinstellungen geschützt, aber es ist nicht immer einfach, dies korrekt zu tun. Die Implementierung geeigneter Kontrollen kann schwierig sein, da moderne Anwendungen oft viele Arten von Rollen und Gruppen sowie eine komplexe Benutzerhierarchie enthalten.
Aber warum machen Sie nicht erst einmal mit und spielen unsere spielerische Herausforderung, um zu sehen, wie weit Sie mit der Navigation in dieser kniffligen Fehlerklasse sind?
Lassen Sie uns einen genaueren Blick darauf werfen:
APIs sind besonders anfällig für diesen Fehler, da sie stark strukturiert sind. Angreifer, die den Code verstehen, können fundierte Vermutungen darüber anstellen, wie sie Befehle implementieren, die auf sie beschränkt sein sollten. Das ist einer der Hauptgründe, warum es die Schwachstelle für die Zugriffskontrolle auf Funktions-/Ressourcenebene in die OWASP-Top Ten geschafft hat.
Wie können Angreifer die Schwachstelle in der Zugriffskontrolle auf Funktionsebene ausnutzen?
Angreifer, die vermuten, dass Funktionen oder Ressourcen nicht richtig geschützt sind, müssen sich zunächst Zugang zu dem System verschaffen, das sie angreifen wollen. Um diese Schwachstelle auszunutzen, müssen sie die Erlaubnis haben, legitime API-Aufrufe an den Endpunkt zu senden. Vielleicht gibt es eine Low-Level-Gastzugriffsfunktion oder eine Möglichkeit, sich als Teil der Funktion der Anwendung anonym anzumelden. Sobald dieser Zugriff hergestellt ist, können sie beginnen, Befehle in ihren legitimen API-Aufrufen zu ändern. Sie könnten z. B. GET mit PUT austauschen oder die Zeichenfolge USERS in der URL in ADMINS ändern. Da APIs strukturiert sind, ist es leicht zu erraten, welche Befehle erlaubt sind und wo sie in der Zeichenfolge eingefügt werden müssen.
OWASP nennt als Beispiel für diese Schwachstelle einen Registrierungsprozess, der eingerichtet wurde, um neuen Benutzern die Teilnahme an einer Website zu ermöglichen. Wahrscheinlich würde er einen API-GET-Aufruf wie den folgenden verwenden:
GET /api/invites/{invite_guid}
Der böswillige Benutzer würde ein JSON mit Details über die Einladung zurückbekommen, einschließlich der Rolle des Benutzers und seiner E-Mail. Er könnte dann GET in POST ändern und außerdem seine Einladung mit dem folgenden API-Aufruf von einem Benutzer zu einem Administrator erheben:
POST /api/invites/new
{"email":"shadyguy@targetedsystem.com","role":"admin"}
Nur Admins sollten in der Lage sein, POST-Befehle zu senden, aber wenn sie nicht richtig abgesichert sind, akzeptiert die API sie als legitim und führt aus, was der Angreifer will. In diesem Fall würde der böswillige Benutzer eingeladen werden, dem System als neuer Administrator beizutreten. Danach könnte er alles sehen und tun, was ein legitimer Administrator auch könnte, was nicht gut wäre.
Beseitigung der Schwachstelle der Zugriffskontrolle auf Funktionsebene
Das Verhindern dieser API-Schwachstelle ist besonders wichtig, weil es für einen Angreifer nicht schwierig ist, Funktionen zu finden, die innerhalb einer strukturierten API ungeschützt sind. Solange sie in irgendeiner Form Zugriff auf eine API erhalten, können sie beginnen, die Struktur des Codes abzubilden und Aufrufe zu erstellen, die schließlich verfolgt werden.
Daher müssen alle Funktionen auf Geschäftsebene mit einer rollenbasierten Autorisierungsmethode geschützt werden. Die meisten Frameworks bieten zentrale Routinen, um dies zu ermöglichen. Wenn das von Ihnen gewählte Framework dies nicht tut oder die vorhandene Routine schwierig zu implementieren ist, gibt es viele externe Module, die speziell für die einfache Verwendung entwickelt wurden. Für welche Methode Sie sich auch immer entscheiden, stellen Sie sicher, dass Sie die Autorisierung auf dem Server implementieren. Versuchen Sie niemals, Funktionen von der Client-Seite aus zu sichern.
Denken Sie bei der Erstellung von Berechtigungen auf Funktions- und Ressourcenebene daran, dass Benutzer nur die Berechtigung erhalten sollten, das zu tun, was sie brauchen, und nicht mehr. Wie immer bei der Programmierung von APIs oder anderen Dingen sollten Sie die Methode der geringsten Privilegien anwenden. Dies wird Ihre Umgebung absichern und eine Menge Probleme im Zusammenhang mit der Cybersicherheit verhindern.
Schauen Sie sich die Secure Code Warrior Blog-Seiten, um mehr über diese Schwachstelle zu erfahren und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Kenntnisse zu schärfen und auf dem neuesten Stand zu halten.
Die fehlende Zugriffskontrolle auf Funktionsebene ermöglicht es Benutzern, Funktionen auszuführen, die eingeschränkt werden sollten, oder lässt sie auf Ressourcen zugreifen, die geschützt werden sollten.
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
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 buchenMatias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.
Diese Blogserie konzentriert sich auf einige der schlimmsten Schwachstellen im Zusammenhang mit Application Programming Interfaces (APIs). Diese sind so schlimm, dass sie es in die Liste der Top-API-Schwachstellen des Open Web Application Security Project(OWASP) geschafft haben. Wenn man bedenkt, wie wichtig APIs für moderne Computerinfrastrukturen sind, sind dies kritische Probleme, die Sie um jeden Preis aus Ihren Anwendungen und Programmen heraushalten müssen.
Die fehlende Zugriffskontrolle auf Funktionsebene ermöglicht es Benutzern, Funktionen auszuführen, die eingeschränkt werden sollten, oder auf Ressourcen zuzugreifen, die geschützt werden sollten. Normalerweise werden Funktionen und Ressourcen direkt im Code oder durch Konfigurationseinstellungen geschützt, aber es ist nicht immer einfach, dies korrekt zu tun. Die Implementierung geeigneter Kontrollen kann schwierig sein, da moderne Anwendungen oft viele Arten von Rollen und Gruppen sowie eine komplexe Benutzerhierarchie enthalten.
Aber warum machen Sie nicht erst einmal mit und spielen unsere spielerische Herausforderung, um zu sehen, wie weit Sie mit der Navigation in dieser kniffligen Fehlerklasse sind?
Lassen Sie uns einen genaueren Blick darauf werfen:
APIs sind besonders anfällig für diesen Fehler, da sie stark strukturiert sind. Angreifer, die den Code verstehen, können fundierte Vermutungen darüber anstellen, wie sie Befehle implementieren, die auf sie beschränkt sein sollten. Das ist einer der Hauptgründe, warum es die Schwachstelle für die Zugriffskontrolle auf Funktions-/Ressourcenebene in die OWASP-Top Ten geschafft hat.
Wie können Angreifer die Schwachstelle in der Zugriffskontrolle auf Funktionsebene ausnutzen?
Angreifer, die vermuten, dass Funktionen oder Ressourcen nicht richtig geschützt sind, müssen sich zunächst Zugang zu dem System verschaffen, das sie angreifen wollen. Um diese Schwachstelle auszunutzen, müssen sie die Erlaubnis haben, legitime API-Aufrufe an den Endpunkt zu senden. Vielleicht gibt es eine Low-Level-Gastzugriffsfunktion oder eine Möglichkeit, sich als Teil der Funktion der Anwendung anonym anzumelden. Sobald dieser Zugriff hergestellt ist, können sie beginnen, Befehle in ihren legitimen API-Aufrufen zu ändern. Sie könnten z. B. GET mit PUT austauschen oder die Zeichenfolge USERS in der URL in ADMINS ändern. Da APIs strukturiert sind, ist es leicht zu erraten, welche Befehle erlaubt sind und wo sie in der Zeichenfolge eingefügt werden müssen.
OWASP nennt als Beispiel für diese Schwachstelle einen Registrierungsprozess, der eingerichtet wurde, um neuen Benutzern die Teilnahme an einer Website zu ermöglichen. Wahrscheinlich würde er einen API-GET-Aufruf wie den folgenden verwenden:
GET /api/invites/{invite_guid}
Der böswillige Benutzer würde ein JSON mit Details über die Einladung zurückbekommen, einschließlich der Rolle des Benutzers und seiner E-Mail. Er könnte dann GET in POST ändern und außerdem seine Einladung mit dem folgenden API-Aufruf von einem Benutzer zu einem Administrator erheben:
POST /api/invites/new
{"email":"shadyguy@targetedsystem.com","role":"admin"}
Nur Admins sollten in der Lage sein, POST-Befehle zu senden, aber wenn sie nicht richtig abgesichert sind, akzeptiert die API sie als legitim und führt aus, was der Angreifer will. In diesem Fall würde der böswillige Benutzer eingeladen werden, dem System als neuer Administrator beizutreten. Danach könnte er alles sehen und tun, was ein legitimer Administrator auch könnte, was nicht gut wäre.
Beseitigung der Schwachstelle der Zugriffskontrolle auf Funktionsebene
Das Verhindern dieser API-Schwachstelle ist besonders wichtig, weil es für einen Angreifer nicht schwierig ist, Funktionen zu finden, die innerhalb einer strukturierten API ungeschützt sind. Solange sie in irgendeiner Form Zugriff auf eine API erhalten, können sie beginnen, die Struktur des Codes abzubilden und Aufrufe zu erstellen, die schließlich verfolgt werden.
Daher müssen alle Funktionen auf Geschäftsebene mit einer rollenbasierten Autorisierungsmethode geschützt werden. Die meisten Frameworks bieten zentrale Routinen, um dies zu ermöglichen. Wenn das von Ihnen gewählte Framework dies nicht tut oder die vorhandene Routine schwierig zu implementieren ist, gibt es viele externe Module, die speziell für die einfache Verwendung entwickelt wurden. Für welche Methode Sie sich auch immer entscheiden, stellen Sie sicher, dass Sie die Autorisierung auf dem Server implementieren. Versuchen Sie niemals, Funktionen von der Client-Seite aus zu sichern.
Denken Sie bei der Erstellung von Berechtigungen auf Funktions- und Ressourcenebene daran, dass Benutzer nur die Berechtigung erhalten sollten, das zu tun, was sie brauchen, und nicht mehr. Wie immer bei der Programmierung von APIs oder anderen Dingen sollten Sie die Methode der geringsten Privilegien anwenden. Dies wird Ihre Umgebung absichern und eine Menge Probleme im Zusammenhang mit der Cybersicherheit verhindern.
Schauen Sie sich die Secure Code Warrior Blog-Seiten, um mehr über diese Schwachstelle zu erfahren und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Kenntnisse zu schärfen und auf dem neuesten Stand zu halten.
Diese Blogserie konzentriert sich auf einige der schlimmsten Schwachstellen im Zusammenhang mit Application Programming Interfaces (APIs). Diese sind so schlimm, dass sie es in die Liste der Top-API-Schwachstellen des Open Web Application Security Project(OWASP) geschafft haben. Wenn man bedenkt, wie wichtig APIs für moderne Computerinfrastrukturen sind, sind dies kritische Probleme, die Sie um jeden Preis aus Ihren Anwendungen und Programmen heraushalten müssen.
Die fehlende Zugriffskontrolle auf Funktionsebene ermöglicht es Benutzern, Funktionen auszuführen, die eingeschränkt werden sollten, oder auf Ressourcen zuzugreifen, die geschützt werden sollten. Normalerweise werden Funktionen und Ressourcen direkt im Code oder durch Konfigurationseinstellungen geschützt, aber es ist nicht immer einfach, dies korrekt zu tun. Die Implementierung geeigneter Kontrollen kann schwierig sein, da moderne Anwendungen oft viele Arten von Rollen und Gruppen sowie eine komplexe Benutzerhierarchie enthalten.
Aber warum machen Sie nicht erst einmal mit und spielen unsere spielerische Herausforderung, um zu sehen, wie weit Sie mit der Navigation in dieser kniffligen Fehlerklasse sind?
Lassen Sie uns einen genaueren Blick darauf werfen:
APIs sind besonders anfällig für diesen Fehler, da sie stark strukturiert sind. Angreifer, die den Code verstehen, können fundierte Vermutungen darüber anstellen, wie sie Befehle implementieren, die auf sie beschränkt sein sollten. Das ist einer der Hauptgründe, warum es die Schwachstelle für die Zugriffskontrolle auf Funktions-/Ressourcenebene in die OWASP-Top Ten geschafft hat.
Wie können Angreifer die Schwachstelle in der Zugriffskontrolle auf Funktionsebene ausnutzen?
Angreifer, die vermuten, dass Funktionen oder Ressourcen nicht richtig geschützt sind, müssen sich zunächst Zugang zu dem System verschaffen, das sie angreifen wollen. Um diese Schwachstelle auszunutzen, müssen sie die Erlaubnis haben, legitime API-Aufrufe an den Endpunkt zu senden. Vielleicht gibt es eine Low-Level-Gastzugriffsfunktion oder eine Möglichkeit, sich als Teil der Funktion der Anwendung anonym anzumelden. Sobald dieser Zugriff hergestellt ist, können sie beginnen, Befehle in ihren legitimen API-Aufrufen zu ändern. Sie könnten z. B. GET mit PUT austauschen oder die Zeichenfolge USERS in der URL in ADMINS ändern. Da APIs strukturiert sind, ist es leicht zu erraten, welche Befehle erlaubt sind und wo sie in der Zeichenfolge eingefügt werden müssen.
OWASP nennt als Beispiel für diese Schwachstelle einen Registrierungsprozess, der eingerichtet wurde, um neuen Benutzern die Teilnahme an einer Website zu ermöglichen. Wahrscheinlich würde er einen API-GET-Aufruf wie den folgenden verwenden:
GET /api/invites/{invite_guid}
Der böswillige Benutzer würde ein JSON mit Details über die Einladung zurückbekommen, einschließlich der Rolle des Benutzers und seiner E-Mail. Er könnte dann GET in POST ändern und außerdem seine Einladung mit dem folgenden API-Aufruf von einem Benutzer zu einem Administrator erheben:
POST /api/invites/new
{"email":"shadyguy@targetedsystem.com","role":"admin"}
Nur Admins sollten in der Lage sein, POST-Befehle zu senden, aber wenn sie nicht richtig abgesichert sind, akzeptiert die API sie als legitim und führt aus, was der Angreifer will. In diesem Fall würde der böswillige Benutzer eingeladen werden, dem System als neuer Administrator beizutreten. Danach könnte er alles sehen und tun, was ein legitimer Administrator auch könnte, was nicht gut wäre.
Beseitigung der Schwachstelle der Zugriffskontrolle auf Funktionsebene
Das Verhindern dieser API-Schwachstelle ist besonders wichtig, weil es für einen Angreifer nicht schwierig ist, Funktionen zu finden, die innerhalb einer strukturierten API ungeschützt sind. Solange sie in irgendeiner Form Zugriff auf eine API erhalten, können sie beginnen, die Struktur des Codes abzubilden und Aufrufe zu erstellen, die schließlich verfolgt werden.
Daher müssen alle Funktionen auf Geschäftsebene mit einer rollenbasierten Autorisierungsmethode geschützt werden. Die meisten Frameworks bieten zentrale Routinen, um dies zu ermöglichen. Wenn das von Ihnen gewählte Framework dies nicht tut oder die vorhandene Routine schwierig zu implementieren ist, gibt es viele externe Module, die speziell für die einfache Verwendung entwickelt wurden. Für welche Methode Sie sich auch immer entscheiden, stellen Sie sicher, dass Sie die Autorisierung auf dem Server implementieren. Versuchen Sie niemals, Funktionen von der Client-Seite aus zu sichern.
Denken Sie bei der Erstellung von Berechtigungen auf Funktions- und Ressourcenebene daran, dass Benutzer nur die Berechtigung erhalten sollten, das zu tun, was sie brauchen, und nicht mehr. Wie immer bei der Programmierung von APIs oder anderen Dingen sollten Sie die Methode der geringsten Privilegien anwenden. Dies wird Ihre Umgebung absichern und eine Menge Probleme im Zusammenhang mit der Cybersicherheit verhindern.
Schauen Sie sich die Secure Code Warrior Blog-Seiten, um mehr über diese Schwachstelle zu erfahren und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Kenntnisse zu schärfen und auf dem neuesten Stand zu halten.
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 buchenMatias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.
Diese Blogserie konzentriert sich auf einige der schlimmsten Schwachstellen im Zusammenhang mit Application Programming Interfaces (APIs). Diese sind so schlimm, dass sie es in die Liste der Top-API-Schwachstellen des Open Web Application Security Project(OWASP) geschafft haben. Wenn man bedenkt, wie wichtig APIs für moderne Computerinfrastrukturen sind, sind dies kritische Probleme, die Sie um jeden Preis aus Ihren Anwendungen und Programmen heraushalten müssen.
Die fehlende Zugriffskontrolle auf Funktionsebene ermöglicht es Benutzern, Funktionen auszuführen, die eingeschränkt werden sollten, oder auf Ressourcen zuzugreifen, die geschützt werden sollten. Normalerweise werden Funktionen und Ressourcen direkt im Code oder durch Konfigurationseinstellungen geschützt, aber es ist nicht immer einfach, dies korrekt zu tun. Die Implementierung geeigneter Kontrollen kann schwierig sein, da moderne Anwendungen oft viele Arten von Rollen und Gruppen sowie eine komplexe Benutzerhierarchie enthalten.
Aber warum machen Sie nicht erst einmal mit und spielen unsere spielerische Herausforderung, um zu sehen, wie weit Sie mit der Navigation in dieser kniffligen Fehlerklasse sind?
Lassen Sie uns einen genaueren Blick darauf werfen:
APIs sind besonders anfällig für diesen Fehler, da sie stark strukturiert sind. Angreifer, die den Code verstehen, können fundierte Vermutungen darüber anstellen, wie sie Befehle implementieren, die auf sie beschränkt sein sollten. Das ist einer der Hauptgründe, warum es die Schwachstelle für die Zugriffskontrolle auf Funktions-/Ressourcenebene in die OWASP-Top Ten geschafft hat.
Wie können Angreifer die Schwachstelle in der Zugriffskontrolle auf Funktionsebene ausnutzen?
Angreifer, die vermuten, dass Funktionen oder Ressourcen nicht richtig geschützt sind, müssen sich zunächst Zugang zu dem System verschaffen, das sie angreifen wollen. Um diese Schwachstelle auszunutzen, müssen sie die Erlaubnis haben, legitime API-Aufrufe an den Endpunkt zu senden. Vielleicht gibt es eine Low-Level-Gastzugriffsfunktion oder eine Möglichkeit, sich als Teil der Funktion der Anwendung anonym anzumelden. Sobald dieser Zugriff hergestellt ist, können sie beginnen, Befehle in ihren legitimen API-Aufrufen zu ändern. Sie könnten z. B. GET mit PUT austauschen oder die Zeichenfolge USERS in der URL in ADMINS ändern. Da APIs strukturiert sind, ist es leicht zu erraten, welche Befehle erlaubt sind und wo sie in der Zeichenfolge eingefügt werden müssen.
OWASP nennt als Beispiel für diese Schwachstelle einen Registrierungsprozess, der eingerichtet wurde, um neuen Benutzern die Teilnahme an einer Website zu ermöglichen. Wahrscheinlich würde er einen API-GET-Aufruf wie den folgenden verwenden:
GET /api/invites/{invite_guid}
Der böswillige Benutzer würde ein JSON mit Details über die Einladung zurückbekommen, einschließlich der Rolle des Benutzers und seiner E-Mail. Er könnte dann GET in POST ändern und außerdem seine Einladung mit dem folgenden API-Aufruf von einem Benutzer zu einem Administrator erheben:
POST /api/invites/new
{"email":"shadyguy@targetedsystem.com","role":"admin"}
Nur Admins sollten in der Lage sein, POST-Befehle zu senden, aber wenn sie nicht richtig abgesichert sind, akzeptiert die API sie als legitim und führt aus, was der Angreifer will. In diesem Fall würde der böswillige Benutzer eingeladen werden, dem System als neuer Administrator beizutreten. Danach könnte er alles sehen und tun, was ein legitimer Administrator auch könnte, was nicht gut wäre.
Beseitigung der Schwachstelle der Zugriffskontrolle auf Funktionsebene
Das Verhindern dieser API-Schwachstelle ist besonders wichtig, weil es für einen Angreifer nicht schwierig ist, Funktionen zu finden, die innerhalb einer strukturierten API ungeschützt sind. Solange sie in irgendeiner Form Zugriff auf eine API erhalten, können sie beginnen, die Struktur des Codes abzubilden und Aufrufe zu erstellen, die schließlich verfolgt werden.
Daher müssen alle Funktionen auf Geschäftsebene mit einer rollenbasierten Autorisierungsmethode geschützt werden. Die meisten Frameworks bieten zentrale Routinen, um dies zu ermöglichen. Wenn das von Ihnen gewählte Framework dies nicht tut oder die vorhandene Routine schwierig zu implementieren ist, gibt es viele externe Module, die speziell für die einfache Verwendung entwickelt wurden. Für welche Methode Sie sich auch immer entscheiden, stellen Sie sicher, dass Sie die Autorisierung auf dem Server implementieren. Versuchen Sie niemals, Funktionen von der Client-Seite aus zu sichern.
Denken Sie bei der Erstellung von Berechtigungen auf Funktions- und Ressourcenebene daran, dass Benutzer nur die Berechtigung erhalten sollten, das zu tun, was sie brauchen, und nicht mehr. Wie immer bei der Programmierung von APIs oder anderen Dingen sollten Sie die Methode der geringsten Privilegien anwenden. Dies wird Ihre Umgebung absichern und eine Menge Probleme im Zusammenhang mit der Cybersicherheit verhindern.
Schauen Sie sich die Secure Code Warrior Blog-Seiten, um mehr über diese Schwachstelle zu erfahren und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Kenntnisse zu schärfen und auf dem neuesten Stand zu halten.
Inhaltsübersicht
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
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
Trust Score zeigt den Wert von Secure-by-Design-Upskilling-Initiativen
Unsere Forschung hat gezeigt, dass Schulungen für sicheren Code funktionieren. Trust Score verwendet einen Algorithmus, der auf mehr als 20 Millionen Lerndaten aus der Arbeit von mehr als 250.000 Lernenden in über 600 Organisationen basiert, und zeigt, wie effektiv die Initiative ist, um Schwachstellen zu beseitigen und wie man sie noch effektiver gestalten kann.
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.
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.