|
Re: Form Checking and Tainting
by Zaxo (Archbishop) on May 30, 2005 at 07:11 UTC
|
You don't get to choose just some to be tainted. If taint mode is on, all the data is tainted. The usual way to detaint is, for instance,
my $zip = $cgi->param('zipcode');
$zip = $1 if $zip =~ m/^(\d{5})$/;
Taint mode helps you guarantee that all the data you use is really checked.
The Regexp::Common module is uncommonly handy for these chores.
| [reply]
[d/l] |
Re: Form Checking and Tainting
by polettix (Vicar) on May 30, 2005 at 08:38 UTC
|
Using taint mode lets you to be future-proof. It's like using strict: you don't really need it (in the sense that you can perfectly do without it), but you understand that coding under strict mode lets you sleep quietly.
What if your program will evolve in time just to add some interactivity, or flexibility? You're already doing 99% of the work required to use taint mode: you're checking your input. Tainting it will help you not to forget anything, and will watch for dark corners you could overlook.
Flavio (perl -e 'print(scalar(reverse("\nti.xittelop\@oivalf")))')
Don't fool yourself.
| [reply] |
Re: Form Checking and Tainting
by gube (Parson) on May 30, 2005 at 08:08 UTC
|
Using the taint mode, switch 'on' the taint mode is not a problem. It will helpful to secure your code anyway.
| [reply] |
Re: Form Checking and Tainting
by TedPride (Priest) on May 30, 2005 at 08:39 UTC
|
I thought DBI / placeholders made data safe to insert? Aren't the bad characters escaped or removed? Or have I been leaving myself security holes... | [reply] |
|
|
Yes, placeholders make it safe to insert any sort of data, but they do not address issues like violating constraints on the table, inserting alphabetic data into columns that are supposed to have numerics, putting an unknown string into an "enum"-type field, etc.
The behavior may vary from one DBD to the next, but for some at least, I believe using placeholders will not cause any alteration of the field data being provided. It's simply a means of conveying values to the database engine without doing any SQL interpretation of the data. So "bad characters" are neither removed nor escaped -- they should be faithfully stored as-is in the database.
| [reply] |
|
|
Yes, DBI quoting or placeholders make insertions safe enough, but you then need to arrange for DBI select results to be tainted and checked. Better IMO to check once to start with, though data with unknown future uses might force reconsideration of that.
| [reply] |
Re: Form Checking and Tainting
by cbrandtbuffalo (Deacon) on May 30, 2005 at 15:55 UTC
|
If you are already checking things, you may be able to turn on Taint mode and not see a difference. Basically, to untaint something, you need to run it through a regex. If that is how you are data checking you're fine.
Do you need to turn it on? No, especially if you are never using the user input to do anything programatically. But it is a nice reminder.
If you're interested in making your form checking a little easier, check out Data::FormValidator. It helps with data checking and untaints your data as a side benefit. | [reply] |
Re: Form Checking and Tainting
by Nevtlathiel (Friar) on May 31, 2005 at 15:00 UTC
|
for example, a zip code field only contains digits and up to 5 digits
I hope that's not a compulsory field - don't forget about those of us outside the USA who have different systems for our zip codes, for example in the UK a valid post code is 1* or 2 letters, followed by 1 or two digits, a space, a digit and 2 more letters. If I were trying to register for your site and you made me enter a zip code your way, I'd just have to make something up ;)
* Normally 2 letters, but London just had to be different
----------
My cow-orkers were talking in punctuation the other day. What disturbed me most was that I understood it.
| [reply] |