2

I found xss on a textarea field. When you enter a character to this field it output the character in real time so when I input the following code:

<input onclick=alert(document.cookie)>

there is no input validation or any filtering so I can click the input field and bam xss.

My question is if there is a real vulnerability in this flaw? I can't think of a real vulnerability because I can't send a victim this link with the injected code.

  • where does the original value from onclick come from, Can you provide some more context on the original state and what you modified, this will result in clearer answers. – Eric G May 15 '15 at 17:23
1

If u cant send the link, that would be a case of self-xss which involves the victim injecting malicious javascript snippets himself, which is a non-vulnerability in the bug bounties i have come across or even for professional assessments. However, social engineering attacks have been reported in the past wherein an attacker convinces someone to paste malicious javascript promising some result but in actual it ends up causing harm to the victim. Since, this involves a lot of user interaction, it is mostly a non-vulnerability. But, adequate protection should be put in place so the input isn't reflected anyways.

More about self-xss at : http://en.wikipedia.org/wiki/Self-XSS

0

Sometimes you get lucky and the app is built in a way that it will hold input state server side and reflect it back if it sees errors. This behavior may not be obvious by default because javascript validation may prevent you from ever seeing that postback (but it's added to make non-js browsers function).

Try seeing if the input has a name parameter and link to the page (GET request) with the inputs name as a query param (test=new name here). If it's all POST, just disable javascript in your browser and try to input your XSS, and in another field leave it blank or put in data that you know wont validate server side. The server may reflect with the forms already prepared with the previous input (allowing you to reflect your XSS with a CSRF post). If CSRF tokens are implemented, your only luck is that the token validation is after the input validation (likely not), or that tokens can be re-used. But if CSRF is allowed you can probably find a ton of other stuff.

0

cant send a victim this link with the injected code

This might be possible if you find that some input will populate the field.

Try POST and GET requests for the page, and attempt to populate the field using either its name (if it has one), but also try id and other variations. Have a look at the rest of the application and see if there are any commonly used parameters that could be tried here. Burp Suite Target tool is great for this because it allows you to see the site map at a glance, along with parameters sent to each page.

If you find you need to use the POST method to populate this field, then to make linking possible you would create a form on your own site to submit to the vulnerable site:

<form method="post" action="https://example.com/submit">

  <input type="hidden" name="textarea1" value="&lt;input onclick=alert(document.cookie)&gt;" />

</form>

You could submit this automatically

<script>
document.forms[0].submit();
</script>

and you simply send the link of your page to your victim for the reflected XSS to trigger.

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.