4.0
1NSchAb
1NSchAb
- No tags were found...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
158<br />
Web Application Penetration Testing<br />
it may contain information on internal workings of the application<br />
such as relative paths of the point where the application is<br />
installed or how objects are referenced internally.<br />
How to Test<br />
Black Box testing<br />
There are a variety of techniques that will cause exception messages<br />
to be sent in an HTTP response. Note that in most cases<br />
this will be an HTML page, but exceptions can be sent as part of<br />
SOAP or REST responses too.<br />
Some tests to try include:<br />
• invalid input (such as input that is not consistent with application<br />
logic.<br />
• input that contains non alphanumeric characters or query syn<br />
tax.<br />
• empty inputs.<br />
• inputs that are too long.<br />
• access to internal pages without authentication.<br />
• bypassing application flow.<br />
All the above tests could lead to application errors that may contain<br />
stack traces. It is recommended to use a fuzzer in addition to<br />
any manual testing.<br />
Some tools, such as OWASP ZAP and Burp proxy will automatically<br />
detect these exceptions in the response stream as you are<br />
doing other penetration and testing work.<br />
Gray Box Testing<br />
Search the code for the calls that cause an exception to be rendered<br />
to a String or output stream. For example, in Java this<br />
might be code in a JSP that looks like:<br />
<br />
In some cases, the stack trace will be specifically formatted into<br />
HTML, so be careful of accesses to stack trace elements.<br />
Search the configuration to verify error handling configuration<br />
and the use of default error pages. For example, in Java this configuration<br />
can be found in web.xml.<br />
Tools<br />
• ZAP Proxy - https://www.owasp.org/index.php/OWASP_Zed_<br />
Attack_Proxy_Project<br />
References<br />
• [RFC2616] Hypertext Transfer Protocol - HTTP/1.1<br />
Testing for Weak SSL/TLS Ciphers, Insufficient<br />
Transport Layer Protection (OTG-CRYPST-001)<br />
Summary<br />
Sensitive data must be protected when it is transmitted through<br />
the network. Such data can include user credentials and credit<br />
cards. As a rule of thumb, if data must be protected when it is<br />
stored, it must be protected also during transmission.<br />
HTTP is a clear-text protocol and it is normally secured via an<br />
SSL/TLS tunnel, resulting in HTTPS traffic [1]. The use of this<br />
protocol ensures not only confidentiality, but also authentication.<br />
Servers are authenticated using digital certificates and it is<br />
also possible to use client certificate for mutual authentication.<br />
Even if high grade ciphers are today supported and normally<br />
used, some misconfiguration in the server can be used to force<br />
the use of a weak cipher - or at worst no encryption - permitting<br />
to an attacker to gain access to the supposed secure communication<br />
channel. Other misconfiguration can be used for a Denial<br />
of Service attack.<br />
Common Issues<br />
A vulnerability occurs if the HTTP protocol is used to transmit<br />
sensitive information [2] (e.g. credentials transmitted over HTTP<br />
[3]).<br />
When the SSL/TLS service is present it is good but it increments<br />
the attack surface and the following vulnerabilities exist:<br />
• SSL/TLS protocols, ciphers, keys and renegotiation must be<br />
properly configured.<br />
• Certificate validity must be ensured.<br />
Other vulnerabilities linked to this are:<br />
• Software exposed must be updated due to possibility of known<br />
vulnerabilities [4].<br />
• Usage of Secure flag for Session Cookies [5].<br />
• Usage of HTTP Strict Transport Security (HSTS) [6].<br />
• The presence of HTTP and HTTPS both, which can be used to<br />
intercept traffic [7], [8].<br />
• The presence of mixed HTTPS and HTTP content in the same<br />
page, which can be used to Leak information.<br />
Sensitive data transmitted in clear-text<br />
The application should not transmit sensitive information via<br />
unencrypted channels. Typically it is possible to find basic authentication<br />
over HTTP, input password or session cookie sent<br />
via HTTP and, in general, other information considered by regulations,<br />
laws or organization policy.<br />
Weak SSL/TLS Ciphers/Protocols/Keys<br />
Historically, there have been limitations set in place by the U.S.<br />
government to allow cryptosystems to be exported only for key<br />
sizes of at most 40 bits, a key length which could be broken and<br />
would allow the decryption of communications. Since then cryptographic<br />
export regulations have been relaxed the maximum<br />
key size is 128 bits.<br />
It is important to check the SSL configuration being used to avoid<br />
putting in place cryptographic support which could be easily defeated.<br />
To reach this goal SSL-based services should not offer<br />
the possibility to choose weak cipher suite. A cipher suite is specified<br />
by an encryption protocol (e.g. DES, RC4, AES), the encryption<br />
key length (e.g. 40, 56, or 128 bits), and a hash algorithm (e.g.<br />
SHA, MD5) used for integrity checking.<br />
Briefly, the key points for the cipher suite determination are the<br />
following:<br />
[1] The client sends to the server a ClientHello message