Ist entweder GET oder POST sicherer als das andere?

Die GET-Anforderung ist geringfügig weniger sicher als die Anforderung POST. Weder bietet echte "Sicherheit" für sich; Durch die Verwendung von POST - Anfragen wird nicht wird Ihre Website auf magische Weise merklich vor böswilligen Angriffen geschützt. Die Verwendung von GET-Anforderungen kann eine ansonsten sichere Anwendung unsicher machen.

Das Mantra, dass Sie "keine GET-Anforderungen verwenden müssen, um Änderungen vorzunehmen", ist immer noch sehr gültig, aber dies hat wenig mit dem Verhalten von böswillig zu tun. Anmeldeformulare reagieren am empfindlichsten auf den Versand mit dem falschen Anfragetyp.

Suche nach Spinnen und Web-Beschleunigern

Dies ist der eigentliche Grund, warum Sie POST - Anforderungen zum Ändern von Daten verwenden sollten. Suchspinnen folgen jedem Link auf Ihrer Website, senden jedoch keine zufälligen Formulare, die sie finden.

Web Accelerators sind schlechter als Suchmaschinen, da sie auf dem Client-Computer ausgeführt werden und auf alle Links "klicken" im Kontext des angemeldeten Benutzers . Daher befolgt eine Anwendung, die eine GET-Anforderung zum Löschen von Inhalten verwendet, auch wenn ein Administrator erforderlich ist, die Anweisungen des (nicht böswilligen!) Web Accelerators und alles löschen, was angezeigt wird .

Verwirrter stellvertretender Angriff

Ein verwirrter stellvertretender Angriff (wobei der Stellvertreter der Browser ist) ist möglich, unabhängig davon, ob Sie eine GET- oder eine POST - Anforderung verwenden .

Auf von Angreifern kontrollierten Websites sind GET und POST ebenso einfach einzureichenohne Benutzerinteraktion .

Das einzige Szenario, in dem POST etwas weniger anfällig ist, besteht darin, dass viele Websites, die nicht unter der Kontrolle des Angreifers stehen (z. B. ein Forum eines Drittanbieters), das Einbetten beliebiger Bilder ermöglichen (der Angreifer kann eine beliebige GET-Anforderung einfügen). Verhindern Sie jedoch alle Möglichkeiten zum Injizieren einer beliebigen POST - Anforderung, ob automatisch oder manuell.

Man könnte argumentieren, dass Web-Beschleuniger ein Beispiel für einen verwirrten stellvertretenden Angriff sind, aber das ist nur eine Frage der Definition. Wenn überhaupt, hat ein böswilliger Angreifer keine Kontrolle darüber. Daher handelt es sich kaum um einen - Angriff , auch wenn der Stellvertreter verwirrt ist.

Proxy-Protokolle

Proxyserver protokollieren GET-URLs wahrscheinlich vollständig, ohne die Abfragezeichenfolge zu entfernen. POST - Anforderungsparameter werden normalerweise nicht protokolliert. In beiden Fällen ist es unwahrscheinlich, dass Cookies protokolliert werden. (Beispiel)

Dies ist ein sehr schwaches Argument für POST. Erstens kann unverschlüsselter Datenverkehr vollständig protokolliert werden. Ein böswilliger Proxy hat bereits alles, was er braucht. Zweitens sind die Anforderungsparameter für einen Angreifer von begrenztem Nutzen: Was sie wirklich benötigen, sind die Cookies. Wenn sie also nur Proxy-Protokolle haben, ist es unwahrscheinlich, dass sie in der Lage sind, entweder ein GET oder ein POST anzugreifen. URL.

Es gibt eine Ausnahme für Anmeldeanfragen: Diese enthalten in der Regel das Kennwort des Benutzers. Wenn Sie dies im Proxy-Protokoll speichern, wird ein Angriffsvektor geöffnet, der bei POST nicht vorhanden ist. Die Anmeldung über normales HTTP ist jedoch ohnehin unsicher.

Proxy-Cache

Zwischenspeichern von Proxys behält möglicherweise GET-Antworten bei, nicht jedoch POST. GET-Antworten können jedoch mit weniger Aufwand als das Konvertieren der URL in einen POST - Handler nicht mehr zwischengespeichert werden.

HTTP "Referer"

Wenn der Benutzer von der als Antwort auf eine GET-Anforderung bereitgestellten Seite zu einer Website eines Drittanbieters navigiert, werden auf dieser Website alle GET-Anforderungsparameter angezeigt.

