Preventing cookie/session theft via local javascript attack

Red Squirrel

No Lifer
May 24, 2003
67,979
12,401
126
www.anyf.ca
I wrote my own web based password manager in php, it works locally, and one attack vector I've always considered is a malicious site could perhaps use XSS attack to fetch a password from the site if I'm logged in to it. Now since this is a fully custom thing that I never released to the public, the odds of that are super slim, but let's just pretend this was actually a mainstream piece of software, what is the best way to prevent this sort of attack?

Essentially say you login to the password manager, so you get a cookie for a session so the next time you go you don't have to login again. You can look at all the passwords. So let's say you were to go to a malicious site, it could then use javascript to do a http request to the local site from within your browser, since you're logged in to the site, it will have access, and then it can relay password info to it's own server via an ajax request or similar call. The js is basically telling your browser "go to this site, get this info, and send it to this server".

Is there a way from a coding perspective to actually stop that from being possible other than very short session times? Or is this just the nature of the beast and why banks and such do in fact have such short session times?
 

lantis3

Senior member
Oct 18, 2023
234
48
61
Can Javascript request local access from another session? As I understand it, if it can, then that will be very serious problem. I think only very, very old browsers allowed that.


Well, TL; DR
 
Last edited:

Red Squirrel

No Lifer
May 24, 2003
67,979
12,401
126
www.anyf.ca
Looks like the HTTPonly flag stops that from being possible, I do have that set to true in my setcookie function so looks like I'm safe already. That's good to know.
 

ssokolow

Member
Jun 15, 2024
25
9
46
ssokolow.com
Take a look at the OWASP Cross Site Scripting Prevention Cheat Sheet.

Also, make sure your site declares a Content Security Policy which doesn't allow inline resources and doesn't allow resources from domains user-uploaded content lives on.

Also, if you use any CDNs for subresources, use Subresource Integrity hashes so they can't change under you. (Though, these days, there's really no benefit to not hosting your JavaScript yourself, since browsers started including the top-level domain in the cache keys to combat more subtle forms of user tracking.)

Together, those should prevent the browser from actually executing any JavaScript or JavaScript-hidden-in-CSS that gets injected, so they're a great Defense in Depth measure.
 
  • Like
Reactions: Sgraffite