Guinguette Marais Poitevin

OWASP oder Open Web Security Project ist eine gemeinnützige Organisation, die sich mit der Verbesserung der Sicherheit von Software und Web-Anwendungen beschäftigt.

Die Organisation veröffentlicht eine Liste der Top-Web-Sicherheitsschwachstellen, die auf den Daten verschiedener Sicherheitsorganisationen basiert.

Die Web-Sicherheitsschwachstellen werden je nach Ausnutzbarkeit, Entdeckbarkeit und Auswirkung auf Software priorisiert.

• Ausnutzbarkeit –

  Was ist nötig, um die Sicherheitslücke auszunutzen? Am höchsten ist die Ausnutzbarkeit, wenn für den Angriff nur ein Webbrowser benötigt wird, am niedrigsten sind fortgeschrittene Programmierung und Tools.

• Erkennbarkeit –

  Wie leicht ist die Bedrohung zu erkennen? Am einfachsten anhand der Informationen, die in der URL, dem Formular oder der Fehlermeldung angezeigt werden, am einfachsten anhand des Quellcodes.

• Auswirkung oder Schaden –

  Wie groß ist der Schaden, wenn die Sicherheitslücke aufgedeckt oder angegriffen wird? Der höchste ist ein kompletter Systemabsturz und der niedrigste gar nichts.

Das Hauptziel der OWASP Top 10 ist es, Entwickler, Designer, Manager, Architekten und Organisationen über die wichtigsten Sicherheitsschwachstellen aufzuklären.

Die Top 10 Sicherheitsschwachstellen laut OWASP Top 10 sind:

• SQL Injection
• Cross Site Scripting
• Broken Authentication and Session Management
• Insecure Direct Object References
• Cross Site Request Forgery
• Security Misconfiguration
• Insecure Cryptographic Storage
• Failure to restrict URL Access
• Insufficient Transport Layer Protection
• Ungültige Um- und Weiterleitungen

SQL Injection

Beschreibung

Injection ist eine Sicherheitslücke, die es einem Angreifer ermöglicht, Backend-SQL-Anweisungen durch Manipulation der vom Benutzer bereitgestellten Daten zu verändern.

Injection tritt auf, wenn die Benutzereingabe als Teil eines Befehls oder einer Abfrage an einen Interpreter gesendet wird und den Interpreter dazu bringt, unbeabsichtigte Befehle auszuführen und Zugriff auf nicht autorisierte Daten zu geben.

Der SQL-Befehl, der von der Webanwendung ausgeführt wird, kann auch die Back-End-Datenbank offenlegen.

Implikation

• Ein Angreifer kann bösartige Inhalte in die verwundbaren Felder injizieren.
• Sensible Daten wie Benutzernamen, Passwörter usw. können aus der Datenbank gelesen werden.
• Datenbankdaten können geändert werden (Einfügen/Update/Löschen).
• Verwaltungsoperationen können auf der Datenbank ausgeführt werden

Angreifbare Objekte

• Eingabefelder
• URLs, die mit der Datenbank interagieren.

Beispiele:

• SQL-Injektion auf der Login-Seite

Einloggen in eine Anwendung ohne gültige Anmeldedaten.

Ein gültiger Benutzername ist vorhanden, ein Passwort ist nicht vorhanden.

Test-URL: http://demo.testfire.net/default.aspx

Benutzername: sjones

Passwort: 1=1′ oder pass123

Die SQL-Abfrage wurde wie folgt erstellt und an den Interpreter gesendet

SELECT * FROM Users WHERE User_Name = sjones AND Password = 1=1′ oder pass123;

Empfehlungen

1. White-Listing der Eingabefelder
2. Vermeiden Sie die Anzeige von detaillierten Fehlermeldungen, die für einen Angreifer nützlich sind.

Cross Site Scripting

Beschreibung

Cross Site Scripting ist auch kurz als XSS bekannt.

XSS-Schwachstellen zielen auf in eine Seite eingebettete Skripte ab, die auf der Client-Seite, also im Browser des Benutzers, und nicht auf der Server-Seite ausgeführt werden. Diese Schwachstellen können auftreten, wenn die Anwendung nicht vertrauenswürdige Daten übernimmt und sie ohne ordnungsgemäße Validierung an den Webbrowser sendet.

