1

We have just had some pen testing completed against a web application and the one area identified as High Impact and Medium Probability was:

Cross-Site scripting (reflected)

The example given was the ability to manipulate a URL such as:

www.domain.com/application/index.php/<IFRAME SRC=source.com onload="alert(document.cookie)"></IFRAME>

Any data which is actually passed to the application via forms, GET etc are escaped and if you enter the above iframe code into a form and submit or pass it as a GET parameter it "does nothing" but when I go to this URL in a browser, I get varying results depending on the browser ranging from nothing in Chrome and IE to Firefox showing the cookie in a popup.

HTTP response as requested:

GET /application/index.php/%3CBODY%20ONLOAD=alert%28%27XSS%27%29%3E HTTP/1.1
Host: "www.domain.com":http://www.domain.com
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close

Obviously I cannot rely on the user using the correct browser so how can I mitigate against this as the code is being passed in the actual URL itself and, from what I can see, is executed before the application loads so I cannot see how I can escape it if it runs in the URL or am I wrong?

There is no genuine reason why anyone should be passing ', ", < or > via the URL so are there server level controls which can strip untoward characters out of the URL maybe using regex in htaccess, for example?

bhttoan
  • 173
  • 1
  • 7
  • 1
    Merely filtering for those characters will not work for you, as people can use encoded characters instead. – Voidpaw May 20 '15 at 15:13
  • possible duplicate of [How to prevent XSS from url](http://security.stackexchange.com/questions/54706/how-to-prevent-xss-from-url). See also this general question about [what is xss](https://security.stackexchange.com/questions/1368/can-anybody-explain-xss), and this [xss prevention](https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet) cheat sheet (to summarize: html encode user input, except for some locations where you shouldn't put it at all). – tim May 20 '15 at 17:43

1 Answers1

1

You probably need to google and read about XSS but here's a quick intro. Cross-site scripting is an attack where a hostile site, let's call it H, attacks your site S. H has on it a link to S that has malicious code in it that has been designed to provide the attacker with some benefit (eg: useful information or perform an action). This will likely only work if the user who visits H is currently logged into your site S, but that's OK. Attackers don't care if it doesn't work most of the time as long as it works enough of the time.

One might think that site S can assume that input is always coming from the currently logged in user so S doesn't need to protect the user from inputing dumb things like scripts. But XSS is a means of an attacker tricking a user to appear to input (they haven't actually input it into a text box but the forged request looks similar to that) scripts and other input that is dangerous to themselves. So S must not only protect itself from the user, S must also protect the user from the user because sometimes the user will be a forged link from another site.

Start by reading OWASP's XSS Cheat sheet and look elsewhere for defenses.

Neil Smithline
  • 14,621
  • 4
  • 38
  • 55
  • Thanks Neil, it is a good explanation - the challenge is how do I deal with it? If the user is not logged in then I can already deal with it as the login page will redirect based on what is in GET which would include the code in question and I already escape that so it would get nullified. The problem is if the user is already logged in hence they bypass the login redirect and go directly to the page and the script runs - how do I stop that script part from running? – bhttoan May 20 '15 at 18:54
  • You process the input and filter out or encode unapproved input. You need to do this anyplace that user input can be resent to the browser. [OWASP has a cheatsheet](https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet) on this but you can google `xss prevention` or `xss defense` and you'll get lots of information. – Neil Smithline May 20 '15 at 18:58
  • I think I am being stupid here - the input is in the URL. It is not used anywhere on the page or in the application in which it is loaded (it doesn't get echoed or inserted or processed or anything - my application does nothing with it but the browser executes it) so how do I filter/encode what is in the URL? The cheatsheet appears to be all about dealing with content prior to inserting it or displaying but I am not inserting anything, I don't touch anything in the URL / GET on that page. Sorry if I am being really dumb but I am not getting this :/ – bhttoan May 20 '15 at 19:09
  • If the script is being executed before the request is sent to your server then I don't think that you can do anything about it (and you have probably found a browser vulnerability). But I suspect that the request is being sent to your server and then the script is being executed when the response from the server is processed in your browser. So your server has to notice that, for example, there's extra text after the `index.php` and strip that text off or redirect to an error page or something. Can you post the HTTP response from your server? That should make it easier to understand. – Neil Smithline May 20 '15 at 19:14
  • Added to original question... – bhttoan May 20 '15 at 19:20