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

enter image description here

So to escape all the TAGS i tried the following


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

enter image description here

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

UPDATE enter image description here

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)


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) enter image description here

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


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>.

  • ok so if is use <script>alert(1)</script> it shows the page isn't working.i tried <img src=x onerror=prompt(1)> and it shows page isn't working. However i used a image from google and put it into src and the image got loaded on the page . <img src=s7d2.scene7.com/is/image/PetSmart/…> (attached a screen shot in the original question) and now if i copy the created url and send it to someone ,they see a bird image on the website .Its still a vulnerability right? but i don't get why whenever i put onerror or alert the page crashes – shujaat Jun 12 '17 at 20:03

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.

  • Thanks for the explanation... do i have to make a POC ?I mean do i have to inform owner of the website...(don't know this is the right place to ask this question) – shujaat Jun 13 '17 at 3:15
  • @shujaat: This is kind of outside the scope of the question, but I'd check quickly if they have any kind of security contact info on their web page, and shoot off an email to security@ and/or webmaster@ for the domain if you don't find any more specific contact. Just be generic and casual about it - you were using the site, noticed that it echoed in-escaped HTML tags, poked it a little and was able to inject a script this way, see <proof-of-concept URL>, you should probably be HTML-encoding that user-supplied text for safety! - unless it's the sort of site where security super matters. – CBHacking Jun 13 '17 at 7:22
  • i have updated the question ...can u please explain – shujaat Jun 14 '17 at 16:00

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.