Write For Us

Submit Tips

Subscribe to Print Edition

Search

HOME

REVIEWS

HOW-TOS

CODING

INTERVIEWS

FEATURES

OVERVIEW

BLOGS

SERIES

IT ADMIN

Securing Apache, Part 7: Fool-proofing the Server OS

By Arpit Bajpai on March 1, 2011 in How-Tos, Security, Sysadmins 0 Comments

Search for:

Search

Get Connected RSS Feed Twitter

Moving deeper into Web application and Apache security, lets now focus on OS commanding attacks, and those that lead to the disclosure of crucial information and server directory paths. The attacks described below are often overlooked or trivialised.

OS Commanding
OS commanding (a.k.a. OS command execution, shell injection) is a vulnerability in websites that lets attackers execute operating system commands through the manipulation of application input. It occurs when scripts execute external commands that are constructed using unsanitised input data. Such commands will run with the privileges of the component (database server, Web application server, Web server, wrapper or application) that executed the command. This lets the attacker gain access to otherwise unreachable areas (e.g., operating system directories and files), inject unexpected and dangerous commands, upload malicious programs or even obtain passwords directly from the operating system. The diagram below illustrates this.

An OS commanding attack

OS commanding vulnerabilities are frequently found in Perl and PHP scripts, because these programming environments encourage programmers to reuse operating system binaries. However, there are also chances of such vulnerabilities in Java and ASP. Lets take a look at a few Perl and PHP examples.

The following Perl CGI code is part of a Web application for server administration. This function allows administrators to specify a directory on the server, and view a summary of its disk usage:
# ! / u s r / b i n / p e r l u s es t r i c t ; u s eC G Iq w ( : s t a n d a r de s c a p e H T M L ) ; p r i n th e a d e r ,s t a r t _ h t m l ( " " ) ; p r i n t" < p r e > " ; m y$ c o m m a n d=" d uhe x c l u d ep h p */ v a r / w w w / h t m l " ; $ c o m m a n d =$ c o m m a n d . p a r a m ( " d i r " ) ; $ c o m m a n d = ` $ c o m m a n d ` ; p r i n t" $ c o m m a n d n " ; p r i n te n d _ h t m l ;

LINUX For You on

Follow

+2,512

Find us on Facebook

When used as intended, this script simply appends the value of the user-supplied d i rparameter to the end of a specific command, which it executes, and displays the results. A normal usage URL might be something like h t t p : / / w w w . e x a m p l e . c o m / c g i b i n / s h o w i n f o . p l ?
d i r = / p u b l i c .

Open Source For You

Like 254,591 people like Open Source For You.

This functionality can be exploited in various ways, by supplying crafted input containing shell characters that have a special meaning to the command interpreter. For example, the pipe character (| ) is used to redirect output from one process to the input of another, enabling the chaining of multiple commands. An attacker can leverage this to inject a second command (and retrieve its output) with a malicious URL such as h t t p : / / w w w . e x a m p l e . c o m / c g i b i n / s h o w i n f o . p l ? d i r = / p u b l i c | % 2 0 c a t & 2 0 / e t c / p a s s w d . Here, the original d ucommands output is redirected as input to the c a t/ e t c / p a s s w dcommand, which simply ignores it, and just outputs the contents of the p a s s w dfile. Note: Most operating systems restrict access to system files. Also, the advent of shadow passwords has rendered this specific attack less useful than it previously was. Still, damaging attacks can be made by obtaining . p h pfiles which may contain database hostnames, usernames and passwords, or other configuration data, or by obtaining the database files themselves. PHP also provides functions, such as p a s s t h r u ( )and e x e c ( ) , and the back-tick operator, to execute external programs. Consider the following PHP code, which displays a list of files in a particular users home folder:
$ o u t p u t=` l sa l/ h o m e / $ u s e r n a m e ` ; e c h o$ o u t p u t ; Popular Comments Tag cloud

F acebook social plugin

August 13, 2013 42 Comments Diksha P Gupta

India has immense under-utilised talent in the cloud security space

