Menü

SANS Top 20 Sicherheitslücken in Softwareanwendungen

  • Haupt
  • Andere
  • SANS Top 20 Sicherheitslücken in Softwareanwendungen

sans top 20 security vulnerabilities software applications

Versuchen Sie Unser Instrument, Um Probleme Zu Beseitigen

Lernen und verstehen Sie die 20 wichtigsten Sicherheitslücken von SANS in Softwareanwendungen anhand von Beispielen in diesem Lernprogramm:

Das Wort OHNE ist nicht nur ein gewöhnliches Wörterbuchwort, sondern es steht für SysAdmin , Prüfung , Netzwerk , und Sicherheit .

In diesem Tutorial lernen wir die 20 wichtigsten Sicherheitslücken von SANS kennen, die wir in Softwareprogrammen finden können, und was wir tun können, um diese zu verringern.

Sicherheitslücken in SANS

Was du lernen wirst:

Auswirkungen von SANs auf die Cyber ​​Security Community

Gemäß OHNE , das OHNE Das Institut wurde als Forschungs- und Bildungsorganisation gegründet. Die verschiedenen Sicherheitsprogramme sind sehr umfassend und wirken sich positiv auf über 165.000 Sicherheitsexperten weltweit aus.

Wir können zu Recht sagen, dass diese Art der Berichterstattung durch SANS und andere positive Bewertungen sie zur vertrauenswürdigsten und mit Abstand größten Organisation für InfoSec-Schulungen und verschiedene Sicherheitszertifizierungen weltweit macht.

Dieser Artikel konzentriert sich auf die 20 wichtigsten SANS-Fehler, die Ihre Software anfällig für Angriffe machen können, sowie auf einige der Sicherheitskontrollen, die Sie implementieren können, um diese Fehler zu vermeiden. Wir können zwar mehr als 20 finden, aber wir werden die Top 20 Schwachstellen diskutieren.

Liste der SANS Top 20 kritischen Sicherheitslücken in Software

  1. CWE-119 : Speicherpufferfehler
  2. CWE-79 : Cross-Site-Scripting
  3. CWE-20 : Nicht validierter Eingabefehler
  4. CWE-200 : Expositionsfehler bei sensiblen Informationen
  5. CWE-125 : Lesefehler außerhalb der Grenzen
  6. CWE-89 : SQL-Injektion
  7. CWE-416 : Fehler beim freien Speicher
  8. CWE-190 : Integer Overflow Error
  9. CWE-352 : Cross-Site Request Forgery
  10. CWE-22 : Verzeichnisdurchquerung
  11. CWE-78 : OS Command Injection
  12. CWE-787 : Schreibfehler außerhalb der Grenzen
  13. CWE-287 : Falscher Authentifizierungsfehler
  14. CWE-476 : Dereferenzierung des NULL-Zeigers
  15. CWE-732 : Falsche Berechtigungszuweisung
  16. CWE-434 : Uneingeschränktes Hochladen von Dateien
  17. CWE-611 : Offenlegung von Informationen durch XML-Entitäten
  18. CWE-94 : Code-Injektion
  19. CWE-798 : Fest codierter Zugriffsschlüssel
  20. CWE-400 : Unkontrollierter Ressourcenverbrauch

Was bedeutet der Begriff CWE?

Das Aufzählung der allgemeinen Schwächen (CWE) ist eine von der Community akzeptierte Liste von Software- und Hardware-Schwachstellen, denen für jede Schwachstelle ein Identifizierungscode zugewiesen ist. Ziel ist es, verschiedene Fehler in Software und Hardware zu identifizieren, um all diese Fehler beheben und mindern zu können.

Agile Scrum Methodik Interview Fragen Antworten

# 1) CWE-119: Speicherpufferfehler

Dieser Fehler tritt normalerweise in den Phasen Architektur und Design, Implementierung und Betrieb des SDLC auf.

Dieser Pufferüberlauf tritt auf, wenn ein Anwendungsprozess versucht, mehr Daten zu speichern, als er im Speicher speichern kann. Da die Puffer nur eine bestimmte Datenebene speichern können und diese Ebene erreicht und überschritten wird, fließen die Daten an einen anderen Speicherort, wodurch die bereits in diesem Puffer enthaltenen Daten beschädigt werden können.

