The Browser Hacker’s Handbook

The Browser Hacker’s Handbook

English | 2014 | ISBN: 978-1118662090 | 648 Pages | PDF, EPUB | 37 MB

Hackers exploit browser vulnerabilities to attack deep within networks
The Browser Hacker’s Handbook gives a practical understanding of hacking the everyday web browser and using it as a beachhead to launch further attacks deep into corporate networks. Written by a team of highly experienced computer security experts, the handbook provides hands-on tutorials exploring a range of current attack methods.
The web browser has become the most popular and widely used computer “program” in the world. As the gateway to the Internet, it is part of the storefront to any business that operates online, but it is also one of the most vulnerable entry points of any system. With attacks on the rise, companies are increasingly employing browser-hardening techniques to protect the unique vulnerabilities inherent in all currently used browsers. The Browser Hacker’s Handbook thoroughly covers complex security issues and explores relevant topics such as: * Bypassing the Same Origin Policy * ARP spoofing, social engineering, and phishing to access browsers * DNS tunneling, attacking web applications, and proxying all from the browser * Exploiting the browser and its ecosystem (plugins and extensions) * Cross-origin attacks, including Inter-protocol Communication and Exploitation
The Browser Hacker’s Handbook is written with a professional security engagement in mind. Leveraging browsers as pivot points into a target’s network should form an integral component into any social engineering or red-team security assessment. This handbook provides a complete methodology to understand and structure your next browser penetration test.


Attacking Browsers

Fingerprinting Browsers

So, how do you narrow down the exact browser version a target is using? To answer this, this section looks at HTTP request headers, DOM properties, as well as browser quirks.

HTTP request headers are information that is sent with every web request, which detail the supported features of the browser, the URL that is requested, as well as the host and other information. You can look at the header sent to help pick out differences from one browser to the next, as you will explore in the next section. By looking at the DOM, you can see what information the browser has stored about a page that’s being viewed. Because different browsers support different features, particularly those exposed within the DOM, this will help reveal what features a browser has. By comparing that to known features of browsers, you can narrow down the browser type and version further. By combining knowledge about how different aspects of the DOM fi together, you can identify multiple different aspects of the DOM that vary across platform and version, and then combine those to create a match.

You will also investigate how browser bugs can be used to identify a browser. As with most applications, browsers have inconsistencies and bugs from time to time. By looking at these features you can work out if a browser is above or below a certain patch level.

By combining multiple pieces of information, you can determine that a browser might be above version 23 and below version 25, effectively narrowing it down to just a single version. This is the type of fie-tuning that brings you closer to what the actual version of a browser is, and with that information you can more specifially tailor attacks to a particular target.

Combining information gathered from the browser’s User-Agent (UA) header and DOM properties is useful for validating your figerprinting results. The UA header can be spoofed easily so it shouldn’t always be trusted by itself. If you hook a browser that includes “Firefox” in its UA header, but appears to have the window.opera property in the DOM, this browser may not in fact be Firefox. From this analysis you might deduce that it is in fact an Opera browser with a fake UA header. DOM properties can be spoofed too, but it’s not as simple, nor as common, as changing the UA header. If you add some checks for browser bugs, in addition to DOM properties and UA headers, you should be able to reliably ascertain what type of browser you’re attacking