Hot answers tagged

25

Replacing < and > characters isn't enough in all cases. Sure, it will prevent any user to open a HTML tag, but that won't prevent him/her to inject HTML attributes in a HTML tag. For example, let's take a parser which transforms [img=XXX] into <img src="XXX" />, only replacing < and >. A malicious user could enter [img=X" ...


21

It may be enough, and it may not be, but it is definitely not a good idea. Can a hacker still get away with a XSS? Possibly, depending on the situation. @BenoitEsnard already described one situation where filtering out < and > is not enough: When the user input is echoed inside attributes of existing HTML tags, because then an attacker could ...


10

You can try console.log('XSS').


8

For testing purposes, I think the most useful one is a HTTP request. This allows your server to log URLs which successfully reflected the XSS. (new Image()).src = "https://localhost/log_xss?from=" + window.location; You can also wrap it in a userscript: // ==UserScript== // @match <all_urls> // @run-at document-start // ==/UserScript== ...


7

XSS is not an attack on your application; it is an attack on your application's users. As a rule, there is no specific threat to the server itself from XSS. As you have a fairly simple application, you don't suffer from some of the more prominent issues XSS generally creates, like stealing authentication tokens and executing site functionality ...


6

With DOM-Manipulation one could change the page itself. In case one knows the target page, it can be manipulated in some nice ways. An easy example would be: document.body.innerHTML = 'XSS';


4

It's definitely not a good idea to put raw user input directly into styles. Is CSS injection as bad as XSS? No, but there are still problems with it. Some of these examples below don't apply to you as quotes are required, but I'll include them anyways for readers interested in CSS injection in general, and to show that CSS is more powerful than generally ...


3

The blog post from Paul Moore holds back quite a lot of information, probably on purpose, seeing that asda hadn't fixed the issue when he published the post. Here is an article that is a bit more explicit about the vulnerabilities of Asda. CSRF Vulnerability First of, they did not seem to have any CSRF protection: There is no XSRF protection ...


3

So landing an XSS where there's some filtering can be done a number of ways. An important consideration is where user input is appearing in the resulting page. For example if the user input is landing in the middle of a JavaScript block then the filters you're seeing won't really slow you down at all, something like ');alert(1); might work just fine. If ...


3

How about </script><script>alert('xss');</script><script>/* ? JS parser will find the close script, and assume the original code is malformed. HTML parser will see the open script and start a new script block. The rest is just to make the rest of the block ignored. Note that it doesn't contain any of the characters you're ...


2

There is an XSS explotation framework called BeEF which allows for a number of different types of attacks once a "hook" can be placed using XSS (or other means). It displays a list of hooked browsers and then gives an attacker a number of different ways to attack them. Some of these attacks including phishing for gmail usernames/passwords using very ...


2

If you're vulnerable to XSS. The attacker can execute any code you could. He could steal (session-)cookies, edit the DOM and craft a phishing-page, hook the BeEF-framework on victims,... And because you're using GET, he could craft the URL and it's parameters to include the malicious payload and send it to anyone. Anyone opening that link then executes the ...


2

No, otherwise anyone could make a website with an XSS vulnerability, get the victim to visit it and then they would be able to steal all the user's session cookies. Also, XSS isn't anything about tabs.


2

Depends on how well the browser has implemented tab separation and cross-site origin policy. In modern browsers, no, you won't be able to do that. It would be possible to write a non-standard conforming browser that would allow you to access third party cookies, but at that point, the attacker can do much more interesting things, so being able to steal ...


2

I usually do a Google image search for an amusing image, save this to my own HTTPS server and then create an <img /> tag using the XSS vulnerability. With a bit of imagination, this can demonstrate the vulnerability in a humorous way. Also check out the http://www.xss-payloads.com/ site for other interesting payloads.


1

XSS is still possible even in newer versions. But it depends how the JSON is used. The article you reference cares only about executing JSON by itself, i.e. accessing a JSON document via a link. It does not discuss the case when you return JSON from an XHR request and then include the received data directly with document.write or even interpret it with ...



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