OWASP - User contributions [en]

Deserialization Cheat Sheet

2018-10-12T06:00:05Z

Augustd: Fixed variable name in text to match code example

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br />
__TOC__{{TOC hidden}}
= Introduction =

This article is focused on providing clear, actionable guidance for safely deserializing untrusted data in your applications.

=What is Deserialization?=

Serialization is the process of turning some object into a data format that can be restored later. People often serialize objects in order to save them to storage, or to send as part of communications. Deserialization is the reverse of that process -- taking data structured from some format, and rebuilding it into an object. Today, the most popular data format for serializing data is JSON. Before that, it was XML.

However, many programming languages offer a native capability for serializing objects. These native formats usually offer more features than JSON or XML, including customizability of the serialization process. Unfortunately, the features of these native deserialization mechanisms can be repurposed for malicious effect when operating on untrusted data. Attacks against deserializers have been found to allow denial-of-service, access control, and remote code execution attacks.

=Guidance on Deserializing Objects Safely=
The following language-specific guidance attempts to enumerate safe methodologies for deserializing data that can't be trusted.

==PHP==
===WhiteBox Review===
Check the use of 'unserialize()' and review how the external parameters are accepted.
Use a safe, standard data interchange format such as JSON (via json_decode() and json_encode()) if you need to pass serialized data to the user.
Please also refer to to http://php.net/manual/en/function.unserialize.php

==Python==
===BlackBox Review===
If the traffic data contains the symbol dot . at the end, it's very likely that the data was sent in serialization.

===WhiteBox Review===
The following API in Python will be vulnerable to serialization attack. Search code for the pattern below.

1. The uses of pickle/c_pickle/_pickle with load/loads
<pre>
import pickle
data = """ cos.system(S'dir')tR. """
pickle.loads(data)
</pre>

2. Uses of PyYAML with load
<pre>
import yaml
document = "!!python/object/apply:os.system ['ipconfig']"
print(yaml.load(document))
</pre>

3. Uses of jsonpickle with encode or store methods

