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

Revision as of 14:27, 16 June 2006

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? --Stephendv 08:04, 12 June 2006 (EDT)

I agree -- suggest deleting this section Jeff Williams 09:04, 12 June 2006 (EDT)

Agreed - Rohyt

Mapping Regulatory requirements to technical requirements

Same as above. --Stephendv 08:04, 12 June 2006 (EDT)

I agree -- suggest deleting this section 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

--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 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 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 Jeff Williams 09:04, 12 June 2006 (EDT)

I agree --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?
~~Misc I/P Validation Attacks (e.g. HTTP Response Splitting)~~ - Moved this out to a separate section below. --Stephendv 08:41, 12 June 2006 (EDT)
~~Using struts~~ Would recommend we cover a number of frameworks as mentioned above. --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? --Stephendv 08:37, 12 June 2006 (EDT)
jChains (www.jchains.org)

Protecting Binaries

Bytecode obfuscation
Convert bytecode to native machine code
jarsigner

@@ Line 43: / Line 43: @@
 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===