In Web security, the server has always played a very important role. However, the browser problem is not trivial, it can also lead to information leakage and so on. Yet many people don’t realize how important browsers are for security. In this lecture (article), we will give readers ideas on how to exploit browser bugs.

The idea of digging holes

Identify the target

Let’s take a look at the structure of the browser:

  • DOM parsing (HTML, XML, SVG, MathML, XUL)
  • Script processing (JavaScript, VBScript, ASM.js, WebAssembly)
  • Protocol support (HTTP, FTP, WebSocket, HTTP/2, QUIC, DNS, mDNS, WebRTC)
  • Media streaming support (JPG, GIF, PNG, WebM, Ogg, AAC, MP3, MP4, FLAC)
  • Middleware included (Skia, FFMPEG, ICU, NSS, OpenVR, libpng, SQLite)
  • Various apis (Fetch API, Push API, Extension API, Fullscreen API, Web Speech API)
  • UI setup (Location Bar, History, Bookmark, Context Menu)
  • Security features (SOP, XSS Filter, CSP, SRI, TLS, Mixed Content, HSTS, HPKP, CT)
  • Handy features (Chrome Extension, Reading View, Secret Mode)
  • other

How should we target from the many features? At this point, we can start with:

Check new features

Features that have just been announced tend to be under-studied and therefore more likely to have potential pitfalls. Therefore, we can try to find bugs in the following products:

  • Firefox Nightly
  • Chrome Dev, Canary
  • Safari Technology Preview
  • The latest version of Edge

When updating, it’s a good idea to pay attention to their release diaries or developer blogs. This way, we can learn about new features in the shortest possible time.

Firefox provides link preloading in this release, which looks interesting! At this point, white hats can use this feature as a basis for security testing, or to consider whether they can use it to expand the supply.

Here are the relevant platforms that allow us to get first-hand information:




Check out old features that aren’t popular

These features are often underappreciated:

  • Nonstandardized function
  • Unpopular function
  • Regular plug-ins

Again, we can explore these features by publishing records or from existing research reports.

For example:

When I use dialogArguments/returnValue data can be transmitted to any window, here is there a SOP to bypass the holes?

When using Dailog, users can’t work with other Windows. Is this likely to cause UI-related problems?

Enumeration – Extends existing vulnerabilities

We can explore the problems with common mechanics:

  • JavaScript HTTP communication mechanism (sendBeacon, Fetch, Worker)
  • Browser pop-up mechanisms (Alert, Confirm, getUserMedia)
  • MIME types (text/javascript, image/SVG + XML, application/octet-stream…)

Features that studies have identified as high-risk also work well:

  • Windows object
  • HTTP leaked
  • HTML5 Security Cheatsheet

Through enumeration, we can better focus on valid goals. For example:

Here, we can see that IE can run CSS scripts, does this mean we can use it for XSS or filter bypass?

Dig holes in the COMMIT history

Git history can be used to discover interesting features, such as:

  • Mobile support (3D Touch, Spotlight, Universal Links)
  • Features in progress (Web App Manifest, Geckoview)

So, how do we find things to watch for:

  • Features that have been identified as high-risk by developers
  • Implementing complex third-party libraries (SQLite, Alamofire)

Let’s take another example. Here’s a Chrome commit record: goo.gl/xo6MMV

Chrome didn’t do a good job of internationalizing characters before the commit, and the a in the following image is actually U+0430 of the Cyrillic character set (not a0 in English) :

And U+0589, / is U+2215

I reported the problem, but Google’s solution was to simply disable internationalized domain names.

The COMMIT record adds two potential points of attack:

  • Does storing data in SQLite mean there is SQL injection?
  • XSS is caused when variables are inserted into the page?

When a browser feature has the following characteristics, it usually means that the feature has a problem:

  • You give the URL to the API, and it returns a specific flag
  • The CSP is abnormal
  • You can send any header to a target

If you know the specific target to attack, then you can check:

  • Location The value returned
  • Behavior of a function
  • Is the CSP implementation correct?

Look for character set vulnerabilities

There are many problems that can be mined from the browser’s mishandling of character sets.

Character set support by browser:

For example, cVE-2013-5612, when you do not specify a character set in a POST request, it defaults to the previous character set specified. We can take advantage of the differences in support to bypass XSS Auditor

Look for third-party library vulnerabilities