May 6, 2013 6 Comments Priyanka Sarkar

PHP Development: A Smart Career Move

June 20, 2013 3 Comments sophie-samuel

New and amazing features of Linux

June 20, 2013 3 Comments Priyanka Sarkar

What it Takes to be an Open Source Expert

May 6, 2013 1 Comments Deepti Sharma

A valid URL for this might be h t t p : / / w w w . e x a m p l e . c o m / v i e w f i l e s . p h p ? u s e r n a m e = a r p i t . If a semicolon is used in the input, it will mark the end of the first command, and the beginning of a second. An example of a malicious URL would be h t t p : / / w w w . e x a m p l e . c o m / v i e w f i l e s . p h p ?
u s e r n a m e = a r p i t ; c a t % 2 0 / e t c / p a s s w d , which again displays the contents of the p a s s w dfile.

A Simple guide to building your own Linux Kernel

With such a vulnerability, attackers can execute any binary on the server like starting a telnet server, logging in to it with the privileges of a Web server user, performing exploits to gain root access, and perhaps attacking other hosts that are reachable from the compromised server.

The time for security

OS commanding is on the list of least-addressed vulnerabilities, but the following security measures can help curb it considerably: 1. Remove the execution bit from the everyone group (r w x r w x r w ) for OS commands. The Web server user account will not be able to execute the targeted command even if an attacker is able to trick the Web application into attempting to execute it. 2. Validate all input fields for characters like ; ,| , /or % 0 0 . Now, since the list of such characters can be endless, the best thing would be to only allow the expected input, and filter out everything else create a whitelist of acceptable inputs that strictly conform to specifications, and reject any other input, or transform it into acceptable input. For example, to neutralise the ampersand character (& ) that appears in user data, and which needs to be a part of an HTML page, it must be converted to & a m p ; . 3. As additional security, you can also try filtering out command directory names such as b i n , s b i n ,o p t .

Path-traversal (a.k.a. directory traversal) attacks

Web servers are generally set up to restrict public access to a specific portion of the servers filesystem, typically called the Web document root directory. This directory contains files and any scripts that provide Web application functionality. In a path-traversal attack, an intruder manipulates a URL in such a way that the Web server executes, or reveals the contents of, a file anywhere on the server including outside the

document root. Such attacks take advantage of special-character sequences in URL input parameters, cookies and HTTP request headers. The most basic path traversal attack uses the . . /character sequence to alter the document or resource location requested in a URL. Although most Web servers prevent this method from escaping the Web document root, alternate encodings of the . . /sequence, such as Unicodeencoding, can bypass basic security filters. Even if a Web server properly restricts path-traversal attempts in the URL path, any application that exposes an HTTP-based interface is also potentially vulnerable to such attacks. Note: For UNIX systems, the parent directory is . . /while in Windows it is . . .

Attack Scenario 1
The valid URL h t t p : / / w w w . e x a m p l e . c o m / s c r i p t s / d a t a b a s e . p h p ? r e p o r t = q u a r t e r 1 . t x t is used to display a text file. However, manipulating it into a malicious URL like
h t t p : / / w w w . e x a m p l e . c o m / s c r i p t s / d a t a b a s e . p h p ? r e p o r t = . . / s c r i p t s / d a t a b a s e . p h p % 0 0 t x twill force the PHP application to display the source

code of the d a t a b a s e . p h pfile, treating it as a text file whose contents are to be displayed. The attacker uses the . . /sequence to traverse one directory above the current directory, and enter the / s c r i p t sdirectory. The % 0 0sequence is used both to bypass a simple file extension check, and to cutoff the extension when the file is read and processed by PHP. This example highlights the critical importance of always checking and cleaning user-supplied input before allowing it to be processed.

Attack Scenario 2
The PHP code below accepts a username, and then opens a file specific to that username. It can be exploited by passing a username that causes it to refer to a different file:
$ u s e r n a m e=$ _ G E T [ ' u s e r ' ] ; $ f i l e n a m e=" / h o m e / u s e r s / $ u s e r n a m e " ; r e a d f i l e ( $ f i l e n a m e ) ;

