Characters aren't dangerous to your Perl program in itself. Passing them along to something else that may interpret them specially is what's dangerous. And knowing how the components you interact with will interpret the characters is the key to security (at least from this class of problems).

For example:

• If you're taking user input and using it in eval, well, you should probably find another way of doing what you're doing. But let's pretend there's some reason you have to, as an illustration. You could write something like this:

  eval "print OUT '$unsafe_input' or die";
  [download]

  . This isn't safe; we can see this by thinking about how Perl will interpret their input. Well, inside a string, a variable identifier will be interpreted, which might give away secret information (think $unsafe_input="',\$DATABASE_PASSWORD,'"), so the this-is-a-variable characters are unsafe---$@%. Also, escaping from that quoted string would be a real problem (think $unsafe_input="'; system('cat /etc/passwd'); print '"), so single-quotes are dangerous.
• As you mentioned, if you're using mySQL, single-quotes are dangerous.
• To the shell, shell metacharacters are dangerous, so you have to be particularly careful of $;*&|?.
• If you're printing the user's input to a Web page, you better make sure it doesn't have HTML tags in it, or else your Web site will be vulnerable to a Cross-Site Scripting attack. So, you'd better prevent code to create HTML tags, such as <>. Taint mode doesn't catch this one.
• If you're using a user's input to execute a network protocol, say SMTP protocol, you have to be careful of single dots on a line by themselves, since they introduce a command. If you're taking the body of a message, for example, and sending it over SMTP, they could enter into their body ".\r\nMAIL FROM:<somebody_else>\r\nRCPT TO:<victim>\r\nBODY\r\n..." to leave the message they were sending, and create their own, perhaps to spam.

Once you know what sorts of characters are unsafe, you need to stop them from being interpreted by the program you're interacting with. The two ways to do that are to disallow them, or escape them. Escaping is usually riskier because it's easier to make a mistake. For example, let's say you're trying to fix that eval with $user_input =~ s/(\"\@\$\%)/\\$1/g;. Well, what if $user_input='\"; cat /etc/passwd; print \"rest'? Your RE replaces the " characters with \, so the \" becomes \\"---an escaped backslash, and an unescaped quote. Yikes! The solution is to also escape the backslash. Now \" turns into \\\", which is an escaped backslash followed by an escaped quote.

The other option is to disallow them altogether. This is safer, since it's easier to do this correctly, but it can be restrictive. If you're asking a user to enter a passage from a book, it may not be acceptable to disallow quotation marks. If you're asking a user for a password, you shouldn't reject any characters.

The final thing to keep in mind is when you're restricting characters, it's safer to think of all of the characters you know are safe than aren't. That way if you make a mistake, you've erred on the side of caution.

Taint mode is designed to help you do this, but it only works when it knows which input sources are unsafe, which interactions are unsafe, and when you tell it how to make user input safe for use. You should be using taint mode, but only as a tool for catching you when you make a mistake, not as a primary line of defense.

Whenever you're interacting with some system that a user can't normally interact with (a database you're authenticated to, a shell on a public Web server), think hard about what an attacker could to to make a mess of things, and then prevent it. Try a few things, and see how they're handled. Getting a particularly devious friend or co-worker to think of ways to subvert your system can be effective.

A final note is that some modules can provide extra information to taint, such as telling DBI to treat all queries as an interaction that requires taint checking, or telling CGI that its output should be taint checked. I don't recall the names of these modules, but CPAN should be able to find them.

Update: Fixed eval example near top so it's actually insecure.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.