Re: Do we need to rename the Origin header?

Adam Barth wrote on 7/16/2009 12:38 PM: 
> On Thu, Jul 16, 2009 at 8:47 AM, Bil Corry<bil@corry.biz> wrote:
>> I think you mean everything will NOT be privacy-sensitive except non-XHR GETs.
> 
> I don't think we've quite settled on exactly what will be privacy
> sensitive.  It's most likely that POSTs and XHR will not be and that
> hyperlinks and image loads will be.  The goal is to harmonize with the
> Mozilla proposal.

I still think same-origin GET should not be privacy-sensitive.  Here's a real-world example of where it would have helped, a CSRF-hole in Facebook recently disclosed:

---8<---
   1. User naively surfs to a well-known and trusted forum at forum.com.
   2. The thread he is viewing contains a malicious comment with an IMG tag point at quaji.com
   3. The user's browsers attempts to retrieve the image
   4. but instead is redirected to http://apps.facebook.com/hacker-app/step1.php.
   5. The request is forwarded through the Facebook platform,
   6. to the hackers app server
   7. and is again redirected to http://apps.facebook.com/hacker-app/step2.php.
   8. and back to the browser.
   9. Browser attempts http://apps.facebook.com/hacker-app/step2.php
  10. The Facebook platform passes the request to the hacker's app server adding the user's personal information after being tricked into thinking it should do so.
  11. To finish off, a redirect is issused to a proper image.

(from: http://blog.quaji.com/2009/08/facebook-csrf-attack-full-disclosure.html)
--->8---

So in the above redirect drive-by, Sec-From on the request would have been seen as "null" by Facebook.  And with GET being denoted as privacy-sensitive, even legitimate GETs would be seen as "null" by Facebook.  But if same-origin GET wasn't privacy-sensitive, Facebook could then tell the legitimate GETs originating from their own domain because they would have a Sec-From with their domain.


- Bil

Received on Monday, 24 August 2009 23:06:53 UTC