Lets suppose a normal URL is w w w . e x a m p l e . c o m / p r o f i l e . p h p ? u s e r = a r p i t . p d f . If an attacker passes a changed query string to make a malicious URL like
w w w . e x a m p l e . c o m / p r o f i l e . p h p ? u s e r = . . / . . / e t c / p a s s w dthen PHP will read / e t c / p a s s w d

and output that to the attacker. Path-traversal attacks mostly target an applications file upload, download, and display functionalities, like those often found in work-flow applications (where users can share documents); in blogging and auction applications (when users upload images); and in informational applications (when users retrieve documents like ebooks, technical manuals, and company reports). In many cases, there may be security measures in place filters for forward or backward slashes but here too, attackers can try simple encoded representations of traversal sequences, such as those shown the following table. Table 1: Some encoding schemes Character dot forward slash backslash URL encoding %2e %2f %5c 16-bit Unicode encoding %u002e %u2215 %u2216 Double URL encoding</> %252e %252f %255c

The time for security

Path traversal attacks can be addressed with the following security measures: 1. Theres really no good reason for Apache to be allowed to serve files outside of its document root. Any request for files outside the document root is highly suspect, so well restrict it to a directory structure with the following directives in the h t t p d . c o n f file:
< D i r e c t o r y/ > O r d e rD e n y ,A l l o w D e n yf r o ma l l O p t i o n sn o n e A l l o w O v e r r i d en o n e < / D i r e c t o r y > < D i r e c t o r yw w w > O r d e rA l l o w ,D e n y

A l l o wf r o ma l l O p t i o n sI n d e x e s < / D i r e c t o r y >

(Replace the w w wdirectory name with whatever youve called your Web servers document root. The O p t i o n sI n d e x e sline in the < D i r e c t o r yw w w >section disables directory browsing, securing the server from directory-traversal attacks.) 2. Apart from this, ensure the user account of the Web server or Web application is given the least read permissions possible for files outside the Web document root. Also, change the default locations of your Web root directories. 3. After performing all relevant decoding and Canonicalisation of user-submitted filenames, validate all inputs so that only an expected character set (such as alpha-numeric) is accepted. The validation routine should be especially aware of shell meta-characters such as /and and command-concatenation characters (& &for Windows shells and the semicolon for UNIX shells). 4. Set a hard limit for the length of a user-supplied value. Note that this step should be applied to every parameter passed between the client and server, not just parameters the user is expected to modify via text boxes or similar input fields. 5. The application should use a predefined list of permissible file types, and reject any request for a different type. It is better to do this before the decoding and Canonicalisation has been performed. 6. Any request containing path-traversal sequences should be logged as an attempted security breach, generating an alert to an administrator, terminating the users session, and if applicable, suspending the users account. 7. r e a l p a t h ( )and b a s e n a m e ( )are two functions PHP provides to help avoid directorytraversal attacks. r e a l p a t h ( )translates any .or . .in a path, resulting in the correct absolute path for a file. For example, the $ f i l e n a m ein Attack Scenario 2, passed to r e a l p a t h ( ) , would return just / e t c / p a s s w d . On the other hand, b a s e n a m e ( )strips the directory part of a name, leaving just the filename itself. Using these two functions, it is possible to rewrite the script of Attack Scenario 2in a much more secure manner:
$ u s e r n a m e=b a s e n a m e ( r e a l p a t h ( $ _ G E T [ ' u s e r ' ] ) ) ; $ f i l e n a m e=" / h o m e / u s e r s / $ u s e r n a m e " ; r e a d f i l e ( $ f i l e n a m e ) ;

Tools of the secure trade

1. Dotdotpwn is a very flexible Perl-based intelligent fuzzer tool, which detects several directory-traversal vulnerabilities on HTTP/FTP servers. For Windows systems, it also detects the presence of b o o t . i n ion vulnerable systems through directory-traversal vulnerabilities. It is available for free download on its website, along with its documentation. 2. This web resource contains many path-traversal URLs that are frequently used by attackers. This domain also contains other good resources on security and ethical hacking.

