Codereview-Deployment - Revision history

Thomas Herlea: Added navigation to facilitate sequential reading online

2010-09-09T16:08:35Z

Added navigation to facilitate sequential reading online

KirstenS: /* Secure Application Deployment */

2009-02-11T00:54:31Z

‎Secure Application Deployment

KirstenS: /* Secure Application Deployment */

2009-01-27T17:33:33Z

‎Secure Application Deployment

KirstenS: /* A clean environment */

2009-01-16T14:02:49Z

‎A clean environment

KirstenS: /* Protecting JSP pages */

2009-01-16T14:02:31Z

‎Protecting JSP pages

KirstenS: /* A clean environment */

2009-01-13T00:52:54Z

‎A clean environment

KirstenS: /* A clean environment */

2009-01-12T21:37:44Z

‎A clean environment

KirstenS: /* Protecting ASP Pages */

2009-01-12T18:14:22Z

‎Protecting ASP Pages

KirstenS: /* Protecting JSP pages */

2009-01-12T18:13:56Z

‎Protecting JSP pages

KirstenS: /* Secure Application Deployment */

2009-01-12T18:12:46Z

‎Secure Application Deployment

@@ Line 1: / Line 1: @@
-[[OWASP Code Review Guide Table of Contents]]__TOC__
+{{LinkBar
 === Secure Application Deployment ===
@@ Line 109: / Line 114: @@
 To sum up, code review includes looking at the configuration of the application server and not just the code. Knowledge of the server in question is important and information is easily available on the web.
 [[Category:OWASP Code Review Project]]

@@ Line 2: / Line 2: @@
 === Secure Application Deployment ===
-Another important thing to be aware of is when you receive the code: make sure it is identical in deployment layout to what would go to production. Having well-written code is a great start, but deploying that great code in unprotected folders on the application server is not a great idea. Attackers do code reviews also, and what better than to code review the potential target application.
+Another important thing to be aware of is when you receive the code: make sure it is identical in deployment layout to what would go to production. Having well-written code is a great start, but deploying that great code in unprotected folders on the application server is not a great idea. Attackers do code reviews also, and what better than to code review the potential target application?
 Outside of the actual code to review, one must examine if the deployment of a web application is within a secure environment. Having secure code, but the environment upon which the code resides is insecure,  is a lost cause. Accessing resources directly must be controlled within the environment;

@@ Line 6: / Line 6: @@
 Outside of the actual code to review, one must examine if the deployment of a web application is within a secure environment. Having secure code, but the environment upon which the code resides is insecure,  is a lost cause. Accessing resources directly must be controlled within the environment;
-Areas such as configuration files, directories, & resources which need authorisation need to be secured on the host so that direct access to such artifacts is disallowed.
+Areas such as configuration files, directories, and resources which need authorisation need to be secured on the host so that direct access to such artifacts is disallowed.
 For example: try in “'''''Google'''''”:

@@ Line 94: / Line 94: @@
 For classic ASP pages there is no way to configure this kind of protection using a configuration file, rather these kinds of configurations can only be only done though IIS console, thus, out of the scope of this document.
-== A clean environment ==
+== A Clean Environment ==
 When reviewing the environment we must see if the directories contain any artifacts from development. These files may not be referenced in any way and hence the application server gives no protection to them. Files such as .'''bak, .old, .tmp''', etc. should be removed as they may contain source code.

@@ Line 73: / Line 73: @@
 [[Category:OWASP Code Review Project]]
-== Protecting JSP pages ==
+== Protecting JSP Pages ==
 If using the Struts framework we do not want users to access any JSP page directly. Accessing the JSP directly without going through the request processor can enable the attacker to view any server-side code in the JSP. Let's say the initial page is an HTML document, so the HTTP GET from the browser retrieves this page. Any subsequent page must go through the framework. Add the following lines to the  '''web.xml''' file to prevent users from accessing any JSP page directly:

@@ Line 100: / Line 100: @@
 Source code should not go into production directories. The compiled class files are all that is required in most cases. All source code should be removed and only the “executables” should remain.
 No development tools should be present in a production environment. For example a Java application should only need a JRE (Java Runtime Environment) and not a JDK (Java Development Kit) to function.
-Test and debug code should be removed from all source code and configuration files. Even commented-out code should be removed as a precaution. Test code can contain backdoors that circumvent the workflow in the application and at worst contain valid authentication credentials or account details.
+Test and debug code should be removed from all source code and configuration files. Even commented-out code should be removed as a precaution. Test code can contain backdoors that circumvent the workflow in the application, and at worst contain valid authentication credentials or account details.
 Comments on code and Meta tags pertaining to the IDE used or technology used to develop the application should be removed. Some comments can divulge important information regarding bugs in code or pointers to functionality. This is particularly important with server side code such as JSP and ASP files.
 A copyright and confidentiality statement should be at the top of every file. This mitigates any confusion regarding who owns the code. This may seem trivial but it is important to state who owns the code.
 [[Category:OWASP Code Review Project]]

@@ Line 92: / Line 92: @@
 ==Protecting ASP Pages==
-For classic ASP pages there is no way to configure this kind of protection using a configuration file, rather all this kind of configurations can only be only done though IIS console, thus, out of the scope of this document.
+For classic ASP pages there is no way to configure this kind of protection using a configuration file, rather these kinds of configurations can only be only done though IIS console, thus, out of the scope of this document.
 == A clean environment ==

@@ Line 74: / Line 74: @@
 == Protecting JSP pages ==
+If using the Struts framework we do not want users to access any JSP page directly. Accessing the JSP directly without going through the request processor can enable the attacker to view any server-side code in the JSP. Let's say the initial page is an HTML document, so the HTTP GET from the browser retrieves this page. Any subsequent page must go through the framework. Add the following lines to the  '''web.xml''' file to prevent users from accessing any JSP page directly:
   <web-app>
@@ Line 91: / Line 88: @@
   </web-app>
-With this directive in '''web.xml''' a HTTP request for a JSP page directly will fail.
+With this directive in '''web.xml''' an HTTP request for a JSP page directly will fail.
 [[Category:OWASP Code Review Project]]

@@ Line 46: / Line 46: @@
   </Directory>
-And then override this for the directories we require access to:
+And then override this for the directories we require access to.
+Also, in Apache HTTP server, to ensure directories like WEB-INF and META-INF are protected, the following should be added to the httpd.conf, the main configuration file for the Apache web server:
   <Directory /usr/users/*/public_html>