==Java==
The following techniques are all good for preventing attacks against deserialization against [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html Java's Serializable format].

Implementation: In your code, override the ObjectInputStream#resolveClass() method to prevent arbitrary classes from being deserialized. This safe behavior can be wrapped in a library like SerialKiller.
Implementation: Use a safe replacement for the generic readObject() method as seen here. Note that this addresses "billion laughs" type attacks by checking input length and number of objects deserialized.

===WhiteBox Review ===
Be aware of the following Java API uses for potential serilization vulnerability.
1. 'XMLdecoder' with external user defined parameters
2. XStream with fromXML method. (xstream version <= v1.46 is vulnerable to the serialization issue.)
3. 'ObjectInputSteam' with 'readObject'
4. Uses of 'readObject' 'readObjectNodData' 'readResolve' 'readExternal'
5. 'ObjectInputStream.readUnshared'
6. 'Serializable'

=== BlackBox Review ===
If the captured traffic data include the following patterns may suggest that the data was sent in Java serialization streams
* "AC ED 00 05" in Hex
* "''rO0" in Base64''
* Content-type = '<nowiki/>''application/x-java-serialized-object'''

===Prevent Data Leakage and Trusted Field Clobbering===
If there are data members of an object that should never be controlled by end users during deserialization or exposed to users during serialization, they should be declared as [https://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#6250 the <code>transient</code> keyword].

For a class that defined as Serializable, the sensitive information variable should be declared as 'private transient'.
For example, the class myAccount, the variable 'profit' and 'margin' were declared as transient to avoid to be serialized.

<pre>
public class myAccount implements Serializable
{
private transient double profit; // declared transient

private transient double margin; // declared transient
....
....

</pre>

===Prevent Deserialization of Domain Objects===
Some of your application objects may be forced to implement Serializable due to their hierarchy. To guarantee that your application objects can't be deserialized, a <code>readObject()</code> should be declared (with a <code>final</code> modifier) which always throws an exception.

<pre>private final void readObject(ObjectInputStream in) throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}</pre>

===Harden Your Own java.io.ObjectInputStream===
The <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. This is the best solution if:

* You can change the code that does the deserialization
* You know what classes you expect to deserialize

The general idea is to override [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html#resolveClass(java.io.ObjectStreamClass) <code>ObjectInputStream.html#resolveClass()</code>] in order to restrict which classes are allowed to be deserialized. Because this call happens before a <code>readObject()</code> is called, you can be sure that no deserialization activity will occur unless the type is one that you wish to allow. A simple example of this shown here, where the the LookAheadObjectInputStream class is guaranteed not to deserialize any other type besides the Bicycle class:

<pre>public class LookAheadObjectInputStream extends ObjectInputStream {

public LookAheadObjectInputStream(InputStream inputStream) throws IOException {
super(inputStream);
}

/**
* Only deserialize instances of our expected Bicycle class
*/
@Override
protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException,
ClassNotFoundException {
if (!desc.getName().equals(Bicycle.class.getName())) {
throw new InvalidClassException(
"Unauthorized deserialization attempt",
desc.getName());
}
return super.resolveClass(desc);
}
}</pre>

More complete implementations of this approach have been proposed by various community members:

* [https://github.com/ikkisoft/SerialKiller NibbleSec] - a library that allows whitelisting and blacklisting of classes that are allowed to be deserialized
* [https://www.ibm.com/developerworks/library/se-lookahead/ IBM] - the seminal protection, written years before the most devastating exploitation scenarios were envisioned.

===Harden All java.io.ObjectInputStream Usage with an Agent===
As mentioned above, the <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. However, if you don't own the code or can't wait for a patch, using an agent to weave in hardening to <code>java.io.ObjectInputStream</code> is the best solution.

Globally changing ObjectInputStream is only safe for blacklisting known malicious types, because it's not possible to know for all applications what the expected classes to be deserialized are. Fortunately, there are very few classes needed in the blacklist to be safe from all the known attack vectors, today. It's inevitable that more "gadget" classes will be discovered that can be abused. However, there is an incredible amount of vulnerable software
exposed today, in need of a fix. In some cases, "fixing" the vulnerability may involve re-architecting messaging systems and breaking backwards compatibility as developers move towards not accepting serialized objects.

To enable these agents, simply add a new JVM parameter:

<pre>-javaagent:name-of-agent.jar</pre>

Agents taking this approach have been released by various community members:
* [https://github.com/gocd/invoker-defender Invoker Defender by Go-CD]
* [https://github.com/Contrast-Security-OSS/contrast-rO0 rO0 by Contrast Security]

A similar, but less scalable approach would be to manually patch and bootstrap your JVM's ObjectInputStream. Guidance on this approach is available [https://github.com/wsargent/paranoid-java-serialization here].

==.Net C#==

=== WhiteBox Review ===
Search the source code for the following terms<br />

# TypeNameHandling
# JavaScriptTypeResolver

Look for any serializers where the type is set by a user controlled variable.

=== BlackBox Review ===
Search for the following base64 encoded content that starts with:

<pre>AAEAAAD/////</pre>

Search for content with the following text:
# "TypeObject"
# "$type":

=== General Precautions ===

Don't allow the datastream to define the type of object that the stream will be deserialized to. You can prevent this by for example using the '''DataContractSerializer''' or '''XmlSerializer''' if at all possible.

Where '''JSON.Net''' is being used make sure the '''TypeNameHandling''' is only set to '''None'''.

<pre>TypeNameHandling = TypeNameHandling.None</pre>

If '''JavaScriptSerializer''' is to be used do not use it with a '''JavaScriptTypeResolver'''

If you must deserialise data streams that define their own type, then restrict the types that are allowed to be deserialized. One should be aware that this is still risky as many native .Net types potentially dangerous in themselves. e.g.

<pre>System.IO.FileInfo</pre>

FileInfo objects that reference files actually on the server can when deserialized, change the properties of those files e.g. to read-only, creating a potential denial of service attack.<br />

Even if you have limited the types that can be deserialised remember that some types have properties that are risky. '''System.ComponentModel.DataAnnotations.ValidationException''', for example has a property '''Value''' of type '''Object'''. if this type is the type allowed for deserialization then an attacker can set the '''Value''' property to any object type they choose.

Attackers should be prevented from steering the type that will be instantiated. If this is possible then even '''DataContractSerializer''' or '''XmlSerializer''' can be subverted e.g.
<pre>
var typename = GetTransactionTypeFromDatabase(); // <-- this is dangerous if the attacker can change the data in the database

var serializer = new DataContractJsonSerializer(Type.GetType(typename));

var obj = serializer.ReadObject(ms);
</pre>

Execution can occur within certain .Net types during deserialization. Creating a control such as the one shown below is ineffective.

<pre>
var suspectObject = myBinaryFormatter.Deserialize(untrustedData);

if (suspectObject is SomeDangerousObjectType) //Too late! Execution may have already occurred.
{
//generate warnings and dispose of suspectObject
}
</pre>

For '''BinaryFormatter''' and '''JSON.Net''' it is possible to create a safer form of white list control useing a custom '''SerializationBinder'''.<br />

Try to keep up-to-date on known .Net insecure deserialization gadgets and pay special attention where such types can be created by your deserialization processes. A deserializer can only only instantiate types that it knows about. Try to keep any code that might create potential gagdets separate from any code that Vas internet connectivity. As an example '''System.Windows.Data.ObjectDataProvider''' used in WPF applications is a known gadget that allows arbitrary method invocation. It would be risky to have this a reference to this assembly in a REST service project that deserializes untrusted data.

=== Known .NET RCE Gadgets ===
System.Configuration.Install.AssemblyInstaller
* System.Activities.Presentation.WorkflowDesigner
* System.Windows.ResourceDictionary
* System.Windows.Data.ObjectDataProvider
* System.Windows.Forms.BindingSource
* Microsoft.Exchange.Management.SystemManager.WinForms.ExchangeSettingsProvider
* System.Data.DataViewManager, System.Xml.XmlDocument/XmlDataDocument
* System.Management.Automation.PSObject

= Language-Agnostic Methods for Deserializing Safely =

==Using Alternative Data Formats==
A great reduction of risk is achieved by avoiding native (de)serialization formats. By switching to a pure data format like JSON or XML, you lessen the chance of custom deserialization logic being repurposed towards malicious ends.

Many applications rely on a [https://en.wikipedia.org/wiki/Data_transfer_object data-transfer object pattern] that involves creating a separate domain of objects for the explicit purpose data transfer. Of course, it's still possible that the application will make security mistakes after a pure data object is parsed.

==Only Deserialize Signed Data==
If the application knows before deserialization which messages will need to be processed, they could sign them as part of the serialization process. The application could then to choose not to deserialize any message which didn't have an authenticated signature.

= Mitigation Tools/Libraries =
* Java secure deserialization library https://github.com/ikkisoft/SerialKiller

* SWAT (Serial Whitelist Application Trainer) https://github.com/cschneider4711/SWAT
* NotSoSerial https://github.com/kantega/notsoserial

= Detection Tools =
* [https://github.com/GrrrDog/Java-Deserialization-Cheat-Sheet Java deserialization cheat sheet aimed at pen testers]

* [https://github.com/frohoff/ysoserial A proof-of-concept tool for generating payloads that exploit unsafe Java object deserialization.]
* Java De-serialization toolkits https://github.com/brianwrf/hackUtils
* Java de-serialization tool https://github.com/frohoff/ysoserial
* .Net payload generator https://github.com/pwntester/ysoserial.net
* Java de-serialization detection by DNS https://github.com/GoSeecure/break-fast-serial
* Burp Suite extension https://github.com/federicodotta/Java-Deserialization-Scanner/releases
* Java secure deserialization library https://github.com/ikkisoft/SerialKiller
* Serianalyzer is a static bytecode analyzer for deserialization https://github.com/mbechler/serianalyzer
* Payload generator https://github.com/mbechler/marshalsec
* Android Java Deserialization Vulnerability Tester https://github.com/modzero/modjoda
* Burp Suite Extension
** JavaSerialKiller https://github.com/NetSPI/JavaSerialKiller
** Java Deserialization Scanner https://github.com/federicodotta/Java-Deserialization-Scanner
** Burp-ysoserial https://github.com/summitt/burp-ysoserial
** SuperSerial https://github.com/DirectDefense/SuperSerial
** SuperSerial-Active https://github.com/DirectDefense/SuperSerial-Active

= References =
* https://github.com/GrrrDog/Java-Deserialization-Cheat-Sheet
* [[Deserialization of untrusted data]]
* [[Media:GOD16-Deserialization.pdf|Java Deserialization Attacks - German OWASP Day 2016]]
* [http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles AppSecCali 2015 - Marshalling Pickles]
* [http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere FoxGlove Security - Vulnerability Announcement]
* [https://github.com/GrrrDog/Java-Deserialization-Cheat-Sheet Java deserialization cheat sheet aimed at pen testers]
* [https://github.com/frohoff/ysoserial A proof-of-concept tool for generating payloads that exploit unsafe Java object deserialization.]
* Java De-serialization toolkits https://github.com/brianwrf/hackUtils
* Java de-serialization tool https://github.com/frohoff/ysoserial
* Java de-serialization detection by DNS https://github.com/GoSeecure/break-fast-serial
* Burp Suite extension https://github.com/federicodotta/Java-Deserialization-Scanner/releases
* Java secure deserialization library https://github.com/ikkisoft/SerialKiller
* Serianalyzer is a static bytecode analyzer for deserialization https://github.com/mbechler/serianalyzer
* Payload generator https://github.com/mbechler/marshalsec
* Android Java Deserialization Vulnerability Tester https://github.com/modzero/modjoda
* Burp Suite Extension
** JavaSerialKiller https://github.com/NetSPI/JavaSerialKiller
** Java Deserialization Scanner https://github.com/federicodotta/Java-Deserialization-Scanner
** Burp-ysoserial https://github.com/summitt/burp-ysoserial
** SuperSerial https://github.com/DirectDefense/SuperSerial
** SuperSerial-Active https://github.com/DirectDefense/SuperSerial-Active
* .Net
** Alvaro Muñoz: .NET Serialization: Detecting and defending vulnerable endpoints https://www.youtube.com/watch?v=qDoBlLwREYk
** James Forshaw - Black Hat USA 2012 - Are You My Type? Breaking .net Sandboxes Through Serialization https://www.youtube.com/watch?v=Xfbu-pQ1tIc
** Jonathan Birch BlueHat v17 || Dangerous Contents - Securing .Net Deserialization https://www.youtube.com/watch?v=oxlD8VWWHE8
** Alvaro Muñoz & Oleksandr Mirosh - Friday the 13th: Attacking JSON - AppSecUSA 2017 Https://www.youtube.com/watch?v=NqHsaVhlxAQ

= Authors and Primary Editors =

Arshan Dabirsiaghi - arshan [at] contrastsecurity dot org<br />
Tony Hsu (Hsiang-Chih)
Shane Murnion

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]] [[Category:OWASP .NET Project]]
|}

CRLF Injection

2018-03-14T16:50:54Z

Augustd: /* Related Attacks */ Added Log Injection

{{Template:Vulnerability}}

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

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==
The term CRLF refers to '''C'''arriage '''R'''eturn (ASCII 13, \r) '''L'''ine '''F'''eed (ASCII 10, \n). They're used to note the termination of a line, however, dealt with differently in today’s popular Operating Systems. For example: in Windows both a CR and LF are required to note the end of a line, whereas in Linux/UNIX a LF is only required. In the HTTP protocol, the CR-LF sequence is always used to terminate a line.

A CRLF Injection attack occurs when a user manages to submit a CRLF into an application. This is most commonly done by modifying an HTTP parameter or URL.

==Risk Factors==
TBD

==Examples==
Depending on how the application is developed, this can be a minor problem or a fairly serious security flaw. Let's look at the latter because this is after all a security related post.

Let's assume a file is used at some point to read/write data to a log of some sort. If an attacker managed to place a CRLF then can then inject some sort of read programmatic method to the file. This could result in the contents being written to screen on the next attempt to use this file.

Another example is the "response splitting" attacks, where CRLFs are injected into an application and included in the response. The extra CRLFs are interpreted by proxies, caches, and maybe browsers as the end of a packet, causing mayhem.

==Related [[Attacks]]==

* [[HTTP Response Splitting]]
* [[Log Injection]]

==Related [[Vulnerabilities]]==

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

==Related [[Controls]]==

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

==Related [[Technical Impacts]]==

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

==References==
TBD

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

Availability Vulnerability
Authorization Vulnerability
Authentication Vulnerability
Concurrency Vulnerability
Configuration Vulnerability
Cryptographic Vulnerability
Encoding Vulnerability
Error Handling Vulnerability
Input Validation Vulnerability
Logging and Auditing Vulnerability
Session Management Vulnerability]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Vulnerability]]
[[Category:Implementation]]

OWASP Java File I O Security Project

2016-02-17T23:08:34Z

Augustd: /* Quick Download */

{{taggedDocument}}
=Main=


<div style="width:100%;height:100px;border:0,margin:0;overflow: hidden;">[[Image:OWASP Inactive Banner.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Inactive_Projects]] </div>

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

==OWASP Java File I/O Security Project==

The OWASP Java File I/O Security Project provides an easy to use library for validating and sanitizing filenames, directory paths, and uploaded files. This project encapsulates the file handling portions of the ESAPI project and makes them available in an easy to use library that has no dependencies.

==Licensing==
OWASP Java File I/O Security Project is licensed under the Apache 2.0 License.

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

== What is the OWASP Java File I/O Security Project? ==

OWASP Java File I/O Security Project provides:

* File name validation
* Directory path validation
* File validation

== Code Repo ==

[https://github.com/augustd/owasp-java-fileio Java File I/O at GitHub]

== Project Leader ==

August Detlefsen [mailto:augustd@codemagi.com @]

== Related Projects ==
[[ESAPI|OWASP Enterprise Security API]]

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

== Email List ==

[https://lists.owasp.org/mailman/listinfo/owasp_java_file_i_o_security_project Project Mailing List]

== News and Events ==
* [20 Nov 2013] News 2
* [30 Sep 2013] News 1

== In Print ==
This project can be purchased as a print on demand book from Lulu.com

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:New projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| align="center" valign="top" width="50%"|
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

=FAQs=

; Q1
: A1

; Q2
: A2

= Acknowledgements =
==Volunteers==
XXX is developed by a worldwide team of volunteers. The primary contributors to date have been:

* xxx
* xxx

==Others==
* xxx
* xxx

= Road Map and Getting Involved =
As of [https://www.owasp.org/index.php/Projects/OWASP_Java_File_I_O_Security_Project/Roadmap April 2014], the priorities are:

* Initial version out in one month.
* Documentation within 4 months.
* Introduction at JavaOne in September.

Involvement in the development and promotion of the OWASP Java File I O Security Project is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* xxx
* xxx

__NOTOC__ <headertabs />

[[Category:OWASP Project]]

OWASP Java File I O Security Project

2016-02-17T22:32:36Z

Augustd: /* Code Repo */

{{taggedDocument}}
=Main=


<div style="width:100%;height:100px;border:0,margin:0;overflow: hidden;">[[Image:OWASP Inactive Banner.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Inactive_Projects]] </div>

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

==OWASP Java File I/O Security Project==

The OWASP Java File I/O Security Project provides an easy to use library for validating and sanitizing filenames, directory paths, and uploaded files. This project encapsulates the file handling portions of the ESAPI project and makes them available in an easy to use library that has no dependencies.

==Licensing==
OWASP Java File I/O Security Project is licensed under the Apache 2.0 License.

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

== What is the OWASP Java File I/O Security Project? ==

OWASP Java File I/O Security Project provides:

* File name validation
* Directory path validation
* File validation

== Code Repo ==

[https://github.com/augustd/owasp-java-fileio Java File I/O at GitHub]

== Project Leader ==

August Detlefsen [mailto:augustd@codemagi.com @]

== Related Projects ==
[[ESAPI|OWASP Enterprise Security API]]

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

== Quick Download ==

* Link to page/download

== Email List ==

[https://lists.owasp.org/mailman/listinfo/owasp_java_file_i_o_security_project Project Mailing List]

== News and Events ==
* [20 Nov 2013] News 2
* [30 Sep 2013] News 1

== In Print ==
This project can be purchased as a print on demand book from Lulu.com

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:New projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| align="center" valign="top" width="50%"|
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

=FAQs=

; Q1
: A1

; Q2
: A2

= Acknowledgements =
==Volunteers==
XXX is developed by a worldwide team of volunteers. The primary contributors to date have been:

* xxx
* xxx

==Others==
* xxx
* xxx

= Road Map and Getting Involved =
As of [https://www.owasp.org/index.php/Projects/OWASP_Java_File_I_O_Security_Project/Roadmap April 2014], the priorities are:

* Initial version out in one month.
* Documentation within 4 months.
* Introduction at JavaOne in September.

Involvement in the development and promotion of the OWASP Java File I O Security Project is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* xxx
* xxx

__NOTOC__ <headertabs />

[[Category:OWASP Project]]

Talk:WebGoat Installation

2016-01-21T18:46:43Z

Augustd: Created page with "All of this documentation is out of date. This page should probably be removed or forwarded to https://github.com/WebGoat/WebGoat-Legacy/wiki/Installation-(WebGoat-6.0)"

All of this documentation is out of date. This page should probably be removed or forwarded to https://github.com/WebGoat/WebGoat-Legacy/wiki/Installation-(WebGoat-6.0)

OWASP Security Logging Project

2015-04-15T23:10:10Z

Augustd: /* News and Events */

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

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

==OWASP Security Logging Project==

The OWASP Security Logging project provides developers and ops personnel with APIs for logging security-related events. The aim is to let developers use the same set of logging APIs they are already familiar with from over a decade of experience with Log4J and its successors, while also adding powerful security features.

==Description==
Logging is often neglected by developers when thinking of security considerations. However, proper logging practice can provide the crucial forensics needed to investigate after a breach, and perhaps more importantly, a change to detect security issues as they happen. Most developers are already familiar with using logging for debugging and diagnostic purposes, so it should be easy for them to grasp the concept of security logging as well. The OWASP Security Logging project aims to give developers an easy way to get started with logging security events, tracking extra forensic information like the who (username), what (event type), and where (IP address, server name) needed for forensics. It also provides a means for classifying the information in log messages and applying masking if necessary.

==Licensing==
This library is free software: you can redistribute it and/or modify it under the terms of the Apache License, Version 2.0. You can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

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

== Project Resources ==
[https://github.com/javabeanz/owasp-security-logging Source Code]

[https://github.com/javabeanz/owasp-security-logging/wiki Documentation]

[https://github.com/javabeanz/owasp-security-logging/issues Issue Tracker]

== Project Leaders ==
[mailto:sytze.vonkoningsveld@owasp.org Sytze van Koningsveld]

[mailto:august.detlefsen@owasp.org August Detlefsen]

[mailto:milton.smith@owasp.org Milton Smith]

== Related Projects ==

* [[Logging_Cheat_Sheet|Logging Cheat Sheet]]

==Classifications==

{| width="200" cellpadding="2"
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects|Incubator Project]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Agplv3-155x51.png|link=http://www.gnu.org/licenses/agpl-3.0.html|Affero General Public License 3.0]]
|}

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

== News and Events ==
5 Mar 2015 Version 1.0.0 deployed to Maven Central

23 Dec 2014 Project Created and source code now available!

|}

=FAQs=

The following provides answers to frequently asked questions.

==How can I participate in your project?==
All you have to do is make the Project Leader's aware of your available time to contribute to the project. It is also important to let the Leader's know how you would like to contribute and pitch in to help the project meet it's goals and milestones. There are many different ways you can contribute to an OWASP Project, but communication with the leads is key.

==If I am not a programmer can I participate in your project?==
Yes, you can certainly participate in the project if you are not a programmer or technical. The project needs different skills and expertise and different times during its development. Currently, we are looking for researchers, writers, graphic designers, and a project administrator.

= Acknowledgements =
==Volunteers==

Only project leads for the moment. Email projects leads if you would like to participate.

=Roadmap & Getting Involved=

Today many logging technologies are available providing powerful application logging capabilities. But while powerful, these technologies are not designed for specific use-cases like security and auditing. The generalized approach to logging platforms makes these platforms more useful to the widest possible audience but it also places more responsibility on designers. In short, we don't consider our desire for additional improvement for security and audit logs is no oversight on the part of logging platform designers.

It's the OWASP Security Logging Project desire to leverage existing technologies and apply them to improve security, audit, in addition to diagnostic logging. We understand logging is mostly an afterthought on many project schedules, if it's included at all. We believe a logging solution embracing this project will help the community produce better logs, a better understanding of our information systems, and higher quality software.

==Getting involved==
Are you passionate about logging? Are you motivated share your time and knowledge with the community? Send the project leads an email, listed on project home page, and explain your ideas and how you can help. Don't be discouraged if we don't immediately respond. We occasionally get distracted with life but rest assured we will respond.

==What is the OWASP Security Logging Project?==
OWASP Security Logging Project purpose is to deliver a suitable logging solution for general-purpose security, audit, and diagnostics log messaging. Beyond code and technology, the project provides architectural and implementation considerations you may find useful in your own projects, or technologies you may not have previously considered.

==Project goals==
* Develop a set of logging requirements for key domains like security, auditing, and diagnostics
* Develop interface specifications that support the projects requirements
* Develop a base implementation supporting project interface specifications
* Develop documentation artifacts (described later)

==Considerations and restraints==
* Ease of use
* Compelling value on initial deployment (without any refactoring). Increased value for refactoring
* Compatibility with existing industry standard logging technologies (e.g., log4*, logback, FluentD, etc)
* Typical scenarios considered, 1) stand-alone applications on mobile or desktop, 2) enterprise applications, and 3) cloud-based applications.

==Anticipated support==
* Java 1.7 and Java 1.8
* .NET (tbd)
''We have considered other platforms for the future but everything depends upon community interest and support.''

==Proposed features==
Following is a list of numbered features.

:1. MDC metadata improvements
:: a. process id (TBD)
:: b. application id and application instance id
:: c. server time\date in UTC
:: d. client time\date in UTC
:: e. client IP address
:: f. username or ID
:: g. global client session ID
:: h. security policy identifier
:: i. transaction id
:2. Log system properties on startup
:3. Log command line options on startup
:4. Log application server properties on startup
:5. Log HTTP request parameters
:6. Log HTTP session attributes
:7. Internationalization considerations
:8. Redirect system streams like system.out and system.err security logging framework
:9. Asynchronous message logging, store and forward
:10. Message correlation
:11. Performance options for transport compression
:12. Authenticated client logging
:13. Secure log message transport
:14. Signed log messages
:15. Guaranteed log message delivery

==Delivery phases==
'''Alpha 1''', some features code complete.<br/>
'''Alpha 2''', more features code complete.<br/>
'''Beta''', release code complete. Public encouraged to test and respond with comments.<br/>
'''Early Availability(EA)''', includes improvements to beta based upon public and team recommendations.<br/>

==Use-case applicability & delivery schedule==
The following table shows a proposed applicability of each feature to the projects areas of concern, diagnostics, security, and audit logging along with a suggested delivery phase.

{| class="wikitable" style="color:#555555; background-color:#ffffcc;" cellpadding="10"
! 
!Diagnostics
!Security
!Audit
!Delivery
|-
|Feature 1a, process id
|'''X'''
|'''X'''
|'''X'''
|Alpha 1
|-
|Feature 1b, application id and application instance id
|'''X'''
|'''X'''
|'''X'''
|Alpha 1
|-
|Feature 1c, server time\date in UTC
|'''X'''
|'''X'''
|'''X'''
|Alpha 1
|-
|Feature 1d, client time\date in UTL
|'''X'''
|'''X'''
|'''X'''
|Alpha 1
|-
|Feature 1e, client IP address
|'''X'''
|'''X'''
|'''X'''
|Alpha 1
|-
|Feature 1f, username or ID
|'''X'''
|'''X'''
|'''X'''
|Alpha 1
|-
|Feature 1g, global client session ID
|'''X'''
|'''X'''
|'''X'''
|Alpha 1
|-
|Feature 1h, security policy identifier
| 
|'''M'''
|'''X'''
|Alpha 1
|-
|Feature 1i, transaction id
|'''X'''
|'''X'''
|'''X'''
|Alpha 1
|-
|Feature 2, Log system properties on startup
|'''X'''
|'''X'''
|'''X'''
|Alpha 1
|-
|Feature 3, Log command line properties on startup
|'''X'''
| 
| 
|Alpha 1
|-
|Feature 4, Log application server properties on startup
|'''X'''
| 
| 
|Alpha 2
|-
|Feature 5, Log HTTP request parameters
|'''X'''
|'''X'''
| 
|Alpha 2
|-
|Feature 6, Log HTTP session attributes
|'''X'''
|'''X'''
|'''?'''
|Alpha 2
|-
|Feature 7, Internationalization considerations
|'''X'''
|'''X'''
|'''X'''
|Alpha 1
|-
|Feature 8, Redirect system streams like System.out and System.err to logging framework
|'''X'''
| 
| 
|Alpha 2
|-
|Feature 9, Asynchronous message logging, store and forward
|'''X'''
|'''X'''
|'''X'''
|Alpha 2
|-
|Feature 10, Message correlation
|'''X'''
|'''X'''
|'''X'''
|Alpha 2
|-
|Feature 11, Performance options for transport compression
|'''X'''
|'''X'''
|'''X'''
|Alpha 2
|-
|Feature 12, Authenticated client logging
| 
|'''X'''
|'''X'''
|Alpha 2
|-
|Feature 13, Secure log message transport
| 
|'''X'''
|'''X'''
|Alpha 2
|-
|Feature 14, Signed log messages
| 
|'''X'''
|'''X'''
|Alpha 1
|-
|Feature 15, Guaranteed log message delivery
| 
|'''X'''
|'''X'''
|Alpha 2
|}
'''''Legend, X=applicable use-case, M=maybe useful, ?=tbd'''''

==Project delivery artifacts==
:'''Logging primer''', architectural considerations for security, audit, and diagnostics for community projects. Provide information how logging project can be leverage to address concerns provided by each use case, general logging best practices, template for using message levels (e.g., INFO, WARN, etc).
:'''Logging design''', specific technical details to apply project logging to community logging projects.
:'''Code''', software program code that implements project feature goals.

==Code areas==
:'''Logging layouts''', at the moment this is Common Event Format(CEF) and Common Log File System(CLFS).
:'''MDC filter''', include system information handy for most deployments into logbacks Mapped Diagnostics Context(MDC).
:'''MDC marker''',
:'''Unit testing''', various software code we use (and you can also use) to test project code.

==Detailed use-case descriptions==
Following are detailed use-case descriptions for each feature. The purpose of this section is to help readers to understand more about each feature and it's potential benefits.

==Feature 1, MDC metadata improvements==
This feature adds certain metadata useful for security purposes to logback’s Mapped Diagnostics Content. The following metadata will be mapped where available.

===process id (feature 1a)===
This is the process id of the application as assigned by the operating system at execution. On *nix and Windows environments this the PID. Depending upon the language platform process id may not be readily available. As an alternative, server hostname or IP may be used.

===application id and application instance id (feature 1b)===
This an identifier set by the application designer to identify a unique application instance. This identifier is useful to identify applications uniquely where many instances of the same program (e.g., web application) are hosted on 1 or more physical servers. The application id is useful visual indicator of the type of application component. The instance id is useful to identify the application instance. The instance is particularly useful where the same process may host 2 or more application instances. An instance id may be a generated hash (e.g., VMID) or unique index where size is a concern. Once the id is used it should persist between process restarts. A suggested format: {APP ID}:{APP INSTANCE ID}. An sample POS:ace22c02aa858f670e3c227fbab141e2d8d6bea6 or POS:14563.

===server time\date in UTC (feature 1c)===
Time, date, and day, on the server with timezone offset at the time the message was logged. A suggested format[1], {yyyy-MM-dd'T'HH:mm:ss.SSSZ}. An example, 2001-07-04T12:08:56.235-0700

===client time\date in UTC (feature 1d)===
Time, date, and day, on the client with timezone offset at the time the message was logged. A suggested format[1], {yyyy-MM-dd'T'HH:mm:ss.SSSZ}. An example, 2001-07-04T12:08:56.235-0700

===client ip address (feature 1e)===
MDC property for the IP address of the client host where the log message originated. An example, 192.168.1.30

===user name or ID (feature 1f)===
This MDC property to property is an application account name associated with a human (if available) this is associated with this log message. This property may not be available if the log message is not specifically related to an individual's activity. An example, milton.smith

===global client session id (feature 1g)===
This MDC property is a session id assigned by an application designer that is shared across multiple application instances. Usually this is a secure hash to avoid reverse engineering. An example, ace22c02aa858f670e3c227fbab141e2d8d6bea6

===security policy identifier (feature 1h)===
MDC property that identifies activities associated with a sites security policy. The value is site defined and can be useful when producing information for audits. An example, Violation:SEC.5.2a

===transaction id (feature 1i)===
MDC property to identify activities associated with a single user action. For example, execution of a single application user feature may require many activities from the main application program along with components like LDAP servers and databases. The transaction id is useful to correlate all the related system activities that support a specific user request. Each subsequent user request receives a new transaction id. An example, TRX:1005862

==Feature 2, Log system properties on startup==
The requirement is to log all system properties on application startup. Often it’s difficult to perform an investigation without understanding the initial state of the system. An example how properties may appear in logs (without MDC information).

<pre>
*******************************************
JAVA PROPERTY SETTINGS
*******************************************
Setting, java.runtime.name=Java(TM) SE Runtime Environment
Setting, sun.boot.library.path=C:\Program Files\Java\jre6\bin
Setting, java.vm.version=14.0-b16
Setting, java.vm.vendor=Sun Microsystems Inc.
Setting, java.vendor.url=http://java.sun.com/
Setting, path.separator=;
Setting, java.vm.name=Java HotSpot(TM) Client VM
Setting, file.encoding.pkg=sun.io
Setting, sun.java.launcher=SUN_STANDARD
Setting, user.country=US
Setting, sun.os.patch.level=
Setting, java.vm.specification.name=Java Virtual Machine Specification
Setting, user.dir=C:\Users\Milton\workspace\MyProject
Setting, java.runtime.version=1.6.0_14-b08
Setting, java.awt.graphicsenv=sun.awt.Win32GraphicsEnvironment
Setting, java.endorsed.dirs=C:\Program Files\Java\jre6\lib\endorsed
Setting, os.arch=x86
Setting, java.io.tmpdir=C:\Users\Milton\AppData\Local\Temp\
Setting, line.separator=

Setting, java.vm.specification.vendor=Sun Microsystems Inc.
Setting, user.variant=
Setting, os.name=Windows 7
Setting, sun.jnu.encoding=Cp1252
Setting, java.library.path=C:\Program Files\Java\jre6\bin;.;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:/Program Files/Java/jre6/bin/client;C:/Program Files/Java/jre6/bin;C:\Program Files\JavaFX\javafx-sdk1.2\bin;C:\Program Files\JavaFX\javafx-sdk1.2\emulator\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;c:\usershellcommands;C:\Program Files\QuickTime\QTSystem\
Setting, java.specification.name=Java Platform API Specification
Setting, java.class.version=50.0
Setting, sun.management.compiler=HotSpot Client Compiler
Setting, os.version=6.1
Setting, user.home=C:\Users\Milton
Setting, user.timezone=
Setting, java.awt.printerjob=sun.awt.windows.WPrinterJob
Setting, file.encoding=Cp1252
Setting, java.specification.version=1.6
Setting, java.class.path=C:\Users\Milton\workspace\SDA\bin;C:\Java-Libs\jmx-1_2_1-bin\lib\jmxri.jar;C:\Java-Libs\apache-log4j-1.2.15\log4j-1.2.15.jar
Setting, user.name=Milton
</pre>

==Feature 3, Log command line options on startup==
The requirement is to log all command line arguments on application startup. All command line arguments must be logged. In Java, the entire arg array passed into the main(String args[]) method should be logged. Any whitespace or special characters should be filtered before logged. For example a small program that echos the input to the command line may produce an output that looks like the following.

<pre>
*******************************************
COMMAND LINE ARGS
*******************************************
java testapp “Hello World!”
Hello World!
</pre>

==Feature 4, Log application server properties on startup==
The requirement is to log all key\value pairs that influence application behavior upon execution. In Java, there parameters are defined by HttpServlet.getInitParameterNames() An example of logged J2EE properties may look like the following.

<pre>
*******************************************
J2EE PROPERTIES
*******************************************
Setting, thread.pool.size=1000
Setting, request.ttlms=30000
</pre>

==Feature 5, Log HTTP request parameters==
The requirement is to log all key\value pairs associated with all application HTTP requests. Raw HTTP requests parameters across the cloud may generate significantly increase log volume. The goal is to define a request log that overwrites itself (e.g., a ring buffer) at a small designer specified interval or a default of 15 mins. This allows highly granular diagnostic messages over a short duration.

An ancillary requirement is that sensitive key\value pairs will be masked. A default set of masking rules will be included with the project with an option for designers to assign their own masking rules specific for their applications.

(TODOMS: need to insert some raw http requests from zap in a suitable log format)

==Feature 6, Log HTTP session attributes==

The requirement is to log all key\value pairs associated with a users HttpSession instance. These properties should be logged once upon user session initialization. In Java, key\value pairs from HttpSession.getAttributeName() should be logged when the HttpSession is created.

(TODOMS: need to insert some sample HTTP session attributes)

==Feature 7, Internationalization considerations==
The action is to use string resources so that logs are compatible across languages. The project will initially define US English. Designers are encouraged to translate resources to different languages. If the translations are made available to us we may include them.

==Feature 8, Redirect system streams like System.out and System.err to security logging framework==
This requirement captures any legacy messaging from older code without refactoring. The approach redirects any messages to system defined streams into the logging framework. Log messages will not be a content rich since since the caller, old code in this case, does not calling the Security API directly. The advantage is instant out of the box compatibility with no refactoring. In Java, the action is to capture calls like System.out.println(“My wife loves security.”) and System.err() reroute them to the logging framework without modification to legacy programs.

An ancillary requirement is that sensitive key\value pairs will be masked. A default set of masking rules will be included with the project with an option for designers to assign their own masking rules specific for their applications.

==Feature 9, Asynchronous message logging, store and forward==
The requirement for this feature one of performance. Log messages sent to a remote location (e.g., central log server) can take some time to send over networks. It may be desirable in some deployments for the caller not to block when logging these messages. The goal is to log the message locally, freeing the caller, then send the message in a background thread to the remote server. See Feature 15 also.

==Feature 10, Message correlation==
A problem with logs today is that it’s often difficult to reconstruct a series of activities leading to an event of interest. System logs are often out of order with messages originating from different threads and hosts. The goal of message correlation is to provide identifier(s) so that all log messages can be sequenced into a narrative of system activities leading to an event of interest. For example, with correlation it will be possible to separate log entries to see the activities involved in a single administrative user operation like Add User. Log entries to add a user may begin with HTTP posts from the clients browser, system permission checks, next a log message describing the insert of the new user into the user table, a log message of positive confirmation a SMTP message was sent to indicate the users new account is ready for initial signon.

==Feature 11, Performance options for transport compression==
Where log message will transit networks facilities will be provided to compress traffic to remote hosts.

==Feature 12, Authenticated client logging==
This feature is useful to ensure each message logged is attributable to a known source and trusted source. Messages from anonymous sources may still be allowed, depending upon system preferences, but authenticated messages will clearly indicate the identity of the source.

==Feature 13, Secure transport==
To facilitate secure transport a TLS 1.2 compliant connection be negotiated. Options must be provided to allow designers to control ciphersuite negotiation. Negotiation options must include provision for, a) the name of each ciphersuite permitted, b) order of negotiation which is ideally strongest suites first as a default but can be changed by the designer. The trust roots will be those supplied by the supporting language platform (e.g., Java, .NET, etc).

==Feature 14, Signed log messages==
To facilitate tamper resistant log messages log messages will be signed by the client. Each field of the log message will be included in the signing process. The signature will be included with the log message entry along with strongest fingerprint included within signing certificate. The fingerprint of the signing certificate is an aid to identify the signing certificate and may be important for enterprise or cloud environments where many clients are logging. Signed logs may or may not be encrypted.

==Feature 15, Guaranteed log message delivery==
This feature builds upon the Feature 9, Asynchronous message logging, store and forward to include guaranteed delivery. The goal is that no messages are lost. Messages received from the caller will be queued for delivery. Clients logging messages must block until their log message is committed to a queue. For simplicity, the queue will exist on the client computer. The function is somewhat analogous to a local print spooler. If committing to a queue is not possible an instance of a RuntimeException must be thrown to the caller. Once committed to a queue, worker threads will send the message in the background to the remote server. On the client, worker threads will not remove the log message from the queue until the server has acknowledged receipt.

From the server side, the server must maintain the client connection until the message is logged. If the message cannot be logged an instance of an Exception must be thrown. Using this system no message will ever be lost. A message will exist in only 3 states, 1) with the blocked client, 2) within the client’s log queue, 3) logged on the server. For a completely reliable solution, HA hardware and RAID media are required which is a consideration for system designers.

==Feedback==
Please report any concerns, correction, or other feedback to any of the project leads listed on the main project page.

=Minimum Viable Product=
<span style="color:#ff0000">
This page is where you should indicate what is the minimum set of functionality that is required to make this a useful product that addresses your core security concern.
Defining this information helps the project leader to think about what is the critical functionality that a user needs for this project to be useful, thereby helping determine what the priorities should be on the roadmap. And it also helps reviewers who are evaluating the project to determine if the functionality sufficiently provides the critical functionality to determine if the project should be promoted to the next project category.
</span>

=Project About=

<span style="color:#ff0000">
This page is where you need to place your legacy project template page if your project was created before October 2013. To edit this page you will need to edit your project information template. You can typically find this page by following this address and substituting your project name where it says "OWASP_Example_Project". When in doubt, ask the OWASP Projects Manager.
Example template page: https://www.owasp.org/index.php/Projects/OWASP_Example_Project
</span>

{{:Projects/OWASP_Example_Project_About_Page}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Code]]

OWASP Security Logging Project

2015-01-13T19:22:34Z

Augustd: /* Main */

OWASP Security Logging Project

2015-01-07T22:08:30Z

Augustd: Added external links

OWASP Java File I O Security Project

2014-08-26T02:33:52Z

Augustd:

OWASP Java File I O Security Project

2014-08-26T02:09:47Z

Augustd:

OWASP Java File I O Security Project

2014-08-26T02:08:23Z

Augustd:

OWASP Java File I O Security Project

2014-04-18T21:17:57Z

Augustd:

Insecure Randomness

2012-02-09T22:42:19Z

Augustd: /* Examples */

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

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

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==

Standard pseudo-random number generators cannot withstand cryptographic attacks.

Insecure randomness errors occur when a function that can produce predictable values is used as a source of randomness in security-sensitive context.

Computers are deterministic machines, and as such are unable to produce true randomness. Pseudo-Random Number Generators (PRNGs) approximate randomness algorithmically, starting with a seed from which subsequent values are calculated.

There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical properties, but their output is highly predictable and forms an easy to reproduce numeric stream that is unsuitable for use in cases where security depends on generated values being unpredictable. Cryptographic PRNGs address this problem by generating output that is more difficult to predict. For a value to be cryptographically secure, it must be impossible or highly improbable for an attacker to distinguish between it and a truly random value. In general, if a PRNG algorithm is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts.

==Risk Factors==

TBD

==Examples==

The following code uses a statistical PRNG to create a URL for a receipt that remains active for some period of time after a purchase (DO NOT DO THIS).

<pre>
String GenerateReceiptURL(String baseUrl) {
Random ranGen = new Random();
ranGen.setSeed((new Date()).getTime());
return(baseUrl + Gen.nextInt(400000000) + ".html");
}
</pre>

This code uses the Random.nextInt() function to generate "unique" identifiers for the receipt pages it generates. Because Random.nextInt() is a statistical PRNG, it is easy for an attacker to guess the strings it generates. Although the underlying design of the receipt system is also faulty, it would be more secure if it used a random number generator that did not produce predictable receipt identifiers, such as a cryptographic PRNG.

The following code uses Java's SecureRandom class to generate a cryptographically strong pseudo-random number (DO THIS):

<pre>
public static int generateRandom(int maximumValue) {
SecureRandom ranGen = new SecureRandom();
return ranGen.nextInt(maximumValue);
}
</pre>

==Related [[Attacks]]==

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

==Related [[Vulnerabilities]]==

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

==Related [[Controls]]==

* [[Random Number Generator]]
* [[:Category:Cryptography]]

==Related [[Technical Impacts]]==

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

==References==
TBD

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Cryptographic Vulnerability]]
[[Category:Java]]
[[Category:Code Snippet]]
[[Category:Vulnerability]]

OWASP Java HTML Sanitizer Project

2011-08-26T22:52:57Z

Augustd:

==== Project About ====
{{:Projects/OWASP Java HTML Sanitizer Project | Project About}}

__NOTOC__ <headertabs/>

A fast and easy to configure HTML Sanitizer written in Java which lets you include HTML authored by third-parties in your web application while protecting against XSS.

The code is hosted on [http://code.google.com/p/owasp-java-html-sanitizer/ Google Code]. The [http://canyouxssthis.com/ attack review] is ongoing so please consider it alpha software.

[[Category:OWASP_Tool]]
[[Category:OWASP_Alpha_Quality_Tool]]
[[Category:OWASP_Project|Java HTML Sanitizer]]

AppSec US 2010, CA/Attending Owasp Leaders

2010-09-05T20:41:18Z

Augustd: /* Also attending (part of OWASP community) */

Page to manage the participation of the OWASP leaders at the [[AppSec_US_2010,_CA|AppSec USA in Irvine USA]]

===Attending Leaders - Confirmed===

# [[User:Dancornell|Dan Cornell]]- ''San Antonio Chapter and Global Membership Committee''
# Tony UV - ''Atlanta Chapter''
# [[User:Jmanico|Jim Manico]] - ''Podcast Project''
# [[User:MichaelCoates|Michael Coates]] - ''AppSensor project and Global Membership Committee''
# [[User:Knoblochmartin|Martin Knobloch]] - ''Education and Connections Committee''
# [[User:Rsnake|Robert Hansen]] - ''Connections Committee''
# [[User:Mtesauro|Matt Tesauro]] - ''Live CD project, Board Member''
# [[User:Wichers|Dave Wichers]] - ''Top 10 project, Board Member''
# [[User:brennan|Tom Brennan]] - ''NYC Chapter Leader, RFP Criteria project, OWASP-CRM, Board Member''
# [[User:Jeff_Williams|Jeff Williams]] - ''ESAPI project, Board Member''
# [[User:Dinis.cruz|Dinis Cruz]] - ''O2 Platform project, Board Member''
# [[User:Dc|David Campbell]] - ''Denver Chapter, Industry Committee''
# [[User:Eduprey|Eric Duprey]] - ''Denver Chapter''
# [[User:Justin42|Justin Clarke]] - ''London Chapter and Connections Committee''
# Roman Hustad - ''Sacramento Chapter''
# Peter Dean - ''NYC Chapter Leader''
# Georg Hess - ''German Chapter, Industry Committee''
# John Steven - ''NoVA Chapter Lead''
# [[User:Lorna Alamri|Lorna Alamri]] - ''Connections Committee''
# [[User:Chris Schmidt|Chris Schmidt]] - ''ESAPI Project''

'''Part of the conference organization'''
# Cassio Goldschmidt - ''Los Angeles Chapter''
# [[:User:Tin Zaw|Tin Zaw]] - ''Los Angeles Chapter''
# [[User:Richard greenberg|Richard Greenberg]] - ''Los Angeles Chapter''
# [http://twitter.com/nilematotle Neil Matatall] - ''[[http://www.owasp.org/index.php/Orange_County Orange County Chapter]]''
# Kate Hartmann - OWASP Foundation
# Alison McNamee - OWASP Foundation (remote support)

===Also attending (part of OWASP community)===
# Joseph Dawson
# Howard Fore - ''Atlanta Chapter (Bring a Developer Attendee)''
# Jon Bango - ''Atlanta Chapter (Bring a Developer Attendee)''
# August Detlefsen - ''(Bring a Developer Attendee)''

===Key WebAppSec players===
objective: identfy potential synergies between WebAppSec industry players and OWASP leaders (for example too meet and have a meeting)

* Firefox Browser
** There are a number of Firefox employees participating and they have shown interest in talking to OWASP about how we can work together
*** Michael Coates (Owasp Leader)
*** Sid Stamm
*** Brandon Sterne
*** Dan Veditz

===Developers and QA participating===
'''Sponsored by the Atlanta Chapter'''
# ''Howard Fore (Atlanta Developer)'' - Howard Fore is a senior web developer in Atlanta, Georgia. He's involved in some high-visibility web projects at the Federal Reserve Bank of Atlanta. Increasing awareness of secure software development practices is an departmental objective for 2010 and he's a member of the security workgroup, which is leading the way in that endeavor. Other practices the security workgroup are implementing include static code analysis and code inspection.
# ''Jon Bango (Atlanta Developer)'' - Jon Bango is an Information Technology professional with over 13 years experience in the education, financial services and retail industries. Primarily working at the enterprise level, Jon has utilized the J2EE stack in building web applications for the largest home improvement retailer in the world. Most recently he has branched out into RIA technologies working in Adobe Flex and Microsoft Silverlight. Currently, Jon has transitioned into the dark arts at his company’s Information Assurance department in which the groundwork has been laid to utilize his developer talents to create a company wide secure coding initiative.
# ''August Detlefsen (Oakland Developer)'' - August Detlefsen is a 13+ year Java web architect veteran. As an independent contractor he has developed solutions for such companies as Sun Microsystems, Oracle, VMware, NetApp and others, managing all phases of the software development lifecycle from initial specification to final disposal. August recently began focusing on web application security and has worked on projects for WhiteHat Security, Security Compass, and AppSec Consulting and donated time on the OWASP ESAPI and AppSensor projects.

===Meetings and sessions===
So far we have identified 6 slots were there will be an event happening around this group

* '''Wed Night''' : 9PM-12PM Drinks at TDB
* '''Thursday Lunch Break''' : 'OWASP and the Browsers: How can we work together?'
* '''Thursday After the conference''' : OWASP Leaders meeting
* '''Thursday Night''' : TBD ''(and maybe the OWASP band?)''
* '''Friday Lunch Break''' : OWASP Summit 2011
* '''Friday After the conference''' : AppSec Soccer Tournament
* '''Friday Night''' : TDB

Note that there are meeting facilities available, so if you need a quite space to meet and talk about OWASP let us know.

=== How to track an OWASP Leader===

Ideally we should be able to track OWASP leaders, the question is how?

What could we give the leaders that would easily identify them (in practical and usable way):
* a special wristband
** with a particular color?
** with a particular logo or message?
** wth a GPC tag? (or auto-location-tweet)
* an armband
* a hat
* a scarf
* a t-shirt
* a bag
* with a paintball gun?

===AppSec Soccer Tournament===
'''When:''' Friday after the conference<br/>
'''Where:''' TBC<br/>
'''Participants:'''<br/>
* Dinis Cruz
* Kate Hartmann (can also be a referre)

===To do (tasks)===
* for each each participant
** link to MediaWiki user page
** add twitter accounts
*Travel arrangements
** map travel dates
** when/where they are arriving
** where are they staying
* figure out what to do with the leaders when they are there
* should we create a welcome pack for these leaders?
* should we see if they need help in their travel arrangements?
* should we see if its possible to find a local host for the accomodation (it is always better than going into an hotel)?
* do we need a budget? if so, how much?

[[Category:Connections Committee]]

AppSec US 2010, CA/Attending Owasp Leaders

2010-09-05T20:40:26Z

Augustd: /* Developers and QA participating */

Page to manage the participation of the OWASP leaders at the [[AppSec_US_2010,_CA|AppSec USA in Irvine USA]]

===Attending Leaders - Confirmed===

# [[User:Dancornell|Dan Cornell]]- ''San Antonio Chapter and Global Membership Committee''
# Tony UV - ''Atlanta Chapter''
# [[User:Jmanico|Jim Manico]] - ''Podcast Project''
# [[User:MichaelCoates|Michael Coates]] - ''AppSensor project and Global Membership Committee''
# [[User:Knoblochmartin|Martin Knobloch]] - ''Education and Connections Committee''
# [[User:Rsnake|Robert Hansen]] - ''Connections Committee''
# [[User:Mtesauro|Matt Tesauro]] - ''Live CD project, Board Member''
# [[User:Wichers|Dave Wichers]] - ''Top 10 project, Board Member''
# [[User:brennan|Tom Brennan]] - ''NYC Chapter Leader, RFP Criteria project, OWASP-CRM, Board Member''
# [[User:Jeff_Williams|Jeff Williams]] - ''ESAPI project, Board Member''
# [[User:Dinis.cruz|Dinis Cruz]] - ''O2 Platform project, Board Member''
# [[User:Dc|David Campbell]] - ''Denver Chapter, Industry Committee''
# [[User:Eduprey|Eric Duprey]] - ''Denver Chapter''
# [[User:Justin42|Justin Clarke]] - ''London Chapter and Connections Committee''
# Roman Hustad - ''Sacramento Chapter''
# Peter Dean - ''NYC Chapter Leader''
# Georg Hess - ''German Chapter, Industry Committee''
# John Steven - ''NoVA Chapter Lead''
# [[User:Lorna Alamri|Lorna Alamri]] - ''Connections Committee''
# [[User:Chris Schmidt|Chris Schmidt]] - ''ESAPI Project''

'''Part of the conference organization'''
# Cassio Goldschmidt - ''Los Angeles Chapter''
# [[:User:Tin Zaw|Tin Zaw]] - ''Los Angeles Chapter''
# [[User:Richard greenberg|Richard Greenberg]] - ''Los Angeles Chapter''
# [http://twitter.com/nilematotle Neil Matatall] - ''[[http://www.owasp.org/index.php/Orange_County Orange County Chapter]]''
# Kate Hartmann - OWASP Foundation
# Alison McNamee - OWASP Foundation (remote support)

===Also attending (part of OWASP community)===
# Joseph Dawson
# Howard Fore - ''Atlanta Chapter (Bring a Developer Attendee)''
# Jon Bango - ''Atlanta Chapter (Bring a Developer Attendee)''

===Key WebAppSec players===
objective: identfy potential synergies between WebAppSec industry players and OWASP leaders (for example too meet and have a meeting)

* Firefox Browser
** There are a number of Firefox employees participating and they have shown interest in talking to OWASP about how we can work together
*** Michael Coates (Owasp Leader)
*** Sid Stamm
*** Brandon Sterne
*** Dan Veditz

===Developers and QA participating===
'''Sponsored by the Atlanta Chapter'''
# ''Howard Fore (Atlanta Developer)'' - Howard Fore is a senior web developer in Atlanta, Georgia. He's involved in some high-visibility web projects at the Federal Reserve Bank of Atlanta. Increasing awareness of secure software development practices is an departmental objective for 2010 and he's a member of the security workgroup, which is leading the way in that endeavor. Other practices the security workgroup are implementing include static code analysis and code inspection.
# ''Jon Bango (Atlanta Developer)'' - Jon Bango is an Information Technology professional with over 13 years experience in the education, financial services and retail industries. Primarily working at the enterprise level, Jon has utilized the J2EE stack in building web applications for the largest home improvement retailer in the world. Most recently he has branched out into RIA technologies working in Adobe Flex and Microsoft Silverlight. Currently, Jon has transitioned into the dark arts at his company’s Information Assurance department in which the groundwork has been laid to utilize his developer talents to create a company wide secure coding initiative.
# ''August Detlefsen (Oakland Developer)'' - August Detlefsen is a 13+ year Java web architect veteran. As an independent contractor he has developed solutions for such companies as Sun Microsystems, Oracle, VMware, NetApp and others, managing all phases of the software development lifecycle from initial specification to final disposal. August recently began focusing on web application security and has worked on projects for WhiteHat Security, Security Compass, and AppSec Consulting and donated time on the OWASP ESAPI and AppSensor projects.

===Meetings and sessions===
So far we have identified 6 slots were there will be an event happening around this group

* '''Wed Night''' : 9PM-12PM Drinks at TDB
* '''Thursday Lunch Break''' : 'OWASP and the Browsers: How can we work together?'
* '''Thursday After the conference''' : OWASP Leaders meeting
* '''Thursday Night''' : TBD ''(and maybe the OWASP band?)''
* '''Friday Lunch Break''' : OWASP Summit 2011
* '''Friday After the conference''' : AppSec Soccer Tournament
* '''Friday Night''' : TDB

Note that there are meeting facilities available, so if you need a quite space to meet and talk about OWASP let us know.

=== How to track an OWASP Leader===

Ideally we should be able to track OWASP leaders, the question is how?

What could we give the leaders that would easily identify them (in practical and usable way):
* a special wristband
** with a particular color?
** with a particular logo or message?
** wth a GPC tag? (or auto-location-tweet)
* an armband
* a hat
* a scarf
* a t-shirt
* a bag
* with a paintball gun?

===AppSec Soccer Tournament===
'''When:''' Friday after the conference<br/>
'''Where:''' TBC<br/>
'''Participants:'''<br/>
* Dinis Cruz
* Kate Hartmann (can also be a referre)

===To do (tasks)===
* for each each participant
** link to MediaWiki user page
** add twitter accounts
*Travel arrangements
** map travel dates
** when/where they are arriving
** where are they staying
* figure out what to do with the leaders when they are there
* should we create a welcome pack for these leaders?
* should we see if they need help in their travel arrangements?
* should we see if its possible to find a local host for the accomodation (it is always better than going into an hotel)?
* do we need a budget? if so, how much?

[[Category:Connections Committee]]

AppSensor Developer Guide

2010-09-02T23:58:38Z

Augustd: /* ResponseAction */

= AppSensor Developer Guide =

The [[:Category:OWASP AppSensor Project|AppSensor Project]] describes an application layer intrusion detection system. There is a Java implementation of this system whose basic usage can be found in the [[AppSensor_GettingStarted|Getting Started]] guide. This document describes in more technical detail for developers how to use and extend AppSensor for a specific environment and application.

== Developer Overview ==
AppSensor is an application layer intrusion detection system. The concept in implementation is roughly analogous to an intrusion detection (and prevention) system in the network security world. However, this concept can be applied inside of an application in a more specific way that (importantly) reduces false positives, which is an issue that often plagues network intrusion detection systems. This means that the core of the AppSensor system performs detection, monitoring, and (possibly) response depending on configuration settings.

AppSensor has been built to be quite extensible from the ground up. Most of the system can be appreciably modified to your needs by simply extending certain key interfaces, and modifying the appsensor configuration file appropriately. This extensible design makes it possible for various configurations to be applied depending upon the application. For instance, in a small application, you may choose to use a simple file-based model for storing intrusions that are detected, whereas for a larger application, you may have a relational database serving as your data store. See the '''Extending AppSensor''' section below for specifics on what can be extended.

== Extending AppSensor ==
Below you will find the individual interfaces you are likely to extend in order to modify AppSensor for your environment.
----

==== IntrusionStore ====
The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/IntrusionStore.java IntrusionStore] interface represents, simply enough, the storage mechanism for any intrusions that occur in the system. The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/AppSensorIntrusionDetector.java AppSensorIntrusionDetector] takes care of adding the intrusions to the intrusion store. The current [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/reference/DefaultIntrusionStore.java DefaultIntrusionStore] class stores all of the intrusions in a simple HashMap. The class is fairly small and simple, though, so it is trivial to understand it's inner workings and to use similar concepts to build an implementation that suits your environment.

<pre>
The setting you'll need to modify in appsensor.properties to enable your own implementation is:

# This is the class that handles the intrusion store
AppSensor.intrusionStore=org.owasp.appsensor.intrusiondetection.reference.DefaultIntrusionStore
</pre>
----

==== ResponseAction ====
The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/ResponseAction.java ResponseAction] interface is used to simply respond to an intrusion once a threshold has been crossed. The decision for when to respond is handled by the [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/AppSensorIntrusionDetector.java AppSensorIntrusionDetector], but the actual handling of the response is delegated to implementations of this interface. The only reason to not use the [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/reference/DefaultResponseAction.java DefaultResponseAction] would be if you have additional response actions you need to take, or if you need to modify the handling of one of the existing responses. Again, the [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/reference/DefaultResponseAction.java DefaultResponseAction] should give you a good starting point for creating your own implementation.

<pre>
The setting you'll need to modify in appsensor.properties to enable your own implementation is:

# This is the class that handles the response actions
AppSensor.responseAction=org.owasp.appsensor.intrusiondetection.reference.DefaultResponseAction
</pre>

[http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/reference/DefaultResponseAction.java DefaultResponseAction] supports the following actions:
<ul>
<li>"log" - logs the activity</li>
<li>"logout" - logs the currently logged in user out (if one exists)</li>
<li>"disable" - disables the account of the currently logged in user (if one exists)</li>
<li>"disableComponent" - disables access to the location of the intrusion using the AppSensorServiceController</li>
<li>"disableComponentForUser" - disables access to the location of the intrusion using the AppSensorServiceController for the currently logged in user(if one exists)</li>
<li>"emailAdmin" - Email administrator to notify of what action has occurred</li>
<li>"smsAdmin" - SMS administrator (via email to sms account) to notify of what action has occurred</li>
</ul>

<pre>
Response actions can be configured for individual detection points using properties like: IntrusionDetector.<detection point>.actions=

# list of actions you want executed in the specified order as the threshold for this intrusion is met -
# ie. log the first time, logout the user the second time, etc.
IntrusionDetector.IE99.actions=log,logout,disable,disableComponent
</pre>

----

==== ASUtilities ====
The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/ASUtilities.java ASUtilities] interface handles a collection of concerns. It handles retrieving the current user of the application (ie. the user that made the current request and/or caused the current intrusion). In addition, it handles the retrieval of the logger as well as the current HTTP request. The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/reference/DefaultASUtilities.java DefaultASUtilities] implementation simply delegates to the equivalent ESAPI method calls to retrieve the appropriate data. If you are not using ESAPI's logging and/or authentication and/or request binding utilities, you'll need to create your own implementation of this class. ''' ''Note: This is the interface you'll need to implement if you are not using ESAPI.'' '''

<pre>
The setting you'll need to modify in appsensor.properties to enable your own implementation is:

# This is the class that handles the utility retriever
AppSensor.asUtilities=org.owasp.appsensor.reference.DefaultASUtilities
</pre>
----

==== TrendLogger ====
The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/trendmonitoring/TrendLogger.java TrendLogger] interface is in place to handle the logging of events in order to monitor trends. The techniques for doing this vary widely depending upon environment. You'll most likely not want to use the existing [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/trendmonitoring/reference/InMemoryTrendLogger.java InMemoryTrendLogger] as it will scale very poorly. It is simply in place as a starting point for other implementations.

<pre>
The setting you'll need to modify in appsensor.properties to enable your own implementation is:

# This is the class that handles the trend logging
AppSensor.trendLogger=org.owasp.appsensor.trendmonitoring.reference.InMemoryTrendLogger
</pre>
----

AppSensor Developer Guide

2010-09-02T23:57:01Z

Augustd: /* ResponseAction */

= AppSensor Developer Guide =

The [[:Category:OWASP AppSensor Project|AppSensor Project]] describes an application layer intrusion detection system. There is a Java implementation of this system whose basic usage can be found in the [[AppSensor_GettingStarted|Getting Started]] guide. This document describes in more technical detail for developers how to use and extend AppSensor for a specific environment and application.

== Developer Overview ==
AppSensor is an application layer intrusion detection system. The concept in implementation is roughly analogous to an intrusion detection (and prevention) system in the network security world. However, this concept can be applied inside of an application in a more specific way that (importantly) reduces false positives, which is an issue that often plagues network intrusion detection systems. This means that the core of the AppSensor system performs detection, monitoring, and (possibly) response depending on configuration settings.

AppSensor has been built to be quite extensible from the ground up. Most of the system can be appreciably modified to your needs by simply extending certain key interfaces, and modifying the appsensor configuration file appropriately. This extensible design makes it possible for various configurations to be applied depending upon the application. For instance, in a small application, you may choose to use a simple file-based model for storing intrusions that are detected, whereas for a larger application, you may have a relational database serving as your data store. See the '''Extending AppSensor''' section below for specifics on what can be extended.

== Extending AppSensor ==
Below you will find the individual interfaces you are likely to extend in order to modify AppSensor for your environment.
----

==== IntrusionStore ====
The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/IntrusionStore.java IntrusionStore] interface represents, simply enough, the storage mechanism for any intrusions that occur in the system. The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/AppSensorIntrusionDetector.java AppSensorIntrusionDetector] takes care of adding the intrusions to the intrusion store. The current [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/reference/DefaultIntrusionStore.java DefaultIntrusionStore] class stores all of the intrusions in a simple HashMap. The class is fairly small and simple, though, so it is trivial to understand it's inner workings and to use similar concepts to build an implementation that suits your environment.

<pre>
The setting you'll need to modify in appsensor.properties to enable your own implementation is:

# This is the class that handles the intrusion store
AppSensor.intrusionStore=org.owasp.appsensor.intrusiondetection.reference.DefaultIntrusionStore
</pre>
----

==== ResponseAction ====
The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/ResponseAction.java ResponseAction] interface is used to simply respond to an intrusion once a threshold has been crossed. The decision for when to respond is handled by the [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/AppSensorIntrusionDetector.java AppSensorIntrusionDetector], but the actual handling of the response is delegated to implementations of this interface. The only reason to not use the [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/reference/DefaultResponseAction.java DefaultResponseAction] would be if you have additional response actions you need to take, or if you need to modify the handling of one of the existing responses. Again, the [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/reference/DefaultResponseAction.java DefaultResponseAction] should give you a good starting point for creating your own implementation.

<pre>
The setting you'll need to modify in appsensor.properties to enable your own implementation is:

# This is the class that handles the response actions
AppSensor.responseAction=org.owasp.appsensor.intrusiondetection.reference.DefaultResponseAction
</pre>

The DefaultResponseAction supports the following actions:
<ul>
<li>"log" - logs the activity</li>
<li>"logout" - logs the currently logged in user out (if one exists)</li>
<li>"disable" - disables the account of the currently logged in user (if one exists)</li>
<li>"disableComponent" - disables access to the location of the intrusion using the AppSensorServiceController</li>
<li>"disableComponentForUser" - disables access to the location of the intrusion using the AppSensorServiceController for the currently logged in user(if one exists)</li>
<li>"emailAdmin" - Email administrator to notify of what action has occurred</li>
<li>"smsAdmin" - SMS administrator (via email to sms account) to notify of what action has occurred</li>
</ul>

<pre>
Response actions can be configured for individual detection points using properties like: IntrusionDetector.<detection point>.actions=

# list of actions you want executed in the specified order as the threshold for this intrusion is met -
# ie. log the first time, logout the user the second time, etc.
IntrusionDetector.IE99.actions=log,logout,disable,disableComponent
</pre>

----

==== ASUtilities ====
The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/ASUtilities.java ASUtilities] interface handles a collection of concerns. It handles retrieving the current user of the application (ie. the user that made the current request and/or caused the current intrusion). In addition, it handles the retrieval of the logger as well as the current HTTP request. The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/reference/DefaultASUtilities.java DefaultASUtilities] implementation simply delegates to the equivalent ESAPI method calls to retrieve the appropriate data. If you are not using ESAPI's logging and/or authentication and/or request binding utilities, you'll need to create your own implementation of this class. ''' ''Note: This is the interface you'll need to implement if you are not using ESAPI.'' '''

<pre>
The setting you'll need to modify in appsensor.properties to enable your own implementation is:

# This is the class that handles the utility retriever
AppSensor.asUtilities=org.owasp.appsensor.reference.DefaultASUtilities
</pre>
----

==== TrendLogger ====
The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/trendmonitoring/TrendLogger.java TrendLogger] interface is in place to handle the logging of events in order to monitor trends. The techniques for doing this vary widely depending upon environment. You'll most likely not want to use the existing [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/trendmonitoring/reference/InMemoryTrendLogger.java InMemoryTrendLogger] as it will scale very poorly. It is simply in place as a starting point for other implementations.

<pre>
The setting you'll need to modify in appsensor.properties to enable your own implementation is:

# This is the class that handles the trend logging
AppSensor.trendLogger=org.owasp.appsensor.trendmonitoring.reference.InMemoryTrendLogger
</pre>
----

AppSensor Developer Guide

2010-09-02T23:35:09Z

Augustd: /* IntrusionStore */

= AppSensor Developer Guide =

The [[:Category:OWASP AppSensor Project|AppSensor Project]] describes an application layer intrusion detection system. There is a Java implementation of this system whose basic usage can be found in the [[AppSensor_GettingStarted|Getting Started]] guide. This document describes in more technical detail for developers how to use and extend AppSensor for a specific environment and application.

== Developer Overview ==
AppSensor is an application layer intrusion detection system. The concept in implementation is roughly analogous to an intrusion detection (and prevention) system in the network security world. However, this concept can be applied inside of an application in a more specific way that (importantly) reduces false positives, which is an issue that often plagues network intrusion detection systems. This means that the core of the AppSensor system performs detection, monitoring, and (possibly) response depending on configuration settings.

AppSensor has been built to be quite extensible from the ground up. Most of the system can be appreciably modified to your needs by simply extending certain key interfaces, and modifying the appsensor configuration file appropriately. This extensible design makes it possible for various configurations to be applied depending upon the application. For instance, in a small application, you may choose to use a simple file-based model for storing intrusions that are detected, whereas for a larger application, you may have a relational database serving as your data store. See the '''Extending AppSensor''' section below for specifics on what can be extended.

== Extending AppSensor ==
Below you will find the individual interfaces you are likely to extend in order to modify AppSensor for your environment.
----

==== IntrusionStore ====
The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/IntrusionStore.java IntrusionStore] interface represents, simply enough, the storage mechanism for any intrusions that occur in the system. The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/AppSensorIntrusionDetector.java AppSensorIntrusionDetector] takes care of adding the intrusions to the intrusion store. The current [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/reference/DefaultIntrusionStore.java DefaultIntrusionStore] class stores all of the intrusions in a simple HashMap. The class is fairly small and simple, though, so it is trivial to understand it's inner workings and to use similar concepts to build an implementation that suits your environment.

<pre>
The setting you'll need to modify in appsensor.properties to enable your own implementation is:

# This is the class that handles the intrusion store
AppSensor.intrusionStore=org.owasp.appsensor.intrusiondetection.reference.DefaultIntrusionStore
</pre>
----

==== ResponseAction ====
The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/ResponseAction.java ResponseAction] interface is used to simply respond to an intrusion once a threshold has been crossed. The decision for when to respond is handled by the [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/AppSensorIntrusionDetector.java AppSensorIntrusionDetector], but the actual handling of the response is delegated to implementations of this interface. The only reason to not use the [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/reference/DefaultResponseAction.java DefaultResponseAction] would be if you have additional response actions you need to take, or if you need to modify the handling of one of the existing responses. Again, the [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/reference/DefaultResponseAction.java DefaultResponseAction] should give you a good starting point for creating your own implementation.