Dieser Vorfall passiert manchmal versehentlich durch einen Programmierfehler, aber der Nacheffekt kann katastrophal sein, da dadurch Daten gelöscht, vertrauliche Informationen gestohlen und sogar die gesamte Anwendung aufgrund dieses Pufferüberlaufs abstürzen kann.

Das folgende Beispiel zeigt einen Puffer mit 8 Byte Speicher. Es wurde jedoch um 2 Byte übergelaufen, da mehr Daten zur Ausführung gesendet wurden.

Speicherpufferfehler

(Bild Quelle ))

# 2) CWE-79: Cross-Site-Scripting

Cross-Site Scripting (XSS) ist ein Injektionsangriff, der normalerweise auftritt, wenn ein böswilliger Akteur oder ein Angreifer böswilliges oder schädliches Skript in eine Webanwendung einfügt, das über die Webbrowser ausgeführt werden kann. Sobald das bösartige Skript seinen Weg in das gefährdete System gefunden hat, kann es verwendet werden, um verschiedene böswillige Aktivitäten auszuführen.

Einige der böswilligen Aktivitäten können in Form der Übertragung privater Informationen wie Cookies erfolgen, die die Sitzungsinformationen vom Computer des Opfers auf den Computer des Angreifers enthalten.

Cross-Site-Scripting-Vorkommen:

  • Wenn nicht validierte und nicht vertrauenswürdige Daten über die Webformularanforderung in eine Webanwendung eingegeben werden.
  • Wenn die Webanwendung sofort eine Webseite ausgibt, die diese schädlichen Daten enthält.
  • Während des Generierens einer Seite kann die Software nicht anhand der Daten validieren, die den Inhalt enthalten, der von einem Webbrowser wie HTML und JavaScript ausgeführt werden kann.
  • Das Opfer besucht unwissentlich die Seite, die über einen Webbrowser generiert wurde und die das schädliche Skript enthält, das durch die Verwendung der nicht vertrauenswürdigen Daten injiziert wurde.
  • Das schädliche Skript stammt von einer Seite, die vom Webserver des Angreifers gesendet wurde. Der gefährdete System-Webbrowser verarbeitet dann das schädliche Skript.
  • Diese Aktion verstößt gegen die Richtlinien des Webbrowsers für denselben Ursprung, wonach Skripte, die von einer Domäne stammen, keinen Zugriff auf Ressourcen haben oder Code in einer anderen Domäne außer ihrer eigenen Domäne ausführen dürfen.

Cross-Site-Scripting-Vorkommen

(Bild Quelle ))

# 3) CWE-20: Nicht validierter Eingabefehler

Die Anwendung empfängt Eingaben, überprüft die Eingabe jedoch nicht, ob sie alle erforderlichen Details enthält, damit sie zur Verarbeitung in das System aufgenommen werden kann.

Bei einer Bereinigung der Eingaben können potenziell gefährliche Eingaben überprüft werden, um sicherzustellen, dass die Eingaben sicher mit dem Quellcode verarbeitet werden können, oder wenn es sich um eine Eingabe handelt, die für die Kommunikation mit anderen Komponenten erforderlich ist.

Wenn solche Eingaben nicht ordnungsgemäß bereinigt oder validiert werden, kann ein Angreifer auf diese Weise eine böswillige Eingabe senden, die von der Hauptanwendung großzügig verarbeitet wird. Dies führt zu Änderungen im Kontrollfluss, zur willkürlichen Kontrolle einer Ressource oder zu willkürlichem Code Ausführung.

Die folgenden Bilder zeigen, dass eine gute Anwendung kein Skript oder Befehl als Eingabe akzeptieren sollte. Wenn solche Eingaben nicht ordnungsgemäß bereinigt werden, verarbeitet die Anwendung sie als gültige Anforderung.

Eingang

Nicht validierter Eingabefehler

(Bild Quelle ))

# 4) CWE-200: Expositionsfehler bei sensiblen Informationen

