Cybersecurity (a.k.a. Information Security) is an overly generalized term for a field securing digital infrastructure, applications, or services. The goal of a cybersecurity program is to identify, categorize, and prioritize risk within an organization. These risks are then remediated in an effort to reduce the likelihood of a successful attack by a bad actor.
Application Security is a sub-category of cybersecurity that focuses on identifying and correcting insecure code or vulnerabilities in software developed within an organization. Unlike applications purchased through vendors or open source software, the security of a custom application is the responsibility of the creator.
Application security describes security measures at the application level that aim to prevent data or code within the app from being stolen or hijacked. It encompasses the security considerations that happen during application development and design, but it also involves systems and approaches to protect apps after they get deployed.
Table Of Contents
My software security journey has been enlightening, to say the least. I quickly realized my understanding of the cybersecurity field was severely limited and it encompasses far more than I could have imagined. The vastness is intimidating, and when you begin to understand the scope of the threat landscape it is difficult to know where to start.
This series is intended to help the reader learn about application security in a practical way. I will be covering the OWASP Top 10, and other common vulnerabilities, as well as how to identify and remediate them. I will also cover some of the more common threats to applications. My goal is to help you (the reader) understand how to identify and remediate vulnerabilities in your applications without having to be an expert in the field or go through a lengthy process of trial and error.
It is important that, while you are learning about application security, you give yourself grace. You are not expected to be an expert in the field and you are not expected to know everything about application security.
Focus on learning the basics and then build on that knowledge. You will continue to learn new things as you go and you will continue to make mistakes. I have personally made many of these mistakes, and I am still learning new things every day. The important thing is to keep learning and keep trying.
I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain.
― Frank Herbert, Dune
There are many incalculable consequences of poor security. The most obvious consequence is the loss of data. This can be financial data, customer data, or even intellectual property. The loss of data can be devastating to an organization.
- Loss of Life12
- Loss of Privacy3
- Loss of Freedom4
- Loss of Sensitive Data
- Loss of Intellectual Property
- Loss of Customer Trust
- Loss of Revenue
- Loss of Reputation
- Loss of Employment
Responsible disclosure is a process that allows security researchers to safely report found vulnerabilities to your team.
What is Responsible Disclosure? - bugcrowd
It is important that if you discover a vulnerability in an application you report it to the appropriate team. This is called responsible disclosure5 and is a critical part of the security process. If you do not report a vulnerability to the appropriate team then you are putting yourself, your organization, and the organization that owns the application along with the users of the application at substantial risk.
Generally, you can identify the appropriate team by looking at the company
website or Github page under the “Security Policy”
section. If you cannot find a security policy then you can contact the
company directly through their corporate phone number or private message
on social media. Usually the security team will have a dedicated email address
for reporting vulnerabilities, likely
To better understand the threats an application faces we must first understand the mindset of each actor involved in securing or attacking an application. Attempting to understand a persona different from your own can be uncomfortable or confusing but the motivations of each can provide insight for improving the security of your application.
If you know the enemy and know yourself, you need not fear the result of a hundred battles.
The Art of War, Sun Tzu
A builder defines their work as the creation of software, or the creation of software to secure other software. If you are a software engineer or part of a blue team then you likely fall into the “Builder” persona. A builder within security is someone with a goal of building secure and fault-tolerant software.
In similar fashion, a builder may have a lot in common with members of a blue team focusing on the security of an application during development and the processes that are in place to ensure that the application is secure.
Secure coding is the first line of defense against attackers. The closer one is to the keyboard when a vulnerability is fixed, the fewer people will be affected by breaches and the less damage will be done.
The number of breaches is increasing as are the consequences. The average cost of a data breach in the United States is $9.4 million dollars and globally it is $4.35 million dollars.6
It is important that we learn7 from these breaches for the sake of our users and our companies.
A destroyer defines their work by “breaking” software or systems through purposeful misuse or malicious intent to cause unintended side effects in an application. If you are a quality assurance engineer then you likely fall into the “Destroyer” persona.
Most modern QA work entails a form of destructive testing (a.k.a. negative path testing) revealing flaws or faults in an application. The same mentality is used in security by bad actors to identify ways of crashing applications or otherwise disrupting operations through destructive actions.
A differentiator for a malicious destroyer, however, is that they will perform destructive actions with the intent of causing harm to the application or organization. They are not subtle in their actions and will often leave evidence of their actions in the form of logs, missing data, or other evidence of their actions. A prime example of a malicious action performed by a destroyer is leveraging a SQL injection vulnerability to delete all of the data in a database.
Depending on motivations, a destroyer may target an organization with the goal of bringing services down through the use of a DDoS (distributed denial of service attack) such as Slowloris8.
An alternative (and potentially more damaging) approach using DDoS, meant to financially hobble9, is to create enough traffic on an organizations infrastructure to cause uncontrolled auto-scaling in a cloud environment (like AWS or Azure).
Ransomware10 is another form of attack common among the destroyer persona. These attackers encrypt the entirety of a system, any attached systems, and backup locations thereby holding the target’s files as ransom. These attackers then tell the victim that unless they pay a fee (likely in bitcoin) the files will be lost forever.
In most cases the files are lost regardless of whether the victim pays the fee or not. Ransomware attacks are increasing year over year, and do not only target large organizations11 (through successful phishing, or social engineering attacks) but also small business12 and home users through embedding in malware.
The damages for 2018 were predicted to reach $8 billion, for 2019 the figure was $11.5 billion, and in 2021 it was $20 billion — which is 57X more than it was in 2015.
The corrupter is a different breed to the destroyer. While the destroyer is focused on breaking the application the corrupter is focused on changing the application to do something that it was not intended to do. A good example of this would be using a cross site scripting (XSS) vulnerability to steal a user’s session cookie and then use that cookie to impersonate the user.
Social engineering, open source intelligence (OSINT), and spear-phishing are common methods used by the corrupter to gain access to a system. Once access is gained the corrupter will attempt to find vulnerabilities in the system and then use those vulnerabilities to gain access to other systems (i.e. lateral movement or pivoting).
The corrupter spends more time within the application than the destroyer and is more likely driven by data exfiltration, monetary gain, or political motivation. These motivations also mean that the corrupter is more likely to attempt to hide their actions and remain undetected.
- Supply Chain Attacks
- Cross Site Scripting
- Cross Site Request Forgery
- Server Side Request Forgery
- Arbitrary Redirect
- Non-Destructive SQL Injection
Throughout the remainder of this series we will be discussing many vulnerabilities an attacker might use and how to prevent them from being exploited.
If you are an engineer or developer, you can prevent these vulnerabilities from being exploited by identifying and fixing them before they are released. The responsibility for security is not solely that of the developer but is shared with the security team and leadership.
If you are a manager, cultivate a health security culture within your team or organization. Security breaches cost money, time, and reputation. You can help prevent breaches by ensuring your team has the tools, training, and resources they need to identify and fix security issues quickly and effectively.