<pre>
The setting you'll need to modify in appsensor.properties to enable your own implementation is:

# This is the class that handles the response actions
AppSensor.responseAction=org.owasp.appsensor.intrusiondetection.reference.DefaultResponseAction
</pre>
----

==== ASUtilities ====
The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/ASUtilities.java ASUtilities] interface handles a collection of concerns. It handles retrieving the current user of the application (ie. the user that made the current request and/or caused the current intrusion). In addition, it handles the retrieval of the logger as well as the current HTTP request. The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/reference/DefaultASUtilities.java DefaultASUtilities] implementation simply delegates to the equivalent ESAPI method calls to retrieve the appropriate data. If you are not using ESAPI's logging and/or authentication and/or request binding utilities, you'll need to create your own implementation of this class. ''' ''Note: This is the interface you'll need to implement if you are not using ESAPI.'' '''

<pre>
The setting you'll need to modify in appsensor.properties to enable your own implementation is:

# This is the class that handles the utility retriever
AppSensor.asUtilities=org.owasp.appsensor.reference.DefaultASUtilities
</pre>
----

==== TrendLogger ====
The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/trendmonitoring/TrendLogger.java TrendLogger] interface is in place to handle the logging of events in order to monitor trends. The techniques for doing this vary widely depending upon environment. You'll most likely not want to use the existing [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/trendmonitoring/reference/InMemoryTrendLogger.java InMemoryTrendLogger] as it will scale very poorly. It is simply in place as a starting point for other implementations.