Dies geschieht, wenn die Anwendung wissentlich und unwissentlich vertrauliche und vertrauliche Informationen für einen Angreifer bereitstellt, der nicht über die Berechtigung zum Zugriff auf diese Informationen verfügt.

Unterschiedliche Fehler führen dazu, dass diese Informationen einem Angreifer ausgesetzt werden. Die Schwere dieses Fehlers hängt vom Kontext ab, in dem die Anwendung ausgeführt wird, von der Art der offenbarten vertraulichen Informationen und davon, was der Akteur aus den offengelegten Informationen gewinnen kann.

Im Folgenden finden Sie einige vertrauliche Informationen, die offengelegt werden könnten:

  • Persönliche Informationen wie persönliche Nachrichten, Finanzdaten, Gesundheitsdaten, geografischer Standort oder Kontaktdaten
  • Systemkonfigurationsdetails und Umgebung, beispielsweise, das Betriebssystem und die installierten Pakete
  • Geschäftsunterlagen und geistiges Eigentum
  • Details zur Netzwerkkonfiguration
  • Interner Anwendungsstatus
  • Metadaten wie die Nachrichtenkopfzeilen

Manchmal kann es bei unseren Anwendungen oder Websites zu technischen Problemen wie Datenbankverbindungsfehlern, Laufzeitfehlern und Netzwerkfehlern kommen.

Wenn solche Fehler während der Entwicklung nicht richtig behandelt werden, d. H. Wenn die Anwendung die Fehlermeldung anzeigt, kann sie Informationen für die Öffentlichkeit anzeigen, die ein Angreifer möglicherweise für böswillige Zwecke wie das folgende Bild verwenden kann.

Serverfehler

# 5) CWE-125: Lesefehler außerhalb der Grenzen

Dies tritt normalerweise auf, wenn die Anwendung Daten über die normale Ebene hinaus entweder bis zum Ende oder vor dem Beginn des Puffers liest. Dies gibt einem Angreifer unprivilegierten Zugriff, um vertrauliche Informationen von anderen Speicherorten zu lesen, was ebenfalls zu einem System- oder Anwendungsabsturz führen kann.

Ein Absturz wird sicherlich auftreten, wenn der Code Daten liest und denkt, dass ein Indikator vorhanden ist, der den Lesevorgang stoppt, wie ein NULL, der auf eine Zeichenfolge angewendet wird

Im folgenden Code ruft die Funktion einen Wert von einer Array-Indexposition ab, die wiederum der Eingabeparameter für die Funktion ist.

Lesefehler außerhalb der Grenzen

(Bild Quelle ))

Aus dem obigen Code können wir ersehen, dass die Funktion überprüft, ob der angegebene Array-Index kleiner als die maximale Länge des Arrays ist, aber den minimalen Wert nicht überprüft.

Diese Nichtvalidierung führt dazu, dass ein negativer Wert als Eingabearray-Index akzeptiert wird, was zu einem Lesevorgang außerhalb der Grenzen führt, der wiederum den Zugriff auf vertraulichen Speicher ermöglicht.

Der Eingabearray-Index muss überprüft werden, wenn er innerhalb des für das Array erforderlichen maximalen und minimalen Bereichs liegt.

Wenn Sie nun das folgende Beispiel überprüfen, werden Sie feststellen, dass die IF-Anweisung geändert werden muss, um eine Mindestbereichsüberprüfung einzuschließen.

Validierung des Mindestbereichs

# 6) CWE-89: SQL Injection

SQL-Injektion ist eine Form der Sicherheitslücke, bei der der Angreifer einen SQL-Code (Structured Query Language) in das Webform-Eingabefeld einfügt, um Zugriff auf Ressourcen zu erhalten oder Daten zu ändern, für die kein Zugriff berechtigt ist.

Diese Sicherheitsanfälligkeit kann während der Entwurfs-, Implementierungs- und Betriebsphase in die Anwendung eingeführt werden.

