Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Are You Prepared to Handle Security Breaches for Web Applications?

DZone 's Guide to

Are You Prepared to Handle Security Breaches for Web Applications?

From identification, to containment, to eradication do more than just react to a vulnerability

· Security Zone ·
Free Resource

man-taking-out-trash-in-alley

Take security threats where they belong

Chances are, while you’re reading this, there are frantic boardroom meetings happening in some parts of the world. Imagine CxO’s shivering to their bones, urging their IT security teams to "do something" about the web application security breach they’ve been hit by. That’s how web application security breaches are.

You may also like Why Framework Choice Matters in Web Application Security.

What do the numbers say?

The number of vulnerabilities in 2018 (17,308) increased by 23%, as compared to the previous year.

Number of vulnerabilities exposed by month

Number of vulnerabilities exposed by month

A web application security breach may be sooner down in the timeline than you’d want or anticipate. What can you do? Well, be prepared with a plan to handle the incident; that’s what we’ll help you with.

Incident Response Life Cycle

The life cycle spans across:

  • Preparation: being ready to handle incidents.

  • Identification: detecting the incident.

  • Containment: limiting its impact.

  • Eradication: threat removal.

  • Recovery: bringing the situation back to normal.

  • Lessons learned: ensuring the same breach won’t happen again?

Incident Response Lift Cycle

Incident Response Life Cycle

The Scope of This Guide

We’ll assume you have prepared for the web application security incident. This guide tells you what to do from here on, for the identification, containment, and eradication. Recovery and lessons learned are not in the scope of this guide.

Identification

Objective: Finding out all security breaches, with their sources.

A system flaw, leaked credentials, a CRLF injection, XSS attack, a directory traversal, cross-site request forgery, failure to restrict URL access, insecure cryptographic storage, LDAP injection, insufficient protection of transport layer, a malicious code, SQL injection attack, operating system command injection — the list can go on.

How do you know you’ve identified all breaches? On top of that, how do you know you identified them accurately? The questions to ask yourself are:

  • Do we use any kind of proprietary application profiling to report anomalies?
  • Do we correlate our attack validation checks to make sure there are no false positives?
  • Do our detection mechanisms "understand" all application aspects (URLs, valid user inputs, file paths, etc.).
  • Do we update our software and patches frequently enough to ensure hackers can’t inject malicious SQL codes to exploit new vulnerabilities?
  • Are we updating our web app firewall filter rules frequently enough to ensure all malicious codes are kept at bay?
  • Do our logs and reports capture anomalous activities and clearly highlight them?

A lot of this comes down to the quality of your web application firewall (WAF). Consider using a WAF that protects your apps in the cloud and on-premise and offers security against the most common vulnerabilities (broken authentication, injection, broken access control, security misconfiguration, cross-site scripting, XML External Entities, etc.) 

Containment

Objective: Mitigate the impact of the incident on the targeted environment

The first step is to create a backup of the entire data stores on the web server (this is the evidence of the breach). If you can, try to create a bit-by-bit copy of the disk containing your affected web server.

Ascertain that the web app vulnerability exploited by the cybercriminals is not located somewhere else. Check all other services running on the machine hosting the webserver. Enlist all other systems that may have been impacted and check connections to them. The ideal containment strategy is to physically disconnect the system from which the attack originates and investigate further.

If you need to deploy a temporary web server in place of the affected server, make sure that it either has the same level of data/content as the affected server or shows an appropriate message such as “unavailable at the moment, we’re working on it.” To prevent another instance of infection, display temporary static content with HTML only.

Eradication

Objective: Remove the root cause of the breach such that the impact doesn’t happen again.

For your affected web application, this could involve:

  • Replacing the hacked/defaced page with a clean page with a temporary message.

  • Running the affected system through your malware removal and antivirus tools, ensuring the corrupted content is removed.

  • Eliminating the network channel that paved the way for the security breach.

  • Changing the passwords that were compromised because of the breach.

  • Restoring the affected data using your backup.

  • Removing the OS backdoor that led to the breach.

Eradication has to be 100% successful because if you make the web application available to end-users without fully eradicating the threat, the consequences will be severe. Of course, this is based on the assumption that you’ve identified all the threat sources.

Parting Thoughts

Again, during the time you took to read this, the stress in that boardroom we envisioned in the beginning of this guide is a lot more tense, as chaos ensues in the absence of a proper mechanism of handling security breaches. Don’t be a part of that boardroom, you can, and must do better.


Related Articles

Topics:
application secuity ,applications ,security ,web framework ,vulnerabilities ,Incident Response Life Cycle

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}