Die 10 häufigsten Sicherheitslücken im Internet

OWASP oder Open Web Security Project ist eine gemeinnützige Wohltätigkeitsorganisation, deren Schwerpunkt auf der Verbesserung der Sicherheit von Software und Webanwendungen liegt.

Die Organisation veröffentlicht eine Liste der größten Sicherheitslücken im Internet, die auf den Daten verschiedener Sicherheitsorganisationen basiert.

Die Web-Sicherheitslücken werden nach Ausnutzbarkeit, Erkennbarkeit und Auswirkung auf die Software priorisiert.

• Ausnutzbarkeit –Was ist erforderlich, um die Sicherheitslücke auszunutzen? Die höchste Ausnutzbarkeit besteht, wenn für den Angriff nur ein Webbrowser erforderlich ist, und die geringste, wenn fortgeschrittene Programmierung und Tools erforderlich sind.
• Erkennbarkeit – Wie einfach ist es, die Bedrohung zu erkennen? Am einfachsten sind die in URL, Formular oder Fehlermeldung angezeigten Informationen, am einfachsten der Quellcode.
• Aufprall oder Schaden –Wie groß ist der Schaden, wenn die Sicherheitslücke aufgedeckt oder angegriffen wird? Der höchste Wert bedeutet einen vollständigen Systemabsturz und der niedrigste Wert bedeutet überhaupt nichts.

Das Hauptziel der OWASP Top 10 besteht darin, Entwickler, Designer, Manager, Architekten und Organisationen über die wichtigsten Sicherheitslücken zu informieren.

Die Top 10 Sicherheitslücken laut OWASP Top 10 sind:

SQL Injection

Beschreibung

Bei der Injektion handelt es sich um eine Sicherheitslücke, die es einem Angreifer ermöglicht, das Backend zu verändern SQL Anweisungen durch Manipulation der vom Benutzer bereitgestellten Daten.

Eine Injektion erfolgt, wenn die Benutzereingabe als Teil eines Befehls oder einer Abfrage an einen Interpreter gesendet wird und den Interpreter dazu verleitet, unbeabsichtigte Befehle auszuführen, und Zugriff auf nicht autorisierte Daten gewährt.

Der SQL-Befehl, der bei Ausführung durch eine Webanwendung auch die Back-End-Datenbank verfügbar machen kann.

Implikation

• Ein Angreifer kann schädliche Inhalte in die anfälligen Felder einschleusen.
• Sensible Daten wie Benutzernamen, Passwörter usw. können aus der Datenbank gelesen werden.
• Datenbankdaten können geändert werden (Einfügen/Aktualisieren/Löschen).
• Verwaltung OperaFunktionen können auf der Datenbank ausgeführt werden

Anfällige Objekte

• Eingabefelder
• URLs, die mit der Datenbank interagieren.

Beispiele:

• SQL-Injection auf der Anmeldeseite

Anmelden bei einer Anwendung ohne gültige Anmeldeinformationen.

Ein gültiger Benutzername ist verfügbar und ein Passwort ist nicht verfügbar.

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

Benutzername: sjones

Passwort: 1=1′ oder pass123

SQL-Abfrage erstellt und wie folgt an Interpreter gesendet

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

Empfehlungen

1. Whitelisting der Eingabefelder
2. Vermeiden Sie die Anzeige detaillierter Fehlermeldungen, die für einen Angreifer nützlich sind.

Cross Site Scripting

Beschreibung

Cross Site Scripting wird auch kurz als XSS bezeichnet.

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

Angreifer können XSS verwenden, um schädliche Skripte auf den Browsern der Benutzer, in diesem Fall der Opfer, 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 kapern, Websites verunstalten oder den Benutzer auf unerwünschte und bösartige Websites umleiten.

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

Implikation:

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

Anfällige Objekte

• Eingabefelder
• URLs

Beispiele

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

Wenn das obige Skript in einem Browser ausgeführt wird, wird ein Meldungsfeld angezeigt, wenn die Site für XSS anfällig ist.

Der schwerwiegendere Angriff kann erfolgen, wenn der Angreifer Sitzungscookies anzeigen oder speichern möchte.

2. http://demo.testfire.net/search.aspx?txtSearch <iframe> http://google.com Breite = 500 Höhe 500>

Wenn das obige Skript ausgeführt wird, lädt der Browser einen unsichtbaren Frame, der darauf verweist http://google.com.

Der Angriff kann schwerwiegend sein, indem ein bösartiges Skript im Browser ausgeführt wird.

