An overview of application security (AppSec)

11 min readJan 11, 2022

Welcome to this brief overview to the application security, the objective is to attract developers who are interesting in developing secure apps and start their own road writing better and secure code. All the content here was learned in a training that I received a few months ago and also experience that I’ve been earning for the past years, and I wanted to share what I’ve learned.

A real life example

Before starting with this article, let’s put a real life example: Have you ever bungee jump? Depending on your answer Why and why not? Probably you did it for adventure, risk appetite or maybe you don't due to vertigo, or fear.

But there are also other IoC that we need to take care, and those are around the risk of a safety breach, what about the belt, material and the hook security? Is everything in place?

Thread modeling is like this example, in which we decomposed the different parts of possible failure, did a quick safety check and risk mitigation. Thread modeling is an approach for analyzing the security perspective in order to identify and quantify risks. Unfortunately some of the developers do not care about the security risks associated while developing a new system, or in this case a person that does bungee jumping.

Do we write code that is secure?

“There is little evidence of improvement in the security features of most products; developers are not devoting sufficient effort to apply lessons learned about the sources of vulnerabilities…”-
Richard Pethia , CERT testimony before US congress

With the quote above and taking a look to the release notes of all the updates that we receives in our software products, we can see that almost all of them contains a small amount of feature fixes and a lot of security related fixes! The most recent issue discovered was the Log4Shell, a 10 out of 10 vulnerability that made us run to patch our systems before Christmas, here is a good video to learn how it appeared: https://www.youtube.com/watch?v=w2F67LbEtnk

Introduction to Application Security

Application security is highly related with security, so the main goal is to protect and preserve the confidentiality, integrity and availability of our data. This is called the CIA triad in all the books that you might read. But here are the details:

Confidentiality: Data is accessible only for the authorized users
Integrity: Data will remain unaltered by unauthorized parties during all the states of the data
Availability: Ensure that the information is always available by the authorized parties

Authentication & Authorization

Sometimes when talking about security there is a question that comes on mind is: Are authentication and authorization the same thing? Well, no. Authentication refers to who you are and authorization what you can do in a system. So there is not authorization without authentication in the beginning, this is important since in the OWASP TOP 10 from 2021 the Broken Access Control referred to this.

STRIDE

The STRIDE model was developed by Microsoft, and shows the different threads and how it affects the security property, For example, Spoofing identity affects the authentication since we are allowing an individual to pretend to be another person, therefore affecting Confidentiality as well of our CIA triad.

Vulnerability & Exploits

If I ask for a real life example of what is a vulnerability and Exploit, what comes to your mind? Here is my example: Image that a farmer has a lot of cows, and he has been having issues with cows that are lost, he does not know if they are being robbed or killed by a predator during nights.

So the farmer decides to used electric fence across all the farm to avoid the cows to run away or to be eaten by a the predator. This looks like a good measure to secure that the cows will not leave, and will also avoid the wolf to enter the farm or the robbers to easily extract them.

The farmer is happy because looks like now all his cows are safe… but a few months later, he sees a dead cow in the farm, after reviewing what occurred (since everything was normal) he noticed that the electric power station that fed the electric wires was not working, therefore the predator was able to enter without any problem.

So, a vulnerability refers to a weakness (electricity was gone) in an application (electric fence) which can be exploited by a Thread Actor (predator) to perform unauthorized actions, and an exploit is a piece of software especially crafted to take advantage of that vulnerability.

OWASP top 10

This is the bible of all the security engineers working in application security,

The Open Web Application Security Project or OWASP meants to improve the security of software. OWASP operates under an ‘open community’ model, where anyone can participate in and contribute to projects, synapsys

As the quote mentioned, it helps to improve the security of software by ranking the most common (TOP 10) Application security vulnerabilities.

We have been using the OWASP 2017, but the last year the rank was reordered on priority and now the most common security vulnerability in our applications are the Broken Access Control.

Here are the TOP 3 of the TOP 10 vulnerabilities from the OWASP page.

Broken Access Control

Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user’s limits. Common access control vulnerabilities include:

Violation of the principle of least privilege, where access should only be granted for particular capabilities, roles, or users, but is available to anyone.
Bypassing access control checks by modifying the URL (parameter tampering or force browsing).
Elevation of privilege. Acting as a user without being logged in or acting as an admin when logged in as a user.

Cryptographic Failures

This one leads to the exposure of sensitive data due to the failures in the implementation, the first thing is to determine the protection needed for the data in transit and at rest. For example, Credit card numbers and passwords, health records and if we are holding EU criticizing PII (personal Identifiable Information) may be under a regulation such as PCI DSS, HIPPA or GDPR.

For all such data:

Is any data transmitted in clear text?
Are any old or weak cryptographic algorithms or protocols used either by default or in older code?
Are default crypto keys in use, weak crypto keys generated or re-used, or is proper key management or rotation missing? Are crypto keys checked into source code repositories?
Is encryption not enforced, e.g., are any HTTP headers (browser) security directives or headers missing?

Zero Day Vulnerabilities

A zero day vulnerability is a vulnerability in a system or device that has been disclosed but is not yet patched, therefore the risk is critical since we cannot guarantee the uptime and security of our systems. An exploit that attacks a zero day vulnerability is called a zero day exploit. Some examples of zero day vulnerabilities are: HeartBleed, CloudBleed, Zerologon

Defensive Design Principles

There are 12 defensive design principles, each of them will help us to secure our applications while auditing, here is the list, we are going to review in detail a few of them:

Secure the weakest links
Defense in depth
Fail Secure
Grant least Privilege
Economize mechanism
Authenticate requests
Control access
Assume secrets not safe
Make security usable
Promote Privacy
Audit and monitor
Proportionality principle

Secure the weakest links

Security can be visualized as a chain, the strength of the chain is as
good as the weakest link, a practical example is when a system allows multiple SSL versions, it can be visualized as follows:

Here the attacker will go for SSL 2.0 which is the weakest link. Comparing with real life scenario: A bank robbery in the night would not happen using the secured main gate but using the windows / back door upstairs.

2. Defense in depth

Defense in depth refers to not fall in only one security method, for example: Just an antivirus will not keep you safe for other more powerful malware, you may need more protection. That is why defense in depth is presented like an onion, in which we secure from the upper layers (end users) to the core business part (devices and servers)

A real life example could be a bank, there are cameras, security guards, glass door, vault to protect items. As same as we take care of the physical security the software security must be implement as well.

3. Grant Least Privilege

The Principle of Least Privilege states that a subject should be given
only those privileges needed for it to complete its task. When we restrict the code to do limited system wide actions, a vulnerability in the code cannot be used to exploit the rest of the system and leading to a privilege escalation and pivoting by the thread actor.

4. Audit & Monitor

There is a security framework called AAA (Authorization, Authentication, Accountability) in which Accountability means the ability to record what action took place, who performed, when and potentially how an specific action was performed

Defense in depth vs Secure the weakest link

Can the defense in depth and the secure the weakest link be contradictory? The short answer is no, defense in depth add more redundancy in the security while the weakest link principle does not have overlapping functionality.

Fail secure & Fail Safe

Failure is unavoidable but it must be planed, because, What happens when our application crash? Are our security measures down? Is the data exposed in error messages? How our application behaves? These are some of the questions that we need to answer when developing apps, but all of them comes to a set of concepts called Fail Secure and Fail Safe.

To identify if fail safe/secure is used, it will depend from system to system. For example: Imagine that there is a fire in the building, Fail secure refers to block the access to all the doors, meanwhile fail safe refers if there is a fire in building to disable all the door access to avoid human lost.

In the last example fail secure might not be an option since human life are part of the equation, but it will depend which kind of system you are dealing with. But remember, when dealing with data, we must guarantee the confidentially, integrity and availability even though the system is lost

Mitigating (some) Common vulnerabilities

When working in security we must apply the zero trust concept, in this case, if we send a request from the web browser, we should never trust the user input and perform the proper validations and also, if this front end validation is bypassed do a second validation at back-end to make sure we are also applying the defense in depth.

1. Input Validation

An input is anything that probably will be sent to our back end of our application and might reach the database, for example: If we have a quantity numeric input, we should not allow especial characters, words, we also must validate the type of input (integer, double,float) and ranges, min-max, length, etc. Following the quantity field example, what you consider that is wrong in this code?

Here we are trusting the parameter that the user is entering in the quantity field, we are not doing any validation regarding especial chars or strings, so this example can be easily breakable.

2. Regular Expressions (Evil Regex)

Some especial crafted regex can be used to cause a ReDos (Regex Denial of service) in our application, we can use SDL Regex Fuzzer from Microsoft to check if an specific regex is evil or not. Here is a good place to learn about ReDOS

3. File Uploading

Usually when a web application allows to upload files, there are several ways to identify which kind of patterns are allowed or not, this is a high security risk if not limited since can lead to LFI (you can learn more of it in my other article of Local File Inclusion) or RFI. So we must allow only the extension of the files that we want to handle and avoid the web server to read outside the target directory

4. Injection attacks

There are different types of injection: SQL Injection, XML Injection, OS Command Injection, LDAP Injection. Here we are going to take a look to the SQL injection.

4.1 SQL Injection

Occurs when an attack is performed to a data-driven applications in which nefarious SQL statements are inserted to alter the data or read data that they are not allowed to do. Occurs when developers concatenate a fragment of SQL statement with user provided text, for example, here we are getting from the URL the value of UserId, and passing that directly to the SQL clause,

txtUserId = getRequestString(“UserId”);
txtSQL = “SELECT * FROM Users WHERE UserId = “ + txtUserId;

This will lead to a parameter change in which we can pass crafted values.

https://myapp.com/secureApp/view?UserId=’ OR 1'1=’1' —

How to defend against SQL Injection? Always use parameterized queries (Prepared statements) and also do an input validation before passing those! Other ways such as allow-list, stored procedures are considered weak.

5. Authentication

If an user is trying to access to our applications how are we going to allow them? Maybe with credentials (Username and password) if they are valid we continue if not, how many attempts are we going to allow? And in how many attempts are we going to show a captcha to avoid a brute force attack? What are the rules that we are going to use to store the password? Maybe a random salted password or also a 2FA?

As you can see a lot of questions are raised when dealing with authentication but we need to know that all the passwords must be a good length maybe 64 chars due to some limitations of hashing algorithms, any of the 3 factor authentication must be applied, Something you know like a password, Something you have like a token, Something you are like a fingerprint.

6. Saving passwords

Passwords cannot be in plain text, there are different ways of securing passwords in our systems. One of them is using SALTED HASH PASSWORDS, which basically means to add a random generated value to the user password to create a completely different HASH, therefore making harder to the attackers to steal common passwords. Other way of doing it is to use not only hashing but also encryption.

There are a lot of vulnerabilities / bad practices that are done in almost all the software, I have left behind XSS, Cryptographic weakness since this post has become a little bit larger than expected, but I’ll be adding more detailed info of that content if you deserve it

Thanks for reading!