Applied Web Application Security - 2019 Catastroph...

former_member609629 · ‎05-03-2019

Truth is, web application security today is very complex. Everyone understands that it’s important, but very few developers actually understand threats in-depth, not to mention the solutions.

I don’t want you to wake up one day only to discover your site has been hacked. So, I put together this article in an effort to make you pay attention to current attack vectors landscape and curb your expectations.

Why Are Data Breaches and Hacks Getting More Common?

Big companies, who can afford to hire the most intelligent security experts, still seem to be affected by breaches on a regular basis.

It seems like every week, there’s a new story of customer information being compromised. These are just some relatively recent hacks:

Equifax was hacked, with the CEO blaming it on “human error”

More than 2 million credit cards from Earl Enterprises (who owns multiple restaurant chains) customers were compromised. Malware was put on point-of-sale (POS) systems to gather this data

Over 3 million Toyota customer records were stolen when a vulnerability at Toyota dealers was exploited

Houzz was hacked to expose private user account information

Chipotle had a data breach back in 2017, and then again in 2019

(and my personal favorite from just the other day) Docker Hub Breach Allowed Attackers to Steal Private VCS keys and Tokens

Different attack methods were used in most of these breaches and hacks.

Why does this happen?

And even if you know, can you do anything about it - if even the largest corporations can’t?

Security field experts are quick to point out that software is used in more and more parts of business. Automation is really only starting to grow, and as machine learning takes off, software is only going to be more vital for businesses.

More code equals more vulnerabilities. The quantity gives potential hackers more opportunities to find a hole.

On top of that, software is getting more and more complicated. It’s rare for a single developer to understand all parts of a codebase they’re working on. Instead, you typically work on a small part in or particular feature branch.

One developer/sysadmin/devops may introduce new vulnerabilities based on interactions with legacy code that they don’t understand.

For instance, understand that every developer, at some point, has copied a snippet of code from Stack Overflow without fully understanding it. In some situations, it could be code for an important process or module that becomes outdated, has security flaws or is easily exploited to wreak havoc on the application or server side.

In many cases, all it really takes is for an attacker to take an interest in an application and focus on finding its vulnerabilities. Amazing example of this approach is how a hosting reviews team hacked the world, a proof of how easy it is for a skilled professional to exploit vulnerability found in services used by many today and which are expected to be as safe as possible since they're handling a lot of sensitive data of huge number of companies and individuals.

This may be seen as a bit of a rant, because there’s literally no solution on sight and this current situation is becoming increasingly frustrating, especially for new business ventures. Your best bet is to do your best to patch obvious security threats and stay off the attackers’ radar as much as humanly possible.

Attackers look for a combination of easy targets and high value rewards (i.e. sensitive data). So, while it’s unlikely your application will be hack-proof, as long as you are a harder target than most others, there’s a high chance you’ll be safe.

The Most Common Types of Vulnerabilities

It makes the most sense to focus on securing the most common types of security flaws that attackers go after.

Imperva tracks how common different vulnerabilities are each year.

Recently, certain types of vulnerabilities have become a bigger threat to security:

SQL Injection: A hacker inserts SQL code on the front-end of your application to extract/alter private data in a back-end database. Mainly occurs when user input is not properly sanitized. (asking why? - human error)

Cross-site scripting (XSS😞 The classic attack that is still around where a hacker inserts a client-side script into your website for a visitor (who typically clicks on a malicious link in an email), which can then access or modify their account. (asking why? - human error)

Data exposure: Not protecting sensitive data like passwords or payment data correctly is more common than it should be, even though it’s almost always accidental. (asking why? - human error)

Third party vulnerabilities: Most applications use third-party software that they don’t fully understand. That’s pretty unavoidable, but not updating third-party software when they patch security holes is a common issue (looking at you, WordPress plugins with external library dependencies).

If you don’t have a solid understanding of those four types of vulnerabilities, spend some time reading about them in-depth to get a clear picture and ensure your developers do to.

Once you do, let's check some testing methods to reveal potential vulnerabilities, and figure out how to best fix them.

The Three Types of Web Application Security Testing

There are three main ways you can test your web application. Ideally, you should use a combination of methods:

Static application security testing (SAST): SAST is a type of white-box testing, as the source code is directly inspected for potential vulnerabilities. Extensive list of popular SASTs of which some are considered a part of an industry standard toolkit: https://www.softwaretestinghelp.com/tools/top-40-static-code-analysis-tools/

Dynamic application security testing (DAST😞 The black-box counterpart to SAST. DAST doesn’t require access to source code, but does require a working application to test. It focuses on finding vulnerabilities that an attacker could exploit from the outside. I recommend checking this list of 10 most popular DASTs: https://hackr.io/blog/top-10-open-source-security-testing-tools-for-web-applications

Application penetration testing: This approach involves hiring a security professional to act as an attacker. They will use a variety of methods to try and compromise your security to identify any important issues. I consider this 19 pen-test tools resource of great use for my client's developers: https://www.softwaretestinghelp.com/penetration-testing-tools/

Tools for SAST and DAST are great for picking up some of the most common vulnerabilities like SQL injection and XSS.

In order for testing to be effective, it should be done prior to deployment of a build if possible, not after as in case of a lot of DevOps teams or individuals. Also, it should not be a one time event, rather continual, mandatory procedural part of a CI/CD pipeline if possible.

Simple (But Effective) Web Application Security Checklist

Security testing comes after building.

If you build your application with security in mind, your security testing will hopefully find minimal flaws that an attacker could exploit.

Use the elements in this section to create a personalized checklist of security items that need to be addressed for your application. Some may not be necessary depending on your specific application or development team but here they are:

Implement a WAF. Web application firewalls should filter incoming traffic and they can protect your application in various ways, like refusing requests with malformed URLs containing weird characters or strings. They are relatively easy to set-up on all common servers like Apache and Nginx or implement them on edge, on your CDN like Cloudflare or Incapsula to minimize performance impact and operational complexity.

Implement HTTPS. There is no excuse to still be using plain HTTP. It doesn’t take long to set-up HTTPS and redirect all HTTP traffic to it, and it’s not expensive either, it's free these days actually (think Let's Encrypt). This will help protect users from accidentally exposing credentials to attackers.

Add the X-XSS-Protection header. It’s one line of code on Apache or Nginx, but the X-XSS-Protection can go a long way to protecting against XSS attacks. All major browsers are compatible with this header, and it will block suspicious scripts for users.

Add the Content Security Policy (CSP) header. This header protects against clickjacking and XSS attacks, and again takes very little time to add. Not all browsers support it yet, but all modern versions of popular ones do.

Identify entry points. It’s a good idea to keep a running list of all the areas that users can input data that can interact with your database(s). Anything from login forms to search bars could be entry points for attackers.

Sanitize user input. If you’re not using a major web framework that sanitizes user input for you (e.g. Django or Laravel), you need to sanitize user input yourself to combat SQL injection attacks. At a basic level, this involves removing tags and special characters (e.g., <, &, %) from user input to prevent attacker sending an SQL query to your backend via browser's address bar with URL containing parameters of the query.

Use two-factor authentication. If your application is popular enough and users store any potentially sensitive data, it’s worth implementing two-factor authentication to protect users. Yes, majority of technically illiterate users will find this a nuisance but security isn't meant to be convenient.

Encrypt all sensitive data. All passwords and payment details should be encrypted. There’s no excuse for storing sensitive data as plain text. Hashing and salting are industry standards in sensitive data storage strategy.

Assign permissions carefully. Every device that can access your application should have its own permissions set, even if it’s just you working on it. Limiting permissions reduces the chance that anyone accidentally creates security vulnerabilities. Say you have several devops and sysadmin people working on infrastructure, each one of them should have their own SSH key instead of sharing the single one so if one is compromised or replaced, it's easily removed from the equation.

Conduct security training. If you have a team working on your application and they don’t all have a background in security, educate them, in a long run this comes much cheaper than doing damage control after breach happens and losing users. Limiting permissions by enforcing the least-privilege system is a good start to prevent potential security issues, but ideally you need to teach team how to work safely first.

Create regular (encrypted) backups. For reasons other than security as well, all applications should be backed up on a regular basis. This won’t protect you from a hack initially, but it will make recovery easier. Additionally, enforce encrypted backups of limited expiry date, for instance 30 days should be good starting point for majority of SaaS projects. This is also covered by GDPR law where users should know how their private data is stored, for how long, where and in what way.

Consider a bounty program. This one is amazing concept. Some companies offer “bounties” to white-hat hackers, challenging them to try to find vulnerabilities in their security and report them (similar to penetration testing). This is probably overkill for a new or small application, but is worth considering if you have a bigger one or one which operates in personally impactful industry such as finance.

If you do all or most of those correctly, your application should be much more secure than the average application out there.

Will Your Application Be Unhackable?

Now the reality check!

You can definitely make some parts of your application free of security vulnerabilities.

However, most still have involve human interaction, and humans, even with the best of intentions, still make mistakes and are terribly inefficient in a lot of processes.

As we’ve seen, even large companies that have whole teams of security experts still get hacked on a regular basis, usually due to human error somewhere along the way.

But perfection isn’t needed to have peace of mind.

If you test often and proactively address security flaws, your application won’t be an easy target for hackers. In most cases, this will keep you off the hackers’ radar, and it’s unlikely that anyone will ever try to seriously compromise your application but the biggest pill to swallow is rise of DevOps culture, CI/CD methods and fact that our applications aren't managed, secured and ultimately owned by us anymore, rather container image repository services which are susceptible to hacks as well as we could see from latest headlines where Docker Hub got hacked and attacker gained access to sensitive data of 190K users so application images, often proprietary in nature are possibly obtained by the attacker who now has insight in their inner workings, entire codebase sources and whatnot.

To conclude, as a human, I hate being pessimistic but as sysadmin and DevOps guy, being pessimistic, not trusting anyone or anything by default and having grim look at the world is often a company's lifeline when it comes to security.