Re: How to handle "special characters"

["T.J." <tjtoocool () phreaker net>]

When using perl I almost always use something like...

$data = <STDIN>; # Or rather, from the query string or post request, etc
$data =~ s/\W//g; # Strips any non alphanumeric character
# Optionally if the buffer length is a concern: $Ldata = length($data);
if($LData > 100) { die print "Whatever.\n"}

$dbh stuff for the SQL query here using $data as the input.

I'm not very fluent in php or asp but I'm sure they have something similar
to the s/// comand, right?

----- Original Message ----- 
From: "Tom Stowell" <jts () deforest k12 wi us>
To: <s.wizard () boundariez com>; <Trey.Keifer () fishnetsecurity com>;
<webappsec () securityfocus com>
Sent: Friday, December 12, 2003 9:55 AM
Subject: RE: How to handle "special characters"


This whole issue seems like history repeating itself.  I'm probably
completely off base (long-time lurker, first time poster), but here's my
thoughts:

Probably a lame example, but remember the Phone Phreakers?  They exploited
Ma Bell's in-band signalling circuitry to get free long distance calls by
generating tones and injecting them into the phone system.  AT&T moved to
out-of-band signaling, and phone phreaking went away (basically).

Some languages allow you to auto-quote variables in SQL statements, which
seems like a nice virtue, but what if their filters are slightly off?
Has there been any movement towards completely seperating commands and data
in this context?  It seems like the only thing that will ever "ensure"
(ha..) the security of a system.





Tom Stowell
Network Administrator
DeForest Area School District
520 E. Holum St.
DeForest, WI 53532
Fax: (608)-842-6545
Voice: (608)-842-6500
Email: <jts () deforest k12 wi us>

> > > "Keifer, Trey" <Trey.Keifer () fishnetsecurity com> 12/11/03 04:09PM >>>
If you *have* to deal with special characters you will want to encapsulate
everything at each level
depending on what you need to deal with and then peel off that encapsulation
at each sub-level within
your application while keeping the idea of least-acceptance in mind. This
has the added benefit of
ensuring input checking at every level in your application which, from my
experience, seems to be the
root of most problems. People implement one layer of protection and either
the malicious user finds a
way around it or they forget to do it *everywhere* so the one place they
missed puts them on CNN.

In a perfect world, every function would verify both the data its given and
the data it returns and
XSS would become a non-issue.

Trey Keifer
Security Engineer - Level II
Fishnet Security

Office: 816.421.6611
Cell: 816.710.6830
Toll Free: 888.732.9406
Fax: 816.421.3371

http://www.fishnetsecurity.com


-----Original Message-----
From: Sekurity Wizard [mailto:s.wizard () boundariez com]
Sent: Wednesday, December 10, 2003 7:34 AM
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

The information transmitted in this e-mail is intended only for the
addressee and may contain confidential and/or privileged material.
Any interception, review, retransmission, dissemination, or other use of, or
taking of any action upon this information by persons or entities
other than the intended recipient is prohibited by law and may subject them
to criminal or civil liability. If you received this communication
in error, please contact us immediately at 816.421.6611, and delete the
communication from any computer or network system.