Is this XSS filter vulnerable

Question

So recently i was testing a web site .I searched bike in the search bar and got the following response.

So to escape all the TAGS i tried the following

</b></font></b>bike

i got following response

<b><font size="2" color="#df3d20" face="Arial">Your search: <b></b></font></b>bike&nbsp;&nbsp;&nbsp;&nbsp;Found 0 item(s)

next i tried the following attack vector

</b></font></b><img src=x onerror=prompt(1)>

and this was the response

I think this site is vulnerable.It looks like i have escaped all the tags.Can anyone suggest something

UPDATE

So i tried this and it worked

<img onmouseover="alert(1)" onmouseout="normalImg(this)" border="0" src="http://d2fbmjy3x0sdua.cloudfront.net/cdn/farfuture/hSDgO-dX1na9VZajH8LUXXZbZFW0DYjcPLDuabM2-1c/mtime:1486670171/sites/default/files/styles/nas_bird_teaser_illustration/public/4995_Sib

i get a popup .But i still dont get why pages crashes when i put onerror oralert(1)

UPDATE

I have one more question ........ when i use the following payload ,i get a pop up....

but if i close SRC attribute inside double quote(which is the correct way)the page crashes

screen shot(when not enclosing SRC inside double qoutes)

and where does all these closing </div> tags came from.They weren't here before when i searched simple terms like "bike"

Answer 1

It might be vulnerable, but we can't tell reliably without more information.

But first, you are not really escaping tags, you are closing tags.

In most situations, closing tags is not necessary, as the parser will happily ignore any possible errors. You can just inject your img payload at the beginning, and it will work (there are a few exceptions, such as textarea, title, script, etc; but b and font are fine).

Regarding the filter, we can see that everything after = is cut off. You should investigate further by supplying more input, such as a=b (to check if it is only cut off inside a tag). You could also try to encode = as %3D.

If bypassing the = problem doesn't work, you should try a payload that doesn't require it. A simple example would be <script>alert(1)</script>.

Answer 2

It's definitely vulnerable, because you were able to get a popup using onmouseover/onmouseout. That's easily enough to exploit almost any scenario, maybe not with 100% reliability but plausibly quite close (especially if you can use inline CSS to make the "image" cover the page, or similar). It certainly demonstrates that whatever filter you're seeing isn't good enough!

Now, to actually building a good PoC... there's a few things you should keep in mind. One is that it's almost always worth bookending your exploit payload with plain text strings that you can search for, like "bugbug" or "123456789". Make sure those strings are displayed in the output where you expect them( separated just by a space or something), then begin putting HTML in between them. This will make it really obvious if something weird (like cutting off all input after a certain point) happens.

Another thing is to look for weird ways to get XSS. It looks like the site is possibly using a blacklist of allowed strings, filtering out <script> and possibly stuff like onerror as well. That kind of filter is futile and - given that better options like output encoding exist - kind of stupid; even if you get it perfect today, tomorrow an update to the HTML spec (or just a browser that supports something nonstandard) will break it, and in practice you won't even get it right for the current standard (I once watched a major financial org try for about a month before giving up). Some payloads to try:

• <iframe src="javascript:... (yes, you can put a javascript: URI as the source of an iframe, and it will execute in the page's context)
• <iframe src="data:... (use a base64-encoded string of an HTML page with script that interacts with the parent page)
• <object data="javascript:... or data="data:... (object: the lesser-known cousin of iframe)
• <svg onload="..."> (one of the shortest payload templates I know)

You should also consider avoiding alert; you'd think nobody would be this foolish, but I've seen people filter that function name specifically to "block" XSS; consider less-used things like console.log or prompt.