Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to find out whether this is vulnerable against XSS: I can control the content of the title tag through the URL. This would make the site vulnerable if it wasn't for the fact that the site only takes the text until the first forward slash appears, making it seemingly impossible to close the title tag. I already tried %2F, but the server appears to convert that to a forward slash and therefore cut the input there. This is possibly mod_rewrite, but without AllowEncodedSlashes.

Example: domain.com/subfolder/myXss</title>bla will lead to ...<title>myXss<</title>

So my question is whether one of these two is possible:

  • Can i encode a forward slash in some other way?
  • Can I somehow close the title tag or insert malicious code into the title tag? I can't simply insert script, as nothing else is allowed within the title tag.
share|improve this question
1  
It's a long shot, but have you tried double-escaping %252F? (Or possibly even triple-escaping maybe?) – LB2 May 30 '14 at 13:46
1  
We would need to see the backend code to see what filters are in place, if you are just checking for the slash, then is possible some special or escape characters would lead to XSS. – Eric G May 30 '14 at 14:09

You can try a lot of things it depends what the server is doing. Double encoding, Hex encoding. If I was looking at this my first though would be how can I do it without a backslash.

The title tag doesn't need to be closed, you just need to be able to get in to javascript context.

In other words you would be abled to insert script alert(xss) /script (won't let me add the opening and closing script tags) and it would execute if the slash was allowed, you wouldn't need to close the html tag.

How about something like %3Csvg%20onload%3D%22alert(%27xss%27)%22%3E

share|improve this answer

Within a HTML5 <title> tag, it is not possible to inject new elements without allowing slashes.

Since your browser's HTML parser is a state machine, you can simply follow the state transitions of the tokenizer (per the HTML syntax specification) and see how far you get.

In your case, a <title> tag in the head section evokes the "generic RCDATA element parsing algorithm". From the RCDATA state, every opening bracket is ignored unless you're closing the most recently opened tag. So the only continuation that will not be treated as raw text is the literal sequence </title>. And since that string contains a slash, no XSS will be possible. (This behavior is similar to other elements such as <textarea>).

My answer here has a slightly more verbose description of how the tokenizer can help you reason about possible XSS.

Can i encode a forward slash in some other way?

The HTML parser only accepts a literal / (0x2f). If you're asking how the web application could be tricked into printing a slash, this would be pure speculation as it depends on the web app's implementation.

share|improve this answer

Your Answer

 
discard

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.