Test Application Platform Configuration (OTG-CONFIG-002) - Revision history

Tony Hsu HsiangChih: /* System Configuration */

2016-03-24T22:49:49Z

‎System Configuration

Tony Hsu HsiangChih: /* How to Test */

2016-03-24T22:43:59Z

‎How to Test

Andrew Muller: Reformat headings

2014-08-05T15:08:21Z

Reformat headings

Jane O'Connor: Added Andrew's changes.

2014-08-01T19:04:54Z

Added Andrew's changes.

Jane O'Connor: Final edit

2014-05-13T20:05:47Z

Final edit

Show changes

Mmeucci at 17:37, 7 April 2014

2014-04-07T17:37:37Z

Clerkendweller: Logging section expanded / Three references added

2013-10-15T15:55:34Z

Logging section expanded / Three references added

Andrew Muller: Andrew Muller moved page Testing for application configuration management (OWASP-CM-004) to Test Application Platform Configuration (OTG-CONFIG-002): Align with common number and cross-product correlation initiative

2013-07-28T13:16:00Z

Andrew Muller moved page Testing for application configuration management (OWASP-CM-004) to Test Application Platform Configuration (OTG-CONFIG-002): Align with common number and cross-product correlation initiative

Amro Ahmed at 17:18, 17 February 2013

2013-02-17T17:18:33Z

Amro Ahmed at 17:17, 17 February 2013

2013-02-17T17:17:30Z

