Websites and applications are the front doors to your network. Whenever you log into either, you’re making dozens of API connections for the smoothest user experience — connections that can be hijacked and twisted toward data theft. Almost 33% of digital security breaches stem from web app compromises.1 From SaaS and CRM platforms to customer or employee portals and company websites, there are many potential avenues to compromise your data, users, or network.
Josh Davies, Fortra’s Alert Logic Principal Technical Marketing Manager, knows a thing or two about application security. As he describes them, “Apps need to be available 24/7 for your business to function, whether we’re focusing on employee productivity or users that can access the service or product you’re trying to sell.” He’s aware that round-the-clock protection is an enormous priority. That’s why he took the reins for our recent webinar on all the threats surrounding web apps. You can watch the full webinar on demand, but we also wanted to summarize his views on impact assessment — a pivotal approach to stamping out network dangers.
So, here’s what Davies wants to tell you about web app security: what it is, why it matters, and how to set up the perfect response.
Why Are Web Apps Vulnerable?
It’s imperative to realize what can go wrong with the technological architecture many businesses take for granted. Credit card details, for example, might be tied to a particular application. Passwords and usernames can easily grow to hundreds or thousands on a single platform. Some web apps give you critical control over operations, too. Davies points to one major target — management interfaces — because they offer admin access that’s ripe for exploitation.
Whether you’re building a custom application or not, app technology sits on top of a web server, which has its own vulnerabilities connected to data stores and widens your attack surface. Some of the main threats to your security include:
SQL injections
Query language creates malicious requests, grabbing data from the connected data stores without proper authorization. As Davies says, “Machines are pretty stupid, they just do what they’re told, without making a value judgment on whether they should. If you don’t sanitize the input and let that request get to the backend, the machine will just run the code and answer the user request.”
Remote code execution
Often without prerequisites like authentication, a criminal tricks a target machine to run malicious code remotely. This allows them to take full control of the server. Then, they could move laterally into your network to deploy ransomware or use the web app as a trusted mechanisms to distribute further malware to your users in a watering hole attack.
DoS and DdoS
Denial of Service (DoS) makes a request that “tricks the server into an infinite logical loop, frying itself.” On the other hand, a Distributed Denial of Service (DDoS) spams a web server with a huge volume of requests and forces it to crash. While a DoS attack can be easily detected, a DDoS is nearly impossible to distinguish from legitimate activity. Davies notes that a content delivery network (CDN) is a great tool for mitigating DDoS attacks. A CDN sits in the cloud and caches pages “at the edge,” taking the bulk of requests that don’t require interaction with the web app.
Credential stuffing
Crucially, Davies shared that 75% of web app breaches result from hackers simply trying usernames and passwords they’ve bought from the dark web. As Davies says, it’s low and slow with a relatively high success rate. “Credential stuffing is basically the evolution of a brute force attack, which goes through numbers and the alphabet sequentially, but that’ll lock you out quite quickly.” Captcha and bot prevention controls can mitigate this threat.
What Does Malicious Web App Behavior Look Like?
Although web app attacks can be complex and far-ranging, there are warning signs to look out for. They inform our managed detection and response (MDR) threat intelligence, directing our combination of automated security detections and human-led investigations.
Web application vigilance can be split into three areas:
Centralized application and OS logs are a solid basis for detection
By piping logs through live analytics, we can trigger an alert when a threshold, correlation, or machine-learning algorithm determines the activity as worth investigating. “These logs are incredibly numerous and verbose,” Davies says. “There’s really a lot of them. You have to make sure you’re filtering and finding the right ones, but you also have to collect them all for investigation purposes, because you never quite know which are going to be useful.” Ideally, you want to enhance your log configurations to provide further visibility, capturing more than standard web app activity, observing abnormal pathways, malicious GET requests, and other data points. However, relying on logs alone is not sufficient for web app threat detection, as there are limitations in visibility. For example, if an attacker were to send an exploit using POST, rather than GET, the attack would be missed.
A network IDS gathers more information and builds a richer picture of network risks
By inspecting data packets, you’re able to see the entirety of the client request and server responses, “full, deep-packet inspection,” as Davies puts it. This provides visibility that logs don’t have, such as being able to verify whether an exploit was successful, or to see exactly what data was leaked following a successful SQL injection.
Stay aware of which files have been altered, deleted, or added during an attack
File integrity monitoring paves the way for root-cause analysis, showing who changed what, when, and whether it was during the compromise window. Malicious web actors can tweak configuration settings, for example, to periodically reinfect your system. Davies reminds us that, “Really sophisticated attackers will actually gain access quietly, change all your files, and wait a while so all of your backups have those malicious versions inside.”
An Analyst’s Role in Detection and Mitigation
Wrapping advanced technology around your web apps is only half of the equation for staying safe. While Davies concedes that everything he’s discussing falls back to the data at our fingertips, more scrutiny is required to turn incidents into alerts. Although machine learning searches for abnormal access pathways 24/7, it won’t be correct 100% of the time. Therefore, human analysts have a huge role to play in your security posture. “Frankly,” Davies says, “if anyone tells you otherwise, that’s snake oil.”
When Davies joined Fortra’s Alert Logic team, he was in the trenches with reams of incident data, combing console reports for actual threats. And while analytics intelligence has developed significantly since then, he’s still an evangelist for the human touch. It’s central to true validation.
Consider new analytics triggers, for instance — the signs of a breach that security technology will be looking for. Zero-day (unknown) threats are rooted out by long- and short-tail analysis, researching unknown dangers, and adding them to a known threat library. Then, there’s the benefit of having someone there to explain what’s happening and how you can stop it. Alert Logic’s 15-minute SLA gives our customers rapid guidance over the phone, shedding more context and details on a serious incident.
Additionally, our analysts follow a six-step process for blocking assault progression and limiting potential downtime. They are:
- Contain
- Disrupt
- Validate
- Patch/Harden
- Remove
- Monitor
If our customer faces a web app compromise, Alert Logic’s security team will offer advice that evolves with the incident. The web actor, in this case, might be exploiting a remote code execution for initial entry, download a “webshell” backdoor to facilitate next steps as they gaze at every file and permission they now have. We can proceed with two response strategies. The first is automated, examples could be disabling compromised user accounts and cordoning off perimeters to buy you time. These simple actions can be performed faster, and more efficiently by automation. These are your containment and disruption response actions.
The second response strategy is to provide complete remediation, which requires human intervention as the response actions are more nuanced and case specific. This could include applying a patch or altering configuration settings to plug the initial entry vector. It may involve reviewing files and code to rectify those that have been maliciously modified, while ensuring you don’t remove anything your application requires to perform its business function. “You don’t mind taking more time,” as the actions can have implications beyond the initial compromise and security advice needs to be considered alongside business context and risk appetites. Such actions are not suitable for automation, as Davies advises, “because a finer hand should be doing this.”
Of course, you should never be blindly confident that the full scope of compromise has been identified and that you have performed all the remediation actions successfully. This is why we continue to monitor the affected systems closely, re-initiating the incident response process if necessary, and providing our customers with peace of mind that the experts are always watching.
That’s just one instance of our skills in action. To bolster your web app security knowledge, watch our webinar on Responding to Web Application Compromise. Explore more about Fortra Managed WAF.
Related Customer Case Study: Alert Logic’s WAF Helps Technology Advisory Firm Secure Their Web Applications
Related Video: What is a WAF?
Footnote:
- 2022 Verizon DBIR
