An overview of application security (AppSec)

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

Image #1 Bungee Jumping

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?

Image #2. Security in details

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

Image #3. Feature / Security defects

Introduction to Application Security

  • 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
Image #4. CIA Triad

Authentication & Authorization

STRIDE

Image #5. STRIDE model of thread

Vulnerability & Exploits

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.

Image #6. Vulnerability & Exploits

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

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.

Image #7 OWASP 2017 vs 2021

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

Broken Access Control

  • 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

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

Defensive Design Principles

  • 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
  1. 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:

Image #8. Securing the weakest link

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

Image #9. Defense in depth

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

Fail secure & 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

1. Input Validation

Image #10. Input Validation

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)

3. File Uploading

4. Injection attacks

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

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

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!

--

--

Sr. Security software engineer working in the DevSecOps area. CompTIA Sec+, C|EH

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Josué Carvajal

Sr. Security software engineer working in the DevSecOps area. CompTIA Sec+, C|EH