Application Threats - Privacy for the World

Common Threats

Threats, attacks and breaches will not cease anytime soon and no application will ever be 100% safe. However, there are things that developers and security professionals can do to decrease the attack surface.

#1 Outdated Software, Libraries or Components

When software, libraries, binaries or any other component becomes outdated or end-of-life, it becomes susceptible to malicious attacks. Newer patches may contain security updates – so do not wait too long to update your application. With that in mind, the latest update may contain ‘zero days’ or vulnerabilities newly discovered without fixes available.

So how long is too long to wait until patching? Well, the answer is subjective but I would recommend updating no later than 30 days post patch release. Read the release notes to see if there are any significant fixes. If it is simply an update on existing/new features, use judgement on whether or not to apply the new patch. Likewise, if there is a significant vulnerability or set of threats that the patch fixes (one under current exploitation), do not wait longer than 7 days.

#2 Security Misconfiguration

Capital One experienced a significant breach of data in 2019 due to a misconfigured open-source Web Application Firewall (WAF) that they were using as part of its operations hosted in AWS. Security misconfigurations are common and are typically a result of human error. Some examples of a misconfiguration include:

Debugging enabled
Incorrect permissions
Using default settings
Accessible pages that should not be

Security misconfigurations rise when security settings are not defined, implemented, and default values are set.

What can we do to fix this?

It’s true that ‘security misconfigurations’ includes a big bucket of items. Vulnerability assessments, penetration tests (more than just once) and continuous monitoring will increase early detection. Prior to deployment or release, a development/test environment that mirrors the production set up should undergo rigorous testing. It is good practice for testing to be done by someone outside the organization with an understanding of how the infrastructure is set up (white box test). A hacker with time and resources can spend months looking at your application whereas a penetration tester only has days. Giving them the details of the application and architecture will greatly reduce their time trying to figure it out themselves, thus, getting the most out of your money.

Threat Modeling

Another action that a company may take into consideration is Threat Modeling. Threat Modeling is done early in the Software Development Lifecycle (SDLC) to review vulnerabilities with the architecture and design of the system. This can show flaws with the design even before coding starts.

Also, be sure to review permissions and roles. OWASP states that companies should set “a task to review and update the configurations appropriate to all security notes… In particular, review cloud storage permissions (e.g. S3 bucket permissions).” It may be beneficial to come up with consistent baselines that are deployed across all applications but make sure that they undergo testing before use! Untested configuration baselines may result in vulnerabilities propagating across all assets that share the same baseline.

Security Headers

Finally, another mechanism that can help with mitigating attacks and threats comes toward the end of development – Security Headers. Headers can be managed at the server level or in the WAF. If you are using WordPress there are easy to use plugins available. For technical details on how to set these, click here. Additionally, users often think they need a penetration tester to verify security headers – just check your posture on securityheaders.com (it’s free!).

#3 Injection Threats

Currently #1 on the OWASP top 10 for the most exploited threat. There are several types of code injections to watch out for: SQL, code, LDAP, OS commands and cross-site scripting. All of these threats can be mitigated with data sanitization in conjunction with security headers (mentioned in #2) and a WAF for added defense in depth (layered security).

How do you exactly do this magical code ‘Data Sanitization?’

SQL Tips

Use stored procedures as a layer of defense, but not as a catch-all. Stored procedures can be valuable for data sanitization efforts but will not completely mitigate an injection attack, especially if you are using a dynamic SQL statements.
NULL – Ensure that stored procedures do not provide a default and that a specific logic path is taken when a NULL is explicitly provided for a field that should always include a value.
Blank/Empty strings – avoid these using the same tactic as above.

Operating System (OS) Commands Tips

The OWASP cheat sheet recommends white listing Regular Expressions. An explicitly defined whitelist of good characters allowed including the maximum length of the string. Ensure that characters like & | ; $ > < \ \ !` and white-spaces are not part of the Regular Expression. They also recommend ensuring the length is no longer than 3-10 characters:
^[a-z0-9]{3,10}$

PHP Tips

htmlspecialchars() supplied with no arguments will convert special characters to HTML. However, if you do not use this in conjunction with the ENT_QUOTES command, you will still be vulnerable because the htmlspecialchars() does not include single quotes.
addslashes() can escape input when inserted into JavaScript variables.
Per OWASP, “HTML entity encoding doesn’t work if you’re putting untrusted data inside a tag anywhere, or an event handler attribute like onmouseover, or inside CSS, or in a URL. So even if you use an HTML entity encoding method everywhere, you are still most likely vulnerable to XSS. You MUST use the encode syntax for the part of the HTML document you’re putting untrusted data into</p>”

Brute Force

At one point or another your application will likely go through several brute force attempts. These attacks are easy to do and quite common. There are several ways to protect yourself from these types of attacks:

2FA/MFA – Set up and use two factor authentication or multifactor authentication. Ensure that they also go through a pen test as it’s still possible to bypass these methods.
Use a complex password.
Account lock outs
Set up monitoring and event logging to track if any are successful and for data analytic purposes.
Use a Web Application Firewall
Use a strong Encryption, do not use custom crypto.

For more information on Brute force attack types and prevention – click here.

These are just a few of the many threats to applications, this page is in progress and will to include more details. If you would like to add to this page or see anything incorrect, please feel free to contact me – see the about page.

Other References for Threats

About