4.0

172
Web Application Penetration Testing
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:
[1] Check if website supports both HTTP and HTTPS protocols
[2] 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:
Then the tester can target all other tools to localhost:9999:
$ openssl s_client -connect localhost:9999
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:
$ socat TCP-LISTEN:9999,reuseaddr,fork
PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\
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.