Ist die Verhinderung von XSS ein guter Grund, POST über GET für Web-Apps zu bevorzugen?

Question

Der aktuelle Trend in Web-Anwendungen scheint zu GET-Anforderungen für alles zu verwenden. Insbesondere die Verwendung von RESTful-URLs, die einen Dienst, einen Befehl und seine Parameter beschreiben. Vor einigen Monaten hat Jeff Atwood über die Gefahren von XSS berichtet. Er demonstrierte, wie es sogar zu einer XSS-Sicherheitslücke kommen kann, wenn Nutzern erlaubt wird, etwas scheinbar harmloses wie ein "img" -Tag auf Ihrer Website zu veröffentlichen. Der Grund dafür ist, dass der Browser einfach blind die URL im "src" -Attribut anfordert, was etwas nur Ärger machen könnte, wie das Abmelden des Benutzers, oder etwas viel Bedrohlicheres.

Als ich vor zehn Jahren mit der Webentwicklung anfing, war die gängige Meinung, POST über GET für Formulare zu bevorzugen und die Anwendung auf der Serverseite aus genau diesem Grund POST zur Formularübermittlung zu erfordern. Browser senden GET-Anfragen die ganze Zeit (wie in dem oben erwähnten "img" -Tag-Beispiel), aber sie senden nur POST-Anfragen unter bestimmten Umständen (insbesondere Formulare mit dem Attribut "method", das auf POST gesetzt ist). Durch die Anforderung von POST scheint es, dass Sie ein großes Segment von XSS-Angriffen eliminieren können. Ist das ein guter Grund, sie zu bevorzugen?

Answer 1

Seit wann REST implizieren mit GET für alles? Zuletzt habe ich nachgesehen, es bedeutete das genaue Gegenteil. Verwenden Sie GET-Anfragen für bekommen eine Ressource, und POST für Beitrag einen auf den Server.

Einer der Schlüsselpunkte von REST ist die Verwendung der HTTP-Anforderungen, die dem Vorgang, den Sie versuchen, am besten entsprechen.GET sollte für die Zwecke verwendet werden, für die es vorgesehen ist: Daten vom Server abrufen, ohne den Status auf dem Server zu ändern. Es sollte nicht zum Aktualisieren von Ressourcen auf dem Server verwendet werden. POST oder PUT sind dafür ausgelegt.

Die Verwendung von HTTP, so wie es verwendet werden sollte, hilft dabei, einige (aber bei weitem nicht alle) XSS-Angriffe zu vermeiden, und Browser verhalten sich auch viel besser bei der Kommunikation mit Ihrer Site. Der Browser erwartet, dass GET-Anfragen sicher wiederholt werden können, ohne dass eine Bestätigung vom Benutzer erforderlich ist. Dies ist beispielsweise der Fall, wenn Sie die Seite aktualisieren oder die Zurück-/Vorwärts-Tasten verwenden. Es wird erwartet, dass POST den Status auf dem Server ändert. Daher fordert der Browser normalerweise eine Bestätigung an, bevor eine POST-Anfrage wiederholt wird.

Answer 2

Du verwechselst Vanille-Ajax-Aufrufe mit REST Anrufe.

Vanilla Ajax ruft Verwendung GET oder POST, und es ist ganz Ihnen überlassen, wie sie zu handhaben.

REST verwendet die Verben GET, HEAD, POST, PUT, DELETE

HTTP VERB REST/CRUD 
POST   Create 
GET   Read 
PUT   Update, Create 
DELETE  Delete 

Sie wollen POST über GET verwenden, wenn Sie sich Sorgen um CSRF sind, nicht XSS.

Eine gute Daumenregel ist immer POST verwenden und verwenden Sie nur, wenn Sie absolut sicher sind Sie, dass die Daten mit anderen Websites teilen möchten oder die Daten nicht empfindlich.

Aber nur allein mit POST erhalten Sie 100% nicht schützen.

