2010-10-22 12 views
6

Sto pensando di intraprendere un nuovo progetto. La premessa del progetto è generare un widget sul mio sito, quindi copiare un pezzo di javascript nel tuo sito e viola hai il tuo widget.Widget javascript privato

È una novità per servizi esistenti come polldady.com, twiig.com e addthis.com.

Molti di questi servizi sono progettati per essere accessibili al pubblico. Significa che il fornitore di widget non si cura che tu stia inviando i dati a loro. Infatti incoraggiano a diffondere il widget il più lontano possibile.

Tuttavia i miei servizi hanno una svolta unica. Nel mio caso, anche se il widget sarà aperto al pubblico, devo essere sicuro che le richieste di post di origine provengano solo dal sito previsto.

A causa di problemi di xss con questi widget javascript, ho bisogno di creare dinamicamente un iframe in cui verrà reso il mio widget.

Esiste un modello di autenticazione per gestire questo tipo di interazione?

risposta

3

Prima di tutto questo uso di un iframe è una violazione dello Same Origin Policy. Con il semplice vecchio JavaScript è possibile creare un <form> e chiamare .submit() per attivare questa richiesta di post ovunque. In effetti, questo è il modo in cui gli exploit di CSRF basati su POST funzionano. È possibile controllare lo referer di questa richiesta POST, tuttavia se questo proviene da una pagina https questo valore sarà vuoto. (che poi potresti rifiutare il servizio ...). L'invio di document.location come variabile POST non è consigliabile poiché è banale modificare questo widget per segnalare un valore modificato. Tuttavia il referente contenuto nella richiesta HTTP in arrivo è off limits to the website's operator.