If we step back and think about what customers are up against, it is truly staggering.  Building a secure web application and network are akin to building a nuclear reactor plant. No detail is small and insignificant, so one tiny failure (a crack, weak weld, or a small contamination), despite all of the good inherent in the design and implementation, can mean failure. A similar truth impacts web application security – just one flaw, be it a misconfiguration or omission in the myriad of components, can provide attackers with enough of a gap through which immense damage can be inflicted. And to add insult to injury, these same proactive defensive measures are relied upon in many environments to help detect these rare events (sometimes called black swan events). Network and application administrators have a tough job, and a white-hat’s purpose is to help them and their organization do it better.

Web application frameworks and platforms contain provisions to help secure them against nefarious actors, but they are rarely deployed alone in a production system. Enterprises will often deploy cyber defense systems that can also enhance their applications’ protection, awareness, and resilience against the attack. In most cases, enterprise buyers will associate more elements with a greater defense in depth and assume higher levels of protection. As with the measures that their application platform provides, these additional systems are only as good as the processes and people responsible for installing, configuring, monitoring, and integrating these systems holistically into the architecture. Lastly, given the special place in an enterprise that these applications have, there is a good chance that various stakeholders have the wrong solutions in place to protect against the form of attacks that we will be testing against. We must endeavor to both assess the target and educate the customer.

Standard defensive elements

So, what elements of the system fit in here? The following figure shows the most common elements involved in a web application’s path, relative to a 3-tier design:

Most serious web applications hide behind defenses to stymie our efforts, but sometimes security elements are only as good as their latest patch, configuration, and the operators using them.

The key external elements in a typical web application’s defense are:

• Firewall (FW): The first element focused on security is usually a perimeter or the internet Edge firewall that is responsible for enforcing a wide variety of access controls and policies to reduce the overall attack surface of the enterprise, web applications included. Recent advances in the firewall market have seen the firewall become a Next Generation Firewall (NGFW) where these policies are no longer defined by strict source and destination port and IP Address pairs, but in contextual fashion, incorporating more human-readable elements such as the users or groups in the conversation, the geographic location, reputation, or category of the external participant, and the application or purpose of the conversation.
• Load Balancer: Many scaled designs rely on load balancers to provide the seamless assignment of workloads to a bank of web servers. While this is done to enable an application to reach more users, this function often corresponds with some proxy-like functions that can obscure the actual web tier resources from the prying eyes of the hacker. Some load balancer solutions also include security-focused services in addition to their virtual IP or reverse proxy functions.  Functionally, they may include the web application firewall functions.  Load balancers can also be important in helping to provide Distributed Denial of Service (DDoS) protection spreading, diverting, or absorbing malicious traffic loads.
• Web Application Firewall (WAF): WAFs provide application-layer inspection and prevention of attacks to ensure that many of the exploits that we will attempt in this book are either impossible or difficult to carry out. These firewalls differ from the network firewall at the perimeter in that they are only inspecting the HTTP/HTTPS flows for attacks. WAFs tend to be very signature-dependent and must be combined with other defense solutions to provide coverage of other vectors.

Additional layers

Not shown in the preceding diagram are additional defensive measures that may run as features on the firewalls or independently at one or more stages of the environment. Various vendors market these solutions in a wide variety of market categories and capability sets. While the branding may vary, they fall into a couple of major categories:

• Intrusion Detection/Prevention Systems (IDS/IPS): These key elements provide deep packet inspection capabilities to enterprises to detect both atomic and pattern-based (anomaly) threats. In a classic implementation, these offer little value to web applications given that they lack the insight into the various manipulations of the seemingly valid payloads that hackers will use to initiate common web application attacks. Next-Generation IPS (NGIPS) may offer more protection from certain threats, in that they not only process classic IDS/IPS algorithms, but combine context and rolling baselines to identify abnormal transactions or interactions. These tools may also be integrated within the network firewall or between tiers of the environment. Newer NGIPS technologies may have the ability to detect common web vulnerabilities, and these tools have shown tremendous value in protecting target systems that use un-patched or otherwise misconfigured software modules. Cisco sells Firepower NGIPS, but other makers include Intel/McAfee, HP, IBM, and Checkpoint.
• Network Behavioral Analysis (NBA): These tools leverage metadata from network elements to see trends and identify abnormal behavior. Information gleaned from Syslogs, and flow feeds (Neflow/IPFIX, sFlow, jFlow, NSEL, and so on) won’t provide the same deep packet information that an IPS can glean, but the trends and patterns gleaned from the many streams through a network can tip operators off to an illicit escalation of credentials. In web applications, more egregious privilege attacks maybe identified by NBA tools, along with file and directory scraping attacks.
• DDoS Protection and Cloud-Based Defenses: While load-balancers, NGFWs, and WAFs can all assist in preventing DDoS attacks locally, there are DDoS specific mitigation approaches like those offered by Radware and Arbor Networks. For volumetric attacks, there is really no substitute for what service providers (SPs) can offer, either natively or together with companies like Akamai, Google, or Cloudflare. Extremely large volumetric attacks can only be successfully mitigated in the cloud if anywhere, and even then you might lose your sponsoring provider (for an impressive example, see how DDoS even hit Brian Krebs’ site )

All of the components mentioned can be implemented in a multitude of form factors: from various physical appliance types to virtual machines to cloud offerings. More sophisticated web applications will often employ multiple layers differentially to provide greater resilience against attacks, as well as to provide overarching functions for a geographically disperse arrangement of hosting sites. A company may have 10 locations, for example, that are globally load-balanced to serve customers.  In this situation, cloud-based load balancers, WAFs, and firewalls may provide the first tier of defense, while each data center may have additional layers serving not only local web application protection but also other critical services specific to that site.

The combinations are limitless, but keep in mind that, as the complexity of the security solutions deployed ratchets up, so does the likelihood that they are misconfigured. As a defender, we know the users are often the weakest link. As attackers or pen testers? We’re counting on it 😉