Difference between revisions of "Talk:OWASP Java Project Roadmap"

From OWASP
Jump to: navigation, search
m (J2EE Security for Architects)
m (J2EE Security for Architects)
Line 9: Line 9:
 
===Design considerations===
 
===Design considerations===
 
<table border=1 cellpadding=5>
 
<table border=1 cellpadding=5>
   <tr><td valign="top"><b>Objective:</b></td><td>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.</td></tr>
+
   <tr><td valign="top"><b>Objective:</b></td><td>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.</td></tr>
 
   <tr><td valign="top"><b>Contributors:</b></td><td></td></tr>
 
   <tr><td valign="top"><b>Contributors:</b></td><td></td></tr>
 
</table>
 
</table>
Line 18: Line 20:
  
 
===Noteworthy Frameworks===
 
===Noteworthy Frameworks===
There are many frameworks out there, so I'd suggest we keep this down to frameworks that specifically offer security functionality such as:  
+
<table border=1 cellpadding=5>
 +
  <tr><td valign="top"><b>Objective:</b></td><td>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.</td></tr>
 +
  <tr><td valign="top"><b>Contributors:</b></td><td></td></tr>
 +
</table>
 
* Acegi
 
* Acegi
 
* Commons validator
 
* Commons validator

Revision as of 02:28, 19 June 2006

Contents

J2EE Security for Architects

Reviewers:
Deadline for first draft:
Deadline for first review:
Deadline for final draft:
Deadline for final review:

Design considerations

Objective: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.
Contributors:
  • Architectural considerations
    • EJB Middle tier
    • Web Services Middle tier
    • Spring Middle tier

Noteworthy Frameworks

Objective: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.
Contributors:
  • 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 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. --Stephendv 08:04, 12 June 2006 (EDT)


I think Struts should be covered too - Rohyt

Struts is important as a web framework, but there are many frameworks that provide the same functionality from a security point of view. I think it makes sense to discuss struts as a web framework in section on XSS below with the other popular web frameworks rather than give it a special place in this section which only covers security specific frameworks. --Stephendv 07:22, 18 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 Jeff Williams 09:04, 12 June 2006 (EDT)

I agree --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?
  • 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? --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