Mit dieser SQL-Abfrage wird eine nicht autorisierte Anforderung an die Datenbank für einige Informationen gesendet. Bei einem normalen Eingabevorgang wird ein Webformular zur Benutzerauthentifizierung verwendet. Wenn ein Benutzer seinen Namen und sein Kennwort in die Textfelder eingibt, werden diese Werte in eine SELECT-Abfrage eingefügt.

Wenn die Eingabewerte korrekt sind, erhält der Benutzer Zugriff auf die Anwendung oder Anforderung. Wenn die Werte jedoch falsch sind, wird der Zugriff verweigert.

Einige Webformulare verfügen heute nicht über Mechanismen zum Blockieren böswilliger Eingaben. Ein Angreifer kann die Eingabefelder verwenden, um böswillige Anforderungen an die Datenbank zu senden. Diese einzelne Anforderung kann ihnen Zugriff auf die gesamte Datenbank gewähren, die vertrauliche Informationen enthalten kann.

SQL-Injektion

# 7) CWE-416: Zuvor freigegebener Speicher

Dieses Problem wird durch die Referenzierung des Speichers nach dessen Freigabe verursacht, was zu einem schwerwiegenden Programmabsturz führen kann. Wenn Sie einen zuvor freigegebenen Speicher verwenden, kann dies nachteilige Folgen haben, z. B. eine Beschädigung gültiger Daten oder eine willkürliche Codeausführung, die vom Fehlerzeitpunkt abhängt.

Zwei häufige Ursachen sind:

  • Fehlerzustände innerhalb der Software und in einigen anderen Ausnahmefällen.
  • Keine Erklärung, welcher Teil des Programms den freien Speicher verursacht hat.

In diesem Fall wird der Speicher unmittelbar nach seiner Freigabe einem anderen Zeiger zugewiesen. Der vorherige Zeiger auf den freigegebenen Speicher wird erneut verwendet und zeigt jetzt irgendwo auf die neue Zuordnung. Wenn die Daten geändert werden, kann dies den verwendeten Speicher beschädigen und dazu führen, dass sich die Anwendung undefiniert verhält.

# 8) CWE-190: Integer Overflow Error

Wenn eine Berechnung von einer Anwendung verarbeitet wird und logisch angenommen wird, dass der resultierende Wert größer als der genaue Wert ist, tritt ein ganzzahliger Überlauf auf. Hier erhöht sich ein ganzzahliger Wert auf einen Wert, der nicht an einem Ort gespeichert werden kann.

In diesem Fall wird der Wert normalerweise umbrochen und wird zu einem sehr kleinen oder negativen Wert. Wenn die Umhüllung erwartet wird, ist dies in Ordnung. Wenn die Umhüllung unerwartet ist, kann dies jedoch Sicherheitsfolgen haben. Wenn dieses Szenario auftritt, kann es als kritisch bezeichnet werden, da das Ergebnis zum Verwalten von Schleifen, Sicherheitsentscheidungen, zum Zuweisen von Speicher und vielem mehr verwendet wird.

Diese Schwäche führt im Allgemeinen zu unberechenbarem Verhalten und kann zu Abstürzen führen. Wenn der Wert für Daten wichtiger ist als für den Datenfluss, kann eine einfache Datenbeschädigung auftreten. Wenn der Umlauf jedoch zu weiteren Bedingungen wie Pufferüberläufen führt, kann es zu einer Speicherbeschädigung kommen.

Dieses Problem kann Pufferüberläufe auslösen, mit denen ein Angreifer beliebigen Code ausführen kann. Dieser ganzzahlige Überlauffehler wird normalerweise während der Entwurfs- und Implementierungsphase des SDLC in das System eingeführt.

IntegerOverflow

# 9) CWE-352: Fälschung von standortübergreifenden Anfragen

In diesem Fall überprüft eine Webanwendung die HTTP-Anforderung nicht ausreichend, unabhängig davon, ob die Anforderung tatsächlich vom richtigen Benutzer stammt oder nicht. Die Webserver sind so konzipiert, dass sie alle Anfragen annehmen und eine Antwort darauf geben.

