Fremde Website auslesen (mit Sessions)

Hallo.

Ich würde gerne an den HTML-Quellcode einer fremden Website gelangen. Normalerweise funktioniert das ganz gut, nur bei Websites mit Login (also solche, die mit Sessions arbeiten) funktioniert das Ganze nicht.

Mein Lösungsansatz wäre gewesen, die Cookie-Dateien auf dem Computer nach einer Session-ID zu durchsuchen und der Website als URL-Variable mitzugeben. Allerdings dauert das sehr lange, da die ganzen temporären Dateien durchsucht werden müssen. Und davon gibt es meist sehr viele. Außerdem muss der Variablenname der Session-ID stimmen, und ich weiß nicht, wie ich ihn finde (im Quellcode nicht, da PHP?). Ich hoffe, das Problem ist nachvollziehbar.

Deswegen, als Zusammenfassung:

• Gibt es einen bewährten, schnellen Weg so eine Website auszulesen?
• Ist es moralisch, so ein Programm weiterzugeben, auch wenn es etwas ganz harmloses tut? Ich habe Bedenken, weil Sessions doch ein sicherheitskritisches Thema ist und der Rechner dafür durchsucht werden muss.

Danke,
Jack

Hallo Jack_AI,

Technik kann man fast immer zum Guten wie auch zum Bösen einsetzen. Richtschnur im Rahmen der bestehenden Gesetze sollte die Höhe des Missbrauchsrisikos und das eigene Gewissen sein. Wenn du selbst schon im Zweifel bist, ob eine Weitergabe zu vertreten ist, solltest du das Programm besser nicht weitergeben.

Deinen Ansatz halte ich auch wirklich für gefährlich, wenn bestehende Cookies verwendet werden, weil dann das Missbrauchspotential relativ groß ist. Besser ist es, wenn das Programm den Login mit den Logindaten - die dann der Benutzer selbst eingeben oder hinterlegen muss - selbst durchführt.

Eine Möglichkeit wäre Button auf Website druecken?! eine andere die Verwendung von HttpWebRequest/Response in Kombination mit der Cookie-Klasse.

herbivore

Hallo herbivore,

ich habe den Tipp mit "Button auf Website ausprobiert". Ich muss erstmal sagen, dass ich ganz erstaunt bin, dass es überhaupt solche Funktionen gibt. Ich habe dabei weitestgehend deinen Beispiel-Code übernommen und dabei die Control-IDs angepasst. Einloggen funktioniert auch, allerdings legt er scheinbar kein Cookie an. Wenn ich eine Unterseite auf der Website mit einem StreamReader auslesen möchte, wirft er mich wieder zur Login-Seite zurück.

Jack

Hallo Jack_AI,

die Unterseiten musst du dann natürlich auch über das WebBrowser-Control aufrufen und auslesen, nicht über HttpWebRequest/Response.

Oder du musst schon den Login über HttpWebRequest/Response durchführen und das zurückgelieferte Cookie bei weiteren Requests selbst übergeben.

herbivore

Hallo,

vielleicht eine blöde Frage - wieso ist das Missbrauchspotenzial dabei groß? Um die Session zu nutzen, muss ich Zugriff auf das entsprechende Cookie haben.

Und wenn ich darauf zugreifen kann, könnte ich es auch direkt im IE / FF einsetzen, um auf die Session zuzugreifen.

Es handelt sich - vom böswilligen Standpunkt aus gesehen - um einen Cookie-Replay-Angriff. Und ein solcher wird nur dadurch verhindert, dass man das Cookie nicht herausgibt. Habe ich dieses erst einmal, ist es vollkommen egal, ob ich das mit dem IE oder mit einer selbstgeschriebenen Software weiterverwende ...

Oder übersehe ich dabei etwas essenzielles?

Viele Grüße,

Golo

Hallo Golo,

Es handelt sich - vom böswilligen Standpunkt aus gesehen - um einen Cookie-Replay-Angriff.

naja, das ist doch genau das Punkt. Man sollte kein Programm weitergeben, das so einen Angriff ermöglicht.

herbivore

Aber dazu brauche ich das Programm nicht. Dazu reicht der IE.

