WyseLabs Internet Marketing Forum :: Start Sharing

The following points are helpful to secure your websites from all kinds of attacks.

1. Sanitize browser input.

All input from web browsers, such as user data from HTML forms and cookies, must be stripped of special characters and HTML tags.

This is by far the most common vulnerability in web applications. Everything from directory traversal problems to cross-site scripting problems can usually be traced to the simple lack of proper stripping of user input.

There are two separate dangers with browser input data:

a. Input containing special characters such as ! and & could cause the web server to execute an operating system command or have other unexpected behavior.

b. User input stored on the server, such as comments posted to a web discussion program, could contain malicious HTML tags and scripts. When another user views the input, that user's web browser could execute the HTML and scripts.

2. Don't put everything in the HTML directory.

Don't put everything in the HTML directory:

Most web applications use many types of files:

* Static files: HTML headers, footers, JPEG images and other raw non-changing content.
* Parsed HTML: static HTML mixed with executable code, such as PHP and ASP files.
* Include files: Libraries and routines shared by parsed HTML and other files.
* Data files: Database or flat text files written by the web application

Most beginning web developers dump all their files in the HTML directory... the "public_html" "htdocs" or "C:\inetpub\wwwroot" directory on the web server.

Web servers use a "permission by directory" model: files are treated according to the directory they are in. Every file in the HTML directory can be accessed by a web browser if the URL is known. Every file in the cgi-bin directory can be executed.

If your web applications write data files (such as a guest book application or message board), don't put the data files in the cgi-bin directory or html directory. Every file in cgi-bin can be executed, including data files. Every file in /public_html can be read by a browser. Never assuming an outside will never guess the name of a file in those directories, because eventually... they will.

For example, if your web app places a data file named "card_numbers.dat" in /public_html, any outsider who guesses the file name can view it's contents in their browser. Likewise, if library file "user_validation.pl" is placed in cgi-bin it can be run, even though the code in that file should only be read by other executable files.

Place data files is a directory outside of both /html and /cgi-bin. For example, create a /data directory outside the cgi-bin and public_html directories so the files cannot be executed or read from a browser. Likewise a create /include directory so library files and header code cannot be executed or read from a browser.

3. No to hidden fields.

Many CGI programs rely on so-called "hidden" form fields to store state information, settings and previous input data. However, HTML "hidden" fields are not hidden and not secure. Users can see them simply by viewing the HTML source of your form in their browser. It's easy for a user to change "hidden" fields... they only have to same the HTML form to their computer, edit the HTML then re-submit the form.

Contents of hidden fields should be sanitized and validated just like any other user input field. Hidden fields should not be used to set access modes or privileges for a CGI program (such as an 'admin' mode or 'paying user' privilege) without also using some form of user validation, such as password and username access restrictions.

A better way of preserving state information and settings is to store data in a file or database on the server then use an HTTP cookie or unique URL ID to reference the file. This is more difficult to program, but important data stays on your server.

4. Use POST instead of GET

HTML forms can be submitted using either GET or POST methods. POST is preferred, especially when sending sensitive information.

The GET method sends all form input to the web application as part of the URL. For example:

http://www.yourdomain.com/cgi-bin/cart. ... d=happypup

When the web application is called using GET, the above input is visible on the browser's URL location window. However, a more dangerous problem is that URLs are logged in many places:

* The web server access log
* The web browser's disk cache and history file
* In firewall logs
* In proxy server and web cache logs such as Squid.

All this logging allows others to see the data sent from HTML forms using GET.

The POST method sends form input in a data stream, not part of the URL. The data is not visible in the browser location window and is not recorded in web server log files.

The POST method is also more practical... there's a limit to how many characters can be sent using the GET method, but POST can send an almost unlimited amount of data from an HTML form.

However, even though POST information is generally not logged, like all other plain text information sent from a browser it can still be sniffed as it passes across the Internet. However, sniffing must be done in real time as information is sent across the Internet and requires the attacker to have physical access to the data lines between the web browser and web server. The risk of information being sniffed is far less than the risk of information being gathered from log files.

5. Validate on the server

Developers know they must check that form input fields contain the correct data type, that required input is not missing and to perform other simple sanity checks. However, a disturbing trend recently has been to use Javascript or Java applets to validate user input.

