Skip to content
HOME >> CYBERSECURITY >> Top web browser attacks and how to avoid them in 2022

Top web browser attacks and how to avoid them in 2022

Top web browser attacks and how to avoid them in 2022. Web browsers enable us to access all kinds of content. Because of that, they’re a tempting target for hackers. We look at the top web browser vulnerabilities and what you can do to avoid them.

Web browsers are the primary target for many attackers because so much sensitive data passes through them. From casual shopping to enterprise management systems to military operations, browsers have become the primary vehicle people use to access network-connected systems. Unfortunately, browsers have a long and storied history of vulnerabilities that have provided attackers with a lucrative and near-endless supply of victims upon which to prey. 

Web browsers are an attractive target to malicious actors because they contain so much sensitive data. Not only that, but web browsers have become one of the primary applications people use to access networked resources, from online shops to government databases, making them an even more valuable payload.

Cross-site scripting (XSS)

This tops our list because it is the most common attack vector for web browsers. Cross-site scripting (XSS) directly targets web applications and websites rather than the browser itself, although it’s the web browser that will deliver the payload. The attack manipulates a web application or website into delivering malicious client-side scripts to a user’s unsuspecting browser, which executes the script without user intervention. Once executed, the script can exfiltrate personal and financial information from the site, install malware, or redirect the victim’s browser to other malicious web pages, among other things.

Cross-site scripting attacks depend on a website or web application’s failure to properly validate user input, opening the door to malicious code being pushed to the server and then back out to users from there. Failure to validate user input can also open the door to CSRF, form action hijacking, session hijacking, and SSRF attacks.

Cross-site scripting (XSS) Mitigation

Sanitize user input. Consider all user input to be untrusted. As soon as user input is included in the HTML output, the risk of an XSS attack is introduced. And the more of it there is, the bigger the risk becomes. Treat input from authenticated users, internal users, and public users the same way: don’t trust it.

You also want to enable the following:

  • The Content Security Policy (CSP) header – Enabling CSP provides an added layer of security by allowing website administrators to control which resources the user agent is allowed to load for a given page.
  • The HTTPOnly flag – Using the HTTPOnly flag when generating cookies can lower the chances of client-side scripts accessing protected cookies.

Another important mitigation measure would be to encode the output of your server’s HTTP responses to bar the browser from interpreting it as active content and executing the embedded code.

Malicious browser plugins

Also high on the list are vulnerabilities in web browser plugins. Web browser plugins are tiny applications that add functionality to a web browser, such as blocking ads, disabling JavaScript, or downloading youtube videos, among other things. There are literally thousands of browser plugins available for most major browsers. And many browser plugins are very popular, finding themselves installed on hundreds of thousands – and in some cases, millions – of machines.

The downside, however, to browser plugins is that they have access to your browsing history and many of them can manipulate your traffic in various ways. Normally, these access permissions should be required to fulfill the plugin’s functionality. However, that access opens the door to malicious plugins as well.

Because of the privileged access browser plugins have to your browser, a malicious plugin could do all sorts of things, such as redirecting your traffic, triggering the download of malware, and stealing the information you supply in web forms – the sky is pretty much the limit here.

Malicious browser plugins Mitigation

The easiest way to steer clear of the threats posed by web browser plugins is to avoid them altogether. Just don’t install any.

If you really want/need web browser plugins, keep them updated so that you get the latest bug fixes and security patches. Most browser plugins have an automatic update function somewhere in their settings. Also, don’t leave unused browser plugins lingering in your browser. You should also only install plugins that come from your browser’s official store and uninstall any browser extensions you don’t use.

Broken authentication and session hijacking

Whenever you log into a website or web application, the server you log into assigns you a unique session ID. As you browse the website and navigate various pages, the server and your device continually exchange the session ID in order to validate the session.

However, let’s suppose the session ID isn’t properly encrypted. In that case, it could be intercepted by malicious actors who would then be able to hijack your sessions (i.e., start a new, authenticated session in your name). After that, the attackers could lock you out of your account, make purchases in your name (if a credit card is linked to the hijacked account), and, of course, steal your sensitive information (which could lead to other attacks).

Your browser may be particularly vulnerable to this type of attack if you’re connected to an unprotected public hotspot. Unprotected means a lack of encryption and opens the door wide open to packet sniffing, which could reveal, among other things, your session IDs.

Broken authentication and session hijacking Mitigation

Website administrators should use SSL to secure interactions between users and the site. They should also add encryption wherever possible to obfuscate the metadata that will inevitably be generated.

Another sound piece of advice would be to avoid unprotected public WiFi. Or, at the very least, use a trustworthy VPN when using public WiFi so that your traffic is still encrypted even if the WiFi hotspot you’re connected to doesn’t provide encryption.

SQL injection

