OWASP - User contributions [en]

OWTGv4 Contributors list

2015-06-03T13:53:10Z

Tomas Zatko: Added Tomas Zatko. He is already in pdf version https://www.owasp.org/images/5/52/OWASP_Testing_Guide_v4.pdf

'''Proposed Contributors team (DRAFT):'''<br>
This page is obsolete, we will create a new one at the end of the project <br>
<br>
> Matteo Meucci<br>
> Pavol Luptak<br>
> Marco Morana<br>
> Giorgio Fedon<br>
> Stefano Di Paola<br>
> Gianrico Ingrosso<br>
> Giuseppe Bonfà<br>
> Roberto Suggi Liverani<br>
> Robert Smith<br>
> Andrew Muller<br>
> Robert Winkel<br>
> tripurari rai<br>
> Thomas Ryan<br>
> tim bertels<br>
> Cecil Su<br>
> Aung KhAnt<br>
> Norbert Szetei<br>
> michael.boman<br>
> Wagner Elias<br>
> Kevin Horvat<br>
> Tom Brennan <br>
> Juan Galiana Lara<br>
> Sumit Siddharth<br>
> Mike Hryekewicz<br>
> Simon Bennetts<br>
> Ray Schippers<br>
> Raul Siles<br>
> Jayanta Karmakar<br>
> Brad Causey<br>
> Vicente Aguilera<br>
> Ismael Gonçalves <br>
> David Fern<br>
> Tom Eston<br>
> Kevin Horvath<br>
> Rick Mitchell<br>
> Eduardo Castellanos <br>
> Simone Onofri <br>
> Harword Sheen <br>
> Amro AlOlaqi <br>
> Suhas Desai<br>
> Ryan Dewhurst<br>
> Zaki Akhmad <br>
> Davide Danelon <br>
> Alexander Antukh <br>
> Thomas Kalamaris <br>
> Alexander Vavousis <br>
> Clerkendweller <br>
> Christian Heinrich <br>
> Babu Arokiadas <br>
> Rob Barnes <br>
> Ben Walther <br>
> Tomas Zatko <br>

<br>
'''Reviewers team (Rev. 7 Apr 2014):'''<br>
<br>
- Davide Danelon <br>
- Andrea Rosignoli<br>
- Irene Abezgauz<br>
- Lode Vanstechelman<br>
- Sebastien Gioria<br>
- Yiannis Pavlosoglou <br>
- Aditya Balapure <br>

Testing for Clickjacking (OTG-CLIENT-009)

2013-12-15T23:40:22Z

Tomas Zatko: X-Frame-Options values

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
<br>
"Clickjacking" (that is a subset of the "UI redressing") is a malicious technique that consists of deceiving a web user into interact (in most cases by clicking) on something different to what the user believes he is interacting on. This type of attack, that can be used alone or in combination with other attacks, could potentially send unauthorized commands or reveal confidential information while the victim is interacting on seemingly harmless web pages. The term "Clickjacking" was coined by Jeremiah Grossman and Robert Hansen in 2008.
<br>
== Description of the Issue ==
<br>
A Clickjacking attack uses seemingly innocuous features of HTML and Javascript to force the victim to perform undesired actions, such as clicking on a button that appears to perform another operation. This is a "client side" security issue that affects a variety of browsers and platforms.
To carry out this type of technique the attacker has to create a seemingly harmless web page that loads the target application throught the use of an iframe (suitably concealed through the use of CSS code). Once this is done, the attacker could induce the victim to interact with his fictitious web page by other means (like for example social engineering). Like others attacks, an usual prerequisite is that the victim is authenticated against the attacker's target website.

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

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

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

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

<br>
== Black Box testing and example ==
<br>
Blackbox testing for Clickjacking is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.
<br>

