4Ba2 WWW Security Project

Introduction

The purpose of this section is to give an overview of the current techniques which are used to in the WWW to provide security, discuss their success and examine some possible future directions. We will begin with a general introduction to some of the areas of concern and then focus on five particular topics:

Introduction

There are three main areas where security needs to be addressed on the WWW

Client End

Automatic Application Launches
Most of the current WWW browsers allow 'helper' applications to be configured which will get loaded when the data downloaded is not in a form the browser can readily display. The problem with these helper applications is that they may be instructed to perform certain operations which would not normally be allowed by the browser. An example of this would be a MS Word document which contained a macro , the macro could perform file operations if it is loaded directly into Word. There are two solutions to the problem: (1) Disallow the helper applications for certain file formats or (2) Provide special file viewers which restrict the range of operations allowed to be performed by the helper application. Click here for more information from the WWW Security FAQ.

Bugs In Client Software
Client browsers are usually rather large monolithic software so it is quite likely that there will be software bugs in the implementation. These bugs may be quite serious, and currently there is a lot of concern about bugs in browsers which can download executable content such as Java applets. The security issues involved with applets will be discussed later but here we will note that there have been several cases where client security has been compromised due to bugs in browser implementations. The only real solution to this problem is to keep up to date with the latest release of the software and patches. Some information about some of security problems with Java can be found here in the WWW Security FAQ

Privacy of the user
When a user requests a html page from a site it is possible that the request is logged by the server. The details logged are the IP address of the client and the file requested. As mentioned above there have been some security threats from downloaded content which could upload files and send the users email address but most of these have been addressed. There is concern over the use of 'cookies' which allow the server to maintain state information about a client. These cookies will keep a permanent record on the client of the pages that a user visits, this information could be sold to a company which is interested in targeting users for sales based on subjects they may be interested in. The users have no control over who gets this information and may be targeted for 'junk mail' from sales people. In most browsers there is an option to notify the user when a cookie is about to be created and the user may refuse to allow this but once the option is turned on cookies are created as needed. More information can be found in the WWW security faq section on cookies.

Server End

Bugs in server software
Again because server software code is rather large the possibility for bugs in the code is increased. A discussion of the security holes in some of the more popular servers can be found here

Permissions of the process running the server
It is important to give the process which is running the server the least amount of privileges needed. We must also consider the file permissions allowed by this process. If files are left world readable, anybody can read the file and any access control provided by the server is useless. A better solution creates a specific account for the web server and gives the authors of the site the necessary details to login to this account. We must also consider the permissions of the process which is running the server. If the process is running as root and the server is compromised, the attacker will have root permissions on the system. This is a huge security hole, a better solution would have the server listening at port 80 as root and when it forks a child process to deal with the incoming request, the child process is given limited permissions as described above. A detailed explanation can be found here .

Controlling access to documents
The webmaster may wish to restrict access to certain sensitive documents, this may be done by using access control lists (described later) which are administered by the webmaster. The server will issue a challenge to the client and depending on the authentication method the client will send the required authorization. We can also filter the incoming requests so that we only accept requests from certain domains based on the IP address. It should be noted that it is possible to spoof the IP address with the special hardware and software so this is not a failsafe mechanism. We may also encrypt the document on the server so that only the client with the correct public key can decrypt the document. Refer to the FAQ for more information .


Communication between client and server

Security of information submitted over the network
In the HTTP specification very little provision is made for secure communications. All communication between the client and the server could be intercepted and the information contained in the requests and responses could easily be determined simply by monitoring the packets and the data that they contain. There is no means to control the path of the information so the information can easily be sniffed out at any machine along the route.

Obviously this is no good if secure transactions are required. A number of solutions have been proposed, we will discuss here their basic mechanisms

Security of information submitted by forms
Some services today require a user to register by filling out an online form to provide the service provider with necessary information. When this form is submitted the information is sent in the clear as described above. Usually the form will contain a field which contains the user's email address, it is possible that an attacker who is monitoring a transaction between a client and a server will easily be able to determine the user's email address and associate it with a particular IP address. This would be more of an infringement on the user's privacy than on their security but is still an issue.

References on security for this section

Project created by:

Return to Project Title Page