2

I am learning about XSS vulnerability. I need to know what sort of XSS attack can be done on clean URLs. Clean URL example : //my url.net/project/public/#questions/question/edit/id/122/answer/1

3

I am a little unclear on what you mean by what sort of xss attack can be done on clean urls so I'm going to go over both types of XSS for your situation.

It really depends on how that URL is being used to render the page. First lets talk about two different types of XSS.

Reflected XSS: Part of your URL is rendered on the page and the attack payload is part of your URL. You need to trick users into clicking your link to execute the attack.

Stored XSS: The XSS is stored on the server itself due to insecure programming. Then when a user visits the page with the XSS payload, the attack is called up from the server. The user just needs to visit the page, no link clicking required.

So lest look at your example URL:

//my url.net/project/public/#questions/question/edit/id/122/answer/1

When I first look at this I don't see anything that jumps out as being rendered to the page, but for arguments sake lets say you are rendering the last parameter (1). If you change the URL to this:

//my url.net/project/public/#questions/question/edit/id/122/answer/1<script>alert('xss');</script>

and you tricked a user into clicking that link, it would display xss in an alert box on their page. This is a reflected XSS attack.

A more likely scenario is that the last parameter (1) is used to pull some info from the database and render that on the page. If you have not properly protected yourself against XSS it is possible that someone submitted an answer that contained javascript code. Example:

My answer to question 1<script>alert('xss');</script>

Now anyone who views that answer will see an alert box that says xss.

0

There's no reason why you can't just do something like:

//my url.net/project/public/#questions/question/edit/id/122/answer/1"><script>alert(document.domain);</script>

However, having said that, it totally depends on how the output is being rendered, whether the characters are being encoded using HTML Entities or HTML Special Characters, or if they are just being output as plain text.

The thing you need to do is called "Fuzzing", where by you add junk characters into an input (be it an inputbox or a URL or whatever) and see how they come back in the source.

For example:

":<>'\t{}banhammer/

I always use something to identify my string input, so in the above case it's banhammer so it is easy to search for through the source.

Also, note the \t in there? That is due to many applications on the web will use (strip|add)cslashes (at least in PHP) which if used incorrectly can cause XSS to be executed correctly.

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.