Table of Contents for
Security and Frontend Performance

Version ebook / Retour

Cover image for bash Cookbook, 2nd Edition Security and Frontend Performance by Sabrina Burney Published by O'Reilly Media, Inc., 2017
  1. nav
  2. Cover
  3. Free ebooks and reports
  4. Security and Frontend Performance
  5. Security and Frontend Performance
  6. 1. Understanding the Problem
  7. 2. HTTP Strict-Transport-Security
  8. 3. iFrame and Content‑Security‑Policy
  9. 4. Web Linking
  10. 5. Obfuscation
  11. 6. Service Workers: An Introduction
  12. 7. Service Workers: Analytics Monitoring
  13. 8. Service Workers: Control Third Party Content
  14. 9. Service Workers: Other Applications
  15. 10. Summary
  16. About the Authors

Chapter 5. Obfuscation

Obfuscation is a common frontend optimization technique that provides both security and performance benefits at the browser when applied to inline or external code. From a security point of view, developers are able to conceal implementation logic in order to avoid allowing attackers to reverse engineer code. From a performance point of view, obfuscation can reduce the size of code (page weight), implying that the browser will load and execute this content faster. Code obfuscation is a basic example of how we, as developers, can implement solutions that provide benefits in both security and performance areas. While the technique of obfuscating code has been around for quite some time, other areas of sites such as resource URLs can utilize this to further enhance frontend security and performance.

Learn from Our Attackers

To explore other applications, let’s discuss how attackers deliver malicious payloads today. Origin infrastructures will often have a web application firewall implemented to block certain types of application layer attacks such as directory traversal attempts for sensitive files (Example 5-1). Attackers will then obfuscate their payloads in order to avoid detection from preset firewall rules, and in doing so, they are able to deliver malicious payloads to origin servers as intended (Example 5-2).

Example 5-1. Original URL
http://www.example.com/test?file=/../etc/passwd
Example 5-2. Obfuscated payload
Decimal Encoded: http://www.example.com/test?file=/et
c/passwd

URL Encoded: http://www.example.com/test?file=%2F..%2Fetc%2Fpasswd

In Example 5-2, obfuscation is applied in the form of different types of encodings including decimal and URL encoded payloads. Let’s use the same concept of obfuscating payloads and apply this to other areas of sites—more specifically, let’s apply obfuscation to embedded third party URLs.

Alternative Application: URL Obfuscation

Why obfuscate third party URLs? Attackers will often target vendor content in order to bring down a site either through compromising content or degrading site performance. Many times, companies do not enforce security or performance measures for third party partners largely due to the focus being on first party content and protecting origin infrastructures. Developers need a way to mask the sources of these third party resources in an attempt to deter attackers from targeting vendor content in the first place.

Concept

Stepping away from the traditional application of obfuscation, we will now proxy and obfuscate third party URLs. Under normal circumstances, the browser parses a page and fetches third party resources from a third party provider as shown in Example 5-3. If we rewrite third party URLs to use a first party URL and obfuscated path/filename as shown in Example 5-4, the flow will change with the introduction of a reverse proxy. The reverse proxy has been introduced in Figure 5-1 to provide a way to interpret obfuscated requests, which can be done through use of Varnish, Apache mod_rewrite functionality, any other reverse proxies that would allow request rewrites, or simply a content delivery network. The browser will now parse a page and fetch obfuscated content, and the reverse proxy will then interpret the obfuscated request and fetch third party content on behalf of the end user’s browser. In doing so, we will achieve both enhanced security and performance at the browser.

Example 5-3. Original path
<img src="http://image.3rdparty.com/images/header_banner.jpg"/>
Example 5-4. New path
<img src="http://firstparty.example.com/fY4dCrWhjwjIu8Wkdhfjhg"/>
Obf-Flow
Figure 5-1. Third party workflow

URL Obfuscation Benefits

The URL obfuscation technique improves overall delivery performance and provides an additional layer of security for the end user, including benefits in areas such as privacy and resource download time.

Privacy

Because we are now proxying third party requests, we are able to enforce an additional layer of privacy by masking end users from third party providers who may not be as trusted as some of the more popular vendors. Additionally, we’re concealing the source of third party content, which will deter attackers from targeting the providers and negatively impacting sites from both a security and performance point of view.

Single Point of Failure

As mentioned, third party content exposes us to the risks of single point of failure, which can happen through compromised content or simply delayed content. Using the method of proxying and obfuscating third party content provides more developer control to handle these situations, by allowing strict monitoring and disaster-recovery implementations in order to adapt to these situations when they occur. More specifically, developers can implement measures to monitor how long it takes to fetch a resource and, if the resource takes too long, serve alternate content to avoid single point of failure. Additionally, company security measures can be applied to proxied content in the same way first party content is secured so we are able to enhance security as well.

Improved Delivery Time

Let’s dive into how URL obfuscation can provide various frontend performance benefits when it comes to actual resource downloads, especially with content classified as third party.

Caching

Introducing a reverse proxy into the flow provides an additional layer of caching for third party content, which ultimately brings resources closer to end users.

DNS Lookup and Connection

