4.0

159Web Application Penetration Testingspecifying, among other information, the protocol and thecipher suites that it is able to handle. Note that a client isusually a web browser (most popular SSL client nowadays), butnot necessarily, since it can be any SSL-enabled application;the same holds for the server, which needs not to be a webserver, though this is the most common case [9].[2] The server responds with a ServerHello message, containingthe chosen protocol and cipher suite that will be used for thatsession (in general the server selects the strongest protocoland 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 wayyou may control whether or not conversations with clients willsupport 40-bit encryption only.[1] The server sends its Certificate message and, if clientauthentication is required, also sends a CertificateRequestmessage to the client.[2] The server sends a ServerHelloDone message and waits fora client response.[3] Upon receipt of the ServerHelloDone message, the clientverifies the validity of the server’s digital certificate.SSL certificate validity – client and serverWhen accessing a web application via the HTTPS protocol, a securechannel 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 thecipher suite is determined, the “SSL Handshake” continues withthe exchange of the certificates:[1] The server sends its Certificate message and, if clientauthentication is required, also sends a CertificateRequestmessage to the client.[2] The server sends a ServerHelloDone message and waits fora client response.[3] Upon receipt of the ServerHelloDone message, the clientverifies the validity of the server’s digital certificate.In order for the communication to be set up, a number of checkson the certificates must be passed. While discussing SSL andcertificate based authentication is beyond the scope of thisguide, this section will focus on the main criteria involved in ascertainingcertificate 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 inthe 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 listcan be customized and expanded at will). During the initialnegotiations with an HTTPS server, if the server certificaterelates to a CA unknown to the browser, a warning is usuallyraised. This happens most often because a web applicationrelies on a certificate signed by a self-established CA. Whetherthis 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 identityof the server we are talking to), it is usually imperative to rely on atrusted CA, one which is recognized by all the user base (and herewe stop with our considerations; we won’t delve deeper in theimplications of the trust model being used by digital certificates).• Certificates have an associated period of validity, thereforethey may expire. Again, we are warned by the browser about this.A public service needs a temporally valid certificate; otherwise, itmeans we are talking with a server whose certificate was issuedby someone we trust, but has expired without being renewed.• What if the name on the certificate and the name of the serverdo not match? If this happens, it might sound suspicious. For anumber of reasons, this is not so rare to see. A system may hosta number of name-based virtual hosts, which share the sameIP address and are identified by means of the HTTP 1.1 Host:header information. In this case, since the SSL handshake checksthe server certificate before the HTTP request is processed, it isnot possible to assign different certificates to each virtual server.Therefore, if the name of the site and the name reported in thecertificate do not match, we have a condition which is typicallysignaled by the browser. To avoid this, IP-based virtual serversmust be used. [33] and [34] describe techniques to deal withthis problem and allow name-based virtual hosts to be correctlyreferenced.Other vulnerabilitiesThe presence of a new service, listening in a separate tcp port mayintroduce vulnerabilities such as infrastructure vulnerabilities ifthe software is not up to date [4]. Furthermore, for the correctprotection of data during transmission the Session Cookie mustuse the Secure flag [5] and some directives should be sent to thebrowser to accept only secure traffic (e.g. HSTS [6], CSP).Also there are some attacks that can be used to intercept traffic ifthe web server exposes the application on both HTTP and HTTPS[6], [7] or in case of mixed HTTP and HTTPS resources in the samepage.How to TestTesting for sensitive data transmitted in clear-textVarious types of information which must be protected can be alsotransmitted in clear text. It is possible to check if this informationis transmitted over HTTP instead of HTTPS. Please refer to specifictests for full details, for credentials [3] and other kind of data [2].Example 1. Basic Authentication over HTTPA typical example is the usage of Basic Authentication over HTTPbecause with Basic Authentication, after log in, credentials areencoded - and not encrypted - into HTTP Headers.