TL;DR this post is full pain, theory and utopia. Don't mind to read if you don't care about better designed web.
Cookies. They made web broken.
Problem 0 [solved, unrelated]: tampering.You can sign cookie with session_secret or store only random string associated with session to prevent tampering.
We invented httpOnly to make critical auth information inaccessible from client side and XSS. We were too stupid to make everything httpOnly by default and only few, really needed on client side httpAccessible or something.
Problem 2 [worked around] Clickjacking, framing.Framed website received your cookies. There is nothing bad in framing any website without sending auth cookies.
We invented X-Frame-Options to deny "showing" of actually *received* private information. Cool, huh? Response with message: "don't read it if you're wrong person". And, look at some PoC.
Bonus question: Why ClearClick(checks visibility of frame on click) technology is not built-in? It is so easy, isn't it.. But Google has AdSense. AdSense is multibillion business and they have powerful tools to detect clickjacking - people, bots, data mining. Other companies( newbies in web advertising) are easily clickjackable. It's called competitive advantage
Problem 3 [worked around]: CSRFMy old articles: CSRF Is Vulnerability in All Browsers and CSRF in 15 Popular Websites
What is CSRF, in a nutshell? Is this just a request from domain1 to domain2? No, if you want such request you can use curl, so core 'benefit' of CSRF is usage of User's cookies for domain2.
This is how cookies work from its creation: you set them once and they are sent automatically, from all hosts/origins and for all kinds of requests(<script>, <img>, <iframe>).
Requests are always sent with your cookies. The very core, key problem.
We invented CSRF Token to make sure that Cookie was sent from proper origin intentionally, not from unknown malicious website. This is just so damn stupid: token to protect another, automatically-sent token.
Auth cookie is "key", CSRF token is "another key", proof that "key" was used intentionally. U MAD
Problem 4: [not solved]: Advanced CSRFRemember JSON leakings? Discovered 4-5 years ago, it was on Hacker News again yesterday.
It all happened because information was actually received by malicious website. All it needs is a trick to extract it. Previously people could reload Array constructor. Who knows what's next? Stealing plain text tokens through ECMAScript Proxy object(analog of method_missing)? Through styleSheet definitions? Through <audio>/<video> stream or canvas? about:blank referrer? Yet another flash vuln?
Jesus, I'm tired of this.
Maybe we are doing it all wrong..?
It's never too late to make something right.
Don't use my Cookies until I decide to use it myself.
originOnly flagwith such flag the Cookie will be sent only when request's origin is equal this cookie's domain. If it was set on site.com than it's sent only if element(<img>, <form>, <script>, style, <iframe> etc) or XHR was executed on this domain. Or if user navigated to this website(opened in a new tab or clicked link somewhere else)
Why I wrote this?
I want web to be ideal. I want web to be like Mona Lisa: perfect or close to it (in terms of architecture)
Yes, this post is utopic, I just want more people to think about the problem, not about yet another workaround.
"It will break "like" buttons and sometimes useful cross POST whatever..."
If you don't need this flag - don't set it. Just let other 99% of websites to be safe-by-default, not waiting for yet another 0day "trick".
Would love to discuss it with web security minded people! Please, write your thoughts!
I think this is a lovely idea which is why we've been working on it at mozilla for some time now. See https://bugzilla.mozilla.org/show_bug.cgi?id=795346ReplyDelete
yes, looks great, is there any progress with chrome and other html5 guys? sameDomain, it could be a standardDelete
just looked at your profile.. SameDomain - Preventing CSRF with a cookie attribute (formerly OriginOnly) it was called originOnly too? LOL, it feels like i stole the ideaReplyDelete
This is more common than you'd think. I remember feeling angry with another researcher years back for "stealing" another idea once until I found out other people had published independently too!Delete
this doesn't stop same origin CSRFReplyDelete
Strictly speaking, if it's same origin it can't be CSRF (just RF)... but yeah, that's a known limitation.Delete
if you actually meant same-origin-csrf known as XSS - there is no cure for it. And never will be. CSP maybe..Delete
A lot of sites let users post links/images, and a lot of CSRF can be performed with GET requests.ReplyDelete
1. yes, e.g. facebook. they do it via iframe. this is not csrfDelete
2. no, in godo website GET = read only
Great article and a valid point. But why not just have this behavior as default (don't send cookie cross-domain) and have a wildcard policy for domains added like path ?ReplyDelete
Set-Cookie: HITHERE=secret; path=/; domain=*.mysite.com; secure; HttpOnly
this is a breaking change, browsers are not gonna do soDelete
Sure, but so is an originOnly flag. All I meant was that if a change like this would happen, might as well make it customizable and the people wanting this behavior (like buttons etc) has nothing to complain about.Delete
originOnly would not break BC. You'd have to explicitly specify it just like HttpOnly; existing websites would not need to change anything to keep working just like they do today.Delete
Congrats, there is SameSite now :)ReplyDelete