Empfehlungen

1. Eingabefelder für die Whitelist
2. Eingabe-Ausgabe-Kodierung

Defekte Authentifizierung und Sitzungsverwaltung

Beschreibung

Die Websites erstellen normalerweise für jede gültige Sitzung ein Sitzungscookie und eine Sitzungs-ID. Diese Cookies enthalten vertrauliche Daten wie Benutzername, Passwort usw. Wenn die Sitzung entweder durch Abmelden oder abruptes Schließen des Browsers beendet wird, sollten diese Cookies für jede Sitzung ungültig gemacht werden Es sollte ein neues Cookie geben.

Wenn die Cookies nicht ungültig werden, bleiben die sensiblen Daten im System bestehen. Wenn beispielsweise ein Benutzer einen öffentlichen Computer (Cyber ​​Cafe) verwendet, werden die Cookies der anfälligen Website auf dem System gespeichert und einem Angreifer ausgesetzt. Nutzt ein Angreifer nach einiger Zeit denselben öffentlichen Computer, sind die sensiblen Daten gefährdet.

Auf die gleiche Weise schließt ein Benutzer, der einen öffentlichen Computer verwendet, den Browser abrupt, anstatt sich abzumelden. Ein Angreifer verwendet dasselbe System. Wenn er dieselbe anfällige Website durchsucht, wird die vorherige Sitzung des Opfers geöffnet. Der Angreifer kann tun und lassen, was er will: Profilinformationen, Kreditkarteninformationen usw. stehlen.

Es sollte eine Prüfung durchgeführt werden, um die Stärke der Authentifizierung und Sitzungsverwaltung zu ermitteln. Schlüssel, Sitzungstoken und Cookies sollten ordnungsgemäß implementiert werden, ohne Passwörter zu gefährden.

Anfällige Objekte

• Auf der URL offengelegte Sitzungs-IDs können zu Sitzungsfixierungsangriffen führen.
• Sitzungs-IDs sind vor und nach dem Abmelden und Anmelden gleich.
• Sitzungszeitüberschreitungen sind nicht korrekt implementiert.
• Die Anwendung weist jeder neuen Sitzung dieselbe Sitzungs-ID zu.
• Authentifizierte Teile der Anwendung werden durch SSL geschützt und Passwörter werden im Hash- oder verschlüsselten Format gespeichert.
• Die Sitzung kann von einem Benutzer mit geringen Berechtigungen wiederverwendet werden.

Implikation

• Durch Ausnutzung dieser Schwachstelle kann ein Angreifer eine Sitzung kapern und sich unbefugten Zugriff auf das System verschaffen, was die Offenlegung und Änderung nicht autorisierter Informationen ermöglicht.
• Die Sitzungen können mithilfe gestohlener Cookies oder mithilfe von XSS gehackt werden.

Beispiele

1. Die Flugreservierungsanwendung unterstützt das Umschreiben von URLs und fügt Sitzungs-IDs in die URL ein:http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Verkauf von Tickets auf die Malediven) Ein authentifizierter Benutzer der Site möchte seine Freunde über den Verkauf informieren und sendet eine E-Mail. Die Freunde erhalten die Sitzungs-ID und können dazu verwendet werden, unbefugte Änderungen vorzunehmen oder die gespeicherten Kreditkartendaten zu missbrauchen.
2. Eine Anwendung ist anfällig für XSS, wodurch ein Angreifer auf die Sitzungs-ID zugreifen und die Sitzung kapern kann.
3. Die Timeouts der Anwendungen sind nicht richtig eingestellt. Der Benutzer verwendet einen öffentlichen Computer und schließt den Browser, anstatt sich abzumelden und wegzugehen. Der Angreifer verwendet denselben Browser einige Zeit später und die Sitzung wird authentifiziert.

Empfehlungen

1. Alle Anforderungen an Authentifizierung und Sitzungsverwaltung sollten gemäß OWASP Application Security Verification Standard definiert werden.
2. Geben Sie niemals Anmeldeinformationen in URLs oder Protokollen preis.
3. Darüber hinaus sollten große Anstrengungen unternommen werden, um XSS-Fehler zu vermeiden, die zum Diebstahl von Sitzungs-IDs verwendet werden können.

Unsichere direkte Objektreferenzen

Beschreibung

