There are two sides to security from a Web developers viewpoint, the client and the server.

The client side issues fall into the following categories:

• Safe access of Web resources - well-behaved browsers, plug-ins, applets, ActiveX controls, etc. that do not corrupt the client system. Includes deliberate and unintentional corruption. Addressed by language design (Java applets), trusted sources (intranet, certified software developer, trusted name), proxy servers that limit or filter access to Web, virus detection software, refusal to open active documents such as OutLook, Word, etc.
• Secure communications - sensitive data that can be transmitted between client and server securely. Addressed by secure protocols such as SSL.

The server issues are generally:

• Secure data - access to sensitive data stored on the server is restricted and the data is encrypted. Addressed by administrative procedures and encryption software.
• Secure communications - sensitive data can be transmitted between client and server. Addressed by secure protocols such as SSL.
• Safe operation of server - the server and system are secured against unintended use. Includes deliberate and unintentional corruption. Addressed by administration of server to restrict client access, careful implementation of server side programs, restriction of execution privileges to trusted developers, firewalls to limit Web access to server, monitoring access log, data encryption etc.

Security Resources:

• http://www.w3.org/Security/Faq/www-security-faq.html
• Web Security by Lincoln Stein, Addison Wesley, ISBN 0-201-63489-9
• VeriSign - http://www.verisign.com/ssl/index.html

Security

·    Authentication as proof of identity. We need to know that a site claiming to be www.money.com actually is www.money.com. Generally, we require some trusted third-party authority that can not only verify an identity but also ensure that the verification is trustworthy; a Certification Authority such as VeriSign provides secure digital certificates to sites for authentication.

·    Encryption transforms an easily read message into a form that, without knowledge of the transformation, is more difficult to read. Decryption transforms the encrypted message back to a readable form. Ideally, only the authenticated sender can encrypt the message and only the intended receiver can decrypt and read the message, keeping the message contents secret and private from all others.

·   Verification determines whether the message has been received as it was sent; no tampering has occurred.

Hashing - Used to verify that the message sent is the message received.

A hash maps input (such as a message text) to some number.

For example, a modulus 256 hash could operate by:

Sum the byte values of the message, the sum will be a value between 0-255.

SHA-1 (Secure Hash Algorithm 1) developed by NSA processes 512-bit blocks to produce a 160-bit hash. Very difficult to change the message and produce the same hash.

Verification process:

Sender computes hash of message and sends along with message.

Receiver recomputes hash, if agree with sent hash assumed message verified.

Secret-key Cryptography - Used for secure data communications.

The same symmetric key encrypts and decrypts plain text message.

Problem is that both sender and receiver must possess key, one sharing solution is plain old mail, another is a key distribution center (KDC) which shares a different secret key with every user on the network.

Both sender and receiver would have an independent key shared with the KDC, the KDC generates a session key and encrypts using the sender and receiver keys, then forwards to each respectively. The send and receiver the decrypt the session key and use for encrypted communication.

A secret-key example is Data Encryption Standard (DES) with a key length of 56 bits, considered too short for modern code breaking methods. Work is under way to improve its security.

Public-key Cryptography - Avoids the secret-key problem of exchanging a common key.

Based on an private key and an inverse public key, the public key is used by the sender to encrypt a message to the receiver, the receiver applies their private key to decrypt the message.

An example public key might be to square each piece of a message, the private key would be the inverse, to take the square root of each piece. For example, square to encrypt the message 2 3 4 as 4 9 16 and send, decrypt 4 9 16 using the square root as 2 3 4.

Generally a key is generated as the composition of two large prime numbers which are needed for encryption and are difficult to determine given the key itself.

When both sender and receiver have public keys, the sender can sign a message using their private key and the receiver decrypt the signature using the sender's public key to verify the origin.

Problem:

Third party could intercept messages, replace with own. Receiver needs to verify message was not tampered.

Solution:

Sender computes message hash, signs hash with private key. Sends message and hash.

Receiver applies sender's public key to hash, recomputes hash of message, if agree message verified.

Certification Authorities (CA) - Certify that one is who they claim, that a public key is associated with a given site. 

Problem of most key systems is that a customer visiting a commercial site needs the site's public key.

Possible for a third party to replace the site's public key in message with their own and receive the customer's information.

For the site to trust the user identity, each user would need their own public/private key and certificate.

