OWASP - User contributions [en]

OWASP Java Table of Contents

2007-03-05T20:21:21Z

Rohyt: /* Session Management */

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)
* Struts
* Turbine
* JFS (MyFaces)
* Tapestry
* Webwork
* Cocoon
* Tiles
* SiteMesh
* Spring

===[[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%, Shyaam Sundar, Review)
* Bytecode verifier (0%, Shyaam Sundar, Review)
* The Security Manager and security.policy file (0%, Shyaam Sundar, Review)

===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, Review)
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Review)

==== [[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, Review)
* Prevention (100%, Stephen de Vries, Review)

==== [[XPATH Injection]] ====
As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing XPATH injection.
* Overview (0%, TD)
* Prevention (0%, TD)

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting (0%, TD)
* Command injection - Runtime.getRuntime().exec() (0%, TD)

=== Authentication===
* Storing credentials - (0%, Adrian San Juan, Review)
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, Review)
* [[SSL Best Practices]] - (20%, Philippe Curmin, Review)
* [[Using JCaptcha]] - (100%, Dave Ferguson, Review)
* Container-managed authentication with Realms
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Reviewed by Pierre Parrend, Dave to act on comments)
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, Review)
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, Review)
* [[Password length & complexity]] - (0%, 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 (0%, TD)
* Session Timeout (0%, TD)
* 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 (0%, 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] (80%, 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] (80%, Joe Prasanna Kumar - To be reviewed)
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions Random number generation] (80%, Joe Prasanna Kumar - To be reviewed)

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

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

=== 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)

== [[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, Review)
* 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 (80%, Jeff Williams, Needs a new owner, Review)
* jChains (www.jchains.org) - (0%, TD)

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

==[[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 (0%, TD)

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

[[Category:OWASP Java Project]]

OWASP Java Table of Contents

2007-03-05T20:20:41Z

Rohyt: /* Preventing SQL Injection in Java */

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)
* Struts
* Turbine
* JFS (MyFaces)
* Tapestry
* Webwork
* Cocoon
* Tiles
* SiteMesh
* Spring

===[[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%, Shyaam Sundar, Review)
* Bytecode verifier (0%, Shyaam Sundar, Review)
* The Security Manager and security.policy file (0%, Shyaam Sundar, Review)

===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, Review)
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Review)

==== [[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, Review)
* Prevention (100%, Stephen de Vries, Review)

==== [[XPATH Injection]] ====
As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing XPATH injection.
* Overview (0%, TD)
* Prevention (0%, TD)

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting (0%, TD)
* Command injection - Runtime.getRuntime().exec() (0%, TD)

=== Authentication===
* Storing credentials - (0%, Adrian San Juan, Review)
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, Review)
* [[SSL Best Practices]] - (20%, Philippe Curmin, Review)
* [[Using JCaptcha]] - (100%, Dave Ferguson, Review)
* Container-managed authentication with Realms
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Reviewed by Pierre Parrend, Dave to act on comments)
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, Review)
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, Review)
* [[Password length & complexity]] - (0%, 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 (0%, TD)
* Session Timeout (0%, TD)
* Absolute Timeout (0%, TD)
* [[Session Fixation in Java]] (50%, Rohyt Belani)
* Terminating sessions (0%, TD)
** Terminating sessions when the browser window is closed

===Authorization===
* Declarative v/s Programmatic (0%, 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] (80%, 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] (80%, Joe Prasanna Kumar - To be reviewed)
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions Random number generation] (80%, Joe Prasanna Kumar - To be reviewed)

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

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

=== 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)

