OWASP stands for the Open Web Application Security Program. It is a worldwide organization that follows security trends and provides standards and guidelines to embed security into software applications in every stage of their lifecycle. Many developers trust the OWASP Top 10 as one of the most comprehensive and valued security programs. For long it provides a Top 10 of security issues that can happen in (modern) applications and (cloud) infrastructure. Git source code repositories host the majority of the OWASP projects. Everything as code also applies here. In this article we’ll take a look at these OWASP Git repos help to strengthen your security skills.
Once you visit the landing page of the OWASP Git project you’ll notice the large list of source code repositories. A large section of these repositories (which are grouped into projects) are heavily in progress every day. Plenty developers and other security enthusiasts regularly push their changes. At the time of writing, there are over 900 repositories of which 25+ were updated last week. The number of contributors constitutes of more than 30 people from everywhere around the globe.
The TOP 10
Let’s start with the most known repository. Perhaps every developer and security person knows about the OWASP TOP 10. As per February 2022, the TOP 10 of 2021 is the most recent list. In the TOP 10 you would find:
- the 10 most common security issues (divided into categories) that application developers and infrastructure experts might be exposed in their daily work.
- a comparison of the items of the previous list from the last year. This helps to judge which (new or other) security topics are important now.
- every category also contains a lot of details to express why the category moved to a different position in the list. Besides, you also see any new categories.
Source: screenshot from https://owasp.org/Top10/
You can generate the Top 10 yourself by following the instructions on this page. By doing so you would have your own instance of this list as a nice dynamic webpage. From here, you can alter the documentation and watch your changes interactively.
Once you are confident and happy with your changes, you can create your branch (isolated piece of source code) or Pull request and assign it to the core group. From here, they will judge it and process it further.
OWASP Community Pages
No community can survive without proper web pages that describe WHAT the community is all about and WHY it exists in the first place. The main purpose of the OWASP Community Pages is to gather the content contributions of volunteers and other security experts. It’s a way to filter out the ideas, security concepts and thoughts of many individuals that want to contribute to one or more OWASP projects.
The content is divided into multiple “headings” that group the content pages:
- Vulnerabilities (f.e. usage of hard-coded passwords, PHP file inclusion, null pointer injections)
- Attacks (f.e. brute force attacks, full path disclosure, clickjacking, parameter tampering)
- Controls (f.e. intrusion detection, bytecode obfuscation, content security policies)
- All others (f.e. double encoding, access control, injection flaws and improper error handling)
Nearly every security topic is covered on the community pages, so it’s very useful to explore these kind of topics.
REST Security Cheat Sheet
Every modern web application that exchanges data with another system should use loose connections to integrate with other services. One of the modern and standardized way to establish this is using REST APIs. Typically, they communicate with other services via HTTP.
The REST Security Cheat Sheet helps developers and other security experts to secure the communication paths to protect their application and it’s data. A brief list of hints and tips.
- REST APIs use JSON as the standard format to exchange data. Therefore they require so-called JSON Web Tokens which need to be secured. Claims help to instruct JWT to define access to the actual API. Typical claims are iss which defines if an issuer is to be trusted or not. Another one is the exp which stands for expiration time or nbf to compare the current time and the time when the request was made.
- Input validation such as the usage of regexes to constrain input strings, the usage of specific validation/sanitation libraries or frameworks in the language of your application and also apply implicit validation using strong types. Think of numbers, booleans and dates.
- Provide a list of response headers that should be present in every response back to the system that performs the request. Examples are: Strict-Transport-Security to only allow secure connections and to prevent invalid certificates. Another one is: Cache-Control: no-store to prevent caching of sensitive information.
- A complete list of all return codes. There is much more than 200 for success or 404 for not-found. Be as specific as possible to prevent disclosure of how the system responds to requests.
Have a look at the projects’ page to get more advice on other topics.
OWASP Web Security Testing Guide
Penetration testers and other security professionals around the world use the OWASP Web Security Testing Guide to evaluate the security of their applications and web services. It consists of a framework and best practices. At the time of writing, version 5.0 is in progress and version 4.2 recently saw the light.
Once you open the website of the latest stable release, you can explore 12 topics that all have a list of so called “scenarios”. Scenarios have a unique identifier and a number.
Example 1: Cross Site Scripting
Every scenario consists of a detailed summary that answers questions like: what is this security issue all about, present background information, advice on how to use key programming languages in a proper way, etc.
From here on, you will find a several test scenarios and how you can test your application against them. In this case, testers need to analyze their source code to potential data leakage based on XSSI vulnerabilities. Think of “CSV files that are vulnerable to quotations theft” or “using global function parameters”. Every example contains some practical source code snippets that shows how the scenarios work in practice. You can then take measures to mitigate these kind of vulnerabilities.
Example 2: Testing Directory Traversal File Include
Web applications require various files to work correctly. This includes files in the public space of the application but also files which might reside in the private space of the server on which it runs. Attackers try to gain access to those “private files” which can reveal very sensitive information such as usernames or even passwords. To fetch these kind of files, they often “travel” through the filesystem misusing the weak spots of an application. This attack vector has different names: directory traversal, directory climbing, backtracing or dot-dot-slash attacks.
First of all, the OWASP website provides information about the methods you can misuse to skip proper input validation. It then presents options to “traverse directories” by appending query strings like “../../../etc/passwd”. Perhaps you need to execute a custom script to fetch this kind of “private file”. You can also include other hosts and/or ports to gather information from those. In addition, this example also outlines various ways to decode strings and it offers multiple options to deal with static and dynamic paths and path separation topics on multiple Operating Systems.
Further reading show the links to OWASP ZAP, Burp Suite and many other (online) tools that help detect these types of vulnerabilities.
Subdomains which are derived from a main application might be widespread and become being exposed when using tools and websites like Pastebin, Github source code repositories or when using personalized social media profiles.
The OWASP Amass project collects (potential) vulnerable attack surfaces and external assets by utilizing open source information gathering techniques. Besides this, it also performs network mapping for your applications. It uses a number of different techniques to gather it’s data from various sources. Think of the following:
- APIs: VirusTotal, PentestTools, Robtex, Hackertarget, etc
- Certificates: GoogleCT, Censys, CertSpotter
- DNS: NSEC Zone walking, Zone transfers as well as brute forcing.
- Scraping: HackerOne, PKey, Yahoor and DuckDuckGo.
- Web archives: Wayback, Arquivo, Archvelt
At the heart of Amass are five subommands such as intel, enum, viz, db & track to discover subdomains and it’s related meta-data. For every subcommand you can list the various information gathering techniques that are supported by Amass.
One of the core functions is Amass enum that helps you perform DNS enumerations on the target host. This reveals the attack surface which is exposed by the organization. Results are stored in a graph database. You can run enum in active- or passive mode. While active mode is the most thorough scanning method, the passive mode also reveals a lot of information about the various subdomains it can find: gather IP ranges, parent domains. All of these are fetched rather quick and the results are reliable since it uses well established software packages. A sample command would be:
amass enum -passive -d tweakers.net -src.
Threat modeling is one of the key security topics you need to master to find the (perceived) risks of an application or system and what the (potential) impact will be if this leads to an exploit. OWASP Thread Dragon is an open source application that helps you to create diagrams, use a threat rule engine and auto-generate mitigations based on the principles of the threat modeling manifesto.
You can use this free piece of software to run as a web application or as a standalone application. It’s data is either stored online in Github or locally on your own disk. This makes it a powerful tool to be used for companies that require to store their data in-house.
Interesting to note is that this tool also integrates with Jira to track workflow processes of the threats which are created / identified. It helps to make sure that it fits into the bigger picture and is not done in isolation and without much attention.
Another powerful addition is TMT2TD which can convert a threat model from the Microsoft Threat Modeling Tool (.tm7) to a Threat Dragon JSON file. It’s a long Python3 script that uses only the original filename as input and in return it creates the corresponding JSON file as output.
Every security professional should value the projects of the Open Web Application Security Program. Not only the website with community related content but also various other projects that help you to secure your application and (cloud) infrastructure. Many applications and tools are offered through their Git source code repositories. In this article, I highlighted several of them that are worth your time to explore. They are a great source of information and to learn more about discovering attack surfaces, penetration testing techniques, application security techniques, conduct threat modeling sessions and more more. Be sure to spread these ideas and concepts in your organization as part of the wider security program. It will definitively strengthen your security skills.
If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to firstname.lastname@example.org.