<pre>
The setting you'll need to modify in appsensor.properties to enable your own implementation is:

# This is the class that handles the trend logging
AppSensor.trendLogger=org.owasp.appsensor.trendmonitoring.reference.InMemoryTrendLogger
</pre>
----

AppSensor Developer Guide

2010-09-02T23:34:02Z

Augustd: /* ResponseAction */

= AppSensor Developer Guide =

The [[:Category:OWASP AppSensor Project|AppSensor Project]] describes an application layer intrusion detection system. There is a Java implementation of this system whose basic usage can be found in the [[AppSensor_GettingStarted|Getting Started]] guide. This document describes in more technical detail for developers how to use and extend AppSensor for a specific environment and application.

== Developer Overview ==
AppSensor is an application layer intrusion detection system. The concept in implementation is roughly analogous to an intrusion detection (and prevention) system in the network security world. However, this concept can be applied inside of an application in a more specific way that (importantly) reduces false positives, which is an issue that often plagues network intrusion detection systems. This means that the core of the AppSensor system performs detection, monitoring, and (possibly) response depending on configuration settings.

AppSensor has been built to be quite extensible from the ground up. Most of the system can be appreciably modified to your needs by simply extending certain key interfaces, and modifying the appsensor configuration file appropriately. This extensible design makes it possible for various configurations to be applied depending upon the application. For instance, in a small application, you may choose to use a simple file-based model for storing intrusions that are detected, whereas for a larger application, you may have a relational database serving as your data store. See the '''Extending AppSensor''' section below for specifics on what can be extended.

