OWASP - User contributions [en]

Staff-Projects/DefCon 27 Event

2019-07-12T19:11:56Z

Jmanico: defcon volunteer

= Overview =

DEFCON 27 Hacking Conference
* '''When:''' August 8-11, 2019
* '''Vendor Room Hours are:'''
** '''''Aug. 8th''''' - '''Thursday SETUP ONLY'''
*** 9 am Vendor Setup Available - 9 pm Room Closes
** '''''Aug. 9 & 10''''' - Friday and Saturday
*** Vendors can enter at 9 am
*** 10 am to 7 pm Doors Open to Attendees
** '''''Aug. 11th''''' - Sunday
*** Vendors can enter at 9 am
*** 10 am - 3 pm Doors Open to Attendees
*** 4 PM Tax Paperwork Due
*** 8 PM Load Out Complete
* '''Where:''' Paris, Bally's, & Planet Hollywood, Las Vegas
* OWASP Board requested and approved the conference

Three volunteers at the booth at all times

= Project Links =

* Event Link: https://www.defcon.org/index.html
* Floor Plan: https://www.owasp.org/index.php/File:DC27_Vendor_room_final.jpg
* Tickets are $300 CASH at the door.

= Goals =

Community Outreach initiative

= Milestones =

* 2019-02-28, DONE - [https://drive.google.com/open?id=14fH4iiMoo1XBCjKWoteQ_q9UL5EIxQ2GaQS_bB8U Vendor application] submitted [Lisa]
* 2019-03-30, DONE - Granted approval of vendor application by [DEFCON NO confirmation provided just email]
* 2019-04-01, DONE - Submitted a proposed budget for the event for approval [Lisa]
* 2019-04-04, DONE - Booth invoice submitted for payment [https://owasporg.atlassian.net/browse/OSD-2318 OSD-2318] payment sent ACH April 17, 2019 [Lisa/Mike/Virtual]
* 2019-06-14, Art Due from Artist [Jon McCoy]
** [https://drive.google.com/drive/u/0/folders/1G-L3xrh_3MvkeB_VKZgvVR5dxdJT3gib DEFCON 26 Artwork] (2018 historical data)
* 2019-06-14, DONE - Second invoice for balance due t-shirt artwork processed for payment [https://owasporg.atlassian.net/browse/OSD-2502 OSD-2502][Approved 6/17/2019]
* 2019-06-14, DONE - Printer contacted - quote on 1 t-shirt design, 6ft 3 sided tablecloth
* 2019-06-27, DONE - Final order to the printer including 2 designs, all black t-shirt, and adj qty with shipping info [DONE 6/26/2019 Lisa]
* 2019-06-28, DONE - Dragongraphics invoice entered for payment [https://owasporg.atlassian.net/browse/OSD-2542 OSD-2542]
* 2019-07-01, Final Art selected [DONE- T-shirt approved 6/17/19] STILL WAITING ON STICKER NEW ARTWORK & HANDOUTS
* 2019-07-10, Flyers(handouts) & sticker ordered [Lisa]
* 2019-08-08, DEFCON Booth Move-in
* Volunteers identified - Board Members attending

= Badge Plan =
9 Badges were purchased by the Foundation - Jon responsible to staff the booth.
* Conference/Exhibition Pass: Jim Manico
* Conference/Exhibition Pass: DAY 1 VOLUNTEER
* Conference/Exhibition Pass: DAY 2 VOLUNTEER
* Conference/Exhibition Pass: DAY 2 VOLUNTEER
* Conference/Exhibition Pass: DAY 3 VOLUNTEER
* Conference/Exhibition Pass: DAY 3 VOLUNTEER
* Conference/Exhibition Pass: Staff/Harold
* Conference/Exhibition Pass: Staff/Mike

= Leadership =

* Lisa Jones [OWASP Staff]
* Mike McCamon [Execitive Director of OWASP Foundation - Approval authority]
* Jon McCoy [OWASP Member jonmccoy@owasp.org] requested approval from the board to do the event and received approval for $ 3,500 for artwork. (2018 $2,500 spent on artwork for this event)

[[Category:Staff Projects]]

=Name & URLs=

* Name: DEFCON 27
* URL: https://www.defcon.org/index.html
* Cash at the door- $300.00
* Exhibition Information: Vendors must stay at Bally's or Paris Hotels in order to take advantage of the packaging center for [https://drive.google.com/open?id=13WgEk6sUq430ib6uNNQtwPqSGaWZH7YM logistical assistance] with receiving and picking up vendor booth event materials.
* 2019-06-27, Janet Whitaker[janetwhitaker68@gmail.com] from DefCon responded that Booth numbers not available yet. They are behind we should find out the first week in July sometime.
= Registration is not available. Only accept cash =

= Budget =
{| class="wikitable"
|Quantity
|Expenses:
|
|-
|
|Artwork for t-shirt & stickers
|$3,500
|-
|1
|Booth 8X8
|$1,100
|-
|
|Power
|$250
|-
|
|Internet
|$400
|-
|
|Tickets 6 Board & 2 staff
|$2,700
|-
|750
|t-shirts & printing (<$8 per)
|$6000
|-
|1
|table cloth
|$275
|-
|
|Stickers / print on both sides
|$1,000
|-
|
|Flyers estimate - Hand out?
|$350
|-
|Est.
|Packing & Handling fees
|$100
|-
|2
|Staff travel & expenses
|$5,000
|-
|9
|Board Hotel Accommodations
|$2,400
|-
|5
|Travel Assistance Grant $1,000
|$5,000
|-
|25
|Global AppSec Vouchers to 1st 25 Woman to donate
|20,000
|-
|
|Total
|48,075
|}
* 25 Vouchers for the first women to "make a donation" to the Foundation at our booth. A process will be setup after the event to solicit Travel Assistance Grants for a later conference. The approximate cost of this promotion is approximately $20,000.

== T-Shirt Order ==

NEW DESIGN
Men (adjusted to stay within budget)
* XXXL 20
* XXL 130
* XL 185
* L 185
* M 50
* S 10
Women
* XXXL 5
* XXL 10
* XL 10
* L 10
* M 5
OLD DESIGN
Men
* XXL 20
* XL 20
* L 20
Women
* XXXL 5
* XXL 10
* XL 10
* L 10
* M 5
[https://docs.google.com/spreadsheets/d/1xSahMqHHA6KmaQDe20HyHbo1fMnbDwHg3DkhQeuwtrw/edit#gid=1837428674 Comparison] with last year's information located.

[[Category:Staff Projects]]

Log Injection

2019-02-12T19:04:30Z

Jmanico: /* Code Execution via Log Injection */

{{Template:Attack}}

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

==Description==

Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.

Writing unvalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs. This is called log injection.

Log injection vulnerabilities occur when:

# Data enters an application from an untrusted source.
# The data is written to an application or system log file.

Successful log injection attacks can cause:

# Injection of new/bogus log events (log forging via log injection)
# Injection of XSS attacks, hoping that the malicious log event is viewed in a vulnerable web application
# Injection of commands that parsers (like PHP parsers) could execute

== Log Forging ==

In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1].

=== Log Forging Example ===

The following web application code attempts to read an integer value from a request object. If the value fails to parse as an integer, then the input is logged with an error message indicating what happened.

<pre>
...
String val = request.getParameter("val");
try {
int value = Integer.parseInt(val);
}
catch (NumberFormatException) {
log.info("Failed to parse val = " + val);
}
...
</pre>

If a user submits the string "twenty-one" for val, the following entry is logged:

<pre>
INFO: Failed to parse val=twenty-one
</pre>

However, if an attacker submits the string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", the following entry is logged:

<pre>
INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy
</pre>

Clearly, attackers can use this same mechanism to insert arbitrary log entries.

== Code Execution via Log Injection ==

PHP code can easily be added to a log file, for example:
<code><nowiki>https://www.somedomain.tld/index.php?file=</nowiki><?php echo phpinfo(); ?></code>

This stage it is called '''log file poisoning'''. If the log file is staged on a public directory and can be accessed via a HTTP GET request, the embedded PHP command may execute in certain circumstances. This is a form of [[Command Injection]] via Log Injection.

==References==

* [1] A. Muffet. The night the log was forged. http://doc.novsu.ac.ru/oreilly/tcpip/puis/ch10_05.htm.
* [2] G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
* https://medium.com/@shatabda/security-log-injection-what-how-a510cfc0f73b
* https://www.geeksforgeeks.org/log-injection/
* https://affinity-it-security.com/what-is-log-injection/

__NOTOC__

[[Category:Attack]]

Log Injection

2019-02-12T19:03:57Z

Jmanico: /* Code Execution via Log Injection */

{{Template:Attack}}

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

==Description==

Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.

Writing unvalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs. This is called log injection.

Log injection vulnerabilities occur when:

# Data enters an application from an untrusted source.
# The data is written to an application or system log file.

Successful log injection attacks can cause:

# Injection of new/bogus log events (log forging via log injection)
# Injection of XSS attacks, hoping that the malicious log event is viewed in a vulnerable web application
# Injection of commands that parsers (like PHP parsers) could execute

== Log Forging ==

In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1].

=== Log Forging Example ===

The following web application code attempts to read an integer value from a request object. If the value fails to parse as an integer, then the input is logged with an error message indicating what happened.

<pre>
...
String val = request.getParameter("val");
try {
int value = Integer.parseInt(val);
}
catch (NumberFormatException) {
log.info("Failed to parse val = " + val);
}
...
</pre>

If a user submits the string "twenty-one" for val, the following entry is logged:

<pre>
INFO: Failed to parse val=twenty-one
</pre>

However, if an attacker submits the string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", the following entry is logged:

<pre>
INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy
</pre>

Clearly, attackers can use this same mechanism to insert arbitrary log entries.

== Code Execution via Log Injection ==

PHP code can easily be added to a log file, for example:
<code><nowiki>https://www.somedomain.tld/index.php?file=</nowiki><?php echo phpinfo(); ?></code>

This stage it is called '''log file poisoning'''. If the log file is staged on a public directory and can be accessed via a HTTP GET request, the embedded PHP command may execute in certain circumstances. This is a form of [[Command_Injection]] via Log Injection.

==References==

* [1] A. Muffet. The night the log was forged. http://doc.novsu.ac.ru/oreilly/tcpip/puis/ch10_05.htm.
* [2] G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
* https://medium.com/@shatabda/security-log-injection-what-how-a510cfc0f73b
* https://www.geeksforgeeks.org/log-injection/
* https://affinity-it-security.com/what-is-log-injection/

__NOTOC__

[[Category:Attack]]

Log Injection

2019-02-12T19:02:52Z

Jmanico: /* Log Forging */

{{Template:Attack}}

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

==Description==

Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.

Writing unvalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs. This is called log injection.

Log injection vulnerabilities occur when:

# Data enters an application from an untrusted source.
# The data is written to an application or system log file.

Successful log injection attacks can cause:

# Injection of new/bogus log events (log forging via log injection)
# Injection of XSS attacks, hoping that the malicious log event is viewed in a vulnerable web application
# Injection of commands that parsers (like PHP parsers) could execute

== Log Forging ==

In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1].

=== Log Forging Example ===

The following web application code attempts to read an integer value from a request object. If the value fails to parse as an integer, then the input is logged with an error message indicating what happened.

<pre>
...
String val = request.getParameter("val");
try {
int value = Integer.parseInt(val);
}
catch (NumberFormatException) {
log.info("Failed to parse val = " + val);
}
...
</pre>

If a user submits the string "twenty-one" for val, the following entry is logged:

<pre>
INFO: Failed to parse val=twenty-one
</pre>

However, if an attacker submits the string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", the following entry is logged:

<pre>
INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy
</pre>

Clearly, attackers can use this same mechanism to insert arbitrary log entries.

== Code Execution via Log Injection ==

PHP code can easily be added to a log file, for example:
<code><nowiki>https://www.somedomain.tld/index.php?file=</nowiki><?php echo phpinfo(); ?></code>

This stage it is called '''log file poisoning'''. If the log file is staged on a public directory and can be accessed via a HTTP GET request, the embedded PHP command may execute in certain circumstances.

==References==

* [1] A. Muffet. The night the log was forged. http://doc.novsu.ac.ru/oreilly/tcpip/puis/ch10_05.htm.
* [2] G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
* https://medium.com/@shatabda/security-log-injection-what-how-a510cfc0f73b
* https://www.geeksforgeeks.org/log-injection/
* https://affinity-it-security.com/what-is-log-injection/

__NOTOC__

[[Category:Attack]]

Log Injection

2019-02-12T18:56:37Z

Jmanico: /* Examples */

{{Template:Attack}}

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

==Description==

Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.

Writing unvalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs. This is called log injection.

Log injection vulnerabilities occur when:

# Data enters an application from an untrusted source.
# The data is written to an application or system log file.

Successful log injection attacks can cause:

# Injection of new/bogus log events (log forging via log injection)
# Injection of XSS attacks, hoping that the malicious log event is viewed in a vulnerable web application
# Injection of commands that parsers (like PHP parsers) could execute

== Log Forging ==

In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1].

=== Log Forging Example ===

The following web application code attempts to read an integer value from a request object. If the value fails to parse as an integer, then the input is logged with an error message indicating what happened.

<pre>
...
String val = request.getParameter("val");
try {
int value = Integer.parseInt(val);
}
catch (NumberFormatException) {
log.info("Failed to parse val = " + val);
}
...
</pre>

If a user submits the string "twenty-one" for val, the following entry is logged:

<pre>
INFO: Failed to parse val=twenty-one
</pre>

However, if an attacker submits the string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", the following entry is logged:

<pre>
INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy
</pre>

Clearly, attackers can use this same mechanism to insert arbitrary log entries.

==References==

* [1] A. Muffet. The night the log was forged. http://doc.novsu.ac.ru/oreilly/tcpip/puis/ch10_05.htm.
* [2] G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
* https://medium.com/@shatabda/security-log-injection-what-how-a510cfc0f73b
* https://www.geeksforgeeks.org/log-injection/
* https://affinity-it-security.com/what-is-log-injection/

__NOTOC__

[[Category:Attack]]

Log Injection

2019-02-12T18:56:20Z

Jmanico: /* Description */

{{Template:Attack}}

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

==Description==

Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.

Writing unvalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs. This is called log injection.

Log injection vulnerabilities occur when:

# Data enters an application from an untrusted source.
# The data is written to an application or system log file.

Successful log injection attacks can cause:

# Injection of new/bogus log events (log forging via log injection)
# Injection of XSS attacks, hoping that the malicious log event is viewed in a vulnerable web application
# Injection of commands that parsers (like PHP parsers) could execute

== Log Forging ==

In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1].

==Examples==

The following web application code attempts to read an integer value from a request object. If the value fails to parse as an integer, then the input is logged with an error message indicating what happened.

<pre>
...
String val = request.getParameter("val");
try {
int value = Integer.parseInt(val);
}
catch (NumberFormatException) {
log.info("Failed to parse val = " + val);
}
...
</pre>

If a user submits the string "twenty-one" for val, the following entry is logged:

<pre>
INFO: Failed to parse val=twenty-one
</pre>

However, if an attacker submits the string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", the following entry is logged:

<pre>
INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy
</pre>

Clearly, attackers can use this same mechanism to insert arbitrary log entries.

==References==

* [1] A. Muffet. The night the log was forged. http://doc.novsu.ac.ru/oreilly/tcpip/puis/ch10_05.htm.
* [2] G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
* https://medium.com/@shatabda/security-log-injection-what-how-a510cfc0f73b
* https://www.geeksforgeeks.org/log-injection/
* https://affinity-it-security.com/what-is-log-injection/

__NOTOC__

[[Category:Attack]]

Log Injection

2019-02-12T18:54:51Z

Jmanico: /* Description */

{{Template:Attack}}

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

==Description==

Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.

Writing unvalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs. This is called log injection.

Log injection vulnerabilities occur when:

# Data enters an application from an untrusted source.
# The data is written to an application or system log file.

Successful log injection attacks can cause:

# Injection of new/bogus log events
# Injection of XSS attacks, hoping that the malicious log event is viewed in a vulnerable web application
# Injection of commands that parsers (like PHP parsers) could execute

In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1].

In other cases, an attacker may inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility [2].

==Examples==

The following web application code attempts to read an integer value from a request object. If the value fails to parse as an integer, then the input is logged with an error message indicating what happened.

<pre>
...
String val = request.getParameter("val");
try {
int value = Integer.parseInt(val);
}
catch (NumberFormatException) {
log.info("Failed to parse val = " + val);
}
...
</pre>

If a user submits the string "twenty-one" for val, the following entry is logged:

<pre>
INFO: Failed to parse val=twenty-one
</pre>

However, if an attacker submits the string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", the following entry is logged:

<pre>
INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy
</pre>

Clearly, attackers can use this same mechanism to insert arbitrary log entries.

==References==

* [1] A. Muffet. The night the log was forged. http://doc.novsu.ac.ru/oreilly/tcpip/puis/ch10_05.htm.
* [2] G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
* https://medium.com/@shatabda/security-log-injection-what-how-a510cfc0f73b
* https://www.geeksforgeeks.org/log-injection/
* https://affinity-it-security.com/what-is-log-injection/

__NOTOC__

[[Category:Attack]]

Log Injection

2019-02-12T18:54:41Z

Jmanico: /* Description */

{{Template:Attack}}

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

==Description==

Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.

Writing unvalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs. This is called log injection.

Log injection vulnerabilities occur when:

# Data enters an application from an untrusted source.
# The data is written to an application or system log file.

Successful log injection attacks can cause:

# Injection of new/bogus log events
# Injection of XSS attacks, hoping that the malicious log event is viewed in a vulnerable web application
# Injection of commands that parsers (like PHP parsers) could execute

In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1].

In other cases, an attacker may inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility [2].

==Examples==

The following web application code attempts to read an integer value from a request object. If the value fails to parse as an integer, then the input is logged with an error message indicating what happened.

<pre>
...
String val = request.getParameter("val");
try {
int value = Integer.parseInt(val);
}
catch (NumberFormatException) {
log.info("Failed to parse val = " + val);
}
...
</pre>

If a user submits the string "twenty-one" for val, the following entry is logged:

<pre>
INFO: Failed to parse val=twenty-one
</pre>

However, if an attacker submits the string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", the following entry is logged:

<pre>
INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy
</pre>

Clearly, attackers can use this same mechanism to insert arbitrary log entries.

==References==

* [1] A. Muffet. The night the log was forged. http://doc.novsu.ac.ru/oreilly/tcpip/puis/ch10_05.htm.
* [2] G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
* https://medium.com/@shatabda/security-log-injection-what-how-a510cfc0f73b
* https://www.geeksforgeeks.org/log-injection/
* https://affinity-it-security.com/what-is-log-injection/

__NOTOC__

[[Category:Attack]]

Log Injection

2019-02-12T18:44:42Z

Jmanico: adding more references from other editor

{{Template:Attack}}

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

==Description==

Writing unvalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs.

Log forging vulnerabilities occur when:

# Data enters an application from an untrusted source.
# The data is written to an application or system log file.

Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.

Interpretation of the log files may be hindered or misdirected if an attacker can supply data to the application that is subsequently logged verbatim. In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1]. In the worst case, an attacker may inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility [2].

==Examples==

