On Mon, Jun 20, 2011 at 11:41 AM, Robin Berjon <[email protected]> wrote: > On Jun 2, 2011, at 09:53 , Marcos Caceres wrote: >> Consider this scenario: the widget requests access to www.google.com. >> On a local level google redirects to .pl or co.in . With WARP, if we >> checked redirects the local google page would be blocked. It would be >> impossible for any developer to take care of all those country wide >> domains in the normal way (and it does not scale). So we would want to >> allow this. Also in widgets XHRs resulting in 301s are followed and >> the final content is returned (this wasn't how it worked but was fixed >> later). >> >> For a future version of WARP to work effectively, the spec should give >> the option of allow for redirects (or should do this automatically): >> >> <access origin="http://x.com"; redirects="true"/> > > That's a security hole begging to happen. A lot of perfectly legit sites have > a built-in redirect service. People use that, notably, to be notified of when > a user leaves their site through a link they clicked, so instead of linking > to http://berjon.com/ they link to > http://nyt.com/redirect?to=http://berjon.com/. > > So with your suggested approach, all a malicious widget has to do is request > access to a perfectly valid data source under whatever false pretence, and > then use its redirector service to go to evil.com, or to hit stuff that > should be hidden on your private network: > > // grab all of Marcos's print jobs > > http://perfectly-legit.com/redirect?to=http://localhost:631/jobs?which_jobs=all
How it is any different in a browser? -- Marcos Caceres http://datadriven.com.au