== [[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, Review)
* 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 (80%, Jeff Williams, Needs a new owner, Review)
* jChains (www.jchains.org) - (0%, TD)

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

==[[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 (0%, TD)

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

[[Category:OWASP Java Project]]

Preventing SQL Injection in Java

2007-03-05T20:19:33Z

Rohyt: /* Ibatis */

==Overview==
As the name implies, SQL injection vulnerabilities allow an attacker to inject (or execute) SQL commands within an application. It is one of the most wide spread and dangerous application vulnerability. The CLASP project provides a good overview of [[SQL injection]].
===Example of SQL injection===
The following Java servlet code, used to perform a login function, illustrates the vulnerability by accepting user input without performing adequate input validation or escaping meta-characters:
conn = pool.getConnection( );
String sql = "select * from user where username='" + username +"' and password='" + password + "'";
stmt = conn.createStatement();
rs = stmt.executeQuery(sql);
if (rs.next()) {
loggedIn = true;
out.println("Successfully logged in");
} else {
out.println("Username and/or password not recognized");
}
It is possible for attackers to provide a username containing SQL meta-characters that subvert the intended function of the SQL statement. For example, by providing a username of:
admin' OR '1'='1
and a blank password, the generated SQL statement becomes:
select * from user where username='admin' OR '1'='1' and password=' '
This allows an attacker to log in to the site without supplying a password, since the ‘OR’ expression is always true. Using the same technique attackers can inject other SQL commands which could extract, modify or delete data within the database.
===Attack techniques===
For more information on SQL injection attacks see:
* http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
* http://www.nextgenss.com/papers/advanced_sql_injection.pdf
* http://www.appsecinc.com/presentations/Manipulating_SQL_Server_Using_SQL_Injection.pdf
==Defence Strategy==
To prevent SQL injection, a two pronged approach is recommended:
* Firstly, all data accepted from user input should be thoroughly validated to ensure that the characters received are part of the set of valid characters for that field;
* Secondly, all data acted on by SQL commands should be escaped for meta-characters.
=== Validating Input ===
A general security principle which applies itself well to data validation is that of “deny by default” where data is rejected unless it specifically matches the criteria for known good data. This is also known as a “white list” approach and is the preferred method for performing data validation. It allows one to define a restricted range for valid data and reject everything that does not fit this set. The set of valid data should be constrained by:
* Type – String, integer, unsigned integer, float etc;
* Length;
* Set of character – for example, only alphabetic characters [a-zA-Z]*;
* Format – if appropriate the data could be further constrained by specifying a format, e.g.: \d\d\/\d\d\/\d\d
* Reasonableness – where possible, values should be compared to expected ranges. For example, a customer ordering 1000 televisions could be suspicious.
It is essential that the data validation routines themselves can be trusted, therefore they must be performed on the server side. Client side validation can be performed as a useful user interface feature, but it must be reinforced by server side validation.
Where input validation is performed on the server side will depend largely on the frameworks available. JSF and Struts provide validation functions that are defined in the view layer, while Spring and EJB 3.0 allow validation to be defined in the model. 
Input validation provides the first line of defence in preventing dangerous characters from being processed by the application.
But even if data is constrained in this way it does not solve the meta-character problem: How should the application handle meta-characters that are defined as valid data, but cannot be used in certain processing contexts? For example, the single quote (') character may be a valid character in a surname, but this character cannot simply be used in a string that is used to form an SQL statement. The OWASP Guide project has more information on [[Data Validation]].
=== Escaping Meta-characters ===
All data access techniques provide some means for escaping SQL meta-characters automatically. The important thing to remember is to never construct SQL statements using string concatenation of unchecked input values. The following sections detail how to perform input validation and meta-character escaping using popular data access technologies.
==Prepared Statements==
Variables passed as arguments to prepared statements will automatically be escaped by the JDBC driver. 
Example: ps.1 
String selectStatement = "SELECT * FROM User WHERE userId = ? ";
PreparedStatement prepStmt = con.prepareStatement(selectStatement);
prepStmt.setString(1, userId);
ResultSet rs = prepStmt.executeQuery();

Although Prepared Statements helps in defending against SQL Injection, there are possibilities of SQL Injection attacks through inappropriate usage of Prepared Statements. The example below explains such a scenario where the input variables are passed directly into the Prepared Statement and thereby paving way for SQL Injection attacks. 
Example: ps.2 
<pre>
String strUserName = request.getParameter("Txt_UserName");
PreparedStatement prepStmt = con.prepareStatement("SELECT * FROM user WHERE userId = '+strUserName+'");
</pre>
It is highly recommended to use Bind Variables as mentioned in the example ps.1 above. Usage of PreparedStatement with Bind variables defends SQL Injection attacks and improves the performance.

==Stored Procedures==
==Hibernate==
According to [http://forum.hibernate.org/viewtopic.php?t=960817&start=0&postdays=0&postorder=asc this forum thread] hibernate uses prepared statements, so it is protected from sql injection.

==Ibatis==

Ibatis creates prepared statements for database access.
However, SQL injection is possible in Ibatis if the $$ variable replacement syntax is used. 

Vulnerable: 
<select id=“vuln" resultMap=“myResultMap”> select * from table where id = $value$</select>

The above query is called as follows:
MyBean b = (MyBean)sqlMap.queryForObject("vuln", new Integer(1));

The SQL statement thus created, looks as follows:

select * from table where id = 1

The object passed as parameter is directly fed to the SQL query making it susceptible to SQL injection 

 Secure: 

<select id=“vuln" resultMap=“myResultMap”> select * from table where id = #value#</select>

Using this form instead generates the following SQL

select * from table where id = ?

The value of the parameter is sent directly to the driver and not used to modify the SQL statement itself. 
This approach thwarts SQL injection attacks

==Spring JDBC==
==EJB 3.0==

== References ==
*[1] [http://research.corsaire.com/whitepapers/060116-a-modular-approach-to-data-validation.pdf A Modular Approach to Data Validation]
*[2] [http://forum.hibernate.org/viewtopic.php?t=960817&start=0&postdays=0&postorder=asc&highlight= Topic: does Hibernate guard against SQL injection?]

[[Category:OWASP Java Project]]

Preventing SQL Injection in Java

2007-03-05T20:12:01Z

Rohyt: /* Ibatis */

==Overview==
As the name implies, SQL injection vulnerabilities allow an attacker to inject (or execute) SQL commands within an application. It is one of the most wide spread and dangerous application vulnerability. The CLASP project provides a good overview of [[SQL injection]].
===Example of SQL injection===
The following Java servlet code, used to perform a login function, illustrates the vulnerability by accepting user input without performing adequate input validation or escaping meta-characters:
conn = pool.getConnection( );
String sql = "select * from user where username='" + username +"' and password='" + password + "'";
stmt = conn.createStatement();
rs = stmt.executeQuery(sql);
if (rs.next()) {
loggedIn = true;
out.println("Successfully logged in");
} else {
out.println("Username and/or password not recognized");
}
It is possible for attackers to provide a username containing SQL meta-characters that subvert the intended function of the SQL statement. For example, by providing a username of:
admin' OR '1'='1
and a blank password, the generated SQL statement becomes:
select * from user where username='admin' OR '1'='1' and password=' '
This allows an attacker to log in to the site without supplying a password, since the ‘OR’ expression is always true. Using the same technique attackers can inject other SQL commands which could extract, modify or delete data within the database.
===Attack techniques===
For more information on SQL injection attacks see:
* http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
* http://www.nextgenss.com/papers/advanced_sql_injection.pdf
* http://www.appsecinc.com/presentations/Manipulating_SQL_Server_Using_SQL_Injection.pdf
==Defence Strategy==
To prevent SQL injection, a two pronged approach is recommended:
* Firstly, all data accepted from user input should be thoroughly validated to ensure that the characters received are part of the set of valid characters for that field;
* Secondly, all data acted on by SQL commands should be escaped for meta-characters.
=== Validating Input ===
A general security principle which applies itself well to data validation is that of “deny by default” where data is rejected unless it specifically matches the criteria for known good data. This is also known as a “white list” approach and is the preferred method for performing data validation. It allows one to define a restricted range for valid data and reject everything that does not fit this set. The set of valid data should be constrained by:
* Type – String, integer, unsigned integer, float etc;
* Length;
* Set of character – for example, only alphabetic characters [a-zA-Z]*;
* Format – if appropriate the data could be further constrained by specifying a format, e.g.: \d\d\/\d\d\/\d\d
* Reasonableness – where possible, values should be compared to expected ranges. For example, a customer ordering 1000 televisions could be suspicious.
It is essential that the data validation routines themselves can be trusted, therefore they must be performed on the server side. Client side validation can be performed as a useful user interface feature, but it must be reinforced by server side validation.
Where input validation is performed on the server side will depend largely on the frameworks available. JSF and Struts provide validation functions that are defined in the view layer, while Spring and EJB 3.0 allow validation to be defined in the model. 
Input validation provides the first line of defence in preventing dangerous characters from being processed by the application.
But even if data is constrained in this way it does not solve the meta-character problem: How should the application handle meta-characters that are defined as valid data, but cannot be used in certain processing contexts? For example, the single quote (') character may be a valid character in a surname, but this character cannot simply be used in a string that is used to form an SQL statement. The OWASP Guide project has more information on [[Data Validation]].
=== Escaping Meta-characters ===
All data access techniques provide some means for escaping SQL meta-characters automatically. The important thing to remember is to never construct SQL statements using string concatenation of unchecked input values. The following sections detail how to perform input validation and meta-character escaping using popular data access technologies.
==Prepared Statements==
Variables passed as arguments to prepared statements will automatically be escaped by the JDBC driver. 
Example: ps.1 
String selectStatement = "SELECT * FROM User WHERE userId = ? ";
PreparedStatement prepStmt = con.prepareStatement(selectStatement);
prepStmt.setString(1, userId);
ResultSet rs = prepStmt.executeQuery();

Although Prepared Statements helps in defending against SQL Injection, there are possibilities of SQL Injection attacks through inappropriate usage of Prepared Statements. The example below explains such a scenario where the input variables are passed directly into the Prepared Statement and thereby paving way for SQL Injection attacks. 
Example: ps.2 
<pre>
String strUserName = request.getParameter("Txt_UserName");
PreparedStatement prepStmt = con.prepareStatement("SELECT * FROM user WHERE userId = '+strUserName+'");
</pre>
It is highly recommended to use Bind Variables as mentioned in the example ps.1 above. Usage of PreparedStatement with Bind variables defends SQL Injection attacks and improves the performance.

==Stored Procedures==
==Hibernate==
According to [http://forum.hibernate.org/viewtopic.php?t=960817&start=0&postdays=0&postorder=asc this forum thread] hibernate uses prepared statements, so it is protected from sql injection.

==Ibatis==

Ibatis creates prepared statements for database access.
However, SQL injection is possible in Ibatis if the $$ variable replacement syntax is used.

Consider the following examples-

* <select id=“vuln" resultMap=“myResultMap”> select * from table where id = $value$</select>

The above query is called as follows:
<pre>
MyBean b = (MyBean)sqlMap.queryForObject("vuln", new Integer(1));
</pre>

The SQL statement thus created, looks as follows:

select * from table where id = 1

The object passed as parameter is directly fed to the SQL query making it susceptible to SQL injection

* <select id=“vuln" resultMap=“myResultMap”> select * from table where id = #value#</select>

Using this form instead generates the following SQL
select * from foo where id = ?

The value of the parameter is sent directly to the driver and not used to modify the SQL statement itself
This approach thwarts SQL injection attacks

==Spring JDBC==
==EJB 3.0==

== References ==
*[1] [http://research.corsaire.com/whitepapers/060116-a-modular-approach-to-data-validation.pdf A Modular Approach to Data Validation]
*[2] [http://forum.hibernate.org/viewtopic.php?t=960817&start=0&postdays=0&postorder=asc&highlight= Topic: does Hibernate guard against SQL injection?]

[[Category:OWASP Java Project]]

Preventing SQL Injection in Java

2007-03-05T20:10:31Z

Rohyt: /* Ibatis */

==Overview==
As the name implies, SQL injection vulnerabilities allow an attacker to inject (or execute) SQL commands within an application. It is one of the most wide spread and dangerous application vulnerability. The CLASP project provides a good overview of [[SQL injection]].
===Example of SQL injection===
The following Java servlet code, used to perform a login function, illustrates the vulnerability by accepting user input without performing adequate input validation or escaping meta-characters:
conn = pool.getConnection( );
String sql = "select * from user where username='" + username +"' and password='" + password + "'";
stmt = conn.createStatement();
rs = stmt.executeQuery(sql);
if (rs.next()) {
loggedIn = true;
out.println("Successfully logged in");
} else {
out.println("Username and/or password not recognized");
}
It is possible for attackers to provide a username containing SQL meta-characters that subvert the intended function of the SQL statement. For example, by providing a username of:
admin' OR '1'='1
and a blank password, the generated SQL statement becomes:
select * from user where username='admin' OR '1'='1' and password=' '
This allows an attacker to log in to the site without supplying a password, since the ‘OR’ expression is always true. Using the same technique attackers can inject other SQL commands which could extract, modify or delete data within the database.
===Attack techniques===
For more information on SQL injection attacks see:
* http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
* http://www.nextgenss.com/papers/advanced_sql_injection.pdf
* http://www.appsecinc.com/presentations/Manipulating_SQL_Server_Using_SQL_Injection.pdf
==Defence Strategy==
To prevent SQL injection, a two pronged approach is recommended:
* Firstly, all data accepted from user input should be thoroughly validated to ensure that the characters received are part of the set of valid characters for that field;
* Secondly, all data acted on by SQL commands should be escaped for meta-characters.
=== Validating Input ===
A general security principle which applies itself well to data validation is that of “deny by default” where data is rejected unless it specifically matches the criteria for known good data. This is also known as a “white list” approach and is the preferred method for performing data validation. It allows one to define a restricted range for valid data and reject everything that does not fit this set. The set of valid data should be constrained by:
* Type – String, integer, unsigned integer, float etc;
* Length;
* Set of character – for example, only alphabetic characters [a-zA-Z]*;
* Format – if appropriate the data could be further constrained by specifying a format, e.g.: \d\d\/\d\d\/\d\d
* Reasonableness – where possible, values should be compared to expected ranges. For example, a customer ordering 1000 televisions could be suspicious.
It is essential that the data validation routines themselves can be trusted, therefore they must be performed on the server side. Client side validation can be performed as a useful user interface feature, but it must be reinforced by server side validation.
Where input validation is performed on the server side will depend largely on the frameworks available. JSF and Struts provide validation functions that are defined in the view layer, while Spring and EJB 3.0 allow validation to be defined in the model. 
Input validation provides the first line of defence in preventing dangerous characters from being processed by the application.
But even if data is constrained in this way it does not solve the meta-character problem: How should the application handle meta-characters that are defined as valid data, but cannot be used in certain processing contexts? For example, the single quote (') character may be a valid character in a surname, but this character cannot simply be used in a string that is used to form an SQL statement. The OWASP Guide project has more information on [[Data Validation]].
=== Escaping Meta-characters ===
All data access techniques provide some means for escaping SQL meta-characters automatically. The important thing to remember is to never construct SQL statements using string concatenation of unchecked input values. The following sections detail how to perform input validation and meta-character escaping using popular data access technologies.
==Prepared Statements==
Variables passed as arguments to prepared statements will automatically be escaped by the JDBC driver. 
Example: ps.1 
String selectStatement = "SELECT * FROM User WHERE userId = ? ";
PreparedStatement prepStmt = con.prepareStatement(selectStatement);
prepStmt.setString(1, userId);
ResultSet rs = prepStmt.executeQuery();

Although Prepared Statements helps in defending against SQL Injection, there are possibilities of SQL Injection attacks through inappropriate usage of Prepared Statements. The example below explains such a scenario where the input variables are passed directly into the Prepared Statement and thereby paving way for SQL Injection attacks. 
Example: ps.2 
<pre>
String strUserName = request.getParameter("Txt_UserName");
PreparedStatement prepStmt = con.prepareStatement("SELECT * FROM user WHERE userId = '+strUserName+'");
</pre>
It is highly recommended to use Bind Variables as mentioned in the example ps.1 above. Usage of PreparedStatement with Bind variables defends SQL Injection attacks and improves the performance.

==Stored Procedures==
==Hibernate==
According to [http://forum.hibernate.org/viewtopic.php?t=960817&start=0&postdays=0&postorder=asc this forum thread] hibernate uses prepared statements, so it is protected from sql injection.

==Ibatis==

Ibatis creates prepared statements for database access.
However, SQL injection is possible in Ibatis if the $$ variable replacement syntax is used.

Consider the following examples-

* <select id=“vuln" resultMap=“myResultMap”> select * from table where id = $value$</select>

The above query is called as follows:
<pre>MyBean b = (MyBean)sqlMap.queryForObject("vuln", new Integer(1));</pre>

The SQL statement thus created, looks as follows:
<pre>select * from table where id = 1</pre>

The object passed as parameter is directly fed to the SQL query making it susceptible to SQL injection

* <select id=“vuln" resultMap=“myResultMap”> select * from table where id = #value#</select>

Using this form instead generates the following SQL
<pre>select * from foo where id = ?</pre>

The value of the parameter is sent directly to the driver and not used to modify the SQL statement itself
This approach thwarts SQL injection attacks

==Spring JDBC==
==EJB 3.0==

== References ==
*[1] [http://research.corsaire.com/whitepapers/060116-a-modular-approach-to-data-validation.pdf A Modular Approach to Data Validation]
*[2] [http://forum.hibernate.org/viewtopic.php?t=960817&start=0&postdays=0&postorder=asc&highlight= Topic: does Hibernate guard against SQL injection?]

[[Category:OWASP Java Project]]

Preventing SQL Injection in Java

2007-03-05T20:08:23Z

Rohyt: /* Ibatis */

==Overview==
As the name implies, SQL injection vulnerabilities allow an attacker to inject (or execute) SQL commands within an application. It is one of the most wide spread and dangerous application vulnerability. The CLASP project provides a good overview of [[SQL injection]].
===Example of SQL injection===
The following Java servlet code, used to perform a login function, illustrates the vulnerability by accepting user input without performing adequate input validation or escaping meta-characters:
conn = pool.getConnection( );
String sql = "select * from user where username='" + username +"' and password='" + password + "'";
stmt = conn.createStatement();
rs = stmt.executeQuery(sql);
if (rs.next()) {
loggedIn = true;
out.println("Successfully logged in");
} else {
out.println("Username and/or password not recognized");
}
It is possible for attackers to provide a username containing SQL meta-characters that subvert the intended function of the SQL statement. For example, by providing a username of:
admin' OR '1'='1
and a blank password, the generated SQL statement becomes:
select * from user where username='admin' OR '1'='1' and password=' '
This allows an attacker to log in to the site without supplying a password, since the ‘OR’ expression is always true. Using the same technique attackers can inject other SQL commands which could extract, modify or delete data within the database.
===Attack techniques===
For more information on SQL injection attacks see:
* http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
* http://www.nextgenss.com/papers/advanced_sql_injection.pdf
* http://www.appsecinc.com/presentations/Manipulating_SQL_Server_Using_SQL_Injection.pdf
==Defence Strategy==
To prevent SQL injection, a two pronged approach is recommended:
* Firstly, all data accepted from user input should be thoroughly validated to ensure that the characters received are part of the set of valid characters for that field;
* Secondly, all data acted on by SQL commands should be escaped for meta-characters.
=== Validating Input ===
A general security principle which applies itself well to data validation is that of “deny by default” where data is rejected unless it specifically matches the criteria for known good data. This is also known as a “white list” approach and is the preferred method for performing data validation. It allows one to define a restricted range for valid data and reject everything that does not fit this set. The set of valid data should be constrained by:
* Type – String, integer, unsigned integer, float etc;
* Length;
* Set of character – for example, only alphabetic characters [a-zA-Z]*;
* Format – if appropriate the data could be further constrained by specifying a format, e.g.: \d\d\/\d\d\/\d\d
* Reasonableness – where possible, values should be compared to expected ranges. For example, a customer ordering 1000 televisions could be suspicious.
It is essential that the data validation routines themselves can be trusted, therefore they must be performed on the server side. Client side validation can be performed as a useful user interface feature, but it must be reinforced by server side validation.
Where input validation is performed on the server side will depend largely on the frameworks available. JSF and Struts provide validation functions that are defined in the view layer, while Spring and EJB 3.0 allow validation to be defined in the model. 
Input validation provides the first line of defence in preventing dangerous characters from being processed by the application.
But even if data is constrained in this way it does not solve the meta-character problem: How should the application handle meta-characters that are defined as valid data, but cannot be used in certain processing contexts? For example, the single quote (') character may be a valid character in a surname, but this character cannot simply be used in a string that is used to form an SQL statement. The OWASP Guide project has more information on [[Data Validation]].
=== Escaping Meta-characters ===
All data access techniques provide some means for escaping SQL meta-characters automatically. The important thing to remember is to never construct SQL statements using string concatenation of unchecked input values. The following sections detail how to perform input validation and meta-character escaping using popular data access technologies.
==Prepared Statements==
Variables passed as arguments to prepared statements will automatically be escaped by the JDBC driver. 
Example: ps.1 
String selectStatement = "SELECT * FROM User WHERE userId = ? ";
PreparedStatement prepStmt = con.prepareStatement(selectStatement);
prepStmt.setString(1, userId);
ResultSet rs = prepStmt.executeQuery();

Although Prepared Statements helps in defending against SQL Injection, there are possibilities of SQL Injection attacks through inappropriate usage of Prepared Statements. The example below explains such a scenario where the input variables are passed directly into the Prepared Statement and thereby paving way for SQL Injection attacks. 
Example: ps.2 
<pre>
String strUserName = request.getParameter("Txt_UserName");
PreparedStatement prepStmt = con.prepareStatement("SELECT * FROM user WHERE userId = '+strUserName+'");
</pre>
It is highly recommended to use Bind Variables as mentioned in the example ps.1 above. Usage of PreparedStatement with Bind variables defends SQL Injection attacks and improves the performance.

==Stored Procedures==
==Hibernate==
According to [http://forum.hibernate.org/viewtopic.php?t=960817&start=0&postdays=0&postorder=asc this forum thread] hibernate uses prepared statements, so it is protected from sql injection.

==Ibatis==

Ibatis creates prepared statements for database access.
However, SQL injection is possible in Ibatis if the $$ variable replacement syntax is used.

Consider the following examples-

* <select id=“vuln" resultMap=“myResultMap”> select * from table where id = $value$</select>

The above query is called as follows:
MyBean b = (MyBean)sqlMap.queryForObject("vuln", new Integer(1));

The SQL statement thus created, looks as follows:
select * from table where id = 1

The object passed as parameter is directly fed to the SQL query making it susceptible to SQL injection

* <select id=“vuln" resultMap=“myResultMap”> select * from table where id = #value#</select>

Using this form instead generates the following SQL
select * from foo where id = ?

The value of the parameter is sent directly to the driver and not used to modify the SQL statement itself
This approach thwarts SQL injection attacks

==Spring JDBC==
==EJB 3.0==

== References ==
*[1] [http://research.corsaire.com/whitepapers/060116-a-modular-approach-to-data-validation.pdf A Modular Approach to Data Validation]
*[2] [http://forum.hibernate.org/viewtopic.php?t=960817&start=0&postdays=0&postorder=asc&highlight= Topic: does Hibernate guard against SQL injection?]

[[Category:OWASP Java Project]]

OWASP Java Table of Contents

2007-03-05T19:48:50Z

Rohyt: /* Noteworthy Frameworks */

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)
* Struts
* Turbine
* JFS (MyFaces)
* Tapestry
* Webwork
* Cocoon
* Tiles
* SiteMesh
* Spring

===[[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%, Shyaam Sundar, Review)
* Bytecode verifier (0%, Shyaam Sundar, Review)
* The Security Manager and security.policy file (0%, Shyaam Sundar, Review)

===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, Review)
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Review)

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

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

==== [[XPATH Injection]] ====
As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing XPATH injection.
* Overview (0%, TD)
* Prevention (0%, TD)

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting (0%, TD)
* Command injection - Runtime.getRuntime().exec() (0%, TD)

=== Authentication===
* Storing credentials - (0%, Adrian San Juan, Review)
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, Review)
* [[SSL Best Practices]] - (20%, Philippe Curmin, Review)
* [[Using JCaptcha]] - (100%, Dave Ferguson, Review)
* Container-managed authentication with Realms
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Reviewed by Pierre Parrend, Dave to act on comments)
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, Review)
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, Review)
* [[Password length & complexity]] - (0%, 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 (0%, TD)
* Session Timeout (0%, TD)
* Absolute Timeout (0%, TD)
* [[Session Fixation in Java]] (50%, Rohyt Belani)
* Terminating sessions (0%, TD)
** Terminating sessions when the browser window is closed

===Authorization===
* Declarative v/s Programmatic (0%, 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] (80%, 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] (80%, Joe Prasanna Kumar - To be reviewed)
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions Random number generation] (80%, Joe Prasanna Kumar - To be reviewed)

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

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

=== 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)

== [[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, Review)
* 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 (80%, Jeff Williams, Needs a new owner, Review)
* jChains (www.jchains.org) - (0%, TD)

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

==[[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 (0%, TD)

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

[[Category:OWASP Java Project]]

OWASP Java Table of Contents

2007-03-05T19:47:36Z

Rohyt: /* Session Management */

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.

(50% ?, Claire McDonough, Ranjita Shankar Iyer, Rohyt Belani to update, Review)
* Struts
* Turbine
* JFS (MyFaces)
* Tapestry
* Webwork
* Cocoon
* Tiles
* SiteMesh
* Spring

===[[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%, Shyaam Sundar, Review)
* Bytecode verifier (0%, Shyaam Sundar, Review)
* The Security Manager and security.policy file (0%, Shyaam Sundar, Review)

===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, Review)
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Review)

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

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

==== [[XPATH Injection]] ====
As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing XPATH injection.
* Overview (0%, TD)
* Prevention (0%, TD)

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting (0%, TD)
* Command injection - Runtime.getRuntime().exec() (0%, TD)

=== Authentication===
* Storing credentials - (0%, Adrian San Juan, Review)
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, Review)
* [[SSL Best Practices]] - (20%, Philippe Curmin, Review)
* [[Using JCaptcha]] - (100%, Dave Ferguson, Review)
* Container-managed authentication with Realms
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Reviewed by Pierre Parrend, Dave to act on comments)
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, Review)
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, Review)
* [[Password length & complexity]] - (0%, 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 (0%, TD)
* Session Timeout (0%, TD)
* Absolute Timeout (0%, TD)
* [[Session Fixation in Java]] (50%, Rohyt Belani)
* Terminating sessions (0%, TD)
** Terminating sessions when the browser window is closed

===Authorization===
* Declarative v/s Programmatic (0%, 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] (80%, 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] (80%, Joe Prasanna Kumar - To be reviewed)
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions Random number generation] (80%, Joe Prasanna Kumar - To be reviewed)

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

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

=== 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)

== [[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, Review)
* 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 (80%, Jeff Williams, Needs a new owner, Review)
* jChains (www.jchains.org) - (0%, TD)

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

==[[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 (0%, TD)

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

[[Category:OWASP Java Project]]

OWASP Java Table of Contents

2007-03-05T19:45:15Z

Rohyt: /* Session Management */

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.

(50% ?, Claire McDonough, Ranjita Shankar Iyer, Rohyt Belani to update, Review)
* Struts
* Turbine
* JFS (MyFaces)
* Tapestry
* Webwork
* Cocoon
* Tiles
* SiteMesh
* Spring

===[[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%, Shyaam Sundar, Review)
* Bytecode verifier (0%, Shyaam Sundar, Review)
* The Security Manager and security.policy file (0%, Shyaam Sundar, Review)

===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, Review)
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Review)

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

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

==== [[XPATH Injection]] ====
As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing XPATH injection.
* Overview (0%, TD)
* Prevention (0%, TD)

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting (0%, TD)
* Command injection - Runtime.getRuntime().exec() (0%, TD)

=== Authentication===
* Storing credentials - (0%, Adrian San Juan, Review)
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, Review)
* [[SSL Best Practices]] - (20%, Philippe Curmin, Review)
* [[Using JCaptcha]] - (100%, Dave Ferguson, Review)
* Container-managed authentication with Realms
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Reviewed by Pierre Parrend, Dave to act on comments)
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, Review)
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, Review)
* [[Password length & complexity]] - (0%, 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 (0%, TD)
* Session Timeout (0%, TD)
* Absolute Timeout (0%, TD)
* [[Session Fixation in Java]] [[User:Rohyt|Rohyt]]
* Terminating sessions (0%, TD)
** Terminating sessions when the browser window is closed

===Authorization===
* Declarative v/s Programmatic (0%, 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] (80%, 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] (80%, Joe Prasanna Kumar - To be reviewed)
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions Random number generation] (80%, Joe Prasanna Kumar - To be reviewed)

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

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

=== 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)

== [[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, Review)
* 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 (80%, Jeff Williams, Needs a new owner, Review)
* jChains (www.jchains.org) - (0%, TD)

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

==[[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 (0%, TD)

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

[[Category:OWASP Java Project]]

Session Fixation in Java

2007-03-05T19:44:19Z

Rohyt: New page: ==Overview of Session Fixation== A detailed overview on session fixation can be found here: Session Fixation ==Countermeasures== * Session ID should be regenerated after login, and ...

==Overview of Session Fixation==

A detailed overview on session fixation can be found here: [[Session Fixation]]

==Countermeasures==

* Session ID should be regenerated after login, and switching in and out of SSL

session.invalidate();
session=request.getSession(true);

* Disable URL rewriting

OWASP Java Table of Contents

2007-03-05T19:31:48Z

Rohyt: /* Session Management */

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.

(50% ?, Claire McDonough, Ranjita Shankar Iyer, Rohyt Belani to update, Review)
* Struts
* Turbine
* JFS (MyFaces)
* Tapestry
* Webwork
* Cocoon
* Tiles
* SiteMesh
* Spring

===[[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%, Shyaam Sundar, Review)
* Bytecode verifier (0%, Shyaam Sundar, Review)
* The Security Manager and security.policy file (0%, Shyaam Sundar, Review)

===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, Review)
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Review)

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

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

==== [[XPATH Injection]] ====
As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing XPATH injection.
* Overview (0%, TD)
* Prevention (0%, TD)

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting (0%, TD)
* Command injection - Runtime.getRuntime().exec() (0%, TD)

=== Authentication===
* Storing credentials - (0%, Adrian San Juan, Review)
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, Review)
* [[SSL Best Practices]] - (20%, Philippe Curmin, Review)
* [[Using JCaptcha]] - (100%, Dave Ferguson, Review)
* Container-managed authentication with Realms
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Reviewed by Pierre Parrend, Dave to act on comments)
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, Review)
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, Review)
* [[Password length & complexity]] - (0%, 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 (0%, TD)
* Session Timeout (0%, TD)
* Absolute Timeout (0%, TD)
* [[Session Fixation in Java]]
* Terminating sessions (0%, TD)
** Terminating sessions when the browser window is closed

===Authorization===
* Declarative v/s Programmatic (0%, 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] (80%, 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] (80%, Joe Prasanna Kumar - To be reviewed)
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions Random number generation] (80%, Joe Prasanna Kumar - To be reviewed)

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

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

=== 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)

== [[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, Review)
* 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 (80%, Jeff Williams, Needs a new owner, Review)
* jChains (www.jchains.org) - (0%, TD)

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

==[[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 (0%, TD)

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

[[Category:OWASP Java Project]]

OWASP Java Table of Contents

2007-03-05T19:28:27Z

Rohyt: /* Session Management */

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.

(50% ?, Claire McDonough, Ranjita Shankar Iyer, Rohyt Belani to update, Review)
* Struts
* Turbine
* JFS (MyFaces)
* Tapestry
* Webwork
* Cocoon
* Tiles
* SiteMesh
* Spring

===[[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%, Shyaam Sundar, Review)
* Bytecode verifier (0%, Shyaam Sundar, Review)
* The Security Manager and security.policy file (0%, Shyaam Sundar, Review)

===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, Review)
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Review)

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

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

==== [[XPATH Injection]] ====
As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing XPATH injection.
* Overview (0%, TD)
* Prevention (0%, TD)

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting (0%, TD)
* Command injection - Runtime.getRuntime().exec() (0%, TD)

=== Authentication===
* Storing credentials - (0%, Adrian San Juan, Review)
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, Review)
* [[SSL Best Practices]] - (20%, Philippe Curmin, Review)
* [[Using JCaptcha]] - (100%, Dave Ferguson, Review)
* Container-managed authentication with Realms
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Reviewed by Pierre Parrend, Dave to act on comments)
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, Review)
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, Review)
* [[Password length & complexity]] - (0%, 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 (0%, TD)
* Session Timeout (0%, TD)
* Absolute Timeout (0%, TD)
* [[Session Fixation]]
* Terminating sessions (0%, TD)
** Terminating sessions when the browser window is closed

===Authorization===
* Declarative v/s Programmatic (0%, 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] (80%, 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] (80%, Joe Prasanna Kumar - To be reviewed)
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions Random number generation] (80%, Joe Prasanna Kumar - To be reviewed)

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

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

=== 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)

