Hi Win,

Many people think that, rather than checking for particular things that you don't want, it's better to check that the input is what you do want, and only accept it if it is.

For example, instead of saying 'don't accept input with dollar symbols in it', you could say 'only accept input consisting solely of alphanumeric characters and whitespace'.

The logic behind this is that, if you try to check for all the possible things that could cause trouble, you're bound to miss some out, perhaps because a particular security problem is only discovered after you write your code - in that situation, there's no way you could have known about it.

There are a couple of tools in Perl that can help with this:

• For data coming in from web forms, there is something called Taint mode. What this does, is it forces you to 'clean' data which could have potential security problems, before you can use it.

  You do this 'cleaning' by using a regular expression to say what characters you're willing to accept, like this:
  

  if ($data =~ /^([-\@\w.]+)$/) {
      $data = $1;             # $data now untainted
      } else {
      die "Bad data in '$data'";     # log this somewhere
      }
  [download]

  
  (This example is from the docs linked above)

• For sending statements out to databases, you can use something called Placeholders. What these do, is they let you separate out the data in a SQL statement, from the parts of the SQL statement that actually do things. So, if someone replaces your data with something unexpected, they can't send instructions to the database itself.

  Placeholders work like this:

  SELECT description FROM products WHERE product_code = ?

  (Example taken from the docs linked above)

Win, I hope that's some help to you. But could I ask you to do one thing though, please? I'm asking because I can see that you've asked a very similar question recently, at this node: Preventing malicious T-SQL injection attacks. So, my request is: please could you print out, and read a couple of times, the pages that I've linked to, before coming back to the monastery with questions on the same topics?

I can see you've just asked in the Chatterbox, "Why didn't people like my last post?", and the answer, as far as I can tell, is that some Monks are getting impatient with you because, when people answer your questions by telling you about online documentation, you're not going away and reading that documentation for yourself.

(Personally I'm a 'no such thing as a stupid question' person, but not everyone is).

You could also take a look at the tips in this article, The Help Vampire, a Spotter's Guide, and if you think that you might be doing some of the things they talk about (such as asking the same question multiple times, and not using your own initiative to understand the documentation), then there are some very useful tips for you to follow, on that page.

This is all meant in the very friendliest spirit, and I hope that it reads in that way. After all, Perlmonks is here to answer questions, so everyone is absolutely entitled to ask them! Which is lucky for me, otherwise I'd have been stuck many times. :)

Do get back to me with any queries about the 'taint mode' and 'placeholders' stuff above.

Hope that helps, and best wishes,
andye

(Other relevant nodes: Database access problem, Perl DBI issue)

The tips from the 'help vampire' page are:

If You're a Help Vampire...

Now you know. Stop. Of course, it's not just that easy, or nobody would ever be a Help Vampire at all.

Before you ask a question in a community, try to find the answer elsewhere. This way you help yourself by stretching your mind and research abilities, and you learn things more thoroughly too. Plus it's good karma.

Always try these avenues first:

1. Keep troubleshooting. Often we learn that it's easier to give up and ask for help rather than persisting—when we'd get our breakthrough if we'd only delay giving up for another 10 minutes. Respect yourself, go a little further before giving up.
2. Google, of course. Google partial error messages, add software names to your queries, and generally try at least 3 or 4 searches before you give it up as hopeless.
3. Mailing lists, forums, and newsgroups. Chances are, you're not the first person on the Earth to have this problem. Luckily we live in an age where we can search the past. Check out these resources next.
4. Docs. Sometimes they seem impenetrable, but give it a whack. The more you learn, the easier the documentation will be to understand and decipher.
5. Ask your question—but phrase it differently. Instead of asking your question directly, ask "Has anyone has seen this problem?" or "Can anyone point me in the right direction?" Likely as not, someone will have been there before, and they might know a blog posting or other resource which can help you out. This way, you show you are respectful of their time, and understand your problem is (probably) not unique.