Client-side Security: Valuable Best Practices to Secure Your Websites

Explore the intricate world of client-side security threats, from cunning Cross-Site Scripting to stealthy Clickjacking, and discover practical strategies to fortify your website defenses against cyber adversaries.

What is client-side security?

Client-side security is something that every website owner needs to understand and stay on top of because the client side of a website (sometimes called the front end) is more vulnerable to attacks than the server side (or backend).

When we use the phrase ‘client-side’, we’re talking about everything that the user sees when they call up a website on any device, whether that’s a phone, tablet, or computer. This includes all the graphical elements, text, and images that make up the design, the forms that users fill in, the buttons they click, and so on, but it also includes the things that go on behind the scenes.

Modern websites are generally very dynamic and interactive, and many extra features like maps, payment options, or chat facilities are provided by connecting the site to third-party applications. A modern website can be connected to dozens or even hundreds of them, and to ensure that the user experience works on so many different devices, all these moving parts need to be brought together in such a way that they can interact safely.

The challenge of client-side security

This is the challenge of client-side security, and it’s easier said than done. This complex, moving mosaic can provide attackers with plenty of opportunities to gain access to data and resources, and with most people now taking their shopping, banking, and socializing online, websites offer a tempting target.

Businesses that fail to keep their websites safe may encounter fines from industry regulators as well as customer lawsuits seeking damages for each security breach. But although the client-side security challenge may seem daunting, there are many practical steps that business owners can take to shore up their defenses against these ever-present threats. In this article, we identify some common client-side security attacks and recommend a range of best practices that you can employ to mitigate them.

Common Client-side Security Attacks

Cross-Site Scripting (XSS)

In a Cross-Site scripting attack, the bad actor injects malicious client-side scripts (usually JavaScript) into vulnerable web apps. Their code changes the way the website behaves so that when other users visit, the attacker can masquerade as a legitimate user in order to control the system and steal their data. Here’s an example of what that might look like:

1.  A website is vulnerable when it fails to properly validate or encode user input in things like search forms, login fields, and comment sections before it displays them in the browser. When an attacker discovers such a vulnerability, they will put together a malicious script (maybe one that creates an alert pop-up box or a request to steal cookies) and then type it into one of the vulnerable input fields.

2.  Without proper output encoding in place, the website accepts the script and displays it. It can now execute on a victim’s browser when they visit that webpage. The victim’s browser has no way of knowing that this script is malicious, it just sees valid instructions, so it goes ahead and runs the script, the alert box pops up, steals whatever it was designed to steal, and sends it to the attacker’s server.

So, an XSS attack is one where the attacker bypasses validation checks to trick the target website into executing scripts in the browser. The goal may be token stealing, cookie stealing, page redirection, control of a web app, or something else.

At this point, it’s also worth mentioning that bad actors often use compromised iFrames to launch XSS attacks. What’s an iFrame? It’s an HTML element that allows content from one site to be nested inside another. Any time you’ve seen a YouTube video embedded into a webpage it will have been put there by using an iFrame. We could talk about iFrame security, but that would just be going over what we’ve already covered in this article here.

Recommended best practices:

• Use modern web frameworks to build apps as these tend to steer developers toward best security practices and include features like templating and auto escaping to mitigate XSS.
• Implement a Content Security Policy (CSP). This can help prevent attackers from injecting malicious scripts into your application.
• Validate all user inputs to ensure they only contain expected values.
• Sanitize user inputs. This means encoding them before displaying them on your site to ensure they can’t be interpreted as code.
• Keep plug-ins and frameworks up to date to limit the number of open doors available for XSS attacks.
• Use a Web Application Firewall (WAF) to help recognize and prevent XSS attacks.

Cross-Site Request Forgery (CSRF)

A cross-site request forgery (CSRF) attack works by tricking an authenticated user into unknowingly submitting a malicious request to a web application they are logged into. Here’s what a typical, attack sequence might look like:

1.   A user logs into a web application using their credentials. The server sets session cookies to identify the authenticated session.

2.  The user visits or gets redirected to a malicious site. This site contains an HTML form or script that targets an action URL within the vulnerable web application.

3.  Because the user is still authenticated by the web application, their browser automatically includes the session cookie with the malicious request.

4.  The vulnerable web application has no defenses against CSRF attacks, so it processes the forged request just like any other valid request. This lets the attacker abuse the permissions of the authenticated user.

The key takeaway here is that session cookies alone cannot protect against CSRF. The attacker can target any function of an application that relies solely on session cookies for protection. By forcing the victim’s browser to submit the request, the application cannot tell that it’s illegitimate. Additional CSRF defenses like tokens or header checks need to be implemented to detect and block such attacks. Here are some examples of how this client-side security vulnerability looks in action:

Social media sites – The attacker creates a request that posts unwanted content, sends messages to other users, or changes privacy settings when the victim visits a particular page while logged in.

Banking/financial sites – Requests are made to transfer money from the victim’s account to the attacker when they click on an embedded link.

Shopping sites – Malicious requests add items to the shopping cart, change the shipping address, apply discounts, etc., when visiting another site.