In a traditional web application, HTML form fields are checked when the user submits the HTML form to the web server. If a mandatory field is blank or has the wrong type of input, the web application typically sends back an HTML page describing the errors and lets the user must submit the form again.

Client-side validation lets this work be done in by the browser. Javascript or Java applets can be used to check inputs before the form is submitted to the web application, and not allow the form information to be sent until all fields are correct. This saves time and processing by the web application. It moves the overhead of input validation from the web application to the browser.

This technique saves load on the web server, but the problem is that anything running on the client end can never be trusted. Javascript in an HTML form can be changed or disabled by the end user very easily. Java applets can be disabled by the end user, or even decompiled and re-written.

It's easy for a knowledgeable user to save an HTML form, disable the embedded Javascript, then use the modified form to submit bad data back to the web application. When the application expects all input validation to have already been done by the web browser, and therefore doesn't double check the input, your web app can be compromised.

For this reason web applications should always validate form inputs on the server even if they are also validated on the client. Client-side input can never be trusted. Client-side validation should be used as a complement to server-side validation... a means of catching simple input mistakes to reduce the number of times the web server has to validate input. Client-side validation should never be trusted as a replacement for additional server-side validation.

Client-side validation is valuable... for highly loaded web sites it offloads a lot of work from the server to the browsers. However if server load is not a factor, it's probably not worth the trouble of writing both client-side and server-side validation routines for HTML form input.

6. Avoid real directory and file names

Never use actual directory or file names as parameters or construct names based on user input. Instead, use keywords that are pointers and store the actual file or directory names in a lookup table.

For flexibility, the locations of the files can be pulled in from an external configuration file, rather than be hard-coded into the application. However, make sure the config file cannot be accessed by web users (ie. put it in a separate data directory outside the html directory. If the web server is shared by many users, also ensure the data file can't be changed by other users on the server.

If your web application absolutely must be capable of opening ad hoc files based directly on browser input, rather than a predetermined list, never accept complete path and filenames from HTML form input fields. Your web application should at least prefix the input filename with an absolute path and strip slashes, backslashes, NULLs and sequential dots ( ".." and "..." ) from the input.

All applications should be written to trap errors. However, web applications are frequently attacked by crackers. It's a good idea to not only trap and recover from errors, but also to log events that may indicate an attack:

7. Before opening a file for reading, a web application should check that the file exists and is readable. If the filename was constructed based on input from an HTML form, attempts to access a non-existent file or one it doesn't have privileges to read can indicate an attack.

8. If a web application was written to be called with the POST method, it should raise an alarm if called using methods such as GET or PUT. Some web apps written to work when called by one method will fail when called by others. Even if your app handles with all methods properly, many crackers try this form of attack. Detecting it will warn you someone is trying to crack your web application.

9. If certain HTML input fields must always be present in a form (such as hidden fields that store values), the application should raise an alarm if the form is submitted without all the required fields. Missing fields could indicate a cracker is calling the web app from a saved version of the HTML form or from a script in an attempt to break in.

10. Denial of service attacks (where a malicious user tries to overload a server or application) can be detected by watching for repeated access from the same IP address. Multiple requests per second from the same IP could indicate a denial of service attempt, or that a cracker is running an automated script attempting to break the application.

Look beyond the web application:

Securing the application itself is worthless if the web server itself has not been secured. Internet security begins with having secure servers and networks. That means the web server operating system and all software on it has the latest security patches installed, it sits behind a well-maintained firewall, and everything is monitored for break-in attempts.

Many organizations believe skilled application developers are also skilled at system and network management. However, that is extremely rare. Being an application developer is a full time career, as is being a system administrator, network manager and security professional.

Many of the well-publicized attacks on web sites targeted well-known operating system and network problems that were missed simply because the organization was focused on developing the web applications and design of the web site, or assumed their development team had all the answers. The "Code Red" worm that affected hundreds of thousand of Microsoft's IIS web server was able to spread largely because unskilled or overworked staff didn't patch a security hole in that product soon enough.

Securing web applications requires a combined effort in many areas: application design, server management, network management and security auditing. Professionals specializing in one of these areas require a good knowledge of all the others, but in reality each area is a specialty that requires the attention of a focused individual or team.