Angreifer können XSS nutzen, um bösartige Skripte auf den Benutzern, in diesem Fall den Opfer-Browsern, auszuführen. Da der Browser nicht wissen kann, ob das Skript vertrauenswürdig ist oder nicht, wird das Skript ausgeführt, und der Angreifer kann Sitzungscookies entführen, Websites verunstalten oder den Benutzer auf eine unerwünschte und bösartige Website umleiten.

XSS ist ein Angriff, der es dem Angreifer ermöglicht, die Skripte im Browser des Opfers auszuführen.

Ausführung:

• Unter Ausnutzung dieser Sicherheitslücke kann ein Angreifer Skripte in die Anwendung einschleusen, Sitzungscookies stehlen, Websites verunstalten und Malware auf den Rechnern der Opfer ausführen.

Anfällige Objekte

• Eingabefelder
• URLs

Beispiele

1. http://www.vulnerablesite.com/home?“<script>alert(„xss“)</script>

Das obige Skript wird, wenn es in einem Browser ausgeführt wird, ein Meldungsfeld anzeigen, wenn die Website für XSS anfällig ist.

Der schwerwiegendere Angriff kann durchgeführt werden, wenn der Angreifer Session-Cookies anzeigen oder speichern will.

2. http://demo.testfire.net/search.aspx?txtSearch<iframe><src = http://google.com width = 500 height 500></iframe>

Wenn das obige Skript ausgeführt wird, wird der Browser einen unsichtbaren Frame laden, der auf http://google.com zeigt.

Der Angriff kann durch das Ausführen eines bösartigen Skripts im Browser ernst gemacht werden.

Empfehlungen

1. Weißes Listing von Eingabefeldern
2. Eingabe-Ausgabekodierung

Broken Authentication and Session Management

Beschreibung

Die Webseiten erstellen in der Regel ein Session-Cookie und eine Session-ID für jede gültige Sitzung, und diese Cookies enthalten sensible Daten wie Benutzername, Passwort, etc. Wenn die Sitzung entweder durch Abmeldung oder durch abruptes Schließen des Browsers beendet wird, sollten diese Cookies ungültig gemacht werden, d. h. für jede Sitzung sollte ein neues Cookie angelegt werden.

Wenn die Cookies nicht ungültig gemacht werden, bleiben die sensiblen Daten im System bestehen. Benutzt ein Benutzer beispielsweise einen öffentlichen Computer (Cyber Cafe), befinden sich die Cookies der verwundbaren Seite auf dem System und sind für einen Angreifer sichtbar. Verwendet ein Angreifer nach einiger Zeit denselben öffentlichen Computer, sind die sensiblen Daten kompromittiert.

Auf die gleiche Weise schließt ein Benutzer, der einen öffentlichen Computer benutzt, statt sich abzumelden, abrupt den Browser. Wenn ein Angreifer dasselbe System verwendet und die gleiche verwundbare Website aufruft, wird die vorherige Sitzung des Opfers geöffnet. Der Angreifer kann tun, was immer er will, vom Stehlen von Profildaten, Kreditkarteninformationen usw.

Eine Überprüfung sollte durchgeführt werden, um die Stärke der Authentifizierung und Sitzungsverwaltung zu ermitteln. Schlüssel, Session-Tokens, Cookies sollten richtig implementiert werden, ohne Passwörter zu kompromittieren.

Anfällige Objekte

• Session-IDs, die in der URL offengelegt werden, können zu einer Session-Fixation-Attacke führen.
• Session-IDs vor und nach dem Logout und Login gleich.
• Session-Timeouts sind nicht korrekt implementiert.
• Die Anwendung vergibt für jede neue Sitzung die gleiche Sitzungs-ID.
• Authentifizierte Teile der Anwendung sind mit SSL geschützt und Passwörter werden in einem Hash- oder verschlüsselten Format gespeichert.
• Die Sitzung kann von einem Benutzer mit geringen Privilegien wiederverwendet werden.

Implikation

• Unter Ausnutzung dieser Schwachstelle kann ein Angreifer eine Sitzung kapern, sich unberechtigten Zugriff auf das System verschaffen, was die Offenlegung und Modifizierung nicht autorisierter Informationen ermöglicht.
• Die Sitzungen können mit gestohlenen Cookies oder Sitzungen mit XSS hochgejagt werden.

Beispiele

1. Die Anwendung zur Reservierung von Flugtickets unterstützt URL-Rewriting und fügt Session-IDs in die URL ein:

   http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Verkauf von Tickets auf die Malediven)

   Ein authentifizierter Benutzer der Website möchte seine Freunde über den Verkauf informieren und sendet eine E-Mail. Die Freunde erhalten die Session-ID und können damit unberechtigte Änderungen vornehmen oder die gespeicherten Kreditkartendaten missbrauchen.

2. Eine Anwendung ist anfällig für XSS, wodurch ein Angreifer auf die Sitzungs-ID zugreifen und zum Hijacking der Sitzung verwendet werden kann.
3. Anwendungen sind nicht richtig auf Timeouts eingestellt. Der Benutzer verwendet einen öffentlichen Computer und schließt den Browser, anstatt sich abzumelden und geht weg. Der Angreifer verwendet einige Zeit später denselben Browser, und die Sitzung wird authentifiziert.

Empfehlungen

1. Alle Anforderungen an die Authentifizierung und Sitzungsverwaltung sollten gemäß dem OWASP Application Security Verification Standard definiert werden.
2. Niemals irgendwelche Anmeldeinformationen in URLs oder Protokollen offenlegen.
3. Es sollten auch große Anstrengungen unternommen werden, um XSS-Fehler zu vermeiden, die zum Stehlen von Sitzungs-IDs verwendet werden können.

Unsichere direkte Objektreferenzen

Beschreibung

Es tritt auf, wenn ein Entwickler einen Verweis auf ein internes Implementierungsobjekt, wie z. B. eine Datei, ein Verzeichnis oder einen Datenbankschlüssel, in einer URL oder als FORM-Parameter offenlegt. Der Angreifer kann diese Informationen nutzen, um auf andere Objekte zuzugreifen.

Implikation

• Über diese Schwachstelle kann ein Angreifer Zugriff auf nicht autorisierte interne Objekte erlangen, Daten verändern oder die Anwendung kompromittieren.

Anfällige Objekte

• In der URL.

Beispiele:

Die Änderung von „userid“ in der folgenden URL kann einen Angreifer dazu bringen, die Daten anderer Benutzer einzusehen.

http://www.vulnerablesite.com/userid=123 Geändert in http://www.vulnerablesite.com/userid=124

Ein Angreifer kann durch Ändern des Wertes „userid“ die Informationen anderer Benutzer einsehen.

Empfehlungen:

1. Zugriffskontrollprüfungen implementieren.
2. Vermeiden Sie das Aufdecken von Objektreferenzen in URLs.
3. Überprüfen Sie die Berechtigung für alle Referenzobjekte.

Cross Site Request Forgery

Beschreibung

Cross Site Request Forgery ist eine gefälschte Anfrage, die von einer anderen Seite kommt.

Ein CSRF-Angriff ist ein Angriff, der auftritt, wenn eine bösartige Website, E-Mail oder ein Programm den Browser eines Benutzers dazu veranlasst, eine unerwünschte Aktion auf einer vertrauenswürdigen Website durchzuführen, für die der Benutzer gerade authentifiziert ist.

Ein CSRF-Angriff zwingt den Browser eines angemeldeten Opfers dazu, eine gefälschte HTTP-Anfrage, einschließlich des Sitzungs-Cookies des Opfers und anderer automatisch enthaltener Authentifizierungsinformationen, an eine anfällige Webanwendung zu senden.

Ein Link wird vom Angreifer an das Opfer gesendet, wenn der Benutzer auf die URL klickt, wenn er auf der ursprünglichen Website angemeldet ist, werden die Daten von der Website gestohlen.

Implikation

• Über diese Schwachstelle kann ein Angreifer Benutzerprofilinformationen ändern, den Status ändern, einen neuen Benutzer im Namen des Administrators erstellen usw.

Angreifbare Objekte

• Benutzerprofilseite
• Benutzerkontenformulare
• Geschäftstransaktionsseite

Beispiele

Das Opfer ist mit gültigen Anmeldedaten auf einer Bank-Website angemeldet. Er erhält eine E-Mail von einem Angreifer mit der Aufforderung: „Bitte klicken Sie hier, um 1 $ für eine gute Sache zu spenden.“

Wenn das Opfer darauf klickt, wird eine gültige Anfrage erstellt, um $1 an ein bestimmtes Konto zu spenden.

http://www.vulnerablebank.com/transfer.do?account=cause&amount=1

Der Angreifer fängt diese Anfrage ab und erstellt eine darunter liegende Anfrage und bettet eine Schaltfläche ein, auf der steht: „I Support Cause.“

http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000

Da die Sitzung authentifiziert ist und die Anfrage von der Bank-Website kommt, würde der Server 1000 Dollar an den Angreifer überweisen.

