Not too long ago I wrote a blog series in which I discussed five client-side security approaches. The initial five approaches included:
- Web Application Firewalls
- Content Security Policy
- Penetration Testing, Vulnerability Assessments, and Security Assessments
- Vulnerability Scanning
- JavaScript Security Permissions
Since then I’ve been doing a metric ton of research trying to better understand how web application developers and cybersecurity professionals can secure their front-end web applications. I found two more approaches that are worth learning about.
- Code Obfuscation & Scrambling
- Client-side Attack Surface Monitoring
Let me walk you through what code scrambles and obfuscators are and what they can and can’t do. Tune into our blog later on to learn about client-side attack surface monitoring solutions.
What are code scramblers and obfuscators?
Code scrambling or code obfuscation is a process by which easy-to-read code is distorted to make it difficult to comprehend. The goal of code scrambling and obfuscation is to make it difficult for competitors, other developers, and threat actors to reverse engineer or modify it. Code obfuscators allow websites to load properly in the browser without being different to the naked eye. Web application developers and security teams acquire code obfuscators in order to hide JavaScript web application code that threat actors or competitors might target. The general idea is that by concealing portions of the code, the risk that a threat actor might use it for malicious purposes might go down.
What limitations do code scramblers and obfuscators have?
It is quite easy and cheap to scramble or obfuscate code. There are many free code obfuscation tools available, but they come with some significant limitations. First, with time and effort web applications that were obfuscated with free code obfuscating technologies can be reverse engineered to uncover a version of the original application. This is why hackers use code obfuscation to their advantage. There are also code de-obfuscators on the market. Unfortunately, these simply do not work. Some paid code obfuscating technologies pollute the original web application code to such an extent that you can’t even get remotely close to the original code if you try to unscramble it. Herein lies a substantial problem. If you obfuscate your web application code, you can’t unscramble it. You can’t go back to the original code. So it gets extremely hard to spot security issues and vulnerabilities in the code. Normal code and malicious code in a scrambled web app looks exactly the same. Your web developers can no longer see issues in the code with the naked eye and are likely to miss critical vulnerabilities. Some businesses circumvent this by implementing dynamic code analysis to track issues, but this is time consuming, costly, and inefficient.
Are code scramblers and obfuscators right for me?
Well, it depends. If you have a simple, single-page web application that doesn’t collect user data and security isn’t an issue, then, sure, code obfuscation might be a viable option for you. However, if you have a sophisticated web application or web page that you use to interact with your customers, you cannot risk not being able to see code vulnerabilities. For example, if your web application is using third-party scripts that you’ve scrambled or obfuscated, and those are attacked in a drive-by-web skimming attack, you will not be able to see the malicious code. A skimming attack could run on your web application in perpetuity. If your web application collects payment information, or if you conduct business in Europe where GDPR is a clear and present danger, you are leaving your business open to tremendous fines, legal action, and troves of upset customers.
In closing
Threat actors are really good at poking holes in even the best security controls, products, and infrastructure. With JavaScript, they don’t even have to breach a network. If they want PII or credit card data, all it takes is one bad third-party script. If your business is using third-party scripts in your web applications, which automatically load from GitHub, and you are also using code obfuscating technologies, you will make it impossible for your business to detect and defend from client-side attacks. It’s honestly better to just lay your code bare, unobfuscated or unscrambled, so that the human eye can see potential issues. On the flipside, if a threat actor is using code obfuscation technologies to hide their malicious code, your developers and security analysts will be able to detect the obfuscated code and can investigate what is being obfuscated, allowing you to better detect and respond to client-side threats.
Implementing effective client-side security is crucial to ensure the safety of your customer data, the integrity of your user experience, and the functionality of your web applications and websites. Having a safe and secure digital presence is the core tenet that drives your businesses ability to grow and succeed. Check out our Inspector and PageGuard products. They are specifically designed to help you avoid the problems and complexities of scramblers and obfuscators by continuously scanning and protecting your business from attackers attempting to execute JS attacks. Moreover, by employing synthetic users in scanning web applications, Inspector is able to detect threats hidden in your code. If you would like to see our products in action, please request a demo here: link.