Not normally required since they're already getting your money.

When necessary (e.g. banks) use a login/password, presumably encrypted using the now certified site's public key.

A solution is for a trusted CA to authenticate the site to be who they claim by:

Providing the site with a certificate containing:

site's public key

a hash of the certificate

CA's own signature generated using the CA's private key

Site publicly posts certificate.

The customer decrypts the CA signature using the CA public key to verify authenticity but a third party could replace the site's public key.

Customer hashes certificate, if agrees with CA provided hash accept public key as authentic.

Customer software would necessarily have the CA key necessary to read and verify the certification authority's signature.

Data Security

Protection of personal or sensitive data is commonly required by law. There are several basic approaches to protecting data on the server or personal machine:

1. Restrict access of directories containing sensitive files to only those users or applications requiring access.
2. Encrypt data. Most operating systems (including Microsoft) support data encryption.

Microsoft

Files or folders can be encrypted and automatically decrypted by the owner, non-owners must supply the encryption key. Details are at: http://www.microsoft.com/windowsxp/using/security/learnmore/encryptdata.mspx

PGP

PGP (Pretty Good Privacy) originated as public-domain software to encrypt/decrypt communications and file encryption using public/private and symmetric and asymmetric keys. A freeware version is available at: http://www.pgp.com/downloads/index.html 

Network Security

Security Protocols - Secure Socket Layer (SSL) is a standard protocol based on public key technology, certificates and secret-keys.

Public key cryptography keys must be long for security, since attackers have lots of time.

Encryption/decryption is slow.

Using a one-time, smaller shared secret key allows for a faster conversion but computationally difficult for attackers to determine key.

To conduct a secure transaction:

1. a customer contacts a commercial site server and sends a random number
2. site sends own random number and its certificate containing public key
3. the customer verifies the certificate authenticity through a CA
4. negotiates a new secret key with the server using the public key
   • the customer sends a 384-bit premaster key encrypted by site's public key. The random numbers and premaster key are thus shared.
   • each derives secret-key using the two random numbers and premaster key.
5. Secure communication is then conducted using the shared secret key for encryption/decryption and a hash for verifying message integrity.

Security Holes

• Certificates can be self-certified, security fails if software and/or user does not verify certificate from a trusted CA.
• CA verification of clients.
• Once encrypted data is received by the server, it is generally decrypted and often stored, making it accessible as plain text.

How to use makecert.exe to create a self-signed test certificate that can be used with IIS for SSL

Problem: Special options must be specified with makecert.exe, to create a self-signed certificate that can be used with IIS (Microsoft Internet Information Server).

Note: Microsoft recommends to install and use the "Certificate Server" to generate an SSL test certificate (Q216907), instead of using makecert.exe. But using makecert is simpler.

Solution:

The following command can be used to create and import a self-signed SSL test certificate:

makecert -r -pe -n "CN=www.yourserver.com" -b 01/01/2000 -e 01/01/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

To install this certificate in IIS 5.0, open the IIS "Web Site Properties", "Directory Security", "Server Certificate...", "Assign an existing certificate" and select the new certificate from the list.

Note: Older versions of makecert.exe do not support the "-pe" option, which makes the private key exportable. If you have an old version of makecert.exe, you can omit the "-pe" option, but then the certificate cannot be exported including the private key.

(Visual Studio contains makecert.exe (5.131) that supports the "-pe" option. The .NET Framework SDK 1.0 of 2002-03-19 contains an old version of makecert.exe that does not support the "-pe" option).

