You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current draft prevents cookies marked as 'Secure' from being overwritten or evicted from a non-secure origin (e.g., section 5.4), but it does nothing to prevent JavaScript from overwriting a cookie marked as 'HttpOnly' by evicting it from the cookie store. In current browsers it's therefore possible to tamper with the integrity of cookies marked with HttpOnly from JavaScript (e.g., XSS attack) despite the specification stating access should be restricted from non-HTTP APIs.
In my view we should protect both confidentiality and integrity for HttpOnly cookies, which could be done by adding a condition that cookies without the HttpOnly attribute should be evicted first when set from a non-HTTP API (e.g., JavaScript).
The text was updated successfully, but these errors were encountered:
mnot
changed the title
RFC6265bis: Shouldn't the browser evict non-HttpOnly cookies first to avoid overwrite from JavaScript?
Shouldn't the browser evict non-HttpOnly cookies first to avoid overwrite from JavaScript?
Dec 12, 2017
I'm wary of changing eviction rules more than we already have. We ended up breaking some Google sites with our Secure prioritization, and ended up with a somewhat complicated scheme to use https://tools.ietf.org/html/draft-west-cookie-priority-00 to solve the problem. I'm a bit reluctant to go through that again without some commitment from Apple and Mozilla that they'd be willing to do the same in much the same timeframe.
@johnwilander, @mozmark/@annevk: Is this something you could find out whether folks internally were interested in doing?
The current draft prevents cookies marked as 'Secure' from being overwritten or evicted from a non-secure origin (e.g., section 5.4), but it does nothing to prevent JavaScript from overwriting a cookie marked as 'HttpOnly' by evicting it from the cookie store. In current browsers it's therefore possible to tamper with the integrity of cookies marked with HttpOnly from JavaScript (e.g., XSS attack) despite the specification stating access should be restricted from non-HTTP APIs.
In my view we should protect both confidentiality and integrity for HttpOnly cookies, which could be done by adding a condition that cookies without the HttpOnly attribute should be evicted first when set from a non-HTTP API (e.g., JavaScript).
The text was updated successfully, but these errors were encountered: