Difference between revisions of "Category:OWASP Java Project"

From OWASP
Jump to: navigation, search
(Securing Java Application Code)
 
(33 intermediate revisions by 11 users not shown)
Line 1: Line 1:
{{Template:Stub}}
+
==== Main  ====
  
; Volunteer leader needed
+
The OWASP Java Project's goal is to enable Java and J2EE developers to build secure applications efficiently. See the [http://www.owasp.org/index.php/OWASP_Java_Project#tab=Roadmap OWASP Java Project Roadmap] for more information on our plans.
The Java project is just getting started and we need a leader. The job requires a bit of project management skill and some editing skill, but doesn't require that you are the ultimate Java, J2EE, or security expert. There are plenty of those associated with OWASP. But we need someone to get us organized.  If you're interested, please contact owasp@owasp.org.
+
  
 +
==Java Security Overview==
  
 +
While Java and J2EE contain many security technologies, it is not easy to produce an application without security vulnerabilities. Most application security [[:Category:Vulnerability|vulnerabilities]] apply to Java applications just like other environments. The notable exception is [[Buffer Overflow|buffer overflow]] and related issues that do not apply to Java applications.
  
 +
There is a wealth of information about vulnerabilities that apply to Java and JavaEE application in the [[:Category:Vulnerability|Vulnerability]] articles here at OWASP. The articles that have specific Java examples are tagged with the [[:Category:Java|Java category]].
  
While Java and J2EE contain many security technologies, it is not easy to produce an application without security vulnerabilities. Most application security [[:Category:Vulnerability|Vulnerabilities]] apply to Java applications just like other environments. The notable exception is [[Buffer overflow|buffer overflow]] and related issues that do not apply to Java applications.
+
The goals of this project are to provide information about building, configuring, deploying, operating, and maintaining secure Java applications. We cover the following topics:
  