== Gray Box testing and example ==
<br>
===Testing for Clickjacking vulnerabilities:===
As mentioned above, this type of attack is often designed to allow an attacker site to induce user's actions on the target site even if anti-CSRF tokens are being used. So it's important, like for the CSRF attack, to individuate web pages of the target site that it take input from the user.
We have to discover if the website that we are testing has no protections against clickjacking attacks or, if the developers have implemented some forms of protection, if these techniques are liable to bypass. Once we know that the website is vulnerable, we can create a "proof of concept" to exploit the vulnerability.
The first step to discover if a website is vulnerable, is to check if the target web page could be loaded into an iframe.
To do this you need to create a simple web page that includes a frame containing the target web page. The HTML code to create this testing web page is displayed in the following snippet:

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

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

===Bypass Clickjacking protection:===
In case in which you only see the target site or the text "Website is vulnerable to clickjacking!" but nothing in the iframe this mean that the target probably has some form of protection against clickjacking. It’s important to note that this isn’t a guarantee that the page is totally immune to clickjacking.
Methods to protect a web page from clickjacking can be divided in two macro-categories:
* Client side protection: Frame Busting
* Server side protection: X-Frame-Options
In some circumstances, every single type of defense could be bypassed. Following are presented the main methods of protection from these attacks and techniques to bypass them.

====Client side protection: Frame Busting====
The most common client side method, that has been developed to protect a web page from clickjacking, is called Frame Busting and it consists of a script in each page that should not be framed. The aim of this technique is to prevent a site from functioning when it is loaded inside a frame.
The structure of frame busting code typically consists of a "conditional statement" and a "counter-action" statement.
For this type of protection, there are some circumventions that fall under the name of "Bust frame busting". Some of this techniques are browser-specific while others work across browsers.

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

'''Double Framing'''
<br>
Some frame busting techniques try to break frame by assigning a value to the "parent.location" attribute in the "counter-action" statement. Such actions are, for example:
* self.parent.location = document.location
* parent.location.href = self.location
* parent.location = self.location
This method works well until the target page is framed by a single page. However, if the attacker encloses the target web page in one frame which is nested in another one (a double frame), then trying to access to "parent.location" becomes a security violation in all popular browsers, due to the descendant frame navigation policy. This security violation disables the counter-action navigation.
Target site frame busting code (target site):

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

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

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

'''Disabling javascript'''
<br>
Since these type of client side protections relies on JavaScript frame busting code, if the victim has JavaScript disabled or it is possible for an attacker to disable JavaScript code, the web page will not have any protection mechanism against clickjacking. There are three deactivation techniques that can be used with frames:
* Restricted frames with Internet Explorer: Starting from Internet Explorer 6, a frame can have the "security" attribute that, if it is set to the value "restricted", ensures that JavaScript code, ActiveX controls, and re-directs to other sites do not work in the frame.
Example:
<pre>
<iframe src="http://target site" security="restricted"></iframe>
</pre>
* Sandbox attribute: with HTML5 there is a new attribute called "sandbox". It enables a set of restrictions on content loaded into the iframe. At this moment this attribute is only compatible whit Chrome and Safari.
Example:
<pre>
<iframe src="http://target site" sandbox></iframe>
</pre>
* Design mode: Paul Stone showed a security issue concerning the "designMode" that can be turned on in the framing page (via document.designMode), disabling JavaScript in top and sub-frame. The design mode is currently implemented in Firefox and IE8.

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

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

The previous technique requires the user interaction but, the same result, can be achieved without prompting the user. To do this the attacker have to automatically cancel the incoming navigation request in an onBeforeUnload event handler by repeatedly submitting (for example every millisecond) a navigation request to a web page that responds with a "HTTP/1.1 204 No Content" header.
Since with this response the browser will do nothing, the resulting of this operation is the flushing of the request pipeline, rendering the original frame busting attempt futile.
Following an example code:

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

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

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

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

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

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

'''Redefining location'''
<br>
For several browser the "document.location" variable is an immutable attribute. However, for some version of Internet Explorer and Safari, it is possible to redefine this attribute. This fact can be exploited to evade frame busting code.
* <b>Redefining location in IE7 and IE8</b>: it is possible to redefine "location" as it is illustrated in the following example. By defining "location" as a variable, any code that tries to read or to navigate by assigning "top.location" will fail due to a security violation and so the frame busting code is suspended.
Example:
<pre>
<script>
var location = "xyz";
</script>
<iframe src="http://target site"></iframe>
</pre>
* <b>Redefining location in Safari 4.0.4</b>: To bust frame busting code with "top.location" it is possible to bind "location" to a function via defineSetter (through window), so that an attempt to read or navigate to the "top.location" will fail.
Example:
<pre>
<script>
window.defineSetter("location" , function(){});
</script>
<iframe src="http://target site"></iframe>
</pre>

