3

I am currently pentesting a site for a client of mine and I found a very strange 'bug'.

They have a search box on the home page which if I enter te\tst and hit search, it redirects to the search results page (not via ajax), and in the title it shows the keywords which I searched for, however, the control character actually gets executed.

So the title tag says this: "te st | site name" <-- Executed the \t and created 4 spaces.

So my questions really are:

  1. Could this be classed as a potential vulnerability?
  2. Is there anyway that this can be exploited?

Thanks!

[Edit]

Just FYI, it does also execute other control-characters not just the tab. I just tried \r\n and it new-lined it.

Also, it only executes the control characters if they are encapsulated within other characters, so:

\r\n doesn't work te\r\nst will return te[new line]st

Improve this question
7
  • 1
    Sounds like maybe they are doing search.matches("[\w]+") rather than search.matches("^[\w]+$"). As to whether this is exploitable, I'm unsure - it would depend on what other functions the search term is passed through.
    – lynks
    Aug 14 '13 at 9:41
  • So are you suggesting that this is done via javascript and not on the server side? The reason I ask this, is because it is redirected to a new page, and from experience, it would be much easier (and arguably faster/safer) for me to populate a title tag from the server side over the client side. I will test this though, I'll read through the (minified) js to see what I can find :)
    – DarkMantis
    Aug 14 '13 at 9:58
  • I'm not suggesting this is done clientside, it seems likely that the content is simply POSTed to the results page, where it is filtered and used (The definition of used will lead to whether or not this is exploitable). The regex I posted was to explain your very last point about needing 'normal' chars surrounding the control chars.
    – lynks
    Aug 14 '13 at 10:06
  • Yeah I tested out the regex and you're right, that's why it requires the chars around the control characters. Well I'll carry on poking around and let you know
    – DarkMantis
    Aug 14 '13 at 10:19
  • Can you make the application parse hex representation like "te\x41st" -> "teAst"? If yes then this can probably used to circumvent some XSS protections (if there is any). Can you display multi-byte characters this way?
    – buherator
    Aug 14 '13 at 15:43
1

Many vulnerabilities occur as a result of smaller non-exploitable bugs which cause different parts of the software make false assumptions about each other.

Returning user-input in a web applications response obviously suggests the possibility of cross-site scripting (XSS) attacks. These can be eliminated by proper input/output filtering/encoding.

Applying a transformation like parsing the control characters you mentioned can however make your payload slip through the applied protections, for example the following pseudocode:

transform(filter_xss($input))

can result in valid HTML/JS for the following input:

test\x3cscript\x3ealert(1)\x3c/script\x3etest

Multibyte characters can also be useful for exploitation.

Also it seems possible that the user input gets parsed by some kind of command shell that would make more dangerous attacks, namely command injection possible. Based on the operating system you can try different metacharacters to achieve remote code execution, these are some for *nix:

https://web.archive.org/web/20120810003039/https://www.cse.unsw.edu.au/help/doc/primer/node109.html

Improve this answer
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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