The following web application code attempts to read an integer value from a request object. If the value fails to parse as an integer, then the input is logged with an error message indicating what happened.

<pre>
...
String val = request.getParameter("val");
try {
int value = Integer.parseInt(val);
}
catch (NumberFormatException) {
log.info("Failed to parse val = " + val);
}
...
</pre>

If a user submits the string "twenty-one" for val, the following entry is logged:

<pre>
INFO: Failed to parse val=twenty-one
</pre>

However, if an attacker submits the string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", the following entry is logged:

<pre>
INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy
</pre>

Clearly, attackers can use this same mechanism to insert arbitrary log entries.

==References==

* [1] A. Muffet. The night the log was forged. http://doc.novsu.ac.ru/oreilly/tcpip/puis/ch10_05.htm.
* [2] G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
* https://medium.com/@shatabda/security-log-injection-what-how-a510cfc0f73b
* https://www.geeksforgeeks.org/log-injection/
* https://affinity-it-security.com/what-is-log-injection/

__NOTOC__

[[Category:Attack]]

Log Injection

2019-02-12T18:43:14Z

Jmanico: returning to Jims version

Category:OWASP Application Security Verification Standard Project

2019-01-02T22:29:02Z

Jmanico: /* Related Projects */

= Home =
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]</div>
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

== What is ASVS? ==

The OWASP Application Security Verification Standard (ASVS) Project provides a basis for testing web application technical security controls and also provides developers with a list of requirements for secure development.

The primary aim of the '''OWASP Application Security Verification Standard (ASVS) Project''' is to normalize the range in the coverage and level of rigor available in the market when it comes to performing Web application security verification using a commercially-workable open standard. The standard provides a basis for testing application technical security controls, as well as any technical security controls in the environment, that are relied on to protect against vulnerabilities such as Cross-Site Scripting (XSS) and SQL injection. This standard can be used to establish a level of confidence in the security of Web applications. The requirements were developed with the following objectives in mind:

*'''Use as a metric''' - Provide application developers and application owners with a yardstick with which to assess the degree of trust that can be placed in their Web applications,
*'''Use as guidance''' - Provide guidance to security control developers as to what to build into security controls in order to satisfy application security requirements, and
*'''Use during procurement''' - Provide a basis for specifying application security verification requirements in contracts.

== OWASP ASVS 4.0 will be released in early 2019 ==

Please note there will <b>not be a 3.1 release</b> and we will be going directly from <b>ASVS 3.0.1 to 4.0 in February 2019</b>!

== Email List ==

[[Image:Asvs-bulb.jpg]] [https://lists.owasp.org/mailman/listinfo/owasp-application-security-verification-standard Project Email List]

== Project Leader ==

Daniel Cuthbert [mailto:Daniel.Cuthbert@owasp.org @]<br/>
Andrew van der Stock [mailto:vanderaj@owasp.org @]<br/>
Jim Manico [mailto:jim.manico@owasp.org @]

== Related Projects ==

[[Image:Asvs-satellite.jpg]]'''OWASP Resources'''

*[https://www.owasp.org/index.php/OWASP_Proactive_Controls OWASP Top Ten Proactive Controls (2018)]
*[http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project OWASP Top Ten Risks (2017)]
*[https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series OWASP Cheatsheet Series]

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

== Quick Download ==

ASVS 3.0.1 in English.<br/>
* [[Media:OWASP_Application_Security_Verification_Standard_3.0.1.pdf|Download PDF - 1.7 MB]]
* [[Media:OWASP_Application_Security_Verification_Standard_3.0.1.docx|Download Word - 835 kB]]

== News and Events ==

* [9 March 2018] [https://docs.google.com/spreadsheets/d/1ic7gsib--Cn4ujrA8rhvzuUmMFpQ2Jkl96SZDCEtqJg/edit?ts=5a6bafe1#gid=950526877 OWASP Application Security Verification Standard 3.1 Spreadsheet] created by August Detlefsen
* [29 June 2016] [[Media:OWASP_Application_Security_Verification_Standard_3.0.1.pdf|Version 3.0.1]] released!
* [9 Oct 2015] Version 3.0 released
* [20 May 2015] "First Cut" Version 3.0 released
* [11 Aug 2014] Version 2.0 released

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-flagship-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_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=]]
|-
| 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_DOC.jpg|link=]]
|}

|}

= Downloads =

'''Application Security Verification Standard 3.0.1 '''

== ASVS 3.0.1 in English ==
* [[Media:OWASP_Application_Security_Verification_Standard_3.0.1.pdf|Download PDF - 1.7 MB]]
* [[Media:OWASP_Application_Security_Verification_Standard_3.0.1.docx|Download Word - 835 kB]]

== ASVS 3.0.1 in Spanish==
* [[Media:Estándar_de_Verificación_de_Seguridad_en_Aplicaciones_3.0.1.pdf|Download PDF - 1.7 MB]]
* [[Media:Estándar_de_Verificación_de_Seguridad_en_Aplicaciones_3.0.1.docx|Download Word - 835 kB]]

== ASVS 3.0.1 in Polish==
* [[Media:OWASP Application Security Verification Standard 3.0.1 PL.pdf|Download PDF - 1.5 MB]]

== ASVS 3.0.1 in Persian==
* [[Media:OWASP ASVS 3.0.1 (Persian).pdf|Download PDF - 2.84 MB]]

We are looking for translators for this version. If you can help us, please contact the project mail list!

'''Legacy Application Security Verification Standard 3.0'''

== ASVS 3.0 in English ==
* [[Media:OWASPApplicationSecurityVerificationStandard3.0.pdf|download PDF - 1.2 MB]]
* [[Media:ASVS-excel.xlsx|ASVS 3.0 excel sheet - 39 kB]]

== Older versions ==

'''Application Security Verification Standard 2.0 (final)'''

* ASVS 2.0 in English ([[Media:OWASP_ASVS_Version_2.pdf|download PDF - 1.6 MB]])
* ASVS 2.0 in English ([[Media:OWASP_ASVS_Version_2.docx|download Word - 1.0MB]])
* ASVS 2.0 in Persian ([[Media:OWASP_ASVS_Version_2_Persian.pdf|download PDF - 1.6MB]])
* ASVS 2.0 in Polish (checklist) ([[Media:Asvs_2_PL.xlsx|download Excel]])

'''Application Security Verification Standard 1.0 - 2009'''

* ASVS 1.0 Final (English) ([[Media:OWASP_ASVS_2009_Web_App_Std_Release.pdf|download PDF - 2.5 MB]])
* ASVS 1.0 Final (English) ([[Media:OWASP_ASVS_2009_Web_App_Std_Release.doc|download Word - 2.3 MB]])

= Acknowledgements =

== Volunteers ==

=== Version 3 (2015) ===

Project Leaders

*Daniel Cuthbert
*Andrew van der Stock

Lead Author
*Jim Manico

Other reviewers and contributors
*Boy Baukema
*Ari Kesäniemi
*Colin Watson
*François-Eric Guyomarc’h
*Cristinel Dumitru
*James Holland
*Gary Robinson
*Stephen de Vries
*Glenn Ten Cate
*Riccardo Ten Cate
*Martin Knobloch
*Abhinav Sejpal
*David Ryan
*Steven van der Baan
*Ryan Dewhurst
*Raoul Endres
*Roberto Martelloni

=== Version 2 (2014) ===

Project leaders
*Sahba Kazerooni
*Daniel Cuthbert

Lead authors
*Andrew van der Stock
*Sahba Kazerooni
*Daniel Cuthbert
*Krishna Raja

Other reviewers and contributors
*Jerome Athias
*Boy Baukema
*Archangel Cuison
*Sebastien.Deleersnyder
*Antonio Fontes
*Evan Gaustad
*Safuat Hamdy
*Ari Kesäniemi
*Scott Luc
*Jim Manico
*Mait Peekma
*Pekka Sillanpää
*Jeff Sergeant
*Etienne Stalmans
*Colin Watson
*Dr. Emin İslam Tatlı

Translators
*Abbas Javan Jafari (Persian)
*Sajjad Pourali (Persian)

=== Version 2009 ===

Project leader
*Mike Boberski

Lead authors
*Mike Boberski
*Jeff Williams
*Dave Wichers

Other reviewers and contributors

Pierre Parrend (OWASP Summer of Code), Andrew van der Stock, Nam Nguyen, John Martin, Gaurang Shah, Theodore Winograd, Stan Wisseman, Barry Boyd, Steve Coyle, Paul Douthit, Ken Huang, Dave Hausladen, Mandeep Khera Scott Matsumoto, John Steven, Stephen de Vries, Dan Cornell, Shouvik Bardhan, Dr. Sarbari Gupta, Eoin Keary, Richard Campbell, Matt Presson, Jeff LoSapio, Liz Fong, George Lawless, Dave van Stein, Terrie Diaz, Ketan Dilipkumar Vyas, Bedirhan Urgun, Dr. Thomas Braun, Colin Watson, Jeremiah Grossman.

== OWASP Summer of Code 2008 ==

The OWASP Foundation sponsored the OWASP Application Security Verification Standard Project during the OWASP Summer of Code 2008.

= Glossary =

[[Image:Asvs-letters.jpg]]'''ASVS Terminology'''

*'''Access Control''' – A means of restricting access to files, referenced functions, URLs, and data based on the identity of users and/or groups to which they belong.
*'''Application Component''' – An individual or group of source files, libraries, and/or executables, as defined by the verifier for a particular application.
*'''Application Security''' – Application-level security focuses on the analysis of components that comprise the application layer of the Open Systems Interconnection Reference Model (OSI Model), rather than focusing on for example the underlying operating system or connected networks.
*'''Application Security Verification''' – The technical assessment of an application against the OWASP ASVS.
*'''Application Security Verification Report''' – A report that documents the overall results and supporting analysis produced by the verifier for a particular application.
*'''Application Security Verification Standard (ASVS)''' – An OWASP standard that defines four levels of application security verification for applications.
*'''Authentication''' – The verification of the claimed identity of an application user.
*'''Automated Verification''' – The use of automated tools (either dynamic analysis tools, static analysis tools, or both) that use vulnerability signatures to find problems.
*'''Back Doors''' – A type of malicious code that allows unauthorized access to an application.
*'''Blacklist''' – A list of data or operations that are not permitted, for example a list of characters that are not allowed as input.
*'''Common Criteria (CC)''' – A multipart standard that can be used as the basis for the verification of the design and implementation of security controls in IT products.
*'''Communication Security''' – The protection of application data when it is transmitted between application components, between clients and servers, and between external systems and the application.
*'''Design Verification''' – The technical assessment of the security architecture of an application.
*'''Internal Verification''' – The technical assessment of specific aspects of the security architecture of an application as defined in the OWASP ASVS.
*'''Cryptographic module''' – Hardware, software, and/or firmware that implements cryptographic algorithms and/or generates cryptographic keys.
*'''Denial of Service (DOS) Attacks''' – The flooding of an application with more requests than it can handle.
*'''Dynamic Verification''' – The use of automated tools that use vulnerability signatures to find problems during the execution of an application.
*'''Easter Eggs''' – A type of malicious code that does not run until a specific user input event occurs.
*'''External Systems''' – A server-side application or service that is not part of the application.
*'''FIPS 140-2''' – A standard that can be used as the basis for the verification of the design and implementation of cryptographic modules
*'''Input Validation''' – The canonicalization and validation of untrusted user input.
*'''Malicious Code''' – Code introduced into an application during its development unbeknownst to the application owner which circumvents the application’s intended security policy. Not the same as malware such as a virus or worm!
*'''Malware''' – Executable code that is introduced into an application during runtime without the knowledge of the application user or administrator.
*'''Open Web Application Security Project (OWASP)''' – The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. See: http://www.owasp.org/
*'''Output Validation''' – The canonicalization and validation of application output to Web browsers and to external systems.
*'''OWASP Enterprise Security API (ESAPI)''' – A free and open collection of all the security methods that developers need to build secure Web applications. See: http://www.owasp.org/index.php/ESAPI
*'''OWASP Risk Rating Methodology''' – A risk rating methodology that has been customized for application security. See: http://www.owasp.org/index.php/How_to_value_the_real_risk
*'''OWASP Testing Guide''' – A document designed to help organizations understand what comprises a testing program, and to help them identify the steps needed to build and operate that testing program. See: http://www.owasp.org/index.php/Category:OWASP_Testing_Project
*'''OWASP Top Ten''' – A document that represents a broad consensus about what the most critical Web application security flaws are. See: http://www.owasp.org/index.php/Top10
*'''Positive''' – See whitelist.
*'''Salami Attack''' – A type of malicious code that is used to redirect small amounts of money without detection in financial transactions.
*'''Security Architecture''' – An abstraction of an application’s design that identifies and describes where and how security controls are used, and also identifies and describes the location and sensitivity of both user and application data.
*'''Security Control''' – A function or component that performs a security check (e.g. an access control check) or when called results in a security effect (e.g. generating an audit record).
*'''Security Configuration''' – The runtime configuration of an application that affects how security controls are used.
*'''Static Verification''' – The use of automated tools that use vulnerability signatures to find problems in application source code.
*'''Target of Verification (TOV)''' – If you are performing an application security verification according to the OWASP ASVS requirements, the verification will be of a particular application. This application is called the "Target of Verification" or simply the TOV.
*'''Threat Modeling''' - A technique consisting of developing increasingly refined security architectures to identify threat agents, security zones, security controls, and important technical and business assets.
*'''Time Bomb''' – A type of malicious code that does not run until a preconfigured time or date elapses.
*'''Verifier''' - The person or team that is reviewing an application against the OWASP ASVS requirements.
*'''Whitelist''' – A list of permitted data or operations, for example a list of characters that are allowed to perform input validation.

= ASVS Users =
[[Image:Asvs-handshake.JPG]]

