sql

1

Scholarly Journal 1: Design and Implementation of SFCI: A Tool for Security Focused Continuous Integration.

Lescisin, Michael; Mahmoud, Qusay H; Cioraca, Anca.Computers; Basel Vol. 8, Iss. 4, (2019): 80. DOI:10.3390/computers8040080.

5. Existing Software Packages:

Our tool employs several pre-existing software packages for vulnerability detection, version control, and report generation. The tools AddressSanitizer, Valgrind, Sqlmap, Commix, XSS Me, and DotDotPwn were used for detecting vulnerabilities in the software being tested. These tools were selected as they cover the nine types of vulnerabilities reported on by our tool. MITRE listed the top four software vulnerabilities as: SQL injection, OS command injection, buffer overflow, and cross-site scripting. Path traversal vulnerabilities were ranked at number 13. These vulnerabilities can be divided into two broad categories: memory safety vulnerabilities and code injection vulnerabilities. Memory safety vulnerabilities are concerned with illegal accesses to memory (such as buffer overflows or use-after-free), while code injection vulnerabilities are concerned with tricking a victim program to treat untrusted data as code (SQL injection, cross-site-scripting, etc.) [21]. For the memory safety vulnerabilities, two popular testing programs are Valgrind Memcheck and AddressSanitizer. AddressSanitizer is routinely used by Google for testing for memory safety bugs in their Chrome browser and has found over 300 previously-undetected vulnerabilities [22]. Although slower than AddressSanitizer, Valgrind has also been used for bug detection in a wide variety of popular software [23]. Commix, SQLmap, and DotDotPwn were chosen for SQL injection, OS command injection, and path traversal, respectively, as they are found as included packages in the popular penetration testing Linux distribution, Kali Linux [24], and are thus well established tools in the computer security community. Wanting to make our tool capable of automated testing of web pages, we modified the XUL code of Iceweasel (Debian’s Firefox) to accept remote privileged JavaScript commands from a testing process. This also gave us the possibility of automating a Firefox plugin of which there are many with the purpose of penetration testing [25]. From these plugins, we chose XSS Me as the default XSS penetration testing tool for our tool. Finally, all our chosen penetration testing tools were free and open-source, which reduced the cost of building our tool and gave us, and the end-user, more freedom to modify any of the programs as needed. Version control was done with Git, and report generation was done with Jinja2. A sandboxed, snapshot (stateless) testing environment was provided by QEMU-KVM. The following discusses these software packages in detail.

5.6. Sqlmap:

Sqlmap is a penetration testing tool for detecting and exploiting SQL injection security flaws [32]. It has been used to successfully detect SQL injection flaws in production software [33,34].

7.1. Developing the Test Cases:

Testing for command injection vulnerabilities was straightforward as Commix was able to detect the command injection vulnerability in the value_x parameter and exploit it. The same command injection test case template that was used when developing this tool was used, and only the URL and parameter tested by Commix needed to be changed. Testing for path traversal vulnerabilities was also straightforward as DotDotPwn was able to detect the path traversal vulnerability. The standard path traversal test case template was used, and only the base URL supplied to DotDotPwn needed to be changed. Testing for the use-after-free vulnerability was also straightforward as AddressSanitizer was able to identify the use-after-free whenever it occurred. The standard use-after-free template was used, and only the arguments passed to the program needed to be changed. Testing for HTML injection (XSS) vulnerabilities was more difficult as our original test case only used XSS Me’s “Test all forms with all attacks” feature. This however, did not catch the XSS vulnerability present in our application as the vulnerability could only be triggered by an authenticated user. Our XSS test case needed to be modified so that it would only attempt to post XSS attack strings as an authenticated user. After this modification, our test case was able to detect the XSS vulnerability and properly report on it. Testing for SQL injection vulnerabilities was also difficult as sqlmap was unable to detect any vulnerabilities in our application. Instead, a test case was written to test an SQL injection vulnerability manually. Although the SQL injection vulnerability could not be automatically detected, this test case can still prove useful for detecting code regressions. If the bug is fixed, but then re-introduced, our tool will immediately alert the developers of this problem.

Author Contributions:

Project administration, A.C.; Software, M.L.; Supervision, Q.H.M.; Writing—original draft, M.L.; Writing—review & editing, Q.H.M. and A.C.

Funding:

This research was funded by Natural Sciences and Engineering Research Council of Canada grant number EGP 490684-15.

© 2019 by the authors. <license-p>Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/). Notwithstanding the ProQuest Terms and Conditions, you may use this content in accordance with the terms of the License.