OWASP - User contributions [en]

Exception handling techniques

2013-12-20T15:44:00Z

Manuela Grindei: changed status

==Status==
To be reviewed

==Exceptions Overview==

Exceptions are occurrences that alter the normal program flow. They can have various causes, such as hardware failures, resource exhaustion, programming bugs etc. When an exceptional event occurs, an exception is said to be "thrown." The code responsible for treating the exception is called an "exception handler," and it "catches" the thrown exception. Exception handling refers to passing the execution of a program to an appropriate exception handler when an exception occurs. For example, if a method that opens a file is called, and the file cannot be opened, the execution of that method will stop, and the code from the appropriate exception handler will be run.

In Java, exception-handling code is cleanly separated from the exception-generating code. The try block (also called "guarded region") is the code in which exceptions may occur, and it must be immediately followed by either a finally block or at least one catch block. In Java 7, there is a new syntactic construction, called "try-with-resources", which is the only exception to this rule, as it is not forced to be followed by a finally or catch block.

A finally block contains code that is always executed at some point after the try block, whether an exception was thrown or not. Even if there is a return statement in the try block, the finally block executes right after the return statement is encountered, and before the return executes. If the try block executes without exception, the finally block is executed immediately after the try block completes. If an exception was thrown, the finally block executes immediately after the
corresponding catch block completes. However, if the JVM exits while the try or catch code is being executed, then the finally block may not execute. Likewise, if the thread executing the try
or catch code is interrupted or killed, the finally block may not execute even though the application keeps running.

==Swallowing Exceptions==

Swallowing exceptions means to continue processing as if nothing had gone wrong even though an exception has been thrown. You catch the exception, but do nothing meaningful with it. The classical example is an empty catch block:

catch(Exception e) {
}

Swallowing exceptions is considered bad practice, because the ignored exception may lead the application to an unexpected failure, at a point in the code that bears no apparent relation to the source of the problem. Finding the cause of the failure in such cases can be very challenging and time-consuming. Merely letting an exception propagate outward can at least cause the program to fail swiftly, preserving information to aid in debugging the failure.

In addition, in case an exception is caught, it is strongly recommended to log information about it, as it is very useful for debugging purposes.

==Resource cleanup and finally block==

One of the situations when exceptions may occur is when we work with resources, such as files, databases, network sockets etc.

Opening/closing, connecting/disconnecting, read/write statements are examples of operations that may throw exceptions in particular cases. If our code needs to work with resources, it is important to release them as soon as we are finished using them.

The following example is about writing a text in a file. The constructor, the write, the flush of the file operation can throw IOException, hence they are being placed inside the try block. We are aware that we must close the file after writing in it. A naive (and wrong) approach would be the following:

File file = new File("file.txt");
Writer writer = null;
try {
writer = new PrintWriter(file);
writer.write("Hello world!");
writer.flush();
writer.close();
}
catch(FileNotFoundException e) {
System.err.println("Caught FileNotFoundException: " + e.getMessage());
}
catch (IOException e) {
System.err.println("Caught IOException: " + e.getMessage());
}

As you can see in the example, we close a resource inside the try block. However this is not a good practice, because if an exception is thrown before our close statement is reached, then it will not be executed and resources might thus leak. We could add the close statement in the catch block, which leads to code duplication. If we have several catch blocks, this means we have to add the close statement there. Whenever we need to add a new catch block, we must also remember to put the close statement there. This way of handling exceptions is error-prone and unnecessarily complicated.

So where should we place the close statement? We would need a block that always gets executed, no matter if we have exceptions or not, like... finally.

Indeed, the ideal place to release resources is the finally block. As we have seen before, finally always gets executed. This means the closing of resources will get executed even if exceptions occur, and in addition we do not have code duplication, which is mainly what we want. This approach is the best way to correctly handle the resources our code used.

To fix the above example, a finally block was added and the file was closed there, as shown in the code below.

File file = new File("file.txt");
Writer writer = null;
try {
writer = new PrintWriter(file);
writer.write("Hello world!");
writer.flush();
}
catch(FileNotFoundException e) {
System.err.println("Caught FileNotFoundException: " + e.getMessage());
}
catch (IOException e) {
System.err.println("Caught IOException: " + e.getMessage());
} finally {
if (writer != null)
try {
writer.close();
} catch (IOException e) {
System.err.println("Caught IOException: " + e.getMessage());
}
}

==Try-with-resources==

In Java 7, resource cleanup was automated by means of the try-with-resources block. In practice, this new syntax allows you to declare resources that are part of the try block. You define the resources ahead of time and the runtime automatically closes those resources (if they are not already closed) after the execution of the try block.

A resource can be any object that implements the interface java.lang.AutoCloseable.

Although the try-with-resources block can have a finally or catch block, it is not mandatory.

In our example, since Writer implements AutoCloseable, we can place it in a try-with-resources block as follows:

File file = new File("file.txt");
try(Writer writer = new PrintWriter(file)) {
writer.write("Hello world!");
writer.flush();
}

The code looks far more readable this way, and the developer is no longer supposed to close the resources, it is automatically done as long as the classes implement the AutoCloseable interface. Also note that the function that contains this code must throw IOException in order to compile, since there are no catch blocks.

[[Category:OWASP Java Project]]
[[Category:Java]]
[[Category:Error Handling]]

OWASP Java Table of Contents

2013-12-20T15:43:31Z

Manuela Grindei: changed status

Key:
* xx%: Progress status of the paragraph
* Review: The paragraph needs a review
* TD: Paragraph to be assigned

==[[J2EE Security for Architects]]==
Discuss the security implications of common J2EE architectures. This could be discussed in terms of: Authentication, Authorisation, Data Validation, Cross Site Scripting protection. Other architecture concerns such as scalability, performance and maintainability can also be mentioned, but the focus on security should not be lost.

Any other security concerns that should be addressed during the design phase should also be mentioned here.
===Design considerations===
* Architectural considerations (0%, TD)
** EJB Middle tier (0%, TD)
** Web Services Middle tier (0%, TD)
** Spring Middle tier (0%, TD)

==[[J2EE Security for Developers]]==
=== Noteworthy Frameworks ===
Discuss important and relevant Java security frameworks that would be useful to architects. The information should be at a suitably high level. For example, by discussing the advantages and features as well as the associated costs (direct and indirect) of using the frameworks.

(0%, Seeking Volunteers)
* Cocoon
* [[Java Server Faces]] (Sam Reghenzi - 90%, Finalising content)
* JSecurity
* SiteMesh
* Spring (0%, Adrian San Juan, TD)
* [[Struts]] (0% Jon Forck)
* Tapestry
* Tiles
* Turbine
* Webwork
* [[Wicket]]

===Java Security Basics===
Provide an introduction into the basic security services provided by the Java language and environment. Remember to keep this relevant for web developers for the initial release - there may be a potential to expand this to thick clients in subsequent releases.
* Class Loading (0%, Philippe Clairet)
* Bytecode verifier (0%, Philippe Clairet)
* The Security Manager and security.policy file (0%, John Wilander, Philippe Clairet)

