Grafvision - Fotolia
Analyzing the flaws of Adobe's HTTP security headers
A recent patching issue with Flash drew attention to shortcomings with Adobe's HTTP security headers. Judith Myerson discusses the importance of HTTP header security.
This summer, Adobe Systems was forced to reissue a patch after being informed by Dutch security researcher Bjorn Ruytenberg that the original patch didn't completely resolve its intended flaw.
Ruytenberg, who also discovered the original Flash sandbox escape vulnerability, found that the flaw could still be exploited by attackers because of input validation weaknesses with HTTP requests, which enabled attackers to redirect requests to a malicious server. This persistent vulnerability drew attention to Adobe's HTTP headers.
HTTP headers
If you enter Adobe's domain into SecurityHeaders.io, a free service that scans and grades HTTP security headers, then you'll see the software company has a poor grade -- E on a grade scale of A to F. This means Adobe's site failed to use all the necessary HTTP security headers to make the site fully secure.
Adobe got a passing grade for implementing the X-Frame-Options header with a value of SAMEORIGIN, which enables Adobe to frame its own site. This helps to defend the site against clickjacking attacks.
When Adobe announced Flash Player would reach end of life in 2020, they apparently didn't check what other security headers were needed to send security policies to the server.
The grade report shows Adobe is missing four HTTP Response headers that must be added to the server. The rules for adding them to Adobe's Apache server are different from the rules for implementing an HTTP Response header on Microsoft Internet Information Services and for NGINX servers that non-Adobe sites use.
A server header is common on all sites, as it shares information about the particular server application that is running, which could make it vulnerable to software attacks. The value for the server header should be replaced with another value, such as Hello, World! This can be done by changing the server property.
Security headers are not shown in the browser's HTML source page. Therefore, when you put Adobe.com in the browser's address bar, the browser sends HTTP request headers containing details on how the browser should behave to a web server. In response, the server sends back HTTP response headers. The responding messages are not part of HTML, and all browsers run HTML on the client's side.
Unlike the Server header, the status of the HTTP Location header is currently not shown in Adobe's grade report. Ruytenberg discovered the vulnerability in the HTTP Location header, and it led to an information disclosure that included users' credentials when URL redirects were performed from Internet Explorer or Firefox to a malicious server message block (SMB) server.
Ruytenberg discovered that the same host served both Adobe's cross-domain policy requests and the attacker's Flash applications. By building a new cross-domain policy with lesser restrictions, the researcher forced Flash to connect to the SMB server, which left credentials in plain view.
Addressing HTTP header security
This discovery led Adobe to publish CVE-2017-3085 on the security bypass vulnerability in Adobe Flash Player 26.0.0.37 running on macOS, Microsoft Windows, Linux Kernel and Chrome OS. Yet, the CVE makes no reference to URLs and redirects to malicious SMB servers; however, the Aug. 15, 2017 update confirmed that Adobe 26.0.0.151 is not vulnerable.
The four HTTP Respond headers that Adobe should have added to Apache server include the following:
- A Content Security Policy can help to protect the site from cross-site scripting (XSS) attacks. Whitelisting sources of approved content, like JS and CSS, can prevent the browser from loading malicious assets. This header can be used to enforce Transport Layer Security (TLS) on all assets. A recommended value to use would be default-src https: data: 'unsafe-inline' 'unsafe eval'.
- X-XSS-Protection provides an option to tell the browser to block the response if it detects an attack. A recommended value would be 1:mode=block.
- X-Content-Type-Options stops a browser from trying to sniff the content type of a response that's different than the one being declared by the server. The only valid value for this header is nosniff. The only valid value for this header is nosniff.
- A Referrer Policy enables a site to control how much information the browser can include with navigations away from a document. A recommended value would be strict-origin-when-cross-origin to send only the origin as a referrer to cross-origin requests, and the full URL to those with same-origin.
According to the SecurityHeaders.io grader, two more HTTP security headers should be added to make the site more secure.
- HTTP Strict Transport Security provides support for enforcing TLS and, optionally, all subdomains for a certain period of time. A value example would be max-age=31536000; includeSubDomains preload. This forces users to use HTTPS for all subdomains for a year -- in seconds -- even they type HTTP in the address bar.
- Public-Key-Pins protect the site from man-in-the-middle attacks that use rogue X.509 certificates. By whitelisting only the identities that the browser should trust, the users are protected in the event a certificate authority is compromised.
Adding security for HTTP headers should help to make websites more secure, and headers should be treated as part of an enterprise's larger picture for website security.
Conclusion
Adobe's poor grade on the HTTP security headers indicates that they didn't consider these headers an additional defense layer to protect users against newsworthy attacks. Organizations should be aware of the existing HTTP security headers that they need to add to their server, while staying up to date on new security issues.