Source-code disclosure
Source-code disclosure, another variant of the path-traversal attack, is a widely prevalent vulnerability in Web applications, which lets attackers extract source code and configuration files. Such vulnerabilities are found mostly in websites that offer to download files using dynamic scripts. The attacker uses this technique to obtain the source code of server-side scripts like ASP, JSP or PHP files, to discover Web application logic, including database structure, source code comments, parameters and other possibly exploitable vulnerabilities of the code. Lets understand this using a simple attack scenario.

An attack scenario
Lets assume a website uses the following PHP code, which initiates a file download from the server:
< ? p h p i f ( i s s e t ( $ _ G E T [ f i l e ] ) ) { $ f i l e=$ _ G E T [ f i l e ] ; r e a d f i l e ( $ f i l e ) ; } ? >

A valid URL for the above script is h t t p : / / w w w . e x a m p l e . c o m / d o w n l o a d s . p h p ?

f i l e = a r p i t . z i p , but the attackers malicious URL could be h t t p : / / w w w . e x a m p l e . c o m / d o w n l o a d s . p h p ? f i l e = l o g i n . p h p , which returns to the attacker

the contents of the file l o g i n . p h p . With this, the attacker learns about the filters and checks in
l o g i n . p h p , and even the names of other crucial database and systems configuration files.

To secure your application from source-code disclosure, the application should use a predefined list of permissible file types, and reject any request for a different type.

Directory listing leakage

This is a commonly-found vulnerability in many Web servers. When a Web server receives a request for a directory rather than an actual file, it may respond in one of three ways: 1. It may return a (configurable) default resource within the directory, such as i n d e x . h t m l ,
h o m e . h t m l ,d e f a u l t . h t m ,d e f a u l t . a s p ,d e f a u l t . a s p x ,i n d e x . p h p , etc.

2. It may return an HTTP status code 403 error message, indicating that the request is not permitted. 3. It may return a listing showing the contents of the directory. This happens when default resources are not present in the directory. In many situations, directory listings do not have any relevance to security. For example, disclosing the listing of an images directory may be completely inconsequential. Indeed, directory listings are often intentionally allowed because they provide a built-in means of navigating sites containing static content. But still, some files and directories are often, unintentionally, left within the Web root of servers, including: Application-generated files: Web-authoring applications often generate files that find their way to the server. A good example is a popular FTP client, WS_FTP, which places a log file into each folder it transfers to the Web server. Since people often transfer folders in bulk, the log files themselves are transferred, exposing file paths and allowing the attacker to enumerate all files. Another example is CityDesk, which places a list of all files in the root folder of the site, in a file named c i t y d e s k . x m l . Configuration-management files: Configuration-management tools create many files with metadata. Again, these files are frequently transferred to the website. CVS, the most popular configuration-management tool, keeps its files in a special folder named CVS. This folder is created as a sub-folder of every user-created folder, and it contains the files Entries, Repository, and Root. Backup files: Text editors often create backup files with extensions such as ~ ,. b a k ,. o l d ,
. b k p , and . s w p . When changes are performed directly on the server, backup files remain

there. Even when created on a development server or workstation, by virtue of a bulk folder FTP transfer, they end up on the production server. Exposed application files: Script-based applications often consist of files not meant to be accessed directly, but instead used as libraries or subroutines. Exposure happens if these files extensions are not recognised by the Web server as a script. Instead of executing the script, the server sends the full source code in response to a request. With access to the source code, the attacker can look for security-related bugs. Also, these files can sometimes be manipulated to circumvent application logic. Web servers crucial information: This is often displayed at the end of the listing page, and contains the server name, version number and other important information. Such information can be used to launch specific exploits against the Web server. Apart from the above, there are many other files which should not be disclosed publicly, such as temporary files, renamed old files, users private home folders, etc. Now, the question is regarding how attackers can gain access to directory listings. I am not going the route of guessing the path of a crucial directory via URI. For this, attackers can simply use Googles advanced search operators (now its obviously a prerequisite to know Googles advanced search operators, s i t e : ,i n u r l : ,i n t e x t : ,i n t i t l e : , etc). Note: I once again stress that neither LFY nor I are responsible for the misuse of the information given in this article. The attack techniques are meant to give you the knowledge that you need to protect your own infrastructure. You will be held solely responsible for any misuse of this knowledge.