Dies geschieht, wenn ein Entwickler einen Verweis auf ein internes Implementierungsobjekt, beispielsweise eine Datei, ein Verzeichnis oder einen Datenbankschlüssel, als URL oder als FORM-Parameter verfügbar macht. Der Angreifer kann diese Informationen verwenden, um auf andere Objekte zuzugreifen und einen zukünftigen Angriff zu starten, um auf die nicht autorisierten Daten zuzugreifen.

Implikation

• Mithilfe dieser Schwachstelle kann ein Angreifer auf nicht autorisierte interne Objekte zugreifen, Daten ändern oder die Anwendung kompromittieren.

Anfällige Objekte

• In der URL.

Beispiele:

Durch Ändern der „Benutzer-ID“ in der folgenden URL kann ein Angreifer die Informationen anderer Benutzer einsehen.

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

Ein Angreifer kann die Informationen anderer einsehen, indem er den Wert der Benutzer-ID ändert.

Empfehlungen:

1. Implementieren Sie Zugriffskontrollprüfungen.
2. Vermeiden Sie es, Objektverweise in URLs offenzulegen.
3. Überprüfen Sie die Berechtigung für alle Referenzobjekte.

Cross Site Request Forgery

Beschreibung

Bei Cross Site Request Forgery handelt es sich um eine gefälschte Anfrage, die von einer Cross-Site stammt.

Bei einem CSRF-Angriff handelt es sich um einen Angriff, der erfolgt, wenn eine bösartige Website, E-Mail oder ein bösartiges Programm den Browser eines Benutzers dazu veranlasst, eine unerwünschte Aktion auf einer vertrauenswürdigen Site auszuführen, für die der Benutzer aktuell authentifiziert ist.

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

Der Angreifer sendet einen Link an das Opfer, wenn der Benutzer auf die URL klickt, während er auf der ursprünglichen Website angemeldet ist. Die Daten werden von der Website gestohlen.

Implikation

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

Anfällige Objekte

• Benutzerprofilseite
• Formulare für Benutzerkonten
• Geschäftstransaktionsseite

Beispiele

Das Opfer ist mit gültigen Anmeldedaten auf einer Bank-Website angemeldet. Es erhält eine E-Mail von einem Angreifer mit dem Inhalt „Klicken Sie hier, um 1 $ für einen guten Zweck 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 erfasst diese Anfrage, erstellt die folgende Anfrage und bettet sie in eine Schaltfläche mit der Aufschrift „Ich unterstütze die Sache“ ein.

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

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

Software Empfehlungen

1. Fordern Sie die Anwesenheit des Benutzers bei der Durchführung sensibler Aktionen an.
2. Implementierung von Mechanismen wie CAPTCHA, erneute Authentifizierung und eindeutige Anforderungstoken.

Sicherheitskonfiguration

Beschreibung

Die Sicherheitskonfiguration muss für die Anwendung, Frameworks, Anwendungsserver, Webserver, Datenbankserver und Plattform definiert und bereitgestellt werden. Wenn diese ordnungsgemäß konfiguriert sind, kann ein Angreifer unbefugten Zugriff auf vertrauliche Daten oder Funktionen erhalten.

Manchmal führen solche Fehler zu einer vollständigen Systemkompromittierung. Auch die Aktualisierung der Software trägt zur Sicherheit bei.

Implikation

• Durch Ausnutzung dieser Schwachstelle kann der Angreifer die zugrunde liegende Technologie und Versionsinformationen des Anwendungsservers sowie Datenbankinformationen aufzählen und Informationen über die Anwendung erhalten, um weitere Angriffe zu vermeiden.

Anfällige Objekte

• URL
• Formularfelder
• Eingabefelder

Beispiele

1. Die Verwaltungskonsole des Anwendungsservers wird automatisch installiert und nicht entfernt. Standardkonten werden nicht geändert. Der Angreifer kann sich mit Standardpasswörtern anmelden und sich unbefugten Zugriff verschaffen.
2. Die Verzeichnisliste ist auf Ihrem Server nicht deaktiviert. Der Angreifer erkennt Verzeichnisse und kann diese einfach auflisten, um Dateien zu finden.

Empfehlungen

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

Unsicherer kryptografischer Speicher

Beschreibung

Unsichere kryptografische Speicherung ist eine häufige Schwachstelle, die auftritt, wenn sensible Daten nicht sicher gespeichert werden.

Zu den sensiblen Daten auf einer Website zählen die Benutzeranmeldeinformationen, Profilinformationen, Gesundheitsdaten, Kreditkarteninformationen usw.