Nehmen wir an, ein Client sendet mehrere HTTP-Anforderungen innerhalb einer oder mehrerer Sitzungen. Für einen Webserver ist es sehr schwierig zu wissen, ob alle Anforderungen authentisch waren oder nicht, und sie werden normalerweise verarbeitet. Ein Angreifer kann einen Kunden dazu zwingen, eine speziell gestaltete Webseite zu besuchen, und kann nun einige Anforderungen wie Geldtransfer, Änderung seiner E-Mail-Adresse und vieles mehr ausführen.

Sofort hat ein Angreifer Zugriff und kann Daten stehlen und sogar Daten zerstören. Sie können ihren Zugriff jederzeit beibehalten und, wenn sie fertig sind, das Überwachungsprotokoll gefährden, um zukünftige Forensik zu verhindern, die ihren Exploit offenlegen könnte.

Das folgende Bild zeigt einen Angreifer, der einen Benutzer dazu veranlasst, Aktionen auszuführen, die er nicht ausführen möchte.

CrossSite

# 10) CWE-22: Verzeichnisdurchquerung

Directory Traversal oder File Path Traversal ist eine Sicherheitslücke im Web, die es einem Angreifer ermöglicht, beliebige Dateien auf dem Server zu lesen, auf dem derzeit eine Anwendung ausgeführt wird.

Diese Dateien können ein Anwendungscode, Anmeldeinformationen für Back-End-Systeme und die Betriebssystemdateien sein. In einem anderen Szenario kann ein Angreifer möglicherweise in diese beliebigen Dateien auf dem Server schreiben, um Anwendungsdaten oder -verhalten zu ändern. Auf diese Weise haben sie die vollständige Kontrolle über den Server.

Durchquerung

(Bild Quelle ))

# 11) CWE-78: OS-Befehlsinjektion

Es geht um die unsachgemäße Bereinigung spezieller Elemente, die zur Änderung des beabsichtigten Betriebssystembefehls führen können, der an eine nachgeschaltete Komponente gesendet wird. Ein Angreifer kann diese böswilligen Befehle auf einem Zielbetriebssystem ausführen und auf eine Umgebung zugreifen, in der er nicht lesen oder ändern sollte.

Dies würde es einem Angreifer ausnahmslos ermöglichen, gefährliche Befehle direkt im Betriebssystem auszuführen.

Immer wenn diese Sicherheitsanfälligkeit in einem privilegierten Programm auftritt, kann der Angreifer Befehle verwenden, die in der Umgebung zulässig sind, oder andere Befehle mit Berechtigungen aufrufen, über die der Angreifer nicht verfügt. Dies kann den Schaden erhöhen, der auftreten kann.

CommandInjection

# 12) CWE-787: Schreibfehler außerhalb der Grenzen

Dies geschieht, wenn die Anwendung Daten nach dem Ende oder vor dem Beginn des festgelegten Puffers schreibt.

In diesem Fall ist das Endergebnis normalerweise Datenbeschädigung, System- oder Anwendungsabsturz. Was die Anwendung tut, ist eine Art Zeigerarithmetik, die zum Verweisen auf einen Speicherort außerhalb der Puffergrenzen verwendet wird.

# 13) CWE-287: Falscher Authentifizierungsfehler

In diesem Fall behauptet ein Angreifer, eine gültige Identität zu haben, die Software konnte jedoch nicht überprüfen oder beweisen, dass die Behauptung korrekt ist.

Eine Software überprüft die Anmeldeinformationen eines Benutzers falsch. Infolgedessen kann ein Angreifer bestimmte Berechtigungen innerhalb der Anwendung erlangen oder vertrauliche Informationen offenlegen, die es ihm ermöglichen, auf vertrauliche Daten zuzugreifen und beliebigen Code auszuführen.

# 14) CWE-476: Dereferenzieren eines NULL-Zeigers

Das Dereferenzieren eines Nullzeigers erfolgt, wenn die Anwendung einen Zeiger dereferenziert, der ein gültiges Ergebnis zurückgeben sollte, stattdessen NULL zurückgibt und dies zu einem Absturz führt. Das Dereferenzieren eines Nullzeigers kann durch viele Fehler wie Rennbedingungen und einige Programmierfehler auftreten.

