In this article, I will explain what is the OWASP and how you can use it as a developer or a security engineer to enhance your game in terms of Secure Development and Secure practice.
I know it is a long post, but I tried to make it as enjoyable and understandable to read as I can as this is a critical topic and reading it to the end is very valuable to you as it can help you to improve a lot the security of your code and of your organisation.
If you prefer to see it on a video, you can find it on my Twitch channel.
I am streaming every Thursday at 9:00pm (GMT+1) on my Twitch channel about Security topics. 🖥️
Feel free to come and say hello 🙋🏼♂️, if that is of any interest to you or if reading that article brought some questions and you desperately need answers. 🤔
The stream about the OWASP is available here.
Here is a clip about it :
Liquid error: internal
See the video about the OWASP on Youtube here :
A lot of attacks are based on the same patterns because developers are developing services using the same patterns, libraries, etc... and they don't know about the attacks.
When I was a developer, I was using a lot of third party libraries and a lot of patterns from previous apps or code from the internet about topic I wasn't very familiar with.
This behavior is very common among developers, especially young developers that are not mentored by more senior developers and it could bring very vulnerable applications to the market.
A lot of mobile applications on iOS or Android are built by teams of engineers that are launching their first application on App Stores or have to do it very quickly to be on the market as soon as possible.
Let's explain why it is interesting and important to understand these security topics even if you are not going to use because you are developing a software.
When you are learning a Fighting Sport like Karaté or MMA, first you are going to learn how to attack your opponent.
Why are we doing that? 🤷🏼
It is because when you know all the attacks, even if you can't do all of them - because that "Super-Flying-High-Kick" is kind of hard to do - you can start learning the best way to defend it, block it or even counter attack.
It terms of Cybersecurity, you are in a similar pattern. There is an Attacker and a Defender. You are in the position of the Defender (and you can't fight back).
Nevertheless, knowing all the possible attacks puts you in a better position to defend yourself and your service.
That's why I want to focus on offensive Security for the next posts.
But before we go through a lot of the most common attacks on Applications, Infrastructures and Services, I want to present one of the most interesting resources if you are interested in Infosec, the Open Web Application Security Project (OWASP).
What is the OWASP ?
The Open Web Application Security Project (OWASP) is an online community that produces freely-available articles, methodologies, documentation, tools, and technologies in the field of web application security.
Everything the OWASP produces is Open Source and freely available on its website or Github.
Moreover, the OWASP resources are available in a lot of different languages. I am sure that your native tongue is supported. And if it is not, you can participate in the project and translate the materials in your language of choice (that was how I got involved in the project at the beginning).
The OWASP produces the OWASP ZAP software to perform Man in the Middle attacks.
OWASP ZAP is similar to the very popular Burp Proxy from PortSwigger, Charles Proxy (Mac only) or Bettercap (CLI, written in Go).
The OWASP produces a lot of documentation, about the 10 most frequent attacks on applications and services, Security Testing Guides for a lot of targets (web, iOS, Android), Security Knowledge Framework to upgrade your Team's Security knowledge and a lot of others.
The OWASP website is a fantastic source of knowledge about Web Security and you should definitely go there and read it extensively.
And be sure to be part of the project. It is really very easy.
My first contribution to the OWASP project was just to translate the OWASP TOP 10 in french (my native tongue). I discovered a very friendly community and it was one of my first contribution to an Open Source project. If that is of interest to you, be sure to be part of the OWASP project and bring your knowledge and values to the OWASP project, whatever they are, they are going to be useful to the project.
The OWASP Top 10
The OWASP Top 10 is one of the most popular project of the OWASP.
It represents a broad consensus about the most critical security risks to web applications.
That means it is where you should focus in terms of security and development. Because they are the flaws that are the most often available on a web service. And so, it is what an attacker is going to test first.
| # | Flaw | Description |
|---|---|---|
| 1 | Injection | Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. |
| 2 | Broken Authentication | Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently. |
| 3 | Sensitive Data Exposure | Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser. |
| 4 | XML External Entities (XXE) | Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks. |
| 5 | Broken Access Control | Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc. |
| 6 | Security Misconfiguration | Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion. |
| 7 | Cross-Site Scripting XSS | XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites. |
| 8 | Insecure Deserialization | Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks. |
| 9 | Using Components with Known Vulnerabilities | Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts. |
| 10 | Insufficient Logging & Monitoring | Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring. |
OWASP Security Knowledge Framework - OSFK
SKF is an open source security knowledgebase including manageble projects with checklists and best practice code examples in multiple programming languages showing you how to prevent hackers gaining access and running exploits on your application.
The latest you discover a vulnerability during your Software Development LifeCycle, the more expensive it will be to solve it.
Here is a good picture about the cost to solve a vulnerability regarding the Software Development LifeCycle.
The OSFK gives you the tools to upgrade your software development teams Security knowledge by doing.
You can find labs to hands-on on a lot of flaws.
 |
 |
For instance, if you want to understand the Path Traversal vulnerability (LFI stands for Local File Inclusion), you just have to choose "Go to Lab" and follow the steps.
You can either choose to try it over a Docker image or a Python script.
Then you can try this vulnerability through the "Reconnaissance" and then "Exploitation" steps.
1 - Reconnaissance
The application shows a dropdown menu from which we can choose an intro or chapters to be displayed on the client-side.
First thing we need to do know is to do more investigation on the requests that are being made. We do this by setting up our intercepting proxy so we can gain more understanding of the application under test.
After we set up our favourite intercepting proxy we are going to look at the traffic between the server and the front-end. the first thing to notice is that it tries to retrieve a text file
The image above shows the text file that is being fetched from the servers file system highlighted in red. And the response is highlighted in blue.
@app.route("/home", methods=['POST'])
def home():
filename = request.form['filename']
if filename == "":
filename = "default.txt"
f = open(filename,'r')
read = f.read()
return render_template("index.html",read = read)
In the code example the "filename" parameter that is used to read content from files of the file system is under the users control. Instead of just reading the intended text files from the file system, a potential attacker could abuse this function to also read other sensitive information from the web server.
2 - Exploitation
A potential attacker can now tamper the "filename" parameter to get more sensitive information from the file system. As a proof of concept in a penetration test we will often show a successful attack by getting the "/etc/passwd" file.
But other files with sensitive information can of course be just as interesting. How about getting a file with connection strings to the database? It is also not uncommon for administrators to re-use passwords. So retrieving this information could prove to be valuable information to gain access to other systems.
You can find this kind of explanation for all the vulnerabilities identified in the OSFK.
I greatly encourage any user to have a look at the OWASP Top 10 and login to the OSFK to look at as many vulnerabilities as possible and try the labs to understand how it is possible to discover and exploit this kind of vulnerability.
I hope that with this, you can understand that exploiting a vulnerability is not that complicated and that it can come from a little mistak ein your code.
I will explain all the most common vulnerabilities (XSS, CSRF, SQLi, etc...) in details in my future posts.
OWASP ZAP
Internet is a network and each node can communicate with the others.
In a webservice, there is a client (you) and a server (the service you want to consume). The client and the server exchange a lot of information in order for the client to be able to consume the server services/APIs.
A lot of vulnerabilities are coming from these exchanges over the network.
If someone can listen to the network flows it can have a lot of valuable information. For instance on an e-commerce website, what you are buying, how many, your name, your address and most of all, your credit card numbers.
That is why we have created "https" to secure exchanges over the network.
Nevertheless, it still has flaws if it is improperly implemented.
That's where a tool like OWASP ZAP can come to a help.
Zed Attack Proxy (ZAP) is a free, open-source penetration testing tool being maintained under the umbrella of the Open Web Application Security Project (OWASP). ZAP is designed specifically for testing web applications and is both flexible and extensible.
At its core, ZAP is what is known as a “man-in-the-middle proxy.” It stands between the tester’s browser and the web application so that it can intercept and inspect messages sent between browser and web application, modify the contents if needed, and then forward those packets on to the destination. It can be used as a stand-alone application, and as a daemon process.
If there is another network proxy already in use, as in many corporate environments, ZAP can be configured to connect to that proxy.
ZAP provides functionality for a range of skill levels – from developers, to testers new to security testing, to security testing specialists. ZAP has versions for each major OS and Docker, so you are not tied to a single OS. Additional functionality is freely available from a variety of add-ons in the ZAP Marketplace, accessible from within the ZAP client.
In terms of attacks, you can perfomr all type of "Man in the Middle" attacks with the Zap proxy like XSS, CSRF, SQLi, and a lot of others.
ZAP is very interesting as it can be userd as a standalone application but as a daemon process as well which a top notch feature if you want to add Security in your CI pipeline, because you can then add some tests using ZAP on your CI.
Let's consider the following CI pipeline :
If you want to add some Security to the CI pipeline, during the "Run Tests" step, you add your security related tests, with the ZAP proxy or any other security tools that you find relevant and then add these tests to the CI pipeline.
Something interesting that you can do to start adding these security tests to your CI pipeline is to perform a pentest on your platform.
Once you get the identified vulnerabilities from this pentest, solve them.
As part of the process of solving these vulnerabilities, you must write tests in your CI pipeline to get sure that the code and the new artifacts you are going to deployed are not subjects to this vulnerability anymore.
It will cost a little bit more at the beginning. But it is defintely a huge cost saving action in terms of security for the future.
You are investing for your own security in the future. And your peace of mind for your future deployment. And your next pentests can focus only on new vulnerabilities because you know that these vulnerabilities are not going to occur again thanks to your test plan.
All of these actions are going to help you focus on the things that matter, in terms of security but to appease anyone about the security of the projects. Everything is under control and you can show what you are doing for that.
That is the all purpose of the DevSecOps methodology and I hope to explain it a bit deeper in a next post.
Thank you so much for reading it to this point.
I hope you enjoyed reading it and learned something.
Leave me a message if you DevSecOps is already something that you are doing in your team or you are planning to add it to your CI pipeline.
Tell me what you think about OWASP ZAP, if you are a developer. Is it useful ? And as a security engineer. What is the goal you want to achieve with this kind of tool .
I’ll be happy to see that I participate adding security to an organisation or that one person discovered something new reading that article and is going to upgrade its game in terms of security. 💪
That would mean a lot to me.
Top comments (2)
Incredible article Remi! You really covered everything 🙌
Thank you so much for your comment.
That is very encouraging for me to continue sharing about security and development.