Waraxe IT Security Portal

LINUX · Moderator

The Technical Details

I. Brief Introduction
II. Common Techniques of Code Injection
III. Countermeasure
IV. Conclusion
V. Glossary
VI. References

I. Brief Introduction

This article attempts to explain the anatomy of Cross Site Scripting holes.
While XSS may show up in many places in a web application, I will only focus
on one subset of the XSS issue - malicious code injection, particularly,
Javascript injection. Generally, the same concepts are also applicable to other
scripting languages like VBScript, JScript and so on.

The readers are assumed to have some knowledge of Cross Site Scripting bugs.
A little knowledge of HTML, CSS and JavaScript is helpful in understanding
the issue.

I feel that XSS issue is often overlooked or not correctly taken care of.
This seemingly trivial hole is a far more complex problem to solve than what
I had imagined it to be. It is my intention to tell you how the typical
XSS holes manifest themselves. Hopefully, you will be able to defend yourself,
build better web application or at the very least, to evaluate your risk better.

II. Common Techniques of Code Injection

Many web applications today are rather interactive. Very often, many parts of
the web site are under our manipulation. For example, a forum, a web messaging
system and so on. In these applications, users can post messages and most of the
time, users are allowed to post message with HTML tags for formatting. Now, all
these nice 'features' opens up oppoturnities for the attackers to inject malicious
code into the web sites if the web applications were poorly written.

As far as I know, these are several categories of code injection techniques:
(if you know of any techniques not listed here, please tell me)

1) Script Tags
==============

<script>alert('XSS')</script>

Variations:

-> %3Cscript%3Ealert('XSS')%3C/script%3E
-> <script>alert('XSS')</script>
-> and so on...

2) Inline Code - Javascript pseudo-protocol
===========================================

<img src="javascript:alert('XSS')">

Variations:

-> <img src="javascript:alert('XSS')">
-> and so on...

3) Event Handler
================

<href src="xxx" onmouseover="javascript:alert('XSS')>

Variations:

-> <href src="xxx" onmouseover="javascript:alert('XSS')>
-> and so on...

4) The Cascading Style Sheet Way
================================

<br style="background-image:url(javascript:alert('XSS'));">

Variations:

-> <br style="background-image:url(javascript:alert('XSS'));">

5) Expression Evaluation in CSS
===============================

<br done="false" style="word-spacing:expression(!(eval(this.done))?alert('XSS'):0);
word-wrap:expression(this.done=true) Wink

">

Notes: 1) to 3) work on most browsers but 4) and 5) work on IE browsers only.

As you can see by now, it is not quite viable to list every possible variations of injection
techniques. Likewise, it is also not very viable to filter Javascript in HTML tags by hardcoded
rules.

III. Countermeasure

Looking at the 5 categories of techniques, let us go through them one at a time and see what
can be done to stop such attack. As I am not a professional programmer, countermeasure that
I put forward here are solely for reference only.

1) Script Tags
==============

This is the easiest to tackle. A simple translation rule that translates "<" to "<"
, ">" to ">" will do the job pretty well.

2) Inline Code - Javascript pseudo-protocol
===========================================

Again, this is also relatively easy to filter. A proposed countermeasure will be:

-> search for pattern 'javascript' and its variations like 'javascript'
-> replace the pattern found with other harmless string
-> or just simply delete it

3) Event Handler
================

Things are getting tougher for the programmers now. For every HTML tags that are allowed
in the message, we have to search for all possible event handlers and defang them.

For instance, search for string "onmouseover" and replace with "" or other harmless string.

4) The Cascading Style Sheet Way
================================

This one is really a pain in the ass. I would suggest you to look at the CSS specifications
for a complete picture of the problem. Anyway, a suggestion (not tested though) will be:

-> be really paranoid and disallow CSS in tags totally
-> this means that we have to search for 'style's and defang them
-> or we may also try search for pattern 'javascript' and its variations like 'javascript'
and replace them with harmless string

5) Expression Evaluation in CSS
===============================

Here comes, finally, an ultimate test for the programmers. Maybe, the safest way to deal with this
one is to disallow CSS completely by filtering 'style'.

By now, we should realise that our defense against XSS problem is a very clumsy one. As there are
just too many items to check for in our list, many programmers often overlook some of them, especially
XSS of type 4 and 5.

IV. Conclusion

At the time of writing, I am not aware of any one-size-fit-all solution that will painlessly eradicate
XSS problems. And I believe, such solution may not materialise at all in the near future. Thankfully,
we have yet to see mass exploitation of XSS holes in the wild that causes significant financial loss.
But, before it happens to us, we have to be extra cautious when building web applications.

V. Glossary

XSSCross Site Scripting
CSSCascading Style Sheet

VI. References

1) http://www.w3.org/TR/REC-CSS1
2) http://www.idefense.com/XSS.html
3) http://www.cgisecurity.com/articles/xss-faq.shtml

[/b]

LINUX · Moderator

other good page XSS

http://www.howdark.com/XSS/