New answers tagged

0

Actually, even if that header could solve the problem, the second part is a human factor: the hosters/developers/webmasters are about to use it, actually...


15

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 ...


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)...


0

Its a server-side vulnerability that can be exploited via client-side applications.


0

I've read some people who care about not using the url or whatever to load different user info or whatever (such as some here in google's tutorial - https://xss-game.appspot.com/) While that's nice to be aware of, you gotta remember that every single function and piece of code on the client side can be arbitrarily executed. Validation and protection for ...


0

About your second question, the main idea is to understand what is part of the code and what is part of the application data, then you should think how the application data are validated or encoded , for example, if you have a search function, you might have something like this: <input id="search" name="search" value="something" /> If you replace ...


0

Within the source of the page you linked, you can find the source CSS. As hinted by @Numeron, you will find this contains the following: #next-controls { margin-top: 20px; display: none; } I recommend opening this page in Chrome, using the Inspect feature, and toggling off/on the display: none; line in the CSS. Then, you will see for yourself the ...


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 += '<...


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 ...


0

It will depend, but if there's another place where user input is inserted, these 10 characters would be enough to fool the browser into parsing it into another context. Suppose that there is below an image (eg. an avatar) that can be controlled by an attacker, including the alt text. An attacker could set: <img src="myimage.jpg" alt="--><script>...


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 ...


0

If untrusted data can be everything, we could inject for example --><script>alert("I just escaped the HTML comment")</script><!-- which would make it appear in source code like: <!----><script>alert("I just escaped the HTML comment")</script><!---->(Note the empty comments)


-1

The article is proving that an HTML form can be used to send a JSON object via CSRF, even if the server-side is only accepting text/plain requests expecting JSON. (instead of the typical application/x-www-form-urlencoded) requests. I've included the linked example on this site, because we do not allow link-only content. <html> <form action=http:/...


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 ...


0

This attack worked for a very simple reason - TweetDeck did not sanitize the user input at all under some circumstances. The attacker did not discovered a clever way to fool the XSS filter. Instead he found a a way to turn it off. As your quote says: So, I started to play around, and discovered, that the Unicode-Heart (which gets replaced with an image ...


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....


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 ...


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 ...


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 ...


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 ...


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....


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/...


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 ...


0

The Access-Control-Allow-Origin is a CORS header meant to check whether the request came from the same domain or not. The request is indeed sent from the same domain, but you might not have said so in the HTTP request header. I don't have much insight in your precise problem, but to me you should specify the Origin header: var xhr= new XMLHttpRequest(); ...


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 ...


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 ...


0

Within a HTML5 <title> tag, it is not possible to inject new elements without allowing slashes. Since your browser's HTML parser is a state machine, you can simply follow the state transitions of the tokenizer (per the HTML syntax specification) and see how far you get. In your case, a <title> tag in the head section evokes the "generic RCDATA ...


1

There is no way to get the password directly You can not get the user password directly from the forum. Simply because you cannot access the browser using javascript. So you will not be able to get the saved passwords in the browser. This would be a huge security failure There are 2 ways to access an account from a XSS vulnerabilty As we saw, it isn't ...



Top 50 recent answers are included