Lecture 13. WWW Security

13.1 Protecting confidential documents at servers (access restriction)

Materials at a WWW server

Web Materials open to the general public
Web Materials open only to authorized users
Non-Web Materials

Access restriction on Web Materials open only to authorized users

Built-in server access control (we use NCSA servers for example)

Restriction by IP address, subnet, or domain

Individual documents or whole directories are protected in such a way that only browsers connecting from certain IP (Internet) addresses, IP subnets, or domains can access them. (limitations: IP spoofing, DNS spoofing, proxy server, no user authentication)

/usr/local/etc/httpd/conf/access.conf

<Directory /path-to-document's-directory> 
<Limit GET> // <Limit POST> // <Limit GET POST>
order deny, allow 
deny from all 
allow from freerange.com 
</Limit>
</Directory>

path-to-document's-directory/.htaccess

<Limit GET>
order allow, deny 
allow from all 
deny from freerange.com 18.157.0.5 .zoo.org
</Limit>

Restriction by user name and password

Documents or directories are protected so that the remote user has to provide a name and password in order to get access. (limitations: badly chosen passwords, passwords and documents transmitted in clear form)

/usr/local/etc/httpd/conf/access.conf

<Directory /path-to-document's-directory> 
AuthUserFile /usr/local/etc/httpd/conf/.htpasswd 
AuthGroupFile /dev/null 
AuthName By Secret Password Only! 
AuthType Basic 
  <Limit GET> 
    require user jean 
    require user chris
    require user mike
  </Limit> 
</Directory>

path-to-document's-directory/.htaccess

better-be-ouside-document-tree/.htpasswd

/usr/.../httpd/support/htpasswd -c be.../.htpasswd jean
.../htpasswd better.../.passwd chris
.../htpasswd better.../.passwd mike

kill -HUP process-id-of-root-httpd

Combination of the above two

<Directory /path-to-document's-directory> 
AuthUserFile /usr/local/etc/httpd/conf/.htpasswd 
AuthGroupFile /dev/null 
AuthName By Secret Password Only! 
AuthType Basic 
  <Limit GET> 
    order allow, deny 
    allow from all 
    deny from freerange.com 18.157.0.5 .zoo.org
    require user jean 
    require user chris
    require user mike
  </Limit> 
</Directory>

log files

/usr/local/etc/httpd/logs/access_log, error_log, referer_log, agent_log

Access restriction by CGI (watch our for CGI vulnerability)

CGI login or other authorization and then reveal the target HTML page or a link to it; the target page may be floating (changing URL)
CGI control for each page
CGI can also be used for adding new users to .htpasswd

Encryption using public key cryptography

Both the request for the document and the document itself are encrypted in such a way that the text cannot be read by anyone but the intended recipient. Public key cryptography can also be used for reliable user verification.

Access restriction on non-Web Materials

Site security (or system security)
Running a web server in a chroot environment

The chroot system command places the server in such a state that it can't see any part of the file system beyond a directory tree that you have set aside for it. The directory you designate becomes the server's new root "/" directory. Anything above this directory is inaccessible.

In order to run a server in a chroot environment, you have to create a whole miniature root file system that contains everything the server needs access to. This includes special device files and shared libraries. You also need to adjust all the path names in the server's configuration files so that they are relative to the new root directory.

To start the server in this environment, place a shell script around it that invokes the chroot command in this way:

chroot /path/to/new/root /server_root/httpd

Individual user's home pages need be adjusted.

13.2 Communications Security

Communications Security is to protect the communications links between the user and the site. An aggressive cracker can sniff passwords, credit card numbers, and other confidential information directly from the Internet. A protection against this attack is encryption.

Secure Socket Layer (SSL)

SSL (Secure Socket Layer) is the scheme proposed by Netscape Communications Corporation. It is a low level encryption scheme used to encrypt transactions in
higher-level protocols such as HTTP, NNTP and FTP. The SSL protocol includes provisions for server authentication (verifying the server's identity to the client),
encryption of data in transit, and optional client authentication (verifying the client's identity to the server).

When a client makes a request for secure communications to a secure server, the server opens an encrypted port. The SSL Handshake Protocol on the server arranges authentication and encryption details with the client using public-key encryption. Using public-key encryption, the client and server exchange information about which cipher methods each understands. They agree on a one-time key to be used for the current transmission. The server might also send a certificate to prove its own identity.

In the Netscape browser, a key in the lower-left corner of the window shows whether a session is encrypted or not. A broken key indicates a non-secure session. A key with one tooth shows that the session is running on a 40-bit key. A key with two teeth shows that a 128-bit key is in use.

Secure HTTP (S-HTTP)

A competing standard to SSL is Secure HTTP (S-HTTP) from Enterprise Integration Technologies. Like SSL, S-HTTP allows for both encryption and digital authentication. Unlike SSL, though, S-HTTP is an application-level protocol-it makes extensions to HTTP.

The S-HTTP proposal suggests a new document suffix, .shttp, and the following new protocol:

Secure * Secure-HTTP/1.1.

Using GET, a client requests a secure document, tells the server what kind of encryption it can handle, and tells the server where to find its public key. If the user who matches that key is authorized to GET the document, the server responds by encrypting the document and sending it back-the client then uses its secret key to decrypt the message and display it to the user.

One of the encryption methods available with S-HTTP is PGP.

One good use of PGP, apart from S-HTTP, is in dealing with information after a user has sent it to the server.

13.3 Site Security