Most websites that offer services (e-commerce, email, search engines, etc.) are eager to track their users, usually via cookies. While such a website is under development, developers typically work with HTTP-based setups and enable cookies for both HTTP and HTTPS. When this website is deployed with a proper SSL certificate, developers may miss re-configuring user-tracking cookies only for HTTPS connections.
If a user enters the website name without the https:// prefix, the browser makes an HTTP request and also sends all stored cookies for this website. Since HTTP is a clear text protocol, the associated cookies (which may contain user credentials, session identifiers, etc.) can be stolen easily by an attacker snooping on the user’s traffic.
To understand this cookie security mechanism, access the following URL:
The PHP code for this page sets three cookies as shown in Table 4.
Setting the sixth parameter to true creates a secure cookie that can only be used via HTTPS. When this sixth parameter is absent or is set to false, the cookie can be used for both HTTP and HTTPS access. Setting the seventh parameter to true means that this cookie is applicable only for HTTP-based access, and not for other accesses (e.g., Ajax calls).
The code in Table 4 sets the first cookie for both HTTP and HTTPS, and sets the second and third cookies for HTTPS access only. These latter cookies will not be sent if the webpage is accessed via HTTP. When this webpage is first accessed using HTTPS, all three cookies will be set. When the page is again accessed via HTTPS, the browser will send all three cookies. However, if the same URL is accessed via HTTP, the browser will send only the first cookie. This simple webpage displays the cookie values received with HTTPS (Figure 6) and HTTP (Figure 7).
Thus, web developers must ensure that cookies that hold sensitive user information must be properly secured. Further, to avoid cross-site scripting attacks, the cookie attribute
HttpOnly should also be used (as shown for the third cookie in the above example). To gain a hands-on understanding of this concept, the reader is encouraged to try out Exercise 3.
HTTP Strict Transport Security
Web servers can force browsers to use HTTPS (even if the user does not enter the https:// prefix explicitly) by making use of the HTTP header
Strict-Transport-Security, also known as HSTS. The web server needs to be configured to communicate this header in its response when accessed using HTTPS. Once the browser receives this header in the response, it stores this information in its cache for the duration specified in the header. The browser will subsequently always use an HTTPS connection for this website, even if the user does not enter the https:// prefix explicitly.
HSTS is especially useful in public spaces such as cafes, airports, railway stations, etc. In such places, a user is likely to access the internet using a shared network, such as a Wi-Fi (either open access or using  ). Even though the Wi-Fi link layer communication (using WPA/WPA2) may be encrypted, the higher-level traffic at IP and TCP is susceptible to MITM attacks. As described earlier in this article, such an attack could succeed if the user tries to access a website via HTTP.
With HSTS enabled, and assuming the user has previously accessed this website via a trusted network, the browser will initiate the communication on the public network using HTTPS only, thwarting the MITM attack.
Several popular websites including Facebook, Amazon and Twitter enable the HSTS feature in their responses. However, prominent e-commerce websites (e.g., www.flipkart.com), financial institutions (e.g., SBI, ICICI, HDFC bank), mutual funds registrars (e.g., www.camsonline.com), and academic institutes (e.g., www.vtu.ac.in and www.iisc.ac.in) do not implement HSTS. Airtel (www.airtel.in) does set the HSTS header, but with max-age=0, making it ineffective.
Users who often access such websites over public networks can configure their preferred browsers to always communicate using HTTPS only. For instance, the plugin ‘HTTPS Everywhere’  allows users to create rulesets for specific websites, as shown in Table 5.
Enabling HSTS in Apache2
To enable a website to send the HSTS header in the response, we need to make certain changes in the configuration files. For the Apache web server, we enable the header module (
sudo a2enmod headers), make the entry “Header always set Strict-Transport-Security "max-age=86400; includeSubDomains" in the file ssl-default.conf under the
VirtualHost section, and restart web server. This will set the life of HSTS to be 1 day (86400 seconds) and applicable to all subdomains of the website domain. Typically, the lifetime of HSTS should be a much higher value and should be set as per requirements. The value for 1 year would be 31536000 (= 86400 * 365) seconds. However, it should be noted that as per RFC 6797 (sec 12.1)  , browsers will ignore this setting for self-signed certificates, since such certificates cannot be fully trusted. To verify that the web server is sending the HSTS header, use wget –d –no-check-certificate https://mywww.com (where mywww.com is the experimental web server where you have enabled HSTS in the Apache configuration file). The output should contain the HSTS header. Similarly, using developer tools in a browser, you can find the HSTS header under the HTTP protocol response headers. To gain practical experience of working with the HSTS header, the reader is encouraged to try Exercise 4.
Browsers can further use HTTP Priming  to determine whether a website supports HSTS. For any website to be accessed using HTTPS, it first makes a HEAD request to verify whether the website supports HSTS. If so, the browser then uses HTTPS to access the website instead of HTTP.
The web community has explored and implemented many other options to enable secure communications. This has resulted in defining new Secure HTTP headers  that provide specific support for specific issues. Some of these header options are discussed below.
HTTP Public Key Pining (HPKP)
A modern browser trusts several certificate authorities. Suppose that an attacker compromises any one of these certificates. The attacker can generate a valid certificate for some target domain (e.g.,
google.com), modify the DNS entries for a network and direct traffic intended for this target domain to the server set up by the attacker to spoof the target domain. A user’s browser will trust this server since the website domain is signed with a trusted CA. The user can thus be tricked into revealing sensitive information to the attacker. HPKP is a mechanism that is designed to prevent such a scenario. This mechanism tells the browser which CA certificates are trustworthy. This mechanism is Trust On First Use (TOFU). The first time a browser accesses a web server, the web server informs the browser with a special header (
Public-Key-Pins:) about the public keys that belongs to the CA, and the browser caches this information. The header attribute
pin-sha256 provides the
Base64 encoded values of a public key. The header has other optional attributes such
max-age, includeSubDomains, report-uri etc. If in future, such a webserver provides a different public key for the CA, the browser recognizes the error and warns the user, thus helping to prevent an attack.
Content Security Policy (CSP):
Websites today are prone to attacks, and the most common form is some variation of an injection attack. This especially occurs on websites which interact with users and expect them to provide inputs via forms, comments on blogs, social media, etc. The attacker makes use of this input interaction facility to inject malicious contents which results in the hacking the website, stealing user information, etc. Content Security Policy (CSP)  is a security mechanism that enables the website to prevent such injection attacks, e.g. cross site scripting (XSS) attack. The CSP mechanism is implemented via HTTP response headers. This mechanism acts as a security layer in the browser by helping it determine whether some dynamic content is dangerous and should be blocked from execution. CSP specifies which origins (web domains) are allowed to access what type of resources. A detailed list of CSP attributes are described in  .
Below we discussed few of these. To allow default resources such as scripts, style sheets, images from the same domain belonging to the web page, the attribute can be set as
default-src ‘self’; This attribute tells the browser that all contents from this parent website is safe and can be rendered. The CSP attribute value
script-src self https://code.jquery.com; enables loading scripts from the external website code.jquery.com as well as from the current domain. Using the
default-src ‘self’; is assumed to be safe in general since the content is coming from same domain.
For a website, the value of CSP attributes are determined by the devops (development and operations) team which should define the policy for content security. This team must modify the web server configuration to send the requisite CSP header in web page responses. A typical example of enabling CSP in Apache defaults to none, but allowing images, style sheets and scripts from the existing domain would require following entry in the configuration file:
Header set Content-Security-Policy “default-src ‘none’; script-src ‘self’; img-src ‘self’; style-src ‘self’”
At times, when the web server is hosted by a third party (e.g., in shared hosting), the devops team may only have access to the website content but not to the configuration files. For such websites, CSP can be supported by using HTML tag in the… portion of the web page. The above example CSP security would be defined in the web page as:
CSP can also be used to partially achieve HSTS functional support by adding the attribute
Upgrade-Insecure-Requests to CSP policies. This is not a substitute for HSTS, however, since this does not ensure that future accesses to the website will always be converted to HTTPS. However, incorporating this attribute instructs the browser to access all links of this website with HTTPS. This is a quick way to move to HTTPS without making changes in existing web pages of the website, which can become a humongous task. Experiential exercises with CSP are described in Exercise 5.
There are many more headers to support secure web communication, including
X-XSS-Protection (to avoid cross site scripting attack),
X-Frame-Options (to avoid clickjacking attack),
X-Content-Type-Options (to avoid guessing the content type)  etc. We hope we have interested the reader to explore these options  as well.