===Input Validation Overview ===
Input validation is perhaps the most important category of application security. Any data entering a software system must be verified to contain safe data that is not mounting a SQL Injection, XSS, CSRF or other form of attack. This is done primarily through the use of regular expressions. It's crucial not to hard-code input validation routines. Regular expressions should contained within a configuration file that can easily updated by an InfoSec professional and not require a programmers intervention or deployment of new application code. Application security needs change over time as new attack vectors are discovered. Application administers need to be able to react to these changes as quickly as possible.

===Input Validation ===
* Dangerous calls (BufferedReader.readLine(), ServletRequest.getParameter(), etc...) (0%, TD)
* [[How to add validation logic to HttpServletRequest]] (100%, Jeff Williams, Complete)
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Complete)

==== [[Preventing SQL Injection in Java]] ====
* Overview
* Prevention (60%, Stephen de Vries, Review)
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis (60%, Rohyt Belani, Review)
** Spring JDBC
** EJB 3.0
** JDO

==== [[Preventing LDAP Injection in Java]] ====
* Overview (100%, Stephen de Vries, Complete)
* Prevention (100%, Stephen de Vries, Complete)

==== XPATH Injection ====
* [[XPATH Injection|Article n°1]] (70%, Weilin Zhong)
* [[XPATH Injection Java|Article n°2]] (100%, Dominique Righetto, Complete)

==== [[Miscellaneous Injection Attacks]] ====
* HTTP Response splitting (0%, TD)
* [[Code injection in Java]] (75%, Neil Bergman, Review)
* [[Command injection in Java]] - Runtime.getRuntime().exec() (100%, Neil Bergman, Review)
* Regular Expression (regex) Injections (20%)

''' Status '''
In progress

=== Authentication===
* [[Storing credentials]] - (20%, Adrian San Juan, Review)
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, Review)
* [[SSL Best Practices]] - (20%, Philippe Curmin, Review)
* [[Captchas in Java]] - (100%, Dave Ferguson, Review)
* Container-managed authentication with Realms
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Completed)
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, Review)
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, Review)
* [[Password length & complexity]] - (100%, Adrian San Juan, Review)

===Session Management ===
The generic problems and solutions for session management are covered in the Guide. This section should focus on Java specific examples.
* [[Logout]] (100%, Dominique Righetto, Complete)
* [[Session Timeout]] (100%, Dominique Righetto, Complete)
* Absolute Timeout (0%, TD)
* [[Session Fixation in Java]] (100%, Rohyt Belani, Review)
* Terminating sessions (0%, TD)
** Terminating sessions when the browser window is closed

===Authorization===
* [[Declarative v/s Programmatic]] (10%, TD)
* EJB Authorization (0%, TD)
* Acegi (0%, TD)
* JACC (0%, TD)
* Check horizontal privilege (0%, TD)