Empfehlung

1. Verlangen Sie die Anwesenheit des Benutzers bei der Durchführung sensibler Aktionen.
2. Implementieren Sie Mechanismen wie , Re-Authentifizierung und eindeutige Request Tokens.

Fehlkonfiguration der Sicherheit

Beschreibung

Die Sicherheitskonfiguration muss für die Anwendung, die Frameworks, den Anwendungsserver, den Webserver, den Datenbankserver und die Plattform definiert und eingesetzt werden. Wenn diese richtig konfiguriert sind, kann ein Angreifer unbefugten Zugriff auf sensible Daten oder Funktionen erhalten.

Manchmal führen solche Schwachstellen zu einer vollständigen Kompromittierung des Systems. Die Software auf dem neuesten Stand zu halten, ist ebenfalls eine gute Sicherheitsmaßnahme.

Implikation

• Unter Ausnutzung dieser Schwachstelle kann der Angreifer die zugrundeliegende Technologie und die Versionsinformationen des Anwendungsservers sowie Datenbankinformationen auslesen und Informationen über die Anwendung gewinnen, um weitere Angriffe zu starten.

Angreifbare Objekte

• URL
• Formularfelder
• Eingabefelder

Beispiele

1. Die Admin-Konsole des Anwendungsservers wird automatisch installiert und nicht entfernt. Die Standardkonten werden nicht geändert. Der Angreifer kann sich mit den Standardpasswörtern anmelden und unberechtigten Zugriff erlangen.
2. Directory Listing ist auf dem Server nicht deaktiviert. Der Angreifer entdeckt und kann einfach Verzeichnisse auflisten, um eine beliebige Datei zu finden.

Empfehlungen

1. Eine starke Anwendungsarchitektur, die eine gute Trennung und Sicherheit zwischen den Komponenten bietet.
2. Ändern Sie Standardbenutzernamen und -kennwörter.
3. Deaktivieren Sie Verzeichnisauflistungen und implementieren Sie Zugriffskontrollprüfungen.

Unsichere kryptografische Speicherung

Beschreibung

Sichere kryptografische Speicherung ist eine häufige Schwachstelle, die besteht, wenn die sensiblen Daten nicht sicher gespeichert werden.

Zu den sensiblen Daten auf einer Website gehören die Anmeldeinformationen des Benutzers, Profilinformationen, Gesundheitsdaten, Kreditkarteninformationen usw.

Diese Daten werden in der Datenbank der Anwendung gespeichert. Wenn diese Daten unsachgemäß gespeichert werden, indem keine Verschlüsselung oder Hashing* verwendet wird, sind sie für Angreifer angreifbar.

(*Hashing ist die Umwandlung von Zeichenfolgen in kürzere Zeichenfolgen fester Länge oder einen Schlüssel. Um die Zeichenkette zu entschlüsseln, sollte der Algorithmus, der zur Bildung des Schlüssels verwendet wurde, verfügbar sein.)

Implikation

• Durch Ausnutzung dieser Schwachstelle kann ein Angreifer solche schwach geschützten Daten stehlen, modifizieren, um Identitätsdiebstahl, Kreditkartenbetrug oder andere Verbrechen durchzuführen.

Anfällige Objekte

• Anwendungsdatenbank.

Beispiele

In einer Bankanwendung verwendet die Passwortdatenbank ungesalzene Hashes *, um die Passwörter aller Benutzer zu speichern. Ein SQL-Injection-Fehler ermöglicht es dem Angreifer, die Passwortdatei auszulesen. Alle ungesalzenen Hashes können in kürzester Zeit geknackt werden, während die gesalzenen Passwörter Tausende von Jahren benötigen würden.

(*Ungesalzene Hashes – Salt ist ein Zufallswert, der an die Originaldaten angehängt wird. Salt wird vor dem Hashing an das Passwort angehängt)

Empfehlungen

1. Sorgen Sie für geeignete starke Standardalgorithmen. Erstellen Sie keine eigenen kryptografischen Algorithmen. Verwenden Sie nur zugelassene öffentliche Algorithmen wie AES, RSA Public-Key-Kryptographie und SHA-256 usw.
2. Stellen Sie sicher, dass Offsite-Backups verschlüsselt sind, aber die Schlüssel separat verwaltet und gesichert werden.

Fehlende Beschränkung des URL-Zugriffs

Beschreibung