====Server side protection: X-Frame-Options====
An alternative approach to client side frame busting code was implemented by Microsoft and it consists of an header based defense. This new "X-FRAME-OPTIONS" header is sent from the server on HTTP responses and is used to mark web pages that shouldn't be framed. This header can take the values DENY, SAMEORIGIN, ALLOW-FROM origin, or non-standard ALLOWALL. Recommended value is DENY.
The "X-FRAME-OPTIONS" is a very good solution, and was adopted by major browser, but also for this technique there are some limitations that could lead in any case to exploit the clickjacking vulnerability.

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

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

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

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

===Create a "proof of concept" ===
Once we have discovered that the site we are testing is vulnerable to clickjacking attack, we can proceed with the development of a "proof of concept" to demonstrate the vulnerability.
It is important to note that, as mentioned previously, these attacks can be used in conjunction with other forms of attacks (for example CSRF attacks) and could lead to overcome anti-CSRF tokens.
In this regard we can imagine that, for example, the target site allows to authenticated and authorized users to make a transfer of money to another account.
Suppose that to execute the transfer the developers have planned three steps. In the first step the user fill a form with the destination account and the amount. In the second step, whenever the user submits the form, is presented a summary page asking the user confirmation (like the one presented in the following picture).

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

Following a snippet of the code for the step 2:

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

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

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

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

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

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

//here we can suppose input sanitization code…

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

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

As you can see the code is protected from CSRF attack both with a random token generated in the second step and accepting only variable passed via POST method.
In this situation an attacker could forge a CSRF + Clickjacking attack to evade anti-CSRF protection and force a victim to do a money transfer without her consent.
The target page for the attack is the second step of the money transfer procedure. Since the developers put the security controls only in the last step, thinking that this is secure enough, the attacker could pass the account and amount parameters via GET method. (<b>Note</b>: there is an advanced clickjacking attack that permits to force users to fill a form, so also in the case in which is required to fill a form, the attack is feasible).
The attacker's page may look a simple and harmless web page like the one presented below:

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

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

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

The clickjacking code the create this page is presented below:

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

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

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

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

</pre>

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

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

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

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

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

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

Conduct search engine discovery/reconnaissance for information leakage (OTG-INFO-001)

2013-12-11T15:17:07Z

Tomas Zatko: Added PunkSPIDER, Google Hacking Database, changed reference numbers to make them unique

{{Template:OWASP Testing Guide v4}}

== Summary ==
There are direct and indirect elements to search engine discovery and reconnaissance. Direct methods relate to searching the indexes and the associated content from caches. Indirect methods relate to gleaning sensitive design and configuration information by searching forums, newsgroups and tendering websites.

Once a search engine robot has completed crawling, it commences indexing the web page based on tags and associated attributes, such as <TITLE>, in order to return the relevant search results. [1]

If the robots.txt file is not updated during the lifetime of the web site, and inline HTML meta tags that instruct robots not to index content ahve not been used, then it is possible for indexes to contain web content not intended to be included in by the owners. Website owners may use the previously mentioned robots.txt, HTML meta tags, authentication and tools provided by search engines to remove such content.

== Test Objectives ==

