When Perl gurus are asked "how do I untaint stuff", they generally answer with "it depends". I understand that, but it seems like there ought to be some common ways of untainting input data in common situations -- e.g. "do this before sending something to a MySQL database" and "do this before using something as an email address".

Well, the answer is it depends. For inserting it in MySQL, it depends on two things. First, how are you inputting the data into the database? If you are using placeholders, you shouldn't have any problems with the insert itself. So, then you can allow anything. But what are you going to do with the data afterwards? If the data in the database is supposed to be trustworthy, you may, or may not, have to filter out characters, or substrings, depending on what you are going to do with it.

It's the same for email addresses. Email addresses themselves aren't dangerous, not even incorrect ones. But they may become dangerous depending on how you use them - even legal email addresses.

To decide how you properly untaint data, it's not relevant what the data is (or isn't), but what is important is how you are going to use the data.

Abigail

You can generally store any arbitrary binary data you want in a DB (but that of course depends ;-) Anyway to ensure the insert does not fail you need to quote some chars. With Perl and DBI all you actually need to do is is use placeholders ie:

my $data = "some 'arbitrary' data.....";
my $more_data = "\007\000\007";

$sth = $dbh->prepare( 'INSERT INTO table (col1, col2) VALUES (?,?)' );
$sth->execute( $data, $more_data);
[download]

The next it depends comes from what you plan on doing with the data when you RETRIEVE it from the DB..... If you are going to do open $data; eval $data; system $data; etc then you do need to untaint it. However whether you untaint it on DB insertion or not I would personally still redo the untaint prior to use, that way if someone corrupts your DB data it will not cause you undue grief.

An inbetween step would be to allow completely safe characters, disallow or escape completely unsafe characters, and for all others just delete them from the input. That's pretty close to the right thing to do for a lot of weird input characters.

You said in your post you don't understand what you're protecting against. Here's a little bit of the flavor of SQL injection attacks.

At the most fundamental level, you're trying to prevent a statement like this:

my $sql = "SELECT * FROM table WHERE NAME=$name"
[download]

So, you change that to:

my $sql = "SELECT * FROM table WHERE NAME='$name'";
[download]

SELECT * FROM table WHERE NAME='Tom';
DELETE FROM table;
SELECT * FROM table WHERE NAME='Bob'
[download]

So now you have to escape quotes, which you can do with the $dbh->quote function, or by using placeholders as others have described.

Other characters that are dangerous to your database will depend on the database, but unless your DBD driver is really crappy, $dbh->quote and placeholders should both be safe.

The remaining dangers, then, depend on what you do with the data. If you're displaying it on a Web page, you want to make sure it doesn't contain HTML tags, particular JavaScript code. If you're using it to send an email, you want to make sure it doesn't have any characters special to the mailing program (for example sending a ~ to /bin/mail, the source of the security bug in setuidperl IIRC).

One school of thought says all data in the DB should be trustworthy, so you should make sure it doesn't have anything dangerous for any application. Another school of thought says put whatever you want in the DB, and the application using it is responsible for making sure it untaints it on the way out. You need to make sure that you treat data from the DB as tainted in this case. The most paranoid school of thought says you should do both---stop characters that are likely to be dangerous from getting into the DB, and applications using the data check to make sure the data really is safe. That last one is what I usually try to do.

When Perl gurus are asked "how do I untaint stuff", they generally answer with "it depends".

my $tainted = $ENV{PATH};
my $untainted = $1 if $tainted =~ /^(.*)$/;
[download]

In your case, it doesn't look like you need to validate data at all (you may need to escape it if you're gonna display it via html, but you should allow the user to enter everything).

PS - on a sidenote, you can untain values like

my $tainted = $ENV{PATH};
my($untainted)= ( keys %{ { $ENV{PATH} => undef }} );
[download]

That's the correct mechanism for untainting data, but if you actually want to get any of the security benefits of taint checking, you'd need to do better than that.

Right, but in this case, he doesn't need to untaint data at all (escape ne untaint).