== Extending AppSensor ==
Below you will find the individual interfaces you are likely to extend in order to modify AppSensor for your environment.
----

==== IntrusionStore ====
The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/IntrusionStore.java IntrusionStore] interface represents, simply enough, the storage mechanism for any intrusions that occur in the system. The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/AppSensorIntrusionDetector.java AppSensorIntrusionDetector] takes care of adding the intrusions to the intrusion store. The current [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/reference/DefaultIntrusionStore.java DefaultIntrusionStore] class stores all of the intrusions in a simple HashMap. The class is fairly small and simple, though, so it is trivial to understand it's inner workings and to use similar concepts to build an implementation that suits your environment.

<pre>
The setting you'll need to modify in appsensor.properties to enable your own implementation is:

# This is the class that handles the response actions
AppSensor.responseAction=org.owasp.appsensor.intrusiondetection.reference.DefaultResponseAction
</pre>
----

==== ResponseAction ====
The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/ResponseAction.java ResponseAction] interface is used to simply respond to an intrusion once a threshold has been crossed. The decision for when to respond is handled by the [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/AppSensorIntrusionDetector.java AppSensorIntrusionDetector], but the actual handling of the response is delegated to implementations of this interface. The only reason to not use the [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/reference/DefaultResponseAction.java DefaultResponseAction] would be if you have additional response actions you need to take, or if you need to modify the handling of one of the existing responses. Again, the [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/reference/DefaultResponseAction.java DefaultResponseAction] should give you a good starting point for creating your own implementation.