== [[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, Review)
* 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 (80%, Jeff Williams, Needs a new owner, Review)
* jChains (www.jchains.org) - (0%, TD)

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

==[[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 (0%, TD)

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

[[Category:OWASP Java Project]]

OWASP Java Table of Contents

2007-03-05T19:28:13Z

Rohyt: /* Session Management */

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.

(50% ?, Claire McDonough, Ranjita Shankar Iyer, Rohyt Belani to update, Review)
* Struts
* Turbine
* JFS (MyFaces)
* Tapestry
* Webwork
* Cocoon
* Tiles
* SiteMesh
* Spring

===[[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%, Shyaam Sundar, Review)
* Bytecode verifier (0%, Shyaam Sundar, Review)
* The Security Manager and security.policy file (0%, Shyaam Sundar, Review)

===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, Review)
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Review)

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

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

==== [[XPATH Injection]] ====
As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing XPATH injection.
* Overview (0%, TD)
* Prevention (0%, TD)

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting (0%, TD)
* Command injection - Runtime.getRuntime().exec() (0%, TD)

=== Authentication===
* Storing credentials - (0%, Adrian San Juan, Review)
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, Review)
* [[SSL Best Practices]] - (20%, Philippe Curmin, Review)
* [[Using JCaptcha]] - (100%, Dave Ferguson, Review)
* Container-managed authentication with Realms
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Reviewed by Pierre Parrend, Dave to act on comments)
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, Review)
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, Review)
* [[Password length & complexity]] - (0%, 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 (0%, TD)
* Session Timeout (0%, TD)
* Absolute Timeout (0%, TD)
[[Session Fixation]]
* Terminating sessions (0%, TD)
** Terminating sessions when the browser window is closed

===Authorization===
* Declarative v/s Programmatic (0%, 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] (80%, 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] (80%, Joe Prasanna Kumar - To be reviewed)
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions Random number generation] (80%, Joe Prasanna Kumar - To be reviewed)

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

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

