3

A colleague suggested to me just to prevent letter characters from occurring immediately after an opening angle bracket as a way to protect against XSS and HTML injection.

Obviously, this doesn't prevent issues such as:

<img src="%injectable%" />

But I can't think of a way around his suggestion.

Is it really that simple?

3
  • Could you be more specific about either the context & the type of XSS you're thinking of? Otherwise I'd say it's a pretty moot protection overall.
    – Dillinur
    Commented Nov 7, 2014 at 10:37
  • 4
    What language or platform are you using? Usually the templating system you are using has an XSS filter.
    – rook
    Commented Nov 7, 2014 at 15:01
  • What is the exact suggestion? Just ban /<[a-z]/i ? In which context would it be run? As you show, if the attacker is able to inject content inside a tag (or a <script>, <style>… ) you are still vulnerable, so I don't understand you statement that you "can't think of a way around his suggestion" while showing a counter-example at the same time.
    – Ángel
    Commented Nov 8, 2014 at 1:21

2 Answers 2

3

I think your example describes exactly why it isn't that simple. There are many forms of XSS, and quite a few of them don't rely on attackers injecting entire tags at all.

What Rook was getting at in his comment is that you should generally rely on a good existing XSS filter to deal with the threat rather than trying to piece one together your own, as your colleague seems to suggest.

0

White-listing the characters is always the best practice instead of black-listing special characters. I had seen the same thing with one of the apps I was assessing. So, I found an input parameter which showed in response at three different places. One of which was inside " " in a-tags. No wonder, XSS was easy there. And yes, already mentioned, many of the payloads don't have to use tags at all.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .