How hyper scalers handle top 10 OWASP web attacks
In this security post, I will cover the tops 10 OWASP common web attacks and how hyper scalers provide services to protect your business using
web app security, WAF and app load balancers, denial of service attacks, and web app safeguards. So let’s get started by talking about web application security. OWASP org publishes a top 10 list of the most common web application attacks:
1. Broken access control, which means that attackers are able to perform
unauthorized actions due to a lack of access control or access control breakdowns.
2. Cryptographic failures, where there’s a failure to encrypt sensitive data.
So this can happen if you have an application that encrypts sensitive data like social security numbers, but decrypts that information
and sends it to another component of your application, where it’s then re-encrypted. Because the action of decrypting the information exposes the data, and as it’s being sent in transit, it may be intercepted and read by an adversary.
3. Injection attacks involve attackers injecting malicious code into a web application database or using an attack like cross-site scripting to target the client’s browser.
4. Insecure design, centers around poorly designed web applications
that need to be re-architected.
5. Security misconfiguration, is when your web application environment
is not sufficiently hardened and may have default usernames and passwords present that an attacker can leverage to exploit your web application.
6. Vulnerable and outdated components refers to unpatched components in your web application, such as code that has known vulnerabilities.
7. Identification and authentication failures involves weaknesses in authentication, as well as poor session management. And this will allow improper authentication for attackers and users to gain unauthorized access through poor authentication.
8. Software and data integrity failures goes back to using third-party code within our web application. If we have untrusted code in our web application, it’s possible that the code repository may have become compromised and now affects our web application.
9. Security logging and monitoring failuresrefers to a lack of visibility concerning the security and performance of our web application
due to insufficient logging about user authentication and privileged actions.
10. Server-side request forgery. And this is when an attacker leverages
a trusted server to forge requests and perform malicious actions on their behalf. So in order to protect against these attacks, we primarily have a web application firewall, or WAF for short. A web application firewall provides
OSI application layer 7 defenses against some of those attacks that we described in the OWASP Top 10. This includes injection attacks, like cross-site scripting or SQL injection, and many other attacks.
Web access control lists allow you to create custom rules so that you can block some of these common OWASP attacks.
On AWS, this is known as the Web Application Firewall.
On Azure, this is known as the Application Gateway WAF,
and on GCP we have Cloud Armor where we can apply WAF rules.
Application load balancers help support application availability.
These layer 7 load balancers distribute the load and traffic flow to your web applications so that resources do not become overwhelmed.
Load balancers are important to the architecture of web applications.
On AWS, this is known as the Application Load Balancer.
While on Azure, we have the Application Gateway that provides load balancing services and on GCP, load balancing is handled by the Cloud Load Balancing Service. Denial of service attacks are attacks on the availability of our web application because they limit or prevent access
to our web application by legitimate users. Distributed denial of service attacks are a special subset of denial-of-service attacks,
and these attacks leverage amplification networks like a botnet to multiply the denial of service attack.
In distributed denial of service attack the attacker sending out a malicious command to a botnet of computers, which could be hundreds or even thousands of malware-infected computers, which could be purchased on the dark web from cyber criminals or even include legitimate hosts that have been infected by malware from the attacker. This army of hosts then sends out a bunch of traffic until they have overwhelmed their target’s resources and that target is no longer available to provide resources to legitimate users, thus taking down a web application and collapsing the availability of that web application. Cloud service providers offer unique services to prevent such an attack since the traffic flow can originate
from a variety of sources and overwhelm our cloud-based web application.
On AWS, we have AWS Shield, which a customer can utilize to identify and mitigate DDoS attacks. AWS also offers AWS Shield Advance, which provides cloud consumers access to the AWS DDoS response team,
as well as tailored protection plans that analyze normal web application traffic flow so that they can easily identify when a DDoS attack is taking place. Within Azure environment, we have Azure DDoS Protection,
which performs much of the same functionality as AWS Shield.
However, Azure’s DDoS Protection standard plan only covers the first 100 resources, and there is an additional cost for resources above that 100 thresholds. GCP Cloud Armor mitigates DDoS attacks on the GCP cloud platform. GCP consumers must leverage the Cloud Load Balancing Service
in conjunction with Cloud Armor to take advantage of DDoS protection.
There’s also the Cloud Armor Managed Protection Service, which provides customized WAF rules, as well as access to Google’s DDoS response team,
which has global insight into DDoS attacks. It is also important to note that Google has been a part of mitigating some of the largest DDoS attacks in history, that additional insight and experience is invaluable.
Here’s an example of Azure DDoS Protection working with an application gateway, which includes a VNET with Azure WAF and the application gateway load balancer. DDoS protection prevents any distributed
denial of service traffic flow from hitting the VNET, protecting
from layer 7 attacks and providing availability before that traffic is ultimately sent to our resource group that host the web applications and databases.
Web app safeguards protects the confidentiality we should always use encryption, especially as it pertains to data in transit, where we can leverage TLS encryption and certificates to protect our data.
IAM policies are particularly important as well, since we can make access controls to the various identities modifying our application as well as the services accessing our application. Since we always want to make sure
that identity is verified, we can leverage various authentication protocols to do so.
Logging and monitoring are supercritical because we need visibility to see what is going on within our application. With this visibility, we can properly monitor for malicious traffic and any unusual activity, so that our security operations team can properly investigate security incidents, as well as monitoring the health and performance of our application to ensure that availability is being supported.
To summarize, I covered the web application security, in particular the OWASP Top 10 project, which lists some of the most notorious web application risks like injection, broken access control, and security misconfiguration. Web application firewalls and load balancers and how web application firewalls can protect our applications from these OWASP Top 10 Security Risks and OSI layer 7 attacks in general.
While load balancers support the availability of application by distributing
a load of traffic hitting our web app. Denial-of-service attacks, which affects the availability of our web application. And how distributed denial-of-service attacks leverage amplification networks to overwhelm cloud resourcesand take down applications.
Join my Linkedin