Due to the presence of characters known to be used in Cross Site Scripting attacks, access is forbidden

Question

Can anyone tell me where does following HTTP error message come from:

Due to the presence of characters known to be used in Cross Site Scripting attacks, access is forbidden. This web site does not allow Urls which might include embedded HTML tags.

We're using dynamically generated URLs and in this specific case the URL contains the characters '<' or '>'. We do URL encode the generated URL (so '%3C' appeary instead of '<') but it doesn't help.

Our setup is ASP.NET MVC / IIS 7.5 / IE8.

It's strange but it looks like the error appears only on some machines. So it could be that the IE internet zone settings are playing a role.

Solution 1

You are probably using a third-party plugin, like SiteMinder, that is trying to "protect" your website from XSS attacks by rejecting URLs with HTML encoded in them.

If the error only appears on some machines and not on others, check what plugins are installed on those machines. Remove them until you find the culprit (then reinstall the others). Try configuring that plugin to allow the URLs.

Think about whether you really need the plugins or not. If some servers have them and others don't, maybe you are better off without them.

Solution 2

As Konerak says, if you're using SiteMinder then it will return 403 and give you that message to prevent cross-site scripting attacks.

This solution may not be appropriate if you're running an external-facing site, but the simplest way we've found to avoid the problem was to edit the LocalConfig.conf file to switch off the XSS checking.

This is the setting:

CSSChecking="NO"

And the file lives here:

Program Files\netegrity\webagent\bin\IIS\LocalConfig.conf

Comments

[llasarov]

Hi Konerak, indeed we're using SiteMinder for user Authentication. I'll try custom encoding (and server-site decoding) of the URL.

[asgs]

You are right. There was a text in the URL which had apostrophe unencoded.

[Ciaran Gallagher]

In my case, we could not reproduce locally as we did not use SiteMinder on local builds, it was only until we had published our website to our remote Development server which was using the SiteMinder plugin were we able to reproduce this issue (with HTTPS).

[fig]

Have also been caught out by this on a major communications company website. Again, it was apostrophes in the text that were rejected (and the text wiped every time!)