Session-Hijacking bzw. Man in the Middle -> HTTPS

[Michi]

Hallo Forum,
gestern hielt unser Prof. einen Vortrag, hab aber leider den Schluss nicht mehr bitbekommen und danach war er leider auch gleich weg.
(Als Grundlage für HTTPS habe ich diesen Link genommen:
http://www.trojaner-und-sicherheit.de/security/verschluesselung.htm)
Mein Wissensstand wäre eben auf dem Niveau von dem Link oben.

Wie liest ein Man-in-the-Middle die Informationen aus (Da dieser verschlüsselt sind)

1. Man-in-the-Middle schleust sich irgendwie in eine Verbindung zwischen Client und Server (Wie er das macht oder machen könnte, müsste ich noch lernen, mir verdeutlichen bzw. mich darüber informieren. Er faked gibt sich beim Clienten praktisch als Server aus. Bsp. in Emails, wenn man sich als die Bank ausgibt mit einer anderen URL?)

2. Nun ist jedoch die Verbindung verschlüsselt. Wie schafft es der Man-in-the-Middle, die Daten zu entschlüsseln. Die Daten sind ja mit einer SessionKey (bei Hybride-Variante) Das wäre, ja wenn sich der Client auch authentifiziert. Nehmen wir an, dass die Daten nur verschlüsselt von irgend einem beliebigen Client an den Server geschickt werden, dann hat ja nur der Server einen public und private key.

Man-in-the-Middle nimmt public Key vom Server, empfängt die Daten vom Client unverschlüsselt, verschlüsselt sie und überträge es dann ganz normal an den Server (niemand kriegt somit also etwas mit?) richtig?

Heute ist Tag der Sicherheit für mich. Hab einige Seiten im Wiki gelesen (XSS, Session_Hijacking, usw.)

Wichtig bei Allem ist es u.a. Benutzereingaben zu filtern, die direkt für die Ausgabe (HTML) genutzt werden.

Man könnte entweder bestimmte Tags (<img>, usw.) heraufiltern/löschen oder maskieren, damit es nicht als TAG sondern als normaler Text erscheint. (In Java würde man etwas mit "" maskieren. (<img>)

3. Wie erkennt der Browser nun, zu dem die Ausgabe gesendet wird, dass er dies nicht als HTML-Tag nutzen soll?

Auf der Seite http://de.wikipedia.org/wiki/Header-Injection habe ich heute noch erfahren, dass man den Header manipulieren könnte, indem man in eine ungefilterte Eingabe ein CR (\n oder \r?) einfügt und damit ein BCC angeben kann.
Das heißt, man sollte \n und \r von der Eingabe herausfiltern oder maskieren.
4. Auch hier, SMPTP, POP3, wie auch immer, erkennen automatisch, dass etwas maskiert ist und nehmen das maskierte Zeichen als ganz normalen Text? Das heißt aber auch im Nachrichtenfeld, sobald ich dies in der Nachricht auch filtere oder maskiere, dass der Empfänger oder irgendwelche Ausgabe dann keine Zeilenumbrüche hat oder nicht?

:-)

Viele Grüße
Michi

[ChrisB]

Hi,

Nun ist jedoch die Verbindung verschlüsselt. Wie schafft es der Man-in-the-Middle, die Daten zu entschlüsseln.

Suppose Alice wishes to communicate with Bob. Meanwhile, ...

3. Wie erkennt der Browser nun, zu dem die Ausgabe gesendet wird, dass er dies nicht als HTML-Tag nutzen soll?

http://de.selfhtml.org/html/referenz/zeichen.htm#benannte_html

[E-Mail Header Injection] Das heißt, man sollte \n und \r von der Eingabe herausfiltern oder maskieren.
4. Auch hier, SMPTP, POP3, wie auch immer, erkennen automatisch, dass etwas maskiert ist und nehmen das maskierte Zeichen als ganz normalen Text? Das heißt aber auch im Nachrichtenfeld, sobald ich dies in der Nachricht auch filtere oder maskiere, dass der Empfänger oder irgendwelche Ausgabe dann keine Zeilenumbrüche hat oder nicht?

Die Nachricht ist Mail Body - Header Injection findet aber wo statt? Richtig, innerhalb der Header der E-Mail. Die Header werden durch das erste Auftreten eines doppelten CR LF vom Body abgetrennt. Alles, was danach kommt, ist diesbezüglich irrelevant.

MfG ChrisB

[Michi]

Hi,
vielen Dank für Links. Das erste (englische) muss ich mir noch bei Gelegenheit in Ruhe übersetzen und anschauen.

»» 3. Wie erkennt der Browser nun, zu dem die Ausgabe gesendet wird, dass er dies nicht als HTML-Tag nutzen soll?

http://de.selfhtml.org/html/referenz/zeichen.htm#benannte_html

Oki doki, da nehme ich dann entweder Unicode (ASCII) entweder DEZ oder Hex, bzw. HTML Name Entities (Welche von der DTD geregelt wird ne?)

Dieser Unicode (Bsp. &#228; für ä) wäre in vielen anderen Medien/Dokumenten (HTML, XML, E-Mails, .doc, .odt, usw.) wichtig ne? Und wird auch immer in der gleichen Schreibweise codiert. (Oder geht man da auch mal bis binär runter)

»» [E-Mail Header Injection] Das heißt, man sollte \n und \r von der Eingabe herausfiltern oder maskieren.
»» 4. Auch hier, SMPTP, POP3, wie auch immer, erkennen automatisch, dass etwas maskiert ist und nehmen das maskierte Zeichen als ganz normalen Text? Das heißt aber auch im Nachrichtenfeld, sobald ich dies in der Nachricht auch filtere oder maskiere, dass der Empfänger oder irgendwelche Ausgabe dann keine Zeilenumbrüche hat oder nicht?

Die Nachricht ist Mail Body - Header Injection findet aber wo statt? Richtig, innerhalb der Header der E-Mail. Die Header werden durch das erste Auftreten eines doppelten CR LF vom Body abgetrennt. Alles, was danach kommt, ist diesbezüglich irrelevant.

ok, das heißt, man muss nur auf Subject aufpassen, falls ein Benutzer nur dies eingeben kann, evtl. noch bei Absenderemail.

grüße
michi

[ChrisB]

Hi,

»» 3. Wie erkennt der Browser nun, zu dem die Ausgabe gesendet wird, dass er dies nicht als HTML-Tag nutzen soll?

http://de.selfhtml.org/html/referenz/zeichen.htm#benannte_html

Oki doki, da nehme ich dann entweder Unicode (ASCII) entweder DEZ oder Hex, bzw. HTML Name Entities (Welche von der DTD geregelt wird ne?)

Ich sehe wenig Grund, an dieser Stelle und zu diesem Zweck irgend etwas anderes zu nehmen, als die Entities.

Dieser Unicode (Bsp. &#228; für ä) wäre in vielen anderen Medien/Dokumenten (HTML, XML, E-Mails, .doc, .odt, usw.) wichtig ne?

Wichtig für was?

Und wird auch immer in der gleichen Schreibweise codiert.

Nö, wieso sollte er?

MfG ChrisB