Gehört zur Kategorie "gibt Anforderungsparameter an Dritte weiter", deren Schweregrad davon abhängt, was in diesen Parametern enthalten ist. POST -Anfragen sind davon natürlich nicht betroffen. Um jedoch die GET-Anfrage auszunutzen, müsste ein Hacker einen Link zu seiner eigenen Website in die Antwort des Servers einfügen.

Browserverlauf

Dies ist dem Argument "Proxy-Protokolle" sehr ähnlich: GET-Anforderungen werden zusammen mit ihren Parametern im Browserverlauf gespeichert. Der Angreifer kann diese leicht erhalten, wenn er physischen Zugriff auf den Computer hat.

Browseraktualisierungsaktion

Der Browser wiederholt eine GET-Anforderung, sobald der Benutzer auf "Aktualisieren" klickt. Dies kann passieren, wenn Registerkarten nach dem Herunterfahren wiederhergestellt werden. Jede Aktion (z. B. eine Zahlung) wird daher ohne Vorwarnung wiederholt.

Der Browser wird eine POST - Anforderung nicht ohne Warnung wiederholen.

Dies ist ein guter Grund, nur POST -Anforderungen zum Ändern von Daten zu verwenden, hat jedoch nichts mit böswilligem Verhalten und damit Sicherheit zu tun.

Also was soll ich tun?

• Verwenden Sie zum Ändern von Daten nur POST -Anforderungen, hauptsächlich aus nicht sicherheitsrelevanten Gründen.
• Verwenden Sie nur POST -Anforderungen für Anmeldeformulare. Andernfalls werden Angriffsvektoren eingeführt.
• Wenn Ihre Website vertrauliche Vorgänge ausführt, benötigen Sie jemanden, der weiß, was er tut, da dies nicht in einer einzigen Antwort behandelt werden kann. Sie müssen HTTPS, HSTS, CSP verwenden, die SQL-Injection abschwächen, Script Injection (XSS) , CSRF und eine Unmenge von andere plattformspezifische Aspekte (z. B. die Sicherheitsanfälligkeit bezüglich Massenzuweisung in verschiedenen Frameworks: ASP.NET MVC , Ruby on Rails usw.). Es gibt keine einzige Sache, die den Unterschied zwischen "sicher" (nicht ausnutzbar) und "nicht sicher" ausmacht.

Über HTTPS werden POST Daten verschlüsselt, aber könnten URLs von einem Drittanbieter abgehört werden?

Nein, sie können nicht beschnuppert werden. Die URLs werden jedoch im Browserverlauf gespeichert.

Wäre es fair zu sagen, dass die beste Vorgehensweise darin besteht, zu vermeiden, dass vertrauliche Daten vollständig in POST oder GET gestellt werden, und stattdessen serverseitigen Code für den Umgang mit vertraulichen Informationen zu verwenden?

Kommt darauf an, wie empfindlich es ist, oder genauer gesagt, auf welche Weise. Offensichtlich wird der Kunde es sehen. Jeder, der physisch auf den Computer des Kunden zugreifen kann, sieht dies. Der Kunde kann es fälschen, wenn er es an Sie zurücksendet. Wenn dies wichtig ist, bewahren Sie die vertraulichen Daten auf dem Server auf und lassen Sie sie nicht verlassen.

Sie haben keine höhere Sicherheit bereitgestellt, da die Variablen über HTTP POST) gesendet werden als bei Variablen, die über HTTP GET gesendet werden.

HTTP/1.1 bietet uns eine Reihe von Methoden zum Senden einer Anfrage :

• OPTIONEN
• GET
• HEAD
• POST
• STELLEN
• LÖSCHEN
• SPUR
• VERBINDEN

Nehmen wir an, Sie haben das folgende HTML-Dokument mit GET:

<html>
<body>
<form action="http://example.com" method="get">
    User: <input type="text" name="username" /><br/>
    Password: <input type="password" name="password" /><br/>
    <input type="hidden" name="extra" value="lolcatz" />
    <input type="submit"/>
</form>
</body>
</html>

