Broken Link Hijacking (BLH) exists whenever a target links to an expired domain or page. Broken Link Hijacking comes in two forms, reflected and stored. This issue has been exploited in the wild numerous times, but surprisingly few researchers actively look for broken links in bug bounty programs.

image

This post aims to give you a basic overview of the different issues that could possibly arise if a target links to an expired endpoint.

Notice from author (Feb, 2022)

This is the original blog post which described Broken Link Hijacking for the first time. Since initial publication, many bug bounty hunters have referenced this blog post when reporting broken social media links to bug bounty programmes. The author of this blog post advises against this behaviour and would encourage readers to focus on the more impactful attack vectors described in this blog post.

External JS File Hijacking

If a target has an external JS file and that domain/page is expired, you can claim it and then you essentially have stored XSS.

Say for instance example.edu has an external JS file hosted on example.com and example.com has expired.

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width" />
    <title>Broken Link Hijacking</title>
  </head>
  <body>
    <script src="//example.com/script.js"></script>
  </body>
</html>

Now you can takeover example.com and can control the JS file on example.edu.

Information Leakage

Hijacking broken links which are missing the rel="noopener noreferrer" attribute could leak information to the attacker-controlled page. [1]

Also sometimes companies still link to expired analytics pages. If the attacker can hijack that expired page, they can monitor traffic and possibly gather valuable information about the target’s users. Someone actually once found one of these on Gratipay’s program: https://hackerone.com/reports/111078.

Content Hijacking

An attacker can hijack the content of a page by taking over the expired domain/page. A good example of this can be seen in @MisterCh0c’s blog post “How I hijacked top celebrities tweets including Katy Perry, Shakira…”.

image

You know that feeling when you think you have reflected XSS, but cannot break out of the href or src attributes?

If the link is a CDN or a file hosting service, you can construct a malicious link and host that file on the service. Admittedly, these are very rare, but definitely something to keep in mind in case you come across this issue in the future.

Example Scenario

http://example.edu/?version=1.0.0 returns a specific version of the JS file being hosted on cdn.example.

<!-- http://example.edu/?version=1.0.0 -->
<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width" />
    <title>Broken Link Hijacking</title>
  </head>
  <body>
    <script src="//cdn.example/1.0.0/script.js"></script>
  </body>
</html>

cdn.example allows us to add our project and host a malicious JS file.

<!-- http://example.edu/?link=maliciouspath -->
<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width" />
    <title>Broken Link Hijacking</title>
  </head>
  <body>
    <script src="//cdn.example/maliciouspath/script.js"></script>
  </body>
</html>

References

[1] GitHub. (2017). cure53/HTTPLeaks. [online] Available at: https://github.com/cure53/HTTPLeaks [Accessed 3 Sep. 2017].