==Securing the Java Environment==
+
; [[OWASP Java Table of Contents#J2EE Security for Architects | J2EE Security for Architects]]
Verifier and Sandbox
+
: Provides information about the design and architectural considerations for a Java web application.  Common architectures such as EJB, Web Services and Spring Middle tiers are discussed.
JRE vs. JDK (precompile JSPs)
+
  
 +
; [[OWASP Java Table of Contents#J2EE Security for Developers | J2EE Security for Developers]]
 +
: These articles cover dangerous Java calls and common vulnerabilities associated with them, such as Runtime.exec(), Statement.execute(), readline(), etc... The dangers of native code, dynamic code, and reflection will be discussed. We'll also talk about using tools like PMD, jlint, FindBugs, Eclipse, jad, and more. This section will also cover standard security mechanisms in the JDK, such as cryptography, logging, encryption, error handling.  Securing elements of an application, such as servlets, JSPs, controllers, business logic, and persistence layers will be covered. We'll discuss handling request parameters, encoding, injection, and more. We'll also discuss the use of security mechanisms such as log4j, BouncyCastle, XML encryption, XML signature, and other technologies.
  
'''Bold text'''==Securing Java Application Code==
+
; [[OWASP Java Table of Contents#J2EE Security For Deployers| J2EE Security for Deployers]]
Common vulnerabilities like...Runtime.exec, Statement, readline()
+
: These articles cover topics specifically related to the J2EE environment. We discuss minimizing the attack surface in web.xml, configuring error handlers, and performing hardening of popular J2EE application servers.
Dangers of native code, dynamic code, and reflection
+
Tools like PMD and FindBugs
+
Security mechanisms like logging, encryption, error handling
+
  
 +
; [[OWASP Java Table of Contents#J2EE Security for Security Analysts and Testers| J2EE Security for Security Analysts and Testers]]
 +
: These articles cover the verification, analysis, and testing of the security of J2EE applications. This section will cover using tools to find vulnerabilities, both in source code and in running applications. These articles will focus on J2EE-specific aspects of testing applications that use various common J2EE frameworks and coding patterns.
  
'''Injection attacks'''
+
==== Related OWASP Projects  ====
SQL injection attacks occur when an attacker includes raw SQL as input to a text field in an application. If the application uses that input to dynamically generate an SQL statement without first applying proper input validation and representation, the attacker's SQL may be executed as written in the database.
+
  
 +
;[[:Category:OWASP Enterprise Security API|OWASP Enterprise Security API (ESAPI) Project]]
 +
:a free and open collection of all the security methods that a developer needs to build a secure web application.
  
Most experienced Java programmers know to avoid this vulnerability through the use of Bind Variables in SQL Prepared Statements. But as Chess pointed out, injection attacks can also occur as "Filename Injection" writing to critical system files (often we might overlook ../../ included in a filename), "Command Injection," "XML Injection" or fundamentally in any string that may be interpreted by any part of the system at any time. In fact, it doesn't even have to be a String at all to be vulnerable to injection attacks. Therefore, input validation, which allows only inputs in a specified range of values, is a MUST for any system.
+
;[[:Category:OWASP Guide Project|OWASP Development Guide]]
 +
:a massive document covering all aspects of web application and web service security
  
 +
;[[:Category:OWASP AntiSamy Project|OWASP AntiSamy Java Project]]
 +
:an API for validating rich HTML/CSS input from users without exposure to cross-site scripting and phishing attacks
  
'''Cross-site scripting'''
+
;[[OWASP Secure Coding Practices - Quick Reference Guide|OWASP Secure Coding Practices - Quick Reference Guide]]
Anytime a user can input data that at some later point will be returned to a browser, there is an opportunity for cross-site scripting. This occurs when a user includes malicious JavaScript in a data input field (such as "First Name" or "Address"). When the data is then later displayed to another user, the embedded JavaScript is interpreted and run by the unwitting user.  
+
:this document provides a quick high level reference for secure coding practices. It is technology agnostic and defines a set of general software security coding practices, in a checklist format, that can be integrated into the development lifecycle.
  
 +
;[[:Category:OWASP Code Review Project|OWASP Code Review Guide]]
 +
:a project to capture best practices for reviewing code.
  
'''Bad credential management'''
+
;[[:Category:OWASP CSRFGuard Project|OWASP CSRFGuard Project]]
This is keeping user names and passwords in code or files as PLAIN TEXT or using trivial Base64 encodings. (It's very common for JDBC connections.)
+
:a J2EE filter that implements a unique request token to mitigate CSRF attacks
  
 +
==== Resources  ====
 +
<tbd>
  
'''Bad error handling'''
+
==== Roadmap  ====
Displaying exception stack traces in a browser window provides the attacker with the tools to "debug" your program.
+
The OWASP Java Project's overall goal is to...
  
 +
build and maintain a central landing page on the Web for all Java users (developers, architects & co.) interested in Web security
  
'''Test code goes into production'''
+
and to
Often programmers include hooks to support debugging in their applications. However, if the programmer fails to later remove ALL the logic, it can accidentally go into production, making it vulnerable to attack.
+
  
 +
produce materials that show J2EE architects, developers, and
 +
deployers how to deal with most common application security
 +
problems throughout the lifecycle.
  
'''Native methods'''
+
In the near term, we are focused on the following tactical goals:
All the security guarantees of Java are lost once Java calls Native code. Buffer overflows and the entire set of vulnerabilities commonly exposed in C and C++ programs are also possible in Java as a result of Native Method calls.
+
  
 +
# Restructure the existing content
 +
# Align the page with other Java-related OWASP projects like ESAPI, Webgoat, ASVS (including a new chapter:  "OWASP J2EE Related Projects")
 +
# Priorize work on missing content
 +
# Implement a J2EE/Java EE Secure Coding Guideline based on ESAPI, ASVS and/or the Quick Reference Guide.
 +
# Set-up a comparision of security aspects of web frameworks such like struts2, spring mvc, jsf, gwt, etc.
 +
# Set-up a comparision of security aspects of templating technologies such as jsp, velocity, tiles, etc.
 +
# Provide examples of how to prevent comman attacks like XSS in popular web frameworks
 +
# A practical guide to implementing a security policy for a Java web application
 +
# Provide secure configuration guides for popular application servers
 +
# Provide an OWASP Java Top 10
  
'''Concurrency/synchronization'''
+
==Current Tasks==
Improperly written shared caches, or even simple member variables in servlets, can result in one user's data being displayed to another user. If this occurs once by accident, an attacker may latch onto the vulnerability until it exposes critical data, such as a credit card number.
+
* Call for volunteers - Join the [http://lists.owasp.org/mailman/listinfo/java-project mailing list], read the [[Tutorial]], check the [[OWASP Java Table of Contents]] and get started!
 +
* Review of current articles
 +
See the [[OWASP Java Table of Contents]] for details of individual article status
  
 +
==Ideas==
  
'''Missing access control'''
+
Please submit your high level ideas about the direction of the OWASP Java Project here (you can sign your ideas by adding four tilde characters like this <nowiki>~~~~</nowiki>)
Often programmers secure JSP pages by including security checks at the top of each page. Such a scheme is highly vulnerable because the security checks are sprinkled throughout the code rather than being contained in one central location. Even if access control is done in a filter, the vulnerability can still occur if the Web.XML fails to include the filter during deployment. The development process needs hooks to ensure that access checks are continually verified and audited.
+
* To add specific articles, visit the [[OWASP Java Table of Contents]]
  
  
'''Bad session management'''
 
Session hijacking occurs anytime an attacker can obtain data from another user's session. Best practices for protecting a session from being hijacked include the following:
 
Issuing a new session ID when transitioning from an unauthenticated session to an authenticated session (or back).
 
Truly invalidating the current session upon logout. If the session isn't invalidated, the attacker can "log in" again by simply clicking the back button.
 
Ensuring sufficient randomness of session IDs to reduce the risk of an attacker "guessing" another user's session ID.
 
  
 +
==== Project About  ====
 +
{{:Projects/OWASP Java Project | Project About}}
  
'''Cookies and other headers'''
+
__NOTOC__
Cookies and headers are just as vulnerable to "injection" attacks as text fields in forms. Often, programmers and frameworks remember to validate form input, but they overlook validation of headers and cookies. Cookies, headers, text fields and hidden form variables all represent data sent by the browser and cannot be trusted by the server without proper validation.
+
<headertabs/>
  
 +
==Joining the Project==
  
'''Logging sensitive data'''
+
Mirko Richter is the project lead.  The project's high level roadmap can be found at the Roadmap tab.
The programmer's mantra of "log everything" can result in disaster if credit card numbers or other sensitive data accidentally make their way into log files.  
+
* Please submit your ideas for individual articles to the [[Java Project Article Wishlist]].
 +
* If you'd like to contribute:
 +
# visit the [[Tutorial]],
 +
# join the [http://lists.owasp.org/mailman/listinfo/java-project mailing list]
 +
# and pick a topic from the [[OWASP Java Table of Contents]], or suggest a new topic.<br>
 +
Remember to add the tag: <nowiki>[[Category:OWASP Java Project]]</nowiki> to the end of new articles so that they're properly categorised.
  
 
+
[[Category:OWASP_Project| Java Project ]]
'''Trusting the configuration'''
+
[[Category:OWASP Document]]
The configuration files from the local file system count as input data, too. These files should be checked for vulnerabilities and invalid input, otherwise an attacker can modify an input file and inject malicious behavior into an application.
+
[[Category:OWASP Download]]
 
+
[[Category:Language]]
==Securing the J2EE Environment==
+
Minimize attack surface in web.xml
+
Configure error handlers
+
 
+
==Securing J2EE Application Code==
+
Vulnerabilities like...
+
Using J2EE filters for protection
+
Mechanisms like input validation, encoding
+
Common vulnerabilities like...
+
 
+
[[Category:Platform]]
+
[[Category:OWASP Project]]
+

Latest revision as of 08:50, 30 October 2012

Main

The OWASP Java Project's goal is to enable Java and J2EE developers to build secure applications efficiently. See the OWASP Java Project Roadmap for more information on our plans.

Java Security Overview

While Java and J2EE contain many security technologies, it is not easy to produce an application without security vulnerabilities. Most application security vulnerabilities apply to Java applications just like other environments. The notable exception is buffer overflow and related issues that do not apply to Java applications.

There is a wealth of information about vulnerabilities that apply to Java and JavaEE application in the Vulnerability articles here at OWASP. The articles that have specific Java examples are tagged with the Java category.

The goals of this project are to provide information about building, configuring, deploying, operating, and maintaining secure Java applications. We cover the following topics:

J2EE Security for Architects
Provides information about the design and architectural considerations for a Java web application. Common architectures such as EJB, Web Services and Spring Middle tiers are discussed.
J2EE Security for Developers
These articles cover dangerous Java calls and common vulnerabilities associated with them, such as Runtime.exec(), Statement.execute(), readline(), etc... The dangers of native code, dynamic code, and reflection will be discussed. We'll also talk about using tools like PMD, jlint, FindBugs, Eclipse, jad, and more. This section will also cover standard security mechanisms in the JDK, such as cryptography, logging, encryption, error handling. Securing elements of an application, such as servlets, JSPs, controllers, business logic, and persistence layers will be covered. We'll discuss handling request parameters, encoding, injection, and more. We'll also discuss the use of security mechanisms such as log4j, BouncyCastle, XML encryption, XML signature, and other technologies.
J2EE Security for Deployers
These articles cover topics specifically related to the J2EE environment. We discuss minimizing the attack surface in web.xml, configuring error handlers, and performing hardening of popular J2EE application servers.
J2EE Security for Security Analysts and Testers
These articles cover the verification, analysis, and testing of the security of J2EE applications. This section will cover using tools to find vulnerabilities, both in source code and in running applications. These articles will focus on J2EE-specific aspects of testing applications that use various common J2EE frameworks and coding patterns.

Related OWASP Projects

OWASP Enterprise Security API (ESAPI) Project
a free and open collection of all the security methods that a developer needs to build a secure web application.
OWASP Development Guide
a massive document covering all aspects of web application and web service security
OWASP AntiSamy Java Project
an API for validating rich HTML/CSS input from users without exposure to cross-site scripting and phishing attacks
OWASP Secure Coding Practices - Quick Reference Guide
this document provides a quick high level reference for secure coding practices. It is technology agnostic and defines a set of general software security coding practices, in a checklist format, that can be integrated into the development lifecycle.
OWASP Code Review Guide
a project to capture best practices for reviewing code.
OWASP CSRFGuard Project
a J2EE filter that implements a unique request token to mitigate CSRF attacks

Resources

<tbd>

Roadmap

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

build and maintain a central landing page on the Web for all Java users (developers, architects & co.) interested in Web security

and 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:

  1. Restructure the existing content
  2. Align the page with other Java-related OWASP projects like ESAPI, Webgoat, ASVS (including a new chapter: "OWASP J2EE Related Projects")
  3. Priorize work on missing content
  4. Implement a J2EE/Java EE Secure Coding Guideline based on ESAPI, ASVS and/or the Quick Reference Guide.
  5. Set-up a comparision of security aspects of web frameworks such like struts2, spring mvc, jsf, gwt, etc.
  6. Set-up a comparision of security aspects of templating technologies such as jsp, velocity, tiles, etc.
  7. Provide examples of how to prevent comman attacks like XSS in popular web frameworks
  8. A practical guide to implementing a security policy for a Java web application
  9. Provide secure configuration guides for popular application servers
  10. Provide an OWASP Java Top 10

Current Tasks

See the OWASP Java Table of Contents for details of individual article status

Ideas

Please submit your high level ideas about the direction of the OWASP Java Project here (you can sign your ideas by adding four tilde characters like this ~~~~)


Project About

PROJECT INFO
What does this OWASP project offer you?
RELEASE(S) INFO
What releases are available for this project?
what is this project?
Name: OWASP Java Project (home page)
Purpose: The OWASP Java Project's goal is to enable Java and J2EE developers to build secure applications efficiently.
License: N/A
who is working on this project?
Project Leader(s):
  • Mirko Richter @
how can you learn more?
Project Pamphlet: Not Yet Created
Project Presentation:
Mailing list: Mailing List Archives
Project Roadmap: Not Yet Created
Main links:
Key Contacts
  • Contact Mirko Richter @ to contribute to this project
  • Contact Mirko Richter @ to review or sponsor this project
  • Contact the GPC to report a problem or concern about this project or to update information.
current release
Not Yet Published
last reviewed release
Not Yet Reviewed


other releases


Joining the Project

Mirko Richter is the project lead. The project's high level roadmap can be found at the Roadmap tab.

  1. visit the Tutorial,
  2. join the mailing list
  3. and pick a topic from the OWASP Java Table of Contents, or suggest a new topic.

Remember to add the tag: [[Category:OWASP Java Project]] to the end of new articles so that they're properly categorised.

Subcategories

This category has the following 2 subcategories, out of 2 total.

J

  • Java(3 C, 49 P)

O

Media in category "OWASP Java Project"

This category contains only the following file.