Google searches for directory listings

Searching for i n t i t l e : i n d e x . o fs i t e : e x a m p l e . c o mwill give you the directory listing of
e x a m p l e . c o mif the directory listing is enabled on the server and in most cases, it is. Such a

result may contain any of the above crucial files. Similarly, searching for i n t i t l e : i n d e x . o f
w s _ f t p . l o gor i n t i t l e :i n d e x . o f' p a r e n td i r e c t o r y '' w s _ f t p . i n i 'will return

directory listings that contain the files w s _ f t p . l o gor w s _ f t p . i n i . In the same manner,

attackers can also search for . b a k ,. b k p ,. s w pand other vulnerable extensions and files. Another popular query among attackers is s i t e : e x a m p l e . c o mAND i n t i t l e :' i n d e x . o f '
' b a c k u p 'which yields the backup directory (if it exists on the e x a m p l e . c o mdomain). A similar

query, s i t e : e x a m p l e . c o mA N De x t : l o g , will yield all the log files on the domain. Note: The A N Dboolean operator combines two or more conditions in the same query. Another such query is " r o b o t s . t x t "+" D i s a l l o w : "e x t : t x ts i t e : e x a m p l e . c o m . This yields the r o b o t s . t x tfile for e x a m p l e . c o m , which tells the attacker about paths and directories that the website admin doesnt want Googles spider to crawl. A more dangerous query is " p h p M y A d m i n "" r u n n i n go n "i n u r l : " m a i n . p h p " , which leads attackers straight to the phpMyAdmin page on the server one of the worst nightmares of an administrator. If you try this out, please dont click through to any of the many results! Other useful trial queries that you can guess the purpose of, are:
i n t i t l e : i n d e x . o f . p a s s w o r d i n t i t l e : " I n d e xo f "_ v t i _ i n f . h t m l a l l i n u r l : a u t h _ u s e r _ f i l e . t x t a l l i n u r l : a d m i nm d b s i t e : e d uf i l e t y p e : x l s+ b a n ka c c o u n t f i l e t y p e : b a ki n u r l : " h t a c c e s s | p a s s w d | s h a d o w | h t u s e r s "

The story does not end here there are many more queries that can be generated and tested.

Time for security

Information leakage via directory listing and Google is a big issue, and also requires almost no expertise; hence, it falls in the category of dangerous vulnerabilities. You can follow these security steps to safeguard yourself: 1. Putting in blank i n d e x . h t mfiles simply prevents directory listings from being displayed to site visitors. Add some text like, " Y o u ra c c e s sh a sb e e nl o g g e d "if you wish to fool script kiddies. 2. To disable directory listing in Apache, open the . h t a c c e s sfile and look for O p t i o n s
I n d e x e sunder the directory you want to disable, and modify it to O p t i o n s I n d e x e s . Do

the same in your h t t p d . c o n ffile, and then restart Apache. Directory listing should be disabled now. 3. If you need to keep listing enabled, then do not link any files that may provide crucial information to attackers. 4. Its a common misconception that you can rely on the D i s a l l o wfeature of r o b o t s . t x t , because some search engines still crawl unwanted pages/directories of the server.

Tools of the secure trade

Goolag, an automated Google search application, helps you find some impressive information about your Web application. Download it along with its documentation, from here. Gooscan is another tool that automates queries against Google search appliances but these particular queries are designed to find potential vulnerabilities on Web pages.

Information leakage
Information leakage occurs when a website reveals sensitive data which may aid an attacker in exploiting the system. It does not necessarily represent a security breach, but it provides the attacker information that may be useful for future exploitation. There are many ways of forcing a Web application to leak this type of information.