CMS admin panels – The back-end site management panels in platforms like WordPress or Joomla often have CSRF vulnerabilities that can allow changes like altering user accounts, adding spam pages, or modifying configurations.

So, with this kind of client-side security vulnerability, the main prerequisites are that the website relies on cookies/tokens for authentication and doesn’t validate the originating request. If a user is logged into the site already, CSRF can potentially allow unauthorized modification of data or content to be posted.

Recommended best practices:

• Use Built-In CSRF Protections: Many frameworks such as Joomla, Spring, Struts, Ruby on Rails, and .NET have built-in CSRF support, so check if yours does, and if it does, use it!
• Add CSRF tokens to all requests that make actions happen on the site and validate them on the backend. The synchronizer token pattern is a recommended popular method to combat CSRF.
• Use the SameSite Cookie Attribute to declare if your cookie should only be used in same-site or first-party situations.
• Origin Validation: Verify the origin with standard headers.
• Re-authentication: For sensitive operations, consider implementing user interaction-based protection.
• Avoid GET for State-Changing Operations: Do not use GET requests for state-changing operations.

Remember, Cross-Site Scripting (XSS) can get past CSRF mitigation methods, so it’s important to also use XSS prevention methods. The key is to verify that requests are originating from your own pages, using measures like tokens, cookies, headers, or other signals that cannot be forged from another site. Defense in depth with multiple controls is the strongest approach.

Clickjacking

Clickjacking is a client-side security attack that tricks users into clicking on something different than what they think they are clicking on. The basic premise is that attackers embed hidden malicious code or buttons in what seem to be harmless pages or links. When a user clicks there, instead of activating what they think they clicked, it triggers the hidden malicious code.

For example, an attacker might create a page with an invisible layer over the top that exactly matches up with buttons or links people expect to click on legitimately. So, when users click on a normal button, they are actually clicking on the invisible button that then activates malicious code or sends them somewhere dangerous.

This allows attackers to “hijack” clicks meant for one purpose or website and channel them into enabling malware installations, revealing private data, posting content on social media under someone else’s identity, or redirecting them to unsafe sites.

There are several ways to defend against clickjacking:

• Content Security Policy (CSP): Use this to instruct the browser to refuse framing from other domains.
• X-Frame-Options: Set it to ensure that a website’s content isn’t embedded into other sites.
• SameSite Cookies: Use this attribute to prevent clickjacking attacks by ensuring that session cookies don’t get included when a webpage is loaded in a frame. If the session cookies are marked as SameSite, a clickjacking attack where the victim needs to be authenticated will fail because the cookie won’t be sent.
• Defensive UI Code: Employ defensive code in the UI to ensure that the current frame is the top-level window.

Web-Skimming and Magecart

Web skimming and Magecart attacks target online transactions. Magecart is a specific category of web skimming attack used by various cybercriminal groups. Big-name companies like British Airways, Ticketmaster, and NewEgg have all fallen victim to them.

Here’s how these attacks typically work:

1.  Access to Website: Attackers gain access to a website, often by exploiting vulnerabilities or compromising third-party scripts.

2.  Injection of Malicious Code: Once they have access, attackers inject malicious JavaScript code into the website. This code is designed to skim sensitive information such as email addresses, passwords, and credit card numbers from online payment forms (formjacking)

3.  Data Skimming: The malicious code monitors user input, waiting for entries in sensitive areas like credit card and CVV fields on checkout pages. When it detects this kind of input it captures it.

4.  Data Exfiltration: This is usually the simplest part of the process where the skimmed information is forwarded to the attacker’s server.

5.  Use of Stolen Data: the attackers are now free to use the stolen information to commit fraud against the victim, or they might choose to sell it on to others, usually as part of a bundle on the dark web.

Recommended best practices: 

1.  Identify all your third-party e-commerce and online advertising vendors. 

2.  Monitor all third-party scripts on your websites.

3.  Monitor code changes on your websites.

4.  Implement client-side anti-web skimming solutions.

5.  Regularly patch your software and operating system with the latest security updates.

6.  Implement malware protection and stay abreast of the latest security patches for all tools and software used on your site.

7.  Expose next-generation cyber-attacks by analyzing script actions.

8.  Track changes, prioritize issues and alerts according to severity level, and remediate.

9.  Ensure continuous monitoring of all sensitive web pages.

How Reflectiz can help with client-side security

Reflectiz empowers you to defend your websites against many of the client-site security issues that we’ve explored. Our sophisticated platform protects them against client-side security vulnerabilities by constantly scanning for code changes, behavior changes, and data exfiltration attempts. It detects malicious scripts and domains, tracks changes in your critical web pages, prioritizes issues according to severity level, and applies on-demand blocking, if needed, to effectively eliminate malicious activity.

But that’s only half the story because we’ve ensured that all that threat detection intelligence is usable. Teams can easily succumb to alert fatigue, so the system is set up to take a risk-based approach to reporting and delivers it via a UI that is intuitive and easy to get to grips with.

If you’d like to level up your client-side security protection, sign up today