in reply to Re: Security with a MEMO field
in thread Security with a MEMO field

Placeholders are a good idea, and if you're worried about gremlin characters, DBI placeholders will get you through a few hoops safely - like the INSERT into the database.

But there are many other kinds of hoops, and you will invent new ones.

other90percent will now expound at length on data paranoia...

rlucas hit on this glancingly:
However, the real question is: what will you do with the memo? If all you'll ever do is put it in the DB (I doubt that), placeholders are enough. Otherwise, think ahead.

Basically, you should validate - look for gremlins, metachacters that might be interpreted by something down the road - whenever you pass the data off between different pieces of the app. Different apps have different pieces, as well as differnet expectations as to the likelyhood of gremlins. You must validate when passing data between people outside your control - be it an RSS feed from an untrusted site, or a search string a webvisitor typed in while surfing your online widget store.

If you use your MEMO text as more than plain text - or it is exposed unquotedly to an interpreter of any kind - you should be working on a list of gremlins. Make up regexes to match them. Then, when you need to validate, it's a simple matter - you've got a regex palette handy.

Here are some interpreters, and the gremlins they don't like; fellow monks, please feel free to add to the list:

Anything
Always at least check the length of the chacater data.
Plain Text
ASCII control characters - hey what's this vertical tab doing here???
Browsers (HTML interpreters)
Check for sane HTML; you may end up parsing it though, and that's a very expensive check.
Databases (SQL interpreters)
Percent signs and semicolons are no-nos; but you shouldn't be exposing a SQL interpreter to an unquoted string anyway (see above, use placeholders)
Shells - (Including filenames)
Look out for dollars, percents, exclamations, semicolons; then talk to a sysadmin of the target system and ask for more. Use the list form of open.
Perl serializers (of many types)
If you froze the object, you can probably thaw it without validation (especially if you validated before freezing). However, if someone else handed it to you, you might want to do some sanity checking.
XML
Your parser will handle well-formedness for you, and there are many ways to syntactically validate an XML chunk (XSL, DTDs, Relax-NG...). But is the data semantically sane within your object model? And there's always the chance of malicious data...

Of course, you must decide where validation is worth the coding time, and the execution time. For example, reading catalog entries out of a trusted, read-only product database is fairly safe (especially if the entries were validated when the database was populated),

Other pitfalls: finding unescaped URLs, or escaped URLs where you expected unescaped. Avoid this by using CGI's auto-escaping mechanism.

Feel free to add more hoops and taint checks in reply....