Skip to main content

Software Security Testing Part - III

 Source Code Review Tools & Techniques

Introduction 

  Welcome to the third module of software security testing workshop. This module will specifically discuss tools available on the Internet to perform security source code review, or simply code review. These tools are not easy to use and understand as it is not a script kiddy job to simply run and detect the vulnerability and you need to have a solid background in programming to understand what the tool is highlighting as a flaw and what could be the outcome of a complete review. 

  This module is an easy go as it will speak about different tools and some snapshots. This module can be separately studied to gain more knowledge about source code review tools and their features. In this module, we will public speaking and reviews about these tools.

    In today’s field of information security, the fastest growing areas in the software security industry is a source code analysis tool, also known as static analysis tools. These tools review source code line by line to detect security vulnerabilities. 

  Why do we need tools?

   This has been already answered to some extent in the previous module where we discussed the Black Box testing method for performing a security code review. However, it’s worthwhile to highlight some more benefits of using cutting edge security tools for performing the source code reviews. 

• Good bug-finding performance 

• Centralized reporting components 

• Tight integration 

• Time & performance 

• Quick solutions & recommendations 

• Standardized approach for detection of flaws 

• Uses best practices • Detect buffer overflows 

• Memory corruption detection 

• Bounds-checking errors and type confusion 

• Control flow analysis 

• Pinter aliasing 

• Memory allocation errors

 • Calls to insecure library functions 

• Database of vulnerability library calls

 • Ability to preprocess source code 

• Lexical analysis 

Some of the key features are explained below which are also stated by big organizations. 

• A database of vulnerable library calls is perhaps the heart of this security scanning technology, but at the same time it is the hardest to evaluate. The vulnerability database must, above all things, be up to date, but an evaluation suite would have to be constantly updated, as well, to remain relevant. 

• The ability to preprocess source code is important for C/C++ analyzers, because it lets the analyzer see the same code that will be seen by the compiler. Without this capability, there are numerous ways to deceive the analyzer. Many analyzers use heuristics to approximate the functionality of a preprocessor.

• Lexical analysis is the process of breaking a program into tokens prior to parsing. Lexical analysis is necessary to reliably distinguish variables from functions and to identify function arguments. These functions can also be performed with heuristics—at the cost of some reliability, however. These are some of the key benefits for using such tools.

Leading Source Code Review Tools

 Flawfinder 

Flawfinder is very a simple tool among the source code review tools that examines C/C++ source code specifically and reports possible security weaknesses (“flaws”) which are also rated or sorted by risk level of those weaknesses. Developers of this tool recommend it as very useful for quickly finding and removing at least some potential security problems before a program is widely released.

  Vendor link: http://www.dwheeler.com/flawfinder/. 

 IBM Rational Software Analyzer 

  This is a commercial tool by industry experts that runs static analysis to perform code reviews. You can run tools to run different analysis with rules and it also provides quick fixes of the problems it finds in the code. To understand more about this tool, you can read this paper written by IBM which is available at below link. 

Vendor link: http://www.ibm.com/developerworks/rational/library/08/0429_gutz1/#toggle. 

Veracode SAST 

 A commercial tool to perform code reviews to detect security flaws and omissions more quickly and at lower cost via automation. Covers flaw detection including SQL Injections, cross-site scripting (XSS), buffer overflows and unhandled error conditions and potential back doors in the software code. 

  Vendor link: http://www.veracode.com/products/binary-static-analysis-sast. 

  Secure Coding Validation Suite by CERT

   Developed by CERT to validate rules defined in ISO/IEC TS 17961. These tests are based on examples in its technical specification. It’s a suite, which includes tools that allow vendors to use these tests with an analyzer, interpreter, or compiler along with the script driver it has. 

  Vendor link: http://www.cert.org/secure-coding/tools/validation-suite.cfm. 

  Microsoft CAT.NET 

  This is one of the best tools in performing source code review for .NET applications, as it is obvious that the vendor itself provides it. It is a binary code analysis tool that helps in identifying common variants of certain prevailing vulnerabilities that can give rise to common attacks. Basically CAT.NET is a plugin to the Visual Studio IDE, which helps to identify security flaws within a managed code. It performs scanning over the binary and/or assembly code of the application. It also works on rule sets and the following rules are currently supported by the tool. 

• Cross Site Scripting 

• SQL Injection 

• Process Command Injection 

• File Canonicalization 

• Exception Information 

• LDAP Injection 

• XPATH Injection 

• Redirection to User Controlled Site 

 Vendor link: http://www.microsoft.com/en-us/download/details.aspx?id=19968. 

These are only a few tools that are available.. Over the Internet, you will be able to find such types of tools that can provide source code review functionality, in both the domains of commercial as well as open source industry. For your ease and to give you a focus area to look for such tools, we have provided a link that lists most of these tools with links to their vendor’s page along with their types and areas of functionality. 

Tools list: http://samate.nist.gov/index.php/Source_Code_Security_Analyzers.html

   In our next module, we will be using Flawfinder, which is an open source tool for performing code review. Personally, I like it as it’s easy to use, lightweight for demonstrations, and Linux based. Since I am a Linux user, I like things on Linux. Most of the software industry also uses Microsoft tools so its worthwhile that we further present some more generic information about CAT.NET and more specifically highlight the functionality it performs. 

  Basically, Code Analysis Tool (CAT.NET) is a binary source code analysis tool that helps in identifying common security flaws in managed code. These vulnerabilities are listed in the below table.


Important Note 

  This is to be considered and noted that whatever functionalities or information we have presented in this workshop for any of the tools by any of the vendors is solely for the purpose of education and it doesn’t confirm that these tools only have such features and is not a criticism of any of the tools or vendors listed or explained in this workshop.

Popular posts from this blog

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
Read more

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
Read more

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
Read more