Learning something entirely new is exciting and daunting at the same time. We love learning and exploring yet we are also afraid of things we do not understand. Security is an excellent example of such a topic. It seems complicated and invites exploration, yet it is so easy to make mistakes, that some would rather avoid it altogether.
Having a mental model during learning will speed up and increase the effectiveness of the process. How? First, it helps you organize the knowledge you gain by helping you chunk the information. Second, it guides your thinking by telling you how different ideas connect. These two factors result in a deeper understanding.
Macro versus Micro
You can look at the field of security from two different viewpoints. One is very high-level, where you see the complete landscape and the large scale forces that shape it. Let’s call this one macro perspective. Zooming in and getting closer to the ground you arrive at the micro level. This is where you notice the details and how different parts interact with each other. Both perspectives offer valuable insights and you need to know which one you are looking at to best absorb it. While the two views appear very different, remember, they describe the same system. It’s all here to help you better organize your knowledge.
The macro and micro perspectiveThe macro
The macro is high-level. It is theoretical and doesn’t deal with concrete implementations but the ideas that shape them. Its two main topics are concepts and constructs.
Concept
A concept is an abstract idea or principle without a concrete specification. Here are a few examples: authentication, layered defense, the state of the industry, attack models, etc. When dealing with concepts aim for understanding and accurate terminology.
Understanding
What is the concept describing? What is the central problem it tries to solve? These are the questions you need to ask yourself when encountering a new idea. These are pieces in a grand puzzle. The more of these pieces you know the clearer the overall picture. A good understanding of the whole is essential as the details you will learn later on will need to be placed in context and connected to the whole.
Terminology
Security has its jargon, and it is essential to learn a subset of it that applies to you as a developer. Encoding is not
encryption. Authentication and
authorization are two different things. You must be able to speak precisely with fellow engineers. Otherwise, it is easy to make grave mistakes.
Construct
Constructs are concrete systems and the building blocks for them. They have an explicit specification (RFC, whitepaper, etc.) and can be implemented from the ground up. This category includes items such as hashing algorithms (SHA, Whirlpool), encryption algorithms (AES, RSA), the Public Key Infrastructure, OAuth 2.0, OpenID Connect. The key is what to use them for and how to use them.
What to use it for?
Constructs solve specific problems and give you concrete assurances about what you can expect when using it. It is imperative to understand these. Unfortunately, misuse is common among security constructs. While they can perform in such a scenario, they likely have limitations.
How to use it?
Usually constructs come with instructions on how to implement them and what to watch out for. Not following these can quickly weaken the integrity of the solution. When deploying a construct, you need to know how to do so securely. If the guide says to use a random number, you must do so. If it requires a nonce, comply. Otherwise, the promises of the solution won’t hold.
Concept or construct?
The distinction is easier than you think. Think of concepts as abstract ideas or “interfaces” and constructs as implementations. Here are three examples of how these ideas connect.
- Encryption is a concept, while the AES algorithm is a construct.
- Two-factor authentication is a concept, while SMS-based 2FA and TOTP is a construct.
- Trust is a concept, while the PKI is a construct.
For more, take a look at the Glossary, it has excellent examples of both.
The micro
The micro deals with the details and hands-on practical stuff. It revolves around the idea of a vulnerability, how it can be used for some gain and what can we do about it. The three parts of the micro are interconnected and affect each other. They can be learned independently, but true understanding requires you to internalize all three.
The micro perspectiveVulnerability
Vulnerabilities are weaknesses in the application. They are well categorized, and some have uniquely identifiable names such as XSS, SQLi. You have surely met many such concepts already. When dealing with a vulnerability, you should focus on two key things: how it works and how to spot it.
How does it work?
Lots of times you need to know a lot before you can grasp why a particular vulnerability is a problem at all. Think about
CSRF, to have a decent idea about what it is; you need to be familiar with the HTTP protocol, session management, browser behavior, etc. The actual vulnerability is just the tip of the iceberg.
You should not shortcut this process, but take the time to understand it. Having a solid grasp of the idea will help you place this knowledge in the grand scheme of things.
How to spot?
Once you know what it is and how it works you need to train yourself to recognize it. Build the triggers that will sound the alarm. This recognition can happen on various levels. You need to know how to detect this in code; you should also be familiar with how this looks like within the application and a complex system.
Here is a quick example of XSS. In code, you are looking for unescaped outputs to HTML. Here are a few examples.
PHP: ...<?php echo $var; ?>...
Pug: ...!{var}...
Handlebars: ...{{{var}}}...
Jinja2: ...{{ var|safe }}...
Razor: ...@Html.Raw(var)...
Erb: ...<%== var %>...
Taking a step back, in the application setting, you are looking for input fields that are echoed back to users: comments, search results, profile information, etc.
Zooming out even more, on a system level, you want to find places where browsers interact with the system, typically web applications.
This is the mindset you should adopt. When looking at a system and thinking of a vulnerability, you should be able to tell where to look and what to look for!
Exploitation
Once you find a vulnerability the next phase is to think about exploitation. There are two main questions here.
How to exploit?
The how very often comes down to something like the following: send a specially crafted payload. What you need to understand here is what makes that payload special, and how can you craft one. This can range from dead easy to something complex.
Staying with the example of XSS, here is a payload you could use to exploit the vulnerability:
Albert <script>alert(1)</script> Mainfield
If the app is vulnerable, this will trigger an alert on the webpage. Keep in mind that there are lots of exotic payloads that will also trigger XSS.
The above is a simple example. Some vulnerabilities are exploited by subverting network traffic or breaking the encryption; it highly depends on the kind of weakness. The key here is understanding what can be done and how you can do it. Armed with this knowledge you are also able to detect if someone else is trying to exploit it.
What’s the impact?
The next piece of the puzzle is dealing with why. Why would an attacker want to exploit this vulnerability? What is the gain? This can range from obtaining sensitive information to establishing a foothold.
For the example of XSS, the attacker gains code execution on the victim’s browser. This allows him to impersonate the victim to the web application, to mine cryptocurrency in the browser, to exploit the victim’s browser, etc. Thoroughly understanding the impact will greatly help when you need to prioritize fixes.
Countermeasures
The third piece of the puzzle deals with security controls. Measures we can implement to mitigate the vulnerability or the scope of the impact.
What can you do?
At first, you may think there is only one solution: to fix the vulnerability. If however, you got this far you understand that a successful attack needs more than the weakness and you can mitigate every step of the way. Take a look at this workshop material for examples on how to defend against XSS. It ranges from input filtering to employing browser features to disable unwanted script execution.
Impact of the fix?
Equally important is the cost of the fix — time and complexity as well as business wise. For instance, if you are creating an HTML editor with a preview functionality, you cannot simple HTML escape everything as that will render part of the app useless.
The critical thing around countermeasures is the idea of trade-offs. Security is about making smart trade-offs, and for that, you need to have a good understanding of your options and their impact.
Next steps
You now have a good understanding of the framework. Use this mental model to explore vulnerabilities, concepts, and constructs from a new perspective. This will help you place and connect ideas more fluidly. Remember, macro and micro are connected; they are just different views of the same field. Be sure to expose yourself to both and ask the questions outlined above to deepen your understanding.
As for learning more in a well-structured format, keep an eye out for new posts. I will use this model in the future when explaining various topics.