Die Massenzuweisungs-Schwachstelle wurde geboren, weil viele moderne Frameworks Entwickler dazu ermutigen, Funktionen zu verwenden, die automatisch Eingaben von Clients in Code-Variablen und interne Objekte binden. Dies geschieht, um den Code zu vereinfachen und Abläufe zu beschleunigen.

Angreifer können mit dieser Methode Änderungen an Objekteigenschaften erzwingen, die nie von einem Client aktualisiert werden sollten. Normalerweise führt dies zu geschäftsspezifischen Problemen, z. B. wenn ein Benutzer sich selbst Administratorrechte hinzufügt, anstatt eine Website zum Absturz zu bringen oder Firmengeheimnisse zu stehlen. Angreifer müssen auch eine gewisse Vorstellung von den Beziehungen zwischen Objekten und der Geschäftslogik der Anwendung haben, die sie ausnutzen.

Nichts davon macht jedoch die Schwachstelle der Massenzuweisung in den Händen eines cleveren und böswilligen Benutzers weniger gefährlich.

Bevor wir mit der vollständigen Anleitung beginnen, spielen Sie unsere spielerische Herausforderung und sehen Sie, wie Sie abschneiden:

Wie können Angreifer die Massenzuordnungsschwachstelle ausnutzen?

Das von OWASP vorgeschlagene (und von uns leicht modifizierte) Szenario geht von einer Ride-Sharing-Anwendung aus, die verschiedene Eigenschaften enthält, die per Massenzuweisung an Objekte im Code gebunden sind. Dazu gehören erlaubnisbezogene Eigenschaften, die Benutzer ändern können, und prozessabhängige Eigenschaften, die nur intern von der Anwendung gesetzt werden sollen. Beide verwenden Massenzuweisung, um Eigenschaften an Objekte zu binden.

In diesem Szenario erlaubt die Ride-Sharing-Anwendung den Benutzern, ihre Profile zu aktualisieren, wie es in vielen benutzerorientierten Anwendungen üblich ist. Dies geschieht über einen API-Aufruf, der an PUT gesendet wird und das folgende JSON-Objekt zurückgibt:

{"user_name":"SneakySnake", "age":17, "is_admin":false}

Da der Angreifer, in diesem Fall Mr. SneakySnake, die Beziehung zwischen den Eigenschaften und den Objekten herausgefunden hat, kann er seine ursprüngliche Anfrage zur Aktualisierung seines Profils mit der folgenden Zeichenfolge erneut senden:

{"user_name":"SneakySnake","age":24,, "is_admin":true}

Da der Endpunkt anfällig für Massenzuweisungen ist, akzeptiert er die neue Eingabe als gültig. Unser Hacker hat nicht nur ein paar Jahre zu seinem Profil hinzugefügt, sondern sich auch Admin-Rechte zugewiesen.

Beseitigung der Schwachstelle der Massenzuweisung

So bequem es auch sein mag, die Massenzuweisungsfunktion in einigen Frameworks zu verwenden, sollten Sie dies vermeiden, wenn Sie Ihre APIs sicher halten wollen. Parsen Sie stattdessen Abfragewerte, anstatt sie direkt an ein Objekt zu binden. Sie können auch ein reduziertes Datenübertragungsobjekt verwenden, das fast den gleichen Komfort wie die direkte Bindung an das Objekt selbst bieten würde, nur ohne das damit verbundene Risiko.

Als zusätzliche Vorsichtsmaßnahme könnten sensible Eigenschaften wie die Admin-Rechte aus dem obigen Beispiel verweigert werden, damit sie vom Server bei einem API-Aufruf niemals akzeptiert werden. Eine noch bessere Idee wäre es, jede Eigenschaft standardmäßig zu verweigern und dann bestimmte, nicht sensible Eigenschaften zuzulassen, die Benutzer aktualisieren oder ändern können sollen. Jede dieser Maßnahmen kann dazu beitragen, APIs zu sperren und die Schwachstelle der Massenzuweisung aus Ihrer Umgebung zu entfernen.

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.

Fügen Sie mit unserer neuen GitHub-Aktion entwicklerzentrierte Schulungen zu SARIF-Dateien im Industriestandard direkt in GitHub-Code-Scan-Workflows hinzu.

Am 30. September gab GitHub offiziell die allgemeine Verfügbarkeit von GitHub Code Scanning bekannt. GitHub Code Scanning ist ein auf Entwickler ausgerichteter, GitHub-nativer Ansatz zum einfachen Auffinden von Sicherheitsschwachstellen, bevor diese die Produktion erreichen.

Code-Scanning lässt sich in GitHub Actions " oder eine bestehende CI/CD-Umgebung " integrieren, um die Flexibilität für Entwicklungsteams zu maximieren. Es scannt den Code bei der Erstellung, zeigt umsetzbare Sicherheitsüberprüfungen in Pull-Requests an und automatisiert die Sicherheit als Teil eines GitHub-Workflows.

Ein nahtloser Ansatz zur Sicherheit für Entwickler.

Das Code-Scanning basiert auf dem offenen SARIF-Standard (Static Analysis Results Interchange Format) und ist so konzipiert, dass es sich an die ständig wachsenden Anforderungen von Unternehmen anpassen lässt. So können sie z. B. Open-Source- und kommerzielle SAST-Lösungen (Static Application Security Testing) in dieselbe GitHub-native Erfahrung integrieren.

Code-Scanning-Tools von Drittanbietern können mit einer GitHub-Aktion oder einer GitHub-App auf der Grundlage eines Ereignisses in GitHub selbst, z. B. einer Pull-Anfrage, gestartet werden. Die Ergebnisse werden als SARIF formatiert und auf die Registerkarte GitHub Security Alerts hochgeladen. Die Warnungen werden dann pro Tool zusammengefasst, und GitHub kann doppelte Warnungen verfolgen und unterdrücken. Auf diese Weise können Entwickler das Tool ihrer Wahl für jedes ihrer Projekte auf GitHub verwenden, und zwar innerhalb der nativen GitHub-Oberfläche. Ganz einfach, es durchbricht die Unterbrechung einiger traditioneller Sicherheitsansätze und respektiert den Arbeitsablauf der Entwickler.

