Here's the proposed client-side fix: http://dev.rubyonrails.org/ticket/7910
On Apr 3, 6:36 pm, "Charlie Vaske" <[EMAIL PROTECTED]> wrote:
> I came here via Bruce Schneier's link to a paper on JSON hijacking 
> where Andrew Dupont commented that Prototype Core has discussed a
> solution. I couldn't find anything in the archives, and didn't get a
> response on IRC, so I hope I'm posting this to the correct place! If
> not, my apologies.
> As I understand it, the problem is that an attacking website can have
> first dibs on private data from a web app by modifying the object and
> array prototypes and then using <script> to GET the data. I see two
> requirements for such an attack: 1) the response is straight JSON and
> 2) the data is available via a GET from an URL that the attacker can
> guess. So far there have been suggested fixes that break each of the
> requirements, by either sending a modified JSON response that can't be
> eval()ed, or by putting the data either at an unpredictable URL or
> making it unGETable.
> Having drunk the REST and JSON koolaid, these solutions taste a little
> bitter. I'm wondering if there's another solution, one that means
> drinking even more REST koolaid: keep straight JSON, keep a
> predictable URL if one wants to, drop the unRESTful cookie
> authentication, and go with simple HTTP authentication.
> JSON hijacking breaks cookie authentication because the shared secret,
> the cookie, is sent with any <script> requests, even if the <script>
> tag isn't on a page from that domain. However, I believe that HTTP
> authentication used with an XMLHttpRequest will not be used in
> subsequent GETs to that URL, so the data can't be hijacked.
> HTTP authentication is often avoided, because all browsers that I know
> of have absolutely terrible UIs for it, e.g. it's impossible to
> "logout" without closing the browser, and "logins" can't persist
> between closing and opening the browser. However, it need not be like
> that for AJAX requests. I believe that an attacking websites don't
> have access to the cookies, meaning that HTTP authentication username
> and password can be sent and stored on the client via cookies, and
> then your own app looks up the cookies when it sends its
> I see this as a much more natural fix, and it has the additional
> benefit that by using HTTP authentication, secure data is now more
> easily accessible to robotic UAs. I.e., it will allow your web app to
> be mashup friendly *and* secure, with the caveat that the user must
> trust whatever third party masher, and give them their password.
> Can anyone see holes, or have a critique? I'd love feedback.
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to firstname.lastname@example.org
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at