@@ Line 28: / Line 28: @@
 ====System Configuration ====
 CIS-CAT gives IT and security professionals a fast, detailed assessment of target systems' conformance to CIS Benchmarks.
 [https://benchmarks.cisecurity.org/downloads/audit-tools/images/assessment_000.png]
+[https://benchmarks.cisecurity.org/downloads/multiform/]
 ===Gray Box Testing ===

@@ Line 25: / Line 25: @@
 Comment review should be done in order to determine if any information is being leaked through comments. This review can only be thoroughly done through an analysis of the web server static and dynamic content and through file searches. It can be useful to browse the site either in an automatic or guided fashion and store all the content retrieved. This retrieved content can then be searched in order to analyse any HTML comments available in the code.
@@ Line 158: / Line 163: @@
 Log statistics or analysis should not be generated, nor stored, in the same server that produces the logs. Otherwise, an attacker might, through a web server vulnerability or improper configuration, gain access to them and retrieve similar information as would be disclosed by log files themselves.
 ==References==

@@ Line 11: / Line 11: @@
 ==How to Test ==
-==Black Box Testing ==
+===Black Box Testing ===
-===Sample and known files and directories===
+====Sample and known files and directories====
 Many web servers and application servers provide, in a default installation, sample applications and files that are provided for the benefit of the developer and in order to test that the server is working properly right after installation. However, many default web server applications have been later known to be vulnerable. This was the case, for example, for CVE-1999-0449 (Denial of Service in IIS when the Exair sample site had been installed), CAN-2002-1744 (Directory traversal vulnerability in CodeBrws.asp in Microsoft IIS 5.0), CAN-2002-1630 (Use of sendmail.jsp in Oracle 9iAS), or CAN-2003-1172 (Directory traversal in the view-source sample in Apache’s Cocoon).
@@ Line 20: / Line 20: @@
-===Comment review===
+====Comment review====
 It is very common, and even recommended, for programmers to include detailed comments on their source code in order to allow for other programmers to better understand why a given decision was taken in coding a given function. Programmers usually add comments when developing large web-based applications. However, comments included inline in HTML code might reveal internal information that should not be available to an attacker. Sometimes, even source code is commented out since a functionality is no longer required, but this comment is leaked out to the HTML pages returned to the users unintentionally.
@@ Line 27: / Line 27: @@
-==Gray Box Testing ==
+===Gray Box Testing ===
-===Configuration review===
+====Configuration review====
 The web server or application server configuration takes an important role in protecting the contents of the site and it must be carefully reviewed in order to spot common configuration mistakes. Obviously, the recommended configuration varies depending on the site policy, and the functionality that should be provided by the server software. In most cases, however, configuration guidelines (either provided by the software vendor or external parties) should be followed to determine if the server has been properly secured.
@@ Line 52: / Line 52: @@
-===Logging===
+====Logging====
 Logging is an important asset of the security of an application architecture, since it can be used to detect flaws in applications (users constantly trying to retrieve a file that does not really exist) as well as sustained attacks from rogue users. Logs are typically properly generated by web and other server software. It is not common to find applications that properly log their actions to a log and, when they do, the main intention of the application logs is to produce debugging output that could be used by the programmer to analyze a particular error.
@@ Line 103: / Line 103: @@
-===Log location===
+====Log location====
 Typically servers will generate local logs of their actions and errors, consuming the disk of the system the server is running on. However, if the server is compromised its logs can be wiped out by the intruder to clean up all the traces of its attack and methods. If this were to happen the system administrator would have no knowledge of how the attack occurred or where the attack source was located. Actually, most attacker tool kits include a ''log zapper '' that is capable of cleaning up any logs that hold given information (like the IP address of the attacker) and are routinely used in attacker’s system-level root kits.
@@ Line 112: / Line 112: @@
-===Log storage===
+====Log storage====
 Logs can introduce a Denial of Service condition if they are not properly stored. Any attacker with sufficient resources could be able to produce a sufficient number of requests that would fill up the allocated space to log files, if they are not specifically prevented from doing so. However, if the server is not properly configured, the log files will be stored in the same disk partition as the one used for the operating system software or the application itself. This means that if the disk were to be filled up the operating system or the application might fail because it is unable to write on disk.
@@ Line 126: / Line 126: @@
-===Log rotation===
+====Log rotation====
 Most servers (but few custom applications) will rotate logs in order to prevent them from filling up the file system they reside on. The assumption when rotating logs is that the information in them is only necessary for a limited amount of time.
@@ Line 141: / Line 141: @@
-===Log Access Control===
+====Log Access Control====
 Event log information should never be visible to end users. Even web administrators should not be able to see such logs since it breaks separation of duty controls. Ensure that any access control schema that is used to protect access to raw logs and any applications providing capabilities to view or search the logs is not linked with access control schemas for other application user roles. Neither should any log data be viewable by unauthenticated users.
-===Log review===
+====Log review====
 Review of logs can be used for more than extraction of usage statistics of files in the web servers (which is typically what most log-based application will focus on), but also to determine if attacks take place at the web server.

@@ Line 1: / Line 1: @@
 {{Template:OWASP Testing Guide v4}}
-== Brief Summary ==
+== Summary ==
 Proper configuration of the single elements that make up an application architecture is important in order to prevent mistakes that might compromise the security of the whole architecture.
 Configuration review and testing is a critical task in creating and maintaining an architecture. This is because many different systems will be usually provided with generic configurations that might not be suited to the task they will perform on the specific site they're installed on.
@@ Line 11: / Line 10: @@
 While the typical web and application server installation will contain a lot of functionality (like application examples, documentation, test pages) what is not essential should be removed before deployment to avoid post-install exploitation.
+==How to Test ==
 ==Black Box Testing ==

@@ Line 159: / Line 159: @@
 ** [http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf SP 800-92] Guide to Computer Security Log Management, NIST
 ** [https://www.pcisecuritystandards.org/security_standards/documents.php PCI DSS v2.0] Requirement 10 and PA-DSS v2.0 Requirement 4, PCI Security Standards Council
 * Generic:

@@ Line 60: / Line 60: @@
 Some applications might, for example, use GET requests to forward form data which will be viewable in the server logs. This means that server logs might contain sensitive information (such as usernames as passwords, or bank account details). This sensitive information can be misused by an attacker if logs were to be obtained by an attacker, for example, through administrative interfaces or known web server vulnerabilities or misconfiguration (like the well-known ''server-status ''misconfiguration in Apache-based HTTP servers ).
-Also, in some jurisdictions, storing some sensitive information in log files, such as personal data, might oblige the enterprise to apply the data protection laws that they would apply to their back-end databases to log files too. And failure to do so, even unknowingly, might carry penalties under the data protection laws that apply.
+Event logs will often contain data that are useful to an attacker (information leakage) or can be used directly in exploits:
 ===Log location===
@@ Line 89: / Line 112: @@
 Some servers might rotate logs when they reach a given size. If this happens, it must be ensured that an attacker cannot force logs to rotate in order to hide his tracks.
 ===Log review===
@@ Line 102: / Line 131: @@
 ==References==
 * Apache
@@ Line 127: / Line 155: @@
 ** IBM WebSphere V5.0 Security, WebSphere Handbook Series, by Peter Kovari et al., IBM, December 2002.
 ** IBM WebSphere V4.0 Advanced Edition Security, by Peter Kovari et al., IBM, March 2002.
+* General
 [[Category:FIXME|these links no longer work, so I removed them.--KS

← Older revision	Revision as of 13:16, 28 July 2013
(No difference)

@@ Line 116: / Line 116: @@
 * Microsoft IIS
 ** IIS 6.0 Security, by Rohyt Belani, Michael Muckin, - http://www.securityfocus.com/print/infocus/1765
-** IIS 7.0 Security - http://www.iis.net/learn/get-started/whats-new-in-iis-7/iis7-and-above-security-improvements
+** IIS 7.0 Securing Configuration -http://technet.microsoft.com/en-us/library/dd163536.aspx
 ** Securing Your Web Server (Patterns and Practices), Microsoft Corporation, January 2004
 ** IIS Security and Programming Countermeasures, by Jason Coombs

@@ Line 36: / Line 36: @@
 *Do not store sensitive information in these files if it should be for administrator eyes only.
 * Encrypt sensitive information that should be read by the IIS worker processes only and not by other users on the machine.
 ===Logging===