<pre>
The setting you'll need to modify in appsensor.properties to enable your own implementation is:

# This is the class that handles the response actions
AppSensor.responseAction=org.owasp.appsensor.intrusiondetection.reference.DefaultResponseAction
</pre>
----

==== ASUtilities ====
The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/ASUtilities.java ASUtilities] interface handles a collection of concerns. It handles retrieving the current user of the application (ie. the user that made the current request and/or caused the current intrusion). In addition, it handles the retrieval of the logger as well as the current HTTP request. The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/reference/DefaultASUtilities.java DefaultASUtilities] implementation simply delegates to the equivalent ESAPI method calls to retrieve the appropriate data. If you are not using ESAPI's logging and/or authentication and/or request binding utilities, you'll need to create your own implementation of this class. ''' ''Note: This is the interface you'll need to implement if you are not using ESAPI.'' '''

<pre>
The setting you'll need to modify in appsensor.properties to enable your own implementation is:

# This is the class that handles the utility retriever
AppSensor.asUtilities=org.owasp.appsensor.reference.DefaultASUtilities
</pre>
----

==== TrendLogger ====
The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/trendmonitoring/TrendLogger.java TrendLogger] interface is in place to handle the logging of events in order to monitor trends. The techniques for doing this vary widely depending upon environment. You'll most likely not want to use the existing [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/trendmonitoring/reference/InMemoryTrendLogger.java InMemoryTrendLogger] as it will scale very poorly. It is simply in place as a starting point for other implementations.

<pre>
The setting you'll need to modify in appsensor.properties to enable your own implementation is:

# This is the class that handles the trend logging
AppSensor.trendLogger=org.owasp.appsensor.trendmonitoring.reference.InMemoryTrendLogger
</pre>
----

Talk:How to perform HTML entity encoding in Java

2008-08-25T21:48:51Z

Augustd:

==Status==
Released [[User:Stephendv|Stephendv]] 09:51, 14 January 2008 (EST)

==Reviewers==
* Dave Read

==General Discussion==

The Apache Jakarta Commons Lang package (as of version 2.2) contains a StringEscapeUtils class that contains this functionality. See the escapeHtml(String) method. The documentation states:

Escapes the characters in a String using HTML entities.

Supports all known HTML 4.0 entities, including funky accents. Note that the commonly used apostrophe escape character (') is not a legal entity and so is not supported).

Why go to all the trouble of computing int len and running the for loop if the input String is null? I suggest adding a sanity check to the top of the method:

if (s == null) return "";