Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
There is an input field which is not getting encoded at the server side. But if you give a whole script say <img src=a onerror=alert(1)>, it shows an error like: <img src=a....' is not a valid value.
I am not aware of any payload which is short enough to exploit this.
Is carrying out an XSS attack possible?
No, 10 characters is not enough to exploit this. If you want to enter a JavaScript context, at the very minimum, you would need:
That means even in an ideal situation, you only have 5 characters for your payload. Even if something like jQuery is already loaded, loading a remote script takes more characters than that.
In reality, you don't even have 5 characters. The shortest attribute is 6 characters, but onload doesn't work with img without a valid src, so onerror is shorter, giving you <img onerror=[] src=a> (20 characters). With a body tag, you could reduce this a bit: <body onload=[]> (14 characters), which is still too long. And you still need your payload, which will be a minimum of ~25 characters (eg $.getScript('http://x.c')).
This means that in your situation, script tags would actually be shortest. But you would only get to <script sr with 10 characters.
You can't even inject a link, which may possibly be used for phishing, as an a tag is cut of as well: <a href=ht
If not, how should I report this vulnerability to the application owner?
Is the length of the text configurable? In that case this would still be a valid vulnerability.
If it is not configurable, I wouldn't consider it an exploitable vulnerability, but I would still report it (at least if I am contacting them anyways because of further issues), as it may become an issue in the future in case the vendor decides to show more characters.
It will depend, but if there's another place where user input is inserted, these 10 characters would be enough to fool the browser into parsing it into another context.
Suppose that there is below an image (eg. an avatar) that can be controlled by an attacker, including the alt text. An attacker could set:
<img src="myimage.jpg" alt="--><script>alert(1);</script>" />
It would be safe not to encode this alt text, since it only appears into a parameter.
However, if the unencoded text in the error message was "<!--", then everything up to the --> in the parameter gets treated as a comment, and the alert() executes.
Another option would be an unfiltered text like «<b c="», although the rest of the payload would need to be much nearer.
The parameter might be anything (eg. the image url), as far as the "redundant" escaping wasn't performed on it, and it appears after the unfiltered text (actual exploitability will depend on the tags inbetween).
<script>/**/alert(1) is another useful option.
Sep 19, 2016 at 19:08