=== Encryption===
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions JCE] (100%, Joe Prasanna Kumar - To be reviewed)
* Storing db secrets (0%, TD)
* Encrypting JDBC connections (0%, TD)
* [http://www.owasp.org/index.php/Using_the_Java_Secure_Socket_Extensions JSSE] (100%, Joe Prasanna Kumar - To be reviewed)
* [http://www.owasp.org/index.php/Digital_Signature_Implementation_in_Java Digital Signatures in Java] (100%, Joe Prasanna Kumar - To be reviewed)

=== Error Handling & Logging===
* Logging - why log? what to log? log4j, etc. (0%, TD)
* [[Exception handling techniques]] (100%, Manuela Grindei, To be reviewed)
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks (50%, TD)
** [[Servlet spec - web.xml]] (100%, Dominique Righetto, Complete)
** [[Securing tomcat]] (100%, Darren Edmonds, Completed)
** [[JSP errorPage]] (100%, Dominique Righetto, Complete)
* Web application forensics (0%, TD)

=== Web Services Security ===
* SAML (0%, TD)
* (X)WS-Security (0%, TD)
* SunJWSDP (0%, TD)
* WSS4J (0%, Eelco Klaver)
* XML Signature (JSR 105) (0%, TD)
* XML Encryption (JSR 106) (0%, TD)

=== Cross-Origin Resource Sharing ===
* [[CORS OriginHeaderScrutiny|Origin HTTP header check]] (100%, Dominique Righetto, Complete)
* [[CORS RequestPreflighScrutiny|Request preflight process check]] (100%, Dominique Righetto, Complete)

=== Content Security Policy ===
* [[Content Security Policy|Set up in a application]] (100%, Dominique Righetto, Complete)

=== Code Analysis Tools ===
The introduction should cover the advantages and short comings of code analysis tools. An overview of the current state of the art and the available tools would go well here. As a start, only open source tools are listed, but if vendors of commercial tools adhere to the [[Tutorial]] guidelines, these submissions will be gladly received.
* Introduction (0%, TD)
* [[:Category:OWASP LAPSE Project]] (100%, Review)
* FindBugs (0%, TD)
** Creating custom rules
* PMD (0%, TD)
** Creating custom rules
* JLint (0%, TD)
* Jmetrics (0%, TD)

=== Choosing Security Libraries ===
* [[Summary of Java Security Libraries]]

== J2EE Security For Deployers ==
Practical step-by-step guides to securing various J2EE servers. Examples of secure configurations can also be provided for download. If configurations are provided, they should be properly commented so that the rationale for configuration settings is clearly explained. Users of the configurations should be provided with enough information to make their own risk decisions.
=== Securing Popular J2EE Servers ===
* [[Securing tomcat|Securing Tomcat]] - (100%, Darren Edmonds, Completed)
* Securing JBoss (0%, TD)
* Securing WebLogic (0%, TD)
* Securing WebSphere (0%, TD)
* Others...

=== Defining a Java Security Policy ===
Practical information on creating a Java security policies for J2EE servers.
* PolicyTool - JChains already provides this functionality, one policy tool is enough.
* jChains (www.jchains.org) - (0%, TD)

=== Protecting Binaries ===
* Bytecode manipulation tools and techniques (0%, TD)
* [[Bytecode obfuscation]] (100%, Pierre Parrend, Released)
* Convert bytecode to native machine code (0%, TD)
* [[Protecting code archives with digital signatures]] (100%, Pierre Parrend, Released)
* [[Signing jar files with jarsigner]] (100%, Pierre Parrend, Released)

==J2EE Security for Security Analysts and Testers==
* Using Eclipse to verify Java applications (0%, TD)
* Using [[:Category:OWASP WebScarab Project|WebScarab]] to find vulnerabilities in J2EE applications - (0%, TD)
* [[Decompiling Java bytecode]] (100%, Dominique Righetto, Complete)

== [[Java Security Resources]] (ongoing)==

[[Category:OWASP Java Project]]

Exception handling techniques

2013-12-20T15:42:15Z

Manuela Grindei: fixed some typos

==Status==
Draft

==Exceptions Overview==

Exceptions are occurrences that alter the normal program flow. They can have various causes, such as hardware failures, resource exhaustion, programming bugs etc. When an exceptional event occurs, an exception is said to be "thrown." The code responsible for treating the exception is called an "exception handler," and it "catches" the thrown exception. Exception handling refers to passing the execution of a program to an appropriate exception handler when an exception occurs. For example, if a method that opens a file is called, and the file cannot be opened, the execution of that method will stop, and the code from the appropriate exception handler will be run.

In Java, exception-handling code is cleanly separated from the exception-generating code. The try block (also called "guarded region") is the code in which exceptions may occur, and it must be immediately followed by either a finally block or at least one catch block. In Java 7, there is a new syntactic construction, called "try-with-resources", which is the only exception to this rule, as it is not forced to be followed by a finally or catch block.

A finally block contains code that is always executed at some point after the try block, whether an exception was thrown or not. Even if there is a return statement in the try block, the finally block executes right after the return statement is encountered, and before the return executes. If the try block executes without exception, the finally block is executed immediately after the try block completes. If an exception was thrown, the finally block executes immediately after the
corresponding catch block completes. However, if the JVM exits while the try or catch code is being executed, then the finally block may not execute. Likewise, if the thread executing the try
or catch code is interrupted or killed, the finally block may not execute even though the application keeps running.

==Swallowing Exceptions==

Swallowing exceptions means to continue processing as if nothing had gone wrong even though an exception has been thrown. You catch the exception, but do nothing meaningful with it. The classical example is an empty catch block:

catch(Exception e) {
}

Swallowing exceptions is considered bad practice, because the ignored exception may lead the application to an unexpected failure, at a point in the code that bears no apparent relation to the source of the problem. Finding the cause of the failure in such cases can be very challenging and time-consuming. Merely letting an exception propagate outward can at least cause the program to fail swiftly, preserving information to aid in debugging the failure.

In addition, in case an exception is caught, it is strongly recommended to log information about it, as it is very useful for debugging purposes.

==Resource cleanup and finally block==

One of the situations when exceptions may occur is when we work with resources, such as files, databases, network sockets etc.

Opening/closing, connecting/disconnecting, read/write statements are examples of operations that may throw exceptions in particular cases. If our code needs to work with resources, it is important to release them as soon as we are finished using them.

The following example is about writing a text in a file. The constructor, the write, the flush of the file operation can throw IOException, hence they are being placed inside the try block. We are aware that we must close the file after writing in it. A naive (and wrong) approach would be the following:

File file = new File("file.txt");
Writer writer = null;
try {
writer = new PrintWriter(file);
writer.write("Hello world!");
writer.flush();
writer.close();
}
catch(FileNotFoundException e) {
System.err.println("Caught FileNotFoundException: " + e.getMessage());
}
catch (IOException e) {
System.err.println("Caught IOException: " + e.getMessage());
}

As you can see in the example, we close a resource inside the try block. However this is not a good practice, because if an exception is thrown before our close statement is reached, then it will not be executed and resources might thus leak. We could add the close statement in the catch block, which leads to code duplication. If we have several catch blocks, this means we have to add the close statement there. Whenever we need to add a new catch block, we must also remember to put the close statement there. This way of handling exceptions is error-prone and unnecessarily complicated.

So where should we place the close statement? We would need a block that always gets executed, no matter if we have exceptions or not, like... finally.

Indeed, the ideal place to release resources is the finally block. As we have seen before, finally always gets executed. This means the closing of resources will get executed even if exceptions occur, and in addition we do not have code duplication, which is mainly what we want. This approach is the best way to correctly handle the resources our code used.

To fix the above example, a finally block was added and the file was closed there, as shown in the code below.

File file = new File("file.txt");
Writer writer = null;
try {
writer = new PrintWriter(file);
writer.write("Hello world!");
writer.flush();
}
catch(FileNotFoundException e) {
System.err.println("Caught FileNotFoundException: " + e.getMessage());
}
catch (IOException e) {
System.err.println("Caught IOException: " + e.getMessage());
} finally {
if (writer != null)
try {
writer.close();
} catch (IOException e) {
System.err.println("Caught IOException: " + e.getMessage());
}
}

==Try-with-resources==

In Java 7, resource cleanup was automated by means of the try-with-resources block. In practice, this new syntax allows you to declare resources that are part of the try block. You define the resources ahead of time and the runtime automatically closes those resources (if they are not already closed) after the execution of the try block.

A resource can be any object that implements the interface java.lang.AutoCloseable.

Although the try-with-resources block can have a finally or catch block, it is not mandatory.

In our example, since Writer implements AutoCloseable, we can place it in a try-with-resources block as follows:

File file = new File("file.txt");
try(Writer writer = new PrintWriter(file)) {
writer.write("Hello world!");
writer.flush();
}

The code looks far more readable this way, and the developer is no longer supposed to close the resources, it is automatically done as long as the classes implement the AutoCloseable interface. Also note that the function that contains this code must throw IOException in order to compile, since there are no catch blocks.

[[Category:OWASP Java Project]]
[[Category:Java]]
[[Category:Error Handling]]

Exception handling techniques

2013-12-08T18:04:59Z

Manuela Grindei: added category

==Status==
Draft

==Exceptions Overview==

Exceptions are occurrences that alter the normal program flow. They can have various causes, such as hardware failures, resource exhaustion, programming bugs etc. When an exceptional event occurs, an exception is said to be "thrown." The code responsible for treating the exception is called an "exception handler," and it "catches" the thrown exception. Exception handling refers to passing the execution of a program to an appropriate exception handler when an exception occurs. For example, if a method that opens a file is called, and the file cannot be opened, the execution of that method will stop, and the code from the appropriate exception handler will be run.

In Java, exception-handling code is cleanly separated from the exception-generating code. The try block (also called "guarded region") is the code in which exceptions may occur, and it must be immediately followed by either a finally block or at least one catch block. In Java 7, there is a new syntactic construction, called "try-with-resources", which is the only exception to this rule, as it is not forced to be followed by a finally or catch block.

A finally block contains code that is always executed at some point after the try block, whether an exception was thrown or not. Even if there is a return statement in the try block, the finally block executes right after the return statement is encountered, and before the return executes. If the try block executes without exception, the finally block is executed immediately after the try block completes. If an exception was thrown, the finally block executes immediately after the
corresponding catch block completes. However, if the JVM exits while the try or catch code is being executed, then the finally block may not execute. Likewise, if the thread executing the try
or catch code is interrupted or killed, the finally block may not execute even though the application keeps running.

==Swallowing Exceptions==

Swallowing exceptions means to continue processing as if nothing had gone wrong even though an exception has been thrown. You catch the exception, but do nothing meaningful with it. The classical example is an empty catch block:

catch(Exception e) {
}

Swallowing exceptions is considered bad practice, because the ignored exception may lead the pplication to an unexpected failure, at a point in the code that bears no apparent relation to the source of the problem. Finding the cause of the failure in such cases can be very challenging and time-consuming. Merely letting an exception propagate outward can at least cause the program to fail swiftly, preserving information to aid in debugging the failure.

In addition, in case an exception is caught, it is strongly recommended to log information about it, as it is very useful for debugging purposes.

==Resource cleanup and finally block==

One of the situations when exceptions may occur is when we work with resources, such as files, databases, network sockets etc.

Opening/closing, connecting/disconnecting, read/write statements are examples of operations that may throw exceptions in particular cases. If our code needs to work with resources, it is important to release them as soon as we are finished using them.

The following example is about writing a text in a file. The constructor, the write, the flush of the file operation can throw IOException, hence they are being placed inside the try block. We are aware that we must close the file after writing in it. A naive (and wrong) approach would be the following:

File file = new File("file.txt");
Writer writer = null;
try {
writer = new PrintWriter(file);
writer.write("Hello world!");
writer.flush();
writer.close();
}
catch(FileNotFoundException e) {
System.err.println("Caught FileNotFoundException: " + e.getMessage());
}
catch (IOException e) {
System.err.println("Caught IOException: " + e.getMessage());
}

As you can see in the example, we close a resource inside the try block. However this is not a good practice, because if an exception is thrown before our close statement is reached, then it will not be executed and resources might thus leak. We could add the close statement in the catch block, which leads to code duplication. If we have several catch blocks, this means we have to add the close statement there. Whenever we need to add a new catch block, we must also remember to put the close statement there. This way of handling exceptions is error-prone and unnecessarily complicated.

So where should to place the close statement? We would need a block that always gets executed, no matter if we have exceptions or not, like... finally.

Indeed, the ideal place to release resources is the finally block. As we have seen before, finally always gets executed. This means the closing of resources will get executed even if exceptions occur, and in addition we do not have code duplication, which is mainly what we want. This approach is the best way to correctly handle the resources our code used.

To fix the above example, a finally block was added and the file was closed there, as shown in the code below.

File file = new File("file.txt");
Writer writer = null;
try {
writer = new PrintWriter(file);
writer.write("Hello world!");
writer.flush();
}
catch(FileNotFoundException e) {
System.err.println("Caught FileNotFoundException: " + e.getMessage());
}
catch (IOException e) {
System.err.println("Caught IOException: " + e.getMessage());
} finally {
if (writer != null)
try {
writer.close();
} catch (IOException e) {
System.err.println("Caught IOException: " + e.getMessage());
}
}

==Try-with-resources==

In Java 7, resource cleanup was automated by means of the try-with-resources block. In practice, this new syntax allows you to declare resources that are part of the try block. You define the resources ahead of time and the runtime automatically closes those resources (if they are not already closed) after the execution of the try block.

A resource can be any object that implements the interface java.lang.AutoCloseable.

Although the try-with-resources block can have a finally or catch block, it is not mandatory.

In our example, since Writer implements AutoCloseable, we can place it in a try-with-resources block as follows:

File file = new File("file.txt");
try(Writer writer = new PrintWriter(file)) {
writer.write("Hello world!");
writer.flush();
}

The code looks far more readable this way, and the developer is no longer supposed to close the resources, it is automatically done as long as the classes implement the AutoCloseable interface. Also note that the function that contains this code must throw IOException in order to compile, since there are no catch blocks.

[[Category:OWASP Java Project]]
[[Category:Java]]
[[Category:Error Handling]]

OWASP Java Table of Contents

2013-12-08T17:59:37Z

Manuela Grindei: updated progress

Key:
* xx%: Progress status of the paragraph
* Review: The paragraph needs a review
* TD: Paragraph to be assigned

==[[J2EE Security for Architects]]==
Discuss the security implications of common J2EE architectures. This could be discussed in terms of: Authentication, Authorisation, Data Validation, Cross Site Scripting protection. Other architecture concerns such as scalability, performance and maintainability can also be mentioned, but the focus on security should not be lost.

Any other security concerns that should be addressed during the design phase should also be mentioned here.
===Design considerations===
* Architectural considerations (0%, TD)
** EJB Middle tier (0%, TD)
** Web Services Middle tier (0%, TD)
** Spring Middle tier (0%, TD)

==[[J2EE Security for Developers]]==
=== Noteworthy Frameworks ===
Discuss important and relevant Java security frameworks that would be useful to architects. The information should be at a suitably high level. For example, by discussing the advantages and features as well as the associated costs (direct and indirect) of using the frameworks.

(0%, Seeking Volunteers)
* Cocoon
* [[Java Server Faces]] (Sam Reghenzi - 90%, Finalising content)
* JSecurity
* SiteMesh
* Spring (0%, Adrian San Juan, TD)
* [[Struts]] (0% Jon Forck)
* Tapestry
* Tiles
* Turbine
* Webwork
* [[Wicket]]

===Java Security Basics===
Provide an introduction into the basic security services provided by the Java language and environment. Remember to keep this relevant for web developers for the initial release - there may be a potential to expand this to thick clients in subsequent releases.
* Class Loading (0%, Philippe Clairet)
* Bytecode verifier (0%, Philippe Clairet)
* The Security Manager and security.policy file (0%, John Wilander, Philippe Clairet)

===Input Validation Overview ===
Input validation is perhaps the most important category of application security. Any data entering a software system must be verified to contain safe data that is not mounting a SQL Injection, XSS, CSRF or other form of attack. This is done primarily through the use of regular expressions. It's crucial not to hard-code input validation routines. Regular expressions should contained within a configuration file that can easily updated by an InfoSec professional and not require a programmers intervention or deployment of new application code. Application security needs change over time as new attack vectors are discovered. Application administers need to be able to react to these changes as quickly as possible.

===Input Validation ===
* Dangerous calls (BufferedReader.readLine(), ServletRequest.getParameter(), etc...) (0%, TD)
* [[How to add validation logic to HttpServletRequest]] (100%, Jeff Williams, Complete)
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Complete)

==== [[Preventing SQL Injection in Java]] ====
* Overview
* Prevention (60%, Stephen de Vries, Review)
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis (60%, Rohyt Belani, Review)
** Spring JDBC
** EJB 3.0
** JDO

==== [[Preventing LDAP Injection in Java]] ====
* Overview (100%, Stephen de Vries, Complete)
* Prevention (100%, Stephen de Vries, Complete)

==== XPATH Injection ====
* [[XPATH Injection|Article n°1]] (70%, Weilin Zhong)
* [[XPATH Injection Java|Article n°2]] (100%, Dominique Righetto, Complete)

==== [[Miscellaneous Injection Attacks]] ====
* HTTP Response splitting (0%, TD)
* [[Code injection in Java]] (75%, Neil Bergman, Review)
* [[Command injection in Java]] - Runtime.getRuntime().exec() (100%, Neil Bergman, Review)
* Regular Expression (regex) Injections (20%)

''' Status '''
In progress

=== Authentication===
* [[Storing credentials]] - (20%, Adrian San Juan, Review)
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, Review)
* [[SSL Best Practices]] - (20%, Philippe Curmin, Review)
* [[Captchas in Java]] - (100%, Dave Ferguson, Review)
* Container-managed authentication with Realms
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Completed)
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, Review)
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, Review)
* [[Password length & complexity]] - (100%, Adrian San Juan, Review)

