0

While testing a website that has a responsible disclosure policy I found out that I can insert code and close the attribute and insert some text of my own:

<input type="text"  value=""xsstext>

Now sure I can send them an email showing them I can insert <!-- and comment out the rest of the page, but I do not think they will take that too serious. From what I tested it will throw a 403 error when using:

"javascript:
"onload=     (and onmouseover, onfocus etc.)
"onload:
"<script >
"<svg >
"<iframe>
"expression(

It is possible to insert for example:

<b>batman</b>
<img>
<div>

I'm quite new to XSS. Is there any way I can actually run some script or do something more useful here?

Improve this question
4
  • 2
    Do you mean "attribute" instead of "tag"? I have trouble understanding your question. If you can introduce new tags, why can't you demonstrate the XSS flaw by popping alert? – Arminius Apr 10 '18 at 10:17
  • @Arminius I can close the attribute and start a new tag like <b></b> however it trows the 403 error when I use <script> or <svg > Hopefully its a bit more clear now? – toom Apr 10 '18 at 10:54
  • 1
    So certain tags are blacklisted? That's definitely important information that you may want to include in the question body. Can you find out which ones are? Can you do <iframe>, <img>, event handlers on, say, <div>? Try to find out under what rules the website refuses to reflect your payload. – Arminius Apr 10 '18 at 10:58
  • @Arminius I changed the question a bit, I saw that part of what I intended to write was not there. So for example <img> is possible. However javascript: any onload etc its all filtered – toom Apr 10 '18 at 11:17
2

The filter here seems to be some kind of blacklist. It does not outright filter out or encode dangerous characters like < and >, but instead it completely blocks requests containing certain strings or patterns. It would not surprise me if the application itself has no XSS protection at all, but there is a web application firewall (WAF) in front of it that throws a 403 when it sees anything that looks dangerous.

The good news about this kind of filter is that they are seldom air tight. The bad news is that it can be hard to find something that actually makes it through. Here are some suggestions that may or may not work:

  • Try case sensitivity: <sCRipT>, ONloAd
  • Every single event handler in the book: onerror, etc., etc.
  • Other dangerous URL schemes: <a href="vbscript:...">
  • URL encoding ordinary letters: %3c%73%63%72%69%70%74%3e

For more inspiration, see the OWASP XSS Filter Evasion Cheet Sheat. In general, try small things (e.g. just the string onerror, not " onerror="alert('XSS');") and see what passes, then work your way up to a full payload. And remember, this is a game where persistence is rewarded.

Improve this answer
4
  • Thanks for the help! It was pretty much what I was doing but It felt quite useless and not the proper way to do it. I will keep trying a bit more! – toom Apr 10 '18 at 13:10
  • @toom Best of luck! There are automated scanners, but doing it by hand has its advantages. Also, you could look for other injection points if you don't get anything out of this one. – Anders Apr 10 '18 at 13:13
  • 1
    @toom - If you find something that is not on the OWASP page, you can add it as that page is a wiki. Then it will be more helpful for the future readers! – Neil Smithline Apr 10 '18 at 14:23
  • 1
    @NeilSmithline you have to much faith in me brother, but ill keep it in mind in case I find something! – toom Apr 10 '18 at 15:33

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.