random bits from the weekend
Jul. 25th, 2004 10:42 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
cellio(Noted in passing: fourth season of West Wing in September; second season of Blake's 7 allegedly in October.)
I sometimes wonder about the security implications of the quizzes and other memes that run around LJ. Consider: your passowrd is (I think) stored in a cookie. You follow a link while reading your friends page (so you're probably logged in) to some unvouched-for site where you give your user name as part of getting some bit of content to post in your journal. I don't know a lot about cookies, but isn't it fairly straightforward for a malicious meme-writer to harvest your password that way? I try to never fill those things out while logged in, personally. (Yes, I do sometimes fill them out, out of curiosity -- the ones that are likely to have interesting content, like the mind map and the friends-list-evaluation ones, not the "what kind of eggplant are you?" ones.)
The two instances of Giant Eagle that I shop at seem to have both stopped carrying my cats' favorite food (Tender Vittles). While googling to try to find out if the product had been discontinued (no one at the store seemed to know anything), I found a place where I can mail-order it by the case for about what I normally pay for it. Ok, that works. Gee, I wonder if I can mail-order the cat litter under similar circumstances, rather than shlepping it home from the store myself? I'll have to try that.
This afternoon I attended a bridal shower for a friend. I so do not know how to be a girly girl. :-) It was a fun time, but there was a lot more estrogen in the air than I'm used to.
(no subject)
Date: 2004-07-25 07:55 pm (UTC)So if the cookie is stolen, it's not easily used, possibly not usable from any other computer.
Also, most broswers these days have a setting or simply a limitation that they will not send a cookie to any server except the one which sent it. So if JRandomServer.com says "Show me your LJ cookie", your browser will probably ignore it.
(I believe that IE allows you to set it into promiscuous mode, "sure, share my cookies with anyone who asks.")
Å
(no subject)
Date: 2004-07-25 08:05 pm (UTC)I'm pretty sure Netscape had the setting you describe for sending cookies only to the issuer. I can't find such a setting in Mozilla; with luck that's because it always imposes this restriction, but I'm not sure how to find out. (Maybe it's in the documentation somewhere.) I'm pretty sure IE behaves as you've described, but I'm not currently using IE except for inspection of local files at work (a requirement).
(no subject)
Date: 2004-07-25 08:08 pm (UTC)(no subject)
Date: 2004-07-25 08:51 pm (UTC)Er, to the best of my knowledge, Javascript can't be used to fetch a document and send it somewhere. (VBScript and ActiveX, all bets are off). Javascript can navigate your browser window somewhere, but I don't think it can download to your machine, nor to send a copy of a retrieved webpage someplace else. So, no, I don't think you could read private entries that way.
To be clear: Javascript runs "in the document"; there's no concept in the language as instantiated on client-side (browsers) of standing outside a document to manipulate it. Client-side javascript has, to my knowledge, absolutely no HTML-capture mechanism!
or maybe change your password (does that require you to re-enter the password? I think it does, in which case the script couldn't exploit it
Yes, LJ requires you to re-enter the old password.
Hmmm. Now you have me brainstorming JS security hacks.
Howzabout: If you can get the user to load a malicious JS into their page (social engineering), which, on-load, asks for the value of an LJ authentication cookie and writes that into an input of type hidden, and on exit, POSTs that cookie to a malicious server. Server now has a cookie of your LJ authentication cookie and your IP number. Malicious server owner now spoofs their IP number (don't know how hard this is) and declares itself to be you, under the reasonable presumption that the LJ authentication token maps to IP number. You are then logged in as that user for as long as the cookie is valid.
This would be foiled by the cookie being browser-specific, which may be (*should* be) the case. This is, I suppose, easily testable (though not by me from home) by copying the entry in one's cookie file into the cookie file of another browser, and seeing if you're suddenly logged in in that browser, too.
OK, here's something that might allow some evil:
Get user to embed the malicious JS. On page load completion, it redirects to a page that is essentially a GET to the malicious server, with a single parameter, the URL of the previous page (with the embedded malicious JS.) What the server's response to the GET is (and this is easy) is to serve a frameset page with two frames, one of width=1 (hey, does "width=0" work?) containing an HTML of the server owner's choice, and the other width=* containing the previous page. Now, what the user is looking at looks identical to what they were looking at before, but it's in a frameset on someone else's server. The location bar will reflect the real server you're on (or is there a way around that?) but most people don't watch that.
Now, does that allow anything interesting in the arbitrary HTML of the framset or the width=1 frame contents? Those can contain JS, which now can learn things about whatever is going on in the other frame, maybe?
s
(no subject)
Date: 2004-07-26 12:02 am (UTC)Good point. On closer thought, I can't find a way to make this specific exploit work. I think you're on to some better examples with your brainstorming, although it's hard because LJ tries very, very hard to filter JS out of the user-modifiable parts of the journal for just that reason.
Try this: a server-side process reads your userinfo (which it can do based on your username) and dynamically generates a variation on the post-a-message-as-you javascript that submits the Modify Info form, with obvious data like the info block and interests populated from the old userinfo but with several of the privacy settings (obfuscate email, no spider indexing) quietly set to most open. That's comparatively minor (it would really only make sense to mess with the email settings if your email was at least partially visible already, or the server-side process would have nothing to work with) but might lead to some low-level chaos - if hundreds of people run the meme, at least a few "hits" where it actually caused problems for someone would be likely.
clarification
Date: 2004-07-26 06:52 am (UTC)This is the basic mechanism; the basic "trick" is trying to convince the browser to execute arbitrary JavaScript with greater access than it normally would have, ideally convincing it to execute the JS as if it were the browser's own code but more commonly (barring certain IE bugs) tricking it into thinking that JS from a malicious site came from a more trusted site with more access. IE's "security zone" implementation tends to make this really easy, because there are so many holes in its checking.
In theory. In practice, JavaScript is the "glue" that holds the browser together[*], so it does stand outside of the document. Browsers are supposed to "sandbox" JavaScript from outside sources so that it can't affect global browser state or documents from different sites, but all too often the sandboxes "leak".
* It's more complex than this, but basically true: if arbitrary JavaScript can escape the sandbox, it gains full control over the browser — and even limited escape grants it too much power (cf. the recent Application.Shell exploit which affected both IE and Mozilla).
(no subject)
Date: 2004-07-26 06:22 am (UTC)It can fetch a document in any of several ways, including creating or hijacking a (possibly invisible, at least in some browsers) frame and loading it with the document; it can generate document content on the fly by assigning literal text to the "document" attribute of a frame or to HTML blocks within it; it can POST forms in loaded documents. Combine these, and malicious JS can retrieve a private entry, then POST it to a waiting site. This is the basis of "cross-site scripting" (XSS) exploits.
There are limits to what can be done via XSS, since browsers do in general try to limit the ability of frames associated with different sites to pass information between each other, but I believe it's not fixable in the general case (at least, not while sites expect to be able to load other sites in frames so they can provide their own navigation mechanisms). In particular, XSS subverts IE's attempt to maintain "security zones" for different sites.
Supposedly not in Mozilla; in IE, there were (now patched) historically several ways to do it, some of which periodically get regressed (like embedding a control character in the URL, %00 and %01 having been especially troublesome in the past). Recently some malware sites actually managed to overlay an authentic-looking replacement location bar which showed whatever they wanted it to.
JavaScript essentially is not sandboxed (at least in IE) and has access to pretty much everything in the browser; while it in and of itself may not have commands to perform arbitrary actions, it can command the browser to do anything and it can invoke other mechanisms (Java, VBScript, ActiveX controls, ...) that may be available to the browser.