Gestern wurde Secure Code Warrior von GitHub als einziger entwicklerorientierter Schulungsanbieter in ihrem Blogbeitrag "Third-Party Code Scanning Tools" vorgestellt:Static Analysis & Developer Security Training, neben Synk, Checkmarx, Fortify On Demand, Synopsis und Veracode.

Obwohl viele SCA/SAST-Lösungen viele Details für jede der entdeckten Schwachstellen und Verweise auf veröffentlichte Advisories und zugehörige CWEs bieten, ist nicht jeder Entwickler ein Sicherheitsexperte, und das sollte auch nicht von ihm erwartet werden. Praktische, brauchbare Ratschläge und Tools sind der Schlüssel zu einem umsetzbaren Bewusstsein.

Kontextuelles Mikro-Lernen.

Je mehr Kontext Entwickler für Schwachstellen haben, desto mehr sind sie in der Lage, die Risiken zu verstehen, die Behebung der dringendsten Probleme zu priorisieren und sie letztendlich von vornherein zu verhindern. Hier kommt Secure Code Warrior ins Spiel. Unsere Mission ist es, Entwickler zu befähigen, von Anfang an sicheren Code zu schreiben, und zwar durch unterhaltsame, ansprechende und Framework-spezifische Schulungen, die ihnen helfen, mit einem Sicherheitsdenken zu denken und zu programmieren, um schnelle Verbesserungen bei der Sicherheitskonformität, Konsistenz, Qualität und Entwicklungsgeschwindigkeit zu erreichen.

Integration von GitHub-Code-Scans

Secure Code Warrior hat eine GitHub-Aktion entwickelt, die kontextbezogenes Lernen in das GitHub-Code-Scanning einbringt. Das bedeutet, dass Entwickler eine Aktion eines Drittanbieters wie die Snyk Container Action verwenden können, um Schwachstellen zu finden, und dann die Ausgabe mit CWE-spezifischem, hyperrelevantem Lernen erweitern können.

Die Secure Code Warrior GitHub-Aktion verarbeitet eine SARIF-Datei nach Industriestandard und fügt kontextbezogene Erkenntnisse auf der Grundlage von CWE-Referenzen in einem SARIF-Regelobjekt hinzu. Auf diese Weise können Entwicklungs- und Sicherheitsteams nicht nur Schwachstellen finden, sondern auch die Berichte der unterstützten SAST-Tools mit umsetzbarem Wissen anreichern, das ihnen hilft, das erneute Auftreten von Schwachstellen zu verhindern.

Sind Sie bereit, es selbst auszuprobieren?

Holen Sie sich die Aktion kostenlos direkt vom GitHub Marketplace hier.
Erfahren Sie mehr über die Secure Code Warrior GitHub Action hier.

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.

Der National Cybersecurity Awareness Month ist der festlichste aller jährlichen Anlässe für Cybersicherheitsexperten und wird von vielen Unternehmen genutzt, um über das allgemeine Sicherheitsbewusstsein im Unternehmen nachzudenken und es zu überprüfen. Und angesichts der Tatsache, dass 62 % der Unternehmen allein im Jahr 2018 einen Phishing- oder Social-Engineering-Angriff erlebt haben, kann die Bedeutung der Sicherstellung, dass jeder Einzelne im Unternehmen - ob in einer Sicherheitsrolle oder nicht - über ein angemessenes Cybersecurity-Awareness-Training verfügt, nicht hoch genug eingeschätzt werden.

Als zunehmend globale Veranstaltung stellt der Monat einen Aufhänger für die Diskussion von Best Practices dar, und die Initiativen sind bewusst oberflächlich gehalten. Aber auch Unternehmen mit robusten Sicherheitsprogrammen und internen Spezialisten können diese Zeit nutzen, um die eher technischen Teams daraufhin zu überprüfen, was sie brauchen, um im Rahmen ihrer Rolle sicherheitsbewusster zu werden.

Für AppSec-Spezialisten, Leiter von Entwicklungsteams und die sicherheitsbewussteren Mitglieder der Ingenieurskohorte mag es sich ein wenig so anfühlen, als würde man ihnen beibringen, wie man Eier lutscht, aber es sind diese Champions innerhalb des Unternehmens, die Sicherheit und Schutz zu neuen Höhen treiben können, und zwar unternehmensweit.

Wie Sie Ihren Cybersecurity Awareness Month aufwerten können

Dies ist eine einmalige Gelegenheit für das Sicherheitsteam, dem Entwicklungsteam einen Olivenzweig zu reichen, vielleicht in Form von teamübergreifenden Aktivitäten und Programmen, die den Entwicklern helfen können, ein positiveres Gefühl gegenüber der Sicherheit im Zusammenhang mit ihrer Arbeit zu entwickeln.

Einige Ideen für den Start sind:

1. Helfen Sie Entwicklern, die Unterstützung zu bekommen, die sie brauchen, um sicheres Coding zu lernen. Nicht die richtigen Werkzeuge für die Aufgabe zu haben, ist ein guter Weg, sich berechtigt zu fühlen, eine Aufgabe in den Korb "Zu schwer" zu werfen. Wenn Entwickler nicht das richtige Training und die richtigen Werkzeuge haben, um Sicherheit als Priorität im Programmierprozess zu sehen, dann ist es kein Wunder, dass so viele Teams schlecht ausgerüstet sind, um häufige Schwachstellen aus ihrem Code herauszuhalten.
   
   Nutzen Sie diesen Monat, um zu verstehen, was im technischen Stack der Entwicklung fehlt, welche Manager zusammenarbeiten können, um die Kommunikation zu verbessern und die Sicherheitstransparenz zu erhöhen, und wer weiterhin für die Sicherheit eintreten und sie fördern kann.
   