Webanwendungen prüfen die URL-Zugriffsrechte, bevor geschützte Links und Schaltflächen dargestellt werden. Anwendungen müssen bei jedem Zugriff auf diese Seiten ähnliche Zugriffskontrollprüfungen durchführen.

In den meisten Anwendungen werden die privilegierten Seiten, Orte und Ressourcen den privilegierten Benutzern nicht angezeigt.

Durch eine intelligente Vermutung kann ein Angreifer auf privilegierte Seiten zugreifen. Ein Angreifer kann auf sensible Seiten zugreifen, Funktionen aufrufen und vertrauliche Informationen einsehen.

Implikation

• Unter Ausnutzung dieser Schwachstelle kann ein Angreifer auf die nicht autorisierten URLs zugreifen, ohne sich in die Anwendung einzuloggen und die Schwachstelle auszunutzen. Ein Angreifer kann auf sensible Seiten zugreifen, Funktionen aufrufen und vertrauliche Informationen einsehen.

Anfällige Objekte:

• URLs

Beispiele

1. Angreifer bemerkt, dass die URL die Rolle als „/user/getaccounts“ angibt. Er modifiziert als „/admin/getaccounts“.
2. Ein Angreifer kann die Rolle an die URL anhängen.

http://www.vulnerablsite.com kann als http://www.vulnerablesite.com/admin modifiziert werden

Empfehlungen

1. Implementieren Sie starke Zugriffskontrollprüfungen.
2. Authentifizierungs- und Autorisierungsrichtlinien sollten rollenbasiert sein.
3. Beschränken Sie den Zugriff auf unerwünschte URLs.

Unzureichender Schutz der Transportschicht

Beschreibung

Es geht um den Informationsaustausch zwischen dem Benutzer (Client) und dem Server (Anwendung). Anwendungen übertragen häufig sensible Informationen wie Authentifizierungsdaten, Kreditkarteninformationen und Sitzungs-Tokens über ein Netzwerk.

Durch die Verwendung von schwachen Algorithmen oder die Verwendung von abgelaufenen oder ungültigen Zertifikaten oder die Nichtverwendung von SSL kann die Kommunikation für nicht vertrauenswürdige Benutzer offengelegt werden, die eine Webanwendung kompromittieren und oder sensible Informationen stehlen können.

Implikation

• Unter Ausnutzung dieser Web-Sicherheitslücke kann ein Angreifer die Anmeldedaten eines legitimen Benutzers ausspähen und sich Zugang zur Anwendung verschaffen.
• Kann Kreditkarteninformationen stehlen.

Angreifbare Objekte

• Daten werden über das Netzwerk gesendet.

Empfehlungen

1. Aktivieren Sie sicheres HTTP und erzwingen Sie die Übertragung von Anmeldeinformationen nur über HTTPS.
2. Stellen Sie sicher, dass Ihr Zertifikat gültig und nicht abgelaufen ist.

Beispiele:

1. Eine Anwendung, die kein SSL verwendet, ein Angreifer überwacht einfach den Netzwerkverkehr und beobachtet ein authentifiziertes Sitzungs-Cookie des Opfers. Ein Angreifer kann dieses Cookie stehlen und einen Man-in-the-Middle-Angriff durchführen.

Ungültige Um- und Weiterleitungen

Beschreibung

Die Webanwendung verwendet wenige Methoden, um Benutzer zu einem bestimmten Zweck auf andere Seiten umzuleiten und weiterzuleiten.

Wenn bei der Umleitung auf andere Seiten keine ordnungsgemäße Validierung stattfindet, können Angreifer dies ausnutzen und Opfer auf Phishing- oder Malware-Seiten umleiten oder Weiterleitungen nutzen, um auf nicht autorisierte Seiten zuzugreifen.

Implikation

• Ein Angreifer kann eine URL an den Benutzer senden, die eine echte URL mit einer verschlüsselten bösartigen URL im Anhang enthält. Ein Benutzer, der nur den echten Teil der vom Angreifer gesendeten URL sieht, kann diese durchsuchen und kann zum Opfer werden.

Beispiele

1.http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com

Modifiziert zu

http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com

Empfehlungen

1. Vermeiden Sie einfach die Verwendung von Umleitungen und Weiterleitungen in der Anwendung. Wenn sie verwendet werden, verwenden Sie keine Benutzerparameter für die Berechnung des Ziels.
2. Wenn die Zielparameter nicht vermieden werden können, stellen Sie sicher, dass der gelieferte Wert gültig und für den Benutzer autorisiert ist.

Dieser Artikel stammt von Prasanthi Eati