To understand what sensitive design and configuration information is exposed of the application/system/organisation both directly (on the organisation's website) or indirectly (on a third party website)

== How to Test ==

Using a search engine, search for:
* Network diagrams and configurations
* Archived posts and emails by administrators and other key staff
* Logon procedures and username formats
* Usernames and passwords
* Error message content
* Development, test, UAT and staging versions of the website

=== Black Box Testing ===
Using the advanced "site:" search operator, it is possible to restrict search results to a specific domain [2]. Do not limit testing to just one search engine provider - they may generate different results depending on when they crawled content and their own algorithms. Consider:

* Baidu
* binsearch.info
* Bing
* Duck Duck Go
* ixquick/Startpage
* Google
* Shodan
* PunkSpider

Duck Duck Go and ixquick/Startpage provide reduced information leakage about the tester.

Google provides the Advanced "cache:" search operator [2], but this is the equivalent to clicking the "Cached" next to each Google Search Result. Hence, the use of the Advanced "site:" Search Operator and then clicking "Cached" is preferred.

The Google SOAP Search API supports the doGetCachedPage and the associated doGetCachedPageResponse SOAP Messages [3] to assist with retrieving cached pages. An implementation of this is under development by the [[::Category:OWASP_Google_Hacking_Project |OWASP "Google Hacking" Project]].

PunkSpider is web application vulnerability search engine. It has little use for pentester doing manual work. However it can be useful as demonstration of easiness of finding vulnerabilities by script-kiddies.

==== Example ====
To find the web content of owasp.org indexed by a typical search engine, the syntax required is:
<pre>
site:owasp.org
</pre>
[[Image:Google_site_Operator_Search_Results_Example_20121219.jpg]]

To display the index.html of owasp.org as cached, the syntax is:
<pre>
cache:owasp.org
</pre>
[[Image:Google_cache_Operator_Search_Results_Example_20121219.jpg]]

==== Google Hacking Database ====

Google Hacking Database is list of useful search queries for for google. Queries are put in several categories:
* Footholds
* Files containing usernames
* Sensitive Directories
* Web Server Detection
* Vulnerable Files
* Vulnerable Servers
* Error Messages
* Files containing juicy info
* Files containing passwords
* Sensitive Online Shopping Info

=== Gray Box testing and example ===
Gray Box testing is the same as Black Box testing above.

== Vulnerability References ==
'''Web'''<br>
[1] "Google Basics: Learn how Google Discovers, Crawls, and Serves Web Pages" - http://www.google.com/support/webmasters/bin/answer.py?answer=70897 <br>
[2] "Operators and More Search Help" - http://support.google.com/websearch/bin/answer.py?hl=en&answer=136861 <br>
[3] "Google Hacking Database" - http://www.exploit-db.com/google-dorks/ <br>

== Tools ==
[4] FoundStone SiteDigger - http://www.mcafee.com/uk/downloads/free-tools/sitedigger.aspx <br>
[5] Google Hacker - http://yehg.net/lab/pr0js/files.php/googlehacker.zip<br>
[6] Stach & Liu's Google Hacking Diggity Project - http://www.stachliu.com/resources/tools/google-hacking-diggity-project/ <br>
[7] PunkSPIDER - http://punkspider.hyperiongray.com/ <br>

== Remediation ==
Carefully consider the sensitivity of design and configuration information before it is posted online.

Periodically review the sensitivity of existing design and configuration information that is posted online.

Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)

2013-12-11T14:18:07Z

Tomas Zatko: Added Testing via HTTP proxy with example. Also some minor changes.

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Sensitive data must be protected when it is transmitted through the network. These data includes 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]. Use of these protocols ensure not only confidentiality but also authentication. Servers are authenticated using digital certificates, and it is also possibile to use client certificate for mutual authentication.

Even if high grade ciphers are today supported and normally used, some misconfiguration in 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.

== Description of the Issue ==
If control is missed and HTTP protocol is used to transmit sensitive information is a vulnerability [2] (e.g. credentials transmitted over HTTP [3]) and there are a specific OWASP Testing Guide v4’s test.

If SSL/TLS service is present it is good but it increments the attack surface and some vulnerabilities insist on it, such as:
* SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured.
* Certificate validity must be ensured.
Other vulnerabilities linked to this is:
* 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===
If the application transmits sensitive information via unencrypted channels - e.g. HTTP - it is a vulnerability. 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/TSL 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, for example, 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, like follow:
# 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, we 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 is examine each check more in detail.