Was mir den Cookie-Replay-Angriff ermöglicht, ist doch der Zugriff auf das Cookie, nicht die Software.

Denn, wenn ich erst mal das Cookie habe, kann ich auch ohne die Software einen entsprechenden Angriff durchführen.

Was also verhindert werden muss, ist meines Erachtens, dass das Cookie in falsche Hände gerät, denn dann ist man a) vor beiden Varianten sicher, und b) ist nichts gegen die Software einzuwenden.

Hallo Golo,

Aber dazu brauche ich das Programm nicht.

das alles stimmt nur dann, wenn du die Kenntnisse hast, wie der Angriff durchzuführen ist. Mit einem (fertigen) Programm kann man den Angriff auch ohne diese Kenntnisse durchführen. Darin liegt die Gefahr.

herbivore

Aber liegt es dann nicht eher im Verantwortungsbereich des Web-Programmierers seine Cookies z.B: mit dem User-Agent-String und einem Seed so zu verschlüsseln, dass die Cookies eben nur von einem User-Agent genutzt werden können?

(Wobei man klar sagen muss, dass sich jemand, der Cookies verwendet, auch über die Risiken im Klaren sein sollte. Bzw. die Webseite sollte/muss darauf hinweisen, dass es Gefahrenpotential birgt, den Login im Cookie zu speichern (wie es z.B: eBay macht))

Hallo LittleBoy,

Aber liegt es dann nicht eher im Verantwortungsbereich des Web-Programmierers seine Cookies z.B: mit dem User-Agent-String und einem Seed so zu verschlüsseln, dass die Cookies eben nur von einem User-Agent genutzt werden können?

ein wirklicher Schutz ist das nicht, weil das "Angriffsprogramm" ja einfach den gleichen User-Agent-String übertragen kann.

herbivore

Das einzige, was meiner Meinung nach hilft, ist, zu verhindern, dass das Cookie geklaut wird ...

Wenn jemand darauf erst einmal Zugriff hat, ist es schnuppe, welche Software er für den Angriff benutzt.

Die kritische Stelle ist der Zugriff auf das Cookie ...

Servus,

Original von herbivore
ein wirklicher Schutz ist das nicht, weil das "Angriffsprogramm" ja einfach den gleichen User-Agent-String übertragen kann.

Jo, aber wenn das "Angriffsprogramm" die genauen Daten nicht weiß, woraus der Cookie-Schlüssel genau gebildet wird (also ob der jetzt der User-Agent oder ein bestimmtes anderes Header-Feld), ist es zumindest schonmal schwerer für den Angreifer.

Grundsätzlich daher ja mein zweiter Absatz:
Es ist ziemlich dumm von einer Webseite, solche Sachen in einem Cookie abzulegen. Wenn eine Webseite das ohne entsprechende Hinweise für die Nutzer macht, sollte man den "Webmaster" dafür eins auf die Ohren geben 😉
Und wenn der Nutzer zugestimmt hat, muss er damit rechnen, dass jedes Programm auf seinem Rechner (bei etwa 60% der "Webmaster") direkt auslesen kann oder zumindest sich auf der Webseite einloggen kann.

Früher oder später gibt es Programme, die sowas ausnutzen. Und wenn man früh genug "harmlose" Beispiele/Programme weitergibt, dann führt vielleicht das dazu, dass die Nutzer zukünftig etwas vorsichtiger mit sensiblen Informationen umgehen...

@Golo:
Man kann aber nicht verhindern, dass der Cookie geklaut wird. Der Cookie landet ja irgendwo in einem Datenspeicher - und wenn der exklusiv nur von einem Programm gelesen werden könnte, dann wäre das ja der Traum eines jeden Angriffs- und Schadprogrammes (dann hätten z.B. Virenscanner keinen Zugriff mehr darauf)

Wenn man es aber nicht verhindern kann, kann man per se auch keinen Cookie-Replay verhindern.

Und deshalb bin ich der Meinung, dass es schnuppe ist, ob's so ein Tool gibt oder nicht, weil jemand, der angreifen will und Zugriff auf das Cookie erhält, so oder so einen Cookie-Replay-Angriff durchführen kann.

Ob's die Software nun gibt oder nicht, macht das ganze nicht wahrscheinlicher oder einfacher.