Education center Application Security

How to Prepare for Attacks on Client-side / Front-end of your websites and web applications

Once the breach has been contained and you’re certain your business and customers are no longer at risk, then you need to prepare for future attacks, because in spite of your best efforts, no web application or code is going to be perfect, and the threat of future attacks is always looming in the distance.

Step 1: Learn, Learn, Learn

If you are like most organizations, a client-side attack is something new and unknown. In order to properly prepare for future attacks, you have to collect as much data, intelligence, and information as possible. Here’s a quick list of the types of information your organization should capture:

  • List of all your web applications and websites.
  • List of access details and credentials for databases and technologies.
  • List of customer, prospect, or user data collected.
  • List of all approved first- and third-party scripts used on your website.
  • List of all approved data first- and third-party scripts used on the website.
  • Configuration file names and paths.
  • List of applicable log files collected from your website, web applications, software, system files, etc.
  • List of API keys, security tokens, and integration details.
  • Vendor contact information (if your website is hosted externally, and if you have any marketing or other technologies integrated with your client-side applications).

Step 2: Scan for Vulnerabilities

Threat actors love to find vulnerabilities in your code so that they can exploit them. When preparing for future attacks, it is important to ascertain whether your website is up to date. Are you using the most secure code libraries? Have you deployed all available patches? Take your time to scan your website or web application and mitigate risk as much as possible. If there are any vulnerabilities without an available patch, track it, or find a work around. Make sure you identify:

  • Web server misconfigurations
  • Old software versions
  • Known vulnerabilities in software versions
  • Available patches for known vulnerabilities
  • Inappropriate access to file and system locations or data

One thing to note, traditional vulnerability scanners are designed to scan back-end code and systems, a.k.a. server-side technologies. It is unlikely that they will be able to detect every client-side vulnerability that a industrious threat actor might use against you. To learn more about client-side vulnerability scanning, check out our blog.

Next, patch all vulnerabilities you uncovered immediately. If there isn’t an available patch, do some research to find out if there is a way to reduce the risk of vulnerability exploitation. You will likely have to end any unauthorized or foreign processes, remove corrupted or unauthorized files, and, if the threat actor modified any client-side script, replace modified files with approved or sanitized versions.

Step 3: Test Your Defenses

Once you have regained control over your web applications and websites, use the intelligence you have collected to validate and, if necessary, upgrade your defenses. Use the threat actor tactics, techniques, and procedures (TTPs) that successfully breached your website previously to see if the same TTPs still work. Use the client-side cyber threat intelligence (CTI) you have collected and look it up in open-source CTI feeds or in paid feeds like VirusTotal. Learn more about your attacker, see how else they might attack you, and pressure test your website to see if those other TTPs might work.

You may also wish to create a clone of your website to test your defenses. If you are using real TTPs, you don’t want to harm your customer-facing website. The goal is not to disrupt your businesses ability to grow and interact with your customers.

Free Assessment

Security for Everyone that Visits Your Website

Find out if your web application is hiding vulnerable, malicious, or dangerous code that could damage your customers and your business. No payment information required.