I have a code like this:
$('.' + InjectionPoint).removeClass('classname');
where InjectionPoint is the part controlled by end user, apparently this code is vulnerable to DOM XSS, but is it really exploitable? and how should an attack vector be like?
Thanks
On what are you basing your belief that "this code is vulnerable to DOM XSS"?
Based on this answer, that was true in older versions of jQuery, but not any version later than 1.6.3: https://stackoverflow.com/a/11170073/877682
This is definitely subject to XSS. Check out this article which describes how an attacker might go about it: https://ttmm.io/tech/jquery-xss/
Basically, the author recommends that you use document.querySelectorAll() instead of the jQuery selector function. Someone commented that this is a non-issue for jQuery 1.7 and above but don't quote me on that.
In general, it's never ever a good idea to trust what your users give you.
Related
I have a website that is only accessible via https.
It does not load any content from other sources. So all content is on the local webserver.
Using the Retire.js Chrome plugin I get a warning that the jquery 1.8.3 I included is vulnerable to 'Selector interpreted as HTML'
(jQuery bug 11290)
I am trying to motivate for a quick upgrade, but I need something more concrete information to motivate the upgrade to the powers that be.
My question are :
Given the above, should I be worried ?
Can this result in a XSS type attack ?
What the bug is telling you is that jQuery may mis-identify a selector containing a < as being an HTML fragment instead, and try to parse and create the relevant elements.
So the vulnerability, such as it is, is that a cleverly-crafted selector, if then passed into jQuery, could define a script tag that then executes arbitrary script code in the context of the page, potentially taking private information from the page and sending it to someone with malicious (or merely prurient) intent.
This is largely only useful if User A can write a selector that will later be given to jQuery in User B's session, letting User A steal information from User B's page. (It really doesn't matter if a user can "tricky" jQuery this way on their own page; they can do far worse things from the console, or with "save as".)
So: If nothing in your code lets users provide selectors that will be saved and then retrieved by other users and passed to jQuery, I wouldn't be all that worried. If it does (with or without the fix to the bug), I'd examine those selector strings really carefully. I say "with or without the bug" because if you didn't filter what the users typed at all, they could still just provide an HTML fragment where the first non-whitespace character is <, which would still cause jQuery to parse it as an HTML fragment.
As the author of Retire.js let me shed some light on this. There are two weaknesses in older versions of jQuery, but those are not vulnerabilities by themselves. It depends on how jQuery is used. Two examples abusing the bugs are shown here: research.insecurelabs.org/jquery/test/
The two examples are:
$("#<img src=x onerror=...>")
and
$("element[attribute='<img src=x onerror=...>'")
Typically this becomes a problem if you do something like:
$(location.hash)
This was a fairly common pattern for many web sites, when single page web sites started to occur.
So this becomes a problem if and only if you put untrusted user data inside the jQuery selector function.
And yes the end result is XSS, if the site is in fact vulnerable. https will not protect you against these kinds of flaws.
Can somebody please explain the pros and cons for below.
Am having a function to get the url querystring parameters, but I need to know which is the best way to write the function. Eg: if i create the function using jquery plugin style, then every time I need to use a target element to access the function as below
$("#targetDom").getQueryString("name");
However, if I create the function using javascript classes or javascript design pattern, it would be
getQueryString("name");
This is a small example but considering large application which approach is best? is there any disadvantage in going with jquery plugin way?
Regards,
Navin
I found a while ago this sentence:
Don't learn jQuery. Just use it.
It's one of the best advices for a newbie, I think.
jQuery is just an addition to javascript. It simplifies DOM traversing/manipulation, makes easy event handling and so on, but it is not something you should start learning before you know vanilla Javascript.
Regarding your example, it is not the best thought example for jQuery plugin.
The syntax you suggested ($("#targetDom").getQueryString("name");) implies that you treat URL query string as attached somehow to the HTML element, which is wrong...
I have an <img id="mypic"> that i need to change with an interval its src.
Should I use jQuery or not?
Should I do:
document.getElementById('mypic').src='src2';
or
jQuery('#mypic').attr('src','src2');
It...doesn't really matter. I'd say use jQuery if you are using it in other places in your code, otherwise..it is up to you. However, if you are doing this in an interval, it would be slightly (but not noticeably) faster to use natural JS.
Use JQuery if the benefit of having convenient selectors and AJAX support is worth the 29 KB it'll add to your page download time. For most of my uses, it is worth is.
Also, for your JQuery code snippet, the $ character is the JQuery selector. So, you can do this:
$('#mypic').attr('src','src2');
In my opinion, JQuery is very concise, and you can get a lot done once you get used to it.
You should not use jQuery if you don't know how to do it in plain Javascript.
Looks like you know, feel free to use it :)
I've tried some of the editors/IDEs regularly recommended for coding JavaScript (Aptana, WebStorm, ...) but none of them has a satisfying autocomplete functionality. I'm probably spoiled by Microsoft's IntelliSense for .NET. There is some JavaScript-IntelliSense in WebDeveloper, but that seems to be a stripped-down version. The best I've found so far is WebStorm, but its code completition is easily distracted by imported libraries (offering hundreds of suggestions) and identical function names.
Did I miss an editor/IDE that uses refactoring (or something else) to offer proper code completition, so that it really "knowns" what that variable-name stands for, I just put a dot behind? Or is something like this on its way?
I always recommend Komodo Edit from ActiveState (now up to version 6, with support for HTML 5 and CSS3 as well as recent versions of Javascript, PHP, etc.) Note that you may have to install addons for the languages you're working in, but you should find them through the Mozilla-like Addon manager.
Also supports jQuery and even lets you use jQuery (along with vanilla Javascript or Python) in its powerful macro IDE.
Code completion example:
<script type="application/x-javascript">
var obj = {};
obj.personnel = [{firstName:"John", lastName:"Brick", age:43},
{firstName:"Jane", lastName:"Motte", age:26}
];
// now type obj. and code completion immediately offers you "personnel"
// note: file must be saved for the app to find all members of declared
// variables, but I save about every 10 seconds so it's not a problem
</script>
The best I've found so far is
WebStorm, but its code completition is
easily distracted by imported
libraries (offering hundreds of
suggestions) and identical function
names.
This comment confuses me. If you import the libraries, and your code is using them, why is it bad to include the function names in the code completion suggestions? Wouldn't you want to have jQuery's functions included if you're using it?
If you're using Microsoft's IntelliSense with jQuery, does it stick to its guns and only show JavaScript core functions? Sounds limited to me, unable to be smart when I add libraries.
Or is something like this on it's [sic] way?
It sounds to me like you want a clairvoyant interface. I don't think it is on the way anytime soon.
By the way, "it's" == "it is"; "its" is the possessive.
Is it, in any way, possible to disable the browsers execution of script inside a block/section/element ?
My scenario is, that I'm letting my (future) users create "rich content" (using CK-editor).
Content that wil later be shown to other users - with all the dangers that imply: xss, redirection, identity theft, spam and what not...
I've, more or less, given up on trying to "sanitize" the incomming XHTML, after seeing how many known "vectors of attack" there are: http://ha.ckers.org/xss.html
What I'm really looking for is something like:
< div id="userContent">< scriptOFF>
suspect HTML
< /scriptOFF>< /div>
The ideal way is to not accept html/javascript from the end users. If you are okay with that limitation, you just need to make sure you encode the output according to the appropriate context. Don't re-invent the wheel, just use an existing library for that purpose.
But if you must accept HTML, use a library like OWASP's ANTI-SAMY or HTML Purifier. They were built exactly for this purpose.
You have to sanitize the input, there is no way to selectively disable javascript that I know of.
It is important to use a whitelist of allowed tags, not a blacklist. That way it should be possible to do it safely.
Even if you used a "noscript" tag or a "textarea" tag its sill xss. Whats keeping the attacker from injecting closing tags?
< div id="userContent">< scriptOFF>
<?=$_GET['xss']?>
< /scriptOFF>< /div>
But its still xss:
http://localhost/xss.php?xss=< /scriptOFF>< /div> <script> alert(/still_xss/) </script>
Yes, but that would "whitelist" would be HUGE - and I'm far from competent enough to detect subtle loopholes, alá those described here: http://ha.ckers.org/xss.html
This would need to be a "community effort" - looking at HTML-purifier (http://htmlpurifier.org) now...
I just thought it would be great to have such a tag to prevent 99% of the XSS "vectors"
Can "anyone in power" please convince the browser-makers to implement it : )
Edit:
Alright. HTML-purifier it is!
- thanks to everybody for replying : )
#sri mentioned where to find "html5 iframe sandbox" information,
here is a test script.
What you should see is "Browser supports iframe sandbox attribute :)" is you are viewing in Chromium.
Might also get positive results in khtml/webkit based browsers like phone browsers.
Opera 11, Firefox 3.6 and Firefox4 have yet to implement the sandbox attribute.
Article explaining background and current state at gnubyexample.blogspot.com
No, but then again you should definitely not be allowing your users to hand-feed code into the page in the first place.
Don't attempt to sanitize Javascript; do not allow Javascript. In fact, do not allow HTML at all. Write your own limited markup language (ala BBCode) or allow a select few HTML tags if you really have to.
i.e. Be additive rather than subtractive with your security endeavours.