1

In one of the recent penetrationtests I encountered an XSS vulnerability within a cookie. The situation is as follows.

The webapplication uses the cookie to store the current URL. Once the user switches to another functionality within the application the cookies information is placed on the website as link. The created links are only valid for the current session.

So for example by manually setting the cookie to Cookie: key=fooXbar results in <a href="./foo">bar</a> where the foo part is not validated but the bar part is.

So when manually manipulating the cookie there is no validation on the foo part and any script is executed. However to make this a successful and valid attack the XSS needs to be served via the actual URL as described above. But the cookie is then set via javascript using escape(document.location.query). The escape() seems to eliminate the chance to make this successfully exploitable (e.g. ">< becomes %22%3e%3c).

So would there still be a possibility to inject XSS via the URL so that it gets properly included and executed? (Assuming there are no other vulnerabilities that could help exploiting this one.)

For now this would be rated as low finding due to the described circumstances. So any further comments or insight are much appreciated.

edited:

Thanks everybody for your feedback. According to the answers and the comments I currently believe that this xss vulnerability should not be exploitable by itself.

It is in fact the escape() function that is used. the a links is crafted via php-script portion and the "./" portion is hardcoded. If I remember correctly it is build doing something in the lines of $html .= '<li ...><a href="./' . $foo . ' " title="' . htmlspecialchars($bar) . '">';

  • Any chance you can also find a network fixation vulnerability? Combine the two and you have a winner – Conor Mancone Apr 23 '20 at 10:25
  • Does the site use HSTS? If not, then a local network attacker (e.g. public WiFi) can set the cookie on the http site, and that also sets it for the https site. But probably still low risk even with that. – paj28 Apr 23 '20 at 10:31
  • what you mean by network fixation? If you refer to session fixation then the answer is yes and no. There is session fixation issue, but the sessionid is stored in another cookie with httponly and secure flags. the site uses HSTS preload – Zapho Oxx Apr 23 '20 at 10:37
1

The escaped string, %22%3e%3c is URL encoded. The URL encoding makes it impossible to escape the quoted attribute value context, since all interesting characters will be converted to their URL encoded percent values.

So can this URL encoding be avoided? I don't know. If it is the escape() function doing it, you might be toast. However, depending how you perform the attack it might be some browser magic somewhere URL encoding things. Try execute the attack under as realistic cirsumstainces as possible - e.g. craft your malicious link and click it, instead of entering the URL in the adress bar.

Finally, it sounds like the a element in question might be generated client side with javascript? I imagine the code might look sort of like this:

theLinkElement.href = "./" + foo

If this is the case, it's game over since many classic XSS tricks don't work when you are explicitly manipulating the DOM via javascript.

But what about that leading ./? Is it hardcoded? Can you get around it? If so, a javascript: URL would do the trick.

  • That's a good point. I think IE (not Edge) is the only modern browser that does not auto encode URL params. – paj28 Apr 23 '20 at 10:39
  • thanks for your feedback. It is in fact the escape() function that is used. the a links is crafted via php-script portion and the "./" portion is hardcoded. If I remember correctly it is build doing something in the lines of $html .= '<li ...><a href="./' . $foo . ' " title="' . htmlspecialchars($bar) . '">'; – Zapho Oxx Apr 23 '20 at 10:49
  • @ZaphoOxx If $foo is URL-encoded, it's not an exploitable XSS vulnerability (unless there is something else going on, off course). – Anders Apr 23 '20 at 11:27

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.