Was fragt Ihr Browser? Es fragt dies:

 GET /?username=swordfish&password=hunter2&extra=lolcatz HTTP/1.1
 Host: example.com
 Connection: keep-alive
 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/ [...truncated]
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) [...truncated]
 Accept-Encoding: gzip,deflate,sdch
 Accept-Language: en-US,en;q=0.8
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Nehmen wir nun an, wir hätten diese Anforderungsmethode in einen POST geändert:

 POST / HTTP/1.1
 Host: example.com
 Connection: keep-alive
 Content-Length: 49
 Cache-Control: max-age=0
 Origin: null
 Content-Type: application/x-www-form-urlencoded
 Accept: application/xml,application/xhtml+xml,text/ [...truncated]
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; [...truncated]
 Accept-Encoding: gzip,deflate,sdch
 Accept-Language: en-US,en;q=0.8
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

 username=swordfish&password=hunter2&extra=lolcatz

[~ # ~] beide [~ # ~] dieser HTTP-Anforderungen sind:

• Nicht verschlüsselt
• In beiden Beispielen enthalten
• Kann angetaucht werden und MITM-Angriffen ausgesetzt sein.
• Leicht reproduzierbar durch Bots von Drittanbietern und Skripten.

Viele Browser unterstützen keine anderen HTTP-Methoden als POST/GET.

In vielen Browsern wird die Seitenadresse gespeichert, dies bedeutet jedoch nicht, dass Sie diese anderen Probleme ignorieren können.

Also um genau zu sein:

Ist einer von Natur aus sicherer als der andere? Mir ist klar, dass POST keine Informationen in der URL verfügbar macht, aber gibt es einen echten Wert darin oder ist es nur Sicherheit durch Unbekanntheit? Was ist die beste Vorgehensweise hier?

Dies ist richtig, da die Software, die Sie zum Sprechen von HTTP verwenden, dazu neigt, die Anforderungsvariablen mit einer Methode zu speichern, aber nicht mit einer anderen, die nur verhindert, dass ein 10-Jähriger den Browserverlauf oder eine andere naive Attacke untersucht, wenn er glaubt, h4x0r1ng zu verstehen oder Skripte, die Ihren Verlaufsspeicher überprüfen. Wenn Sie ein Skript haben, mit dem Sie Ihren Verlaufsspeicher überprüfen können, können Sie genauso gut ein Skript haben, mit dem Sie Ihren Netzwerkverkehr überprüfen können. Diese gesamte Sicherheit durch Unbekanntheit stellt also nur Unbekanntheit für Skriptkinder und eifersüchtige Freundinnen bereit.

Über https werden POST Daten verschlüsselt, aber könnten URLs von Dritten abgehört werden?

So funktioniert SSL. Erinnerst du dich an die beiden Anfragen, die ich oben gesendet habe? In SSL sehen sie folgendermaßen aus: (Ich habe die Seite auf https: //encrypted.google.com/ geändert, da example.com nicht auf SSL reagiert.).

POST über SSL

q5XQP%RWCd2u#o/T9oiOyR2_YO?yo/3#tR_G7 2_RO8w?FoaObi)
oXpB_y?oO4q?`[email protected]?/P/oOEQC5v?vai /%0Odo
QVw#6eoGXBF_o?/u0_F!_1a0A?Q b%[email protected]/O/o/[email protected]&_o
9q1/?q$7yOAXOD5sc$H`BECo1w/`4?)f!%geOOF/!/#Of_f&AEI#
yvv/wu_b5?/o d9O?VOVOFHwRO/pO/OSv_/8/9o6b0FGOH61O?ti
/i7b?!_o8u%RS/Doai%/Be/d4$0sv_%YD2_/EOAO/C?vv/%X!T?R
_o_2yoBP)orw7H_yQsXOhoVUo49itare#cA?/c)I7R?YCsg ??c'
(_!(0u)o4eIis/S8Oo8_BDueC?1uUO%ooOI_o8WaoO/ [email protected]&
Pw?os9Od!c?/$3bWWeIrd_?( `P_C?7_g5O(ob(go?&/ooRxR'u/
T/yO3dS&??hIOB/?/OI?$oH2_?c_?OsD//0/_s%r

Holen Sie sich über SSL

rV/O8ow1pc`?058/8OS_Qy/$7oSsU'qoo#vCbOO`vt?yFo_?EYif)
43`I/WOP_8oH0%3OqP_h/cBO&24?'?o_4`scooPSOVWYSV?H?pV!i
?78cU!_b5h'/b2coWD?/43Tu?153pI/9?R8!_Od"(//O_a#t8x?__
bb3D?05Dh/PrS6_/&[email protected] f $)/xvxfgO'[email protected]&e&S0rB3D/Y_/fO?
_'woRbOV?_!yxSOdwo1G1?8d_p?4fo81VS3sAOvO/Db/br)f4fOxt
_Qs3EO/?2O/TOo_8p82FOt/hO?X_P3o"OVQO_?Ww_dr"'DxHwo//P
oEfGtt/_o)5RgoGqui&AXEq/oXv&//?%/6_?/x_OTgOEE%v (u(?/
t7DX1O8oD?fVObiooi'8)so?o??`o"FyVOByY_ Supo? /'i?Oi"4
tr'9/o_7too7q?c2Pv

(Anmerkung: Ich habe das HEX in ASCII konvertiert, einige davon sollten offensichtlich nicht anzeigbar sein)

Die gesamte HTTP-Konversation ist verschlüsselt. Der einzige sichtbare Teil der Kommunikation befindet sich auf der TCP/IP-Ebene (dh die IP-Adresse und die Verbindungsportinformationen).

Lassen Sie mich hier eine große kühne Aussage machen. Ihre Website ist in Bezug auf eine HTTP-Methode nicht sicherer als in Bezug auf eine andere. Hacker und Neulinge auf der ganzen Welt wissen genau, wie das zu tun ist, was ich gerade hier demonstriert habe. Wenn Sie Sicherheit wünschen, verwenden Sie SSL. Browser neigen dazu, den Verlauf zu speichern. RFC2616 9.1.1 empfiehlt, GET NICHT zu verwenden, um eine Aktion auszuführen, aber zu denken, dass POST) die Sicherheit absolut falsch ist.

