[thelist] [tip] Macromedia even forgets (encoding user input)

[David Kaufman]

Sarah <poohbear at designshift.com> wrote:
>> Don't feel so bad... even the big boys forget.
>>
>> Open up macromedia.com and search on the following using the box in
>> the top-right corner:
>> <meta http-equiv="Refresh" content="0;url=http://www.intel.com">
>>
>> Ooops.
>
> ...I am having a hard time figuring out a really bad thing that
> could happen as a result of not encoding user input.

AxssDnied <axssdnied at borg.darktech.org> posted a good example of the
need for validating escaping user input, when that input is headed to a
SQL statement.  i did a similar trick on a friend who had a web
discussion board with a SQL back-end and wasn't escaping the input data
before passing it to the database.  all posts to the board were
*supposed* to be subject to moderator approval.  but i was able to
*guess* (after a bit of trial and error) that his messages table had a
column named "approved" that needed a 1 in it, before the post would
show up publicly.  so all i had to was put the string:

  MyUserName", approved="1

into the "username" text input of a message edit form.  the result was
that his SQL statement, something like:

  UPDATE Messages
  SET username="$username",
      message_text="$input_text"
  WHERE id="$hidden_id"

was magically transformed into something like:

  UPDATE Messages
  SET username="MyUserName", approved="1",
      message_text="$input_text"
  WHERE id="$hidden_id"

and my post was instantly approved!

there are similar, but much more serious (and malicious) exploits
announced and fixed every day to all sorts of software.  one very
serious mistake many novice programmers make security-wise is failing to
validate string that will be passed to the operating system as
*filenames*

if a site lets users upload images and lets them enter the filenames
that should used to save those files on the server, for instance, a
carelessly trusting programmer might simply append that user-input
filename string onto another string with the full path to to where she
wants the images to be saved, say (in perl):

  my $filespec = "/home/www/htdocs/upload/$user_input_filename";
  open (FILE, "> $filespec") # ... what file did we just clobber?

if $user_input_filename happened to contain a string beginning with
"../../../.." it can end with the full path to any file on the server
that the webserver has permission to write.  obviously, the webserver
shouldn't have permission to write *much*, but the script has allowed
the walls to be breached.  any data files your web scripts can write, at
the bare minimum are wide open.  all you have to do is validate that the
filename didn't have slashes in it to prevent that.

but wait! there's more: many scripts also take a user-supplied email
address, add it to a sendmail command line, and give it to the system
shell to execute.  if the email address has dollar signs in it, a
modestly clever hacker can can have your system email him the contents
all of it's shell environment variables!  or if he wants to play with
backtick characters he can execute literally any shell command he wants
to.

the thing to do is *not* to try "stripping out the bad characters" but
rather defining as small as possibly a set of allowed characters for
each bit of input, and rejecting anything that contains anything else.
ASCII has a lot of funny stuff in it, and unicode... oh my god.

> ...I know I used to do a lot of error checking on variables coming
> from the querystring until I decided that, if someone really wants
> to be a jerk and break my site by putting some garbage in the url,
> I just don't care what happens.

well forms that contain data for a database, or filenames are the most
common types of exploits and this data is most often POST'ed by a form
(though not necessarily!), rather that found a the query string, but
you're right, there are many cases where you just *don't* care.  you
tend to think (as macromedia does, in the example above), "Hey this
script doesn't *write* anything -- it's  search form.  if they search
for stupid stuff, they'll find stupid stuff -- or no stuff".  but they
forgot that that script could be exploited to write malicious javascript
code to the user's browser... how hard is it to HTML-escape any text
that should *always* be readable, and never *ever* executed?

> ...But if something bad really could happen as a result, I'd like
> to know and prepare.

preparing is not that difficult.  perl has taint mode, which will help
you identify unsafe data-handling practices in your code.  another thing
to do is lock down file permissions.  make sure that your webserver runs
as an unprivledged user and make *only* the files to which the webserver
*needs* write-access, writable by that user.  same with databases -- 
when you make database connections, use a username and password that
only has read only access, in the functions and scripts that *should*
never need write access, because you never know when someone will find a
way to exploit some script you have running.

that and don't run Windows webservers :-)  -- sorry, i just had to get
that in :-)

-dave