对于DOM XSS是否是错误的肯定

Question

I used the IBM AppScan to scan my website. And one of the vulnerability is found called "DOM XSS". After investigation, I am suspect that it may be a false positive. Do anyone know is it possible to inject on it basic on my following code?

Answer 1

It just seems like a subdomain parsing routine that sets document.domain to this value for inter-origin communication .

eg if the current URL is http://www.example.com/ then document.domain is set to example.com .

This appears to be a false positive because even though untrusted input is being used to set the domain in order to loosen Same Origin Policy restrictions, setting document.domain is only valid for a subdomain of the current domain, therefore it would be very hard to manipulate this into something malicious.

That is, if example.edu set thier document.domain to example.com then the browser would not accept this because the domain itself does not match and the browser will not allow anything to be set to a top level domain in the case of com is attempted.

Parsing the href isn't the best way to do this - there are other properties available in the location object such as .hostname . If there was a flaw in the parsing routine, it may be possible to trick the code by submitting a hostname somewhere else in the URL:

http://www.example.com?injectedHostname=http://www.example.org

Having said that, I can't see how your current function implementation could be abused.

Answer 2

This isn't a traditional HTML/script injection into the DOM, so it's not what people typically call “DOM XSS”, but AppScan has detected it because data is going from an untrusted source (the document URL) to a dangerous sink (the security-sensitive document.domain property), and that is in general a risky thing to do.

If an attacker can influence document.domain there is indeed the possibility of allowing cross-origin scripting, though it would have to be from a neighbour domain (because document.domain can't be set to eg. a TLD) so that would limit the damage a bit.

If you must set document.domain automatically from the browser address, then in order to do it securely you should (a) read location.hostname directly instead of trying to split apart location.href , and (b) ensure that the application is deployed such that it only responds to its real hostname. If an attacker points their own DNS to your server's IP address, the application should not come up. Once you've done that, you'll still have to ignore the warning.

It would be a much better approach if possible to set document.domain to a specific static value that doesn't come from input (eg take it from configuration).