Das einzige, was POST ist eine Sicherheitsmaßnahme gegen? Schutz vor Ihrem eifersüchtigen Ex, der durch Ihren Browserverlauf blättert. Das war's. Der Rest der Welt ist in Ihrem Konto eingeloggt und lacht Sie aus.

Um weiter zu demonstrieren, warum POST ist nicht sicher, verwendet Facebook POST fordert überall an, also wie kann Software wie FireSheep existieren?

Beachten Sie, dass Sie möglicherweise mit [~ # ~] csrf [~ # ~] angegriffen werden, auch wenn Sie HTTPS verwenden und Ihre Site nicht [~ # ~] xss [~ enthält # ~] Sicherheitslücken. Kurz gesagt, in diesem Angriffsszenario wird davon ausgegangen, dass das Opfer (der Benutzer Ihrer Website oder Ihres Dienstes) bereits angemeldet ist und über ein ordnungsgemäßes Cookie verfügt. Anschließend wird der Browser des Opfers aufgefordert, etwas mit Ihrer (vermeintlich sicheren) Website zu tun. Wenn Sie nicht gegen CSRF geschützt sind, kann der Angreifer dennoch Aktionen mit den Berechtigungsnachweisen des Opfers ausführen. Der Angreifer kann die Serverantwort nicht sehen, da sie an den Browser des Opfers übertragen wird, der Schaden jedoch in der Regel bereits an diesem Punkt entstanden ist.

Es gibt keine zusätzliche Sicherheit.

Post-Daten werden nicht im Verlauf und/oder in den Protokolldateien angezeigt. Wenn die Daten jedoch sicher aufbewahrt werden sollen, benötigen Sie SSL.
Andernfalls kann jeder, der am Kabel schnüffelt, Ihre Daten trotzdem lesen.

Auch wenn POST keinen wirklichen Sicherheitsvorteil gegenüber GET bietet, stellen Sie bei Anmeldeformularen oder anderen Formularen mit relativ vertraulichen Informationen sicher, dass Sie POST verwenden als:

1. Die Informationen POSTed werden nicht im Verlauf des Benutzers gespeichert.
2. Die vertraulichen Informationen (Passwort usw.), die im Formular gesendet werden, werden später in der URL-Leiste nicht angezeigt (mit GET werden sie im Verlauf und in der URL-Leiste angezeigt).

Außerdem hat GET ein theoretisches Datenlimit. POST nicht.

Verwenden Sie für wirklich vertrauliche Informationen unbedingt SSL (HTTPS)

Keines von GET und POST ist von Natur aus "sicherer" als das andere, genauso wie keines von Fax und Telefon "sicherer" als das andere ist. Die verschiedenen HTTP-Methoden werden dafür bereitgestellt Sie können diejenige auswählen, die für das zu lösende Problem am besten geeignet ist. GET ist besser geeignet für idempotente Abfragen, während POST ist besser geeignet für "Aktion" "abfragen, aber sie können sich genauso leicht in den fuß schießen, wenn sie die sicherheitsarchitektur der von ihnen verwalteten anwendung nicht verstehen.

Am besten lesen Sie Kapitel 9: Methodendefinitionen des HTTP/1.1 RFC , um einen Überblick über GET und POST waren ursprünglich ot mean gedacht.

Der Unterschied zwischen GET und POST sollte nicht in Bezug auf die Sicherheit gesehen werden, sondern in Bezug auf die Absichten gegenüber dem Server. GET sollte niemals Daten auf dem Server ändern - zumindest nicht in Protokollen -, sondern POST kann neue Ressourcen erstellen.

Nice-Proxies werden keine POST Daten zwischenspeichern, aber sie können GET-Daten von der URL zwischenspeichern, sodass Sie sagen könnten, dass POST sicherer sein soll. Aber POST Daten wären immer noch für Proxys verfügbar, die sich nicht gut abspielen lassen.

Wie in vielen Antworten erwähnt, ist die einzige sichere Wette SSL.

Stellen Sie jedoch sicher, dass mit GET-Methoden keine Änderungen vorgenommen werden, z. B. das Löschen von Datenbankzeilen usw.

Dies ist nicht sicherheitsrelevant, aber ... Browser zwischenspeichern nicht POST Anfragen.

Meine übliche Methode für die Auswahl ist so etwas wie:

• GET für Elemente, die abgerufen später per URL
  • Z.B. Die Suche sollte GET sein, damit Sie später search.php? S = XXX ausführen können
• POST für Artikel, die gesendet
  • Dies ist relativ unsichtbar und für GET schwieriger zu senden, aber Daten können weiterhin über cURL gesendet werden.

Keiner von beiden verleiht einer Anfrage auf magische Weise Sicherheit, jedoch impliziert GET einige Nebenwirkungen, die im Allgemeinen die Sicherheit beeinträchtigen.

GET-URLs werden im Browserverlauf und in den Webserver-Protokollen angezeigt. Aus diesem Grund sollten sie niemals für Anmeldeformulare oder Kreditkartennummern verwendet werden.

Das reine POSTEN dieser Daten macht sie jedoch auch nicht sicher. Dafür möchten Sie SSL. Sowohl GET als auch POST senden Daten im Klartext über die Leitung, wenn sie über HTTP verwendet werden.

Es gibt auch andere gute Gründe, um POST Daten zu senden - wie die Möglichkeit, unbegrenzte Datenmengen zu übermitteln oder Parameter vor Gelegenheitsbenutzern zu verbergen.

Der Nachteil ist, dass Benutzer die Ergebnisse einer über POST gesendeten Abfrage nicht mit einem Lesezeichen versehen können. Dafür brauchen Sie GET.

Betrachten Sie diese Situation: Eine schlampige API akzeptiert GET-Anforderungen wie:

http://www.example.com/api?apikey=abcdef123456&action=deleteCategory&id=1

In einigen Einstellungen wird beim Anfordern dieser URL und bei Auftreten eines Fehlers/einer Warnung bezüglich der Anforderung diese gesamte Zeile in der Protokolldatei protokolliert. Schlimmer noch: Wenn Sie vergessen, Fehlermeldungen auf dem Produktionsserver zu deaktivieren, werden diese Informationen im Browser nur in Klartext angezeigt! Jetzt haben Sie Ihren API-Schlüssel an alle weitergegeben.

Leider funktionieren echte APIs auf diese Weise.

Ich hätte nicht gerne die Idee, vertrauliche Informationen in den Protokollen zu haben oder sie im Browser anzuzeigen. POST und GET ist nicht dasselbe. Verwenden Sie jedes, wo es angebracht ist.

1. SICHERHEIT als Sicherheit von Daten IN TRANSIT: kein Unterschied zwischen POST und GET.

2. SICHERHEIT als Datensicherheit AUF DEM COMPUTER: POST ist sicherer (kein URL-Verlauf)

Der Begriff Sicherheit ist bedeutungslos, es sei denn, Sie definieren, gegen was Sie sicher sein möchten.

Wenn Sie vor dem gespeicherten Browserverlauf, einigen Arten der Protokollierung und Personen, die Ihre URLs betrachten, sicher sein möchten, ist POST) sicherer.

