4 ms·
> The other reason is: If a user figures out a way to upload javascript and have it work, you don't want them to steal other users' login cookies. This was sol
by aaronmdjones 1y ago
> The other reason is: If a user figures out a way to upload javascript and have it work, you don't want them to steal other users' login cookies.
This was solved a long time ago by marking such cookies as "HTTP only", preventing client-side scripts from reading their values.
Google does mark their account login cookies as both "Secure" (sent only over HTTPS) and "HttpOnly" (not exposed to client-side scripting). You can see this in the server response headers in the browser dev tools' network tab. Even a piece of first-party JavaScript loaded directly from google.com -- even with SRI -- cannot read these cookies for google.com.
- michaelt 1y ago> This was solved a long time ago by marking such cookies as "HTTP only" That stops the attacker from exfiltrating your cookies with their evil JavaScript - but they can still have their script make http requests, and they’ll be made with your cookies. Or they can throw up a fake login page, which will fool plenty of users because it’s on the right URL, and do what they like with your inputs. Lots of attack options.
- blincoln 1y agoThis is true, but additionally, the HttpOnly flag is now mostly a relic, because so much web app logic runs in JS in the browser and makes API calls. That code generally needs access to tbe cookies, or something equivalent, like a bearer token.