In the Pwn2Own competition, researchers from Changting Technology successfully exploited SQLite’s memory corruption to break Safari. Similarly, we can look for vulnerabilities in the following lib:

Other attack surfaces

Browser resolution of special protocols, such as about, can also cause problems. When we type about:neterror? e=nssBadCert&d=Hello%20Guys! , there will be:

Never forget to learn from previous experience

When we find loopholes, don’t forget to learn from previous ideas, we should think about these questions: what type of vulnerabilities? How did they find the leak? How did this leak come about? You can learn the process through Security Advisors (Mozilla, Chrome) and private blogs.

In-depth research objectives

To explore a goal in depth, we need to understand the features:

  • What is this function for
  • How to use it
  • What are the inputs and outputs
  • Is there any filtering
  • Can we use it to bypass security mechanisms
  • Can we use it to attack secure sites

So what should we do to dig deeper?

  • Use it yourself
  • The audit code
  • Auditing executable files (disassembly)
  • Viewing software Log

Take the Fetch API for example:

fetch('http://api.example.jp/path', {  // What addresses can I plug in here?
  method:'POST'.                        // What other methods can I add?
  headers: {
    'Content-Type':'text/plain'           // Can I insert other headers or MIME types here?
  },
  body:'Hello World! '                   // What text can be inserted into the body?
  }).then(function(res) {
    console.log(res.headers.get('Content-Type')); What headers can I read?
  }).catch(function(err) {
  console.error(err);                   // The error that was thrown contained sensitive information.
});
Copy the code

An example of finding bugs by working backwards:

A DLL for Edge contains a regular expression for the XSS filter. We can find the bypass payload by deducting it backwards.

Explore interesting behaviors

We need to keep an eye out when we spot unusual behavior, because it often indicates a deeper vulnerability:

  • URL Spoof does not update after jump
  • An input causes the browser to crash or pause the response
  • The HTML tag is not running properly
  • The text garbled

For example, in CVE-2012-3695, when we type https://aaa% http://[email protected]/, %2F is decoded and returns https://aaa/@http://example.com/. The aaa%2F used for authentication was converted to a domain name, which could lead to phishing.

What are the techniques for exploiting these vulnerabilities? We can check the following functions:

  • URL scheme (http:, https:, ftp:, data:, resource:, about:, chrome-extension:)
  • Request method (GET, POST, HEAD, OPTIONS, TRACE)
  • Iframe, Object/Embed Tag, SVG foreignobject, Reading View
  • How do browsers get resources (img tags, video/audio tags, Worker importScripts)
  • Methods to open a new URL (Location header, meta refresh, window.open, browser return key)
  • Unconventional inputs (too long strings, HPP, null values, too large numbers, negative numbers)
  • Enumerate various other elements to quickly find potential pitfalls.

A few examples:

In CVE-2017-7789, if Firefox receives multiple HSTS headers in the response, HSTS will not be enabled. The attacker can bypass the HSTS mechanism as long as he/she includes several HSTS headers in the normal HTTP response.

In CVE-2015-4483, we can bypass the Content Mixed Blocker by adding the URL after ‘feed:’

The exploit

When you find a bug, how do you exploit it:

  • Imagine leveraging it in an existing Web application
    • Because of this vulnerability, we can attack otherwise secure web pages
    • This vulnerability can cause browser security mechanisms to fail
  • Even if you can’t use it in certain situations, consider the ideal circumstances in which you can use it
    • If this website is implemented like this, then how can we?
    • If this scenario is relatively sound, the vulnerability may work in certain environments

Let’s take a look at a quirk in the Behavior of the Firefox plugin. Although we can use this vulnerability to inject HTML into the title (TAB title) of the page, we can’t trigger XSS due to CSP.

When we look closely at the order of %TITLE%, %CONTENT%, we find a template injection vulnerability:

This way, whenever we insert a form element into %TITLE%, we can also externalize %CONTENT% to the attacker, even if we can’t XSS.

In practice, many sites insert user input into the page title. Take Google for example:

While it seems useless to access other people’s search results, could we get more sensitive data?

Gmail seems like a good target, we can send a malicious email to the target, and when he or she opens the email, the page title changes to the email title:

When a user clicks Click Me, the email information is sent to the attacker

So far, we have successfully turned this vulnerability into a treasure.

The author:Masato Kinugawa