2010-10-22 7 views
6

Ich überlege mir, ein neues Projekt zu beginnen. Die Prämisse des Projekts ist ein Widget auf meiner Website zu generieren, dann ein Stück JavaScript in Ihre Website kopieren und Viola Sie haben Ihr Widget.Eigenes Javascript-Widget

Es ist ein neuer Spin auf bestehenden Diensten wie pollday.com, twiig.com und addthis.com.

Viele dieser Dienste sind öffentlich zugänglich. Das bedeutet, dass es dem Widget-Lieferanten egal ist, ob er Daten an sie zurückgibt. In der Tat regen sie an, das Widget so weit und so weit wie möglich zu verbreiten.

Allerdings hat meine Dienste eine einzigartige Wendung. In meinem Fall, obwohl das Widget der Öffentlichkeit zugänglich sein wird, muss ich sicher sein, dass die ausgehenden Postanfragen nur von der erwarteten Seite kommen.

Aufgrund von XSS-Problemen mit diesen JavaScript-Widgets muss ich dynamisch einen Iframe erstellen, in dem mein Widget gerendert wird.

Gibt es ein Authentifizierungsmodell für diese Art der Interaktion?

Antwort

3

Vor allem diese Verwendung eines iframe ist eine Verletzung der Same Origin Policy. Mit einfachem altem JavaScript können Sie eine <form> erstellen und .submit() aufrufen, um diese Postanforderung überall abzufeuern. In der Tat nutzt POST-basierte CSRF die Arbeit. Sie können die referer dieser POST-Anfrage überprüfen, aber wenn sie von einer https-Seite kommt, wird dieser Wert leer sein. (was dann den Dienst ablehnen könnte ...). Das Senden der document.location als eine POST-Variable wird nicht empfohlen, da es einfach ist, dieses Widget zu ändern, um einen geänderten Wert zu melden. Der Referer in der eingehenden HTTP-Anfrage ist jedoch off limits to the website's operator.