Skip to main content

Software Security Testing Part - IV

 Demo Code Review

Introduction

   Welcome to the fourth module of software security testing workshop. In this workshop so far we have spoken enough about security testing in software code, methodologies and different types of software testing along with different tools introduction that are available easily in the industry market. However, so far we have not presented a practical demo for performing code review. 

  This will be a quick module to demonstrate how you can perform code reviews before you put your code on a live desk. We will be using Flawfinder as our tool to review code written in “C” language. 

  What is Flawfinder? 

  The Flawfinder is an open source security code review tool that is easily available to be downloaded from the Internet in one quick go. 

  Vendor’s mouth 

  “A simple program that examines C/C++ source code and reports possible security weaknesses (“flaws”) sorted by risk level. It’s very useful for quickly finding and removing at least some potential security problems before a program is widely released to the public, Flawfinder is specifically designed to be easy to install and use.” 

 How does it work? Flawfinder works by using a built-in database of C/C++ functions with well-known problems, such as buffer overflow risks like: 

• strcpy() 

• strcat() 

• gets() 

• sprintf() 

• scanf() family. 

It also detects format string problems such as 

 • [v][f]printf() 

• [v]snprintf() 

• syslog() 

Race conditions such as 

• access() 

• chown() 

• chgrp() 

• chmod() 

• tmpfile() 

• tmpnam() 

• tempnam() 

• mktemp() 

Potential Shell met character dangers (most of the exec() family, system(), popen()), and poor random number acquisition (such as random()).

The good thing is that you don’t have to create this database – it comes with the tool. 

  Easy to use 

  Flawfinder is extremely easy to use, and doesn’t require long hours and dependencies before its installation. It is a Linux based product and you can easily install this on Kali Linux as part of your security testing Swiss army knife. 

  Download: http://www.dwheeler.com/flawfinder/flawfinder-1.31.tar.gz. 

  We will present quick installation steps so that you can setup your machine, as well, however, it doesn’t take much time, honestly. 

  Login to your Kali Linux and open up terminal windows and you can download this via above direct link as shown below in the figure.


   You can directly use Flawfinder from this directory, however, it’s worthwhile if you can install this by using the following commands as shown in the figure so that you can more easily use Flawfinder.


   Practicing Flawfinder We have downloaded sample “C” codes from the Internet that are easily available with a search over Internet. Now it’s time to run some quick reviews with Flawfinder. We have the following “C” files available in a directory called scripts as shown in below figure.


You can see that Flawfinder has detected 183 hits. These hits are potential vulnerabilities Flawfinder has detected. The total time it took is less than 1 second, a rate of 49579 lines / second, and the total lines it reviewed was 3392. 

  The steps Flawfinder performs are given below as captured logs:







While running Flawfinder, you can also see the actual line where the flaw is detected. To achieve this, you can use the –context switch and see the exact line where the hit is detected.

   To explore the complete features of Flawfinder, you should download this tool and run it yourself to find out how you can detect security issues in your source code. 
  
We will post the “C” sample code we used to run Flawfinder on the forum

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

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

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