Die Prozesse, die mit Hilfe des NULL-Zeigers ausgeführt werden, führen normalerweise zu Fehlern, und die Möglichkeit, den Prozess auszuführen, ist sehr gering. Dies hilft Angreifern, schädlichen Code auszuführen.

Null Zeiger

(Bild Quelle ))

# 15) CWE-732: Falsche Berechtigungszuweisung

Diese Sicherheitsanfälligkeit tritt auf, wenn eine Anwendung einer sehr wichtigen und kritischen Ressource Berechtigungen so zuweist, dass die Ressource, auf die ein böswilliger Benutzer zugreifen kann, verfügbar gemacht wird.

Wenn Sie vielen Personen die Berechtigung für eine Ressource erteilen, kann dies dazu führen, dass vertrauliche Informationen von einem Angreifer angezeigt oder geändert werden. Wenn keine Überprüfungen gegen diese Art der Vorgehensweise bei der Zuweisung von Berechtigungen zu Ressourcen durchgeführt werden, kann dies zu einem sehr katastrophalen Ende führen, wenn eine Programmkonfiguration oder einige vertrauliche Daten in die falsche Hand geraten.

# 16) CWE-434: Uneingeschränktes Hochladen von Dateien

Diese Sicherheitsanfälligkeit tritt auf, wenn die Anwendung die Dateitypen vor dem Hochladen von Dateien in die Anwendung nicht überprüft. Diese Sicherheitsanfälligkeit ist sprachunabhängig, tritt jedoch normalerweise in Anwendungen auf, die in ASP- und PHP-Sprache geschrieben sind.

Ein gefährlicher Dateityp ist eine Datei, die automatisch in der Anwendungsumgebung verarbeitet werden kann.

Das folgende Programm zeigt einen Upload einer PHP-Datei. Der Dateityp wurde vor dem Hochladen in das Webroot-Verzeichnis nicht überprüft und validiert. Aufgrund dieser Schwachstelle kann ein Angreifer eine beliebige PHP-Datei hochladen und ausführen, indem er direkt auf die hochgeladene Datei zugreift.

Hochladen einer PHP-Datei

beliebige PHP-Datei

# 17) CWE-611: Offenlegung von Informationen durch XML-Entitäten

Wenn ein XML-Dokument zur Verarbeitung in eine Anwendung hochgeladen wird und dieses Dokument XML-Entitäten mit einer einheitlichen Ressourcen-ID enthält, die in ein anderes Dokument an einem anderen Speicherort als dem beabsichtigten Speicherort aufgelöst wird. Diese Anomalie kann dazu führen, dass die Anwendung falsche Dokumente an ihre Ausgabe anfügt.

Die XML-Dokumente enthalten manchmal eine DTD (Document Type Definition), mit der die XML-Entitäten und andere Funktionen definiert werden. Über die DTD kann die einheitliche Ressourcenkennung als eine Form der Substitutionszeichenfolge dienen. Der XML-Parser greift auf das zu, was in der einheitlichen Ressourcen-ID enthalten ist, und gibt diese Inhalte zur Ausführung wieder in das XML-Dokument ein.

InfoExposure

(Bild Quelle ))

# 18) CWE-94: Code-Injektion

Das Vorhandensein von Codesyntax in den Benutzerdaten erhöht die Möglichkeit des Angreifers, das geplante Steuerungsverhalten zu ändern und beliebigen Code auszuführen. Diese Sicherheitsanfälligkeit wird als 'Injection-Schwachstellen' bezeichnet. Diese Schwachstelle kann dazu führen, dass eine Datensteuerung vom Benutzer gesteuert wird.

Diese Sicherheitsanfälligkeit stellt ein Szenario dar, in dem Software nicht vertrauenswürdige Daten in den Code zulässt und keine Validierung von Sonderzeichen durchführt, die sowohl das Verhalten des Codesegments als auch die Syntax negativ beeinflussen können.

Kurz gesagt, ein Angreifer könnte beliebigen Code einfügen und innerhalb der Anwendung ausführen. Der folgende PHP-Code zeigt die Verwendung der Funktion eval () in nicht vertrauenswürdigen Daten. Im folgenden Code kann ein Angreifer den beliebigen Parameter „param“ in den Code eingeben, der dann in der Software ausgeführt wird.

