Über welche häufigen Web-Exploits sollte ich Bescheid wissen?[geschlossen]
https://stackoverflow.com/questions/23102
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Was die Webprogrammierung angeht, bin ich noch ziemlich grün und habe die meiste Zeit mit Client-Anwendungen verbracht.Daher bin ich neugierig auf die häufigsten Exploits, vor denen ich auf meiner Website Angst haben/Testen sollte.
Andere Tipps
Ich poste das Kurzliste der OWASP Top 2007 hier, damit die Leute nicht zu einem anderen Link durchsehen müssen und für den Fall, dass die Quelle ausfällt.
Cross-Site-Scripting (XSS)
- XSS-Fehler treten immer dann auf, wenn eine Anwendung vom Benutzer bereitgestellte Daten an einen Webbrowser sendet, ohne diesen Inhalt zuvor zu validieren oder zu kodieren.XSS ermöglicht es Angreifern, Skripte im Browser des Opfers auszuführen, die Benutzersitzungen kapern, Websites verunstalten, möglicherweise Würmer einschleusen usw.
Einspritzfehler
- Injektionsfehler, insbesondere SQL-Injection, kommen in Webanwendungen häufig vor.Eine Injektion erfolgt, wenn vom Benutzer bereitgestellte Daten als Teil eines Befehls oder einer Abfrage an einen Interpreter gesendet werden.Die feindlichen Daten des Angreifers verleiten den Interpreter dazu, unbeabsichtigte Befehle auszuführen oder Daten zu ändern.
Schädliche Dateiausführung
- Code, der für Remote File Inclusion (RFI) anfällig ist, ermöglicht es Angreifern, feindlichen Code und Daten einzubinden, was zu verheerenden Angriffen wie einer vollständigen Serverkompromittierung führt.Schädliche Dateiausführungsangriffe betreffen PHP, XML und alle Frameworks, die Dateinamen oder Dateien von Benutzern akzeptieren.
Unsichere direkte Objektreferenz
- Ein direkter Objektverweis liegt vor, wenn ein Entwickler einen Verweis auf ein internes Implementierungsobjekt, beispielsweise eine Datei, ein Verzeichnis, einen Datenbankeintrag oder einen Schlüssel, als URL oder Formularparameter verfügbar macht.Angreifer können diese Referenzen manipulieren, um unbefugt auf andere Objekte zuzugreifen.
Cross-Site-Request-Forgery (CSRF)
- Ein CSRF-Angriff zwingt den Browser eines angemeldeten Opfers dazu, eine vorab authentifizierte Anfrage an eine anfällige Webanwendung zu senden, wodurch der Browser des Opfers dann gezwungen wird, eine feindliche Aktion zugunsten des Angreifers auszuführen.CSRF kann genauso mächtig sein wie die Webanwendung, die es angreift.
Informationslecks und unsachgemäße Fehlerbehandlung
- Anwendungen können durch eine Vielzahl von Anwendungsproblemen unbeabsichtigt Informationen über ihre Konfiguration und interne Funktionsweise preisgeben oder den Datenschutz verletzen.Angreifer nutzen diese Schwachstelle, um sensible Daten zu stehlen oder schwerwiegendere Angriffe durchzuführen.
Defekte Authentifizierung und Sitzungsverwaltung
- Kontoanmeldeinformationen und Sitzungstoken sind häufig nicht ordnungsgemäß geschützt.Angreifer kompromittieren Passwörter, Schlüssel oder Authentifizierungstoken, um die Identität anderer Benutzer anzunehmen.
Unsicherer kryptografischer Speicher
- Webanwendungen nutzen 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 zu begehen.
Unsichere Kommunikation
- Anwendungen versäumen es häufig, den Netzwerkverkehr zu verschlüsseln, wenn dies zum Schutz sensibler Kommunikation erforderlich ist.
Fehler beim Einschränken des URL-Zugriffs
- Häufig schützt eine Anwendung nur sensible Funktionen, indem sie die Anzeige von Links oder URLs für nicht autorisierte Benutzer verhindert.Angreifer können diese Schwachstelle ausnutzen, um auf nicht autorisierte Vorgänge zuzugreifen und diese auszuführen, indem sie direkt auf diese URLs zugreifen.
Das Open Web Application Security Project
-Adam
Diese drei sind die wichtigsten:
Jeder wird „SQL-Injection“ sagen, weil es sich um die Sicherheitslücke handelt, die am gruseligsten klingt und am einfachsten zu verstehen ist.Cross-Site Scripting (XSS) kommt an zweiter Stelle, weil es auch leicht zu verstehen ist.„Schlechte Eingabevalidierung“ ist keine Schwachstelle, sondern vielmehr eine Bewertung einer bewährten Sicherheitsmethode.
Versuchen wir es aus einer anderen Perspektive.Hier sind Funktionen, die Sie bei der Implementierung in einer Webanwendung wahrscheinlich durcheinander bringen werden:
Dynamisches SQL (z. B. UI-Abfrage-Builder).Mittlerweile wissen Sie wahrscheinlich, dass die einzige zuverlässig sichere Möglichkeit, 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.Ich sehe, dass Web-Apps am häufigsten gegen diese Regel verstoßen, wenn es sich bei der böswilligen Eingabe nicht um einen offensichtlichen Parameter (wie einen Namen), sondern um ein Abfrageattribut handelt.Ein offensichtliches Beispiel sind die iTunes-ähnlichen „Smart Playlist“-Abfrageersteller, die man auf Suchseiten sieht, wo Dinge wie Where-Klausel-Operatoren direkt an das Backend übergeben werden.Ein weiterer toller Stein zum Umdrehen sind Tabellenspaltensortierungen, bei denen Dinge wie DESC in HTTP-Parametern angezeigt werden.
Datei-Upload.Das Hochladen von Dateien bringt die Leute durcheinander, weil Dateipfadnamen verdächtig wie URL-Pfadnamen aussehen und weil Webserver es einfach machen, den „Download“-Teil zu implementieren, indem sie URLs einfach auf Verzeichnisse im Dateisystem richten.7 von 10 von uns getesteten Upload-Handlern ermöglichen Angreifern den Zugriff auf beliebige Dateien auf dem Server, da die App-Entwickler davon ausgegangen sind, dass für den Dateisystemaufruf „open()“ dieselben Berechtigungen gelten wie für Abfragen.
Passwortspeicherung.Wenn Ihre Anwendung mir mein Rohpasswort per E-Mail zurückschicken kann, wenn ich es verliere, scheitern Sie.Es gibt eine einzige sichere und zuverlässige Lösung für die Passwortspeicherung: bcrypt;Wenn Sie PHP verwenden, möchten Sie wahrscheinlich PHPpass.
Zufallszahlengenerierung.Ein klassischer Angriff auf Web-Apps:Das Passwort eines anderen Benutzers zurücksetzen, und da die App die Funktion „rand()“ des Systems verwendet, die nicht kryptosicher ist, ist das Passwort vorhersehbar.Dies gilt auch überall dort, wo Sie Kryptografie betreiben.Was Sie übrigens nicht tun sollten:Wenn Sie sich irgendwo auf Krypto verlassen, sind Sie höchstwahrscheinlich anfällig.
Dynamische Ausgabe.Die Leute vertrauen zu sehr auf die Eingabevalidierung.Ihre Chancen, Benutzereingaben von allen möglichen Metazeichen zu bereinigen, sind gering, insbesondere in der realen Welt, wo Metazeichen notwendige Bestandteile der Benutzereingabe sind.Ein viel besserer Ansatz besteht darin, ein konsistentes System zum Filtern von Datenbankausgaben und deren Umwandlung in HTML-Entitäten wie „quot“, „gt“ und „lt“ zu haben.Rails erledigt dies automatisch für Sie.
Email.Viele Anwendungen implementieren eine Art Funktion für ausgehende E-Mails, die es einem Angreifer ermöglicht, entweder ein anonymes Konto zu erstellen oder überhaupt kein Konto zu verwenden, um vom Angreifer kontrollierte E-Mails an beliebige E-Mail-Adressen zu senden.
Abgesehen von diesen Funktionen besteht der Fehler Nr. 1, den Sie in Ihrer Anwendung wahrscheinlich machen, darin, irgendwo eine Datenbankzeilen-ID offenzulegen, sodass Benutzer X Daten für Benutzer Y sehen kann, indem er einfach eine Zahl von „5“ in „6“ ändert.
bool UserCredentialsOK(User user)
{
if (user.Name == "modesty")
return false;
else
// perform other checks
}
SQL-INJECTION-ANGRIFFE.Sie sind leicht zu vermeiden, aber allzu häufig.
NIEMALS (habe ich „jemals“ erwähnt?) Vertrauen Sie den Benutzerinformationen, die Ihnen von Formularelementen übermittelt werden.Wenn Ihre Daten vor der Weitergabe an andere logische Schichten Ihrer Anwendung nicht überprüft werden, können Sie die Schlüssel zu Ihrer Website genauso gut einem Fremden auf der Straße geben.
Sie erwähnen nicht, auf welcher Plattform Sie sich befinden, aber wenn Sie ASP.NET verwenden, beginnen Sie mit dem guten alten Scott Guthrie und seinem Artikel „Tipp/Trick:Schutz vor SQL-Injection-Angriffen".
Anschließend müssen Sie überlegen, welche Art von Daten Sie den Benutzern erlauben, in Ihre Datenbank einzusenden und diese gegebenenfalls zu verlassen.Wenn Sie zulassen, dass HTML eingefügt und später angezeigt wird, besteht die Gefahr von Cross-Site-Scripting-Angriffen (bekannt als XSS).
Das sind die beiden, die mir in den Sinn kommen, aber unser ganz persönlicher Jeff Atwood hatte einen guten Artikel dazu Coding-Horror mit einer Rezension des Buches“19 Todsünden der Softwaresicherheit".
Die meisten Leute hier haben SQL Injection und XSS erwähnt So'ne Art Richtig, aber lassen Sie sich nicht täuschen – das Wichtigste, worüber Sie sich als Webentwickler Gedanken machen müssen, ist die Eingabevalidierung, aus der XSS und SQL-Injection stammen.
Wenn Sie beispielsweise ein Formularfeld haben, das immer nur Ganzzahlen akzeptiert, stellen Sie sicher, dass Sie sowohl auf der Client- als auch auf der Serverseite etwas implementieren, um die Daten zu bereinigen.
Überprüfen Sie alle Eingabedaten noch einmal, insbesondere wenn sie in einer SQL-Abfrage enden.Ich schlage vor, eine Escaper-Funktion zu erstellen und sie um alles zu wickeln, was in eine Abfrage eingeht.Zum Beispiel:
$query = "SELECT field1, field2 FROM table1 WHERE field1 = '" . myescapefunc($userinput) . "'";
Wenn Sie vom Benutzer eingegebene Informationen auf einer Webseite anzeigen möchten, stellen Sie außerdem sicher, dass Sie alle <script>-Tags oder alles andere entfernt haben, was zur Ausführung von Javascript führen könnte (z. B. onLoad= onMouseOver= usw.).Attribute auf Tags).
Dies ist auch eine kurze Präsentation zum Thema Sicherheit von einem der Hauptentwickler von WordPress.
Es deckt alle grundlegenden Sicherheitsprobleme in Web-Apps ab.
Am häufigsten sind vermutlich Database-Injection-Angriffe und Cross-Site-Scripting-Angriffe;vor allem, weil diese am einfachsten zu bewerkstelligen sind (das liegt wahrscheinlich daran, dass Programmierer bei ihnen am faulsten sind).
Sie können sogar auf dieser Website sehen, dass die schädlichsten Dinge, nach denen Sie suchen, die Code-Injektion in Ihre Anwendung sind, daher sind XSS (Cross Site Scripting) und SQL-Injection (@Patricks Vorschläge) Ihre größten Sorgen.Grundsätzlich möchten Sie sicherstellen, dass Ihre Anwendung, wenn sie es einem Benutzer erlaubt, beliebigen Code einzufügen, reguliert und getestet wird, um sicherzustellen, dass nur Dinge, von denen Sie sicher sind, dass Sie sie zulassen möchten (ein HTML-Link, ein Bild usw ) werden übergeben und nichts anderes wird ausgeführt.
SQL-Injektion.Cross-Site-Scripting.
Die Verwendung gespeicherter Prozeduren und/oder parametrisierter Abfragen trägt wesentlich dazu bei, Sie vor SQL-Injection zu schützen.Auch tun NICHT Lassen Sie Ihre Web-App als SA oder DBO auf die Datenbank zugreifen. Richten Sie ein Standardbenutzerkonto ein und legen Sie die Berechtigungen fest.
AS für XSS (Cross-Site-Scripting) ASP.NET verfügt über einige integrierte Schutzfunktionen.Am besten filtern Sie die Eingabe mithilfe von Validierungskontrollen und Regex.
Ich bin kein Experte, aber nach dem, was ich bisher gelernt habe, lautet die goldene Regel, keinen Benutzerdaten (GET, POST, COOKIE) zu vertrauen.Häufige Angriffsarten und wie Sie sich retten können:
- SQL-Injection-Angriff:Verwenden Sie vorbereitete Abfragen
- Cross-Site-Scripting:Senden Sie keine Benutzerdaten an den Browser, ohne sie vorher zu filtern/zu maskieren.Dazu gehören auch in der Datenbank gespeicherte Benutzerdaten, die ursprünglich von Benutzern stammen.
