SQL Injection, CISSP and Software Development

One of the topics of the CISSP is software development which covers the web application environment and vulnerabilities such as SQL Injection. SQL injection in its simplest form and the derivatives that have came about are probable the most effective attack tool in the hackers toolbox, whether black or white hat. The vulnerability is well know, as is the methods to mitigate the vulnerability, so why is there a problem? and why is the vulnerability still so effective.

A recent Ponemon study found:-

Measures to prevent SQL injection attacks are also lacking. Despite concerns about the threat, 52 percent do not take such precautions as testing and validating third party software to ensure it is not vulnerable to SQL injection attack. 

and that

44 percent of respondents say their organization uses professional penetration testers to identify vulnerabilities in their information systems but only 35 percent of these organizations include testing for SQL injection vulnerabilities. 

It also concluded

it used to require a high-level of expertise to construct a malicious query and conduct an SQL attack. Now the internet is flooded with tools that allow inexperienced individuals to obfuscate malicious queries, making it easy to be a bad guy, and even more difficult for SQL security measures to detect malicious queries.

The results are what I expected, I would a bit more into the detail and say the root cause of SQL vulnerabilities is the programming behind the applications. The developers don't understand SQL injection and don't know how to code to mitigate against such attacks.

History of SQL

The SQL injection has formally been around since Rain Forrest Puppy (aka Jeff Forristal) published papers in 1998 on the technique (http://phrack.org/issues/54/8.html#article). SQL Injection is as the name suggests a code injection attack used on data driven applications, such as web applications but can be used to attack any SQL database. In the attack malicious SQL statements are inserted into an entry field for execution when the page is submitted to the application.

Mitigating

The methods for mitigating SQL injection are well documented, the main methods are forms of input validation and restricting commands that can be run.

• Parameterized statements
• Enforcement at the coding level
• Escaping
• Pattern check
• Database permissions

The Continuing problem

The problem is still very prevalent despite being widely known and methods of mitigating have been identified. The problem is prevalent in web applications; these are typically developed by coders who more experienced with design and usability issues than with business logic and server communication. Often tools and frameworks are used to develop application are using sophisticated front ends that auto generate code to drive the application, including the code to access databases.

In the past, I have hand coded applications using text editors as simple as notepad and used development environments such as Dreamweaver, which is not unique in its approach or particular bad, but the designer drags elements on to the screen, creates a layout and then enters details of the database to which it is to communicate and the code is generated automatically by the application to access the database.

My experience is that the application generated code is a lot more complex and larger than it needs to be to do the same function that I can write in a simple text editor. Further I find that web application developers and database application developers are not software engineers (programmers) and not trained in coding techniques in the same way. Often at University and colleges they will use examples of industrial applications for web and database front end development to give them experience of the tools they will use when employed before they really understand hand coding.

The problem with web applications will continue whilst developers are not aware of good secure programming practice and the tools used in development are not generating secure code.

Secure (Software) Development Lifecycle

A Software Development Lifecycle (SDL) is essentially a series of steps, or phases, that provide a model for the development and lifecycle management of an application or piece of software. The methodology within the SDL process can vary across industries and organizations, but standards such as ISO/IEC 12207 represent processes that establish a lifecycle for software, and provide a mode for the development, acquisition, and configuration of software systems. The intent of a SDL process it to help produce a product that is cost-efficient, effective, and of high quality. Once an application is created, the SDLC maps the proper deployment and decommissioning of the software once it becomes a legacy. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release, and maintenance (response). The maturity of the SDL can be measured with using a Software Assurance Maturity Model (SAMM) such as the OpenSAMM which has become part of the Open Web Application Security Project (OWASP).

Security is required to be consider all stages if security is to be built into the development rather than bolted on afterwards. If security is considered at the project initiation stage, it becomes part of the functional requirements, considered at the design stage, secure techniques will need to be used at the development stage and will be a requirement to be considered during testing and acceptance of the software. Microsoft have a good resource on Secure Development Lifecycle (https://www.microsoft.com/security/sdl/default.aspx) on their website.

Building security in, especially once the secure development lifecycle has matured will be easier and cheaper than trying to bolt on security after the functional testing has been completed.

Separation of testing and development

It is understand that developers are often not the best testers of a product, nor are end users. Both developers and end users will use cases they know will work or fail due to business logic and fail to use test cases that were not expected by the developers or expected when the functional requirements were generated. Testing application for functionality and security require two different approaches and less experienced the tester is the more likely they will not be able to test security requirements fully.

Applications should be written by developers who understand secure programming, then moved to a separate testing environment where security is tested as one of the acceptance criteria of the project by experienced testers. After certification and accreditation against the requirements, which include security, it is then moved into the production environment.

Open Web Application Security Project

The Open Web Application Security Project (OWASP) is a worldwide not-for-profit charitable organization focused on improving the security of software. OWASP  build documents, tools, teaching environments, guidelines, checklists, and other materials to help organizations improve their capability to produce secure code. It provides tools for developers and tester to use to develop and test secure applications and should be considered the first port of call for an organisation wishing know more about web application secure coding and how to test the security of an application.

Conclusion

To wrap this article I will reiterate that the root cause of SQL Injection vulnerabilities is poor application development caused by lack of secure programming knowledge by developers. During the initial phase of an application project security is not considered as part of requirement development, this causes security to be ignored at the other stages of the software development lifecycle.

Additionally lack of use of skilled tester in the testing stage is not identifying the vulnerabilities, allowing through into the production environment. Once into production the increased number of attacks by script kiddies using automated tools that obfuscate attacks make it hard for the application to be defended.

I would recommend

• The use of a secure development lifecycle to build security into the development project as a functional requirement.
• Auto-generated code should be reviewed by a skilled program, so it is optimised and to ensure security requirements are part of the functionality the code delivers.
• The use of code review by experienced reviews who understand security requirements and secure programming practice. his can be done by 3rd parties and the use of tools to help with the analysis
• Better education of web developers into secure programming techniques.
• Organisations sourcing 3rd party developers need to check secure programming knowledge of those developers.
• The use of skilled software testers to test the application for all vulnerabilities.