Code-Injection

Das folgende Beispiel erklärt den Aufruf an die phpinfo () Funktion. Diese Sicherheitsanfälligkeit kann auch in anderen Fällen ausgenutzt werden, um über den system () -Aufruf beliebige Betriebssystembefehle auf der Zielsoftware auszuführen.

Rufen Sie die Funktion phpinfo () auf

# 19) CWE-798: Fest codierter Zugriffsschlüssel

Dies ist der Fall, wenn das Kennwort und der Zugriffsschlüssel direkt für eingehende Authentifizierungszwecke und ausgehende Kommunikation mit einigen externen Komponenten sowie zur Verschlüsselung interner Daten fest in der Anwendung fest codiert sind. Fest codierte Anmeldedaten verursachen normalerweise eine Sicherheitsanfälligkeit, die es einem Angreifer ermöglicht, die vom Software-Administrator konfigurierte Authentifizierung zu umgehen.

Dem Systemadministrator fällt es immer sehr schwer, diese Sicherheitsanfälligkeit zu erkennen und zu beheben.

Diese Schwäche hat zwei Hauptströme:

  • Eingehende : Die Anwendung enthält ein Authentifizierungssystem, das die Eingabeanmeldeinformationen anhand der fest codierten Details überprüft.
  • Ausgehend : Die Anwendung stellt eine Verbindung zu einem anderen System her und Details zum Herstellen einer Verbindung zum anderen System sind im System fest codiert.

Im eingehenden Stream wird immer ein Standardadministratorkonto erstellt, und die Anmeldeinformationen für den Zugriff darauf werden in der Anwendung fest codiert und diesem Standardadministratorkonto zugeordnet.

Die fest codierten Details sind normalerweise bei jeder Installation der Anwendung gleich und können von niemandem geändert oder deaktiviert werden. Selbst die Systemadministratoren haben kein Recht, außer sie können die Anwendung manuell ändern. Wenn das Passwort jemals der Öffentlichkeit zugänglich gemacht wird, kann ein Angreifer auf die gesamte Anwendung zugreifen und diese zu seinem eigenen Vorteil bearbeiten.

Da alle Installationen der Anwendung dasselbe Kennwort haben, selbst wenn sie in separaten Organisationen installiert werden, kann dies über alle Unternehmensgrenzen hinweg zu sehr massiven Angriffen führen. beispielsweise, Injizieren eines Wurms in die Anwendung, der sich ausbreitet.

Der ausgehende Stream gilt nur für Front-End-Systeme, die sich bei einem Back-End-Service authentifizieren. Für den Back-End-Dienst ist möglicherweise ein fester Code oder ein festes Kennwort erforderlich, das leicht erkannt werden kann. Der Programmierer codiert diese Back-End-Anmeldeinformationen einfach fest in die Front-End-Software. Jeder Benutzer dieser Anwendung kann möglicherweise das Kennwort extrahieren.

Jede clientseitige Software, in die das Kennwort und der Zugriffsschlüssel fest codiert sind, stellt normalerweise eine größere Bedrohung dar als diejenigen, die nicht fest codiert sind, da das Extrahieren eines Kennworts aus einer Binärdatei normalerweise sehr einfach durchzuführen ist.

# 20) CWE-400: Unkontrollierter Ressourcenverbrauch

Diese Sicherheitsanfälligkeit tritt auf, wenn die Anwendung die Zuordnung und Wartung einer begrenzten Ressource nicht ordnungsgemäß steuert. Auf diese Weise kann ein Angreifer die Menge der verbrauchten Ressourcen beeinflussen, was schließlich zur Erschöpfung der verfügbaren Ressourcen führt.

Ein Teil der begrenzten Ressourcen umfasst Speicher, Dateisystemspeicher, Datenbankverbindungspooleinträge und CPU.

Nehmen wir an, ein Angreifer kann die Zuweisung dieser begrenzten Ressourcen auslösen und die Anzahl oder Größe der Ressourcen wird nicht kontrolliert. Dann kann der Angreifer durch Denial-of-Service, der alle verfügbaren Ressourcen verbraucht, Chaos verursachen.