2. Veranstalten Sie ein "Lunch and Learn"-Event. Die Cybersicherheits- und Entwickler-Communitys sind im Allgemeinen voll von unglaublich großzügigen Menschen, die nur zu gerne ihr Fachwissen teilen. Wenden Sie sich an Konferenzredner, technische Kollegen in anderen Unternehmen oder sogar an lokale OWASP-Organisationen und schauen Sie, wer vorbeikommen und mit dem Team chatten oder ein Webinar mit jemandem in der Organisation aufzeichnen könnte. Es ist ein relativ schneller Gewinn, und es kann ein großer Vorteil für aufstrebende Entwickler sein, verschiedene Karrierewege im Bereich Sicherheit vor sich zu sehen.
   
3. Versammeln Sie sich zu einem freundschaftlichen Wettbewerb. Es macht viel mehr Spaß, etwas über Sicherheit zu lernen, wenn man etwas anderes und Besonderes macht. Sicheres Coding tournaments ist eine großartige Möglichkeit, Entwickler dazu zu bringen, ihre Fähigkeiten im sicheren Coding zu testen und sich mit Gleichgesinnten in einer spielerischen Umgebung zu messen. Veranstalten Sie ein Kostümfest und seien Sie kreativ mit den Teams (wie wäre es mit Entwicklern gegen ihre Manager?). Bestellen Sie Pizza und Getränke, sorgen Sie für gute Musik und es wird ein unvergessliches Ereignis für die ganze Organisation.

Geben Sie der community etwas zurück: Laden Sie Ihre kostenlose Secure Code Bootcamp App herunter

Ich bin selbst Entwickler, und es war schon immer so, dass wir nach dem suchen, was wir kostenlos teilen und nutzen können. Es ist ein Punkt des Stolzes, etwas Freeware zu machen, die anderen helfen könnte, und dieser Monat ist ein guter Zeitpunkt, um uns auf unsere Wurzeln zu besinnen und zu schauen, was wir der Gemeinschaft zur Verfügung stellen können.

Zu diesem Zweck freuen wir uns, unsere neue, kostenlose App Secure Code Bootcamp ankündigen zu können. Es handelt sich dabei um einen sicheren Programmierbegleiter für Programmierer, die sich selbst herausfordern und ihr Sicherheitsbewusstsein überall und jederzeit schrittweise verbessern wollen.

Laden Sie die App für iOS und Android jetzt herunter und lernen Sie, wie Sie OWASP-Schwachstellen in Node.JS, Python:Django, Java:Spring, C# .NET finden und identifizieren: MVC:

Mit dem Mangel an Ressourcen und der Ratenbegrenzung verhält sich die API-Schwachstelle fast genau so, wie sie im Titel beschrieben wird. Jede API verfügt über begrenzte Ressourcen und Rechenleistung, die ihr je nach Umgebung zur Verfügung stehen. Die meisten müssen auch Anfragen von Benutzern oder anderen Programmen bearbeiten, die sie auffordern, die gewünschte Funktion auszuführen. Diese Schwachstelle tritt auf, wenn zu viele Anfragen gleichzeitig eingehen und die API nicht über genügend Rechenressourcen verfügt, um diese Anfragen zu bearbeiten. Die API kann dann nicht mehr verfügbar sein oder nicht mehr auf neue Anfragen reagieren.

APIs werden anfällig für dieses Problem, wenn ihre Raten- oder Ressourcenlimits nicht korrekt eingestellt sind oder wenn Limits im Code undefiniert bleiben. Eine API kann dann überlastet werden, wenn z. B. ein Unternehmen eine besonders geschäftige Zeit erlebt. Es ist aber auch eine Sicherheitsschwachstelle, da Bedrohungsakteure ungeschützte APIs absichtlich mit Anfragen überlasten können, um Denial-of-Service-Angriffe (DDoS) durchzuführen.  

Übrigens, wie geht es Ihnen bisher mit den API gamifizierten Herausforderungen? Wenn Sie Ihre Fähigkeiten im Umgang mit einer ratenbegrenzenden Schwachstelle gleich ausprobieren möchten, treten Sie in die Arena:

Lassen Sie uns ein wenig tiefer gehen.

Was sind einige Beispiele für den Mangel an Ressourcen und die Rate, die die Anfälligkeit der API einschränken?

Es gibt zwei Möglichkeiten, wie sich diese Sicherheitslücke in eine API einschleichen kann. Die erste ist, wenn ein Programmierer einfach nicht definiert, wie hoch die Drosselungsraten für eine API sein sollen. Vielleicht gibt es irgendwo in der Infrastruktur eine Standardeinstellung für Drosselungsraten, aber sich darauf zu verlassen, ist keine gute Strategie. Stattdessen sollten die Raten für jede API individuell festgelegt werden. Dies gilt insbesondere deshalb, weil APIs sehr unterschiedliche Funktionen sowie verfügbare Ressourcen haben können.

Zum Beispiel könnte eine interne API, die nur einige wenige Benutzer bedienen soll, eine sehr niedrige Drosselungsrate haben und problemlos funktionieren. Eine öffentlich zugängliche API, die Teil einer E-Commerce-Website ist, benötigt jedoch höchstwahrscheinlich eine außergewöhnlich hohe Drosselungsrate, um die Möglichkeit eines Anstiegs der gleichzeitigen Benutzer zu kompensieren. In beiden Fällen sollten die Drosselungsraten auf der Grundlage der erwarteten Anforderungen, der Anzahl der potenziellen Benutzer und der verfügbaren Rechenleistung definiert werden.