HTML comments
Website programmers often leave comments in HTML source code. These are mainly for their self-reference, and sometimes for other programmers to see. However, often these comments help attackers in understanding the target better. For example, look at the HTML code below:
< T A B L Eb o r d e r = " 0 "c e l l P a d d i n g = " 0 "c e l l S p a c i n g = " 0 "h e i g h t = " 5 9 "w i d t h = " 5 9 1 " > < T B O D Y > < T R > < ! I ft h ei m a g ef i l e sa r em i s s i n g ,r e s t a r tZ B E A S T> < T Db g C o l o r = " # f f f f f f "c o l S p a n = " 5 "h e i g h t = " 1 7 "w i d t h = " 5 8 7 " >< / T D >

Here we see a comment left by the programmer indicating what one should do if image files do not show up. The key information here is the host name of the server, which is mentioned explicitly in the code, Z B E A S T .

JavaScript code
Parts of JavaScript code, especially those dealing with data validation, can reveal a lot of information about application business rules. Often, programmers implement data validation on the client side itself, thinking that this will reduce server-side load. This is a mistake.

Tools comments and metadata

Tools that are used to create Web pages (either server-side or client-side) also often leave comments in the code, which could include paths in the filesystem.

WebDAV
Web Distributed Authoring and Versioning (WebDAV) is an extension of the HTTP protocol. It consists of several new request methods that are added on top of HTTP to allow functionality, such as editing and managing files stored on WWW servers even from remote systems. If it is enabled by default on a website, WebDAV will allow anyone to enumerate files on the site, even with all directory indexes in place and directory listings turned off.
P R O P F I N D(an HTTP method used by WebDAV) is used to retrieve properties (stored as XML)

from a resource, and also allows one to retrieve the collection structure (a.k.a. directory hierarchy) of a remote system. This can be used by attackers as shown below, using telnet to connect to w w w . e x a m p l e . c o m :
$t e l n e te x a m p l e . c o m8 0 8 0 T r y i n g2 1 7 . 1 6 0 . 1 8 2 . 1 5 3 . . . C o n n e c t e dt oe x a m p l e . c o m . E s c a p ec h a r a c t e ri s' ^ ] ' . P R O P F I N D/H T T P / 1 . 1 D e p t h :1

The above process will reveal the contents of the Web server root folder. Users browsing normally would get served i n d e x . h t m l , but when using WebDAV, the attacker can reveal many secret files.

Verbose error messages

These are messages which are mainly responses to an invalid query. A prominent example is the error message associated with SQL queries. SQL injection attacks typically require the attacker to have prior knowledge of the structure or format used to create SQL queries on the site. The information leaked by a verbose error message can provide the attacker with crucial information on how to construct valid SQL queries for the backend database. (For information on SQL injection, refer to Part 1 of this series.) The following error message was returned by placing an apostrophe into the username field of a login page:

A nE r r o rH a sO c c u r r e d .E r r o rM e s s a g e :S y s t e m . D a t a . O l e D b . O l e D b E x c e p t i o n :S y n t a xe r r o r( m i s s i n go p e r a t o r )i nq u e r ye x p r e s s i o n' u s e r n a m e=' ' 'a n d

In the first error statement, a syntax error is reported. The error message reveals the query parameters that are used in the SQL query: u s e r n a m eand p a s s w o r d . The leaked information here is the missing link for an attacker to begin to construct SQL injection attacks against the site. A common error that we can see during our search is HTTP 404 Not Found. Often, this error code provides useful details about the underlying Web server and associated components. For example:
N o tF o u n d T h er e q u e s t e dU R L/ p a g e . h t m lw a sn o tf o u n do nt h i ss e r v e r . A p a c h e / 2 . 2 . 3( U n i x )m o d _ s s l / 2 . 2 . 3O p e n S S L / 0 . 9 . 7 gD A V / 2P H P / 5 . 1 . 2S e r v e ra tl o c a l h o s tP o r t8 0

