Skip to main content

Software Security Testing Part - II

 Types of Software Security Testing


Introduction

  Welcome to the second module of software security testing workshop.In this module, we will be exploring different types of evaluating software security. It is recommended that you should first complete the previous module in order to build a knowledge base in this domain, which will help you continue in this workshop with a separate mind set on how to be an expert in software security testing.

 Software Security Testing 

  Different organizations and different security professionals define it differently and mostly all are correct. There are different ways of understanding software security testing. Following are some well known concepts:,

   “Security testing which is non-functional in nature, more focused on security aspects” 

                        OR 

“It is a type of testing in which a security professional performs different types of attacks to check the security blueprint of the software in order to find if the software or application is secure or not”

   OR 

  “It is also defined as a process in which security professionals determine that the overall information system integrated with the software is secure and protects data and maintains functionality as intended”

   Core Values

   The core concept that is considered while performing security testing of software is to cover the following as the major topics: 

• Confidentiality 

• Integrity 

• Authentication

 • Authorization 

• Non-repudiation 

• Availability

   Considering the above six aspects in software security testing assures an improved software or application risk management for the enterprise. The purpose of security testing for flaws in software is to seek solutions to remove vulnerabilities before software is purchased or deployed in the enterprise and, most importantly, to ensure security before the flaws can be exploited. 

  However, most enterprises think that software security testing can be problematic while considering the purchasing, installing, maintaining, and hiring internal security experts to operate it can be costly. And the time it takes to execute can impact productivity by slowing secure software development.

   This is just one of the many reasons why leading enterprises have chosen the automated, software security testing services from different vendors.

Types of Software Security Testing 

  With the different types of security testing that are usually performed by organizations, we can simply categorize them in the three main types as follows: 

1. Front End Testing 

2. End to End Testing 

3. Main Code Testing 

  These types explains what type of testing are usually covered while they are performed. However, we will explain each one of them separately.

   Front End Testing (FET) 

   This is basically testing of the front end of the software or application, focusing on the some of key aspects of the security lifecycle, and this type of testing doesn’t provide a high level of security as only the front end of the application is testing for security. FET is usually performed as a part of the overall security development lifecycle and it is not the recommended type of security testing which enterprises should follow. What it mainly covers is given below: 

• Input validation 

• SQL Injections 

• Cross-site scripting 

• Operational testing 

• Segregation of duties 

• Authentication mechanism of application 

• Client side environment of the application 

These are some of the key activities that form an integral part of front end testing (FET).

  End-to-End Testing (E2E) 

  This is the most effective type of software security testing in which complete security assessment is performed, covering a range of security controls. Key activities that form the core of E2E are given below: 

• Process Review of related software activities 

• Segregation of Duties 

• Workflow reviews 

• Security Administration 

• Roles and Responsibilities 

• Core source code review 

• Input validation 

• SQL Injections 

• Cross-Site scripting 

• Authentication & authorization 

• Backend database security

 • Software dependencies check 

• Vulnerabilities assessment 

• Security misconfiguration

   Main Code Testing (MCoT) 

  This type of testing is mostly used with different security testing tools which security professionals utilize for detection of software weaknesses. This type is further divided into sub divisions, based on the nature of testing for performing main code testing. These types are listed below:

  • Quick code review 

• Structural analysis review 

• Complete code review 

 Quick code review is the baseline code review that runs if you do not select a code review in any set preference. It includes rules with the severity levels. 

 Structural analysis review is based on only an architectural review of the code and doesn’t cover end-to-end review of the code to highlight all weaknesses.

Complete code review ensures all possible aspects of the weaknesses that should be considered in review. The purpose is to ensure that no security holes are left in the software code before the software goes live in the industry. This is the most extensive type of code review that takes time and requires experienced security professionals with a strong background in programming and software development lifecycle. 

  Now, regardless of which MCoT type yo qu use for performing security code review, there are two main methods that are supposed to be used to run this testing. These methods are basically based on which techniques security professionals use to achieve the goal.

   Techniques or Methodologies

   Two main techniques widely used in performing software code reviews are as follows: 

 • Black Box Method

 • White Box Method 

  Now, you might have already guessed what the difference is in these two types, it is basically based on the approach. The Black Box method is better because it saves time and also uses parts of the White Box method in it.

   Black Box Method

   In this approach, the secure code review is done using different open testing tools commercially available or on open source platform. 

  Quality assurance professionals use such tools during the development stage of the software but a security analyst also gets help from them. These security tools are very useful while doing code review in order to analyze a large amount of main code, which is normally millions of lines of code.

   They can quickly identify potentially insecure pieces of code in the main code, which can be further analyzed by the developer or a security professional with manual methods. 

  White Box Method 

  In this method, a thorough code review is performed over the whole code manually, which may become a very tedious and tiring process. However, this process might be helpful in identifying flaws but this requires at least more than two professionals in performing this type of code review. 

  The best way of performing this type of testing would be to concentrate on potential problems in the code instead of going line by line through whole main code. Those potential vulnerabilities can be given a high priority.

   Example1 

