Hot answers tagged

133

A good option is to harden your Content Security Policy. It allows you to fine-tune which resources the browser will load/run, and is supported by most browsers. Consider the following header: Content-Security-Policy: default-src 'none'; img-src 'self'; style-src 'self'; This tells the browser to disable scripts, frames, connections and any other objects/...


17

Did XSS reach its end-of-life with the introduction of the HTTP X-XSS-Protection header? No. X-XSS-Protection is only used to enable or disable the inbuilt filtering[*] - which is generally enabled by default anyways. So a more fitting question would be if XSS reached its end-of-life with browser filters. But again, the answer is no. XSS is still a ...


8

Are there any caveats to this approach? (security-wise) Yeah, it's not very thorough, you can get a new instance of the constructor from a new window object instead: XMLHttpRequest = null; var iframe = document.createElement('iframe'); iframe.style.display = 'none'; // optional document.body.appendChild(iframe); var XHR = iframe.contentWindow....


5

The relevant entries in the HTML5 Security Cheatsheet are: Ending HTML comments with a backtick character: html5sec#133 (IE6, IE8) Injecting XSS or with a conditional comment html5sec#115 (older IE, IE quirks mode) Apart from that user input might be used to change this comment into a conditional comment (IE only) and thus change the DOM or block the ...


5

Are there any frameworks that work this way? Sure. Twig or Django would be two examples. The inverse of this is clearly a far more secure default, ie. all dynamic data is escaped, unless you specifically tell the framework not to. Yes, this is a lot more secure. Is there something I'm missing? The one downside is that XSS is context-sensitive....


4

This does not look exploitable to me. The only user input here is the location variable. However, it is only used to check if the protocol is HTTPS or not and then change the URL of the included script accordingly. There is no way to sneak any parts of the URL, like a query parameter, into g.src. Also note how it is constructed through concatenating hard ...


4

Parsing BBCode in a safe way that does not open the doors to XSS hell is a tricky task, and there have been many failed attempts. As you yourself note, the way you currently do it is vulnerable to XSS - all you need to do is post [script src="evil.js"]. Just using htmlentities() will not solve this for you, it is much more complex. This blog illustrates the ...


3

Each production IP address has a unique hostname, which is predictable, consistent, deterministic, and entirely useless to anyone but a few engineers who I suspect can read these addresses like a map. These names matter a lot to those people; but for the rest of us we just care that it doesn't create new problems. That's where the XSS comes in, because ...


3

RFC RFC 1945 - which first mentions the referer header - specifies that referers need to be URL encoded: Referer = "Referer" ":" ( absoluteURI | relativeURI ) absoluteURI = scheme ":" ( uchar | reserved ) [...] uchar = unreserved | escape unreserved = ALPHA | DIGIT | safe | extra | national escape = "%" HEX ...


3

You can find the answer if you peak at the source code. The <script> tag does not work because the HTML is not generated by a Python script simply echoing the user input, as in Level 1. Instead, the user input is contained in a JSON file and it is displayed on the page with the help of some JavaScript: html += '<b>You</b>'; html += '<...


2

The user can modify and delete anything stored in their browser. Any malware installed in the user's system with the user's privilege can also do so. The system administrator can also modify and delete anything stored in any user's browser. Any malware with the administrator's privilege can do the same. Another non privileged user in the same system ...


2

The risk isn't that a script such as http://attacker.com/omg.php runs on your domain, it is that a user manages to break out of the <div style='background-image: url("http://example.com/image.jpg")'></div> context where the URL is written to the page. Note the code has been corrected from your question (single quotes used for HTML attribute ...


2

i tried many php scripts like http://attacker.com/omg.php and it doesn't runs the script on my domain .. The problem here would not be a server side vulnerability but more of a reflective XSS vulnerability that runs on the browser not on the server which is why the php file did not work. Taken from OWASP (see here): Reflected Cross-site Scripting (XSS)...


2

Even if this would work and you could block JavaScript from performing XMLHttpRequests - which as shown by @Alexander is not the case (ActiveXObject would be another alternative) - it doesn't really limit the dangers of XSS. An attacker still has a number of possibilities: Defacement Phishing: For example, add a login form, which sends the entered data ...


2

It can, but not directly. This vulnerability does not inject code on your webserver, rather it injects JavaScript that, when you visit the page, will be executed in your browser. What can happen then is that an attacker steals your session cookies and logs onto your wordpress website or redirects you to a malicious page with malware or a phishing website to ...


2

Is carrying out an XSS attack possible? No, 10 characters is not enough to exploit this. If you want to enter a JavaScript context, at the very minimum, you would need: 1 < to get into a tag context 1+ [a-z] for the tag name 1 space 1+ [a-z] for the attribute (in practice, the shortest event attribute that currently exists is onload, which is 6 ...


2

I think the scenario you are talking should be called HTML injection. Sometimes, there might be an XSS filter deployed which does not allow any event attribute (the list is huge) as well as script tags. In that case, "getting XSS is hard". Although, blacklists seldom work to prevent XSS.


2

No, I would not call that cross site scripting, since there is no actual scripting involved. But that does not mean it is not a security risk! The correct term for the vulnerability would be "HTML injection", and as you note in your question it can be a dangerous thing. Here's another example, just to show how HTML injection can indeed be used to cause real ...


1

I suspect the security aspect (their second reason) is related to 1e100.net simply being different from the product domains (youtube.com, blogger.com, google.com). The fact that all servers identify by the same hostname is nice for simplicity (their first reason), but probably not significant for security. I'm not sure exactly what the threat profile is ...


1

Yes,it will work. The CORS header will avoid external requests from perform actions(eg. a malicious link received by email and clicked by the user). If you combine a stored XSS flaw and perform a request on the page load to execute some action,it will certainly work. The request comes from the application domain,so the application/browser will have no way ...


1

Yes, it is a problem, maybe even a big problem, but "XSS" probably isn't the right term. What could possibly go wrong? remote code execution using svg, especially older browsers off-site images leak your user's IP address (aka lat/lon), userAgent, and net performance malicious images themselves been vectors, lots of 0days in the past A special or even ...


1

No, in modern browsers no XSS is possible via the style or src attribute of an <img> tag. So neither of these would execute the JS code in any up-to-date browser: <img src="javascript:alert(1)"> <img src="x.jpg" style=background-image:url('javascript:alert(2)')"> Support for Javascript in CSS attributes has long been abandoned. You can ...



Only top voted, non community-wiki answers of a minimum length are eligible