Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

My company recently had a security assessment done on our website and we had a XSS vulnerability reported. Below are the details of the reported vulnerability:

If a user hits a URL like the one below:


You can find the following when the page is rendered:

<script src="/Secure/Account/Addresses.aspx/25?_TSM_HiddenField_=ctl00_ContentPlaceHolder1_ScriptManager1_HiddenField&amp;_TSM_CombinedScripts_=%3b%3bAjaxControlTo.....{goes on for a while}" type = text/javascript"></script>
                                            ^ASCII characters here                                                                                                      ^truncating actual value for brevity's sake

As you can see the ASCII codes are converted to their character values (2 and 5 in this case) and rendered as part of a script tag. If I swap out the %32%35 for different values I get the results below:

  1. %32%35%3E which should render as 25< the page throws a 400 error
  2. %32%35%22 which should render as 25" it actually renders 25&quot;

My question is if this actually an XSS vulnerability? If so, what payload could be passed in to execute an attack?

share|improve this question

2 Answers 2

On it's face, because it takes encoded characters and is handled by the page code, it gets classified as an XSS vulnerability. This does not mean that it is a XSS vulnerability for your site, but it is suspicious.

As for the process to determine is there is a risk, you need to do a little fuzzing to see how your site responds. XSS fuzzing options abound with a search.

share|improve this answer
Interesting, thanks for the info. Just out of curiosity, can XSS attacks be performed without characters like <,> and "? –  Abe Miessler Jun 30 at 20:29
@AbeMiessler The data being modified is a script URL. In theory, it might be possible to make that URL point to a script controlled by the attacker without breaking out of the attribute. Whether that's actually possible might be hard to determine. –  Brilliand Jun 30 at 20:52
It's probably easier to just fix it, than to try and find an exploit that uses it. –  OrangeDog Jun 30 at 21:32
@AbeMiessler Yes, XSS attacks can be performed without those characters. –  schroeder Jun 30 at 22:52
@schroeder: There are some kinds of XSS attacks that don't need those, yes, but which of them would work in OP's markup? –  Bergi Jul 1 at 0:21

In itself, merely having %32%35 decoded to 25 in a URL is neither an error nor a sign of a vulnerability. In fact, it's what RFC 3986, section 2.3 says should happen (emphasis mine):

2.3. Unreserved Characters

Characters that are allowed in a URI but do not have a reserved purpose are called unreserved. These include uppercase and lowercase letters, decimal digits, hyphen, period, underscore, and tilde.

unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"

URIs that differ in the replacement of an unreserved character with its corresponding percent-encoded US-ASCII octet are equivalent: they identify the same resource. However, URI comparison implementations do not always perform normalization prior to comparison (see Section 6). For consistency, percent-encoded octets in the ranges of ALPHA (%41-%5A and %61-%7A), DIGIT (%30-%39), hyphen (%2D), period (%2E), underscore (%5F), or tilde (%7E) should not be created by URI producers and, when found in a URI, should be decoded to their corresponding unreserved characters by URI normalizers.

In fact, it's quite possible that it may not be your application that's decoding those characters at all, but your webserver, which tries to normalize the URLs it receives before passing them on to your application.

To tell whether or not your application (or webserver) is decoding too much, you should test it with characters that actually shouldn't be decoded according to the standard, and which could have an actual effect on the parsing of the URL or the HTML it's embedded in. Examples of such characters include:

  • The general URL delimiter characters (gen-delims in RFC 3986, section 2.2), especially the characters ? (%3F) and # (%23) — these should never appear un-escaped in the path portion of a URL.

  • Characters that are not permitted in URLs at all, such as newlines (%0A), spaces (%20), " (%22), < (%3C), > (%3E), \ (%5C), ^ (%5E), ` (%60), { (%7B), | (%7C) and } (%7D).

  • HTML metacharacters, such as & (%26), ' (%27), " (%22), < (%3C) and > (%3E) — having these inappropriately decoded (and not replaced by the corresponding HTML character entities) could corrupt the HTML markup and potentially create an HTML injection / XSS vulnerability.

    Note that several of these (", < and >) are in the list of forbidden URL characters above, and should thus always be percent-encoded; the others (& and ') may, and in some cases must, appear in URLs without percent-encoding, but in such cases they (especially &) must be encoded as the corresponding HTML character entity (e.g. &amp; for &).

  • A literal % sign, encoded as %25, should never be decoded to its literal form within a URL; if it is, it can invalidate the URL or, worse, form a valid but unexpected percent-escape sequence with the characters following it. While this is unlikely to allow a direct XSS attack, it is certainly a bug, and could open up other vulnerabilities by allowing malicious input to pass validation.

In particular, the test where you observed %22 being replaced by the HTML entity &quot; suggests that a) there is some inappropriate decoding (or insufficient re-encoding) going on, yet b) the URL, though strictly speaking invalid, is being properly HTML-escaped, which should prevent it from corrupting the HTML markup in a way that would allow an XSS attack.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.