===Session Management ===
The generic problems and solutions for session management are covered in the Guide. This section should focus on Java specific examples.
* [[Logout]] (100%, Dominique Righetto, Complete)
* [[Session Timeout]] (100%, Dominique Righetto, Complete)
* Absolute Timeout (0%, TD)
* [[Session Fixation in Java]] (100%, Rohyt Belani, Review)
* Terminating sessions (0%, TD)
** Terminating sessions when the browser window is closed

===Authorization===
* [[Declarative v/s Programmatic]] (10%, TD)
* EJB Authorization (0%, TD)
* Acegi (0%, TD)
* JACC (0%, TD)
* Check horizontal privilege (0%, TD)

=== Encryption===
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions JCE] (100%, Joe Prasanna Kumar - To be reviewed)
* Storing db secrets (0%, TD)
* Encrypting JDBC connections (0%, TD)
* [http://www.owasp.org/index.php/Using_the_Java_Secure_Socket_Extensions JSSE] (100%, Joe Prasanna Kumar - To be reviewed)
* [http://www.owasp.org/index.php/Digital_Signature_Implementation_in_Java Digital Signatures in Java] (100%, Joe Prasanna Kumar - To be reviewed)

=== Error Handling & Logging===
* Logging - why log? what to log? log4j, etc. (0%, TD)
* [[Exception handling techniques]] (90%, Manuela Grindei, In progress)
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks (50%, TD)
** [[Servlet spec - web.xml]] (100%, Dominique Righetto, Complete)
** [[Securing tomcat]] (100%, Darren Edmonds, Completed)
** [[JSP errorPage]] (100%, Dominique Righetto, Complete)
* Web application forensics (0%, TD)

=== Web Services Security ===
* SAML (0%, TD)
* (X)WS-Security (0%, TD)
* SunJWSDP (0%, TD)
* WSS4J (0%, Eelco Klaver)
* XML Signature (JSR 105) (0%, TD)
* XML Encryption (JSR 106) (0%, TD)

=== Cross-Origin Resource Sharing ===
* [[CORS OriginHeaderScrutiny|Origin HTTP header check]] (100%, Dominique Righetto, Complete)
* [[CORS RequestPreflighScrutiny|Request preflight process check]] (100%, Dominique Righetto, Complete)

=== Content Security Policy ===
* [[Content Security Policy|Set up in a application]] (100%, Dominique Righetto, Complete)

=== Code Analysis Tools ===
The introduction should cover the advantages and short comings of code analysis tools. An overview of the current state of the art and the available tools would go well here. As a start, only open source tools are listed, but if vendors of commercial tools adhere to the [[Tutorial]] guidelines, these submissions will be gladly received.
* Introduction (0%, TD)
* [[:Category:OWASP LAPSE Project]] (100%, Review)
* FindBugs (0%, TD)
** Creating custom rules
* PMD (0%, TD)
** Creating custom rules
* JLint (0%, TD)
* Jmetrics (0%, TD)

=== Choosing Security Libraries ===
* [[Summary of Java Security Libraries]]

== J2EE Security For Deployers ==
Practical step-by-step guides to securing various J2EE servers. Examples of secure configurations can also be provided for download. If configurations are provided, they should be properly commented so that the rationale for configuration settings is clearly explained. Users of the configurations should be provided with enough information to make their own risk decisions.
=== Securing Popular J2EE Servers ===
* [[Securing tomcat|Securing Tomcat]] - (100%, Darren Edmonds, Completed)
* Securing JBoss (0%, TD)
* Securing WebLogic (0%, TD)
* Securing WebSphere (0%, TD)
* Others...

=== Defining a Java Security Policy ===
Practical information on creating a Java security policies for J2EE servers.
* PolicyTool - JChains already provides this functionality, one policy tool is enough.
* jChains (www.jchains.org) - (0%, TD)

=== Protecting Binaries ===
* Bytecode manipulation tools and techniques (0%, TD)
* [[Bytecode obfuscation]] (100%, Pierre Parrend, Released)
* Convert bytecode to native machine code (0%, TD)
* [[Protecting code archives with digital signatures]] (100%, Pierre Parrend, Released)
* [[Signing jar files with jarsigner]] (100%, Pierre Parrend, Released)

==J2EE Security for Security Analysts and Testers==
* Using Eclipse to verify Java applications (0%, TD)
* Using [[:Category:OWASP WebScarab Project|WebScarab]] to find vulnerabilities in J2EE applications - (0%, TD)
* [[Decompiling Java bytecode]] (100%, Dominique Righetto, Complete)

== [[Java Security Resources]] (ongoing)==

[[Category:OWASP Java Project]]

Exception handling techniques

2013-12-08T17:58:25Z

Manuela Grindei: first version of Exceptions Tutorial

==Status==
Draft

==Exceptions Overview==

Exceptions are occurrences that alter the normal program flow. They can have various causes, such as hardware failures, resource exhaustion, programming bugs etc. When an exceptional event occurs, an exception is said to be "thrown." The code responsible for treating the exception is called an "exception handler," and it "catches" the thrown exception. Exception handling refers to passing the execution of a program to an appropriate exception handler when an exception occurs. For example, if a method that opens a file is called, and the file cannot be opened, the execution of that method will stop, and the code from the appropriate exception handler will be run.

In Java, exception-handling code is cleanly separated from the exception-generating code. The try block (also called "guarded region") is the code in which exceptions may occur, and it must be immediately followed by either a finally block or at least one catch block. In Java 7, there is a new syntactic construction, called "try-with-resources", which is the only exception to this rule, as it is not forced to be followed by a finally or catch block.

A finally block contains code that is always executed at some point after the try block, whether an exception was thrown or not. Even if there is a return statement in the try block, the finally block executes right after the return statement is encountered, and before the return executes. If the try block executes without exception, the finally block is executed immediately after the try block completes. If an exception was thrown, the finally block executes immediately after the
corresponding catch block completes. However, if the JVM exits while the try or catch code is being executed, then the finally block may not execute. Likewise, if the thread executing the try
or catch code is interrupted or killed, the finally block may not execute even though the application keeps running.

==Swallowing Exceptions==

Swallowing exceptions means to continue processing as if nothing had gone wrong even though an exception has been thrown. You catch the exception, but do nothing meaningful with it. The classical example is an empty catch block:

catch(Exception e) {
}

Swallowing exceptions is considered bad practice, because the ignored exception may lead the pplication to an unexpected failure, at a point in the code that bears no apparent relation to the source of the problem. Finding the cause of the failure in such cases can be very challenging and time-consuming. Merely letting an exception propagate outward can at least cause the program to fail swiftly, preserving information to aid in debugging the failure.

In addition, in case an exception is caught, it is strongly recommended to log information about it, as it is very useful for debugging purposes.

==Resource cleanup and finally block==

One of the situations when exceptions may occur is when we work with resources, such as files, databases, network sockets etc.

Opening/closing, connecting/disconnecting, read/write statements are examples of operations that may throw exceptions in particular cases. If our code needs to work with resources, it is important to release them as soon as we are finished using them.

The following example is about writing a text in a file. The constructor, the write, the flush of the file operation can throw IOException, hence they are being placed inside the try block. We are aware that we must close the file after writing in it. A naive (and wrong) approach would be the following:

File file = new File("file.txt");
Writer writer = null;
try {
writer = new PrintWriter(file);
writer.write("Hello world!");
writer.flush();
writer.close();
}
catch(FileNotFoundException e) {
System.err.println("Caught FileNotFoundException: " + e.getMessage());
}
catch (IOException e) {
System.err.println("Caught IOException: " + e.getMessage());
}

As you can see in the example, we close a resource inside the try block. However this is not a good practice, because if an exception is thrown before our close statement is reached, then it will not be executed and resources might thus leak. We could add the close statement in the catch block, which leads to code duplication. If we have several catch blocks, this means we have to add the close statement there. Whenever we need to add a new catch block, we must also remember to put the close statement there. This way of handling exceptions is error-prone and unnecessarily complicated.

So where should to place the close statement? We would need a block that always gets executed, no matter if we have exceptions or not, like... finally.

Indeed, the ideal place to release resources is the finally block. As we have seen before, finally always gets executed. This means the closing of resources will get executed even if exceptions occur, and in addition we do not have code duplication, which is mainly what we want. This approach is the best way to correctly handle the resources our code used.

To fix the above example, a finally block was added and the file was closed there, as shown in the code below.

File file = new File("file.txt");
Writer writer = null;
try {
writer = new PrintWriter(file);
writer.write("Hello world!");
writer.flush();
}
catch(FileNotFoundException e) {
System.err.println("Caught FileNotFoundException: " + e.getMessage());
}
catch (IOException e) {
System.err.println("Caught IOException: " + e.getMessage());
} finally {
if (writer != null)
try {
writer.close();
} catch (IOException e) {
System.err.println("Caught IOException: " + e.getMessage());
}
}

==Try-with-resources==

In Java 7, resource cleanup was automated by means of the try-with-resources block. In practice, this new syntax allows you to declare resources that are part of the try block. You define the resources ahead of time and the runtime automatically closes those resources (if they are not already closed) after the execution of the try block.

A resource can be any object that implements the interface java.lang.AutoCloseable.

Although the try-with-resources block can have a finally or catch block, it is not mandatory.

In our example, since Writer implements AutoCloseable, we can place it in a try-with-resources block as follows:

File file = new File("file.txt");
try(Writer writer = new PrintWriter(file)) {
writer.write("Hello world!");
writer.flush();
}

The code looks far more readable this way, and the developer is no longer supposed to close the resources, it is automatically done as long as the classes implement the AutoCloseable interface. Also note that the function that contains this code must throw IOException in order to compile, since there are no catch blocks.

[[Category:OWASP Java Project]]
[[Category:Java]]

OWASP Java Table of Contents

2013-12-08T17:41:51Z

Manuela Grindei: added link

Key:
* xx%: Progress status of the paragraph
* Review: The paragraph needs a review
* TD: Paragraph to be assigned

==[[J2EE Security for Architects]]==
Discuss the security implications of common J2EE architectures. This could be discussed in terms of: Authentication, Authorisation, Data Validation, Cross Site Scripting protection. Other architecture concerns such as scalability, performance and maintainability can also be mentioned, but the focus on security should not be lost.

Any other security concerns that should be addressed during the design phase should also be mentioned here.
===Design considerations===
* Architectural considerations (0%, TD)
** EJB Middle tier (0%, TD)
** Web Services Middle tier (0%, TD)
** Spring Middle tier (0%, TD)

==[[J2EE Security for Developers]]==
=== Noteworthy Frameworks ===
Discuss important and relevant Java security frameworks that would be useful to architects. The information should be at a suitably high level. For example, by discussing the advantages and features as well as the associated costs (direct and indirect) of using the frameworks.

(0%, Seeking Volunteers)
* Cocoon
* [[Java Server Faces]] (Sam Reghenzi - 90%, Finalising content)
* JSecurity
* SiteMesh
* Spring (0%, Adrian San Juan, TD)
* [[Struts]] (0% Jon Forck)
* Tapestry
* Tiles
* Turbine
* Webwork
* [[Wicket]]

===Java Security Basics===
Provide an introduction into the basic security services provided by the Java language and environment. Remember to keep this relevant for web developers for the initial release - there may be a potential to expand this to thick clients in subsequent releases.
* Class Loading (0%, Philippe Clairet)
* Bytecode verifier (0%, Philippe Clairet)
* The Security Manager and security.policy file (0%, John Wilander, Philippe Clairet)

===Input Validation Overview ===
Input validation is perhaps the most important category of application security. Any data entering a software system must be verified to contain safe data that is not mounting a SQL Injection, XSS, CSRF or other form of attack. This is done primarily through the use of regular expressions. It's crucial not to hard-code input validation routines. Regular expressions should contained within a configuration file that can easily updated by an InfoSec professional and not require a programmers intervention or deployment of new application code. Application security needs change over time as new attack vectors are discovered. Application administers need to be able to react to these changes as quickly as possible.

===Input Validation ===
* Dangerous calls (BufferedReader.readLine(), ServletRequest.getParameter(), etc...) (0%, TD)
* [[How to add validation logic to HttpServletRequest]] (100%, Jeff Williams, Complete)
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Complete)

==== [[Preventing SQL Injection in Java]] ====
* Overview
* Prevention (60%, Stephen de Vries, Review)
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis (60%, Rohyt Belani, Review)
** Spring JDBC
** EJB 3.0
** JDO

==== [[Preventing LDAP Injection in Java]] ====
* Overview (100%, Stephen de Vries, Complete)
* Prevention (100%, Stephen de Vries, Complete)

==== XPATH Injection ====
* [[XPATH Injection|Article n°1]] (70%, Weilin Zhong)
* [[XPATH Injection Java|Article n°2]] (100%, Dominique Righetto, Complete)

==== [[Miscellaneous Injection Attacks]] ====
* HTTP Response splitting (0%, TD)
* [[Code injection in Java]] (75%, Neil Bergman, Review)
* [[Command injection in Java]] - Runtime.getRuntime().exec() (100%, Neil Bergman, Review)
* Regular Expression (regex) Injections (20%)

''' Status '''
In progress

=== Authentication===
* [[Storing credentials]] - (20%, Adrian San Juan, Review)
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, Review)
* [[SSL Best Practices]] - (20%, Philippe Curmin, Review)
* [[Captchas in Java]] - (100%, Dave Ferguson, Review)
* Container-managed authentication with Realms
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Completed)
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, Review)
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, Review)
* [[Password length & complexity]] - (100%, Adrian San Juan, Review)

