HTML Wie könnte ein Hacker GET missbrauchen?

[Zeboo]

Hallo,

mir wurde eine Frage gestellt und konnte sie nicht beantworten: Was könnte ein Hacker zum Beispiel bei einem Eingabeformular mit GET machen um gefälschte Daten an dem Server zu schicken?

Verstehe die frage garnicht. Mit GET kann man unter anderem die Inhalte im Formular abschicken. Was man damit böses machen könnte bzw. der "Hacker" damit anstellen soll verstehe ich nicht. Jemand eine was man böses mit GET machen kann?

Gruß

 

[ice-breaker]

Stichwort: (nicht persistentes) XSS

 

[RoseFlunder]

SQL Injection ist das Stichwort.
Bei Wikipedia haste auch gleich n Beispiel:
http://de.wikipedia.org/wiki/SQL-Injection

 

[Zeboo]

Stichwort: (nicht persistentes) XSS

Ich weiß nicht ob das als Antwort gelten soll. Da das auch bei POST gelten würde. GET muss etwas (einfaches) haben was man ausnutzen kann, was bei POST etc nicht geht.

 

[redeye86]

Ich würd sagen, das die Eingaben in den Logdateien zu finden sind, da die übertragenen Daten bei einem GET ja in der URL stehen. Wenn da jemand dran kommt, hat man zwar noch ganz andere Probleme, aber gut wäre es nicht.

 

[Zeboo]

Ich würd sagen, das die Eingaben in den Logdateien zu finden sind, da die übertragenen Daten bei einem GET ja in der URL stehen.

Ja an sowas dachte ich irgendwie auch. Und das beim GET auch gegacht wird. Trozdem verstehe ich nicht was man da missbrauchen kann ^^

 

[Simple Man]

Bei GET werden alle key value Dinger über die URL mitgeschickt und sind somit für alle, die auf den Monitor starren sichtbar.

http://www.example.org/?benutzer=xy&passwort=yx

 

[ice-breaker]

Ich weiß nicht ob das als Antwort gelten soll. Da das auch bei POST gelten würde. GET muss etwas (einfaches) haben was man ausnutzen kann, was bei POST etc nicht geht.

nein, genau darauf hinaus geht die Frage
SQL-Injection kann es nicht sein, da es mit jedem externen Parameter geht.

Hier geht es aber um eine spezielle Form von nicht persistentem XSS:
Formulare geben i.R. wieder die Daten aus, die eingegeben wurden, wenn das Formular nicht komplett richtig war. Nutzt der Programmierer nun nicht $_POST sondern $_REQUEST kann ein Formularwert über $_GET eingeschleust werden. Ist die Ausgabe des Wertes nun nicht sicher gegen XSS-Angriffe kann ich einen nicht persistenten XSS-Angriff fahren, indem ich jemandem meinen speziellen Link unterschiebe. Dieser wird dann den XSS ausführen, der XSS ist aber nie persistent, deshalb dieser Trick über $_GET.

Auf Wikipedia steht es auch noch einmal: Cross-Site Scripting: Nicht-persistent oder reflexiv

 

[NullPointer]

CSRF? Das geht nur mit GET. Dabei ist es allerdings nicht der Hacker selbst, der die Daten schickt, sondern er bringt sein Opfer dazu, auf den GET-Link zu klicken.

 

[ice-breaker]

Neija CSRF geht auch mit Post, ist nur umständlicher, aber du hast Recht, prinzipiell lässt sich jede Lücke mit Get und Post ausnutzen.
CSRF wäre sicherlich eine weitere Option, allerdings ist die Fragestellung so wage, dass es wirklich alles sein könnte

 

[IceMatrix]

mit GET geht im großen und ganzen das gleiche wie mit POST. es ist nur einfacher, weil man bei GET alles über die URL machen kann.