Wednesday Oct 01, 2008

Simple Tips to secure your Web Servers.

1). Introduction


In our global business environment it is imperative for all participants to have a web site. The Web and Electronic commerce sites are growing in numbers every day and so are the threats to them. Businesses are exposed to outside world through web servers. An April' 2006 survey indicates that there are more than 80 million web sites on the internet(1).  

Organizations can protect themselves from threats using common security measures including firewalls, IDS(Intrusion Detection Systems). These common security solutions still do not provide a completely safe environment against sophisticated techniques used by modern day hackers.  The reliance and dependency on their websites for Enterprise corporations have grown to a greater extent with the advancement of technology. Many a times a simple compromise to their web site could cost a lot to the business. Needless to day Security is a prime concern when choosing a Web server.

Security vulnerabilities in web server and the business applications deployed on them pose a big challenge to keeping corporate data and resources safe from snooping, intrusion, or misuse.  Since web servers provide data via an externally or publicly exposed interface, the web server is a well-known target for exploitation. Unprotected and poorly configured web servers are highly susceptible for malicious activity, such as theft or the denial of service to an organization’s resources.  

2). Scope

Major security forums (e.g., SysAdmin(2), Security (SANS) Institute(3) and the Open Web Application Security Project (OWASP)(4)) do a good job of constantly updating the community in great detail about security threats and mitigation techniques. The following are some well known and most often used vulnerabilities that pave the way for attacks against an organization's web server.

  • Communication programs such as Instant Messaging.
  • non-existent/poorly administered backup and logging mechanisms.
  • weak/no/default passwords
  • Cross site scripting(XSS).
  • Unchanged default installation and configuration.
  • Lazy programming techniques.
  • File sharing applications.
 

Though web server security can be enhanced by various automated tools, this blog identifies two sources that play key role in providing a secure environment for web server and the web applications hosted in them. They are Web Server Administrators and Web Application Developers. 

This blog does not cover all of the possible security guidelines/practices that these two entities can practice, but only highlight some of the most obvious and simple techniques and procedures that are very effective in preventing attacks on web server thereby increasing the security. The core theme of this blog is “securing web servers by minimizing vulnerabilities”.

A Web Server administrator is usually a dedicated person or sometimes a team depending on the size of the organization. The administrator's main responsibilities include installing, configuring and updating web servers with the latest patches. The administrator is also responsible for working closely with the development team to fine-tune web server to suite development needs, backup/restore and implement security policy related to web-servers.

A web application developer is a software application developer responsible for automating the business requirements through front-end and back-end e-commerce solutions. Responsibilities include deploying the application in production web servers by working with web server administrator. Web server security is a wide area offering solutions at various levels from network to physical security. All of the attacks on web server happen through vulnerabilities in web applications, hence this blog is focused on the web application developer who builds these applications and the web server administrator who provides a secure container to host these applications. Though there are several ways to prevent such attacks from reaching web server and the applications, they are not fail-proof, so it is important to provide stronger security to the prime targets the web applications.

3). Administrators role in securing web servers.

Let us look at the some of the of simple techniques that a web server administrator to secure web servers.

 

3.1). Configure to prevent DOS attacks:

It is important to configure web servers appropriately and not rely on the default configuration. Configured correctly, it is possible even to prevent Denial-of-service attack from reaching the web-server. Denial-of-Service (DoS) attack is an explicit attempt to prevent legitimate users from using a service by some malicious users of the Server. Such an attack can be launched by sending continuous requests to the server for a particular web resource. Most of the web servers of recent times do provide easy mechanism to prevent such attacks. For example Sun Java System Web Server(5) can detect DoS attack by monitoring frequently accessed URI and denying request, if the request frequency is considerably high. It is very easy to tweak the server to prevent Denial-Of-Service attacks by configuring request limits and monitoring maximum number of connections per virtual server.

 

3.2). Configure not to reveal HTTP headers:

The more information web servers provide about themselves to the outside world, the more vulnerable they are to be attacked. Hackers are always looking for information to exploit vulnerabilities. HTTP response headers are information that is sent from a web server to its client applications(predominantly a web browser). A poorly configured web server might reveal information such as “web server version,  operating system name and version” etc., Web server software like other software products have bugs in them and usually the vendors publicly alert their users of such bugs and strongly encourage them to apply fixes/patches to resolve them. If the version of the web server and the operating system it runs on is known to a hacker, it is easy to find out open bugs/vulnerabilities from its vendors site and base their attacks. Freely available programs such as websniffer (6) reveal http response header information.  Below is a sample output gathered from hotmail.com web site where the web server version is visible.