===Session Management ===
The generic problems and solutions for session management are covered in the Guide. This section should focus on Java specific examples.
* [[Logout]] (100%, Dominique Righetto, Complete)
* [[Session Timeout]] (100%, Dominique Righetto, Complete)
* Absolute Timeout (0%, TD)
* [[Session Fixation in Java]] (100%, Rohyt Belani, Review)
* Terminating sessions (0%, TD)
** Terminating sessions when the browser window is closed

===Authorization===
* [[Declarative v/s Programmatic]] (10%, TD)
* EJB Authorization (0%, TD)
* Acegi (0%, TD)
* JACC (0%, TD)
* Check horizontal privilege (0%, TD)

=== Encryption===
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions JCE] (100%, Joe Prasanna Kumar - To be reviewed)
* Storing db secrets (0%, TD)
* Encrypting JDBC connections (0%, TD)
* [http://www.owasp.org/index.php/Using_the_Java_Secure_Socket_Extensions JSSE] (100%, Joe Prasanna Kumar - To be reviewed)
* [http://www.owasp.org/index.php/Digital_Signature_Implementation_in_Java Digital Signatures in Java] (100%, Joe Prasanna Kumar - To be reviewed)

=== Error Handling & Logging===
* Logging - why log? what to log? log4j, etc. (0%, TD)
* [[Exception handling techniques]] (20%, Manuela Grindei, In progress)
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks (50%, TD)
** [[Servlet spec - web.xml]] (100%, Dominique Righetto, Complete)
** [[Securing tomcat]] (100%, Darren Edmonds, Completed)
** [[JSP errorPage]] (100%, Dominique Righetto, Complete)
* Web application forensics (0%, TD)

=== Web Services Security ===
* SAML (0%, TD)
* (X)WS-Security (0%, TD)
* SunJWSDP (0%, TD)
* WSS4J (0%, Eelco Klaver)
* XML Signature (JSR 105) (0%, TD)
* XML Encryption (JSR 106) (0%, TD)

=== Cross-Origin Resource Sharing ===
* [[CORS OriginHeaderScrutiny|Origin HTTP header check]] (100%, Dominique Righetto, Complete)
* [[CORS RequestPreflighScrutiny|Request preflight process check]] (100%, Dominique Righetto, Complete)

=== Content Security Policy ===
* [[Content Security Policy|Set up in a application]] (100%, Dominique Righetto, Complete)

=== Code Analysis Tools ===
The introduction should cover the advantages and short comings of code analysis tools. An overview of the current state of the art and the available tools would go well here. As a start, only open source tools are listed, but if vendors of commercial tools adhere to the [[Tutorial]] guidelines, these submissions will be gladly received.
* Introduction (0%, TD)
* [[:Category:OWASP LAPSE Project]] (100%, Review)
* FindBugs (0%, TD)
** Creating custom rules
* PMD (0%, TD)
** Creating custom rules
* JLint (0%, TD)
* Jmetrics (0%, TD)

=== Choosing Security Libraries ===
* [[Summary of Java Security Libraries]]

== J2EE Security For Deployers ==
Practical step-by-step guides to securing various J2EE servers. Examples of secure configurations can also be provided for download. If configurations are provided, they should be properly commented so that the rationale for configuration settings is clearly explained. Users of the configurations should be provided with enough information to make their own risk decisions.
=== Securing Popular J2EE Servers ===
* [[Securing tomcat|Securing Tomcat]] - (100%, Darren Edmonds, Completed)
* Securing JBoss (0%, TD)
* Securing WebLogic (0%, TD)
* Securing WebSphere (0%, TD)
* Others...

=== Defining a Java Security Policy ===
Practical information on creating a Java security policies for J2EE servers.
* PolicyTool - JChains already provides this functionality, one policy tool is enough.
* jChains (www.jchains.org) - (0%, TD)

=== Protecting Binaries ===
* Bytecode manipulation tools and techniques (0%, TD)
* [[Bytecode obfuscation]] (100%, Pierre Parrend, Released)
* Convert bytecode to native machine code (0%, TD)
* [[Protecting code archives with digital signatures]] (100%, Pierre Parrend, Released)
* [[Signing jar files with jarsigner]] (100%, Pierre Parrend, Released)

==J2EE Security for Security Analysts and Testers==
* Using Eclipse to verify Java applications (0%, TD)
* Using [[:Category:OWASP WebScarab Project|WebScarab]] to find vulnerabilities in J2EE applications - (0%, TD)
* [[Decompiling Java bytecode]] (100%, Dominique Righetto, Complete)

== [[Java Security Resources]] (ongoing)==

[[Category:OWASP Java Project]]

OWASP Java Table of Contents

2013-11-17T14:23:21Z

Manuela Grindei:

Key:
* xx%: Progress status of the paragraph
* Review: The paragraph needs a review
* TD: Paragraph to be assigned

==[[J2EE Security for Architects]]==
Discuss the security implications of common J2EE architectures. This could be discussed in terms of: Authentication, Authorisation, Data Validation, Cross Site Scripting protection. Other architecture concerns such as scalability, performance and maintainability can also be mentioned, but the focus on security should not be lost.

Any other security concerns that should be addressed during the design phase should also be mentioned here.
===Design considerations===
* Architectural considerations (0%, TD)
** EJB Middle tier (0%, TD)
** Web Services Middle tier (0%, TD)
** Spring Middle tier (0%, TD)

==[[J2EE Security for Developers]]==
=== Noteworthy Frameworks ===
Discuss important and relevant Java security frameworks that would be useful to architects. The information should be at a suitably high level. For example, by discussing the advantages and features as well as the associated costs (direct and indirect) of using the frameworks.

(0%, Seeking Volunteers)
* Cocoon
* [[Java Server Faces]] (Sam Reghenzi - 90%, Finalising content)
* JSecurity
* SiteMesh
* Spring (0%, Adrian San Juan, TD)
* [[Struts]] (0% Jon Forck)
* Tapestry
* Tiles
* Turbine
* Webwork
* [[Wicket]]

===Java Security Basics===
Provide an introduction into the basic security services provided by the Java language and environment. Remember to keep this relevant for web developers for the initial release - there may be a potential to expand this to thick clients in subsequent releases.
* Class Loading (0%, Philippe Clairet)
* Bytecode verifier (0%, Philippe Clairet)
* The Security Manager and security.policy file (0%, John Wilander, Philippe Clairet)

===Input Validation Overview ===
Input validation is perhaps the most important category of application security. Any data entering a software system must be verified to contain safe data that is not mounting a SQL Injection, XSS, CSRF or other form of attack. This is done primarily through the use of regular expressions. It's crucial not to hard-code input validation routines. Regular expressions should contained within a configuration file that can easily updated by an InfoSec professional and not require a programmers intervention or deployment of new application code. Application security needs change over time as new attack vectors are discovered. Application administers need to be able to react to these changes as quickly as possible.

===Input Validation ===
* Dangerous calls (BufferedReader.readLine(), ServletRequest.getParameter(), etc...) (0%, TD)
* [[How to add validation logic to HttpServletRequest]] (100%, Jeff Williams, Complete)
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Complete)

==== [[Preventing SQL Injection in Java]] ====
* Overview
* Prevention (60%, Stephen de Vries, Review)
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis (60%, Rohyt Belani, Review)
** Spring JDBC
** EJB 3.0
** JDO

==== [[Preventing LDAP Injection in Java]] ====
* Overview (100%, Stephen de Vries, Complete)
* Prevention (100%, Stephen de Vries, Complete)

==== XPATH Injection ====
* [[XPATH Injection|Article n°1]] (70%, Weilin Zhong)
* [[XPATH Injection Java|Article n°2]] (100%, Dominique Righetto, Complete)

==== [[Miscellaneous Injection Attacks]] ====
* HTTP Response splitting (0%, TD)
* [[Code injection in Java]] (75%, Neil Bergman, Review)
* [[Command injection in Java]] - Runtime.getRuntime().exec() (100%, Neil Bergman, Review)
* Regular Expression (regex) Injections (20%)

''' Status '''
In progress

=== Authentication===
* [[Storing credentials]] - (20%, Adrian San Juan, Review)
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, Review)
* [[SSL Best Practices]] - (20%, Philippe Curmin, Review)
* [[Captchas in Java]] - (100%, Dave Ferguson, Review)
* Container-managed authentication with Realms
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Completed)
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, Review)
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, Review)
* [[Password length & complexity]] - (100%, Adrian San Juan, Review)

