Cross-Site Scripting

[Matze]

Hallo zusammen!
Ich bin gerade auf der Suche nach einer passenden Lösung, bei der ich nicht weiterkomme.
Ich möchte gerne von einer http-Webseite eine Anmeldung über eine https-Seite erstellen.
Prinzipiell ist da ja nichts drann, nur wie bekomme ich die Daten wieder zurück? Da wird es irgendwie kompliziert. Alles was mir in´s Hirn springt unterliegt der Javascript-Sicherheit.
Die einzige (sehr unschöne) Lösung die ich mir überlegt habe ist folgende:

WWW Form Ziel: iframe -> HTTPS Auswertung -> META Refresh zurück zu einem 2. Script auf der Ursprungsdomain mit dem Ergebnis der Prüfung an ein Hilfsscript (Serverseitiger Redirect geht nicht, da dann kein HTTP_Referrer übertragen wird) -> Hilfsscript geht über parent.xxx zurück auf die Seite.

Sehr viel wirbel um nichts - das einzige was ich hierbei erreiche ist

• die Daten werden verschlüsselt übertragen
• ich kann sicherstellen, dass der Aufruf vom richtigen Script kam (Referrer)

Allerdings ist keine Verschlüsselung der Daten zum ursprünglichen Script möglich. Bei einer einfachen Statusmeldung noch OK, aber für alles andere ist es damit nicht mehr tauglich.

Die ganze Seite unter SSL laufen zu lassen wäre zwar möglich, aber irgendwie nicht im Sinne des Erfinders. Bis auf die Anmeldung ist nichts schützenswertes dabei, eine unnötige Verschlüsselung wäre also unnötige Serverauslastung.

Server ist ein IIS, ASP, .net oder PHP geht also alles (wobei micht das letztere eigentlich nicht wirklich interessiert ;-))

Weiß jemand eine gute und sichere Lösung?

1. HTTP Post -> 2. HTTPS -> Javascript schreibt in 1.

Gruß
Matze

PS.: Noch viel toller wäre eine Lösung, wie ich Daten per Ajax vom https holen kann, aber das wird wohl unter keinen Umständen was?!

[LX]

Warum willst Du unbedingt mit JavaScript/AJAX machen, was ein serverseitiges Session-Management leisten kann?

Gruß, LX

[Matze]

Warum willst Du unbedingt mit JavaScript/AJAX machen, was ein serverseitiges Session-Management leisten kann?

Gruß, LX

Die Idee ist gut - aber leider nicht anwendbar. Die ssl-Seite bekommt eine eingene Session-ID - und das wird mein Provider für mich nicht ändern. Ich kann also in die ssl-Session schreiben bis ich grün werde, auf der nicht-ssl Seite bringt mir das nichts....

Wobei micht auch eine Session ja nicht vom grundsätzlichen Problem wegbringen würde.
Das Formular würde immernoch per ssl auf der falschen Domain liegen, und damit stehe ich wieder vor dem gleichen Problem.

Normalerweise sollte es egal sein, gibt halt einen vollen Postback von der Seite - aber ich finde es irgendwie blöde einfach so aufzugeben.

Schon kurios, dass das Sicherheitskonzept verbietet die maximale Sicherheit bei geringster Last herzustellen.
Leider werden die Nachfolgetechnologien, wie z.B. XDomainRequest aus dem IE8, die so etwas bieten noch lange Zeit nicht anwendbar sein :-(

Gruß
Matze

[LX]

Schon mal von Cookies gehört oder davon, dass man Sessioncodes auch via GET-String übertragen kann?

Gruß, LX

[Matze]

Schon mal von Cookies gehört oder davon, dass man Sessioncodes auch via GET-String übertragen kann?

Gruß, LX

Cookie geht auch nicht (SSL-Proxy), den darf nur lesen wer ihn geschrieben hat.
Sessioncode im GET - das ist für mich Sicherheitslücke in Eigenbau. Aber auch da wäre der Rückweg wieder problematisch.
Ich werde mal versuchen, meinen Wunsch besser darzustellen.

http Formular -> Übertragen an ssl (POST)
Benutzername  -> Übertragen an ssl
Kennwort      -> Übertragen an ssl
Senden        -> per Javascript deaktivieren

ssl Auswertung-> Überprüfung der Daten
Javascript    -> Einfügen des echten Benutzernamens im Login-Form
Javascript    -> Setzen der Session auf "angemeldet"
Javascript    -> Aktivieren des Senden-Buttons
------------------------------------------------------------------

In dem Falle soll "nur" der Name des Benutzers übertragen werden. Auf der Seite auf der ein Benutzer seine Daten ändern kann ist es dann natürlich ähnlich, nur das dort alle Daten üertragen werden müssen.

Weitere Angaben:
Der SSL-Proxy hat logischerweise eine andere URL als meine Seite.

Gruß
Matze