Bezüglich Webprogrammierung bin ich noch ziemlich unerfahren. Die meiste Zeit habe ich mit Client-Anwendungen verbracht. Daher bin ich neugierig, welche gängigen Angriffe ich bei meiner Website fürchten/testen sollte.
Antworten
Zu viele Anzeigen?Ich poste die abgekürzte Liste der OWASP Top 2007 hier, damit Leute nicht durch einen anderen Link suchen müssen und falls die Quelle offline geht.
Cross Site Scripting (XSS)
- XSS-Schwachstellen treten auf, wenn eine Anwendung Benutzerdaten annimmt und sie an einen Webbrowser sendet, ohne den Inhalt zuvor zu validieren oder zu kodieren. XSS ermöglicht es Angreifern, Skripte im Browser des Opfers auszuführen, die Benutzersitzungen kapern, Webseiten verunstalten oder möglicherweise Würmer einführen können.
Injektionsfehler
- Injektionsfehler, insbesondere SQL-Injektionen, sind häufig in Webanwendungen. Eine Injektion tritt auf, wenn Benutzerdaten als Teil eines Befehls oder einer Abfrage an einen Interpreter gesendet werden. Die feindlichen Daten des Angreifers führen dazu, dass der Interpreter unbeabsichtigte Befehle ausführt oder Daten ändert.
Bösartige Dateiausführung
- Code, der anfällig für Remote-Dateieinschlüsse (RFI) ist, ermöglicht es Angreifern, feindlichen Code und Daten einzufügen und so verheerende Angriffe zu starten, wie z.B. die vollständige Kompromittierung des Servers. Bösartige Dateiausführungsangriffe betreffen PHP, XML und jedes Framework, das Dateinamen oder Dateien von Benutzern akzeptiert.
Unsicherer direkter Objektverweis
- Ein direkter Objektverweis tritt auf, wenn ein Entwickler einen Verweis auf ein internes Implementierungsobjekt, wie eine Datei, ein Verzeichnis, einen Datenbankeintrag oder einen Schlüssel, als URL oder Formparameter freigibt. Angreifer können diese Verweise manipulieren, um auf andere Objekte zuzugreifen, ohne autorisiert zu sein.
Cross Site Request Forgery (CSRF)
- Ein CSRF-Angriff zwingt den Browser eines eingeloggten Opfers dazu, eine vorauthentifizierte Anfrage an eine anfällige Webanwendung zu senden, die dann den Browser des Opfers dazu zwingt, eine feindliche Aktion zugunsten des Angreifers auszuführen. CSRF kann genauso mächtig sein wie die Webanwendung, die er angreift.
Informationsleckage und unsachgemäße Fehlerbehandlung
- Anwendungen können unbeabsichtigt Informationen über ihre Konfiguration, interne Abläufe oder die Privatsphäre durch verschiedene Anwendungsprobleme preisgeben. Angreifer nutzen diese Schwäche, um sensible Daten zu stehlen oder schwerwiegendere Angriffe durchzuführen.
Fehlerhafte Authentifizierung und Sitzungsverwaltung
- Kontoanmeldeinformationen und Sitzungstokens sind oft nicht ordnungsgemäß geschützt. Angreifer können Passwörter, Schlüssel oder Authentifizierungstokens kompromittieren, um die Identität anderer Benutzer anzunehmen.
Unsichere kryptografische Speicherung
- Webanwendungen verwenden kryptografische Funktionen selten ordnungsgemäß, um Daten und Anmeldeinformationen zu schützen. Angreifer nutzen schwach geschützte Daten, um Identitätsdiebstahl und andere Straftaten wie Kreditkartenbetrug durchzuführen.
Unsichere Kommunikation
- Anwendungen versäumen es häufig, Netzwerkdaten zu verschlüsseln, wenn es erforderlich ist, sensitive Kommunikation zu schützen.
Fehlerhafte Einschränkung des URL-Zugriffs
- Oft schützt eine Anwendung sensible Funktionalitäten nur, indem sie die Anzeige von Links oder URLs für nicht autorisierte Benutzer verhindert. Angreifer können diese Schwäche nutzen, um auf diese URLs direkt zuzugreifen und nicht autorisierte Operationen auszuführen.
Das Open Web Application Security Project
-Adam
Jeder wird "SQL-Injection" sagen, weil es die beängstigendste Schwachstelle klingt und am einfachsten zu verstehen ist. Cross-Site-Scripting (XSS) wird an zweiter Stelle stehen, weil es auch einfach zu verstehen ist. "Schlechte Eingabeüberprüfung" ist keine Schwachstelle, sondern vielmehr eine Bewertung einer bewährten Sicherheitspraxis.
Lassen Sie uns dies aus einer anderen Perspektive betrachten. Hier sind Funktionen, die, wenn sie in einer Webanwendung implementiert werden, wahrscheinlich zu Problemen führen:
-
Dynamisches SQL (zum Beispiel UI-Abfragegeneratoren). Inzwischen wissen Sie wahrscheinlich, dass der einzige zuverlässig sichere Weg, SQL in einer Web-App zu verwenden, darin besteht, parametrisierte Abfragen zu verwenden, bei denen Sie jeden Parameter in der Abfrage explizit an eine Variable binden. Die Stellen, an denen ich sehe, dass Webanwendungen am häufigsten gegen diese Regel verstoßen, sind, wenn die bösartige Eingabe kein offensichtlicher Parameter ist (wie ein Name), sondern ein Abfrageattribut. Ein offensichtliches Beispiel sind die iTunes-ähnlichen "Smart Playlist"-Abfragegeneratoren, die Sie auf Suchseiten sehen, wo Dinge wie Where-Clause-Operatoren direkt an das Backend übergeben werden. Ein weiterer guter Angriffspunkt sind Tabellenspalten-Sortierungen, wo Sie Dinge wie DESC in den HTTP-Parametern sehen.
-
Datei-Upload. Datei-Upload bringt Menschen durcheinander, weil Dateipfade verdächtig nach URL-Pfaden aussehen und weil Webserver es einfach machen, den "Download"-Teil nur durch Ausrichten von URLs auf Verzeichnisse im Dateisystem zu implementieren. 7 von 10 von uns getesteten Upload-Handler ermöglichen Angreifern den Zugriff auf beliebige Dateien auf dem Server, weil die App-Entwickler davon ausgingen, dass die gleichen Berechtigungen für den Dateisystem-"Open()"-Aufruf gelten, wie für Abfragen.
-
Passwortspeicherung. Wenn Ihre Anwendung mir mein Rohpasswort per E-Mail zusenden kann, haben Sie versagt. Es gibt eine einzige sichere zuverlässige Antwort für die Passwortspeicherung, nämlich bcrypt; wenn Sie PHP verwenden, möchten Sie wahrscheinlich PHPpass.
-
Zufallszahlenerzeugung. Ein klassischer Angriff auf Webanwendungen: einen anderen Benutzer zurücksetzen, und, weil die App die systemeigene "rand()"-Funktion verwendet, die nicht kryptostark ist, ist das Passwort vorhersehbar. Dies gilt auch überall dort, wo Sie Kryptographie betreiben. Was Sie übrigens nicht tun sollten: Wenn Sie überall auf Krypto angewiesen sind, sind Sie höchstwahrscheinlich verwundbar.
-
Dynamische Ausgabe. Die Leute setzen zu viel Vertrauen in die Eingabeüberprüfung. Ihre Chancen, Benutzereingaben von allen möglichen Meta-Zeichen zu bereinigen, insbesondere in der realen Welt, wo Meta-Zeichen notwendige Bestandteile von Benutzereingaben sind, sind gering. Ein viel besseres Vorgehen ist ein konsistentes Regime zur Filtrierung von Datenbankausgaben und zur Umwandlung in HTML-Entitäten wie quot, gt und lt. Rails wird dies automatisch für Sie erledigen.
-
E-Mail. Viele Anwendungen implementieren eine Art ausgehende E-Mail-Fähigkeit, die einem Angreifer entweder ermöglicht, ein anonymes Konto zu erstellen oder überhaupt kein Konto zu verwenden, um von einem beliebigen E-Mail-Adressen aus E-Mails zu versenden.
Jenseits dieser Funktionen ist der größte Fehler, den Sie in Ihrer Anwendung wahrscheinlich machen werden, eine Datenbank-Zeilen-ID an einer Stelle freizulegen, sodass Benutzer X Daten für Benutzer Y sehen können, indem sie eine Zahl von "5" auf "6" ändern.
- See previous answers
- Weitere Antworten anzeigen