===Session Management ===
The generic problems and solutions for session management are covered in the Guide. This section should focus on Java specific examples.
* [[Logout]] (100%, Dominique Righetto, Complete)
* [[Session Timeout]] (100%, Dominique Righetto, Complete)
* Absolute Timeout (0%, TD)
* [[Session Fixation in Java]] (100%, Rohyt Belani, Review)
* Terminating sessions (0%, TD)
** Terminating sessions when the browser window is closed

===Authorization===
* [[Declarative v/s Programmatic]] (10%, TD)
* EJB Authorization (0%, TD)
* Acegi (0%, TD)
* JACC (0%, TD)
* Check horizontal privilege (0%, TD)

=== Encryption===
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions JCE] (100%, Joe Prasanna Kumar - To be reviewed)
* Storing db secrets (0%, TD)
* Encrypting JDBC connections (0%, TD)
* [http://www.owasp.org/index.php/Using_the_Java_Secure_Socket_Extensions JSSE] (100%, Joe Prasanna Kumar - To be reviewed)
* [http://www.owasp.org/index.php/Digital_Signature_Implementation_in_Java Digital Signatures in Java] (100%, Joe Prasanna Kumar - To be reviewed)

=== Error Handling & Logging===
* Logging - why log? what to log? log4j, etc. (0%, TD)
* Exception handling techniques (20%, Manuela Grindei, In progress)
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks (50%, TD)
** [[Servlet spec - web.xml]] (100%, Dominique Righetto, Complete)
** [[Securing tomcat]] (100%, Darren Edmonds, Completed)
** [[JSP errorPage]] (100%, Dominique Righetto, Complete)
* Web application forensics (0%, TD)

=== Web Services Security ===
* SAML (0%, TD)
* (X)WS-Security (0%, TD)
* SunJWSDP (0%, TD)
* WSS4J (0%, Eelco Klaver)
* XML Signature (JSR 105) (0%, TD)
* XML Encryption (JSR 106) (0%, TD)

=== Cross-Origin Resource Sharing ===
* [[CORS OriginHeaderScrutiny|Origin HTTP header check]] (100%, Dominique Righetto, Complete)
* [[CORS RequestPreflighScrutiny|Request preflight process check]] (100%, Dominique Righetto, Complete)

=== Content Security Policy ===
* [[Content Security Policy|Set up in a application]] (100%, Dominique Righetto, Complete)

=== Code Analysis Tools ===
The introduction should cover the advantages and short comings of code analysis tools. An overview of the current state of the art and the available tools would go well here. As a start, only open source tools are listed, but if vendors of commercial tools adhere to the [[Tutorial]] guidelines, these submissions will be gladly received.
* Introduction (0%, TD)
* [[:Category:OWASP LAPSE Project]] (100%, Review)
* FindBugs (0%, TD)
** Creating custom rules
* PMD (0%, TD)
** Creating custom rules
* JLint (0%, TD)
* Jmetrics (0%, TD)

=== Choosing Security Libraries ===
* [[Summary of Java Security Libraries]]

== J2EE Security For Deployers ==
Practical step-by-step guides to securing various J2EE servers. Examples of secure configurations can also be provided for download. If configurations are provided, they should be properly commented so that the rationale for configuration settings is clearly explained. Users of the configurations should be provided with enough information to make their own risk decisions.
=== Securing Popular J2EE Servers ===
* [[Securing tomcat|Securing Tomcat]] - (100%, Darren Edmonds, Completed)
* Securing JBoss (0%, TD)
* Securing WebLogic (0%, TD)
* Securing WebSphere (0%, TD)
* Others...

=== Defining a Java Security Policy ===
Practical information on creating a Java security policies for J2EE servers.
* PolicyTool - JChains already provides this functionality, one policy tool is enough.
* jChains (www.jchains.org) - (0%, TD)

=== Protecting Binaries ===
* Bytecode manipulation tools and techniques (0%, TD)
* [[Bytecode obfuscation]] (100%, Pierre Parrend, Released)
* Convert bytecode to native machine code (0%, TD)
* [[Protecting code archives with digital signatures]] (100%, Pierre Parrend, Released)
* [[Signing jar files with jarsigner]] (100%, Pierre Parrend, Released)

==J2EE Security for Security Analysts and Testers==
* Using Eclipse to verify Java applications (0%, TD)
* Using [[:Category:OWASP WebScarab Project|WebScarab]] to find vulnerabilities in J2EE applications - (0%, TD)
* [[Decompiling Java bytecode]] (100%, Dominique Righetto, Complete)

== [[Java Security Resources]] (ongoing)==

[[Category:OWASP Java Project]]