Diese Daten werden in der Bewerbungsdatenbank gespeichert. Wenn diese Daten unsachgemäß und ohne Verschlüsselung oder Hashing* gespeichert werden, sind sie für Angreifer anfällig.

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

Implikation

• Durch Ausnutzung dieser Schwachstelle kann ein Angreifer solche schwach geschützten Daten stehlen oder verändern, um Identitätsdiebstahl, Kreditkartenbetrug oder andere Straftaten zu begehen.

Anfällige Objekte

• Anwendungsdatenbank.

Beispiele

In einer Bankanwendung verwendet die Passwortdatenbank ungesalzene Hashes *, um die Passwörter aller zu speichern. Ein SQL-Injection-Fehler ermöglicht es dem Angreifer, die Passwortdatei abzurufen. Alle ungesalzenen Hashes können in kürzester Zeit brutal erzwungen werden, wohingegen die gesalzenen Passwörter Tausende von Jahren dauern würden.

(*Ungesalzene Hashes – Salt sind zufällige Daten, die an die Originaldaten angehängt werden. Salt wird vor dem Hashing an das Passwort angehängt.)

Empfehlungen

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

Fehler beim Einschränken des URL-Zugriffs

Beschreibung

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

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

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

Implikation

• Durch die Ausnutzung dieser Sicherheitslücke kann ein Angreifer auf die nicht autorisierten URLs zugreifen, ohne sich bei der Anwendung anzumelden und die Sicherheitslücke auszunutzen. Ein Angreifer kann auf sensible Seiten zugreifen, Funktionen aufrufen und vertrauliche Informationen einsehen.

Gefährdete Objekte:

• URLs

Beispiele

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

http://www.vulnerablsite.com kann geändert werden als http://www.vulnerablesite.com/admin

Empfehlungen

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

Unzureichender Schutz der Transportschicht

Beschreibung

Befasst sich mit dem Informationsaustausch zwischen dem Benutzer (Client) und dem Server (Anwendung). Anwendungen übertragen häufig vertrauliche Informationen wie Authentifizierungsdetails, Kreditkarteninformationen und Sitzungstoken über ein Netzwerk.

Durch die Verwendung schwacher Algorithmen, abgelaufener bzw. ungültiger Zertifikate oder den Verzicht auf SSL kann die Kommunikation nicht vertrauenswürdigen Benutzern zugänglich gemacht werden, was zu einer Gefährdung einer Webanwendung und/oder zum Diebstahl vertraulicher Informationen führen kann.

Implikation

• Durch Ausnutzung dieser Web-Sicherheitslücke kann ein Angreifer die Anmeldeinformationen eines legitimen Benutzers ausspionieren und sich Zugriff auf die Anwendung verschaffen.
• Kann Kreditkarteninformationen stehlen.

Anfällige Objekte

• Über das Netzwerk gesendete Daten.

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. Bei einer Anwendung, die kein SSL verwendet, überwacht ein Angreifer einfach den Netzwerkverkehr und beobachtet ein authentifiziertes Sitzungscookie des Opfers. Ein Angreifer kann dieses Cookie stehlen und einen Man-in-the-Middle-Angriff durchführen.

Nicht validierte Weiterleitungen und Weiterleitungen

Beschreibung

Die Webanwendung verwendet wenige Methoden, um Benutzer für einen bestimmten Zweck auf andere Seiten umzuleiten und weiterzuleiten.

Wenn beim Weiterleiten auf andere Seiten keine ordnungsgemäße Validierung erfolgt, können Angreifer dies ausnutzen und Opfer auf Phishing- oder Malware-Websites umleiten oder Weiterleitungen verwenden, um auf nicht autorisierte Seiten zuzugreifen.

Implikation

• Ein Angreifer kann dem Benutzer eine URL senden, die eine echte URL enthält und an die eine verschlüsselte bösartige URL angehängt ist. Wenn ein Benutzer nur den echten Teil der vom Angreifer gesendeten URL sieht, kann er diese durchsuchen und möglicherweise zum Opfer werden.

Beispiele

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

Geändert in

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

Empfehlungen

1. Vermeiden Sie einfach die Verwendung von Um- und Weiterleitungen in der Anwendung. Bei Verwendung dürfen bei der Berechnung des Ziels keine Benutzerparameter verwendet werden.
2. Wenn die Zielparameter nicht vermieden werden können, stellen Sie sicher, dass der angegebene Wert gültig und für den Benutzer autorisiert ist.