How could an attacker exploit XSS in a cookie reflecting the URL?

Question

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) . '">';

Answer 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.