Web Site that is not Easy to hack - Part 2 HOWTO - the web site attacks

The second part of the Web server protection will focus on common Web site hacking methods. Since there are so many of them, this will be a several post job, but one has to start somewhere

Attack name - SQL Injection
Description

SQL Injection is a type of attack which has a goal of creating a custom SQL query by inserting SQL commands into fields on the web site. It is very common web engine design that the content of an input field directly becomes a part of the backend SQL statement.

For example, the input field is named UserNameField, and the SQL statement is

"SELECT * FROM Customers WHERE name = '" + UserNameField + "';"

An attacker places the following string in the input field:

a' or '1'='1

The resulting statement will become

"SELECT * FROM Customers WHERE name = 'a' or '1'='1';"

It probably won't find anyone named 'a', but the or clause with an always true condition will cause the server to return every record in the databaseThis is a relatively benign example, but the injected SQL code could be much more malicious (think drop table...)

Test

For a benign first step verification, repeat the string from the example above.As a second step, I would suggest at least a scan with a good vulnerability scanner. There are several on the market, like Tenable Nessus (free), or eEye Retina (commercial)

Control

  1. User input should not be directly embedded into the SQL statements. Instead, all special characters in the user input must be escaped or just removed prior to passing it to the SQL statement.
  2. Second control is to always use a SQL username with LEAST POSSIBLE priviledges, thus even if an attacker finds an SQL Injection vulnerability, his manouvering space is limited.

Some sites recommend using parameterized statements, where the statements use parameters (sometimes called placeholders or bind variables) instead of embedding user input in the statement. I will comment in a later post on this method.


Attack name - Directory traversal

Description

Directory traversal is also known as the .. (dot dot) attack, or the ../ (dot dot slash) attack. This vulnerability is primarily caused by bad controls in the web server software.

The idea behind the attack is to use the web server to move around the real directory structure of the Web server.

For example, the web site's root is in C:\inetpub\wwwroot\site1.com

The target is to reach the C:\Windows directory and execute the cmd.exe program

A directory traversal attack will create a HTTP get request containing ../../../Windows/system32/cmd.exe

This way, it is very easy to reach all commands of the server. In Windows Web servers, until windows 2003, the default security context of the Web server process is SYSTEM. Thus, any command executed through directory traversal is executed as having an adiministrator account. After this, the sky is the limit!


Test

It is not the goal of this author to expose direct attack sequences, since regardless of benign intent, the same code can be used for malicious purposes. I would suggest at least a scan with a good vulnerability scanner. There are several on the market, like Tenable Nessus (free), or eEye Retina (commercial)

Control

Controls should be dual.

  1. Make sure that your hosting company has the latest version of the web server software, or at least that all latest patches for their product have been applied.
  2. Confirm that the web site engine you are using performs controls on user input and parameter passed to scripts. Ideally the engine code should remove everything but what is known to be good data. This means that it should limit length of input, validate the non-alphanumeric characters or in simpler situations, just remove them from the user input.

This second control will have an additional benefit: Your site will become much more resistent to Wildcard or regular expression searches in your search fields.

Attack name - Wildcard search

Description

Not an actual attack, but a way of circumventing the intended method of interaction with a site. This can also lead to breach of confidentiality of data stored within the Web engine database.

The target of this attack is to get the web site to return much more data or data formatted in a different way then it is designed to.

Wildcard search will try to place wildcard symbols ('%','*','&') within a search field in an attempt to list a large set of data, where normal search will return a subset.

Also, this can be used to search for the '@' symbol by e-mail harvesting bots, or it can place regular expressions to find some specific set of data.

Apart from data confidentiality compromise, this type of attack will usually pass a query to a database that it is not optimized for, causing it to perform a full text search and effectively reducing performance of the web site.

Therefore, this type of attack as a base for a Denial of Service attack

Test

This type of attack is rarely covered by vulnerability tools so it is up to the administrator to check all input fields for this type of attack

Control

  1. Confirm that the web site engine you are using performs controls on user input and parameter passed to search back-end scripts. Ideally the engine code should remove everything but what is known to be good data. This means that it should limit length of input, validate the non-alphanumeric characters or just remove them from the user input.

More reading

For more on Directory traversal, please visit http://en.wikipedia.org/wiki/Directory_traversal

For more on SQL Injection, please visit http://en.wikipedia.org/wiki/SQL_injection

Designed by Posicionamiento Web