$_POST trotzdem escapen, wenn ich keinen Connect zur DB durchführe?

[Fuerst Rainer]

Hallo,

muss ich eine $_POST escapen, wenn ich keinen Connect zur DB durchführe?

[rkr]

Ja: CSRF. Und: Kommt drauf an, was du mit den Daten sonst so vor hast. Ungeprüfter Userinput ist immer gefährlich - die Gefahr hängt aber immer vom Nutzungskontext ab.

[Fuerst Rainer]

Ja: CSRF. Und: Kommt drauf an, was du mit den Daten sonst so vor hast. Ungeprüfter Userinput ist immer gefährlich - die Gefahr hängt aber immer vom Nutzungskontext ab.

Danke.

[ChrisvA]

Hallo,

muss ich eine $_POST escapen, wenn ich keinen Connect zur DB durchführe?

Definitiv nein!
Escapen macht immer nur da Sinn, wo es gebraucht wird, was in Zeiten von prepared-Statements wohl nicht mehr viel sein wird.

Escapen schadet wenn es um die Ausgabe von Daten geht sogar, da man dann die ganzen überflüssigen Slashes wieder entfernen muss und die für HTML relevaten Zeichen austauschen muss.

[nikosch]

Ungeprüfter Userinput ist immer gefährlich - die Gefahr hängt aber immer vom Nutzungskontext ab.

Irgendwie eine NULL-Aussage. Könnte man auch über ungeprüftes Trinkwasser sagen.

Definitiv nein!

Sehe ich auch so. Selbst wenn mit Escaping hier nicht addslashes gemein sein sollte - der Kontext bestimmt die Art der notwendigen Filterung, ergo kann man pauschal sowieso keine Sicherheit erzeugen.

[rkr]

Wie kann man das denn falsch verstehen?
"Abhängig vom Nutzungskontext" heisst:
- will ich damit eine Datenbankabfrage formulieren: Entsprechend escapen
- will ich die Daten in HTML ausgeben: Entsprechend kodieren, damit kein XSS/CSRF möglich ist.
- will ich die Daten in JSON-Form ausgeben...
usw.

Und nein, pauschal die $_POST-Daten zu escapen ohne zu wissen, was damit passieren soll, macht natürlich keinen Sinn.

[nikosch]

Wie kann man dann auf:

muss ich eine $_POST escapen, wenn ich keinen Connect zur DB durchführe?

mit Ja antworten?

[rkr]

Habs mehr als Metapher für zu verarbeitenden Userinput gesehen. Das gleiche gilt natürlich auch für alles, was via $_GET in den Kreislauf gelangt.
An ein Vorgehen nach Vorbild von magic_quotes habe ich gar nicht gedacht

[Fuerst Rainer]

Danke für die Kommentare, es hat mir weitergeholfen

[lstegelitz]

muss ich eine $_POST escapen, wenn ich keinen Connect zur DB durchführe?

Die Antwort lautet: Du kannst es gar nicht ohne Verbindung.

(Sofern, wie schon angemerkt, ein Escaping im Sinne einer SQL Injection gemeint war)

[monolith]

Ja: CSRF

Kannst du das erläutern? Der Zusammenhang ist mir unbekannt.

[erc]

Escapen macht immer nur da Sinn, wo es gebraucht wird, was in Zeiten von prepared-Statements wohl nicht mehr viel sein wird.

In Zeiten von prepared statements? Prepared statements sind nicht dazu gedacht dir das escapen zu ersparen, das ist ein Nebeneffekt davon das Query und Daten getrennt übertragen werden.

[mermshaus]

@monolith:

Wenn du als Angreifer Seiten HTML-/JS-Code hinzufügen kannst, weil deine Eingaben nicht passend escapet werden, kannst du im Namen der ahnungslosen Nutzer, die dann auf die präparierte Seite klicken, GET- und POST-Requests zu beliebigen Webseiten absetzen.

Wenn diese Webseiten zum Beispiel irgendwelche Dienste sind, bei denen ein Nutzer zufällig angemeldet und gerade eingeloggt ist, kannst du ihn durch passendes Gestalten des Requests dazu bringen, in seinem Namen unbewusst irgendeine Funktion auf der Zielseite auszulösen.

Beispiele finden sich etwa im Wikipedia-Artikel dazu: https://de.wikipedia.org/wiki/CSRF

[monolith]

Ok, danke für die Erläuterung. Mir war nicht klar, dass mit "escapen" in dem Fall auch der Umgang mit Benutzereingaben gemeint war. Klar, wenn mit denen nicht entsprechend umgegangen wird und ein <script>...</script> einfach so gespeichert und dann ausgegeben wird, kann man JS-Code einschleusen und dann scheinbar als ein User, der die entsprechende Seite aufruft, agieren.

Also auch nochmal für Fuerst Rainer, falls er hier nochmal hereinschaut: Angenommen auf einer Webseite können angemeldete User Kommentare schreiben. Dann sollte man z. B. diese mit htmlentities behandeln bevor sie gespeichert (oder angezeigt) werden. Denn wenn man das nicht macht und ein User als Kommentar angibt <script>alert(123)</script>, dann baut er damit JavaScript in seinen Kommentar ein. Ruft nun ein anderer User die Seite mit dem Kommentar auf, liest dessen Browser den JS-Code aus und führt ihn anschließend aus, sprich der User bekommt die 123-Message angezeigt. Das lässt sich natürlich noch weiter treiben, z. B. könnte man dann mit JS auch Aktionen ausführen wie dass der fremde User neue Kommentare postet oder noch schlimmer in einem Shop etwas kauft.

Allerdings: Das wäre dann ein XSS-Angriff und kein CSRF-Angriff. Das deutsche Wiki ist da irritierend, aber auf der englischen Seite heißt es: " Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser." (https://en.wikipedia.org/wiki/Cross-...equest_forgery) und außerdem "Cross-site request forgery (CSRF/XSRF) is almost the opposite of XSS" (https://en.wikipedia.org/wiki/Cross-site_scripting)

[mermshaus]

Ich weiß nicht genau, auf welches Beispiel du dich in deinem letzten Absatz beziehst, aber ich würde mich da glaube ich nicht zu sehr auf die Begriffe versteifen. Je länger ich darüber nachdenke, desto weniger trennscharf kommen die mir vor. (Vielleicht ändert sich das wieder, falls ich noch länger darüber nachdenken würde. ) Der zuletzt von dir zitierten Satz geht ja zum Beispiel auch noch weiter:

Cross-site request forgery (CSRF/XSRF) is almost the opposite of XSS, in that rather than exploiting the user's trust in a site, the attacker (and his malicious page) exploits the site's trust in the client software, submitting requests that the site believes represent conscious and intentional actions of authenticated users.

Aus Sicht der Kontextwechselproblematik ist der dort angesprochene Aspekt meines Erachtens ziemlich unbedeutend. Da kann man verallgemeinern und sagen, dass XSS und CSRF beides Angriffsarten sind, die durch unzureichendes Escaping ermöglicht werden können, indem JavaScript-Code eingeschleust wird.