In C/C++, we try to find any copying function in the code and check whether it’s using functions, such as strcpy() for performing copy function. As we know, strcpy() is vulnerable to buffer overflow attacks.

   Example2

 We may also want to check if any customized encryption is being used in the application, which automated tools may miss, as they can identify standard algorithms only. 

  By knowing these two methods, we see that the best approach will be a mix of both, depending on the volume and criticality of data. In today’s world, where many complex applications are developed, we can’t ignore any of the above-mentioned techniques.

   However, it is recommended that Black Box is used first, and then later, perform some manual analysis on areas of code which are highlighted by the tools. For such manual reviews, a second security professional should be deployed in order to get the best results out of these methods. 

 Security Code Review Tools 

  There are many tools available in the market for performing security code reviews and these tools are based and dependent on the computer programming language in which the software is coded. You may find tools that have the capability to perform security reviews in more than one language and are considered leading software in performing code analysis. We have listed a few tools below,that you can download and try with the trial version. However, they may not all be available for free download and use

. • OWASP LAPSE 

• Black Duck Suite 

• Cigital SecureAssist 

• Coverity SAVE 

• HP Fortify Static Code Analyzer 

• IBM Rational Appscan Source Edition 

• Veracode SAST • Flawfinder 

• Source code validation tool by cert 

• Microsoft Code Analysis Tool (CAT.NET) 

  In our upcoming module, we will be utilizing the CAT.NET tool by Microsoft to perform the code review for .Net application. For this you will be required to download a sample code and prepare to perform a security source code review of the application. 

  We will be talking in detail about the code review tools and the techniques further in our next module. In order to continue the workshop and gain practical experience in performing security code review, keep going through the workshop, as this is one of the very unique skills not all security professionals possess. By completing this workshop, you will be able to execute source code reviews for at least .NET based applications or software.

Popular posts from this blog

Bypassing Web Application Firewall Part - 2

WAF Bypassing with SQL Injection HTTP Parameter Pollution & Encoding Techniques HTTP Parameter Pollution is an attack where we have the ability to override or add HTTP GET/POST parameters by injecting string delimiters. HPP can be distinguished in two categories, client-side and server-side, and the exploitation of HPP can result in the following outcomes:  •Override existing hardcoded HTTP parameters  •Modify the application behaviors   •Access and potentially exploit uncontrollable variables  • Bypass input validation checkpoints and WAF rules HTTP Parameter Pollution – HPP   WAFs, which is the topic of interest, many times perform query string parsing before applying the filters to this string. This may result in the execution of a payload that an HTTP request can carry. Some WAFs analyze only one parameter from the string of the request, most of the times the first or the last, which may result in a bypass of the WAF filters, and execution of the payload in the server.  Let’s e

Haking On Demand_WireShark - Part 5

Detect/Analyze Scanning Traffic Using Wireshark “Wireshark”, the world’s most popular Network Protocol Analyzer is a multipurpose tool. It can be used as a Packet Sniffer, Network Analyser, Protocol Analyser & Forensic tool. Through this article my focus is on how to use Wireshark to detect/analyze any scanning & suspect traffic. Let’s start with Scanning first. As a thief studies surroundings before stealing something from a target, similarly attackers or hackers also perform foot printing and scanning before the actual attack. In this phase, they want to collect all possible information about the target so that they can plan their attack accordingly. If we talk about scanning here they want to collect details like: • Which IP addresses are in use? • Which port/services are active on those IPs? • Which platform (Operating System) is in use? • What are the vulnerabilities & other similar kinds of information. • Now moving to some popular scan methods and ho

Bypassing Web Application Firewall Part - 4

Securing WAF and Conclusion DOM Based XSS DOM based XSS is another type of XSS that is also used widely, and we didn’t discuss it in module 3. The DOM, or Document Object Model, is the structural format used to represent documents in a browser. The DOM enables dynamic scripts such as JavaScript to reference components of the document such as a form field or a session cookie, and it is also a security feature that limits scripts on different domains from obtaining cookies for other domains. Now, the XSS attacks based on this is when the payload that we inject is executed as a result of modifying the DOM environment in the victim’s browser, so that the code runs in an unexpected way. By this we mean that in contrast with the other two attacks, here the page that the victim sees does not change, but the injected code is executed differently because of the modifications that have been done in the DOM environment, that we said earlier. In the other XSS attacks, we saw the injected code was