With the widely used HTTP/1.1, browsers open a single connection per unique hostname. Under the conditions of a page loading several resources from different third party domains, we observe in Figure 5-2 how much time is spent in DNS Lookup and Connection in the browser due to HTTP/1.1 properties. DNS Lookup is the time spent to perform a domain lookup while Connection is the time spent when the browser initiates a connection to the resolved domain address. Both of these metrics contribute to how long a browser will take to load a resource.

WPT-Colors
Obf-DNS-1
Figure 5-2. HTTP/1.1 browser conditions

If we apply URL obfuscation to all third party resources in a page, we observe in Figure 5-3 a reduction in overall DNS Lookup and Connection in the browser. Proxying these resources under the same first party hostname allows us to eliminate the browser opening many different connections.

Obf-DNS-2
Figure 5-3. HTTP/1.1 browser conditions with URL obfuscation

With the recently introduced HTTP/2, browsers open a single connection per unique origin server. Additionally, we are introduced to the idea of multiplexing in that a browser can open a single connection to fetch multiple resources at the same time. Keeping the features of HTTP/2 in mind, we can couple HTTP/2 with URL obfuscation to provide even more of a reduction in overall DNS Lookup and Connection in the browser as shown in Figure 5-4. This is mainly due to the multiplexing feature in that a single connection is now the most optimal approach with HTTP/2.

Obf-DNS-3
Figure 5-4. HTTP/2 browser conditions with URL obfuscation

Content-Security-Policy

Recall that Content-Security-Policy is a security technique aimed at whitelisting known third party domains, while prohibiting unknown third party domains from accessing and executing content on a site. When used as a header, it can grow large and often becomes harder to maintain as shown in Examples 5-5 and 5-6. Not only are we at risk of a large header delaying resource download time, but we are essentially exposing the sources of third party content as shown in the following examples. As mentioned earlier, attackers will target vendor content in order to bring a site down. That being said, we need to ensure information about vendor content is concealed as much as possible.

Example 5-5. Content-Security-Policy
Content-Security-Policy:
      default-src * data: blob:;script-src *.facebook.com
      *.fbcdn.net *.facebook.net *.google-analytics.com
      *.virtualearth.net *.google.com 127.0.0.1:*
      *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval'
      fbstatic-a.akamaihd.net fbcdn-static-b-a.akamaihd.net
      *.atlassolutions.com blob:; style-src * 'unsafe-inline'
      data:;connect-src *.facebook.com *.fbcdn.net
      *.facebook.net *.spotilocal.com:* *.akamaihd.net
      wss://*.facebook.com:* https://fb.scanandcleanlocal.com:*
      *.atlassolutions.com attachment.fbsbx.com
      ws://localhost:* blob:
Example 5-6. Content-Security-Policy
Content-Security-Policy:
      script-src 'self' *.google.com *.google-analytics.com
      'unsafe-inline' 'unsafe-eval' *.gstatic.com
      *.googlesyndication.com *.blogger.com
      *.googleapis.com uds.googleusercontent.com
      www-onepick-opensocial.googleusercontent.com
      www-bloggervideo-opensocial.googleusercontent.com
      www-blogger-opensocial.googleusercontent.com
      *.blogspot.com; report-uri /cspreport

Coupling the technique of URL obfuscation with Content-Security-Policy, we can overcome the associated risks of large header size and content exposure as shown in Example 5-7. From a security point of view, proxying third party content masks the original source and deters attackers from targeting vendor content. From a frontend performance point of view, grouping third party content under a smaller set of first party hostnames can decrease the size of the Content-Security-Policy header, which is delivered on a per-resource download basis.

Example 5-7. Original and replacement
Content-Security-Policy:
      script-src 'self' *.google.com *.google-analytics.com
      'unsafe-inline’ *.gstatic.com *.googlesyndication.com
      *.blogger.com *.googleapis.com uds.googleusercontent.com
      www-onepick-opensocial.googleusercontent.com
      www-bloggervideo-opensocial.googleusercontent.com
      www-blogger-opensocial.googleusercontent.com *.blogspot.com;
      report-uri /cspreport

Content-Security-Policy:
      script-src 'self' *.obf1.firstparty.com 'unsafe-inline'
      *.obf2.firstparty.com ; report-uri /cspreport

Thinking ahead with HTTP/2, we are also introduced to header compression, which avoids sending similar headers back and forth across the same connection. Instead, headers are maintained on a session basis to avoid the resending of duplicate headers. With this feature, we are also given a restriction in that header compression is provided up to 4K. For any headers that exceed this limit, the original header will continue being resent over the same connection, which can have an effect on the overall download time of resources. While using the Content-Security-Policy header, we are at risk of exceeding the header compression limit due to how large this header can become. With the coupling of HTTP/2 and URL obfuscation, we are essentially reducing the size of the Content-Security-Policy header by proxying and grouping third party resources. In doing so, developers can take advantage of HTTP/2 header compression due to the reduction in Content-Security-Policy header size.

Last Thoughts

Overall, we can see how proxying and obfuscating third party content provides benefits in a number of different areas. These areas include enabling faster browsing experiences, adapting to single point of failure situations, and utilizing the Content-Security-Policy technique without exposing sources of vendor content. With this technique, we address common concerns when dealing with third party content while improving both frontend delivery as well as browser-level security.