When testing for a web application, those tests fall into one of two categories: Online tests and offline tests. With offline testing, you won’t be interacting directly with the deployed online application. The key benefit is that this kind of testing is generally considered safer to the application. The trade-off is that the results are more likely to be limited from those who are generated from online testing. Nevertheless, offline testing has a real value and you should make every effort to make the best of it.
For the testing frameworks that we are presenting here, it is better to use a virtual lab to avoid any unwanted problems in your PC.
Why offline security testing
Well, it’s best to start off with offline testing for multiple reasons.
- It’s much less expensive than putting ourselves as a target in the wild.
- More effective.
Therefore, offline testing has such a high value if it is applied properly.
This article is then organised as follows:
1- Practices and frameworks: leading practices in offline security testing
In order to determine where and how to integrate your AppSec testing activities, you need to think in terms of the software development life cycle (SDLC). The SDLC is a big picture concept that you break down into three concrete activities:
Conceptualise your application, what you want to do. Develop the application and release the application to the intended user population.
It might be overwhelming from a developer point of view to consider security testing on a regular basis. Especially, with the urgent tasks that he deals with every day.
But still, no escape from that. So, let’s answer the question where exactly should the security fit in. We can think of that as four distinct points in the SDLC:
- Documentation: review documents related to security such as policies, contracts and standards
- Review the source code for security vulnerabilities
- Review the quality assurance process to ensure that includes security tests.
- Review the deployed application for security weaknesses.
Well, happy for you, offline security testing includes only the two first touchpoints of the above list. This approach will enable you to more effectively integrate security testing into the SDLC, reducing both the likelihood and the impact of a potential security issue later on.
Understanding the development’s methodologies is quite important before diving into performing your offline security testing. Determining the right development methodology for a team or an organisation depends on a number of factors including organisational culture.
Here are some of the well-known and common methodologies:
We are not going to discuss the details of each methodology, because that will make the article so long. Instead, we will just mention how security tests are integrated into these methodologies.
- Waterfall: building security into this methodology is pretty straight forward. Make sure security requirements are imbedded to each phase and include check between phases to ensure those security requirements were met.
- Agile: it is more difficult for security teams to perform tests in agile, as phases do not exist in agile. However, security tests can be applied at the end of each sprint.
- Rapid: similarly, to the agile approach, the security testing for Rapid methodology is more likely to be performed at the end of each iteration. Generally, it is more about code review than documentation.
- DevOps: there is a subset in the DevOps practitioners that includes security teams in the discussion as well. This subset is called DevSecOps.
It is likely you will encounter teams using different application development methodologies. It is up to you to figure out how they develop applications so you can help them integrate security testing in their process.
So much of the security knowledge that we rely on today was pioneered by those who came before us. People who recognise the risk inherent in relying on technology. Security Frameworks are an excellent example of that accumulated knowledge put into paper.
Happy for us that every security framework already includes application security requirements. That means that you don’t have to start building your offline security testing from scratch. You can turn to these frameworks to determine where makes the most sense for you to start your testing.
Although there is a lot of theses frameworks, we suggest that you begin with the four most popular ones:
- ISO 27k series: International organisation for standardisation is a collection of over 30 related standards. This series is designed to help you build a fairly robust information security management system (ISMS).
- NIST cybersecurity framework: rely on multiple special publications from the US national institute of standards and technology. Similar to ISO 27002, NIST is documented anywhere from 100-50 to 100-73 unique security controls depending on which baseline you choose: low, moderate, or high.
- COBIT: which is formally know as control objectives for IT, comes from the ISACA organisation. It is designed for IT governance.
- CIS CSC: I recommend personally that you take a look at the critical security control from the centre for internet security. CIS applies a maturity model when selecting controls.
You will find tremendous value in reviewing these four frameworks in detail focusing on the guidance each one provides regarding application security.
While security frameworks provide recommended standards based on best practices, compliance standards and frameworks contain rules that organisation have to follow in certain cases. Failure to meet compliance standards can result in hefty financial penalties.
Popular compliance standards
- Publicly traded companies in the US must comply with: SOX
- Financial services organisation must meet the requirements lied out in: GLBA
- Healthcare organisations in the US are expected to protect healthcare information in accordance with: HIPAA.
- Payment cards: PCI DSS.
- Privacy: GDPR, PIPEDA.
When it comes to compliance, this list is far from complete. However, it gives you a starting point for other resources you can turn to for guidance on relevant application security controls.
OWASP is one of the most influential organisations when it comes to web application security. OWASP stands for Open Web Application Security Project. The OWASP is a non-profit organisation dedicated to helping developers and organisations better understand how to secure their web applications. OWASP has published a tremendous number of security resources. These resources are grouped into three distinct project categories.
- Flagship projects are the most mature OWASP had to offer.
- Lab projects, which are more practical to use.
- Incubator projects where ideas are still being tested.
The most well-known flagship project from OWASP is the top ten project. It contains a rotating list of the most critical web application security risks. It was first released in 2003. The following year, they locked in an official version control list that they committed to updating every three years.
Happy for us it is always freely available for anyone to download.
- Broken Authentication
- Sensitive Data Exposure
- XML External Entities (XXE)
- Broken Access Control
- Security Misconfiguration
- Cross-Site Scripting (XSS)
- Insecure Deserialization
- Using Components with Known Vulnerabilities
- Insufficient Logging & Monitoring
The OWASP Top ten white paper also includes guidance on threat agents, the attack vectors that may use to exploit security weaknesses, the controls you can implement to mitigate those risks and the potential technical and business impact of those attacks if they are successful.
Well OWASP is best known for their top ten project, they have a lot more to offer for web application security professionals. Here are some of other notable OWASP projects:
The testing guide project is a PDF file that provides extensive guidance on security testing that you should be performing as well as for instructions of the tools and techniques you can use to execute those tests.
When performing web security testing, I personally use this testing guide to build a basic security profile of the application. This guide is without any doubt one of the most important tools to add to your toolkit.
The code review project is also a PDF file providing a comprehensive process to what to look for exactly when performing a code review. It also includes examples of how the code should look like.
The amount of knowledge contained within this guide is incredible.
The OWASP ZAP project is a combination of web vulnerability scanner and web application proxy and one of the most widely used. You can use ZAP to capture, intercept and manipulate requests between your testing machine and the application server. This is a great way to test if your backend security control is up to the test.
The OWTF short for offensive web testing framework is designed to help penetration testers automated many of their web application tests. The OWTF combines information from the OWASP testing guide, the penetration testing execution standards (PTES) and the NIST. The goal is to automate the basic tasks when it comes to web application security testing.
Although the installation of this tool is not east, it is most certainly worth every second.
3- Offline testing tools
As discussed above, you most likely need to perform offline security testing using documentation. However, you will need to dive into the source code. There is a lot of code analysers. But we will only mention some of the most commonly used which are: Codacy and SonarQube.
Codacy is a static code analyser designed to help you identify a number of potential quality issues within your app. With one of those quality issues being security. What is great about Codacy is that you can relate the cloud version of the tool to your GitHub or Bitbucket and automate that analysis of every commit and code request. You can also download a free trial version to continue testing in your testing machine.
SonarQube is pretty similar to Codacy, although it has a slightly large userbase. You can run the SonarQube community edition for free locally. You can also use their cloud version to take advantage of their online resources.
Repeatable processes could be overwhelming and time-consuming if it is performed without documentation. Especially, when it comes to security testing. By documenting your testing checklist, you will be able to measure your results over time to determine whether or not your testing efforts are having the desired results. And measuring your results should absolutely be a core consideration as you are designing your offline security testing activity.
5- Threat modelling
With respect to the threat modelling, the code review guide applies two separate models: STRIDE and DREAD.
If you did some threat modelling in the past, chances are you are somewhat familiar with one or both of these models.
STRIDE Threat Model
The STRIDE threat model was developed by a pair of Microsoft employees. It focuses on six potential threats.
- Spoofing user identity
- Tampering with the integrity of the application
- Information disclosure
- Denial of service
- Elevation of privilege
DREAD Threat Model
The DREAD threat model also came from Microsoft space. This model relies on five threat categories.
- Affected users
When building out a code security review process, you personally run the risk to be overwhelmed by the scope of the effort. And by the imbalance between potential threats and available security resources. The OWASP code review guide can help simplify this process considerably shifting your mindset from overwhelmed to empowered. Download the guide and build it into your process.
6- Tools for offline security testing by language
During the documentation, you should have discovered the languages your team are using for the development. This information is absolutely essential when it comes to choosing the tool or tools, you’ll use to perform this automated static code security testing. Here are some of the testing tools giving the language used.
- Python: when it comes to testing Python apps, Bandit is one of the most common tools. Bandit is a free tool designed specifically to test security flaws in Python code.
- Ruby: for Ruby code, Brakemanscanner is extremely popular.
- C#: If you’ve worked with C# applications, then you may have taken advantage of the real-time scanning functionality offered by Puma scan.
OWASP maintains a fairly extensive list of source code analysis tools including both free and commercial tools.
In order to determine the right metrics for your program, you need to start by identifying your audience.
The OWASP app sec Metrics project is currently inactive, but the questions posed by their project provide an excellent foundation for metrics that are likely to resonate with developers and managers alike.
- How many lines of code?
- What languages are used?
- What libraries does this application use?
- What type of network access is required?
Thank you so much for taking the time to read about offline web security testing. You should be able to begin applying what you’ve learned in this article. But there is only so much we can cover in these lines. This is only a brief introduction that should provide you the guidance from where you should start. To keep your skills sharp, try to build your own lab performing security testing for your projects or code you download online. Find opportunities via paid internships or by finding a mentor.