RE: How to handle "special characters"

["Sachin Hamirwasia" <sachinh () singnet com sg>]

Hi Gunter, 

Your articles on CSS are very impressive indeed. Quite an in-depth work I
must say. 

Am wondering, in case you haven't already written one - a good related topic
to write a paper would be on the possible ways of inserting code into HTML
tags. Many sites don't (or cannot) simply filter characters like < or >. eg.
Web-based email services which must allow some HTML formatting tags. Such
sites need to be extra careful in filtering input data, because of the great
variety of ways in which an attacker could send a malicious script - like
the one recently observed in Yahoo! Mail - using Cascading Style Sheet. 

And like you've mentioned, it is just too difficult to fully secure your
sites against CSS attacks without loosing almost all flexibility. Perhaps
the best option in many cases is to allow characters from a select set ONLY,
eg. [a-zA-Z0-9\.,-]. But of course, doing this becomes increasingly
difficult when you must support international characters as well. 

Cheers,
Sachin

-----Original Message-----
From: appsec () technicalinfo net [mailto:appsec () technicalinfo net] 
Sent: Friday, December 12, 2003 6:59 AM
To: tonyl () s2s ltd uk; s.wizard () boundariez com
Cc: webappsec () securityfocus com
Subject: RE: How to handle "special characters"

One of the many problems in dealing with "special characters" within web
applications is not so much the individual character, but at what stage (or
host-service) within the application is the character interpreted into
something meaningful.

The type, and level, of character filtering required by an application is
totally dependant upon the layers and sub-services within the application.
Thus, characters are often dangerous at only 'one' layer, while being
'required' or irrelevant for other layers.

It is not possible to provide answers in the form of a list.  Unfortunately,
to deal with the problem sufficiently, a fair understanding of the types of
threats and how different characters effect different application layers is
required.  And from there, relating these threats to your own layered
application configuration.

Even then you may get caught out - especially when application layers repeat
data processing code.  The classic example is double-decode (or even
triple-decode) of unicode characters such as % -- for example the character
sequence %%25

I would recommend that anyone interested in understanding the impact of
different characters review the following three papers - especially the
multiple examples - to have a clearer idea:

http://www.technicalinfo.net/papers/URLEmbeddedAttacks.html
http://www.technicalinfo.net/papers/CSS.html
http://www.nextgenss.com/papers/advanced_sql_injection.pdf 

Cheers,

Gunter

-----Original Message-----
From: Tony Langley [mailto:tonyl () s2s ltd uk]
Sent: Wednesday, December 10, 2003 11:56 AM
To: 'Sekurity Wizard'
Cc: webappsec () securityfocus com
Subject: RE: How to handle "special characters"


I hope you get a good clear set of answers, or at least some links for
further reference. It would be extremely useful to have a definitive
single point of reference for this.

Please let us know of anything useful which isn't copied to the mailing
list?

It would certainly be useful to know:

1) Which chars are always safe (if there are any).
2) Which chars are always dangerous.
3) Those which are sometimes one or the other.

Thanks...

Tony Langley.

Systems Architect
S2S Limited
-----------------------
 Tel: +44 8703 504 525
 Fax: +44 8703 504 526
-----------------------
http://www.s2s.ltd.uk

-----Original Message-----
From: Sekurity Wizard [mailto:s.wizard () boundariez com] 
Sent: 10 December 2003 13:34
To: webappsec () securityfocus com
Subject: How to handle "special characters"


Greetings,
  I had a developer pose an interesting question today, and I wasn't
100% sure what the answer was - so I figured I'd turn to the community
for advice.

  There are certain characters which pose threats at different levels of
the application tier model.  Some at the client, some at the web server,
and others in the database.  Characters such as the &, |, ', ", and -
can be associated with database hacks, for the most part.  If a
requirement is there to absolutely keep these characters in, for
example, interface with a back-end legacy database, whats the best way
to handle their existance?  As a developer, what are the necessary and
proper steps to take to avoid SQL Injection, command execution or other
attacks?

Just looking for some good best-practices..
  s.Wizard