Beide XSS und CSRF sind sehr wichtig, und Sie sollten Ihre App für beide überprüfen, aber sie sind zwei sehr unterschiedliche Bestien.

CSRF:

Wikipedia

OWASP

XSS:

OWASP

Answer 3

Ich glaube, du bist REST Missverständnis. Der Punkt ist nicht, GET über POST zu bevorzugen, der Punkt besteht darin, GET zu verwenden, wo die Anforderung die Daten auf dem Server nicht beeinflusst, und POST, wo Daten geändert werden. Bei REST geht es darum, die verfügbaren HTTP-Verben richtig zu verwenden.

Zum Beispiel wird ein Suchformular verwenden, oft bekommen, während ein X Formular erstellen wird in der Regel POST verwenden.

Answer 4

Es gibt Situationen, in denen Sie POST anstatt GET verwenden sollten, aber das Vermeiden von XSS ist nicht einer von ihnen. Vielleicht denken Sie an XSRF, aber selbst dann, wenn Sie POST benötigen, schützt Sie das nicht wirklich. Und in der Tat würden REST-Befürworter tatsächlich sagen, dass Sie nicht nur GET verwenden sollten, sondern dass Sie POST, PUT und DELETE für die entsprechenden "CRUD" -Operationen verwenden sollten.

Um zu vermeiden, XSS, Flucht und/oder scheuern Inhalt von Benutzern entsprechend.

Um zu vermeiden, XSRF, benötigen geheime Tokens auf alle Nebeneffekte verursachen Betrieb, der potenziell gefährlich ist. (Übrigens: Vermeiden Sie die Verwendung von GET-Anforderungen beim Übergeben geheimer Token, da dies dazu führen kann, dass sie in Referrern eindringen.)

Verwenden Sie GET für schreibgeschützt Anforderungen wann immer möglich. (Ziemlich oft, wenn die Abfrage in eine URL passen kann)

Verwenden Sie POST (oder PUT oder DELETE, wenn machbar und angemessen) für schreiben Anfragen.

Answer 5

XSS wird nicht gestoppt; XSS ist, wenn ein Benutzer Sie dazu bringt, sein Skript irgendwie an andere Benutzer auszugeben. Das erfordert Filterung.

XSRF wird auch nicht gestoppt; Es erfordert das Hinzufügen von Einmal-Tokens irgendeiner Art, um sicherzustellen, dass jemand nur dann auf Ihre Site zugreifen kann, wenn sie tatsächlich darauf ist (anstatt von einem eingebetteten Iframe oder Ähnlichem zu posten).

POST vs GET verhindert jedoch, dass Webbeschleuniger und Scraper (z. B. Google Bot) Ihre Site ändern. Sie gehen nur zu GET-Links, und wenn Sie also Ihre Website nicht löschen lassen möchten (a la Daily WTF schreibt dazu), stellen Sie sicher, dass "dieses Element löschen" kein GET ist. ;-)

Üblicher ist es eine Frage der Semantik und Formulargröße. GET posten kein Formular und sind daher auf alles beschränkt, was Sie in eine URL eingeben können, was nicht viel ist. POST erlaubt beliebige Datenmengen. PUT und DELETE sind mehr für Semantik; Sie können beide auch über POST erfolgen.

Answer 6

Die bereits gegebenen Antworten beantworten wirklich Ihre Frage - nein, die Verhinderung von XSS ist kein gültiger Grund, POST über GET zu bevorzugen. Wenn Sie dies jedoch demonstrieren möchten, sehen Sie sich Tools wie WebScarab oder Tamper Data an, die sehr nützlich sind, um die Schwachstellen Ihrer eigenen Website zu testen. Es ist genauso einfach, Code in eine POST-Anforderung wie in ein GET zu injizieren. Aber auch ohne diese Tools ist zu beachten, dass es einfach ist, Parms mit einem GET zu senden, es sei denn, Sie suchen auf der Serverseite nach POST oder GET. Fügen Sie einfach z. B.? Parm1 = value1 & parm2 = value2 & usw. zur URL hinzu.