In diesem Fall wird verhindert, dass gültige Benutzer auf die Anwendung zugreifen, was sich ausnahmslos negativ auf die Umgebung auswirkt. Zum Beispiel, Wenn der Anwendungsspeicher einen Erschöpfungsangriff durchläuft, kann dies die gesamte Anwendung sowie das Host-Betriebssystem verlangsamen.

Die drei verschiedenen Fälle, die zur Erschöpfung der Ressourcen führen können, sind:

  • Mangel an Drosselung für die Anzahl der zugewiesenen Ressourcen
  • Verlust aller Verweise auf eine Ressource vor Erreichen der Abschaltphase
  • Fehler beim Schließen / Zurückgeben einer Ressource nach der Verarbeitung

Das Problem der Ressourcenerschöpfung ist normalerweise auf die fehlerhafte Implementierung der folgenden Szenarien zurückzuführen:

  • Fehlerbedingungen und andere außergewöhnliche Umstände.
  • Es gibt gemischte Reaktionen darüber, welcher Teil des Programms die Ressource freigibt.

Das folgende Beispiel zeigt die Art dieser Sicherheitsanfälligkeit und beschreibt Methoden, mit denen das Risiko gemindert werden kann.

Das folgende Beispiel erläutert die Sicherheitsanfälligkeit:

Unkontrollierter Ressourcenverbrauch

(Bild Quelle ))

Dieses Programm verfolgt nicht, wie viele Verbindungen hergestellt wurden, und begrenzt nicht die Anzahl der verfügbaren Verbindungen. Forking ist nur eine der Möglichkeiten, mit denen ein Angreifer dazu führt, dass dem System CPU, Prozesse oder Speicher ausgehen, indem eine große Anzahl von Verbindungen hergestellt wird.

Ein Angreifer nutzt alle verfügbaren Verbindungen, um zu verhindern, dass andere remote auf das System zugreifen.

Häufig gestellte Fragen

F # 1) Wofür steht SANS?

Antworten: SANS steht für SysAdmin, Audit, Network und Security.

F # 2) Tragen Sie einige Beispiele für Sicherheitslücken ein.

Antwort: Die Beispiele lauten wie folgt:

  • Sicherheitslücken in der Software
  • Sicherheitslücken in der Firewall
  • Netzwerkschwachstellen
  • Sicherheitslücken im Betriebssystem
  • Sicherheitslücken im Webserver
  • Sicherheitslücken in der Datenbank

F # 3) Was ist der Unterschied zwischen Bedrohungen und Schwachstellen?

Antworten: Bedrohung ist die Möglichkeit, eine böswillige oder unerwünschte Handlung auszuführen, um ein Computersystem oder eine Anwendung durch vorhandene Schwachstellen im System zu beschädigen. Beispiel: Ransomware.

Sicherheitslücken sind Schwachstellen in einem System, die einen unerwünschten oder nicht autorisierten Zugriff eines Angreifers hätten ermöglichen können, um den Schaden einer Organisation zu infiltrieren. Beispiel: Fehlkonfiguration der Firewall.

F # 4) Was sind die häufigsten Sicherheitslücken?

Antwort: Diese sind wie folgt:

  • SQL-Injektion
  • Cross-Site-Scripting
  • Sicherheitsfehlkonfiguration
  • Sensible Datenexposition
  • Unterbrochene Authentifizierung
  • Sitzungsverwaltung

Fazit

Diese SANS Top 20-Schwachstellenliste ist keine Regel oder Richtlinie, sondern eine Anleitung, die uns dabei hilft, Software-Schwachstellen zu vermeiden. Unabhängig davon, ob wir Entwickler oder Sicherheitsexperte sind, bleibt es uns nun überlassen, diesen Leitfaden zu befolgen, um Fehler zu vermeiden, die zu Schwachstellen in unserer Anwendung führen können, durch die ein Akteur eine Hintertür für die Ausführung einer böswilligen Handlung erstellen kann.

Literatur-Empfehlungen

^