Wenn Sie sicher sein möchten, dass niemand Ihre Netzwerkaktivität riecht, gibt es keinen Unterschied.

Sie sollten sich auch darüber im Klaren sein, dass, wenn Ihre Websites Links zu anderen externen Websites enthalten, die Sie nicht mit GET steuern, diese Daten in den Header der externen Websites aufgenommen werden, wenn diese auf die Links auf Ihrer Website klicken. Das Übertragen von Anmeldedaten mit GET-Methoden ist daher IMMER ein großes Problem. Da dies Anmeldeinformationen für den einfachen Zugriff verfügbar machen könnte, indem Sie nur die Protokolle überprüfen oder in Google Analytics (oder ähnlichem) nachsehen.

Es ist schwieriger, eine POST) - Anforderung zu ändern (dies erfordert mehr Aufwand als das Bearbeiten der Abfragezeichenfolge). Bearbeiten: Mit anderen Worten, es ist nur Sicherheit durch Dunkelheit, und kaum das.

Viele Leute nehmen eine Konvention an (von Ross angedeutet), dass GET-Anfragen nur Daten abrufen und keine Daten auf dem Server ändern, und POST) Anfragen werden für alle Datenänderungen verwendet nicht von Natur aus sicherer als die anderen, wenn Sie do dieser Konvention folgen, können Sie eine übergreifende Sicherheitslogik anwenden (z. B. können nur Benutzer mit Konten Daten ändern, sodass nicht authentifizierte POSTs abgelehnt werden).