=== 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)

== [[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, Review)
* 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 (80%, Jeff Williams, Needs a new owner, Review)
* jChains (www.jchains.org) - (0%, TD)

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

==[[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 (0%, TD)

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

[[Category:OWASP Java Project]]

Talk:OWASP Java Project Roadmap

2006-06-17T20:03:44Z

Rohyt: /* Java Security Basics */

==J2EE Security for Architects==

=== Risk Analysis===
To my mind, Risk Analysis is a general exercise that will apply equaly to all apps irrespective of the language used to implement the app. So would say that this belongs in the Guide rather than the Java project, unless you have some ideas on how to make this Java specific? --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
I agree -- suggest deleting this section [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

Agreed - Rohyt

===Mapping Regulatory requirements to technical requirements===
Same as above. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
I agree -- suggest deleting this section [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

Agreed - Rohyt

===Design considerations===
This is quite general. Shall we narrow it down to the architectural issues that should be considered for each of the popular architectures such as:
* Architectural considerations
** EJB Middle tier
** Web Services Middle tier
** Spring Middle tier
--[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)

===Frameworks you should be aware of (e.g. struts, stinger, etc.)===
There are many frameworks out there, so I'd suggest we keep this down to frameworks that specifically offer security functionality such as:
* Acegi
* Commons validator
* jGuard
* Stinger seems to be parked for a while now, is this correct Jeff?
** Stinger is
** CVS HEAD is in a functional state; needs work on docs and new features [[User:Roman|Roman]] 00:15, 13 June 2006 (EDT)
Most web tier frameworks will prevent XSS attacks, so listing them all in this section is a bit verbose, would prefer to see them listed in the XSS section. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)

I think Struts should be covered too - Rohyt

==J2EE Security for Developers==

===Java Security Basics===
* Class Loading
* Bytecode verifier
* The Security Manager and security.policy file
I suggest we do something short here for web developers, and wait on client side apps for now [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

I agree --[[User:Stephendv|Stephendv]] 09:48, 12 June 2006 (EDT)

I agree - the initial focus should be on web apps. We can address security issues pertinent to thick-client apps in the next phase - Rohyt

===Input Validation===
* Overview

==== SQL Injection====
* Overview
* Prevention
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis
** Spring JDBC
** EJB 3.0?
** JDO?

====XSS====
* Overview
* Prevention
** White Listing
** Manual HTML Encoding
** Preventing XSS in popular Web Frameworks
*** JSP/JSTL
*** Struts
*** Spring MVC
*** Java Server Faces
*** WebWork?
*** Wicket?
*** Tapestry?
* <s>Misc I/P Validation Attacks (e.g. HTTP Response Splitting)</s> - Moved this out to a separate section below. --[[User:Stephendv|Stephendv]] 08:41, 12 June 2006 (EDT)
* <s>Using struts</s> Would recommend we cover a number of frameworks as mentioned above. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
* CSRF attack

==== LDAP Injection ====
* Overview
* Prevention

==== XPATH Injection ====
* Overview
* Prevention

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting
* Command injection - Runtime.getRuntime().exec()

=== Authentication===
* Storing credentials
* Hashing
* SSL Best Practices
* CAPTCHA systems (jcaptcha?)
* Container-managed authentication with Realms
* JAAS Authentication
* Password length & complexity

===Session Management===
* Logout
* Session Timeout
* Absolute Timeout
* Session Fixation
* Terminating sessions
** Terminating sessions when the browser window is closed

===Authorization===
* In presentation layer
* In business logic
* In data layer
* Declarative v/s Programmatic
* web.xml configuration
* [[Forced browsing]]
* JAAS
* EJB Authorization
* Acegi?
* JACC
* Check horizontal privilege

=== Encryption===
* JCE
* Storing db secrets
* Encrypting JDBC connections
* JSSE
* Random number generation

=== Error Handling & Logging===
* Output Validation
* Custom Errors
* Logging - why log? what to log? log4j, etc.
* Exception handling techniques
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks
** Servlet spec - web.xml
** JSP errorPage

- Web application forensics and how it differs from conventional forensics. This will emphasize the importance of appropriate exception handling and logging - Rohyt

=== Web Services Security ===
* SAML
* WS-Security
* ...?

=== Code Analysis Tools ===
* FindBugs
** Creating custom rules
* PMD
** Creating custom rules
* JLint
* Jmetrics

== J2EE Security For Deployers ==

=== Securing Popular J2EE Servers ===
* Securing Tomcat
* Securing JBoss
* Securing WebLogic
* Securing WebSphere
* Securing x...
Would be nice to include an example secure by default configuration file for each server that has additional comments in it which expands on the security repurcussions of the various sections.

=== Defining a Java Security Policy ===
* Jeff's tool? --[[User:Stephendv|Stephendv]] 08:37, 12 June 2006 (EDT)
* jChains (www.jchains.org)

=== Protecting Binaries ===
- Discuss Bytecode Manipulation Tools and Techniques - Rohyt
* Bytecode obfuscation
* Convert bytecode to native machine code
* jarsigner

Talk:OWASP Java Project Roadmap

2006-06-16T14:34:40Z

Rohyt: /* Frameworks you should be aware of (e.g. struts, stinger, etc.) */

==J2EE Security for Architects==

=== Risk Analysis===
To my mind, Risk Analysis is a general exercise that will apply equaly to all apps irrespective of the language used to implement the app. So would say that this belongs in the Guide rather than the Java project, unless you have some ideas on how to make this Java specific? --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
I agree -- suggest deleting this section [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

Agreed - Rohyt

===Mapping Regulatory requirements to technical requirements===
Same as above. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
I agree -- suggest deleting this section [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

Agreed - Rohyt

===Design considerations===
This is quite general. Shall we narrow it down to the architectural issues that should be considered for each of the popular architectures such as:
* Architectural considerations
** EJB Middle tier
** Web Services Middle tier
** Spring Middle tier
--[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)

===Frameworks you should be aware of (e.g. struts, stinger, etc.)===
There are many frameworks out there, so I'd suggest we keep this down to frameworks that specifically offer security functionality such as:
* Acegi
* Commons validator
* jGuard
* Stinger seems to be parked for a while now, is this correct Jeff?
** Stinger is
** CVS HEAD is in a functional state; needs work on docs and new features [[User:Roman|Roman]] 00:15, 13 June 2006 (EDT)
Most web tier frameworks will prevent XSS attacks, so listing them all in this section is a bit verbose, would prefer to see them listed in the XSS section. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)

I think Struts should be covered too - Rohyt

==J2EE Security for Developers==

===Java Security Basics===
* Class Loading
* Bytecode verifier
* The Security Manager and security.policy file
I suggest we do something short here for web developers, and wait on client side apps for now [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

I agree --[[User:Stephendv|Stephendv]] 09:48, 12 June 2006 (EDT)

I agree - the initial focus should be on web app appss. We can address security issues pertinent to thick-client apps in the next phase - Rohyt

===Input Validation===
* Overview

==== SQL Injection====
* Overview
* Prevention
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis
** Spring JDBC
** EJB 3.0?
** JDO?

====XSS====
* Overview
* Prevention
** White Listing
** Manual HTML Encoding
** Preventing XSS in popular Web Frameworks
*** JSP/JSTL
*** Struts
*** Spring MVC
*** Java Server Faces
*** WebWork?
*** Wicket?
*** Tapestry?
* <s>Misc I/P Validation Attacks (e.g. HTTP Response Splitting)</s> - Moved this out to a separate section below. --[[User:Stephendv|Stephendv]] 08:41, 12 June 2006 (EDT)
* <s>Using struts</s> Would recommend we cover a number of frameworks as mentioned above. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
* CSRF attack

==== LDAP Injection ====
* Overview
* Prevention

==== XPATH Injection ====
* Overview
* Prevention

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting
* Command injection - Runtime.getRuntime().exec()

=== Authentication===
* Storing credentials
* Hashing
* SSL Best Practices
* CAPTCHA systems (jcaptcha?)
* Container-managed authentication with Realms
* JAAS Authentication
* Password length & complexity

===Session Management===
* Logout
* Session Timeout
* Absolute Timeout
* Session Fixation
* Terminating sessions
** Terminating sessions when the browser window is closed

===Authorization===
* In presentation layer
* In business logic
* In data layer
* Declarative v/s Programmatic
* web.xml configuration
* [[Forced browsing]]
* JAAS
* EJB Authorization
* Acegi?
* JACC
* Check horizontal privilege

=== Encryption===
* JCE
* Storing db secrets
* Encrypting JDBC connections
* JSSE
* Random number generation

=== Error Handling & Logging===
* Output Validation
* Custom Errors
* Logging - why log? what to log? log4j, etc.
* Exception handling techniques
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks
** Servlet spec - web.xml
** JSP errorPage

- Web application forensics and how it differs from conventional forensics. This will emphasize the importance of appropriate exception handling and logging - Rohyt

=== Web Services Security ===
* SAML
* WS-Security
* ...?

=== Code Analysis Tools ===
* FindBugs
** Creating custom rules
* PMD
** Creating custom rules
* JLint
* Jmetrics

== J2EE Security For Deployers ==

=== Securing Popular J2EE Servers ===
* Securing Tomcat
* Securing JBoss
* Securing WebLogic
* Securing WebSphere
* Securing x...
Would be nice to include an example secure by default configuration file for each server that has additional comments in it which expands on the security repurcussions of the various sections.

=== Defining a Java Security Policy ===
* Jeff's tool? --[[User:Stephendv|Stephendv]] 08:37, 12 June 2006 (EDT)
* jChains (www.jchains.org)

=== Protecting Binaries ===
- Discuss Bytecode Manipulation Tools and Techniques - Rohyt
* Bytecode obfuscation
* Convert bytecode to native machine code
* jarsigner

Talk:OWASP Java Project Roadmap

2006-06-16T14:33:46Z

Rohyt: /* Protecting Binaries */

==J2EE Security for Architects==

=== Risk Analysis===
To my mind, Risk Analysis is a general exercise that will apply equaly to all apps irrespective of the language used to implement the app. So would say that this belongs in the Guide rather than the Java project, unless you have some ideas on how to make this Java specific? --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
I agree -- suggest deleting this section [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

Agreed - Rohyt

===Mapping Regulatory requirements to technical requirements===
Same as above. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
I agree -- suggest deleting this section [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

Agreed - Rohyt

===Design considerations===
This is quite general. Shall we narrow it down to the architectural issues that should be considered for each of the popular architectures such as:
* Architectural considerations
** EJB Middle tier
** Web Services Middle tier
** Spring Middle tier
--[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)

===Frameworks you should be aware of (e.g. struts, stinger, etc.)===
There are many frameworks out there, so I'd suggest we keep this down to frameworks that specifically offer security functionality such as:
* Acegi
* Commons validator
* jGuard
* Stinger seems to be parked for a while now, is this correct Jeff?
** Stinger is
** CVS HEAD is in a functional state; needs work on docs and new features [[User:Roman|Roman]] 00:15, 13 June 2006 (EDT)
Most web tier frameworks will prevent XSS attacks, so listing them all in this section is a bit verbose, would prefer to see them listed in the XSS section. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)

I think Struts should be covered too given the extensive input validation functionality it supports - Rohyt

==J2EE Security for Developers==

===Java Security Basics===
* Class Loading
* Bytecode verifier
* The Security Manager and security.policy file
I suggest we do something short here for web developers, and wait on client side apps for now [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

I agree --[[User:Stephendv|Stephendv]] 09:48, 12 June 2006 (EDT)

I agree - the initial focus should be on web app appss. We can address security issues pertinent to thick-client apps in the next phase - Rohyt

===Input Validation===
* Overview

==== SQL Injection====
* Overview
* Prevention
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis
** Spring JDBC
** EJB 3.0?
** JDO?

====XSS====
* Overview
* Prevention
** White Listing
** Manual HTML Encoding
** Preventing XSS in popular Web Frameworks
*** JSP/JSTL
*** Struts
*** Spring MVC
*** Java Server Faces
*** WebWork?
*** Wicket?
*** Tapestry?
* <s>Misc I/P Validation Attacks (e.g. HTTP Response Splitting)</s> - Moved this out to a separate section below. --[[User:Stephendv|Stephendv]] 08:41, 12 June 2006 (EDT)
* <s>Using struts</s> Would recommend we cover a number of frameworks as mentioned above. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
* CSRF attack

==== LDAP Injection ====
* Overview
* Prevention

==== XPATH Injection ====
* Overview
* Prevention

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting
* Command injection - Runtime.getRuntime().exec()

=== Authentication===
* Storing credentials
* Hashing
* SSL Best Practices
* CAPTCHA systems (jcaptcha?)
* Container-managed authentication with Realms
* JAAS Authentication
* Password length & complexity

===Session Management===
* Logout
* Session Timeout
* Absolute Timeout
* Session Fixation
* Terminating sessions
** Terminating sessions when the browser window is closed

===Authorization===
* In presentation layer
* In business logic
* In data layer
* Declarative v/s Programmatic
* web.xml configuration
* [[Forced browsing]]
* JAAS
* EJB Authorization
* Acegi?
* JACC
* Check horizontal privilege

=== Encryption===
* JCE
* Storing db secrets
* Encrypting JDBC connections
* JSSE
* Random number generation

=== Error Handling & Logging===
* Output Validation
* Custom Errors
* Logging - why log? what to log? log4j, etc.
* Exception handling techniques
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks
** Servlet spec - web.xml
** JSP errorPage

- Web application forensics and how it differs from conventional forensics. This will emphasize the importance of appropriate exception handling and logging - Rohyt

=== Web Services Security ===
* SAML
* WS-Security
* ...?

=== Code Analysis Tools ===
* FindBugs
** Creating custom rules
* PMD
** Creating custom rules
* JLint
* Jmetrics

== J2EE Security For Deployers ==

=== Securing Popular J2EE Servers ===
* Securing Tomcat
* Securing JBoss
* Securing WebLogic
* Securing WebSphere
* Securing x...
Would be nice to include an example secure by default configuration file for each server that has additional comments in it which expands on the security repurcussions of the various sections.

=== Defining a Java Security Policy ===
* Jeff's tool? --[[User:Stephendv|Stephendv]] 08:37, 12 June 2006 (EDT)
* jChains (www.jchains.org)

=== Protecting Binaries ===
- Discuss Bytecode Manipulation Tools and Techniques - Rohyt
* Bytecode obfuscation
* Convert bytecode to native machine code
* jarsigner

Talk:OWASP Java Project Roadmap

2006-06-16T14:32:12Z

Rohyt: /* Java Security Basics */

==J2EE Security for Architects==

=== Risk Analysis===
To my mind, Risk Analysis is a general exercise that will apply equaly to all apps irrespective of the language used to implement the app. So would say that this belongs in the Guide rather than the Java project, unless you have some ideas on how to make this Java specific? --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
I agree -- suggest deleting this section [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

Agreed - Rohyt

===Mapping Regulatory requirements to technical requirements===
Same as above. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
I agree -- suggest deleting this section [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

Agreed - Rohyt

===Design considerations===
This is quite general. Shall we narrow it down to the architectural issues that should be considered for each of the popular architectures such as:
* Architectural considerations
** EJB Middle tier
** Web Services Middle tier
** Spring Middle tier
--[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)

===Frameworks you should be aware of (e.g. struts, stinger, etc.)===
There are many frameworks out there, so I'd suggest we keep this down to frameworks that specifically offer security functionality such as:
* Acegi
* Commons validator
* jGuard
* Stinger seems to be parked for a while now, is this correct Jeff?
** Stinger is
** CVS HEAD is in a functional state; needs work on docs and new features [[User:Roman|Roman]] 00:15, 13 June 2006 (EDT)
Most web tier frameworks will prevent XSS attacks, so listing them all in this section is a bit verbose, would prefer to see them listed in the XSS section. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)

I think Struts should be covered too given the extensive input validation functionality it supports - Rohyt

==J2EE Security for Developers==

===Java Security Basics===
* Class Loading
* Bytecode verifier
* The Security Manager and security.policy file
I suggest we do something short here for web developers, and wait on client side apps for now [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

I agree --[[User:Stephendv|Stephendv]] 09:48, 12 June 2006 (EDT)

I agree - the initial focus should be on web app appss. We can address security issues pertinent to thick-client apps in the next phase - Rohyt

===Input Validation===
* Overview

==== SQL Injection====
* Overview
* Prevention
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis
** Spring JDBC
** EJB 3.0?
** JDO?

====XSS====
* Overview
* Prevention
** White Listing
** Manual HTML Encoding
** Preventing XSS in popular Web Frameworks
*** JSP/JSTL
*** Struts
*** Spring MVC
*** Java Server Faces
*** WebWork?
*** Wicket?
*** Tapestry?
* <s>Misc I/P Validation Attacks (e.g. HTTP Response Splitting)</s> - Moved this out to a separate section below. --[[User:Stephendv|Stephendv]] 08:41, 12 June 2006 (EDT)
* <s>Using struts</s> Would recommend we cover a number of frameworks as mentioned above. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
* CSRF attack

==== LDAP Injection ====
* Overview
* Prevention

==== XPATH Injection ====
* Overview
* Prevention

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting
* Command injection - Runtime.getRuntime().exec()

=== Authentication===
* Storing credentials
* Hashing
* SSL Best Practices
* CAPTCHA systems (jcaptcha?)
* Container-managed authentication with Realms
* JAAS Authentication
* Password length & complexity

===Session Management===
* Logout
* Session Timeout
* Absolute Timeout
* Session Fixation
* Terminating sessions
** Terminating sessions when the browser window is closed

===Authorization===
* In presentation layer
* In business logic
* In data layer
* Declarative v/s Programmatic
* web.xml configuration
* [[Forced browsing]]
* JAAS
* EJB Authorization
* Acegi?
* JACC
* Check horizontal privilege

=== Encryption===
* JCE
* Storing db secrets
* Encrypting JDBC connections
* JSSE
* Random number generation

=== Error Handling & Logging===
* Output Validation
* Custom Errors
* Logging - why log? what to log? log4j, etc.
* Exception handling techniques
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks
** Servlet spec - web.xml
** JSP errorPage

- Web application forensics and how it differs from conventional forensics. This will emphasize the importance of appropriate exception handling and logging - Rohyt

=== Web Services Security ===
* SAML
* WS-Security
* ...?

=== Code Analysis Tools ===
* FindBugs
** Creating custom rules
* PMD
** Creating custom rules
* JLint
* Jmetrics

== J2EE Security For Deployers ==

=== Securing Popular J2EE Servers ===
* Securing Tomcat
* Securing JBoss
* Securing WebLogic
* Securing WebSphere
* Securing x...
Would be nice to include an example secure by default configuration file for each server that has additional comments in it which expands on the security repurcussions of the various sections.

=== Defining a Java Security Policy ===
* Jeff's tool? --[[User:Stephendv|Stephendv]] 08:37, 12 June 2006 (EDT)
* jChains (www.jchains.org)

=== Protecting Binaries ===
* Bytecode obfuscation
* Convert bytecode to native machine code
* jarsigner

Talk:OWASP Java Project Roadmap

2006-06-16T14:30:48Z

Rohyt: /* Error Handling & Logging */

==J2EE Security for Architects==

=== Risk Analysis===
To my mind, Risk Analysis is a general exercise that will apply equaly to all apps irrespective of the language used to implement the app. So would say that this belongs in the Guide rather than the Java project, unless you have some ideas on how to make this Java specific? --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
I agree -- suggest deleting this section [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

Agreed - Rohyt

===Mapping Regulatory requirements to technical requirements===
Same as above. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
I agree -- suggest deleting this section [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

Agreed - Rohyt

===Design considerations===
This is quite general. Shall we narrow it down to the architectural issues that should be considered for each of the popular architectures such as:
* Architectural considerations
** EJB Middle tier
** Web Services Middle tier
** Spring Middle tier
--[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)

===Frameworks you should be aware of (e.g. struts, stinger, etc.)===
There are many frameworks out there, so I'd suggest we keep this down to frameworks that specifically offer security functionality such as:
* Acegi
* Commons validator
* jGuard
* Stinger seems to be parked for a while now, is this correct Jeff?
** Stinger is
** CVS HEAD is in a functional state; needs work on docs and new features [[User:Roman|Roman]] 00:15, 13 June 2006 (EDT)
Most web tier frameworks will prevent XSS attacks, so listing them all in this section is a bit verbose, would prefer to see them listed in the XSS section. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)

I think Struts should be covered too given the extensive input validation functionality it supports - Rohyt

==J2EE Security for Developers==

===Java Security Basics===
* Class Loading
* Bytecode verifier
* The Security Manager and security.policy file
I suggest we do something short here for web developers, and wait on client side apps for now [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

I agree --[[User:Stephendv|Stephendv]] 09:48, 12 June 2006 (EDT)

I agree - the initial focus should be web app developers. We can then address security issues pertinent to thick-client apps - Rohyt

===Input Validation===
* Overview

==== SQL Injection====
* Overview
* Prevention
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis
** Spring JDBC
** EJB 3.0?
** JDO?

====XSS====
* Overview
* Prevention
** White Listing
** Manual HTML Encoding
** Preventing XSS in popular Web Frameworks
*** JSP/JSTL
*** Struts
*** Spring MVC
*** Java Server Faces
*** WebWork?
*** Wicket?
*** Tapestry?
* <s>Misc I/P Validation Attacks (e.g. HTTP Response Splitting)</s> - Moved this out to a separate section below. --[[User:Stephendv|Stephendv]] 08:41, 12 June 2006 (EDT)
* <s>Using struts</s> Would recommend we cover a number of frameworks as mentioned above. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
* CSRF attack

==== LDAP Injection ====
* Overview
* Prevention

==== XPATH Injection ====
* Overview
* Prevention

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting
* Command injection - Runtime.getRuntime().exec()

=== Authentication===
* Storing credentials
* Hashing
* SSL Best Practices
* CAPTCHA systems (jcaptcha?)
* Container-managed authentication with Realms
* JAAS Authentication
* Password length & complexity

===Session Management===
* Logout
* Session Timeout
* Absolute Timeout
* Session Fixation
* Terminating sessions
** Terminating sessions when the browser window is closed

===Authorization===
* In presentation layer
* In business logic
* In data layer
* Declarative v/s Programmatic
* web.xml configuration
* [[Forced browsing]]
* JAAS
* EJB Authorization
* Acegi?
* JACC
* Check horizontal privilege

=== Encryption===
* JCE
* Storing db secrets
* Encrypting JDBC connections
* JSSE
* Random number generation

=== Error Handling & Logging===
* Output Validation
* Custom Errors
* Logging - why log? what to log? log4j, etc.
* Exception handling techniques
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks
** Servlet spec - web.xml
** JSP errorPage

- Web application forensics and how it differs from conventional forensics. This will emphasize the importance of appropriate exception handling and logging - Rohyt

=== Web Services Security ===
* SAML
* WS-Security
* ...?

=== Code Analysis Tools ===
* FindBugs
** Creating custom rules
* PMD
** Creating custom rules
* JLint
* Jmetrics

== J2EE Security For Deployers ==

=== Securing Popular J2EE Servers ===
* Securing Tomcat
* Securing JBoss
* Securing WebLogic
* Securing WebSphere
* Securing x...
Would be nice to include an example secure by default configuration file for each server that has additional comments in it which expands on the security repurcussions of the various sections.

=== Defining a Java Security Policy ===
* Jeff's tool? --[[User:Stephendv|Stephendv]] 08:37, 12 June 2006 (EDT)
* jChains (www.jchains.org)

=== Protecting Binaries ===
* Bytecode obfuscation
* Convert bytecode to native machine code
* jarsigner

Talk:OWASP Java Project Roadmap

2006-06-16T14:29:48Z

Rohyt: /* Error Handling & Logging */

==J2EE Security for Architects==

=== Risk Analysis===
To my mind, Risk Analysis is a general exercise that will apply equaly to all apps irrespective of the language used to implement the app. So would say that this belongs in the Guide rather than the Java project, unless you have some ideas on how to make this Java specific? --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
I agree -- suggest deleting this section [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

Agreed - Rohyt

===Mapping Regulatory requirements to technical requirements===
Same as above. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
I agree -- suggest deleting this section [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

Agreed - Rohyt

===Design considerations===
This is quite general. Shall we narrow it down to the architectural issues that should be considered for each of the popular architectures such as:
* Architectural considerations
** EJB Middle tier
** Web Services Middle tier
** Spring Middle tier
--[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)

===Frameworks you should be aware of (e.g. struts, stinger, etc.)===
There are many frameworks out there, so I'd suggest we keep this down to frameworks that specifically offer security functionality such as:
* Acegi
* Commons validator
* jGuard
* Stinger seems to be parked for a while now, is this correct Jeff?
** Stinger is
** CVS HEAD is in a functional state; needs work on docs and new features [[User:Roman|Roman]] 00:15, 13 June 2006 (EDT)
Most web tier frameworks will prevent XSS attacks, so listing them all in this section is a bit verbose, would prefer to see them listed in the XSS section. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)

I think Struts should be covered too given the extensive input validation functionality it supports - Rohyt

==J2EE Security for Developers==

===Java Security Basics===
* Class Loading
* Bytecode verifier
* The Security Manager and security.policy file
I suggest we do something short here for web developers, and wait on client side apps for now [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

I agree --[[User:Stephendv|Stephendv]] 09:48, 12 June 2006 (EDT)

I agree - the initial focus should be web app developers. We can then address security issues pertinent to thick-client apps - Rohyt

===Input Validation===
* Overview

==== SQL Injection====
* Overview
* Prevention
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis
** Spring JDBC
** EJB 3.0?
** JDO?

====XSS====
* Overview
* Prevention
** White Listing
** Manual HTML Encoding
** Preventing XSS in popular Web Frameworks
*** JSP/JSTL
*** Struts
*** Spring MVC
*** Java Server Faces
*** WebWork?
*** Wicket?
*** Tapestry?
* <s>Misc I/P Validation Attacks (e.g. HTTP Response Splitting)</s> - Moved this out to a separate section below. --[[User:Stephendv|Stephendv]] 08:41, 12 June 2006 (EDT)
* <s>Using struts</s> Would recommend we cover a number of frameworks as mentioned above. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
* CSRF attack

==== LDAP Injection ====
* Overview
* Prevention

==== XPATH Injection ====
* Overview
* Prevention

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting
* Command injection - Runtime.getRuntime().exec()

=== Authentication===
* Storing credentials
* Hashing
* SSL Best Practices
* CAPTCHA systems (jcaptcha?)
* Container-managed authentication with Realms
* JAAS Authentication
* Password length & complexity

===Session Management===
* Logout
* Session Timeout
* Absolute Timeout
* Session Fixation
* Terminating sessions
** Terminating sessions when the browser window is closed

===Authorization===
* In presentation layer
* In business logic
* In data layer
* Declarative v/s Programmatic
* web.xml configuration
* [[Forced browsing]]
* JAAS
* EJB Authorization
* Acegi?
* JACC
* Check horizontal privilege

=== Encryption===
* JCE
* Storing db secrets
* Encrypting JDBC connections
* JSSE
* Random number generation

=== Error Handling & Logging===
* Output Validation
* Custom Errors
* Logging - why log? what to log? log4j, etc.
* Exception handling techniques
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks
** Servlet spec - web.xml
** JSP errorPage

Talk about web application forensics and how it differs from conventional forensics

=== Web Services Security ===
* SAML
* WS-Security
* ...?

=== Code Analysis Tools ===
* FindBugs
** Creating custom rules
* PMD
** Creating custom rules
* JLint
* Jmetrics

== J2EE Security For Deployers ==

=== Securing Popular J2EE Servers ===
* Securing Tomcat
* Securing JBoss
* Securing WebLogic
* Securing WebSphere
* Securing x...
Would be nice to include an example secure by default configuration file for each server that has additional comments in it which expands on the security repurcussions of the various sections.

=== Defining a Java Security Policy ===
* Jeff's tool? --[[User:Stephendv|Stephendv]] 08:37, 12 June 2006 (EDT)
* jChains (www.jchains.org)

=== Protecting Binaries ===
* Bytecode obfuscation
* Convert bytecode to native machine code
* jarsigner

Talk:OWASP Java Project Roadmap

2006-06-16T14:27:47Z

Rohyt: /* Java Security Basics */

==J2EE Security for Architects==

=== Risk Analysis===
To my mind, Risk Analysis is a general exercise that will apply equaly to all apps irrespective of the language used to implement the app. So would say that this belongs in the Guide rather than the Java project, unless you have some ideas on how to make this Java specific? --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
I agree -- suggest deleting this section [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

Agreed - Rohyt

===Mapping Regulatory requirements to technical requirements===
Same as above. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
I agree -- suggest deleting this section [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

Agreed - Rohyt

===Design considerations===
This is quite general. Shall we narrow it down to the architectural issues that should be considered for each of the popular architectures such as:
* Architectural considerations
** EJB Middle tier
** Web Services Middle tier
** Spring Middle tier
--[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)

===Frameworks you should be aware of (e.g. struts, stinger, etc.)===
There are many frameworks out there, so I'd suggest we keep this down to frameworks that specifically offer security functionality such as:
* Acegi
* Commons validator
* jGuard
* Stinger seems to be parked for a while now, is this correct Jeff?
** Stinger is
** CVS HEAD is in a functional state; needs work on docs and new features [[User:Roman|Roman]] 00:15, 13 June 2006 (EDT)
Most web tier frameworks will prevent XSS attacks, so listing them all in this section is a bit verbose, would prefer to see them listed in the XSS section. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)

I think Struts should be covered too given the extensive input validation functionality it supports - Rohyt

==J2EE Security for Developers==

===Java Security Basics===
* Class Loading
* Bytecode verifier
* The Security Manager and security.policy file
I suggest we do something short here for web developers, and wait on client side apps for now [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

I agree --[[User:Stephendv|Stephendv]] 09:48, 12 June 2006 (EDT)

I agree - the initial focus should be web app developers. We can then address security issues pertinent to thick-client apps - Rohyt

===Input Validation===
* Overview

==== SQL Injection====
* Overview
* Prevention
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis
** Spring JDBC
** EJB 3.0?
** JDO?

====XSS====
* Overview
* Prevention
** White Listing
** Manual HTML Encoding
** Preventing XSS in popular Web Frameworks
*** JSP/JSTL
*** Struts
*** Spring MVC
*** Java Server Faces
*** WebWork?
*** Wicket?
*** Tapestry?
* <s>Misc I/P Validation Attacks (e.g. HTTP Response Splitting)</s> - Moved this out to a separate section below. --[[User:Stephendv|Stephendv]] 08:41, 12 June 2006 (EDT)
* <s>Using struts</s> Would recommend we cover a number of frameworks as mentioned above. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
* CSRF attack

==== LDAP Injection ====
* Overview
* Prevention

==== XPATH Injection ====
* Overview
* Prevention

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting
* Command injection - Runtime.getRuntime().exec()

=== Authentication===
* Storing credentials
* Hashing
* SSL Best Practices
* CAPTCHA systems (jcaptcha?)
* Container-managed authentication with Realms
* JAAS Authentication
* Password length & complexity

===Session Management===
* Logout
* Session Timeout
* Absolute Timeout
* Session Fixation
* Terminating sessions
** Terminating sessions when the browser window is closed

===Authorization===
* In presentation layer
* In business logic
* In data layer
* Declarative v/s Programmatic
* web.xml configuration
* [[Forced browsing]]
* JAAS
* EJB Authorization
* Acegi?
* JACC
* Check horizontal privilege

=== Encryption===
* JCE
* Storing db secrets
* Encrypting JDBC connections
* JSSE
* Random number generation

=== Error Handling & Logging===
* Output Validation
* Custom Errors
* Logging - why log? what to log? log4j, etc.
* Exception handling techniques
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks
** Servlet spec - web.xml
** JSP errorPage

=== Web Services Security ===
* SAML
* WS-Security
* ...?

=== Code Analysis Tools ===
* FindBugs
** Creating custom rules
* PMD
** Creating custom rules
* JLint
* Jmetrics

== J2EE Security For Deployers ==

=== Securing Popular J2EE Servers ===
* Securing Tomcat
* Securing JBoss
* Securing WebLogic
* Securing WebSphere
* Securing x...
Would be nice to include an example secure by default configuration file for each server that has additional comments in it which expands on the security repurcussions of the various sections.

=== Defining a Java Security Policy ===
* Jeff's tool? --[[User:Stephendv|Stephendv]] 08:37, 12 June 2006 (EDT)
* jChains (www.jchains.org)

=== Protecting Binaries ===
* Bytecode obfuscation
* Convert bytecode to native machine code
* jarsigner

Talk:OWASP Java Project Roadmap

2006-06-16T14:26:55Z

Rohyt: /* Frameworks you should be aware of (e.g. struts, stinger, etc.) */

==J2EE Security for Architects==

=== Risk Analysis===
To my mind, Risk Analysis is a general exercise that will apply equaly to all apps irrespective of the language used to implement the app. So would say that this belongs in the Guide rather than the Java project, unless you have some ideas on how to make this Java specific? --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
I agree -- suggest deleting this section [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

Agreed - Rohyt

===Mapping Regulatory requirements to technical requirements===
Same as above. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
I agree -- suggest deleting this section [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

Agreed - Rohyt

===Design considerations===
This is quite general. Shall we narrow it down to the architectural issues that should be considered for each of the popular architectures such as:
* Architectural considerations
** EJB Middle tier
** Web Services Middle tier
** Spring Middle tier
--[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)

===Frameworks you should be aware of (e.g. struts, stinger, etc.)===
There are many frameworks out there, so I'd suggest we keep this down to frameworks that specifically offer security functionality such as:
* Acegi
* Commons validator
* jGuard
* Stinger seems to be parked for a while now, is this correct Jeff?
** Stinger is
** CVS HEAD is in a functional state; needs work on docs and new features [[User:Roman|Roman]] 00:15, 13 June 2006 (EDT)
Most web tier frameworks will prevent XSS attacks, so listing them all in this section is a bit verbose, would prefer to see them listed in the XSS section. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)

I think Struts should be covered too given the extensive input validation functionality it supports - Rohyt

==J2EE Security for Developers==

===Java Security Basics===
* Class Loading
* Bytecode verifier
* The Security Manager and security.policy file
I suggest we do something short here for web developers, and wait on client side apps for now [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

I agree --[[User:Stephendv|Stephendv]] 09:48, 12 June 2006 (EDT)

===Input Validation===
* Overview

==== SQL Injection====
* Overview
* Prevention
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis
** Spring JDBC
** EJB 3.0?
** JDO?

====XSS====
* Overview
* Prevention
** White Listing
** Manual HTML Encoding
** Preventing XSS in popular Web Frameworks
*** JSP/JSTL
*** Struts
*** Spring MVC
*** Java Server Faces
*** WebWork?
*** Wicket?
*** Tapestry?
* <s>Misc I/P Validation Attacks (e.g. HTTP Response Splitting)</s> - Moved this out to a separate section below. --[[User:Stephendv|Stephendv]] 08:41, 12 June 2006 (EDT)
* <s>Using struts</s> Would recommend we cover a number of frameworks as mentioned above. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
* CSRF attack

==== LDAP Injection ====
* Overview
* Prevention

==== XPATH Injection ====
* Overview
* Prevention

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting
* Command injection - Runtime.getRuntime().exec()

=== Authentication===
* Storing credentials
* Hashing
* SSL Best Practices
* CAPTCHA systems (jcaptcha?)
* Container-managed authentication with Realms
* JAAS Authentication
* Password length & complexity

===Session Management===
* Logout
* Session Timeout
* Absolute Timeout
* Session Fixation
* Terminating sessions
** Terminating sessions when the browser window is closed

===Authorization===
* In presentation layer
* In business logic
* In data layer
* Declarative v/s Programmatic
* web.xml configuration
* [[Forced browsing]]
* JAAS
* EJB Authorization
* Acegi?
* JACC
* Check horizontal privilege

=== Encryption===
* JCE
* Storing db secrets
* Encrypting JDBC connections
* JSSE
* Random number generation

=== Error Handling & Logging===
* Output Validation
* Custom Errors
* Logging - why log? what to log? log4j, etc.
* Exception handling techniques
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks
** Servlet spec - web.xml
** JSP errorPage

=== Web Services Security ===
* SAML
* WS-Security
* ...?

=== Code Analysis Tools ===
* FindBugs
** Creating custom rules
* PMD
** Creating custom rules
* JLint
* Jmetrics

== J2EE Security For Deployers ==

=== Securing Popular J2EE Servers ===
* Securing Tomcat
* Securing JBoss
* Securing WebLogic
* Securing WebSphere
* Securing x...
Would be nice to include an example secure by default configuration file for each server that has additional comments in it which expands on the security repurcussions of the various sections.

=== Defining a Java Security Policy ===
* Jeff's tool? --[[User:Stephendv|Stephendv]] 08:37, 12 June 2006 (EDT)
* jChains (www.jchains.org)

=== Protecting Binaries ===
* Bytecode obfuscation
* Convert bytecode to native machine code
* jarsigner

Talk:OWASP Java Project Roadmap

2006-06-16T14:25:57Z

Rohyt: /* Mapping Regulatory requirements to technical requirements */

==J2EE Security for Architects==

=== Risk Analysis===
To my mind, Risk Analysis is a general exercise that will apply equaly to all apps irrespective of the language used to implement the app. So would say that this belongs in the Guide rather than the Java project, unless you have some ideas on how to make this Java specific? --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
I agree -- suggest deleting this section [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

Agreed - Rohyt

===Mapping Regulatory requirements to technical requirements===
Same as above. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
I agree -- suggest deleting this section [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

Agreed - Rohyt

===Design considerations===
This is quite general. Shall we narrow it down to the architectural issues that should be considered for each of the popular architectures such as:
* Architectural considerations
** EJB Middle tier
** Web Services Middle tier
** Spring Middle tier
--[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)

===Frameworks you should be aware of (e.g. struts, stinger, etc.)===
There are many frameworks out there, so I'd suggest we keep this down to frameworks that specifically offer security functionality such as:
* Acegi
* Commons validator
* jGuard
* Stinger seems to be parked for a while now, is this correct Jeff?
** Stinger is
** CVS HEAD is in a functional state; needs work on docs and new features [[User:Roman|Roman]] 00:15, 13 June 2006 (EDT)
Most web tier frameworks will prevent XSS attacks, so listing them all in this section is a bit verbose, would prefer to see them listed in the XSS section. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)

==J2EE Security for Developers==

===Java Security Basics===
* Class Loading
* Bytecode verifier
* The Security Manager and security.policy file
I suggest we do something short here for web developers, and wait on client side apps for now [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

I agree --[[User:Stephendv|Stephendv]] 09:48, 12 June 2006 (EDT)

===Input Validation===
* Overview

==== SQL Injection====
* Overview
* Prevention
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis
** Spring JDBC
** EJB 3.0?
** JDO?

====XSS====
* Overview
* Prevention
** White Listing
** Manual HTML Encoding
** Preventing XSS in popular Web Frameworks
*** JSP/JSTL
*** Struts
*** Spring MVC
*** Java Server Faces
*** WebWork?
*** Wicket?
*** Tapestry?
* <s>Misc I/P Validation Attacks (e.g. HTTP Response Splitting)</s> - Moved this out to a separate section below. --[[User:Stephendv|Stephendv]] 08:41, 12 June 2006 (EDT)
* <s>Using struts</s> Would recommend we cover a number of frameworks as mentioned above. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
* CSRF attack

==== LDAP Injection ====
* Overview
* Prevention

==== XPATH Injection ====
* Overview
* Prevention

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting
* Command injection - Runtime.getRuntime().exec()

=== Authentication===
* Storing credentials
* Hashing
* SSL Best Practices
* CAPTCHA systems (jcaptcha?)
* Container-managed authentication with Realms
* JAAS Authentication
* Password length & complexity

===Session Management===
* Logout
* Session Timeout
* Absolute Timeout
* Session Fixation
* Terminating sessions
** Terminating sessions when the browser window is closed

===Authorization===
* In presentation layer
* In business logic
* In data layer
* Declarative v/s Programmatic
* web.xml configuration
* [[Forced browsing]]
* JAAS
* EJB Authorization
* Acegi?
* JACC
* Check horizontal privilege

=== Encryption===
* JCE
* Storing db secrets
* Encrypting JDBC connections
* JSSE
* Random number generation

=== Error Handling & Logging===
* Output Validation
* Custom Errors
* Logging - why log? what to log? log4j, etc.
* Exception handling techniques
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks
** Servlet spec - web.xml
** JSP errorPage

=== Web Services Security ===
* SAML
* WS-Security
* ...?

=== Code Analysis Tools ===
* FindBugs
** Creating custom rules
* PMD
** Creating custom rules
* JLint
* Jmetrics

== J2EE Security For Deployers ==

=== Securing Popular J2EE Servers ===
* Securing Tomcat
* Securing JBoss
* Securing WebLogic
* Securing WebSphere
* Securing x...
Would be nice to include an example secure by default configuration file for each server that has additional comments in it which expands on the security repurcussions of the various sections.

=== Defining a Java Security Policy ===
* Jeff's tool? --[[User:Stephendv|Stephendv]] 08:37, 12 June 2006 (EDT)
* jChains (www.jchains.org)

=== Protecting Binaries ===
* Bytecode obfuscation
* Convert bytecode to native machine code
* jarsigner

Talk:OWASP Java Project Roadmap

2006-06-16T14:25:39Z

Rohyt: /* Risk Analysis */

==J2EE Security for Architects==

=== Risk Analysis===
To my mind, Risk Analysis is a general exercise that will apply equaly to all apps irrespective of the language used to implement the app. So would say that this belongs in the Guide rather than the Java project, unless you have some ideas on how to make this Java specific? --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
I agree -- suggest deleting this section [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

Agreed - Rohyt

===Mapping Regulatory requirements to technical requirements===
Same as above. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
I agree -- suggest deleting this section [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

===Design considerations===
This is quite general. Shall we narrow it down to the architectural issues that should be considered for each of the popular architectures such as:
* Architectural considerations
** EJB Middle tier
** Web Services Middle tier
** Spring Middle tier
--[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)

===Frameworks you should be aware of (e.g. struts, stinger, etc.)===
There are many frameworks out there, so I'd suggest we keep this down to frameworks that specifically offer security functionality such as:
* Acegi
* Commons validator
* jGuard
* Stinger seems to be parked for a while now, is this correct Jeff?
** Stinger is
** CVS HEAD is in a functional state; needs work on docs and new features [[User:Roman|Roman]] 00:15, 13 June 2006 (EDT)
Most web tier frameworks will prevent XSS attacks, so listing them all in this section is a bit verbose, would prefer to see them listed in the XSS section. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)

==J2EE Security for Developers==

===Java Security Basics===
* Class Loading
* Bytecode verifier
* The Security Manager and security.policy file
I suggest we do something short here for web developers, and wait on client side apps for now [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

I agree --[[User:Stephendv|Stephendv]] 09:48, 12 June 2006 (EDT)

===Input Validation===
* Overview

==== SQL Injection====
* Overview
* Prevention
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis
** Spring JDBC
** EJB 3.0?
** JDO?

====XSS====
* Overview
* Prevention
** White Listing
** Manual HTML Encoding
** Preventing XSS in popular Web Frameworks
*** JSP/JSTL
*** Struts
*** Spring MVC
*** Java Server Faces
*** WebWork?
*** Wicket?
*** Tapestry?
* <s>Misc I/P Validation Attacks (e.g. HTTP Response Splitting)</s> - Moved this out to a separate section below. --[[User:Stephendv|Stephendv]] 08:41, 12 June 2006 (EDT)
* <s>Using struts</s> Would recommend we cover a number of frameworks as mentioned above. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
* CSRF attack

==== LDAP Injection ====
* Overview
* Prevention

==== XPATH Injection ====
* Overview
* Prevention

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting
* Command injection - Runtime.getRuntime().exec()

=== Authentication===
* Storing credentials
* Hashing
* SSL Best Practices
* CAPTCHA systems (jcaptcha?)
* Container-managed authentication with Realms
* JAAS Authentication
* Password length & complexity

===Session Management===
* Logout
* Session Timeout
* Absolute Timeout
* Session Fixation
* Terminating sessions
** Terminating sessions when the browser window is closed

===Authorization===
* In presentation layer
* In business logic
* In data layer
* Declarative v/s Programmatic
* web.xml configuration
* [[Forced browsing]]
* JAAS
* EJB Authorization
* Acegi?
* JACC
* Check horizontal privilege

=== Encryption===
* JCE
* Storing db secrets
* Encrypting JDBC connections
* JSSE
* Random number generation

=== Error Handling & Logging===
* Output Validation
* Custom Errors
* Logging - why log? what to log? log4j, etc.
* Exception handling techniques
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks
** Servlet spec - web.xml
** JSP errorPage

=== Web Services Security ===
* SAML
* WS-Security
* ...?

=== Code Analysis Tools ===
* FindBugs
** Creating custom rules
* PMD
** Creating custom rules
* JLint
* Jmetrics

== J2EE Security For Deployers ==

=== Securing Popular J2EE Servers ===
* Securing Tomcat
* Securing JBoss
* Securing WebLogic
* Securing WebSphere
* Securing x...
Would be nice to include an example secure by default configuration file for each server that has additional comments in it which expands on the security repurcussions of the various sections.

=== Defining a Java Security Policy ===
* Jeff's tool? --[[User:Stephendv|Stephendv]] 08:37, 12 June 2006 (EDT)
* jChains (www.jchains.org)

=== Protecting Binaries ===
* Bytecode obfuscation
* Convert bytecode to native machine code
* jarsigner

Talk:OWASP Java Project Roadmap

2006-06-16T14:24:55Z

Rohyt: /* Risk Analysis */

==J2EE Security for Architects==

=== Risk Analysis===
To my mind, Risk Analysis is a general exercise that will apply equaly to all apps irrespective of the language used to implement the app. So would say that this belongs in the Guide rather than the Java project, unless you have some ideas on how to make this Java specific? --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
I agree -- suggest deleting this section [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)
Agreed - Rohyt

===Mapping Regulatory requirements to technical requirements===
Same as above. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
I agree -- suggest deleting this section [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

===Design considerations===
This is quite general. Shall we narrow it down to the architectural issues that should be considered for each of the popular architectures such as:
* Architectural considerations
** EJB Middle tier
** Web Services Middle tier
** Spring Middle tier
--[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)

===Frameworks you should be aware of (e.g. struts, stinger, etc.)===
There are many frameworks out there, so I'd suggest we keep this down to frameworks that specifically offer security functionality such as:
* Acegi
* Commons validator
* jGuard
* Stinger seems to be parked for a while now, is this correct Jeff?
** Stinger is
** CVS HEAD is in a functional state; needs work on docs and new features [[User:Roman|Roman]] 00:15, 13 June 2006 (EDT)
Most web tier frameworks will prevent XSS attacks, so listing them all in this section is a bit verbose, would prefer to see them listed in the XSS section. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)

==J2EE Security for Developers==

===Java Security Basics===
* Class Loading
* Bytecode verifier
* The Security Manager and security.policy file
I suggest we do something short here for web developers, and wait on client side apps for now [[User:Jeff Williams|Jeff Williams]] 09:04, 12 June 2006 (EDT)

I agree --[[User:Stephendv|Stephendv]] 09:48, 12 June 2006 (EDT)

===Input Validation===
* Overview

==== SQL Injection====
* Overview
* Prevention
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis
** Spring JDBC
** EJB 3.0?
** JDO?

====XSS====
* Overview
* Prevention
** White Listing
** Manual HTML Encoding
** Preventing XSS in popular Web Frameworks
*** JSP/JSTL
*** Struts
*** Spring MVC
*** Java Server Faces
*** WebWork?
*** Wicket?
*** Tapestry?
* <s>Misc I/P Validation Attacks (e.g. HTTP Response Splitting)</s> - Moved this out to a separate section below. --[[User:Stephendv|Stephendv]] 08:41, 12 June 2006 (EDT)
* <s>Using struts</s> Would recommend we cover a number of frameworks as mentioned above. --[[User:Stephendv|Stephendv]] 08:04, 12 June 2006 (EDT)
* CSRF attack

==== LDAP Injection ====
* Overview
* Prevention

==== XPATH Injection ====
* Overview
* Prevention

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting
* Command injection - Runtime.getRuntime().exec()

=== Authentication===
* Storing credentials
* Hashing
* SSL Best Practices
* CAPTCHA systems (jcaptcha?)
* Container-managed authentication with Realms
* JAAS Authentication
* Password length & complexity

===Session Management===
* Logout
* Session Timeout
* Absolute Timeout
* Session Fixation
* Terminating sessions
** Terminating sessions when the browser window is closed

===Authorization===
* In presentation layer
* In business logic
* In data layer
* Declarative v/s Programmatic
* web.xml configuration
* [[Forced browsing]]
* JAAS
* EJB Authorization
* Acegi?
* JACC
* Check horizontal privilege

=== Encryption===
* JCE
* Storing db secrets
* Encrypting JDBC connections
* JSSE
* Random number generation

=== Error Handling & Logging===
* Output Validation
* Custom Errors
* Logging - why log? what to log? log4j, etc.
* Exception handling techniques
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks
** Servlet spec - web.xml
** JSP errorPage

=== Web Services Security ===
* SAML
* WS-Security
* ...?

=== Code Analysis Tools ===
* FindBugs
** Creating custom rules
* PMD
** Creating custom rules
* JLint
* Jmetrics

== J2EE Security For Deployers ==

=== Securing Popular J2EE Servers ===
* Securing Tomcat
* Securing JBoss
* Securing WebLogic
* Securing WebSphere
* Securing x...
Would be nice to include an example secure by default configuration file for each server that has additional comments in it which expands on the security repurcussions of the various sections.

=== Defining a Java Security Policy ===
* Jeff's tool? --[[User:Stephendv|Stephendv]] 08:37, 12 June 2006 (EDT)
* jChains (www.jchains.org)

=== Protecting Binaries ===
* Bytecode obfuscation
* Convert bytecode to native machine code
* jarsigner

OWASP Java Project Roadmap

2006-06-10T14:34:23Z

Rohyt: /* Goals */

==Goals==
The OWASP Java Project's overall goal is to...

Produce materials that show J2EE architects, developers, and deployers how to deal with most common application security problems throughout the lifecycle.

In the near term, we are focused on the following tactical goals:

# Provide examples of how to prevent Cross Site Scripting attacks in popular web frameworks
# Provide examples of how to prevent SQL Injection in popular data access frameworks
# Provide examples of how to prevent LDAP injection in Java
# A practical guide to implementing a security policy for a Java web application
# Secure configuration guides for popular application servers

==Current Tasks==
* Decide on the near term tactical goals
* Define this roadmap

==Ideas==

Please submit your ideas for the OWASP Java Project here (you can sign your ideas by adding four tilde characters like this <nowiki>~~~~</nowiki>)
* It would be useful to have a library of J2EE security resources on the web. In addition to URLs, I think these should have short summaries that explain what the resource is about. I've clicked on far too many "J2EE Security" links only to find that the article is about implementing access control in Tomcat.
* A tool that automatically generates a security policy for a given application could be useful. The tool is first run in learning mode where it maps all the accesses that the application attempts and then generates a policy based on those access attempts.
** Note: I built such a tool back in the mid-1990's. It's a custom security manager that intercepts all accesses and has a "learn" mode. If someone is willing to take on the project, I'd be happy to dig it up. [[User:Jeff Williams|Jeff Williams]] 16:18, 8 June 2006 (EDT)

[[Category:OWASP Java Project]]

OWASP Java Project Roadmap

2006-06-10T14:33:14Z

Rohyt: /* Goals */

OWASP Java Project Roadmap

2006-06-10T14:32:37Z

Rohyt: /* Goals */

==Goals==
The OWASP Java Project's overall goal is to...

Produce materials that show J2EE architects, developers,
and deployers how to deal with most common application security problems throughout the lifecycle.

In the near term, we are focused on the following tactical goals:

# Provide examples of how to prevent Cross Site Scripting attacks in popular web frameworks
# Provide examples of how to prevent SQL Injection in popular data access frameworks
# Provide examples of how to prevent LDAP injection in Java
# A practical guide to implementing a security policy for a Java web application
# Secure configuration guides for popular application servers

==Current Tasks==
* Decide on the near term tactical goals
* Define this roadmap

==Ideas==

Please submit your ideas for the OWASP Java Project here (you can sign your ideas by adding four tilde characters like this <nowiki>~~~~</nowiki>)
* It would be useful to have a library of J2EE security resources on the web. In addition to URLs, I think these should have short summaries that explain what the resource is about. I've clicked on far too many "J2EE Security" links only to find that the article is about implementing access control in Tomcat.
* A tool that automatically generates a security policy for a given application could be useful. The tool is first run in learning mode where it maps all the accesses that the application attempts and then generates a policy based on those access attempts.
** Note: I built such a tool back in the mid-1990's. It's a custom security manager that intercepts all accesses and has a "learn" mode. If someone is willing to take on the project, I'd be happy to dig it up. [[User:Jeff Williams|Jeff Williams]] 16:18, 8 June 2006 (EDT)

[[Category:OWASP Java Project]]

OWASP Java Project Roadmap

2006-06-10T14:32:09Z

Rohyt: /* Goals */