Besonders bei APIs, die wahrscheinlich sehr stark ausgelastet sind, könnte es verlockend sein, die Preise auf unbegrenzt zu setzen, um die Leistung zu maximieren. Dies könnte mit einem einfachen Stück Code erreicht werden (als Beispiel verwenden wir das Python Django REST Framework):

"DEFAULT_THROTTLE_RATES: {
       "anon: None,
       "user: None

In diesem Beispiel können sowohl anonyme Benutzer als auch solche, die dem System bekannt sind, die API beliebig oft kontaktieren, ohne Rücksicht auf die Anzahl der Anfragen im Laufe der Zeit. Dies ist eine schlechte Idee, denn egal wie viele Rechenressourcen einer API zur Verfügung stehen, Angreifer können Dinge wie Botnets einsetzen, um sie schließlich zu verlangsamen oder möglicherweise ganz offline zu schalten. Wenn das passiert, wird gültigen Benutzern der Zugriff verweigert und der Angriff ist erfolgreich.

Beseitigung von Ressourcenmangel und ratenbegrenzenden Problemen

Für jede API, die von einer Organisation eingesetzt wird, sollten die Drosselungsraten im Code definiert sein. Dies könnte Dinge wie Ausführungszeitüberschreitungen, den maximal zulässigen Speicher, die Anzahl der Datensätze pro Seite, die an einen Benutzer zurückgegeben werden können, oder die Anzahl der zulässigen Prozesse innerhalb eines bestimmten Zeitrahmens umfassen.

Aus dem obigen Beispiel könnte man, anstatt die Drosselungsraten weit offen zu lassen, sie eng definieren mit unterschiedlichen Raten für anonyme und bekannte Benutzer.

"DEFAULT_THROTTLE_RATES: {
       "anon: config("THROTTLE_ANON, default=200/hour),
       "user: config("THROTTLE_USER, default=5000/hour)

In dem neuen Beispiel würde die API anonyme Benutzer auf 200 Anfragen pro Stunde beschränken. Bekannte Benutzer, die bereits vom System überprüft wurden, erhalten mit 5.000 Anfragen pro Stunde mehr Spielraum. Aber auch sie sind begrenzt, um eine versehentliche Überlastung zu Spitzenzeiten zu verhindern oder um zu kompensieren, wenn ein Benutzerkonto kompromittiert und für einen Denial-of-Service-Angriff verwendet wird.

Als abschließende gute Praxis ist es eine gute Idee, eine Benachrichtigung für Benutzer anzuzeigen, wenn sie die Drosselungsgrenzen erreicht haben, zusammen mit einer Erklärung, wann diese Grenzen zurückgesetzt werden. Auf diese Weise wissen gültige Benutzer, warum eine Anwendung ihre Anfragen ablehnt. Dies kann auch hilfreich sein, wenn gültigen Benutzern, die genehmigte Aufgaben ausführen, der Zugriff auf eine API verweigert wird, da dies dem Betriebspersonal signalisieren kann, dass die Drosselung erhöht werden muss.

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 Schwachstelle "Excessive Data Exposure" unterscheidet sich von anderen API-Problemen auf der OWASP-Liste dadurch, dass sie eine ganz bestimmte Art von Daten betrifft. Die eigentliche Mechanik hinter der Schwachstelle ist ähnlich wie bei anderen Schwachstellen, aber exzessive Datenexposition ist in diesem Fall so definiert, dass gesetzlich geschützte oder hochsensible Daten betroffen sind. Dies kann alle persönlich identifizierbaren Informationen umfassen, die oft als PII bezeichnet werden. Oder es kann sich um Informationen der Kreditkartenindustrie (PCI) handeln. Schließlich kann eine übermäßige Datenexposition alle Informationen umfassen, die Datenschutzgesetzen unterliegen, wie z. B. der General Data Protection Regulation (GDPR) in Europa oder dem Health Insurance Portability and Accountability Act (HIPAA) in den USA.

Wie Sie sich vorstellen können, gibt dies Anlass zu großer Sorge, und es ist zwingend erforderlich, dass versierte Entwickler lernen, wie sie diese Fehler, wo immer möglich, ausmerzen können. Wenn Sie bereits bereit sind, es mit einem Datenexpositionsdrachen aufzunehmen, gehen Sie zu unserer gamifizierten Herausforderung:

Wie war Ihr Ergebnis? Lesen Sie weiter und erfahren Sie mehr:

Was sind einige Beispiele für übermäßige Datenbelastung?

Einer der Hauptgründe für die übermäßige Datenexposition ist, dass Entwickler und Programmierer nicht genügend Einblick in die Art der Daten haben, die ihre Anwendungen verwenden werden. Aus diesem Grund neigen Entwickler dazu, generische Prozesse zu verwenden, bei denen alle Objekteigenschaften für den Endbenutzer offengelegt werden.

Entwickler gehen manchmal auch davon aus, dass Frontend-Komponenten eine Datenfilterung durchführen, bevor sie dem Benutzer Informationen anzeigen. Für die meisten generischen Daten ist dies selten ein Problem. Aber die Offenlegung rechtlich geschützter oder sensibler Daten für Benutzer, z. B. als Teil einer Sitzungs-ID, kann zu großen Problemen führen, sowohl aus Sicherheits- als auch aus rechtlicher Sicht.

Als Beispiel dafür, wie leicht sensible Daten versehentlich weitergegeben werden können, stellt sich der OWASP-Bericht ein Szenario vor, in dem ein Wachmann Zugriff auf bestimmte IOT-basierte Kameras in einer Einrichtung erhält. Vielleicht überwachen diese Kameras versiegelte und gesicherte Bereiche, während andere Kameras, die Menschen sehen, auf Wachpersonal oder Vorgesetzte mit höheren Berechtigungen beschränkt sein sollen.

