1BO4r2U

157 158
Web Application Penetration Testing
Web Application Penetration Testing
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:
[1] 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].
[2] 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.
[1] The server sends its Certificate message and, if client authentication
is required, also sends a CertificateRequest message to the
client.
[2] The server sends a ServerHelloDone message and waits for a
client response.
[3] 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:
[1] The server sends its Certificate message and, if client authentication
is required, also sends a CertificateRequest message to the
client.
[2] The server sends a ServerHelloDone message and waits for a
client response.
[3] Upon receipt of the ServerHelloDone message, the client verifies
the validity of the server’s digital certificate.
In order for the communication to be set up, a number of checks on
the certificates must be passed. While discussing SSL and certificate
based authentication is beyond the scope of this guide, this section
will focus on the main criteria involved in ascertaining certificate validity:
• Checking if the Certificate Authority (CA) is a known one (meaning
one considered trusted);
• Checking that the certificate is currently valid;
• Checking that the name of the site and the name reported in the
certificate match.
Let’s examine each check more in detail.
• Each browser comes with a pre-loaded list of trusted CAs,
against which the certificate signing CA is compared (this list can be
customized and expanded at will). During the initial negotiations with
an HTTPS server, if the server certificate relates to a CA unknown
to the browser, a warning is usually raised. This happens most
often because a web application relies on a certificate signed by a
self-established CA. Whether this is to be considered a concern
depends on several factors. For example, this may be fine for an
Intranet environment (think of corporate web email being provided
via HTTPS; here, obviously all users recognize the internal CA as a
trusted CA). When a service is provided to the general public via the
Internet, however (i.e. when it is important to positively verify the
identity of the server we are talking to), it is usually imperative to rely
on a trusted CA, one which is recognized by all the user base (and
here we stop with our considerations; we won’t delve deeper in the
implications of the trust model being used by digital certificates).
• Certificates have an associated period of validity, therefore they
may expire. Again, we are warned by the browser about this.
A public service needs a temporally valid certificate; otherwise, it
means we are talking with a server whose certificate was issued by
someone we trust, but has expired without being renewed.
• What if the name on the certificate and the name of the server do
not match? If this happens, it might sound suspicious. For a number
of reasons, this is not so rare to see. A system may host a number
of name-based virtual hosts, which share the same IP address and
are identified by means of the HTTP 1.1 Host: header information.
In this case, since the SSL handshake checks the server certificate
before the HTTP request is processed, it is not possible to assign
different certificates to each virtual server. Therefore, if the name of
the site and the name reported in the certificate do not match, we
have a condition which is typically signaled by the browser. To avoid
this, IP-based virtual servers must be used. [33] and [34] describe
techniques to deal with this problem and allow name-based virtual
hosts to be correctly referenced.
Other vulnerabilities
The presence of a new service, listening in a separate tcp port may
introduce vulnerabilities such as infrastructure vulnerabilities if the
software is not up to date [4]. Furthermore, for the correct protection
of data during transmission the Session Cookie must use the
Secure flag [5] and some directives should be sent to the browser to
accept only secure traffic (e.g. HSTS [6], CSP).
Also there are some attacks that can be used to intercept traffic if
the web server exposes the application on both HTTP and HTTPS
[6], [7] or in case of mixed HTTP and HTTPS resources in the same
page.
How to Test
Testing for sensitive data transmitted in clear-text
Various types of information which must be protected can be also
transmitted in clear text. It is possible to check if this information is
transmitted over HTTP instead of HTTPS. Please refer to specific
tests for full details, for credentials [3] and other kind of data [2].
Example 1. Basic Authentication over HTTP
A typical example is the usage of Basic Authentication over HTTP
because with Basic Authentication, after log in, credentials are encoded
- and not encrypted - into HTTP Headers.
$ 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
401 Authorization Required
401 Authorization Required
Invalid login credentials!
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 as-