SQL injection has been an actively exploited and largely successful online attack for more than ten years. In fact, the Open Web Application Security Project (OWASP) has included SQL injection in the top tier of its Top 10 threats list for roughly the same period. With SQL injection, attackers can push SQL commands to a web server in an attempt to access, modify, or steal data stored on the server.

Malicious actors can corrupt the server’s web forms, cookies, or HTTP posts and manipulate them into injecting their malicious code into the unsuspecting website visitor’s browser, which will execute the code, as it considers it as coming from a trusted source. Once they have access to the user’s browser, attackers typically harvest sensitive (and profitable) information from the compromised user, including customer names, Social Security numbers, and payment details.

SQL injection Mitigation

The mitigation techniques for SQL injection closely follow those used to defend against cross-site scripting. Organizations should ensure their web server(s) sanitize and filter user-supplied data while also limiting the functions that can be executed through SQL commands. Additionally, web application firewalls should be deployed to protect organizations from SQL injection attacks made possible by potential vulnerabilities found in third-party software.

Man-in-the-middle/man-in-the-browser attacks

Any third party that can insert themselves between a user and a website/application in a network connection is considered a “man in the middle.” Man-in-the-middle attacks are system-wide, while man-in-the-browser attacks are limited to your browser’s traffic, but they both share essentially the same modus operandi and they’re both quite dangerous.

In both permutations, the man-in-the-middle has the ability to observe and even modify traffic as it passes between the browser and web servers because they sit in “the middle” of that connection. Because the man-in-the-middle can modify the contents of what’s being transmitted and received, this type of attack can lead to pretty much any undesirable outcome typically associated with online attacks, from phishing to data theft, malware, ransomware, etc.

Because the attacker in a man-in-the-middle attack can manipulate the traffic coming and going from your browser, they can alter the messages you receive, redirect your traffic, manipulate DNS responses, etc. If you fall victim to a man-in-the-middle attack, you simply cannot trust what’s displayed in your browser.

The use of TLS/HTTPS helps mitigate this attack because attackers typically have a difficult time spoofing certificates used by the server to authenticate itself to the browser. But we know (and so do the attackers) that we’ve essentially been conditioned to ignore browser warnings and click through them when they appear. So attackers frequently use an invalid/self-signed certificate, and in many cases – if not most – users will ignore their browser’s warning.

Man-in-the-middle/man-in-the-browser attacks Mitigation

Mitigating this one is relatively straightforward. Don’t ignore your browser’s warnings. If your browser displays a warning that you may be accessing a malicious site or that there’s a TLS certificate mismatch, pay attention and follow your browser’s advice (unless you positively know that it’s a false positive). And even then, if you have any reason to doubt, try a different machine or internet connection.

Of course, website administrators should make sure their sites use TLS/HTTPS.

DNS Poisoning attacks

DNS poisoning attacks are nasty business. DNS servers are responsible for translating human-readable website names, like apple.com, to an internet-routable IP address, such as 17.253.144.10. Malicious actors can compromise your browser’s DNS in various ways.

Your device (laptop, tablet, smartphone) caches DNS entries, and many attackers attempt to poison your local DNS cache. Additionally, a particular file on your system (the “hosts” file) can override DNS servers’ responses for specific web addresses. Malicious actors can even compromise DNS servers themselves, forcing them to serve compromised IP addresses for legitimate sites.

Once a DNS poisoning attack is set up, your browser will end up on a compromised site, controlled by the attackers instead of the legitimate website you requested – although the chances are high that it won’t be immediately apparent that you’re on the wrong site. As with other website-spoofing attacks, the goal is to get the user to enter sensitive information, such as user names, passwords, and payment information.

DNS Poisoning attacks Mitigation

Make sure to check for “HTTPS://” at the beginning of the site’s URL when visiting a website – especially for email, online banking, and any other website with which you’ll be exchanging sensitive (valuable) information. Even with a poisoned DNS cache, malicious actors likely won’t be able to forge the site’s TLS/HTTPS certificates. So, most of the time, they’ll use a plain HTTP URL (those starting with “HTTP://…” rather than “HTTPS://…”) in the hope that users don’t notice. And of course, again, don’t ignore your browser’s warnings.

Advanced Persistent Threats

Advanced persistent threats (APTs) quietly install malicious code on an endpoint and then steal data (keystrokes, screenshots, browser activity) or even modify what the user sees in their browser, sometimes going undetected for years. These attacks use a myriad of methods to get users to install them, many not related to the browser—for example, via an infected thumb drive or a hostile email attachment. But since so many sensitive interactions occur via the browser, most of these types of attacks put a high priority on stealing data from the browser.

Advanced Persistent Threats Mitigation

Install a good antivirus product, and don’t pick up random thumb drives, open suspicious email attachments, or visit spam-filled sites on your work computer. Also, avoid public Wi-Fi networks as much as possible, as attackers can sometimes access machines through these.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.