Um dem Wächter Zugriff auf autorisierte Kameras zu geben, können Entwickler einen API-Aufruf wie den folgenden verwenden.

/api/sites/111/kameras

Als Antwort würde die App Details zu den Kameras, die der Wachmann sehen kann, im folgenden Format senden:

{ "id":"xxx","live_access_token":"xxxxbbbbb","building_id":"yyy"}

Oberflächlich betrachtet, scheint dies gut zu funktionieren. Der Wachmann, der die grafische Benutzeroberfläche der App verwendet, würde nur die Kamera-Feeds sehen, für die er eine Berechtigung hat. Das Problem ist, dass aufgrund des verwendeten generischen Codes die tatsächliche API-Antwort eine vollständige Liste aller Kameras in der gesamten Anlage enthalten würde. Jeder, der das Netzwerk ausspäht und diese Daten erfasst oder das Konto des Wachmanns kompromittiert, wäre in der Lage, die Standorte und die Nomenklatur jeder Kamera im Netzwerk zu ermitteln. Sie könnten dann ohne Einschränkung auf diese Daten zugreifen.

Eliminieren übermäßiger Datenbelastung

Der größte Schlüssel zur Vermeidung einer übermäßigen Datenexposition ist das Verständnis der Daten und der sie umgebenden Schutzmaßnahmen. Generische APIs zu erstellen und es dem Client zu überlassen, Daten zu sortieren, bevor sie den Benutzern angezeigt werden, ist eine gefährliche Entscheidung, die zu vielen vermeidbaren Sicherheitsverletzungen führt.

Neben dem Verständnis der relevanten Datenschutzbestimmungen ist es auch wichtig, den Prozess zu stoppen, alles mit generischen APIs an einen Benutzer zu senden. Zum Beispiel muss Code wie to_json() und to_string() vermieden werden. Stattdessen sollte der Code speziell die Eigenschaften auswählen, die an autorisierte Benutzer zurückgegeben werden müssen, und ausschließlich diese Informationen senden.

Um sicherzustellen, dass keine geschützten Daten versehentlich weitergegeben werden, sollten Unternehmen die Implementierung eines schemabasierten Antwortvalidierungsmechanismus als zusätzliche Sicherheitsebene in Betracht ziehen. Dieser sollte die Daten, die von allen API-Methoden zurückgegeben werden, definieren und erzwingen, einschließlich Regeln für die Fehlerberichterstattung.

Schließlich sollten alle Daten, die als PII oder PCI klassifiziert sind, oder Informationen, die durch Vorschriften wie GDPR oder HIPAA geschützt sind, mit starker Verschlüsselung geschützt werden. Auf diese Weise gibt es eine gute zweite Verteidigungslinie, die die Daten auch dann schützt, wenn sie in die Hände eines böswilligen Anwenders oder Bedrohungsakteurs gelangen, selbst wenn der Speicherort dieser Daten als Teil einer Schwachstelle mit übermäßiger Datenexposition nach außen gelangt.

Lesen Sie auf den Secure Code Warrior Blog-Seiten, um mehr über diese Schwachstelle zu erfahren und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen 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.

Es ist kein Wunder, dass gebrochene Authentifizierung es auf die OWASP-Liste für API-Probleme geschafft hat - Authentifizierungsmechanismen sind notorisch schwierig korrekt zu implementieren. Außerdem haben Angreifer einen kleinen Vorteil, da die meisten Authentifizierungsherausforderungen von Natur aus für die Benutzer sichtbar sein müssen, was Angreifern die Möglichkeit gibt, sie zu studieren und nach Mustern oder Schwachstellen zu suchen, die sie ausnutzen können.

Da die Authentifizierung häufig als Tor zu einer Anwendung und möglicherweise auch zum restlichen Netzwerk fungiert, sind sie ein verlockendes Ziel für Angreifer. Wenn ein Authentifizierungsprozess fehlerhaft oder anfällig ist, besteht eine gute Chance, dass Angreifer diese Schwäche entdecken und ausnutzen.

In diesem Kapitel werden wir also lernen, wie man die bösen Jungs ausschaltet, wenn es um Authentifizierungsprobleme geht. Wenn Sie Ihre Fähigkeiten zuerst testen möchten, spielen Sie unsere spielerische Herausforderung:

Wollen Sie Ihr Ergebnis verbessern? Bleiben Sie bei mir, während wir es aufschlüsseln.

Was sind einige Beispiele für fehlerhafte oder falsch konfigurierte Authentifizierung?

Ein Beispiel, bei dem das Problem vielleicht nicht so offensichtlich ist, ist, wenn eine Authentifizierungsmethode anfällig für Credential Stuffing ist, also die Verwendung von Listen mit bekannten Benutzernamen und Passwörtern, um die Sicherheit zu umgehen. Selbst eine normalerweise sehr sichere Autorisierungsmethode, wie die Multifaktor-Authentifizierung, kann anfällig sein, wenn Anfragen nicht begrenzt, gedrosselt oder anderweitig überwacht werden.

Ein Angreifer könnte zum Beispiel eine Passwort-Wiederherstellungsanfrage auslösen, indem er eine POST-Anfrage an /api/system/verification-codes sendet und einen Benutzernamen im Anfragetext angibt. Wenn eine App eine SMS-Challenge verwendet, bei der ein sechsstelliger Code an das Telefon eines Benutzers gesendet wird, das Eingabefeld aber nicht begrenzt ist, kann die Anwendung in wenigen Minuten geknackt werden. Ein Angreifer muss einfach jede mögliche sechsstellige Kombination in die Anwendung senden, bis er die richtige trifft.

In diesem Szenario sieht es oberflächlich betrachtet so aus, als ob die Zwei-Faktor-Authentifizierung eine Anwendung sicher machen würde. Aber da die Benutzereingabe nicht ratenbegrenzt ist, ist die Authentifizierung fehlerhaft und angreifbar.