This error message can be generated by requesting a non-existent URL. After the common message that shows a page as not found, there is information about the Web server version, OS, modules and other products used. This information can be very useful to attackers. Other methods include guessing the files with no direct link pointing to them. The best example of this is guessing the URL for the admin interface of the Web application for example, guessing the URL w w w . e x a m p l e . c o m / w p a d m i n /for any WordPress-based website is quite easy.

Time for security

1. Disable WebDAV in Apache if you dont need it. To do this, find the following entries in
h t t p d . c o n fand change O nto O f f .
< I f D e f i n eD A V > D A VO n < / I f D e f i n e >

By default, / u s r / l o c a l / h t t p d / h t d o c sis the only directory with the I f D e f i n eD A V directive. Other directories that have this directive will also need to be changed. After this, restart Apache. 2. When dealing with information disclosures in HTML comment tags, it would not be appropriate to deny the entire request for a Web page due to comment tags. To handle this, theres a really cool feature in Apache 2.0, called filters (refer to official Apache documentation). The basic premise of filters is that they read from standard input and print to standard output. This feature becomes intriguing from a security perspective when dealing with this type of information disclosure prevention. 3. The application should never return verbose error messages or debug information to the users browser. When an unexpected event occurs (such as an error in a database query, a failure to read a file from disk, or an exception in an external API call), the application should return the same generic message, informing the user that an error occurred. 4. In Apache, custom error pages can be configured using the E r r o r D o c u m e n tdirective in h t t p d . c o n f . For example: E r r o r D o c u m e n t5 0 0/ g e n e r a l e r r o r . h t m l . This will redirect users to g e n e r a l e r r o r . h t m l , which can be your own modified error page. 5. Disable or limit detailed error handling. In particular, do not display debug information, stack traces, or path information to end-users. Moreover, overriding the default error handler so that it always returns 200 (OK) error screens reduces the ability of automated scanning tools to determine if a serious error occurred. 6. Lastly, programmers need to be more aware about whether they are unintentionally providing any crucial information. We will deal with other dangerous attacks on Web applications and how to secure Apache in the next article. Always remember: know hacking, but no hacking.

References
Google Cheat Sheet: Cool web tools and services offered by (and about) Google [PDF] Information Leakage From Google Hacking
Feature image courtesy: DeWitt Clinton. Modified and reused under the terms of CC-BY 2.0 License.

Related Posts:
Secure Upload Methods in PHP Securing Apache, Part 9: Attacks that Target PHP-based Instances Securing Apache, Part 11: Logs, et al. Puppet Data Centre Automation Solution, Part 2: User & Group Management Connecting to MySQL with Python and PHP
Tags: .htaccess, Apache, Apache HTTP Server, apache security, CityDesk, command execution, database server, DeWitt Clinton, directory paths, Google, Gooscan, Home directory, html, HTTP cookie, Java, JSP, LFY March 2011, log file, malicious programs, perl, PHP, php scripts, Securing Apache series, Security, server administration, server directory, shell, SQL injection, system directories, unix, web applications, Web server, WebDAV

Article written by:

Previous Post

Next Post

Digital Forensic Analysis Using BackTrack, Part 1

The Needle and the Haystack: Exploring Search Models, Part 2

0 comments Leave a message...

Newest Community Share

No one has commented yet.

C o m m e n t fe e d

Su b s cri b e vi a e m a i l

Reviews

How-Tos

Coding

Interviews

Features

Overview

Blogs

Search
Popular tags
Linux , ubuntu, Java, MySQL, Google, python, Fedora, Android, PHP, C, html, w eb applications , India, Microsoft, unix , Window s , Red Hat, Oracle, Security , Apache, xml, LFY April 2012, FOSS, GNOME, http, JavaScript, LFY June 2011, open source, RAM, operating systems

For You & Me Developers Sysadmins Open Gurus CXOs Columns

All published articles are released under Creative Commons Attribution-NonCommercial 3.0 Unported License, unless otherw ise noted. LINUX For You is pow ered by WordPress, w hich gladly sits on top of a CentOS-based LEMP stack.