HTTP/1.1·302·Found
Connection:·close
Date:·Mon,·10·Mar·2008·19:49:52·GMT
Server:·Microsoft-IIS/6.0
X-Powered-By:·ASP.NET
X-AspNet-Version:·1.1.4322
Pragma:·no-cache
Location:·http://mail.live.com/
Cache-Control:·no-cache
Pragma:·no-cache
Expires:·-1
Content-Type:·text/html;·charset=utf-8
Content-Length:·138

The vendors do not turn off such header information as such information could benefit statistical companies such as Netcraft to gather data, but there are documented ways that an administrator could use to turn them off. As an administrator it is important to follow such post installation configuration to make web server more secure.

 

3.3). Configure to prevent attacks leveraging search engines:

Search engines are so powerful to penetrate deep into web server during their preparation of index database. Popular ones such as Google uses sophisticated queries to get more information about a web site and unfortunately hackers just leverage the same mechanism. It is quite easy for an average surfer to peek into other people's websites using exploits in search engine mechanism. This type of attacks are very simple to execute but often could cause severe damages.(7) Though these type of attacks using search engines are collectively called as “Google Hacking”, the popular search engine Google is most often used. Network printers, VNCs, Automated cameras are some of the quite common targets of such attacks by average surfers. To avoid such attacks, an Administrator should configure “robots.txt” file correctly preventing search engine access to confidential and sensitive information. If the page has already been picked up by Google and has been cached, then tools such as as Google automatic URL removal system(8) should be used to secure web server. Google also provides other options for removing such information(9).

 

3.4). Coordinate placement of information and scripts

 on the web server with appropriate authorities to prevent from URL manipulation attacks.

 

3.5). Avoid installing unnecessary tools, samples and 3rd party software

that comes with web server installation. Most of such tools do not follow the same security standard as the web server and hackers often exploit the server through them. Some of the scripts part of the samples are often used by hackers to stage an attack.

 

3.6). Administer the server with a good patch management system.

It is important to stay up-to-date with the vendor on fixes for bugs in web server. Wherever possible this process should be automated. Good auditing tools such as(showrev on Solaris(10)) will come handy to detect the status of the system.


4). Developers role in securing web servers.

Web applications are common target of attack. Some of the famous attacks on web server manipulating web applications are(source: 11))

  • Attack on a large bank in 2000 by manipulating the account number in URL.  
  • Acme Art Inc.,'s web site was hacked in October 2001 revealing all credit card information.
  • In 2002, a Swedish company's turnover report was accessed by manipulating the year numbers in the URL.
  • A simple attack on Harvard Business School's website by prospective students enabled them to check their admission status in 2002.
  • Famous pet supply retailer Petco and fashion Label Guess were attacked in June 2003 exposing customers credit card information. These attacks used a technique called SQL Injection.
  • In 2004 attack on web servers through the worm named “Santy”.
  • In november 2004, SCO's website logo was replaced by the text “We own all your code, pay us all your money”.

Let us look at the type of attacks that are very common against web applications and simple techniques/tips that the web application developer can use to mitigate these attacks.

4.1). Parameter Manipulation:

Parameter Manipulation is a simple technique hackers use to exploit vulnerabilities in web applications and cause severe damage. This technique modifies data that is being sent from a web browser to a web server.  Hackers modify the values of  Form Fields, Cookies, URL Query Strings, HTTP Headers and Cookies to their advantage to attack. It is important for the web application developer to understand these sources of attack and take preventive mechanism as part of the application design and development. 

 

4.1.1) Form Fields Manipulation:

This is the easiest of attack that can be performed on a poorly designed/written web application. The functionality provided by almost all of the web browsers on the market “the ability to read the html source” is mis-used by hackers to their advantage. HTML forms use visible and hidden form fields to accept user input and pass them to the web server to be used. Hidden form fields serve the purpose of hiding the values from users are most of the times used by web developers to conveniently store local variables required for the application. This is a very bad design as the attacker could simply read the file, find out the hidden field and manipulate the values before sending it to the server . 

Mitigation Techniques: Hidden form fields should be avoided and their usage should be replace by session variables if possible. Other approach would be to encrypt and decrypt the values to be hidden programmatically on the browser and server side respectively using a well known encryption mechanism such as MD5.

 

4.1.2). Cookie Manipulation:

The protocol used widely in internet HTTP is stateless, meaning that it cannot be used for conversational style of communication. Cookies are used to achieve this. Cookies store data to enable such communication. They store data temporarily for a session or permanently depending on the application needs. There are tools such as Winhex(12) to modify the local data. The following example shows a simple modification that can fool a poorly written web application to execute with “administrator” rights. “Cookie: lang=en-us; ADMIN=no; lvar=1 ; “ can be easily modified to “Cookie: lang=en-us; ADMIN=Yes; lvar=1 ;”. 

Mitigation Techniques: Cookies should be avoided to the extent possible and replaced with session variables. In some cases where cookies need to be used, they should be encrypted and validated against session information stored on the server side.

 

4.1.3). HTTP Headers Manipulation:

HTTP headers hold control information on HTTP request coming from a web client to a web server. Though it is not easy to modify the headers, hackers sometimes make programmatic alterations to the headers often times to take control of the web site or to act as a precursor for other manipulation attacks. One of the field in HTTP header that has been known to get altered is the REFERER field. Simple tools such as modifyheaders(13) makes the job of hackers easy.

Mitigation Techniques: As a web application developer, never rely on REFERER field.

 

4.1.4). URL Manipulation:

HTML forms are submitted to the server using one of GET or POST http methods. When GET is used, the parameters and values passed to the server are added as part of the URL. This enables malicious users to modify the URL and alter the parameter values to their advantage to orchestrate an attack.

Mitigation Techniques: Using session tokens, avoiding parameters in the query strings, encrypting parameter values embedded in query strings especial are some of the effective way of avoiding URL Manipulations.

4.2). Cross-site scripting(XSS):

This type of attack is enabled by vulnerabilities in web applications wherein malicious code can be injected(could be html or client-side application) to carry out the attack. Most common way of XSS attack is to bypass access controls. Generally another script or executable is invoked as part of the malicious code to cause damage.

Mitigation Techniques: Simple programming techniques such as filtering out dangerous characters as part of the validation will help. XSS vulnerability scanners come handy during development of such web applications.

 

4.3).SQL Injection:

SQL Injection attacks are done by injecting SQL strings to access database through web applications. This is an easy attack to carry out if the application that is the target of the attack dynamically creates SQL Queries based on user entered parameters that are not validated. For example, a basic HTML form might have two input fields to allow users to log in to a Web site with a username and password. If the database query that looks up the information relies on the user's input for its variables, without validating that input, the database can be compromised by adding a string to the password input field. For example the query SELECT \* FROM Users WHERE UserName ='" + txtuid.Text + "'", conn);   that is hardcoded in the web application, can be easily altered as txtuid is user input value. The modification could be changes to the parameter values to cause destruction or appending destructive SQL command(s) to the end of the query strings by using malicious input field values. 

Mitigation Techniques: Using bound parameters(PREPARE statements), Limiting database permissions to segregate users, Using stored procedures are some of the good practices to prevent SQL Injection.

It is also important to test the application during development using automatic SQL injection tools. For example SQLMap(14) is one such automatic blind SQL injection tool. SQLNinja(15) is another one.

 

Golden Rules to follow: 

1).Never trust input, especially user input, always validate input.
2).Do Not Make Security Decisions Based on Parameters Accessible on the Client-Side.
3).Follow well established/tested security standards.
4).Use scanning tools: Most of the parameter manipulation attacks can be prevented if developers use scanning tools. A lot of scanning tools are available to identify such vulnerabilities during web application development period itself. Leveraging such tools combined with awareness and intelligent coding would prevent most of parameter manipulation attacks. Some of the popular web application scanners are listed here
1).Scando Web application scanner from Kavado
2).WebInspect from SPI Dynamics
3).Web Vulnerability Scanner from Acunetix.
4).AppScan from watchfire.

Conclusion:

This blog presented some of the simple techniques/tips that are very effective for securing web servers.  As web application developer/web server administrator it is important not to ignore these fine details failing which the business loss is enormous. 
Though it is easy to overlook some of the security measures amidst challenges such as time constraint, open sourced web server exposing their source code, accountability issues, it is imperative that having a secure web server is something that all organization involved in e-commerce should consider as their number one priority.

 

References:

(1): http://news.netcraft.com/archives/2006/04/06/april_2006_web_server_survey.html
(2): http://www.samag.com/
(3): http://www.sans.org/
(4): http://www.owasp.org
(5): http://docs.sun.com/app/docs/doc/819-2629/gdhhn?l=en&a=view&q=denial+of+service
(6):http://web-sniffer.net/
(7):http://www.theregister.co.uk/2001/11/28/the_google_attack_engine/
(8):https://www.google.com/support/bin/topic.py?topic=360
(9):http://www.google.com/support/webmasters/bin/topic.py?topic=8459
(10):http://docs.sun.com/app/docs/doc/816-5166/6mbb1kqf8?a=view
(11): http://www.acunetix.com/websitesecurity/application-scanning-wp.htm
(12):http://www.x-ways.net/winhex/
(13): http://modifyheaders.mozdev.org/
(14): http://sqlmap.sourceforge.net/ 
(15): http://sqlninja.sourceforge.net/

Sunday Jun 22, 2008

Watch this section..

I will soon be writing/sharing with you my thoughts on different areas such as Database, Security, Servers(App/Web), Product Marketing, IT Policies, Knowledge Management, Interesting analysis of strategical paths that some companies have adapted. Please visit back soon and I hope I can entertain you. 


"The more you share, the more you learn.". 

About

sathyan

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today