In einem anderen Beispiel könnte eine Anwendung verschlüsselte Benutzerobjekte als Authentifizierungs-Cookies verwenden. Wenn jedoch ein Angreifer mit Low-Level-Benutzerzugriff dieses Cookie mit Base64 dekodiert, könnte er herausfinden, wie das Cookie Sitzungen und Benutzer für die Anwendung definiert. Nach der Dekodierung könnte er zum Beispiel folgendes JSON sehen:

{
"username" : "ShadyGuy",
"role" : "user"
{

An diesem Punkt könnte der böswillige Benutzer seinen Benutzernamen, seine Rolle oder beides ändern. Er könnte ein anderer Benutzer mit einer höheren Berechtigungsstufe werden, indem er ein paar Werte ändert:

{
"username" : "GoodGuy",
"role" : "admin"
{

Wenn der Angreifer zu diesem Zeitpunkt die Informationen umkodiert und als Cookie-Wert einstellt, wird er im Wesentlichen zum neuen Benutzer mit einer höheren Berechtigungsstufe. Wenn keine Methoden vorhanden sind, um eine solche Änderung zu verhindern, besteht eine gute Chance, dass die Anwendung die Umwandlung akzeptiert.

Eliminieren von fehlerhafter oder falsch konfigurierter Authentifizierung

Wenn die Authentifizierung fehlschlägt, ist die Wahrscheinlichkeit groß, dass die Sicherheit in der gesamten Anwendung beeinträchtigt wird. Aber das Befolgen einiger wichtiger Richtlinien beim Codieren von Anwendungen kann dazu beitragen, dass alles sicher bleibt.

Zunächst einmal sollten Sie sicherstellen, dass überall dort, wo Benutzer auf Programmfunktionen zugreifen können, Authentifizierungsprüfungen vorhanden sind. Wenn die Authentifizierungsprüfung überhaupt nicht vorhanden ist, dann ist die Schlacht von vornherein verloren.

In Bezug auf Best Practices ist eine gute Sache, die man im Hinterkopf behalten sollte, zu vermeiden, dass Sitzungs-IDs in der URL, die für Benutzer zugänglich ist, offengelegt werden. Im zweiten Beispiel oben bezüglich der gebrochenen Authentifizierung ist es viel einfacher, einen Angreifer davon abzuhalten, zu versuchen, das Sitzungs-Cookie zu entschlüsseln, wenn es ihm niemals offengelegt wird.

Es ist auch eine gute Idee, eine Multifaktor-Authentifizierung zu implementieren. Dies kann sicher mit Hardware-Tokens erfolgen, die Passwörter nach einem festen Zeitplan algorithmisch generieren. Wenn Sie Ihren Benutzern solche Geräte nicht zur Verfügung stellen können, können auch SMS-Textnachrichten funktionieren. Sie müssen jedoch sicherstellen, dass die Benutzeranfragen auf etwas Vernünftiges wie drei oder vier Versuche in einem Zeitraum von 30 Sekunden beschränkt sind und dass die Codes insgesamt nach wenigen Minuten ablaufen. Die Verwendung eines alphanumerischen Codes kann auch die Sicherheit erhöhen, indem Buchstaben und Zahlen zu potenziellen Passwörtern hinzugefügt werden.

Vermeiden Sie schließlich nach Möglichkeit die Abhängigkeit von Benutzernamen oder vorhersehbaren sequentiellen Werten als Sitzungs-IDs. Verwenden Sie stattdessen einen sicheren serverseitigen Sitzungsmanager, der jedes Mal eine zufällige Sitzungs-ID erzeugt.

Die Implementierung sicherer Authentifizierungsmethoden ist ein wenig kniffliger als die Bekämpfung einer durchschnittlichen Schwachstelle. Aber da die Autorisierung für jede Anwendung, jedes Programm und jede API so wichtig ist, lohnt es sich, sich extra Zeit zu nehmen, um sicherzustellen, dass Sie es richtig machen.

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.

Eines der besten Dinge an der Arbeit in einem Tech-Startup sind all die interessanten, cleveren Leute, die man auf dem Weg trifft und mit denen man zusammenarbeitet. Um ein Unternehmen von einer coolen Idee zu einem ernstzunehmenden Marktanwärter zu entwickeln, muss man sein eigenes Team von Avengers (oder Justice League, je nach Zugehörigkeit) zusammenstellen.

In diesem Sinne möchten wir einen unserer Experten, Oscar Quintas, ins Rampenlicht stellen. Er ist Teil unseres Product Content Teams und arbeitet als Senior Security Researcher. Er ist außerdem unser ortsansässiger Zauberer für alles, was mit Infrastructure as Code (IaC) zu tun hat. Er ist die treibende Kraft hinter unseren 178 (und mehr!) IaC-Plattform-Herausforderungen und unser Ansprechpartner für alle brennenden Fragen, die wir zu diesem brandaktuellen Thema haben.

Wir denken, dass er ziemlich besonders ist, deshalb möchten wir, dass Sie ihn ein wenig besser kennenlernen. Hier wird er seine Einblicke in das brandaktuelle Thema der Infrastructure as Code-Sicherheit, seine Rolle und was Unternehmen tun können, um ihre Cloud-Infrastruktur und Ingenieure besser vorzubereiten:

F: Erzählen Sie uns etwas über Ihre Rolle bei Secure Code Warrior. Wie sieht ein typischer Tag für Sie aus?

A: Ich bin Teil des Product Content Teams und arbeite als Senior Security Researcher. Ein typischer Tag besteht darin, Code in verschiedenen Sprachen (Python, Java, Golang und viele andere!) zu überprüfen, um sicherzustellen, dass die Qualitätsstandards für den Code eingehalten und bewährte Sicherheitsverfahren implementiert werden. Ich entwickle auch neue IaC-Inhalte.

F: Sie sind das Genie hinter all unseren Infrastructure as Code-Plattform-Herausforderungen gewesen. Wie sieht Ihr Prozess aus?

A: Ich würde sagen, es ist eine Kombination aus Recherche und harter Arbeit, um Inhalte zu liefern, die eine hohe Relevanz und ein hohes Maß an Engagement für verschiedene Qualifikationsstufen bieten. Ich beginne in der Regel damit, die häufigsten Probleme zu untersuchen, mit denen Benutzer bei der Bereitstellung der Infrastruktur konfrontiert sind, und mit diesen Informationen entwickle ich nützliche Herausforderungen, um die besten Sicherheitspraktiken für jeden Fall zu zeigen.

Ich versuche immer, unseren Kriegern eine gute Lernerfahrung zu bieten und sicherzustellen, dass es eine berufsrelevante und nützliche Übung mit einem anhaltenden Nutzen ist.

F: IaC-Sicherheit ist im Moment ein sehr beliebtes Thema. Was sind die wichtigsten Probleme, mit denen Unternehmen in Bezug auf ihre Cloud-Sicherheitspraktiken konfrontiert sind?
A: Bei Infrastructure as Code geht es um die Verwaltung Ihrer Infrastrukturressourcen mithilfe von Code. Mit nur ein paar Zeilen dieses Codes können Sie Hunderte von Cloud-Ressourcen (Netzwerk, Firewall-Regeln, virtuelle Maschinen, Container usw.) bereitstellen, die Sicherheitslücken enthalten können, wenn sie nicht richtig konfiguriert sind. Die gleichen Prinzipien, die für die sichere Anwendungsbereitstellung gelten, können also auch auf IaC angewendet werden, und diese Risiken - und ihre Behebung - müssen von jedem am SDLC beteiligten Team verstanden werden.

Dieses Bewusstsein und diese Maßnahmen beginnen mit einer angemessenen Schulung in IaC-Sicherheit und der Priorisierung der sicheren Codierungsfähigkeiten Ihrer Cloud-Ingenieure. Sie können eine mächtige Verteidigungsschicht sein, und dies ist besonders wichtig, wenn sie die Infrastruktur aufbauen, die Anwendungen hostet.

F: In der Branche gibt es viel Interesse an Kubernetes, und es scheint weit verbreitet zu sein. Unsere Plattformdaten zeigen jedoch, dass Terraform eine überwältigend populäre Sprache ist, mit hohem Engagement. Können Sie uns sagen, warum diese Sprache so beliebt ist?
A: Terraform ist die De-facto-Sprache für IaC, da sie es uns ermöglicht, Infrastrukturressourcen in Multi-Cloud-Umgebungen (z. B. AWS, GCP, Azure) mit einer einfachen Syntax bereitzustellen. Es ermöglicht Ihnen, Ihre Infrastruktur mithilfe von Code zu definieren, und es interagiert transparent mit Cloud-APIs, um die Bereitstellung der Ressourcen zu verwalten.

Diese Sprache ist unglaublich vielseitig, und da sie zu Source-Control-Repositories hinzugefügt werden kann, können DevOps / DevSecOps-Prinzipien auch auf die Bereitstellung der Infrastruktur angewendet werden. Allerdings werden dadurch auch neue Bedrohungen eingeführt, die adressiert werden müssen, daher ist eine umfassende Schulung in sicherer Kodierung mit Terraform ein Muss.

F: Sie sind ein IaC-Sicherheitsexperte. Was ist das Beste an Ihrem Job?
A: IaC steckt noch in den Kinderschuhen, daher gibt es eine Menge neuer Dinge, die häufig veröffentlicht werden. Es ist ein bisschen herausfordernd, mit diesen neuen Technologien auf dem Laufenden zu bleiben, aber es ist gleichzeitig auch sehr lohnend. Ich mag es wirklich, neue Dinge zu lernen und bewährte Sicherheitsverfahren für neue Dienste zu testen.

Bringen Sie Ihre IaC-Sicherheit auf die nächste Stufe.

Wenn Sie möchten, dass Ihre Cloud-Entwickler ihre Sicherheitskenntnisse rund um Infrastructure as Code verfeinern, fordern Sie sich mit unseren IaC Top 8 heraus! Lesen Sie jedes Kapitel für die vollständige Auflistung von acht häufigen IaC-Sicherheitsfehlern, einschließlich interaktiver Herausforderungen, um ihr neues Wissen zu testen.

Teilen Sie uns Ihr Ergebnis mit und machen Sie Oscar stolz!

Die Bedrohungen für die Cybersicherheit sind heutzutage allgegenwärtig und unerbittlich. Es ist so schlimm geworden, dass der Versuch, mit ihnen Schritt zu halten, nachdem Programme bereitgestellt wurden, fast unmöglich geworden ist. Im Zeitalter von DevSecOps, Continuous Delivery und mehr Daten als je zuvor helfen kluge Unternehmen ihren Entwicklern, sich zu sicherheitsbewussten Superstars zu entwickeln, die dabei helfen, häufige Schwachstellen zu beseitigen, bevor sie in die Produktion gelangen. Wir haben uns mit Web-Schwachstellen und unseren eigenen Top 8 Infrastructure as Code-Bugs befasst, und jetzt ist es an der Zeit, sich mit der nächsten großen Software-Sicherheitsherausforderung vertraut zu machen. Sind Sie bereit?

Diese nächste Blogserie konzentriert sich auf einige der schlimmsten Sicherheitslücken im Zusammenhang mit Application Programming Interfaces (APIs). Diese sind so schlimm, dass sie es auf 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.

Ein perfektes Beispiel dafür, warum es unerlässlich ist, Code zu verwenden, um die Sicherheit zu erzwingen, findet sich in einer Untersuchung der Schwachstelle "broken object level authorization". Dies geschieht, wenn Programmierer nicht explizit definieren, welche Benutzer in der Lage sind, Objekte und Daten anzuzeigen oder irgendeine Form der Überprüfung vorzunehmen, um Objekte anzuzeigen, zu ändern oder andere Anfragen zur Manipulation oder zum Zugriff auf Objekte zu stellen, so dass sie Objekte und Daten über API-Endpunkte ändern und darauf zugreifen können. Ein API-Endpunkt ist ein Berührungspunkt, oft eine URL, der für die Kommunikation zwischen der API selbst und einem anderen System verwendet wird. Die Fähigkeit zur Konnektivität zwischen Apps hat einige der beliebtesten Software der Welt aufgewertet, aber sie geht mit dem Risiko einher, dass mehrere Endpunkte offengelegt werden, wenn sie nicht luftdicht sind.

Es kann auch vorkommen, dass Programmierer Eigenschaften von übergeordneten Klassen vergessen oder erben, ohne sich darüber im Klaren zu sein, dass sie damit auch einen kritischen Überprüfungsprozess innerhalb ihres Codes auslassen. Generell sollten Berechtigungsprüfungen auf Objektebene für jede Funktion enthalten sein, die über eine Eingabe des Benutzers auf eine Datenquelle zugreift.

Sie denken, Sie kennen diese bereits und können einen Fehler in der Zugangskontrolle sofort finden, beheben und beseitigen? Spielen Sie die gamifizierte Herausforderung:

Wie haben Sie abgeschnitten? Wenn Sie an Ihrem Ergebnis arbeiten wollen, lesen Sie weiter!

Was sind einige Beispiele für Sicherheitslücken bei der Autorisierung auf Objektebene?

Schwachstellen in der Zugriffskontrolle auf Objektebene ermöglichen es Angreifern, Aktionen auszuführen, die ihnen nicht erlaubt sein sollten. Dabei kann es sich um Aktionen handeln, die Administratoren vorbehalten sein sollten, wie z. B. der Zugriff auf oder die Anzeige von sensiblen Daten oder das Zerstören von Datensätzen. In einer hochsicheren Umgebung könnte es sogar bedeuten, dass niemand Datensätze einsehen darf, es sei denn, er ist ausdrücklich dazu autorisiert.
Sie sollten alle möglichen Aktionen im Auge behalten, wenn Sie die Autorisierung auf Objektebene definieren. In Java Spring API könnte ein Endpunkt mit einem potenziellen Problem zum Beispiel so aussehen:

public boolean deleteOrder(Long id) {
       Order order = orderRepository.getOne(id);
       if (order == null) {
           log.info("No found order");
           return false;
       }
       User user = order.getUser();
       orderRepository.delete(order);
       log.info("Delete order for user {}", user.getId());
       return true;

Der API-Endpunkt löscht Bestellungen nach ID, prüft aber nicht, ob diese Bestellung von dem aktuell angemeldeten Benutzer getätigt wurde. Dies stellt eine Möglichkeit für einen Angreifer dar, diese Lücke auszunutzen und die Bestellungen anderer Benutzer zu löschen.

Um sichere Zugriffsbeschränkungen richtig zu implementieren, würde der Code eher wie folgt aussehen:

public boolean deleteOrder(Long id) {
       User user = userService.getUserByContext();
       boolean orderExist = getUserOrders().stream()
               .anyMatch(order -> (order.getId() == id));
       if (orderExist) {
           orderRepository.deleteById(id);
           log.info("Delete order for user {}", user.getId());
           return true;
       } else {
           log.info("No found order");
           return false;

Eliminierung von Schwachstellen bei der Autorisierung auf Objektebene

Der Code für die Zugriffskontrolle muss nicht übermäßig kompliziert sein. Im Fall unseres Beispiels einer Java-Spring-API-Umgebung kann er durch eine enge Definition, wer auf Objekte zugreifen darf, festgelegt werden.

Zunächst muss ein Verifizierungsprozess implementiert werden, um zu identifizieren, wer die Anfrage stellt:

Benutzer user = userService.getUserByContext();

Als nächstes müssen wir sicherstellen, dass die Objekt-ID existiert und zu dem Benutzer gehört, der die Anfrage stellt:

boolean orderExist = getUserOrders().stream()
.anyMatch(order -> (order.getId() == id));

Und schließlich fahren wir fort, das Objekt zu löschen:

orderRepository.deleteById(id);

Denken Sie daran, dass Sie sicherstellen müssen, dass die Autorisierungsmethode in Ihrem Code mit den Benutzerrichtlinien und Datenzugriffskontrollen Ihrer Organisation übereinstimmt. Um sicherzustellen, dass Ihr Code vollständig sicher ist, sollten Sie Prüfungen durchführen, um zu verifizieren, dass Benutzer mit verschiedenen Berechtigungsstufen Zugriff auf die Daten haben, die sie für ihre Arbeit benötigen, aber daran gehindert werden, etwas anzuzeigen oder zu ändern, das auf sie beschränkt sein sollte. Auf diese Weise werden möglicherweise Schwachstellen in der Objektsteuerung aufgedeckt, die versehentlich übersehen wurden.

Die wichtigsten Erkenntnisse aus diesen Beispielen sind, zuerst jede Aktion zu definieren, die ein Benutzer mit einem Objekt durchführen könnte, und dann starke Zugriffskontrollen direkt in den Code einzufügen. Und schließlich sollten Sie niemals darauf vertrauen, dass die vererbten übergeordneten Eigenschaften diese Aufgabe übernehmen oder diese Berechtigung an andere Stellen delegieren. Definieren Sie stattdessen Benutzerberechtigungen und Aktionen im Code explizit für jeden Objekttyp, den Sie schützen müssen.

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.