* Each browser comes with a preloaded 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 vulnerability if software is not up to date [4]. Futhermore for a correct protection of data during transmission 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 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.

== Black Box testing and example ==

===Testing for sensitive data transmitted in clear-text===
Various typologies of information which must be protected can be also transmitted in clear text. It is possible to check if these 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. Also because with Basic Authentication, after login, 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/TSL Ciphers/Protocols/Keys vulnerabilities===
Large number of available cipher suites and quick progress in cryptanalysis makes judging a 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 most 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].

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], and other used into examples - can be used to assess SSL/TLS vulnerabilities. But due to evolution of these vulnerabilities a good way is also to check them manually with openssl [30] or using tool’s output as an input for manual evaluation using the references on the bottom on the Test to stay updated.

Sometimes the SSL/TLS enabled service is not directly accessible and you can access it only via HTTP proxy using CONNECT method [36]. Most of the tools will try to connect to desired tcp port in order to start SSL/TLS handshake. This will obviously not work since desired port is accessible only via HTTP proxy. You can easily circumvent this by using relaying software such as socat [37].

====Example 2. SSL service recognition via nmap====
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 for 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 we try to initiate a renegotiation by client [m] connecting to server with openssl - writing the fist line of an HTTP request, in a new line typing “R”, waiting for renegotiaion and completing the HTTP request - and check if secure renegotiaion is supperted looking server output. Using manual request it is also possible to see if Compression is enabled for TLS in order to check for CRIME [13], check for ciphers and 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 we 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 we 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 to check cipher suite and also 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 sould be disabled. It is really interesting a first fix for BEAST was the usage of RC4, but this is 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 also mass scan and XML output. Follows an example of a regular scan. Is one of the most complete and versatile tool 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>

===Testing SSL certificate validity – client and server===
Firstly upgrade your browser because also CA certs expire and, in every release of the browser, these are been 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 namewise with the site to which they should refer. By clicking on the padlock which appears in the browser window when visiting an HTTPS site, you can look at information related to the certificate – including the issuer, period of validity, encryption characteristics, etc. If the application requires a client certificate, you probably have 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.

Some tools, as in previous examples, check also for certificate validity.

====Example 7. Testing for certificate validity (manually)====
Rather than providing a fictitious example, we have inserted 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 an .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 preloaded 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. A part from others discussed in other parts of the Guide, the another one is possible when the server provide the website both with the HTTP and HTTPS protocols, and permit to an attacker to force a victim into using a non-secure channel instead of a secure one.

====Surf Jacking====
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:

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 cookie in the HTTP header in clear text
* The attacker sees this traffic and logs the cookie for later (ab)use.
To test if a website is vulnerable is sufficient to proceed like follow:
# Check if website supports both HTTP and HTTPS protocol
# Check if cookies do not have the “Secure” flag

====SSL Strip====
Often applications supports both HTTP and HTTPS. As for usability or because users do not use to type “https://www.example.com”. Often users go into an HTTPS website from link or a redirect. Typically also home banking site have a similar configuration with an iframed login 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 incercept traffic when user is into HTTP and manipulate it to get a Man-In-The-Middle attack under HTTPS.
To test if application is vulnerable is sufficient the website supports both HTTP and HTTPS.

===Testing via HTTP proxy===

Inside corporate environment you can see services that are not directly accessible and you can access them only via HTTP proxy using CONNECT method [36]. Most of the tools will not work in this scenario because they try to connect to desired tcp port in order to start SSL/TLS handshake. With the help of relaying software such as socat [37] you can re-enable those tools for use with services behind 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 you 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.

== Gray Box testing and example ==

===Testing for Weak SSL/TSL Cipher Suites===
Check the configuration of the web servers which 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>
which has some sub-keys like Ciphers, Protocols and KeyExchangeAlgorithms.

====Example 10: Apache====
To check the cipher suites and protocols supported by 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). You should check the application architecture to identify all SSL protected channels.

==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 |https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)][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?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-007)&action=edit&redlink=1]
* [3] [OWASP Testing Guide - Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-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]

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

[[Category:Cryptographic Vulnerability]]
[[Category:SSL]]