If the private key is exportable, you can export the certificate together with the private key into a PFX (PKCS #12) file as described in Q232136.

Note: SSL server certificates for IIS are stored in the "Personal" ("My") certificate store of the "computer account" ("localMachine"). The "Certificates" snap-in of the Microsoft Management Console (mmc.exe) must be used to manage these certificates. The normal certificate management window (accessible via "Internet Properties" / "Content" / "Certificates" or via "Control Panel" / "Users and Passwords" / "Advanced" / "Certificates") cannot be used.

Note: To create a key with more than 512 bits, use the "-len" parameter of makecert.exe.

Author: Christian d'Heureuse (chdh@inventec.ch)

Server Security

CGI - There are a number of common programming holes that can be exploited to gain access or control over a server. Below are examples of the most common programmer mistakes.

• C - Input buffer over-run occurs when the length of data Posted from a form exceeds the storage allocated. The following does not restrict the number of characters input to 2 or less, input of more than 2 characters would over run the array input, either causing the program to fail or, given a clever hacker, over writing the original program with the hacker's program and executing it. The obvious solution is to never input more characters than allocated.
  

Hole.htm <FORM Method='POST'   Action='Hole.exe'>  Enter a string: <Input Type='Text' name="string"><br>  </FORM>

// Hole.cpp #include <iostream.h>  #include <stdlib.h>  #include <stdio.h>  void main( ) {  char input[2];  int length;  cout << "Content-type: text/html\n\n";  sscanf( getenv("CONTENT_LENGTH"), "%d", &length);  for (int i=0; i<length; i++) cin >> input[i];  input[length]='\0';  cout << input; }

• Perl - Actually many scripting languages have similar problems, many related to allowing Web users to execute arbitrary commands on the server.


Consider the dir.pl Perl script that executes the dir command on the current server directory and pipes the output back to the browser. Since there is no browser input from a Post or Get the script is safe.

# dir.pl print "Content-type: text/html\n\n"; # create the HTTP header open(DIR, "dir |"); # Execute dir and pipe output print <DIR>; close DIR;

A more useful script would allow the user to provide inputs to the dir command such as listing only Perl files by dir *.pl which seems reasonable and safe enough. Here is the BADdir.pl Perl to allow a Web user to enter on the URL or by Get the dir command parameters. The URL to list all exe files would be:

http://localhost/N342/BADdir.pl?dir=*.exe

The problem is that Windows 2000 allows multiple commands to be entered on one line separated by an &, a moderately clever user might create a little havoc by entering the URL:

http://localhost/N342/perl/BADdir.pl?dir=*.exe%26del+*.pl

The %26 is dutifully converted from the hexadecimal code to the & by Perl. The two commands executed by the server is then:

dir *.exe
del *.pl

The obvious solution is to disallow the & from command parameters when executing a command in Perl. The second OKdir.pl program more safely runs the dir command. Since each command/program executed may interpret characters differently, a better solution is to determine what are acceptable characters and only accept those from user input.

# BADdir.pl # To use piping to get Perl to execute any command such as delete all *.pl the files: # http://localhost/N342/perl/dir.pl?dir=*.exe%26del+*.pl # Works on Windows 2000 IIS server because &=%26 allows multiple commands to be entered on a line. use CGI qw/:standard/; # load standard CGI routines  $query = new CGI; # GET data $dir = $query->param('dir'); # Parse dir variable print header; # create the HTTP header open(DIR, "dir $dir |"); # Execute dir and parameters print <DIR>; close DIR;

# OKdir.pl use CGI qw/:standard/; # load standard CGI routines  $query = new CGI; # GET data $dir = $query->param('dir'); # Parse dir print header; # create the HTTP header $dir =~ s/&/\//g; # Mangle the & open(DIR, "dir $dir |"); # Execute dir and parameters print <DIR>; close DIR;

Servers

• Server security holes are more attractive to hackers than CGIs since all servers of the same flavor may have the same weakness while each CGI presents a new hacking challenge. Server holes are usually patched by the vendor but require the updates to be applied. Microsoft's own servers were hacked because they had failed to install the most recent updates/patches.

Server configuration is an administration problem that varies from one server to another, setting promiscuous access rights to files or directories can compromise the system. There are security scanners available that probe for known holes in server software, since intruders also probe potential victims with the same scanners, its advisable to check it yourself before someone else does. Popular scanners are: COPS, TAMU, SATAN (from an IU CSCI dropout), and ISS.

• After careful configuration and security testing, the server may still be vulnerable to the floppy disk attack. Simply booting up the server on a floppy disk gives complete access to the machine hardware. Linux can be installed on a single floppy along with NTFS drivers, booting a Windows machine on Linux circumvents any of the careful file and directory configuration restrictions. Lock the server away, unplug the floppy, CD-ROM and any other bootable device.

Hosts

• Securing a host begins with two tasks:
  1. Configure a firewall
     • Download and install ZoneAlarm, a free fire wall for personal use on Windows machines.
  2. Test firewall
     • To probe for potential security problems of  a host go to grc.com for Shields UP! Run Test My Shields.
  • The official Windows security test is at Microsoft.