A broad range of companies and agencies around the globe have added ASVS to their software assurance tool boxes, including [http://www.aspectsecurity.com Aspect Security], [http://www.astyran.com Astyran], [http://www.boozallen.com Booz Allen Hamilton], [http://casabasecurity.com Casaba Security], [http://www.cgi.com/web/en/industries/governments/us_federal/services_solutions.htm CGI Federal], [http://denimgroup.com Denim Group], [http://etebaran.com Etebaran Informatics], [http://www.mindedsecurity.com Minded Security], [http://www.nixu.com Nixu], [http://www.pstestware.com/ ps_testware], [http://www.proactiverisk.com Proactive Risk], [http://quince.co.uk Quince Associates Limited (SeeMyData)], [http://www.serpro.gov.br/ Serviço Federal de Processamento de Dados (SERPRO)], [http://www.udistrital.edu.co/ Universidad Distrital Francisco José de Caldas] Organizations listed are not accredited by OWASP. Neither their products or services have been endorsed by OWASP. Use of ASVS may include for example providing verification services using the standard. Use of ASVS may also include for example performing internal evaluation of products with the OWASP ASVS in mind, and NOT making any claims of meeting any given level in the standard. Please let us know how your organization is using OWASP ASVS. Include your name, organization's name, and brief description of how you use the standard. The project lead can be reached [mailto:sahba@securitycompass.com here].

= Precedents-Interpretations =

'''PI-0001: Are there levels between the levels?'''

*Issue: Are there levels between the levels for the cases where "The specification for an application may require OWASP ASVS Level N, but it could also include other additional detailed requirements such as from a higher ASVS level"?
*Resolution: No. Use of alternate level definitions or notations such as "ASVS Level 1B+" is discouraged.
*References: ASVS section "Application Security Verification Levels"

'''PI-0002: Is use of a master key simply another level of indirection?'''

*Issue: If a master key is stored as plaintext, isn't using a master key simply another level of indirection?
*Resolution: No. There is a strong rationale for having a "master key" stored in a secure location that is used to encrypt all other secrets. In many applications, there are lots of secrets stored in many different locations. This greatly increases the likelihood that one of them will be compromised. Having a single master key makes managing the protection considerably simpler and is not simply a level of indirection.
*References: ASVS verification requirement V2.14

'''PI-0003: What is a "TOV" or "Target of Verification"?'''

*Issue: New terminology
*Resolution: If you are performing an application security verification according to ASVS, the verification will be of a particular application. This application is called the "Target of Verification" or simply the TOV. The TOV should be identified in verification documentation as follows:
**TOV Identification – <name and version of the application> or <Application name>, <application version>, dynamic testing was performed in a staging environment, not the production environment
**TOV Developer – <insert name of the developer or verification customer>
*References: ASVS section "Approach"

= Internationalization =

[[Image:Asvs-writing.JPG]]
If you can help with translations, please download the latest draft here:

https://github.com/OWASP/ASVS

If there are any incomprehensible English idiom or phrases in there, please don't hesitate to ask for clarification, because if it's hard to translate, it's almost certainly wrong in English as well. We recommend logging translation issues in GitHub, too, so please make yourself known.

Translations are coordinated through OWASP's Crowd In account, so you don't have to do the entire thing yourself.

https://crowdin.com/project/owasp-asvs/

You don't HAVE to use Crowd In, but it would be nice to indicate to other native speakers of your language that you are willing to work together. This is a 70 page document, and in all honesty, will take a dedicated person a week or more to translate, so please please please work together rather than apart. You have full access to the original document and the original images, so you have everything I have.

= Archive - Previous Version =

'''*Please note that ASVS is currently on version 3.0. The information on this page is for archival purposes only.*'''

[[Image:Asvs-step1.jpg]]'1. About ASVS 1.0'

*Video presentation in English [https://www.youtube.com/watch?v=Ba6ncpIfaJA (YouTube)]
*ASVS vs. WASC et al [http://www.owasp.org/index.php/ASVS_vs_WASC_Et_Al (Wiki)]

[[Image:Asvs-step2.jpg]]'2. Get ASVS 1.0'

*ASVS in Bahasa Indonesia (Indonesian language) ([http://owasp-asvs.googlecode.com/files/asvs-webapp-release-2009-id.pdf PDF])
*ASVS in Bahasa Malaysia (Malay) (Currently under development!)
*ASVS in Chinese(Currently under development!)
*ASVS in English ([http://www.owasp.org/images/4/4e/OWASP_ASVS_2009_Web_App_Std_Release.pdf PDF], [http://www.owasp.org/images/3/35/OWASP_ASVS_2009_Web_App_Std_Release.doc Word], [http://code.google.com/p/owasp-asvs/wiki/ASVS '''Online'''], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-xml.zip XML])
*ASVS in French ([http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-fr.pdf PDF], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-fr.odt OpenOffice])
*ASVS in German ([http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-de.pdf PDF], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-de.doc Word])
*ASVS in Hungarian (Currently under development!)
*ASVS in Japanese ([http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-jp.pdf PDF], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-jp.doc Word])
*ASVS in Persian (Farsi) ([http://abiusx.com/archive/document/OWASP-ASVS-fa-20111115.pdf PDF]) beta 0.7
*ASVS in Polish ([http://owasp-asvs.googlecode.com/files/asvs-webapp-release-2009-pl.pdf PDF])
*ASVS in Portuguese-Brazil ([http://owasp-asvs.googlecode.com/files/asvs-webapp-release-2009-pt-br.pdf PDF])
*ASVS in Spanish (Currently under development!)
*ASVS in Thai (Currently under development!)

[[Image:Asvs-step3.jpg]]'3. Learn ASVS 1.0'

*ASVS Article: Getting Started Using ASVS ([http://www.owasp.org/images/f/f8/OWASP_ASVS_Article_-_Getting_Started_Using_ASVS.pdf PDF])
*ASVS Article: Code Reviews and Other Verification Activities: USELESS Unless Acted Upon IMMEDIATELY [http://www.owasp.org/index.php/Code_Reviews_and_Other_Verification_Activities:_USELESS_Unless_Acted_Upon_IMMEDIATELY (Wiki)]
*ASVS Article: Agile Software Development: Don't Forget EVIL User Stories ([http://www.owasp.org/index.php/Agile_Software_Development:_Don%27t_Forget_EVIL_User_Stories Wiki])
*ASVS Article: Man vs. Code ([http://www.owasp.org/index.php/Man_vs._Code Wiki])
*ASVS Article: Getting started designing for a level of assurance ([http://www.owasp.org/images/0/01/Getting_started_designing_for_a_level_of_assurance.pdf PDF])
*ASVS Template: Sample verification fee schedule template ([http://www.owasp.org/index.php/Image:Sample_ASVS_Fee_Schedule_Template.xls Excel])
*ASVS Template: Sample verification report template ([http://www.owasp.org/index.php/Image:Sample_ASVS_Report_Template.doc Word])
*ASVS Training: An ASVS training presentation ([http://www.owasp.org/index.php/Image:OWASP_AU_Secure_Architecture_and_Coding.ppt PowerPoint])
*ASVS Presentation: Executive-Level Presentation ([http://www.owasp.org/images/9/99/About_OWASP_ASVS_Executive_Presentation.ppt PowerPoint])
*ASVS Presentation: Presentation Abstract ([http://www.owasp.org/images/1/10/OWASP_ASVS_Presentation_Abstract.doc Word])
*Articles [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project#Articles_Below_-_More_About_ASVS_and_Using_It (More About ASVS and Using It)]

__NOTOC__ <headertabs />

[[Category:OWASP_Project|Application Security Verification Standard Project]]
[[Category:OWASP_Document]]
[[Category:OWASP_Download]]
[[Category:OWASP_Release_Quality_Document|OWASP Stable Quality Document]]
[[Category:SAMM-CR-1]]
[[Category:SAMM-DR-2]]
[[Category:SAMM-ST-3]]

Category:OWASP Application Security Verification Standard Project

2019-01-02T22:28:04Z

Jmanico: /* OWASP ASVS 4.0 will be released in early 2019 */

= Home =
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]</div>
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

== What is ASVS? ==

The OWASP Application Security Verification Standard (ASVS) Project provides a basis for testing web application technical security controls and also provides developers with a list of requirements for secure development.

The primary aim of the '''OWASP Application Security Verification Standard (ASVS) Project''' is to normalize the range in the coverage and level of rigor available in the market when it comes to performing Web application security verification using a commercially-workable open standard. The standard provides a basis for testing application technical security controls, as well as any technical security controls in the environment, that are relied on to protect against vulnerabilities such as Cross-Site Scripting (XSS) and SQL injection. This standard can be used to establish a level of confidence in the security of Web applications. The requirements were developed with the following objectives in mind:

*'''Use as a metric''' - Provide application developers and application owners with a yardstick with which to assess the degree of trust that can be placed in their Web applications,
*'''Use as guidance''' - Provide guidance to security control developers as to what to build into security controls in order to satisfy application security requirements, and
*'''Use during procurement''' - Provide a basis for specifying application security verification requirements in contracts.

== OWASP ASVS 4.0 will be released in early 2019 ==

Please note there will <b>not be a 3.1 release</b> and we will be going directly from <b>ASVS 3.0.1 to 4.0 in February 2019</b>!

== Email List ==

[[Image:Asvs-bulb.jpg]] [https://lists.owasp.org/mailman/listinfo/owasp-application-security-verification-standard Project Email List]

== Project Leader ==

Daniel Cuthbert [mailto:Daniel.Cuthbert@owasp.org @]<br/>
Andrew van der Stock [mailto:vanderaj@owasp.org @]<br/>
Jim Manico [mailto:jim.manico@owasp.org @]

== Related Projects ==

[[Image:Asvs-satellite.jpg]]'''OWASP Resources'''

*[https://www.owasp.org/index.php/OWASP_Proactive_Controls OWASP Top Ten Proactive Controls (2016)]
*[http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project OWASP Top Ten Risks (2013)]
*[http://www.owasp.org/index.php/Category:OWASP_Guide_Project OWASP Development Guide]

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

== Quick Download ==

ASVS 3.0.1 in English.<br/>
* [[Media:OWASP_Application_Security_Verification_Standard_3.0.1.pdf|Download PDF - 1.7 MB]]
* [[Media:OWASP_Application_Security_Verification_Standard_3.0.1.docx|Download Word - 835 kB]]

== News and Events ==

* [9 March 2018] [https://docs.google.com/spreadsheets/d/1ic7gsib--Cn4ujrA8rhvzuUmMFpQ2Jkl96SZDCEtqJg/edit?ts=5a6bafe1#gid=950526877 OWASP Application Security Verification Standard 3.1 Spreadsheet] created by August Detlefsen
* [29 June 2016] [[Media:OWASP_Application_Security_Verification_Standard_3.0.1.pdf|Version 3.0.1]] released!
* [9 Oct 2015] Version 3.0 released
* [20 May 2015] "First Cut" Version 3.0 released
* [11 Aug 2014] Version 2.0 released

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-flagship-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_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=]]
|-
| 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_DOC.jpg|link=]]
|}

|}

= Downloads =

'''Application Security Verification Standard 3.0.1 '''

== ASVS 3.0.1 in English ==
* [[Media:OWASP_Application_Security_Verification_Standard_3.0.1.pdf|Download PDF - 1.7 MB]]
* [[Media:OWASP_Application_Security_Verification_Standard_3.0.1.docx|Download Word - 835 kB]]

== ASVS 3.0.1 in Spanish==
* [[Media:Estándar_de_Verificación_de_Seguridad_en_Aplicaciones_3.0.1.pdf|Download PDF - 1.7 MB]]
* [[Media:Estándar_de_Verificación_de_Seguridad_en_Aplicaciones_3.0.1.docx|Download Word - 835 kB]]

== ASVS 3.0.1 in Polish==
* [[Media:OWASP Application Security Verification Standard 3.0.1 PL.pdf|Download PDF - 1.5 MB]]

== ASVS 3.0.1 in Persian==
* [[Media:OWASP ASVS 3.0.1 (Persian).pdf|Download PDF - 2.84 MB]]

We are looking for translators for this version. If you can help us, please contact the project mail list!

'''Legacy Application Security Verification Standard 3.0'''

== ASVS 3.0 in English ==
* [[Media:OWASPApplicationSecurityVerificationStandard3.0.pdf|download PDF - 1.2 MB]]
* [[Media:ASVS-excel.xlsx|ASVS 3.0 excel sheet - 39 kB]]

== Older versions ==

'''Application Security Verification Standard 2.0 (final)'''

* ASVS 2.0 in English ([[Media:OWASP_ASVS_Version_2.pdf|download PDF - 1.6 MB]])
* ASVS 2.0 in English ([[Media:OWASP_ASVS_Version_2.docx|download Word - 1.0MB]])
* ASVS 2.0 in Persian ([[Media:OWASP_ASVS_Version_2_Persian.pdf|download PDF - 1.6MB]])
* ASVS 2.0 in Polish (checklist) ([[Media:Asvs_2_PL.xlsx|download Excel]])

'''Application Security Verification Standard 1.0 - 2009'''

* ASVS 1.0 Final (English) ([[Media:OWASP_ASVS_2009_Web_App_Std_Release.pdf|download PDF - 2.5 MB]])
* ASVS 1.0 Final (English) ([[Media:OWASP_ASVS_2009_Web_App_Std_Release.doc|download Word - 2.3 MB]])

= Acknowledgements =

== Volunteers ==

=== Version 3 (2015) ===

Project Leaders

*Daniel Cuthbert
*Andrew van der Stock

Lead Author
*Jim Manico

Other reviewers and contributors
*Boy Baukema
*Ari Kesäniemi
*Colin Watson
*François-Eric Guyomarc’h
*Cristinel Dumitru
*James Holland
*Gary Robinson
*Stephen de Vries
*Glenn Ten Cate
*Riccardo Ten Cate
*Martin Knobloch
*Abhinav Sejpal
*David Ryan
*Steven van der Baan
*Ryan Dewhurst
*Raoul Endres
*Roberto Martelloni

=== Version 2 (2014) ===

Project leaders
*Sahba Kazerooni
*Daniel Cuthbert

Lead authors
*Andrew van der Stock
*Sahba Kazerooni
*Daniel Cuthbert
*Krishna Raja

Other reviewers and contributors
*Jerome Athias
*Boy Baukema
*Archangel Cuison
*Sebastien.Deleersnyder
*Antonio Fontes
*Evan Gaustad
*Safuat Hamdy
*Ari Kesäniemi
*Scott Luc
*Jim Manico
*Mait Peekma
*Pekka Sillanpää
*Jeff Sergeant
*Etienne Stalmans
*Colin Watson
*Dr. Emin İslam Tatlı

Translators
*Abbas Javan Jafari (Persian)
*Sajjad Pourali (Persian)

=== Version 2009 ===

Project leader
*Mike Boberski

Lead authors
*Mike Boberski
*Jeff Williams
*Dave Wichers

Other reviewers and contributors

Pierre Parrend (OWASP Summer of Code), Andrew van der Stock, Nam Nguyen, John Martin, Gaurang Shah, Theodore Winograd, Stan Wisseman, Barry Boyd, Steve Coyle, Paul Douthit, Ken Huang, Dave Hausladen, Mandeep Khera Scott Matsumoto, John Steven, Stephen de Vries, Dan Cornell, Shouvik Bardhan, Dr. Sarbari Gupta, Eoin Keary, Richard Campbell, Matt Presson, Jeff LoSapio, Liz Fong, George Lawless, Dave van Stein, Terrie Diaz, Ketan Dilipkumar Vyas, Bedirhan Urgun, Dr. Thomas Braun, Colin Watson, Jeremiah Grossman.

== OWASP Summer of Code 2008 ==

The OWASP Foundation sponsored the OWASP Application Security Verification Standard Project during the OWASP Summer of Code 2008.

= Glossary =

[[Image:Asvs-letters.jpg]]'''ASVS Terminology'''

*'''Access Control''' – A means of restricting access to files, referenced functions, URLs, and data based on the identity of users and/or groups to which they belong.
*'''Application Component''' – An individual or group of source files, libraries, and/or executables, as defined by the verifier for a particular application.
*'''Application Security''' – Application-level security focuses on the analysis of components that comprise the application layer of the Open Systems Interconnection Reference Model (OSI Model), rather than focusing on for example the underlying operating system or connected networks.
*'''Application Security Verification''' – The technical assessment of an application against the OWASP ASVS.
*'''Application Security Verification Report''' – A report that documents the overall results and supporting analysis produced by the verifier for a particular application.
*'''Application Security Verification Standard (ASVS)''' – An OWASP standard that defines four levels of application security verification for applications.
*'''Authentication''' – The verification of the claimed identity of an application user.
*'''Automated Verification''' – The use of automated tools (either dynamic analysis tools, static analysis tools, or both) that use vulnerability signatures to find problems.
*'''Back Doors''' – A type of malicious code that allows unauthorized access to an application.
*'''Blacklist''' – A list of data or operations that are not permitted, for example a list of characters that are not allowed as input.
*'''Common Criteria (CC)''' – A multipart standard that can be used as the basis for the verification of the design and implementation of security controls in IT products.
*'''Communication Security''' – The protection of application data when it is transmitted between application components, between clients and servers, and between external systems and the application.
*'''Design Verification''' – The technical assessment of the security architecture of an application.
*'''Internal Verification''' – The technical assessment of specific aspects of the security architecture of an application as defined in the OWASP ASVS.
*'''Cryptographic module''' – Hardware, software, and/or firmware that implements cryptographic algorithms and/or generates cryptographic keys.
*'''Denial of Service (DOS) Attacks''' – The flooding of an application with more requests than it can handle.
*'''Dynamic Verification''' – The use of automated tools that use vulnerability signatures to find problems during the execution of an application.
*'''Easter Eggs''' – A type of malicious code that does not run until a specific user input event occurs.
*'''External Systems''' – A server-side application or service that is not part of the application.
*'''FIPS 140-2''' – A standard that can be used as the basis for the verification of the design and implementation of cryptographic modules
*'''Input Validation''' – The canonicalization and validation of untrusted user input.
*'''Malicious Code''' – Code introduced into an application during its development unbeknownst to the application owner which circumvents the application’s intended security policy. Not the same as malware such as a virus or worm!
*'''Malware''' – Executable code that is introduced into an application during runtime without the knowledge of the application user or administrator.
*'''Open Web Application Security Project (OWASP)''' – The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. See: http://www.owasp.org/
*'''Output Validation''' – The canonicalization and validation of application output to Web browsers and to external systems.
*'''OWASP Enterprise Security API (ESAPI)''' – A free and open collection of all the security methods that developers need to build secure Web applications. See: http://www.owasp.org/index.php/ESAPI
*'''OWASP Risk Rating Methodology''' – A risk rating methodology that has been customized for application security. See: http://www.owasp.org/index.php/How_to_value_the_real_risk
*'''OWASP Testing Guide''' – A document designed to help organizations understand what comprises a testing program, and to help them identify the steps needed to build and operate that testing program. See: http://www.owasp.org/index.php/Category:OWASP_Testing_Project
*'''OWASP Top Ten''' – A document that represents a broad consensus about what the most critical Web application security flaws are. See: http://www.owasp.org/index.php/Top10
*'''Positive''' – See whitelist.
*'''Salami Attack''' – A type of malicious code that is used to redirect small amounts of money without detection in financial transactions.
*'''Security Architecture''' – An abstraction of an application’s design that identifies and describes where and how security controls are used, and also identifies and describes the location and sensitivity of both user and application data.
*'''Security Control''' – A function or component that performs a security check (e.g. an access control check) or when called results in a security effect (e.g. generating an audit record).
*'''Security Configuration''' – The runtime configuration of an application that affects how security controls are used.
*'''Static Verification''' – The use of automated tools that use vulnerability signatures to find problems in application source code.
*'''Target of Verification (TOV)''' – If you are performing an application security verification according to the OWASP ASVS requirements, the verification will be of a particular application. This application is called the "Target of Verification" or simply the TOV.
*'''Threat Modeling''' - A technique consisting of developing increasingly refined security architectures to identify threat agents, security zones, security controls, and important technical and business assets.
*'''Time Bomb''' – A type of malicious code that does not run until a preconfigured time or date elapses.
*'''Verifier''' - The person or team that is reviewing an application against the OWASP ASVS requirements.
*'''Whitelist''' – A list of permitted data or operations, for example a list of characters that are allowed to perform input validation.

= ASVS Users =
[[Image:Asvs-handshake.JPG]]

A broad range of companies and agencies around the globe have added ASVS to their software assurance tool boxes, including [http://www.aspectsecurity.com Aspect Security], [http://www.astyran.com Astyran], [http://www.boozallen.com Booz Allen Hamilton], [http://casabasecurity.com Casaba Security], [http://www.cgi.com/web/en/industries/governments/us_federal/services_solutions.htm CGI Federal], [http://denimgroup.com Denim Group], [http://etebaran.com Etebaran Informatics], [http://www.mindedsecurity.com Minded Security], [http://www.nixu.com Nixu], [http://www.pstestware.com/ ps_testware], [http://www.proactiverisk.com Proactive Risk], [http://quince.co.uk Quince Associates Limited (SeeMyData)], [http://www.serpro.gov.br/ Serviço Federal de Processamento de Dados (SERPRO)], [http://www.udistrital.edu.co/ Universidad Distrital Francisco José de Caldas] Organizations listed are not accredited by OWASP. Neither their products or services have been endorsed by OWASP. Use of ASVS may include for example providing verification services using the standard. Use of ASVS may also include for example performing internal evaluation of products with the OWASP ASVS in mind, and NOT making any claims of meeting any given level in the standard. Please let us know how your organization is using OWASP ASVS. Include your name, organization's name, and brief description of how you use the standard. The project lead can be reached [mailto:sahba@securitycompass.com here].

= Precedents-Interpretations =

'''PI-0001: Are there levels between the levels?'''

*Issue: Are there levels between the levels for the cases where "The specification for an application may require OWASP ASVS Level N, but it could also include other additional detailed requirements such as from a higher ASVS level"?
*Resolution: No. Use of alternate level definitions or notations such as "ASVS Level 1B+" is discouraged.
*References: ASVS section "Application Security Verification Levels"

'''PI-0002: Is use of a master key simply another level of indirection?'''

*Issue: If a master key is stored as plaintext, isn't using a master key simply another level of indirection?
*Resolution: No. There is a strong rationale for having a "master key" stored in a secure location that is used to encrypt all other secrets. In many applications, there are lots of secrets stored in many different locations. This greatly increases the likelihood that one of them will be compromised. Having a single master key makes managing the protection considerably simpler and is not simply a level of indirection.
*References: ASVS verification requirement V2.14

'''PI-0003: What is a "TOV" or "Target of Verification"?'''

*Issue: New terminology
*Resolution: If you are performing an application security verification according to ASVS, the verification will be of a particular application. This application is called the "Target of Verification" or simply the TOV. The TOV should be identified in verification documentation as follows:
**TOV Identification – <name and version of the application> or <Application name>, <application version>, dynamic testing was performed in a staging environment, not the production environment
**TOV Developer – <insert name of the developer or verification customer>
*References: ASVS section "Approach"

= Internationalization =

[[Image:Asvs-writing.JPG]]
If you can help with translations, please download the latest draft here:

https://github.com/OWASP/ASVS

If there are any incomprehensible English idiom or phrases in there, please don't hesitate to ask for clarification, because if it's hard to translate, it's almost certainly wrong in English as well. We recommend logging translation issues in GitHub, too, so please make yourself known.

Translations are coordinated through OWASP's Crowd In account, so you don't have to do the entire thing yourself.

https://crowdin.com/project/owasp-asvs/

You don't HAVE to use Crowd In, but it would be nice to indicate to other native speakers of your language that you are willing to work together. This is a 70 page document, and in all honesty, will take a dedicated person a week or more to translate, so please please please work together rather than apart. You have full access to the original document and the original images, so you have everything I have.

= Archive - Previous Version =

'''*Please note that ASVS is currently on version 3.0. The information on this page is for archival purposes only.*'''

[[Image:Asvs-step1.jpg]]'1. About ASVS 1.0'

*Video presentation in English [https://www.youtube.com/watch?v=Ba6ncpIfaJA (YouTube)]
*ASVS vs. WASC et al [http://www.owasp.org/index.php/ASVS_vs_WASC_Et_Al (Wiki)]

[[Image:Asvs-step2.jpg]]'2. Get ASVS 1.0'

*ASVS in Bahasa Indonesia (Indonesian language) ([http://owasp-asvs.googlecode.com/files/asvs-webapp-release-2009-id.pdf PDF])
*ASVS in Bahasa Malaysia (Malay) (Currently under development!)
*ASVS in Chinese(Currently under development!)
*ASVS in English ([http://www.owasp.org/images/4/4e/OWASP_ASVS_2009_Web_App_Std_Release.pdf PDF], [http://www.owasp.org/images/3/35/OWASP_ASVS_2009_Web_App_Std_Release.doc Word], [http://code.google.com/p/owasp-asvs/wiki/ASVS '''Online'''], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-xml.zip XML])
*ASVS in French ([http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-fr.pdf PDF], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-fr.odt OpenOffice])
*ASVS in German ([http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-de.pdf PDF], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-de.doc Word])
*ASVS in Hungarian (Currently under development!)
*ASVS in Japanese ([http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-jp.pdf PDF], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-jp.doc Word])
*ASVS in Persian (Farsi) ([http://abiusx.com/archive/document/OWASP-ASVS-fa-20111115.pdf PDF]) beta 0.7
*ASVS in Polish ([http://owasp-asvs.googlecode.com/files/asvs-webapp-release-2009-pl.pdf PDF])
*ASVS in Portuguese-Brazil ([http://owasp-asvs.googlecode.com/files/asvs-webapp-release-2009-pt-br.pdf PDF])
*ASVS in Spanish (Currently under development!)
*ASVS in Thai (Currently under development!)

[[Image:Asvs-step3.jpg]]'3. Learn ASVS 1.0'

*ASVS Article: Getting Started Using ASVS ([http://www.owasp.org/images/f/f8/OWASP_ASVS_Article_-_Getting_Started_Using_ASVS.pdf PDF])
*ASVS Article: Code Reviews and Other Verification Activities: USELESS Unless Acted Upon IMMEDIATELY [http://www.owasp.org/index.php/Code_Reviews_and_Other_Verification_Activities:_USELESS_Unless_Acted_Upon_IMMEDIATELY (Wiki)]
*ASVS Article: Agile Software Development: Don't Forget EVIL User Stories ([http://www.owasp.org/index.php/Agile_Software_Development:_Don%27t_Forget_EVIL_User_Stories Wiki])
*ASVS Article: Man vs. Code ([http://www.owasp.org/index.php/Man_vs._Code Wiki])
*ASVS Article: Getting started designing for a level of assurance ([http://www.owasp.org/images/0/01/Getting_started_designing_for_a_level_of_assurance.pdf PDF])
*ASVS Template: Sample verification fee schedule template ([http://www.owasp.org/index.php/Image:Sample_ASVS_Fee_Schedule_Template.xls Excel])
*ASVS Template: Sample verification report template ([http://www.owasp.org/index.php/Image:Sample_ASVS_Report_Template.doc Word])
*ASVS Training: An ASVS training presentation ([http://www.owasp.org/index.php/Image:OWASP_AU_Secure_Architecture_and_Coding.ppt PowerPoint])
*ASVS Presentation: Executive-Level Presentation ([http://www.owasp.org/images/9/99/About_OWASP_ASVS_Executive_Presentation.ppt PowerPoint])
*ASVS Presentation: Presentation Abstract ([http://www.owasp.org/images/1/10/OWASP_ASVS_Presentation_Abstract.doc Word])
*Articles [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project#Articles_Below_-_More_About_ASVS_and_Using_It (More About ASVS and Using It)]

__NOTOC__ <headertabs />

[[Category:OWASP_Project|Application Security Verification Standard Project]]
[[Category:OWASP_Document]]
[[Category:OWASP_Download]]
[[Category:OWASP_Release_Quality_Document|OWASP Stable Quality Document]]
[[Category:SAMM-CR-1]]
[[Category:SAMM-DR-2]]
[[Category:SAMM-ST-3]]

Category:OWASP Application Security Verification Standard Project

2019-01-02T22:27:46Z

Jmanico: /* OWASP ASVS 4.0 will be released in late 2018 */

= Home =
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]</div>
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

== What is ASVS? ==

The OWASP Application Security Verification Standard (ASVS) Project provides a basis for testing web application technical security controls and also provides developers with a list of requirements for secure development.

The primary aim of the '''OWASP Application Security Verification Standard (ASVS) Project''' is to normalize the range in the coverage and level of rigor available in the market when it comes to performing Web application security verification using a commercially-workable open standard. The standard provides a basis for testing application technical security controls, as well as any technical security controls in the environment, that are relied on to protect against vulnerabilities such as Cross-Site Scripting (XSS) and SQL injection. This standard can be used to establish a level of confidence in the security of Web applications. The requirements were developed with the following objectives in mind:

*'''Use as a metric''' - Provide application developers and application owners with a yardstick with which to assess the degree of trust that can be placed in their Web applications,
*'''Use as guidance''' - Provide guidance to security control developers as to what to build into security controls in order to satisfy application security requirements, and
*'''Use during procurement''' - Provide a basis for specifying application security verification requirements in contracts.

== OWASP ASVS 4.0 will be released in early 2019 ==

Please note there will <b>not be a 3.1 release</b> and we will be going directly from ASVS 3.0.1 to 4.0 in February 2019!

== Email List ==

[[Image:Asvs-bulb.jpg]] [https://lists.owasp.org/mailman/listinfo/owasp-application-security-verification-standard Project Email List]

== Project Leader ==

Daniel Cuthbert [mailto:Daniel.Cuthbert@owasp.org @]<br/>
Andrew van der Stock [mailto:vanderaj@owasp.org @]<br/>
Jim Manico [mailto:jim.manico@owasp.org @]

== Related Projects ==

[[Image:Asvs-satellite.jpg]]'''OWASP Resources'''

*[https://www.owasp.org/index.php/OWASP_Proactive_Controls OWASP Top Ten Proactive Controls (2016)]
*[http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project OWASP Top Ten Risks (2013)]
*[http://www.owasp.org/index.php/Category:OWASP_Guide_Project OWASP Development Guide]

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

== Quick Download ==

ASVS 3.0.1 in English.<br/>
* [[Media:OWASP_Application_Security_Verification_Standard_3.0.1.pdf|Download PDF - 1.7 MB]]
* [[Media:OWASP_Application_Security_Verification_Standard_3.0.1.docx|Download Word - 835 kB]]

== News and Events ==

* [9 March 2018] [https://docs.google.com/spreadsheets/d/1ic7gsib--Cn4ujrA8rhvzuUmMFpQ2Jkl96SZDCEtqJg/edit?ts=5a6bafe1#gid=950526877 OWASP Application Security Verification Standard 3.1 Spreadsheet] created by August Detlefsen
* [29 June 2016] [[Media:OWASP_Application_Security_Verification_Standard_3.0.1.pdf|Version 3.0.1]] released!
* [9 Oct 2015] Version 3.0 released
* [20 May 2015] "First Cut" Version 3.0 released
* [11 Aug 2014] Version 2.0 released

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-flagship-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_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=]]
|-
| 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_DOC.jpg|link=]]
|}

|}

= Downloads =

'''Application Security Verification Standard 3.0.1 '''

== ASVS 3.0.1 in English ==
* [[Media:OWASP_Application_Security_Verification_Standard_3.0.1.pdf|Download PDF - 1.7 MB]]
* [[Media:OWASP_Application_Security_Verification_Standard_3.0.1.docx|Download Word - 835 kB]]

== ASVS 3.0.1 in Spanish==
* [[Media:Estándar_de_Verificación_de_Seguridad_en_Aplicaciones_3.0.1.pdf|Download PDF - 1.7 MB]]
* [[Media:Estándar_de_Verificación_de_Seguridad_en_Aplicaciones_3.0.1.docx|Download Word - 835 kB]]

== ASVS 3.0.1 in Polish==
* [[Media:OWASP Application Security Verification Standard 3.0.1 PL.pdf|Download PDF - 1.5 MB]]

== ASVS 3.0.1 in Persian==
* [[Media:OWASP ASVS 3.0.1 (Persian).pdf|Download PDF - 2.84 MB]]

We are looking for translators for this version. If you can help us, please contact the project mail list!

'''Legacy Application Security Verification Standard 3.0'''

== ASVS 3.0 in English ==
* [[Media:OWASPApplicationSecurityVerificationStandard3.0.pdf|download PDF - 1.2 MB]]
* [[Media:ASVS-excel.xlsx|ASVS 3.0 excel sheet - 39 kB]]

== Older versions ==

'''Application Security Verification Standard 2.0 (final)'''

* ASVS 2.0 in English ([[Media:OWASP_ASVS_Version_2.pdf|download PDF - 1.6 MB]])
* ASVS 2.0 in English ([[Media:OWASP_ASVS_Version_2.docx|download Word - 1.0MB]])
* ASVS 2.0 in Persian ([[Media:OWASP_ASVS_Version_2_Persian.pdf|download PDF - 1.6MB]])
* ASVS 2.0 in Polish (checklist) ([[Media:Asvs_2_PL.xlsx|download Excel]])

'''Application Security Verification Standard 1.0 - 2009'''

* ASVS 1.0 Final (English) ([[Media:OWASP_ASVS_2009_Web_App_Std_Release.pdf|download PDF - 2.5 MB]])
* ASVS 1.0 Final (English) ([[Media:OWASP_ASVS_2009_Web_App_Std_Release.doc|download Word - 2.3 MB]])

= Acknowledgements =

== Volunteers ==

=== Version 3 (2015) ===

Project Leaders

*Daniel Cuthbert
*Andrew van der Stock

Lead Author
*Jim Manico

Other reviewers and contributors
*Boy Baukema
*Ari Kesäniemi
*Colin Watson
*François-Eric Guyomarc’h
*Cristinel Dumitru
*James Holland
*Gary Robinson
*Stephen de Vries
*Glenn Ten Cate
*Riccardo Ten Cate
*Martin Knobloch
*Abhinav Sejpal
*David Ryan
*Steven van der Baan
*Ryan Dewhurst
*Raoul Endres
*Roberto Martelloni

=== Version 2 (2014) ===

Project leaders
*Sahba Kazerooni
*Daniel Cuthbert

Lead authors
*Andrew van der Stock
*Sahba Kazerooni
*Daniel Cuthbert
*Krishna Raja

Other reviewers and contributors
*Jerome Athias
*Boy Baukema
*Archangel Cuison
*Sebastien.Deleersnyder
*Antonio Fontes
*Evan Gaustad
*Safuat Hamdy
*Ari Kesäniemi
*Scott Luc
*Jim Manico
*Mait Peekma
*Pekka Sillanpää
*Jeff Sergeant
*Etienne Stalmans
*Colin Watson
*Dr. Emin İslam Tatlı

Translators
*Abbas Javan Jafari (Persian)
*Sajjad Pourali (Persian)

=== Version 2009 ===

Project leader
*Mike Boberski

Lead authors
*Mike Boberski
*Jeff Williams
*Dave Wichers

Other reviewers and contributors

Pierre Parrend (OWASP Summer of Code), Andrew van der Stock, Nam Nguyen, John Martin, Gaurang Shah, Theodore Winograd, Stan Wisseman, Barry Boyd, Steve Coyle, Paul Douthit, Ken Huang, Dave Hausladen, Mandeep Khera Scott Matsumoto, John Steven, Stephen de Vries, Dan Cornell, Shouvik Bardhan, Dr. Sarbari Gupta, Eoin Keary, Richard Campbell, Matt Presson, Jeff LoSapio, Liz Fong, George Lawless, Dave van Stein, Terrie Diaz, Ketan Dilipkumar Vyas, Bedirhan Urgun, Dr. Thomas Braun, Colin Watson, Jeremiah Grossman.

== OWASP Summer of Code 2008 ==

The OWASP Foundation sponsored the OWASP Application Security Verification Standard Project during the OWASP Summer of Code 2008.

= Glossary =

[[Image:Asvs-letters.jpg]]'''ASVS Terminology'''

*'''Access Control''' – A means of restricting access to files, referenced functions, URLs, and data based on the identity of users and/or groups to which they belong.
*'''Application Component''' – An individual or group of source files, libraries, and/or executables, as defined by the verifier for a particular application.
*'''Application Security''' – Application-level security focuses on the analysis of components that comprise the application layer of the Open Systems Interconnection Reference Model (OSI Model), rather than focusing on for example the underlying operating system or connected networks.
*'''Application Security Verification''' – The technical assessment of an application against the OWASP ASVS.
*'''Application Security Verification Report''' – A report that documents the overall results and supporting analysis produced by the verifier for a particular application.
*'''Application Security Verification Standard (ASVS)''' – An OWASP standard that defines four levels of application security verification for applications.
*'''Authentication''' – The verification of the claimed identity of an application user.
*'''Automated Verification''' – The use of automated tools (either dynamic analysis tools, static analysis tools, or both) that use vulnerability signatures to find problems.
*'''Back Doors''' – A type of malicious code that allows unauthorized access to an application.
*'''Blacklist''' – A list of data or operations that are not permitted, for example a list of characters that are not allowed as input.
*'''Common Criteria (CC)''' – A multipart standard that can be used as the basis for the verification of the design and implementation of security controls in IT products.
*'''Communication Security''' – The protection of application data when it is transmitted between application components, between clients and servers, and between external systems and the application.
*'''Design Verification''' – The technical assessment of the security architecture of an application.
*'''Internal Verification''' – The technical assessment of specific aspects of the security architecture of an application as defined in the OWASP ASVS.
*'''Cryptographic module''' – Hardware, software, and/or firmware that implements cryptographic algorithms and/or generates cryptographic keys.
*'''Denial of Service (DOS) Attacks''' – The flooding of an application with more requests than it can handle.
*'''Dynamic Verification''' – The use of automated tools that use vulnerability signatures to find problems during the execution of an application.
*'''Easter Eggs''' – A type of malicious code that does not run until a specific user input event occurs.
*'''External Systems''' – A server-side application or service that is not part of the application.
*'''FIPS 140-2''' – A standard that can be used as the basis for the verification of the design and implementation of cryptographic modules
*'''Input Validation''' – The canonicalization and validation of untrusted user input.
*'''Malicious Code''' – Code introduced into an application during its development unbeknownst to the application owner which circumvents the application’s intended security policy. Not the same as malware such as a virus or worm!
*'''Malware''' – Executable code that is introduced into an application during runtime without the knowledge of the application user or administrator.
*'''Open Web Application Security Project (OWASP)''' – The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. See: http://www.owasp.org/
*'''Output Validation''' – The canonicalization and validation of application output to Web browsers and to external systems.
*'''OWASP Enterprise Security API (ESAPI)''' – A free and open collection of all the security methods that developers need to build secure Web applications. See: http://www.owasp.org/index.php/ESAPI
*'''OWASP Risk Rating Methodology''' – A risk rating methodology that has been customized for application security. See: http://www.owasp.org/index.php/How_to_value_the_real_risk
*'''OWASP Testing Guide''' – A document designed to help organizations understand what comprises a testing program, and to help them identify the steps needed to build and operate that testing program. See: http://www.owasp.org/index.php/Category:OWASP_Testing_Project
*'''OWASP Top Ten''' – A document that represents a broad consensus about what the most critical Web application security flaws are. See: http://www.owasp.org/index.php/Top10
*'''Positive''' – See whitelist.
*'''Salami Attack''' – A type of malicious code that is used to redirect small amounts of money without detection in financial transactions.
*'''Security Architecture''' – An abstraction of an application’s design that identifies and describes where and how security controls are used, and also identifies and describes the location and sensitivity of both user and application data.
*'''Security Control''' – A function or component that performs a security check (e.g. an access control check) or when called results in a security effect (e.g. generating an audit record).
*'''Security Configuration''' – The runtime configuration of an application that affects how security controls are used.
*'''Static Verification''' – The use of automated tools that use vulnerability signatures to find problems in application source code.
*'''Target of Verification (TOV)''' – If you are performing an application security verification according to the OWASP ASVS requirements, the verification will be of a particular application. This application is called the "Target of Verification" or simply the TOV.
*'''Threat Modeling''' - A technique consisting of developing increasingly refined security architectures to identify threat agents, security zones, security controls, and important technical and business assets.
*'''Time Bomb''' – A type of malicious code that does not run until a preconfigured time or date elapses.
*'''Verifier''' - The person or team that is reviewing an application against the OWASP ASVS requirements.
*'''Whitelist''' – A list of permitted data or operations, for example a list of characters that are allowed to perform input validation.

= ASVS Users =
[[Image:Asvs-handshake.JPG]]

A broad range of companies and agencies around the globe have added ASVS to their software assurance tool boxes, including [http://www.aspectsecurity.com Aspect Security], [http://www.astyran.com Astyran], [http://www.boozallen.com Booz Allen Hamilton], [http://casabasecurity.com Casaba Security], [http://www.cgi.com/web/en/industries/governments/us_federal/services_solutions.htm CGI Federal], [http://denimgroup.com Denim Group], [http://etebaran.com Etebaran Informatics], [http://www.mindedsecurity.com Minded Security], [http://www.nixu.com Nixu], [http://www.pstestware.com/ ps_testware], [http://www.proactiverisk.com Proactive Risk], [http://quince.co.uk Quince Associates Limited (SeeMyData)], [http://www.serpro.gov.br/ Serviço Federal de Processamento de Dados (SERPRO)], [http://www.udistrital.edu.co/ Universidad Distrital Francisco José de Caldas] Organizations listed are not accredited by OWASP. Neither their products or services have been endorsed by OWASP. Use of ASVS may include for example providing verification services using the standard. Use of ASVS may also include for example performing internal evaluation of products with the OWASP ASVS in mind, and NOT making any claims of meeting any given level in the standard. Please let us know how your organization is using OWASP ASVS. Include your name, organization's name, and brief description of how you use the standard. The project lead can be reached [mailto:sahba@securitycompass.com here].

= Precedents-Interpretations =

'''PI-0001: Are there levels between the levels?'''

*Issue: Are there levels between the levels for the cases where "The specification for an application may require OWASP ASVS Level N, but it could also include other additional detailed requirements such as from a higher ASVS level"?
*Resolution: No. Use of alternate level definitions or notations such as "ASVS Level 1B+" is discouraged.
*References: ASVS section "Application Security Verification Levels"

'''PI-0002: Is use of a master key simply another level of indirection?'''

*Issue: If a master key is stored as plaintext, isn't using a master key simply another level of indirection?
*Resolution: No. There is a strong rationale for having a "master key" stored in a secure location that is used to encrypt all other secrets. In many applications, there are lots of secrets stored in many different locations. This greatly increases the likelihood that one of them will be compromised. Having a single master key makes managing the protection considerably simpler and is not simply a level of indirection.
*References: ASVS verification requirement V2.14

'''PI-0003: What is a "TOV" or "Target of Verification"?'''

*Issue: New terminology
*Resolution: If you are performing an application security verification according to ASVS, the verification will be of a particular application. This application is called the "Target of Verification" or simply the TOV. The TOV should be identified in verification documentation as follows:
**TOV Identification – <name and version of the application> or <Application name>, <application version>, dynamic testing was performed in a staging environment, not the production environment
**TOV Developer – <insert name of the developer or verification customer>
*References: ASVS section "Approach"

= Internationalization =

[[Image:Asvs-writing.JPG]]
If you can help with translations, please download the latest draft here:

https://github.com/OWASP/ASVS

If there are any incomprehensible English idiom or phrases in there, please don't hesitate to ask for clarification, because if it's hard to translate, it's almost certainly wrong in English as well. We recommend logging translation issues in GitHub, too, so please make yourself known.

Translations are coordinated through OWASP's Crowd In account, so you don't have to do the entire thing yourself.

https://crowdin.com/project/owasp-asvs/

You don't HAVE to use Crowd In, but it would be nice to indicate to other native speakers of your language that you are willing to work together. This is a 70 page document, and in all honesty, will take a dedicated person a week or more to translate, so please please please work together rather than apart. You have full access to the original document and the original images, so you have everything I have.

= Archive - Previous Version =

'''*Please note that ASVS is currently on version 3.0. The information on this page is for archival purposes only.*'''

[[Image:Asvs-step1.jpg]]'1. About ASVS 1.0'

*Video presentation in English [https://www.youtube.com/watch?v=Ba6ncpIfaJA (YouTube)]
*ASVS vs. WASC et al [http://www.owasp.org/index.php/ASVS_vs_WASC_Et_Al (Wiki)]

[[Image:Asvs-step2.jpg]]'2. Get ASVS 1.0'

*ASVS in Bahasa Indonesia (Indonesian language) ([http://owasp-asvs.googlecode.com/files/asvs-webapp-release-2009-id.pdf PDF])
*ASVS in Bahasa Malaysia (Malay) (Currently under development!)
*ASVS in Chinese(Currently under development!)
*ASVS in English ([http://www.owasp.org/images/4/4e/OWASP_ASVS_2009_Web_App_Std_Release.pdf PDF], [http://www.owasp.org/images/3/35/OWASP_ASVS_2009_Web_App_Std_Release.doc Word], [http://code.google.com/p/owasp-asvs/wiki/ASVS '''Online'''], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-xml.zip XML])
*ASVS in French ([http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-fr.pdf PDF], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-fr.odt OpenOffice])
*ASVS in German ([http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-de.pdf PDF], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-de.doc Word])
*ASVS in Hungarian (Currently under development!)
*ASVS in Japanese ([http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-jp.pdf PDF], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-jp.doc Word])
*ASVS in Persian (Farsi) ([http://abiusx.com/archive/document/OWASP-ASVS-fa-20111115.pdf PDF]) beta 0.7
*ASVS in Polish ([http://owasp-asvs.googlecode.com/files/asvs-webapp-release-2009-pl.pdf PDF])
*ASVS in Portuguese-Brazil ([http://owasp-asvs.googlecode.com/files/asvs-webapp-release-2009-pt-br.pdf PDF])
*ASVS in Spanish (Currently under development!)
*ASVS in Thai (Currently under development!)

[[Image:Asvs-step3.jpg]]'3. Learn ASVS 1.0'

*ASVS Article: Getting Started Using ASVS ([http://www.owasp.org/images/f/f8/OWASP_ASVS_Article_-_Getting_Started_Using_ASVS.pdf PDF])
*ASVS Article: Code Reviews and Other Verification Activities: USELESS Unless Acted Upon IMMEDIATELY [http://www.owasp.org/index.php/Code_Reviews_and_Other_Verification_Activities:_USELESS_Unless_Acted_Upon_IMMEDIATELY (Wiki)]
*ASVS Article: Agile Software Development: Don't Forget EVIL User Stories ([http://www.owasp.org/index.php/Agile_Software_Development:_Don%27t_Forget_EVIL_User_Stories Wiki])
*ASVS Article: Man vs. Code ([http://www.owasp.org/index.php/Man_vs._Code Wiki])
*ASVS Article: Getting started designing for a level of assurance ([http://www.owasp.org/images/0/01/Getting_started_designing_for_a_level_of_assurance.pdf PDF])
*ASVS Template: Sample verification fee schedule template ([http://www.owasp.org/index.php/Image:Sample_ASVS_Fee_Schedule_Template.xls Excel])
*ASVS Template: Sample verification report template ([http://www.owasp.org/index.php/Image:Sample_ASVS_Report_Template.doc Word])
*ASVS Training: An ASVS training presentation ([http://www.owasp.org/index.php/Image:OWASP_AU_Secure_Architecture_and_Coding.ppt PowerPoint])
*ASVS Presentation: Executive-Level Presentation ([http://www.owasp.org/images/9/99/About_OWASP_ASVS_Executive_Presentation.ppt PowerPoint])
*ASVS Presentation: Presentation Abstract ([http://www.owasp.org/images/1/10/OWASP_ASVS_Presentation_Abstract.doc Word])
*Articles [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project#Articles_Below_-_More_About_ASVS_and_Using_It (More About ASVS and Using It)]

__NOTOC__ <headertabs />

[[Category:OWASP_Project|Application Security Verification Standard Project]]
[[Category:OWASP_Document]]
[[Category:OWASP_Download]]
[[Category:OWASP_Release_Quality_Document|OWASP Stable Quality Document]]
[[Category:SAMM-CR-1]]
[[Category:SAMM-DR-2]]
[[Category:SAMM-ST-3]]

How to meet verification reporting requirements

2018-12-12T22:38:22Z

Jmanico: fix

{{taggedDocument
| type=delete
| comment=old content from a deleted user removed
}}

How to meet verification reporting requirements

2018-12-12T22:37:32Z

Jmanico: old content from a deleted user, fishy

Injection Prevention Cheat Sheet in Java

2018-11-26T13:21:31Z

Jmanico: cleanup

__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}}'''
= Introduction =
__TOC__{{TOC hidden}}

This document has for objective to provide some tips to handle ''Injection'' into Java application code.

Sample codes used in tips are located [https://github.com/righettod/injection-cheat-sheets here].

= What is Injection ? =

[[Top_10_2013-A1-Injection|Injection]] in OWASP Top 10 is defined as following:

''Consider anyone who can send untrusted data to the system, including external users, internal users, and administrators.''

= General advices to prevent Injection =

The following point can be applied, in a general way, to prevent ''Injection'' issue:

# Apply '''Input Validation''' (using whitelist approach) combined with '''Output Sanitizing+Escaping''' on user input/output.
# If you need to interact with system, try to use API features provided by your technology stack (Java / .Net / PHP...) instead of building command.

Additional advices are provided on this [[Input_Validation_Cheat_Sheet|cheatsheet]].

= Specific Injection types =

''Examples in this section will be provided in Java technology (see Maven project associated) but advices are applicable to others technologies like .Net / PHP / Ruby / Python...''

== SQL ==

=== Symptom ===

Injection of this type occur when the application use untrusted user input to build a SQL query using a String and execute it.

=== How to prevent ===

Use ''Query Parameterization'' in order to prevent injection.

=== Example ===

<syntaxhighlight lang="java">
/*No DB framework used here in order to show the real use of Prepared Statement from Java API*/
/*Open connection with H2 database and use it*/
Class.forName("org.h2.Driver");
String jdbcUrl = "jdbc:h2:file:" + new File(".").getAbsolutePath() + "/target/db";
try (Connection con = DriverManager.getConnection(jdbcUrl)) {

/* Sample A: Select data using Prepared Statement*/
String query = "select * from color where friendly_name = ?";
List<String> colors = new ArrayList<>();
try (PreparedStatement pStatement = con.prepareStatement(query)) {
pStatement.setString(1, "yellow");
try (ResultSet rSet = pStatement.executeQuery()) {
while (rSet.next()) {
colors.add(rSet.getString(1));
}
}
}
Assert.assertEquals(1, colors.size());
Assert.assertTrue(colors.contains("yellow"));

/* Sample B: Insert data using Prepared Statement*/
query = "insert into color(friendly_name, red, green, blue) values(?, ?, ?, ?)";
int insertedRecordCount;
try (PreparedStatement pStatement = con.prepareStatement(query)) {
pStatement.setString(1, "orange");
pStatement.setInt(2, 239);
pStatement.setInt(3, 125);
pStatement.setInt(4, 11);
insertedRecordCount = pStatement.executeUpdate();
}
Assert.assertEquals(1, insertedRecordCount);

/* Sample C: Update data using Prepared Statement*/
query = "update color set blue = ? where friendly_name = ?";
int updatedRecordCount;
try (PreparedStatement pStatement = con.prepareStatement(query)) {
pStatement.setInt(1, 10);
pStatement.setString(2, "orange");
updatedRecordCount = pStatement.executeUpdate();
}
Assert.assertEquals(1, updatedRecordCount);

/* Sample D: Delete data using Prepared Statement*/
query = "delete from color where friendly_name = ?";
int deletedRecordCount;
try (PreparedStatement pStatement = con.prepareStatement(query)) {
pStatement.setString(1, "orange");
deletedRecordCount = pStatement.executeUpdate();
}
Assert.assertEquals(1, deletedRecordCount);

}
</syntaxhighlight>

=== References ===

* [[SQL_Injection_Prevention_Cheat_Sheet|SQL Injection Prevention Cheat Sheet]]

== JPA ==

=== Symptom ===

Injection of this type occur when the application use untrusted user input to build a JPA query using a String and execute it. It's quite similar to SQL injection but here the altered language is not SQL but JPA QL.

=== How to prevent ===

Use Java Persistence Query Language '''Query Parameterization''' in order to prevent injection.

=== Example ===

<syntaxhighlight lang="java">
EntityManager entityManager = null;
try {
/* Get a ref on EntityManager to access DB */
entityManager = Persistence.createEntityManagerFactory("testJPA").createEntityManager();

/* Define parametrized query prototype using named parameter to enhance readability */
String queryPrototype = "select c from Color c where c.friendlyName = :colorName";

/* Create the query, set the named parameter and execute the query */
Query queryObject = entityManager.createQuery(queryPrototype);
Color c = (Color) queryObject.setParameter("colorName", "yellow").getSingleResult();

/* Ensure that the object obtained is the right one */
Assert.assertNotNull(c);
Assert.assertEquals(c.getFriendlyName(), "yellow");
Assert.assertEquals(c.getRed(), 213);
Assert.assertEquals(c.getGreen(), 242);
Assert.assertEquals(c.getBlue(), 26);
} finally {
if (entityManager != null && entityManager.isOpen()) {
entityManager.close();
}
}
</syntaxhighlight>

=== References ===

* https://software-security.sans.org/developer-how-to/fix-sql-injection-in-java-persistence-api-jpa

== Operating System ==

=== Symptom ===

Injection of this type occur when the application use untrusted user input to build a Operating System command using a String and execute it.

=== How to prevent ===

Use technology stack '''API''' in order to prevent injection.

=== Example ===

<syntaxhighlight lang="java">
/* The context taken is, for example, to perform a PING against a computer.
* The prevention is to use the feature provided by the Java API instead of building
* a system command as String and execute it */
InetAddress host = InetAddress.getByName("localhost");
Assert.assertTrue(host.isReachable(5000));
</syntaxhighlight>

=== References ===

* [[Command_Injection|Command Injection]]

== XML: External Entity attack ==

=== Symptom ===

Injection of this type occur when the application load the received XML stream using a XML parser instance in which the resolution of External Entity is not disabled.

=== How to prevent ===

Disable to resolution of the External Entity in the parser instance to prevent injection.

=== Example ===

<syntaxhighlight lang="java">
/*Create a XML document builder factory*/
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

/*Disable External Entity resolution for differents cases*/
// This is the PRIMARY defense. If DTDs (doctypes) are disallowed,
// almost all XML entity attacks are prevented
// Xerces 2 only - http://xerces.apache.org/xerces2-j/features.html#disallow-doctype-decl
String feature = "http://apache.org/xml/features/disallow-doctype-decl";
dbf.setFeature(feature, true);

// If you can't completely disable DTDs, then at least do the following:
// Xerces 1 - http://xerces.apache.org/xerces-j/features.html#external-general-entities
// Xerces 2 - http://xerces.apache.org/xerces2-j/features.html#external-general-entities
// JDK7+ - http://xml.org/sax/features/external-general-entities
feature = "http://xml.org/sax/features/external-general-entities";
dbf.setFeature(feature, false);

// Xerces 1 - http://xerces.apache.org/xerces-j/features.html#external-parameter-entities
// Xerces 2 - http://xerces.apache.org/xerces2-j/features.html#external-parameter-entities
// JDK7+ - http://xml.org/sax/features/external-parameter-entities
feature = "http://xml.org/sax/features/external-parameter-entities";
dbf.setFeature(feature, false);

// feature external DTDs as well
feature = "http://apache.org/xml/features/nonvalidating/load-external-dtd";
dbf.setFeature(feature, false);

// and these as well, per Timothy Morgan's 2014 paper: "XML Schema, DTD, and Entity Attacks"
dbf.setXIncludeAware(false);
dbf.setExpandEntityReferences(false);

/*Load XML file*/
DocumentBuilder builder = dbf.newDocumentBuilder();
//Here an org.xml.sax.SAXParseException will be throws because the XML contains a External Entity.
builder.parse(new File("src/test/resources/SampleXXE.xml"));
</syntaxhighlight>

== XML: XPath Injection ==

=== Symptom ===

Injection of this type occur when the application use untrusted user input to build a XPath query using a String and execute it.

=== How to prevent ===

Use '''XPath Variable Resolver''' in order to prevent injection.

=== Example ===

'''Variable Resolver''' implementation.

<syntaxhighlight lang="java">
/**
* Resolver in order to define parameter for XPATH expression.
*
*/
public class SimpleVariableResolver implements XPathVariableResolver {

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

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

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

Code using it to perform XPath query.

<syntaxhighlight lang="java">
/*Create a XML document builder factory*/
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

/*Disable External Entity resolution for differents cases*/
//Do not performed here in order to focus on variable resolver code
//but do it for production code !

/*Load XML file*/
DocumentBuilder builder = dbf.newDocumentBuilder();
Document doc = builder.parse(new File("src/test/resources/SampleXPath.xml"));

/* Create and configure parameter resolver */
String bid = "bk102";
SimpleVariableResolver variableResolver = new SimpleVariableResolver();
variableResolver.addVariable(new QName("bookId"), bid);

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

/* Apply expression on XML document */
Object nodes = xPathExpression.evaluate(doc, XPathConstants.NODESET);
NodeList nodesList = (NodeList) nodes;
Assert.assertNotNull(nodesList);
Assert.assertEquals(1, nodesList.getLength());
Element book = (Element)nodesList.item(0);
Assert.assertTrue(book.getTextContent().contains("Ralls, Kim"));
</syntaxhighlight>

=== References ===

* [[XPATH_Injection|XPATH Injection]]

== HTML/JavaScript/CSS ==

=== Symptom ===

Injection of this type occur when the application use untrusted user input to build a HTTP response and sent it to browser.

=== How to prevent ===

Either apply strict input validation (whitelist approach) or use output sanitizing+escaping if input validation is not possible (combine both every time is possible).

=== Example ===

<syntaxhighlight lang="java">
/*
INPUT WAY: Receive data from user
Here it's recommended to use strict input validation using whitelist approach.
In fact, you ensure that only allowed characters are part of the input received.
*/

String userInput = "You user login is owasp-user01";

/* First we check that the value contains only expected character*/
Assert.assertTrue(Pattern.matches("[a-zA-Z0-9\\s\\-]{1,50}", userInput));

/* If the first check pass then ensure that potential dangerous character that we have allowed
for business requirement are not used in a dangerous way.
For example here we have allowed the character '-', and, this can be used in SQL injection so, we
ensure that this character is not used is a continuous form.
Use the API COMMONS LANG v3 to help in String analysis...
*/
Assert.assertEquals(0, StringUtils.countMatches(userInput.replace(" ", ""), "--"));

/*
OUTPUT WAY: Send data to user
Here we escape + sanitize any data sent to user
Use the OWASP Java HTML Sanitizer API to handle sanitizing
Use the OWASP Java Encoder API to handle HTML tag encoding (escaping)
*/

String outputToUser = "You <p>user login</p> is <strong>owasp-user01</strong>";
outputToUser += "<script>alert(22);</script><img src='#' onload='javascript:alert(23);'>";

/* Create a sanitizing policy that only allow tag '<p>' and '<strong>'*/
PolicyFactory policy = new HtmlPolicyBuilder().allowElements("p", "strong").toFactory();

/* Sanitize the output that will be sent to user*/
String safeOutput = policy.sanitize(outputToUser);

/* Encode HTML Tag*/
safeOutput = Encode.forHtml(safeOutput);
String finalSafeOutputExpected = "You <p>user login</p> is <strong>owasp-user01</strong>";
Assert.assertEquals(finalSafeOutputExpected, safeOutput);
</syntaxhighlight>

=== References ===

* [[Cross-site_Scripting_(XSS)| XSS]]

* https://github.com/owasp/java-html-sanitizer

* https://github.com/owasp/owasp-java-encoder/

* https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html

* https://commons.apache.org/proper/commons-lang/javadocs/api-3.4/org/apache/commons/lang3/StringEscapeUtils.html

== LDAP ==

A dedicated [[LDAP_Injection_Prevention_Cheat_Sheet|cheatsheet]] has been created.

== NoSQL ==

=== Symptom ===

Injection of this type occur when the application use untrusted user input to build a NoSQL API call expression.

=== How to prevent ===

As there many NoSQL database system and each one use a API for call, it's important to ensure that user input received
and used to build the API call expression do not contains any character that have a special meaning in the target API syntax.
This in order to avoid that it will be used to escape the initial call expression in order to create another one based on crafted user input.
It's also important to not use string concatenation to build API call expression but use the API to create the expression.

=== Example - MongoDB ===

<syntaxhighlight lang="java">
/* Here use MongoDB as target NoSQL DB */
String userInput = "Brooklyn";

/* First ensure that the input do no contains any special characters for the current NoSQL DB call API,
here they are: ' " \ ; { } $
*/
//Avoid regexp this time in order to made validation code more easy to read and understand...
ArrayList<String> specialCharsList = new ArrayList<String>() {{
add("'");
add("\"");
add("\\");
add(";");
add("{");
add("}");
add("$");
}};
specialCharsList.forEach(specChar -> Assert.assertFalse(userInput.contains(specChar)));
//Add also a check on input max size
Assert.assertTrue(userInput.length() <= 50);

/* Then perform query on database using API to build expression */
//Connect to the local MongoDB instance
try(MongoClient mongoClient = new MongoClient()){
MongoDatabase db = mongoClient.getDatabase("test");
//Use API query builder to create call expression
//Create expression
Bson expression = eq("borough", userInput);
//Perform call
FindIterable<org.bson.Document> restaurants = db.getCollection("restaurants").find(expression);
//Verify result consistency
restaurants.forEach(new Block<org.bson.Document>() {
@Override
public void apply(final org.bson.Document doc) {
String restBorough = (String)doc.get("borough");
Assert.assertTrue("Brooklyn".equals(restBorough));
}
});
}
</syntaxhighlight>

=== References ===

[[Testing_for_NoSQL_injection|Testing for NoSQL injection]]

https://ckarande.gitbooks.io/owasp-nodegoat-tutorial/content/tutorial/a1_-_sql_and_nosql_injection.html

https://arxiv.org/ftp/arxiv/papers/1506/1506.04082.pdf

== Log Injection ==

=== Symptom ===

[[Log_Injection|Log Injection]] occurs when an application uses untrusted data to create a message in an application log.

More information about this attack is available on this OWASP [[Log_Injection|page]].

=== How to prevent ===

In order to prevent an attacker from writing malicious content into the application log, apply the following steps:

# Limit the size of the user input value used to create the log message.
# Filter the user input used to prevent injection of '''C'''arriage '''R'''eturn (CR) or '''L'''ine '''F'''eed (LF) characters.

The project [[OWASP_Security_Logging_Project|OWASP Security Logging]] can be used to protect the application log against ''Log Injection'' attack.

=== Example ===

Usage of the ''OWASP Security Logging'' features with the LOG4J2 logging API.

Configuration of a logging policy to roll on 10 files of 5MB each one and encode/limit the log message using the ''OWASP Security Logging'' features (see the ''encode'' function usage in the ''Pattern'' tag):

<syntaxhighlight lang="xml" highlight="7">
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="error" name="SecureLoggingPolicy">
<Appenders>
<RollingFile name="RollingFile" fileName="App.log" filePattern="App-%i.log" ignoreExceptions="false">
<PatternLayout>

<Pattern>%d{ISO8601} %-5p - %encode{%.-500m}%n</Pattern>
</PatternLayout>
<Policies>
<SizeBasedTriggeringPolicy size="5MB"/>
</Policies>
<DefaultRolloverStrategy max="10"/>
</RollingFile>
</Appenders>
<Loggers>
<Root level="debug">
<AppenderRef ref="RollingFile"/>
</Root>
</Loggers>
</Configuration>
</syntaxhighlight>

Usage of the logger at code level:

<syntaxhighlight lang="java">
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
...
// No special action needed because security actions are performed at the logging policy level
Logger logger = LogManager.getLogger(MyClass.class);
logger.info(logMessage);
...
</syntaxhighlight>

=== References ===

https://logging.apache.org/log4j/2.x/manual/configuration.html

https://logging.apache.org/log4j/2.x/manual/appenders.html

https://github.com/javabeanz/owasp-security-logging

= Authors and Primary Editors =

[[User:Dominique_RIGHETTO|Dominique Righetto]] - dominique.righetto@owasp.org

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

Injection Prevention Cheat Sheet in Java

2018-11-26T13:21:09Z

Jmanico: removing HTML escaping in log files

__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}}'''
= Introduction =
__TOC__{{TOC hidden}}

This document has for objective to provide some tips to handle ''Injection'' into Java application code.

Sample codes used in tips are located [https://github.com/righettod/injection-cheat-sheets here].

= What is Injection ? =

[[Top_10_2013-A1-Injection|Injection]] in OWASP Top 10 is defined as following:

''Consider anyone who can send untrusted data to the system, including external users, internal users, and administrators.''

= General advices to prevent Injection =

The following point can be applied, in a general way, to prevent ''Injection'' issue:

# Apply '''Input Validation''' (using whitelist approach) combined with '''Output Sanitizing+Escaping''' on user input/output.
# If you need to interact with system, try to use API features provided by your technology stack (Java / .Net / PHP...) instead of building command.

Additional advices are provided on this [[Input_Validation_Cheat_Sheet|cheatsheet]].

= Specific Injection types =

''Examples in this section will be provided in Java technology (see Maven project associated) but advices are applicable to others technologies like .Net / PHP / Ruby / Python...''

== SQL ==

=== Symptom ===

Injection of this type occur when the application use untrusted user input to build a SQL query using a String and execute it.

=== How to prevent ===

Use '''Query Parameterization'' in order to prevent injection.

=== Example ===

<syntaxhighlight lang="java">
/*No DB framework used here in order to show the real use of Prepared Statement from Java API*/
/*Open connection with H2 database and use it*/
Class.forName("org.h2.Driver");
String jdbcUrl = "jdbc:h2:file:" + new File(".").getAbsolutePath() + "/target/db";
try (Connection con = DriverManager.getConnection(jdbcUrl)) {

/* Sample A: Select data using Prepared Statement*/
String query = "select * from color where friendly_name = ?";
List<String> colors = new ArrayList<>();
try (PreparedStatement pStatement = con.prepareStatement(query)) {
pStatement.setString(1, "yellow");
try (ResultSet rSet = pStatement.executeQuery()) {
while (rSet.next()) {
colors.add(rSet.getString(1));
}
}
}
Assert.assertEquals(1, colors.size());
Assert.assertTrue(colors.contains("yellow"));

/* Sample B: Insert data using Prepared Statement*/
query = "insert into color(friendly_name, red, green, blue) values(?, ?, ?, ?)";
int insertedRecordCount;
try (PreparedStatement pStatement = con.prepareStatement(query)) {
pStatement.setString(1, "orange");
pStatement.setInt(2, 239);
pStatement.setInt(3, 125);
pStatement.setInt(4, 11);
insertedRecordCount = pStatement.executeUpdate();
}
Assert.assertEquals(1, insertedRecordCount);

/* Sample C: Update data using Prepared Statement*/
query = "update color set blue = ? where friendly_name = ?";
int updatedRecordCount;
try (PreparedStatement pStatement = con.prepareStatement(query)) {
pStatement.setInt(1, 10);
pStatement.setString(2, "orange");
updatedRecordCount = pStatement.executeUpdate();
}
Assert.assertEquals(1, updatedRecordCount);

/* Sample D: Delete data using Prepared Statement*/
query = "delete from color where friendly_name = ?";
int deletedRecordCount;
try (PreparedStatement pStatement = con.prepareStatement(query)) {
pStatement.setString(1, "orange");
deletedRecordCount = pStatement.executeUpdate();
}
Assert.assertEquals(1, deletedRecordCount);

}
</syntaxhighlight>

=== References ===

* [[SQL_Injection_Prevention_Cheat_Sheet|SQL Injection Prevention Cheat Sheet]]

== JPA ==

=== Symptom ===

Injection of this type occur when the application use untrusted user input to build a JPA query using a String and execute it. It's quite similar to SQL injection but here the altered language is not SQL but JPA QL.

=== How to prevent ===

Use Java Persistence Query Language '''Query Parameterization''' in order to prevent injection.

=== Example ===

<syntaxhighlight lang="java">
EntityManager entityManager = null;
try {
/* Get a ref on EntityManager to access DB */
entityManager = Persistence.createEntityManagerFactory("testJPA").createEntityManager();

/* Define parametrized query prototype using named parameter to enhance readability */
String queryPrototype = "select c from Color c where c.friendlyName = :colorName";

/* Create the query, set the named parameter and execute the query */
Query queryObject = entityManager.createQuery(queryPrototype);
Color c = (Color) queryObject.setParameter("colorName", "yellow").getSingleResult();

/* Ensure that the object obtained is the right one */
Assert.assertNotNull(c);
Assert.assertEquals(c.getFriendlyName(), "yellow");
Assert.assertEquals(c.getRed(), 213);
Assert.assertEquals(c.getGreen(), 242);
Assert.assertEquals(c.getBlue(), 26);
} finally {
if (entityManager != null && entityManager.isOpen()) {
entityManager.close();
}
}
</syntaxhighlight>

=== References ===

* https://software-security.sans.org/developer-how-to/fix-sql-injection-in-java-persistence-api-jpa

== Operating System ==

=== Symptom ===

Injection of this type occur when the application use untrusted user input to build a Operating System command using a String and execute it.

=== How to prevent ===

Use technology stack '''API''' in order to prevent injection.

=== Example ===

<syntaxhighlight lang="java">
/* The context taken is, for example, to perform a PING against a computer.
* The prevention is to use the feature provided by the Java API instead of building
* a system command as String and execute it */
InetAddress host = InetAddress.getByName("localhost");
Assert.assertTrue(host.isReachable(5000));
</syntaxhighlight>

=== References ===

* [[Command_Injection|Command Injection]]

== XML: External Entity attack ==

=== Symptom ===

Injection of this type occur when the application load the received XML stream using a XML parser instance in which the resolution of External Entity is not disabled.

=== How to prevent ===

Disable to resolution of the External Entity in the parser instance to prevent injection.

=== Example ===

<syntaxhighlight lang="java">
/*Create a XML document builder factory*/
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

/*Disable External Entity resolution for differents cases*/
// This is the PRIMARY defense. If DTDs (doctypes) are disallowed,
// almost all XML entity attacks are prevented
// Xerces 2 only - http://xerces.apache.org/xerces2-j/features.html#disallow-doctype-decl
String feature = "http://apache.org/xml/features/disallow-doctype-decl";
dbf.setFeature(feature, true);

// If you can't completely disable DTDs, then at least do the following:
// Xerces 1 - http://xerces.apache.org/xerces-j/features.html#external-general-entities
// Xerces 2 - http://xerces.apache.org/xerces2-j/features.html#external-general-entities
// JDK7+ - http://xml.org/sax/features/external-general-entities
feature = "http://xml.org/sax/features/external-general-entities";
dbf.setFeature(feature, false);

// Xerces 1 - http://xerces.apache.org/xerces-j/features.html#external-parameter-entities
// Xerces 2 - http://xerces.apache.org/xerces2-j/features.html#external-parameter-entities
// JDK7+ - http://xml.org/sax/features/external-parameter-entities
feature = "http://xml.org/sax/features/external-parameter-entities";
dbf.setFeature(feature, false);

// feature external DTDs as well
feature = "http://apache.org/xml/features/nonvalidating/load-external-dtd";
dbf.setFeature(feature, false);

// and these as well, per Timothy Morgan's 2014 paper: "XML Schema, DTD, and Entity Attacks"
dbf.setXIncludeAware(false);
dbf.setExpandEntityReferences(false);

/*Load XML file*/
DocumentBuilder builder = dbf.newDocumentBuilder();
//Here an org.xml.sax.SAXParseException will be throws because the XML contains a External Entity.
builder.parse(new File("src/test/resources/SampleXXE.xml"));
</syntaxhighlight>

== XML: XPath Injection ==

=== Symptom ===

Injection of this type occur when the application use untrusted user input to build a XPath query using a String and execute it.

=== How to prevent ===

Use '''XPath Variable Resolver''' in order to prevent injection.

=== Example ===

'''Variable Resolver''' implementation.

<syntaxhighlight lang="java">
/**
* Resolver in order to define parameter for XPATH expression.
*
*/
public class SimpleVariableResolver implements XPathVariableResolver {

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

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

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

Code using it to perform XPath query.

<syntaxhighlight lang="java">
/*Create a XML document builder factory*/
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

/*Disable External Entity resolution for differents cases*/
//Do not performed here in order to focus on variable resolver code
//but do it for production code !

/*Load XML file*/
DocumentBuilder builder = dbf.newDocumentBuilder();
Document doc = builder.parse(new File("src/test/resources/SampleXPath.xml"));

/* Create and configure parameter resolver */
String bid = "bk102";
SimpleVariableResolver variableResolver = new SimpleVariableResolver();
variableResolver.addVariable(new QName("bookId"), bid);

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

/* Apply expression on XML document */
Object nodes = xPathExpression.evaluate(doc, XPathConstants.NODESET);
NodeList nodesList = (NodeList) nodes;
Assert.assertNotNull(nodesList);
Assert.assertEquals(1, nodesList.getLength());
Element book = (Element)nodesList.item(0);
Assert.assertTrue(book.getTextContent().contains("Ralls, Kim"));
</syntaxhighlight>

=== References ===

* [[XPATH_Injection|XPATH Injection]]

== HTML/JavaScript/CSS ==

=== Symptom ===

Injection of this type occur when the application use untrusted user input to build a HTTP response and sent it to browser.

=== How to prevent ===

Either apply strict input validation (whitelist approach) or use output sanitizing+escaping if input validation is not possible (combine both every time is possible).

=== Example ===

<syntaxhighlight lang="java">
/*
INPUT WAY: Receive data from user
Here it's recommended to use strict input validation using whitelist approach.
In fact, you ensure that only allowed characters are part of the input received.
*/

String userInput = "You user login is owasp-user01";

/* First we check that the value contains only expected character*/
Assert.assertTrue(Pattern.matches("[a-zA-Z0-9\\s\\-]{1,50}", userInput));

/* If the first check pass then ensure that potential dangerous character that we have allowed
for business requirement are not used in a dangerous way.
For example here we have allowed the character '-', and, this can be used in SQL injection so, we
ensure that this character is not used is a continuous form.
Use the API COMMONS LANG v3 to help in String analysis...
*/
Assert.assertEquals(0, StringUtils.countMatches(userInput.replace(" ", ""), "--"));

/*
OUTPUT WAY: Send data to user
Here we escape + sanitize any data sent to user
Use the OWASP Java HTML Sanitizer API to handle sanitizing
Use the OWASP Java Encoder API to handle HTML tag encoding (escaping)
*/

String outputToUser = "You <p>user login</p> is <strong>owasp-user01</strong>";
outputToUser += "<script>alert(22);</script><img src='#' onload='javascript:alert(23);'>";

/* Create a sanitizing policy that only allow tag '<p>' and '<strong>'*/
PolicyFactory policy = new HtmlPolicyBuilder().allowElements("p", "strong").toFactory();

/* Sanitize the output that will be sent to user*/
String safeOutput = policy.sanitize(outputToUser);

/* Encode HTML Tag*/
safeOutput = Encode.forHtml(safeOutput);
String finalSafeOutputExpected = "You <p>user login</p> is <strong>owasp-user01</strong>";
Assert.assertEquals(finalSafeOutputExpected, safeOutput);
</syntaxhighlight>

=== References ===

* [[Cross-site_Scripting_(XSS)| XSS]]

* https://github.com/owasp/java-html-sanitizer

* https://github.com/owasp/owasp-java-encoder/

* https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html

* https://commons.apache.org/proper/commons-lang/javadocs/api-3.4/org/apache/commons/lang3/StringEscapeUtils.html

== LDAP ==

A dedicated [[LDAP_Injection_Prevention_Cheat_Sheet|cheatsheet]] has been created.

== NoSQL ==

=== Symptom ===

Injection of this type occur when the application use untrusted user input to build a NoSQL API call expression.

=== How to prevent ===

As there many NoSQL database system and each one use a API for call, it's important to ensure that user input received
and used to build the API call expression do not contains any character that have a special meaning in the target API syntax.
This in order to avoid that it will be used to escape the initial call expression in order to create another one based on crafted user input.
It's also important to not use string concatenation to build API call expression but use the API to create the expression.

=== Example - MongoDB ===

<syntaxhighlight lang="java">
/* Here use MongoDB as target NoSQL DB */
String userInput = "Brooklyn";

/* First ensure that the input do no contains any special characters for the current NoSQL DB call API,
here they are: ' " \ ; { } $
*/
//Avoid regexp this time in order to made validation code more easy to read and understand...
ArrayList<String> specialCharsList = new ArrayList<String>() {{
add("'");
add("\"");
add("\\");
add(";");
add("{");
add("}");
add("$");
}};
specialCharsList.forEach(specChar -> Assert.assertFalse(userInput.contains(specChar)));
//Add also a check on input max size
Assert.assertTrue(userInput.length() <= 50);

/* Then perform query on database using API to build expression */
//Connect to the local MongoDB instance
try(MongoClient mongoClient = new MongoClient()){
MongoDatabase db = mongoClient.getDatabase("test");
//Use API query builder to create call expression
//Create expression
Bson expression = eq("borough", userInput);
//Perform call
FindIterable<org.bson.Document> restaurants = db.getCollection("restaurants").find(expression);
//Verify result consistency
restaurants.forEach(new Block<org.bson.Document>() {
@Override
public void apply(final org.bson.Document doc) {
String restBorough = (String)doc.get("borough");
Assert.assertTrue("Brooklyn".equals(restBorough));
}
});
}
</syntaxhighlight>

=== References ===

[[Testing_for_NoSQL_injection|Testing for NoSQL injection]]

https://ckarande.gitbooks.io/owasp-nodegoat-tutorial/content/tutorial/a1_-_sql_and_nosql_injection.html

https://arxiv.org/ftp/arxiv/papers/1506/1506.04082.pdf

== Log Injection ==

=== Symptom ===

[[Log_Injection|Log Injection]] occurs when an application uses untrusted data to create a message in an application log.

More information about this attack is available on this OWASP [[Log_Injection|page]].

=== How to prevent ===

In order to prevent an attacker from writing malicious content into the application log, apply the following steps:

# Limit the size of the user input value used to create the log message.
# Filter the user input used to prevent injection of '''C'''arriage '''R'''eturn (CR) or '''L'''ine '''F'''eed (LF) characters.

The project [[OWASP_Security_Logging_Project|OWASP Security Logging]] can be used to protect the application log against ''Log Injection'' attack.

=== Example ===

Usage of the ''OWASP Security Logging'' features with the LOG4J2 logging API.

Configuration of a logging policy to roll on 10 files of 5MB each one and encode/limit the log message using the ''OWASP Security Logging'' features (see the ''encode'' function usage in the ''Pattern'' tag):

<syntaxhighlight lang="xml" highlight="7">
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="error" name="SecureLoggingPolicy">
<Appenders>
<RollingFile name="RollingFile" fileName="App.log" filePattern="App-%i.log" ignoreExceptions="false">
<PatternLayout>

<Pattern>%d{ISO8601} %-5p - %encode{%.-500m}%n</Pattern>
</PatternLayout>
<Policies>
<SizeBasedTriggeringPolicy size="5MB"/>
</Policies>
<DefaultRolloverStrategy max="10"/>
</RollingFile>
</Appenders>
<Loggers>
<Root level="debug">
<AppenderRef ref="RollingFile"/>
</Root>
</Loggers>
</Configuration>
</syntaxhighlight>

Usage of the logger at code level:

<syntaxhighlight lang="java">
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
...
// No special action needed because security actions are performed at the logging policy level
Logger logger = LogManager.getLogger(MyClass.class);
logger.info(logMessage);
...
</syntaxhighlight>

=== References ===

https://logging.apache.org/log4j/2.x/manual/configuration.html

https://logging.apache.org/log4j/2.x/manual/appenders.html

https://github.com/javabeanz/owasp-security-logging

= Authors and Primary Editors =

[[User:Dominique_RIGHETTO|Dominique Righetto]] - dominique.righetto@owasp.org

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

Injection Prevention Cheat Sheet in Java

2018-11-26T13:16:43Z

Jmanico: cleanup

__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}}'''
= Introduction =
__TOC__{{TOC hidden}}

This document has for objective to provide some tips to handle ''Injection'' into Java application code.

Sample codes used in tips are located [https://github.com/righettod/injection-cheat-sheets here].

= What is Injection ? =

[[Top_10_2013-A1-Injection|Injection]] in OWASP Top 10 is defined as following:

''Consider anyone who can send untrusted data to the system, including external users, internal users, and administrators.''

= General advices to prevent Injection =

The following point can be applied, in a general way, to prevent ''Injection'' issue:

# Apply '''Input Validation''' (using whitelist approach) combined with '''Output Sanitizing+Escaping''' on user input/output.
# If you need to interact with system, try to use API features provided by your technology stack (Java / .Net / PHP...) instead of building command.

Additional advices are provided on this [[Input_Validation_Cheat_Sheet|cheatsheet]].

= Specific Injection types =

''Examples in this section will be provided in Java technology (see Maven project associated) but advices are applicable to others technologies like .Net / PHP / Ruby / Python...''

== SQL ==

=== Symptom ===

Injection of this type occur when the application use untrusted user input to build a SQL query using a String and execute it.

=== How to prevent ===

Use '''Query Parameterization'' in order to prevent injection.

=== Example ===

<syntaxhighlight lang="java">
/*No DB framework used here in order to show the real use of Prepared Statement from Java API*/
/*Open connection with H2 database and use it*/
Class.forName("org.h2.Driver");
String jdbcUrl = "jdbc:h2:file:" + new File(".").getAbsolutePath() + "/target/db";
try (Connection con = DriverManager.getConnection(jdbcUrl)) {

/* Sample A: Select data using Prepared Statement*/
String query = "select * from color where friendly_name = ?";
List<String> colors = new ArrayList<>();
try (PreparedStatement pStatement = con.prepareStatement(query)) {
pStatement.setString(1, "yellow");
try (ResultSet rSet = pStatement.executeQuery()) {
while (rSet.next()) {
colors.add(rSet.getString(1));
}
}
}
Assert.assertEquals(1, colors.size());
Assert.assertTrue(colors.contains("yellow"));

/* Sample B: Insert data using Prepared Statement*/
query = "insert into color(friendly_name, red, green, blue) values(?, ?, ?, ?)";
int insertedRecordCount;
try (PreparedStatement pStatement = con.prepareStatement(query)) {
pStatement.setString(1, "orange");
pStatement.setInt(2, 239);
pStatement.setInt(3, 125);
pStatement.setInt(4, 11);
insertedRecordCount = pStatement.executeUpdate();
}
Assert.assertEquals(1, insertedRecordCount);

/* Sample C: Update data using Prepared Statement*/
query = "update color set blue = ? where friendly_name = ?";
int updatedRecordCount;
try (PreparedStatement pStatement = con.prepareStatement(query)) {
pStatement.setInt(1, 10);
pStatement.setString(2, "orange");
updatedRecordCount = pStatement.executeUpdate();
}
Assert.assertEquals(1, updatedRecordCount);

/* Sample D: Delete data using Prepared Statement*/
query = "delete from color where friendly_name = ?";
int deletedRecordCount;
try (PreparedStatement pStatement = con.prepareStatement(query)) {
pStatement.setString(1, "orange");
deletedRecordCount = pStatement.executeUpdate();
}
Assert.assertEquals(1, deletedRecordCount);

}
</syntaxhighlight>

=== References ===

* [[SQL_Injection_Prevention_Cheat_Sheet|SQL Injection Prevention Cheat Sheet]]

== JPA ==

=== Symptom ===

Injection of this type occur when the application use untrusted user input to build a JPA query using a String and execute it. It's quite similar to SQL injection but here the altered language is not SQL but JPA QL.

=== How to prevent ===

Use Java Persistence Query Language '''Query Parameterization''' in order to prevent injection.

=== Example ===

<syntaxhighlight lang="java">
EntityManager entityManager = null;
try {
/* Get a ref on EntityManager to access DB */
entityManager = Persistence.createEntityManagerFactory("testJPA").createEntityManager();

/* Define parametrized query prototype using named parameter to enhance readability */
String queryPrototype = "select c from Color c where c.friendlyName = :colorName";

/* Create the query, set the named parameter and execute the query */
Query queryObject = entityManager.createQuery(queryPrototype);
Color c = (Color) queryObject.setParameter("colorName", "yellow").getSingleResult();

/* Ensure that the object obtained is the right one */
Assert.assertNotNull(c);
Assert.assertEquals(c.getFriendlyName(), "yellow");
Assert.assertEquals(c.getRed(), 213);
Assert.assertEquals(c.getGreen(), 242);
Assert.assertEquals(c.getBlue(), 26);
} finally {
if (entityManager != null && entityManager.isOpen()) {
entityManager.close();
}
}
</syntaxhighlight>

=== References ===

* https://software-security.sans.org/developer-how-to/fix-sql-injection-in-java-persistence-api-jpa

== Operating System ==

=== Symptom ===

Injection of this type occur when the application use untrusted user input to build a Operating System command using a String and execute it.

=== How to prevent ===

Use technology stack '''API''' in order to prevent injection.

=== Example ===

<syntaxhighlight lang="java">
/* The context taken is, for example, to perform a PING against a computer.
* The prevention is to use the feature provided by the Java API instead of building
* a system command as String and execute it */
InetAddress host = InetAddress.getByName("localhost");
Assert.assertTrue(host.isReachable(5000));
</syntaxhighlight>

=== References ===

* [[Command_Injection|Command Injection]]

== XML: External Entity attack ==

=== Symptom ===

Injection of this type occur when the application load the received XML stream using a XML parser instance in which the resolution of External Entity is not disabled.

=== How to prevent ===

Disable to resolution of the External Entity in the parser instance to prevent injection.

=== Example ===

<syntaxhighlight lang="java">
/*Create a XML document builder factory*/
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

/*Disable External Entity resolution for differents cases*/
// This is the PRIMARY defense. If DTDs (doctypes) are disallowed,
// almost all XML entity attacks are prevented
// Xerces 2 only - http://xerces.apache.org/xerces2-j/features.html#disallow-doctype-decl
String feature = "http://apache.org/xml/features/disallow-doctype-decl";
dbf.setFeature(feature, true);

// If you can't completely disable DTDs, then at least do the following:
// Xerces 1 - http://xerces.apache.org/xerces-j/features.html#external-general-entities
// Xerces 2 - http://xerces.apache.org/xerces2-j/features.html#external-general-entities
// JDK7+ - http://xml.org/sax/features/external-general-entities
feature = "http://xml.org/sax/features/external-general-entities";
dbf.setFeature(feature, false);

// Xerces 1 - http://xerces.apache.org/xerces-j/features.html#external-parameter-entities
// Xerces 2 - http://xerces.apache.org/xerces2-j/features.html#external-parameter-entities
// JDK7+ - http://xml.org/sax/features/external-parameter-entities
feature = "http://xml.org/sax/features/external-parameter-entities";
dbf.setFeature(feature, false);

// feature external DTDs as well
feature = "http://apache.org/xml/features/nonvalidating/load-external-dtd";
dbf.setFeature(feature, false);

// and these as well, per Timothy Morgan's 2014 paper: "XML Schema, DTD, and Entity Attacks"
dbf.setXIncludeAware(false);
dbf.setExpandEntityReferences(false);

/*Load XML file*/
DocumentBuilder builder = dbf.newDocumentBuilder();
//Here an org.xml.sax.SAXParseException will be throws because the XML contains a External Entity.
builder.parse(new File("src/test/resources/SampleXXE.xml"));
</syntaxhighlight>

== XML: XPath Injection ==

=== Symptom ===

Injection of this type occur when the application use untrusted user input to build a XPath query using a String and execute it.

=== How to prevent ===

Use '''XPath Variable Resolver''' in order to prevent injection.

=== Example ===

'''Variable Resolver''' implementation.

<syntaxhighlight lang="java">
/**
* Resolver in order to define parameter for XPATH expression.
*
*/
public class SimpleVariableResolver implements XPathVariableResolver {

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

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

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

Code using it to perform XPath query.

<syntaxhighlight lang="java">
/*Create a XML document builder factory*/
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

/*Disable External Entity resolution for differents cases*/
//Do not performed here in order to focus on variable resolver code
//but do it for production code !

/*Load XML file*/
DocumentBuilder builder = dbf.newDocumentBuilder();
Document doc = builder.parse(new File("src/test/resources/SampleXPath.xml"));

/* Create and configure parameter resolver */
String bid = "bk102";
SimpleVariableResolver variableResolver = new SimpleVariableResolver();
variableResolver.addVariable(new QName("bookId"), bid);

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

/* Apply expression on XML document */
Object nodes = xPathExpression.evaluate(doc, XPathConstants.NODESET);
NodeList nodesList = (NodeList) nodes;
Assert.assertNotNull(nodesList);
Assert.assertEquals(1, nodesList.getLength());
Element book = (Element)nodesList.item(0);
Assert.assertTrue(book.getTextContent().contains("Ralls, Kim"));
</syntaxhighlight>

=== References ===

* [[XPATH_Injection|XPATH Injection]]

== HTML/JavaScript/CSS ==

=== Symptom ===

Injection of this type occur when the application use untrusted user input to build a HTTP response and sent it to browser.

=== How to prevent ===

Either apply strict input validation (whitelist approach) or use output sanitizing+escaping if input validation is not possible (combine both every time is possible).

=== Example ===

<syntaxhighlight lang="java">
/*
INPUT WAY: Receive data from user
Here it's recommended to use strict input validation using whitelist approach.
In fact, you ensure that only allowed characters are part of the input received.
*/

String userInput = "You user login is owasp-user01";

/* First we check that the value contains only expected character*/
Assert.assertTrue(Pattern.matches("[a-zA-Z0-9\\s\\-]{1,50}", userInput));

/* If the first check pass then ensure that potential dangerous character that we have allowed
for business requirement are not used in a dangerous way.
For example here we have allowed the character '-', and, this can be used in SQL injection so, we
ensure that this character is not used is a continuous form.
Use the API COMMONS LANG v3 to help in String analysis...
*/
Assert.assertEquals(0, StringUtils.countMatches(userInput.replace(" ", ""), "--"));

/*
OUTPUT WAY: Send data to user
Here we escape + sanitize any data sent to user
Use the OWASP Java HTML Sanitizer API to handle sanitizing
Use the OWASP Java Encoder API to handle HTML tag encoding (escaping)
*/

String outputToUser = "You <p>user login</p> is <strong>owasp-user01</strong>";
outputToUser += "<script>alert(22);</script><img src='#' onload='javascript:alert(23);'>";

/* Create a sanitizing policy that only allow tag '<p>' and '<strong>'*/
PolicyFactory policy = new HtmlPolicyBuilder().allowElements("p", "strong").toFactory();

/* Sanitize the output that will be sent to user*/
String safeOutput = policy.sanitize(outputToUser);

/* Encode HTML Tag*/
safeOutput = Encode.forHtml(safeOutput);
String finalSafeOutputExpected = "You <p>user login</p> is <strong>owasp-user01</strong>";
Assert.assertEquals(finalSafeOutputExpected, safeOutput);
</syntaxhighlight>

=== References ===

* [[Cross-site_Scripting_(XSS)| XSS]]

* https://github.com/owasp/java-html-sanitizer

* https://github.com/owasp/owasp-java-encoder/

* https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html

* https://commons.apache.org/proper/commons-lang/javadocs/api-3.4/org/apache/commons/lang3/StringEscapeUtils.html

== LDAP ==

A dedicated [[LDAP_Injection_Prevention_Cheat_Sheet|cheatsheet]] has been created.

== NoSQL ==

=== Symptom ===

Injection of this type occur when the application use untrusted user input to build a NoSQL API call expression.

=== How to prevent ===

As there many NoSQL database system and each one use a API for call, it's important to ensure that user input received
and used to build the API call expression do not contains any character that have a special meaning in the target API syntax.
This in order to avoid that it will be used to escape the initial call expression in order to create another one based on crafted user input.
It's also important to not use string concatenation to build API call expression but use the API to create the expression.

=== Example - MongoDB ===

<syntaxhighlight lang="java">
/* Here use MongoDB as target NoSQL DB */
String userInput = "Brooklyn";

/* First ensure that the input do no contains any special characters for the current NoSQL DB call API,
here they are: ' " \ ; { } $
*/
//Avoid regexp this time in order to made validation code more easy to read and understand...
ArrayList<String> specialCharsList = new ArrayList<String>() {{
add("'");
add("\"");
add("\\");
add(";");
add("{");
add("}");
add("$");
}};
specialCharsList.forEach(specChar -> Assert.assertFalse(userInput.contains(specChar)));
//Add also a check on input max size
Assert.assertTrue(userInput.length() <= 50);

/* Then perform query on database using API to build expression */
//Connect to the local MongoDB instance
try(MongoClient mongoClient = new MongoClient()){
MongoDatabase db = mongoClient.getDatabase("test");
//Use API query builder to create call expression
//Create expression
Bson expression = eq("borough", userInput);
//Perform call
FindIterable<org.bson.Document> restaurants = db.getCollection("restaurants").find(expression);
//Verify result consistency
restaurants.forEach(new Block<org.bson.Document>() {
@Override
public void apply(final org.bson.Document doc) {
String restBorough = (String)doc.get("borough");
Assert.assertTrue("Brooklyn".equals(restBorough));
}
});
}
</syntaxhighlight>

=== References ===

[[Testing_for_NoSQL_injection|Testing for NoSQL injection]]

https://ckarande.gitbooks.io/owasp-nodegoat-tutorial/content/tutorial/a1_-_sql_and_nosql_injection.html

https://arxiv.org/ftp/arxiv/papers/1506/1506.04082.pdf

== Log Injection ==

=== Symptom ===

[[Log_Injection|Log Injection]] occurs when an application uses untrusted data to create a message in an application log.

More information about this attack is available on this OWASP [[Log_Injection|page]].

=== How to prevent ===

In order to prevent an attacker to be able to write arbitrary content into the application log, apply the following steps:
# Limit the size of the user input value used to create the log message.
# Encode the user input used to prevent injection using html tag.
# Filter the user input used to prevent injection of '''C'''arriage '''R'''eturn (CR) or '''L'''ine '''F'''eed (LF) characters.

The project [[OWASP_Security_Logging_Project|OWASP Security Logging]] can be used to protect the application log against ''Log Injection'' attack.

=== Example ===

Usage of the ''OWASP Security Logging'' features with the LOG4J2 logging API.

Configuration of a logging policy to roll on 10 files of 5MB each one and encode/limit the log message using the ''OWASP Security Logging'' features (see the ''encode'' function usage in the ''Pattern'' tag):

<syntaxhighlight lang="xml" highlight="7">
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="error" name="SecureLoggingPolicy">
<Appenders>
<RollingFile name="RollingFile" fileName="App.log" filePattern="App-%i.log" ignoreExceptions="false">
<PatternLayout>

<Pattern>%d{ISO8601} %-5p - %encode{%.-500m}%n</Pattern>
</PatternLayout>
<Policies>
<SizeBasedTriggeringPolicy size="5MB"/>
</Policies>
<DefaultRolloverStrategy max="10"/>
</RollingFile>
</Appenders>
<Loggers>
<Root level="debug">
<AppenderRef ref="RollingFile"/>
</Root>
</Loggers>
</Configuration>
</syntaxhighlight>

Usage of the logger at code level:

<syntaxhighlight lang="java">
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
...
// No special action needed because security actions are performed at the logging policy level
Logger logger = LogManager.getLogger(MyClass.class);
logger.info(logMessage);
...
</syntaxhighlight>

=== References ===

https://logging.apache.org/log4j/2.x/manual/configuration.html

https://logging.apache.org/log4j/2.x/manual/appenders.html

https://github.com/javabeanz/owasp-security-logging

= Authors and Primary Editors =

[[User:Dominique_RIGHETTO|Dominique Righetto]] - dominique.righetto@owasp.org

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

Injection Prevention Cheat Sheet in Java

2018-11-26T13:16:03Z

Jmanico: cleanup

__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}}'''
= Introduction =
__TOC__{{TOC hidden}}

This document has for objective to provide some tips to handle ''Injection'' into Java application code.

Sample codes used in tips are located [https://github.com/righettod/injection-cheat-sheets here].

= What is Injection ? =

[[Top_10_2013-A1-Injection|Injection]] in OWASP Top 10 is defined as following:

''Consider anyone who can send untrusted data to the system, including external users, internal users, and administrators.''

= General advices to prevent Injection =

The following point can be applied, in a general way, to prevent ''Injection'' issue:

# Apply '''Input Validation''' (using whitelist approach) combined with '''Output Sanitizing+Escaping''' on user input/output.
# If you need to interact with system, try to use API features provided by your technology stack (Java / .Net / PHP...) instead of building command.

Additional advices are provided on this [[Input_Validation_Cheat_Sheet|cheatsheet]].

= Specific Injection types =

''Examples in this section will be provided in Java technology (see Maven project associated) but advices are applicable to others technologies like .Net / PHP / Ruby / Python...''

== SQL ==

=== Symptom ===

Injection of this type occur when the application use untrusted user input to build a SQL query using a String and execute it.

=== How to prevent ===

Use '''Query Parameterization'' in order to prevent injection.

=== Example ===

<syntaxhighlight lang="java">
/*No DB framework used here in order to show the real use of Prepared Statement from Java API*/
/*Open connection with H2 database and use it*/
Class.forName("org.h2.Driver");
String jdbcUrl = "jdbc:h2:file:" + new File(".").getAbsolutePath() + "/target/db";
try (Connection con = DriverManager.getConnection(jdbcUrl)) {

/* Sample A: Select data using Prepared Statement*/
String query = "select * from color where friendly_name = ?";
List<String> colors = new ArrayList<>();
try (PreparedStatement pStatement = con.prepareStatement(query)) {
pStatement.setString(1, "yellow");
try (ResultSet rSet = pStatement.executeQuery()) {
while (rSet.next()) {
colors.add(rSet.getString(1));
}
}
}
Assert.assertEquals(1, colors.size());
Assert.assertTrue(colors.contains("yellow"));

/* Sample B: Insert data using Prepared Statement*/
query = "insert into color(friendly_name, red, green, blue) values(?, ?, ?, ?)";
int insertedRecordCount;
try (PreparedStatement pStatement = con.prepareStatement(query)) {
pStatement.setString(1, "orange");
pStatement.setInt(2, 239);
pStatement.setInt(3, 125);
pStatement.setInt(4, 11);
insertedRecordCount = pStatement.executeUpdate();
}
Assert.assertEquals(1, insertedRecordCount);

/* Sample C: Update data using Prepared Statement*/
query = "update color set blue = ? where friendly_name = ?";
int updatedRecordCount;
try (PreparedStatement pStatement = con.prepareStatement(query)) {
pStatement.setInt(1, 10);
pStatement.setString(2, "orange");
updatedRecordCount = pStatement.executeUpdate();
}
Assert.assertEquals(1, updatedRecordCount);

/* Sample D: Delete data using Prepared Statement*/
query = "delete from color where friendly_name = ?";
int deletedRecordCount;
try (PreparedStatement pStatement = con.prepareStatement(query)) {
pStatement.setString(1, "orange");
deletedRecordCount = pStatement.executeUpdate();
}
Assert.assertEquals(1, deletedRecordCount);

}
</syntaxhighlight>

=== References ===

* [[SQL_Injection_Prevention_Cheat_Sheet|SQL Injection Prevention Cheat Sheet]]

== JPA ==

=== Symptom ===

Injection of this type occur when the application use untrusted user input to build a JPA query using a String and execute it. It's quite similar to SQL injection but here the altered language is not SQL but JPA QL.

=== How to prevent ===

Use Java Persistence Query Language '''Query Parameterization''' in order to prevent injection.

=== Example ===

<syntaxhighlight lang="java">
EntityManager entityManager = null;
try {
/* Get a ref on EntityManager to access DB */
entityManager = Persistence.createEntityManagerFactory("testJPA").createEntityManager();

/* Define parametrized query prototype using named parameter to enhance readability */
String queryPrototype = "select c from Color c where c.friendlyName = :colorName";

/* Create the query, set the named parameter and execute the query */
Query queryObject = entityManager.createQuery(queryPrototype);
Color c = (Color) queryObject.setParameter("colorName", "yellow").getSingleResult();

/* Ensure that the object obtained is the right one */
Assert.assertNotNull(c);
Assert.assertEquals(c.getFriendlyName(), "yellow");
Assert.assertEquals(c.getRed(), 213);
Assert.assertEquals(c.getGreen(), 242);
Assert.assertEquals(c.getBlue(), 26);
} finally {
if (entityManager != null && entityManager.isOpen()) {
entityManager.close();
}
}
</syntaxhighlight>

=== References ===

* https://software-security.sans.org/developer-how-to/fix-sql-injection-in-java-persistence-api-jpa

== Operating System ==

=== Symptom ===

Injection of this type occur when the application use untrusted user input to build a Operating System command using a String and execute it.

=== How to prevent ===

Use technology stack '''API''' in order to prevent injection.

=== Example ===

<syntaxhighlight lang="java">
/* The context taken is, for example, to perform a PING against a computer.
* The prevention is to use the feature provided by the Java API instead of building
* a system command as String and execute it */
InetAddress host = InetAddress.getByName("localhost");
Assert.assertTrue(host.isReachable(5000));
</syntaxhighlight>

=== References ===

* [[Command_Injection|Command Injection]]

== XML: External Entity attack ==

=== Symptom ===

Injection of this type occur when the application load the received XML stream using a XML parser instance in which the resolution of External Entity is not disabled.

=== How to prevent ===

Disable to resolution of the External Entity in the parser instance to prevent injection.

=== Example ===

<syntaxhighlight lang="java">
/*Create a XML document builder factory*/
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

/*Disable External Entity resolution for differents cases*/
// This is the PRIMARY defense. If DTDs (doctypes) are disallowed,
// almost all XML entity attacks are prevented
// Xerces 2 only - http://xerces.apache.org/xerces2-j/features.html#disallow-doctype-decl
String feature = "http://apache.org/xml/features/disallow-doctype-decl";
dbf.setFeature(feature, true);

// If you can't completely disable DTDs, then at least do the following:
// Xerces 1 - http://xerces.apache.org/xerces-j/features.html#external-general-entities
// Xerces 2 - http://xerces.apache.org/xerces2-j/features.html#external-general-entities
// JDK7+ - http://xml.org/sax/features/external-general-entities
feature = "http://xml.org/sax/features/external-general-entities";
dbf.setFeature(feature, false);

// Xerces 1 - http://xerces.apache.org/xerces-j/features.html#external-parameter-entities
// Xerces 2 - http://xerces.apache.org/xerces2-j/features.html#external-parameter-entities
// JDK7+ - http://xml.org/sax/features/external-parameter-entities
feature = "http://xml.org/sax/features/external-parameter-entities";
dbf.setFeature(feature, false);

// feature external DTDs as well
feature = "http://apache.org/xml/features/nonvalidating/load-external-dtd";
dbf.setFeature(feature, false);

// and these as well, per Timothy Morgan's 2014 paper: "XML Schema, DTD, and Entity Attacks"
dbf.setXIncludeAware(false);
dbf.setExpandEntityReferences(false);

/*Load XML file*/
DocumentBuilder builder = dbf.newDocumentBuilder();
//Here an org.xml.sax.SAXParseException will be throws because the XML contains a External Entity.
builder.parse(new File("src/test/resources/SampleXXE.xml"));
</syntaxhighlight>

== XML: XPath Injection ==

=== Symptom ===

Injection of this type occur when the application use untrusted user input to build a XPath query using a String and execute it.

=== How to prevent ===

Use '''XPath Variable Resolver''' in order to prevent injection.

=== Example ===

'''Variable Resolver''' implementation.

<syntaxhighlight lang="java">
/**
* Resolver in order to define parameter for XPATH expression.
*
*/
public class SimpleVariableResolver implements XPathVariableResolver {

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

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

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

Code using it to perform XPath query.

<syntaxhighlight lang="java">
/*Create a XML document builder factory*/
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

/*Disable External Entity resolution for differents cases*/
//Do not performed here in order to focus on variable resolver code
//but do it for production code !

/*Load XML file*/
DocumentBuilder builder = dbf.newDocumentBuilder();
Document doc = builder.parse(new File("src/test/resources/SampleXPath.xml"));

/* Create and configure parameter resolver */
String bid = "bk102";
SimpleVariableResolver variableResolver = new SimpleVariableResolver();
variableResolver.addVariable(new QName("bookId"), bid);

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

/* Apply expression on XML document */
Object nodes = xPathExpression.evaluate(doc, XPathConstants.NODESET);
NodeList nodesList = (NodeList) nodes;
Assert.assertNotNull(nodesList);
Assert.assertEquals(1, nodesList.getLength());
Element book = (Element)nodesList.item(0);
Assert.assertTrue(book.getTextContent().contains("Ralls, Kim"));
</syntaxhighlight>

=== References ===

* [[XPATH_Injection|XPATH Injection]]

== HTML/JavaScript/CSS ==

=== Symptom ===

Injection of this type occur when the application use untrusted user input to build a HTTP response and sent it to browser.

=== How to prevent ===

Either apply strict input validation (whitelist approach) or use output sanitizing+escaping if input validation is not possible (combine both every time is possible).

=== Example ===

<syntaxhighlight lang="java">
/*
INPUT WAY: Receive data from user
Here it's recommended to use strict input validation using whitelist approach.
In fact, you ensure that only allowed characters are part of the input received.
*/

String userInput = "You user login is owasp-user01";

/* First we check that the value contains only expected character*/
Assert.assertTrue(Pattern.matches("[a-zA-Z0-9\\s\\-]{1,50}", userInput));

/* If the first check pass then ensure that potential dangerous character that we have allowed
for business requirement are not used in a dangerous way.
For example here we have allowed the character '-', and, this can be used in SQL injection so, we
ensure that this character is not used is a continuous form.
Use the API COMMONS LANG v3 to help in String analysis...
*/
Assert.assertEquals(0, StringUtils.countMatches(userInput.replace(" ", ""), "--"));

/*
OUTPUT WAY: Send data to user
Here we escape + sanitize any data sent to user
Use the OWASP Java HTML Sanitizer API to handle sanitizing
Use the OWASP Java Encoder API to handle HTML tag encoding (escaping)
*/

String outputToUser = "You <p>user login</p> is <strong>owasp-user01</strong>";
outputToUser += "<script>alert(22);</script><img src='#' onload='javascript:alert(23);'>";

/* Create a sanitizing policy that only allow tag '<p>' and '<strong>'*/
PolicyFactory policy = new HtmlPolicyBuilder().allowElements("p", "strong").toFactory();

/* Sanitize the output that will be sent to user*/
String safeOutput = policy.sanitize(outputToUser);

/* Encode HTML Tag*/
safeOutput = Encode.forHtml(safeOutput);
String finalSafeOutputExpected = "You <p>user login</p> is <strong>owasp-user01</strong>";
Assert.assertEquals(finalSafeOutputExpected, safeOutput);
</syntaxhighlight>

=== References ===

* [[Cross-site_Scripting_(XSS)| XSS]]

* https://github.com/owasp/java-html-sanitizer

* https://github.com/owasp/owasp-java-encoder/

* https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html

* https://commons.apache.org/proper/commons-lang/javadocs/api-3.4/org/apache/commons/lang3/StringEscapeUtils.html

== LDAP ==

A dedicated [[LDAP_Injection_Prevention_Cheat_Sheet|cheatsheet]] has been created.

== NoSQL ==

=== Symptom ===

Injection of this type occur when the application use untrusted user input to build a NoSQL API call expression.

=== How to prevent ===

As there many NoSQL database system and each one use a API for call, it's important to ensure that user input received
and used to build the API call expression do not contains any character that have a special meaning in the target API syntax.
This in order to avoid that it will be used to escape the initial call expression in order to create another one based on crafted user input.
It's also important to not use string concatenation to build API call expression but use the API to create the expression.

=== Example - MongoDB ===

<syntaxhighlight lang="java">
/* Here use MongoDB as target NoSQL DB */
String userInput = "Brooklyn";

/* First ensure that the input do no contains any special characters for the current NoSQL DB call API,
here they are: ' " \ ; { } $
*/
//Avoid regexp this time in order to made validation code more easy to read and understand...
ArrayList<String> specialCharsList = new ArrayList<String>() {{
add("'");
add("\"");
add("\\");
add(";");
add("{");
add("}");
add("$");
}};
specialCharsList.forEach(specChar -> Assert.assertFalse(userInput.contains(specChar)));
//Add also a check on input max size
Assert.assertTrue(userInput.length() <= 50);

/* Then perform query on database using API to build expression */
//Connect to the local MongoDB instance
try(MongoClient mongoClient = new MongoClient()){
MongoDatabase db = mongoClient.getDatabase("test");
//Use API query builder to create call expression
//Create expression
Bson expression = eq("borough", userInput);
//Perform call
FindIterable<org.bson.Document> restaurants = db.getCollection("restaurants").find(expression);
//Verify result consistency
restaurants.forEach(new Block<org.bson.Document>() {
@Override
public void apply(final org.bson.Document doc) {
String restBorough = (String)doc.get("borough");
Assert.assertTrue("Brooklyn".equals(restBorough));
}
});
}
</syntaxhighlight>

=== References ===

[[Testing_for_NoSQL_injection|Testing for NoSQL injection]]

https://ckarande.gitbooks.io/owasp-nodegoat-tutorial/content/tutorial/a1_-_sql_and_nosql_injection.html

https://arxiv.org/ftp/arxiv/papers/1506/1506.04082.pdf

== Log Injection ==

=== Symptom ===

[[Log_Injection]] occurs when an application uses untrusted data to create a message in an application log.

More information about this attack is available on this OWASP [[Log_Injection|page]].

=== How to prevent ===

In order to prevent an attacker to be able to write arbitrary content into the application log, apply the following steps:
# Limit the size of the user input value used to create the log message.
# Encode the user input used to prevent injection using html tag.
# Filter the user input used to prevent injection of '''C'''arriage '''R'''eturn (CR) or '''L'''ine '''F'''eed (LF) characters.

The project [[OWASP_Security_Logging_Project|OWASP Security Logging]] can be used to protect the application log against ''Log Injection'' attack.

=== Example ===

Usage of the ''OWASP Security Logging'' features with the LOG4J2 logging API.

Configuration of a logging policy to roll on 10 files of 5MB each one and encode/limit the log message using the ''OWASP Security Logging'' features (see the ''encode'' function usage in the ''Pattern'' tag):

<syntaxhighlight lang="xml" highlight="7">
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="error" name="SecureLoggingPolicy">
<Appenders>
<RollingFile name="RollingFile" fileName="App.log" filePattern="App-%i.log" ignoreExceptions="false">
<PatternLayout>

<Pattern>%d{ISO8601} %-5p - %encode{%.-500m}%n</Pattern>
</PatternLayout>
<Policies>
<SizeBasedTriggeringPolicy size="5MB"/>
</Policies>
<DefaultRolloverStrategy max="10"/>
</RollingFile>
</Appenders>
<Loggers>
<Root level="debug">
<AppenderRef ref="RollingFile"/>
</Root>
</Loggers>
</Configuration>
</syntaxhighlight>

Usage of the logger at code level:

<syntaxhighlight lang="java">
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
...
// No special action needed because security actions are performed at the logging policy level
Logger logger = LogManager.getLogger(MyClass.class);
logger.info(logMessage);
...
</syntaxhighlight>

=== References ===

https://logging.apache.org/log4j/2.x/manual/configuration.html

https://logging.apache.org/log4j/2.x/manual/appenders.html

https://github.com/javabeanz/owasp-security-logging

= Authors and Primary Editors =

[[User:Dominique_RIGHETTO|Dominique Righetto]] - dominique.righetto@owasp.org

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

Securing Cascading Style Sheets (CSS) Cheat Sheet

2018-11-25T11:53:09Z

Jmanico: cleanup defense mechanism 3

Securing Cascading Style Sheets (CSS) Cheat Sheet

2018-11-25T11:44:22Z

Jmanico: clearity

Securing Cascading Style Sheets (CSS) Cheat Sheet

2018-11-25T11:41:37Z

Jmanico: cleanup

Securing Cascading Style Sheets (CSS) Cheat Sheet

2018-11-25T11:40:32Z

Jmanico: edits for clarity

Securing Cascading Style Sheets (CSS) Cheat Sheet

2018-11-25T11:33:58Z

Jmanico: editing for clarity

Securing Cascading Style Sheets (CSS) Cheat Sheet

2018-11-25T11:30:57Z

Jmanico: editing for clarity

Securing Cascade Style Sheets (CSS) Cheat Sheet

2018-11-25T11:22:59Z

Jmanico: move for name change

#REDIRECT [[Securing Cascading Style_Sheets (CSS)_Cheat_Sheet]]

Securing Cascading Style Sheets (CSS) Cheat Sheet

2018-11-25T11:22:09Z

Jmanico: move for page title name change

Securing Cascade Style Sheets (CSS) Cheat Sheet

2018-11-25T11:20:17Z

Jmanico: cascade to cascading

Template:Cheatsheet Navigation Body

2018-11-24T09:38:23Z

Jmanico: added css security

<noinclude>See documentation of [[Template:navigationBoxBegin|the navigationBoxBegin template]] to see how this works...</noinclude>
{{navigationBoxBegin|title=[[Cheat_Sheets|Cheat Sheets]]|editlink={{FULLPAGENAME}}}}
{{navigationBoxRow|title=Developer / Builder|content=
* [[3rd_Party_Javascript_Management_Cheat_Sheet|3rd Party Javascript Management]]
* [[Access Control Cheat Sheet|Access Control]]
* [[AJAX Security Cheat Sheet]]
* [[Authentication Cheat Sheet|Authentication]] ([[Authentication_Cheat_Sheet_Español|ES]])
* [[Bean Validation Cheat Sheet]]
* [[Choosing and Using Security Questions Cheat Sheet|Choosing and Using Security Questions]]
* [[Clickjacking Defense Cheat Sheet|Clickjacking Defense]]
* [[Credential Stuffing Prevention Cheat Sheet]]
* [[Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet|Cross-Site Request Forgery (CSRF) Prevention]]
* [[Cryptographic Storage Cheat Sheet|Cryptographic Storage]]
* [[C-Based Toolchain Hardening Cheat Sheet|C-Based Toolchain Hardening]]
* [[Securing Cascade Style Sheets (CSS) Cheat Sheet|CSS Security]]
* [[Deserialization_Cheat_Sheet|Deserialization]]
* [[DOM based XSS Prevention Cheat Sheet|DOM based XSS Prevention]]
* [[Forgot Password Cheat Sheet|Forgot Password]]
* [[HTML5 Security Cheat Sheet|HTML5 Security]]
* [[HTTP Strict Transport Security Cheat Sheet|HTTP Strict Transport Security]]
* [[Injection Prevention Cheat Sheet]]
* [[Injection Prevention Cheat Sheet in Java]]
* [[JSON Web Token (JWT) Cheat Sheet for Java]]
* [[Input Validation Cheat Sheet|Input Validation]]
* [[Insecure Direct Object Reference Prevention Cheat Sheet|Insecure Direct Object Reference Prevention]]
* [[JAAS Cheat Sheet|JAAS]]
* [[Key Management Cheat Sheet|Key Management]]
* [[LDAP Injection Prevention Cheat Sheet|LDAP Injection Prevention]]
* [[Logging Cheat Sheet|Logging]]
* [[Mass Assignment Cheat Sheet]]
* [[.NET Security Cheat Sheet|.NET Security]]
* [[OS Command Injection Defense Cheat Sheet]]
* [[OWASP Top Ten Cheat Sheet|OWASP Top Ten]]
* [[Password Storage Cheat Sheet|Password Storage]]
* [[Pinning Cheat Sheet|Pinning]]
* [[Query Parameterization Cheat Sheet|Query Parameterization]]
* [[REST Security Cheat Sheet|REST Security]]
* [[Ruby on Rails Cheatsheet|Ruby on Rails]]
* [[Session Management Cheat Sheet|Session Management]]
* [[SAML Security Cheat Sheet|SAML Security]]
* [[SQL Injection Prevention Cheat Sheet|SQL Injection Prevention]]
* [[Transaction Authorization Cheat Sheet|Transaction Authorization]]
* [[Transport Layer Protection Cheat Sheet|Transport Layer Protection]]
* [[TLS_Cipher_String_Cheat_Sheet|TLS Cipher String Configuration]]
* [[Unvalidated Redirects and Forwards Cheat Sheet|Unvalidated Redirects and Forwards]]
* [[User Privacy Protection Cheat Sheet|User Privacy Protection]]
* [[Web Service Security Cheat Sheet|Web Service Security]]
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet|XSS (Cross Site Scripting) Prevention]]
* [[XML External Entity (XXE) Prevention Cheat Sheet]]
}}
{{navigationBoxRow|title=Assessment / Breaker|content=
* [[Attack Surface Analysis Cheat Sheet|Attack Surface Analysis]]
* [[REST Assessment Cheat Sheet|REST Assessment]]
* [[Web Application Security Testing Cheat Sheet|Web Application Security Testing]]
* [[XML Security Cheat Sheet]]
* [[XSS Filter Evasion Cheat Sheet|XSS Filter Evasion]]
}}
{{navigationBoxRow|title=Mobile|content=
* [[Android_Testing_Cheat_Sheet|Android Testing]]
* [[IOS Developer Cheat Sheet|IOS Developer]]
* [[Mobile Jailbreaking Cheat Sheet|Mobile Jailbreaking]]
}}
{{navigationBoxRow|title=OpSec / Defender|content=
* [[Virtual Patching Cheat Sheet|Virtual Patching]]
* [[Vulnerability Disclosure Cheat Sheet|Vulnerability Disclosure]]
}}
{{navigationBoxRow|title=Draft and Beta|content=
* [[Application Security Architecture Cheat Sheet|Application Security Architecture]]
* [[Business Logic Security Cheat Sheet|Business Logic Security]]
* [[Content Security Policy Cheat Sheet|Content Security Policy]]
* [[Denial of Service Cheat Sheet]]
* [[Grails Secure Code Review Cheat Sheet|Grails Secure Code Review]]
* [[IOS Application Security Testing Cheat Sheet|IOS Application Security Testing]]
* [[PHP Security Cheat Sheet|PHP Security]]
* [[Regular Expression Security Cheatsheet]]
* [[Secure Coding Cheat Sheet|Secure Coding]]
* [[Secure SDLC Cheat Sheet|Secure SDLC]]
* [[Threat Modeling Cheat Sheet|Threat Modeling]]
}}
{{navigationBoxEnd|content=[[:Category:Cheatsheets|All Pages In This Category]]}}

Securing Cascade Style Sheets (CSS) Cheat Sheet

2018-11-24T09:34:17Z

Jmanico: cleanup

Securing Cascade Style Sheets (CSS) Cheat Sheet

2018-11-24T09:33:21Z

Jmanico: cleanup

Securing Cascade Style Sheets (CSS) Cheat Sheet

2018-11-24T09:32:50Z

Jmanico: small fix

Securing Cascade Style Sheets (CSS) Cheat Sheet

2018-11-24T09:32:08Z

Jmanico: css security cheatsheet

ASVS V20 Internet of Things

2018-11-07T16:48:35Z

Jmanico: de