Wie bereits erwähnt, bringt HTTPS Sicherheit.

Allerdings ist POST etwas sicherer als GET, da GET im Verlauf gespeichert werden könnte.

Leider liegt die Wahl von POST oder GET nicht im Ermessen des Entwicklers. Beispielsweise wird ein Hyperlink immer per GET gesendet (es sei denn, er wird mit Javascript in ein Post-Formular umgewandelt).

Ich werde nicht alle anderen Antworten wiederholen, aber es gibt einen Aspekt, den ich noch nicht erwähnt habe - es ist die Geschichte des Verschwindens von Daten. Ich weiß nicht, wo ich es finden soll, aber ...

Im Grunde handelt es sich um eine Webanwendung, bei der auf mysteriöse Weise alle paar Nächte alle Daten verloren gingen und niemand wusste, warum. Eine spätere Überprüfung der Protokolle ergab, dass die Website von Google oder einer anderen beliebigen Spinne gefunden wurde, die alle auf der Website gefundenen Links glücklich abrief (lesen Sie: GOT) - einschließlich "Diesen Eintrag löschen" und "Sind Sie sicher?" links.

Eigentlich - ein Teil davon wurde erwähnt. Dies ist die Geschichte hinter "Ändere keine Daten auf GET, sondern nur auf POST". Crawler werden GET gerne folgen, niemals POST. Auch robots.txt hilft nicht gegen schlechtes Verhalten von Crawlern.

RFC7231:

"URIs sollen gemeinsam genutzt und nicht gesichert werden, auch wenn sie sichere Ressourcen identifizieren. URIs werden häufig auf Anzeigen angezeigt, beim Drucken einer Seite zu Vorlagen hinzugefügt und in einer Vielzahl ungeschützter Lesezeichenlisten gespeichert. Es ist daher nicht ratsam, sie einzuschließen Informationen innerhalb einer URI, die sensibel, persönlich identifizierbar oder mit einem Risiko verbunden sind.

Autoren von Diensten sollten GET-basierte Formulare für die Übermittlung sensibler Daten vermeiden, da diese Daten im Anforderungsziel abgelegt werden. Viele vorhandene Server, Proxys und Benutzeragenten protokollieren oder zeigen das Anforderungsziel an Stellen an, an denen es möglicherweise für Dritte sichtbar ist. Solche Dienste sollten stattdessen POST-basierte Formularübermittlung verwenden. "

Dieser RFC besagt eindeutig, dass vertrauliche Daten nicht mit GET übermittelt werden sollten. Aufgrund dieser Bemerkung behandeln einige Implementierer Daten, die aus dem Abfrageteil einer GET-Anforderung erhalten wurden, möglicherweise nicht mit der gleichen Sorgfalt. Ich arbeite selbst an einem Protokoll, das die Integrität der Daten gewährleistet. Nach dieser Spezifikation sollte ich nicht die Integrität der GET-Daten garantieren müssen (was ich tun werde, weil sich niemand an diese Spezifikationen hält)

