Web browser attacks are some of the most prevalent online attacks today. Web browser attacks come in all shapes and sizes, and they don’t necessarily directly attack your web browser. The attack could be mounted by attacking a website/ web application, an endpoint, a DNS server, etc. The attacks manipulate your web browser into performing an undesirable action that leads to your browser delivering the payload of the attack.
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.
In this post, we look at the top five web browser attacks and provide mitigation advice for each one.
1. 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.
Example of a cross-site scripting attack
In 2019, the popular online video game Fortnite fell victim to a data breach that enabled the attackers to access the accounts of up to 200 million users. This was a cross-site scripting attack that exploited an XSS vulnerability that was present in just a single unsecured web page on Fortnite’s servers — but it was more than enough…
More recently, in 2023, researchers discovered a reflected cross-site scripting vulnerability in the Zimbra Collaboration Suite (ZCS) email servers that was actively being exploited. Zimbra released security updates to patch the vulnerability two weeks later, while warning users that the XSS vulnerability could “potentially impact the confidentiality and integrity of your data.”
Mitigating cross-site scripting attacks
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 web site 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.
2. 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 fulfil 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.
Examples of a malicious browser plugin attack
In June of 2020, cybersecurity firm, Awake Security — which is now owned by Arista — published a report that identified 111 malicious Chrome browser plugins. The plugins in question could do things like bypass Google’s Chrome Web Store security scans, take screenshots, read the clipboard, collect authentication cookies, and record user keystrokes. The report states that by May 2020, the 111 malicious extensions had been downloaded 32,962,951 times. Google subsequently removed 106 of them from the Chrome Web Store.
In 2023, cybersecurity firm — Sucuri — reported that attackers were using an abandoned WordPress plugin — Eval PHP — to insert malicious code into websites. Although Eval PHP hasn’t been updated in over ten years, many WordPress sites continue to use it.
Mitigation
The easiest way to steer clear from 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.
3. 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 “lack of encryption” and opens the door wide open to packet sniffing, which could reveal, among other things, your session IDs.
Examples of a session hijacking attack
A nice example of a session hijacking tool is Firesheep. Firesheep is a Mozilla Firefox extension, released in 2010, that provided attackers with an easy way to extract private information, such as session cookies, from users over unencrypted wi-fi networks. Large websites like X (then Twitter) and Facebook were vulnerable to Firesheep until they enabled HTTPS on all pages of their websites.
In 2023, the channels of tech YouTuber Linus Sebastian were taken over by hackers. One of Sebastian’s employees had unwittingly extracted an emailed file containing malware that accessed user data from browsers. This enabled the attackers to access the YouTube channels and replace the videos found there.
Mitigation
In addition to not extracting files in unknown email attachments, 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 wi-fi. Or, at the very least, use a trustworthy VPN when using public wi-fi so that your traffic is still encrypted even if the wi-fi hotspot you’re connected to doesn’t provide encryption.
4. 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.
Examples of an SQL injection attack
In 2021, far-right social media website Gab had over 70GB of user data stolen by an attacker. The attack was mounted using SQL injection. The irony is that the vulnerability that enabled the SQL injection attack was introduced by the company’s CTO, who had a hand in building the site.
In 2023, attackers used a SQL injection vulnerability to target the MOVEit Transfer file management web application. They were able to install a web shell and extract personal data from thousands of companies and government entities around the world.
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.
5. 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 — if not most — cases users will ignore their browser’s warning.
Example of a man-in-the-middle attack
In 2011, Iranian users of Google Chrome were targeted with a man-in-the-middle attack. The attackers had managed to get their hands on a fake Google SSL certificate that Google Chrome considered valid. The attack went on for two months before it was neutralized when Google hard-coded the fingerprints for its own sites’ encryption keys into Chrome, with a directive to ignore any different information that may be coming from certificate authorities (CA).
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.
6. 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.
Example of a DNS poisoning attack
In 2011, many large Brazilian ISPs fell victim to a massive DNS poisoning attack. Clients of the affected ISPs trying to access some of the Web’s top sites (Google, Gmail, Microsoft) would be redirected to an innocuous-looking malicious site and prompted to download a Java applet to access the website they originally requested. It was reported that the attackers managed to poison the DNS cache to redirect users to the malicious site.
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.
Other common-sense measures that make sense
So the above list consists of the main threats that can affect your browser and their respective mitigations. But there are other threats. As such, below is a shortlist of common sense tips that will keep you safer online. Every little bit helps, so it’s recommended to implement as many of these as reasonably possible.
- Don’t open attachments in emails unless you know who the sender is and that you’ve confirmed with them that they sent you the email in question and are aware of the attachment (and what it is).
- Don’t click links (URLs) in emails unless you know who sent the URL, what its destination is, and that you’re sure the sender is not being impersonated. Even then, scrutinize the link carefully. Is it an HTTP or an HTTPS link? The vast majority of legitimate websites today use HTTPS. You also want to check the link for incorrect spelling (i.e., faceboook instead of facebook or goggle instead of google). If you can get to the destination without using the link, do that instead.
- Use an antivirus program. And make sure only to buy genuine, well-known, and reviewed antivirus software from legitimate vendors. Always keep your antivirus application updated and configure it to run frequent scans regularly.
- Keep your operating system updated. The latest OS updates contain the latest security patches. Make sure they’re installed as soon as they’re made available.
- Use a firewall – Major operating systems all have a built-in incoming firewall, and all off-the-shelf commercial routers provide a built-in NAT firewall. Make sure these are enabled. They could make all the difference in the world if you ever click a malicious link.
- Never click on pop-ups. Ever. You never know where they’ll take you (though it’s pretty easy to imagine).
As always, stay safe.