Application security is difficult. Much of network security can be addressed by segmentation, best practice default-deny firewall polices, and well-placed sensors. That’s an over-simplification of network security practice, but it covers the high-level areas most infosec teams can apply to an effective practice. Application security, on the other hand, seems to require not only a bespoke approach per application, but also much greater cross-functional collaboration and discipline.
The DevOps philosophy was meant to solve much of this by fostering cooperation and collaboration between network, security, and developer disciplines at the design, engineering, and operational phases of any application deployment. The reality is that DevOps is still something many organizations are struggling to adopt. Even in the DevOps world, disagreement abounds on how to solve application security challenges. Developers would argue that pushing code regularly to fix vulnerabilities as they’re found is the right approach and aligns with continuous integration and delivery (CI/CD) philosophies. Network operations would prefer to work with sensors in the network with application layer visibility, similar to the firewalls and IPS they’re accustomed to operating. Security teams would want to employ tools and countermeasures at various layers, including regular Red Teaming or penetration testing.
The security or network team may suggest a WAF to filter out bad requests matching signatures for malicious payloads or appearing malformed in the protocol layer. Vulnerability assessments and penetration tests may reveal weakness that can be patched with WAF policy and/or code remediation. The development team may also suggest run-time application self protection (RASP) agents loaded on the application servers, designed to detect threats and adapt to them in real-time. All of these approaches, along with a healthy dose of code review and secure coding practices are necessary for an effective application security practice.
However, these tools still overlook some of the major threats in the landscape by focusing only on application flaws and malicious requests. Many serious threats are sourced from automated sources and generate requests designed to look like legitimate traffic. Automated threats are proliferating at a spectacular rate thanks to all the easily-compromised devices and systems on the Internet available for building botnets. These botnets can be leveraged for everything from DoS attacks to data breaches to credential stuffing to resource hoarding.
More advanced countermeasures are required in a defense-in-depth strategy for application security. Detecting bots in their various forms and functions can be very difficult since the botnet-builders actively work to conceal the nature of the bot client. Rather than task application developers with enriching application code to detect bots, seek out services and devices with advanced application security features.
These features include the ability to interrogate the client to prove it is a legitimate browser or mobile app with a human user. This interrogation is most often done via dynamic JavaScript (JS) injection in the web application responses. Many functions are possible via this sort of JS-injection, including client fingerprinting to uniquely identify a client at the session-level. Via client-fingerprinting, it becomes more difficult for sessions to be hijacked and for malicious clients to evade detection by simply changing IP addresses. Other functions such as parameter-masking and encryption are also possible via code injection at an intermediate proxy, either on-premises or in a cloud service. Many WAF technologies are able to run in a full proxy mode and can be ideal control points to assert these more advanced countermeasures.
These advanced protections against bots are vital to stemming the tidal wave of account takeover attacks seen in recent years. With the plethora of known username and password combinations available via the many large- and small-scale data breaches, guessing passwords via brute force and dictionary attacks is no longer necessary for the attacker. Since as many as 3 out of 4 consumers reuse passwords and compromised accounts number in the billions, account takeover attacks have spread like wildfire due to the automation of credential stuffing.
Protections against account takeover can even be extended to malware-infected machines which may have keyloggers or other malicious spyware present. Enriching the security of the web application in the browser can take the form of keystroke encryption of password fields, and obfuscation of the password parameter name in the HTML. While these methods aren’t bulletproof, they make credential theft and account takeover much more difficult to easily automate via malware or botnet attacks.
These application security enrichments can be enabled via additional application code, but increasingly, information security teams are finding appliances and services capable of injecting these enhancements dynamically. Some WAF technologies have added these enhancements to fight online fraud such as account takeover, and these more advanced application security countermeasures should become requirements for many organizations. Another benefit of commoditizing these protections against bots and malware via cloud services or appliances is freeing developer time to focus on the other business-related application features and writing more innately secure code.