GET ist für jeden sichtbar (auch für den, der sich gerade auf Ihrer Schulter befindet) und wird im Cache gespeichert. Daher ist die Verwendung von Post weniger sicher. Übrigens ist die Verwendung von Kryptografieroutinen nicht sicher. Aus Sicherheitsgründen müssen Sie SSL verwenden ( https)

Kürzlich wurde ein Angriff veröffentlicht, mit dem man in der Mitte einen Anforderungsrumpf komprimierter HTTPS-Anforderungen aufdecken kann. Da Anforderungsheader und URL nicht durch HTTP komprimiert werden, sind GET-Anforderungen besser gegen diesen bestimmten Angriff geschützt.

Es gibt Modi , in denen GET-Anforderungen ebenfalls anfällig sind, SPDY komprimiert Anforderungsheader, TLS bietet auch eine optionale (selten verwendete) Komprimierung. In diesen Szenarien ist der Angriff leichter zu verhindern (Browser-Anbieter haben bereits Korrekturen bereitgestellt). Die Komprimierung auf HTTP-Ebene ist eine grundlegendere Funktion. Es ist unwahrscheinlich, dass Anbieter sie deaktivieren.

Es ist nur ein Beispiel, das ein Szenario zeigt, in dem GET sicherer ist als POST, aber ich denke nicht, dass es eine gute Idee wäre, GET anstelle von POST aus diesem Angriffsgrund zu wählen Der Angriff ist recht komplex und erfordert nicht triviale Voraussetzungen (Angreifer müssen in der Lage sein, einen Teil des Anforderungsinhalts zu kontrollieren.) Es ist besser, die HTTP-Komprimierung in Szenarien zu deaktivieren, in denen der Angriff schädlich wäre.

Ein Grund, warum POST aus Sicherheitsgründen schlechter ist, ist, dass GET standardmäßig protokolliert wird, Parameter und alle Daten von Ihrem Webserver nahezu universell protokolliert werden.

POST ist das Gegenteil, es ist fast universell nicht protokolliert , was dazu führt, dass die Aktivität eines Angreifers sehr schwer zu erkennen ist.

Ich kaufe nicht das Argument "es ist zu groß", das ist kein Grund, nicht zu loggen irgendetwas, mindestens 1 KB, wäre ein langer Weg für die Leute, um Angreifer zu identifizieren, die an einem schwachen Eingang arbeiten -point bis es auftaucht, dann führt POST ein doppeltes Dis-Service durch, indem es jedem HTTP-basierten Back-Door ermöglicht, unbegrenzte Datenmengen stillschweigend weiterzuleiten.

Haftungsausschluss: Die folgenden Punkte gelten nur für API-Aufrufe und nicht für die Website-URLs.

Sicherheit über das Netzwerk: Sie müssen HTTPS verwenden. GET und POST sind in diesem Fall gleichermaßen sicher.

Browserverlauf: Für Front-End-Anwendungen wie Angular JS, React JS usw. API-Aufrufe sind AJAX Aufrufe über das Front-End. Diese werden nicht Teil des Browserverlaufs. Daher sind POST und GET gleichermaßen sicher.

Server-seitige Protokolle: Mit der Verwendung des Schreibsatzes von Datenmaskierungs- und Zugriffsprotokollformaten ist es möglich, alle oder nur sensible Daten von der Anforderungs-URL auszublenden.

Sichtbarkeit der Daten in der Browserkonsole: Für jemanden mit mallicious intent ist es fast dasselbe wie GET, die Daten zu betrachten POST).

Daher ist die GET-API mit der richtigen Protokollierungspraxis so sicher wie die POST API. Wenn Sie POST überall folgen, werden schlechte API-Definitionen erzwungen und sollten vermieden werden.

Der Unterschied besteht darin, dass GET Daten offen und POST versteckt (im http-Header) sendet.

Get ist also besser für nicht sichere Daten wie Abfragezeichenfolgen in Google. Auth-Daten dürfen niemals per GET gesendet werden - verwenden Sie also POST hier. Das ganze Thema ist natürlich etwas komplizierter. Wenn Sie mehr lesen möchten, lesen Sie diesen Artikel .