eCultist

with Security, sometimes Sacrifies need to be made.

SQLi and Requirements Traceability (FISMA)

An important but often tedious part of completing a security testing engagement is writing the report.  When compiling the report, assembling and assigning traceability between identified vulnerabilities or weaknesses and security controls/requirements can be difficult to perform consistently.

This will be the first in a series of posts on assisting in maintaining traceability between identified security vulnerabilities/weaknesses and security controls/requirements.  Most of the requirements that I deal with are based on Federal Information Security Management Act (FISMA) and the requirements which flow from NIST Special Publication (SP) 800-53 Rev 3, Recommended Security Controls for Federal Information Systems and Organizations; consequently the traceability will focus on mapping vulnerabilities to those requirements.

The first traceability mapping that I am offering is mapping SQL injection (SQLi) to SP 800-53 Security Controls.  SQLi has many formal definitions (see CAPEC, CWE, and OWASP Top 10 references below for more details) but at the heart of the issue it is a flaw in which an adversary is able to manipulate the query that an application is submitting to a Database Management System (DBMS).  Since the specific details of the SQLi vulnerability may vary, some reasoning behind the proposed security control references are provided to allow the tester to make a determination if the suggested mapping is applicable.

SP 800-53 Security Controls

The mapping provided will map SQLi vulnerabilities/weaknesses to Revision 3 of NIST SP 800-53. Rev 4 is in draft status and this post will be updated following its release by NIST.  If SQLi is found within an application, it is recommended that these requirements should be marked as failing (or non-compliant);

  • AC-3 Access Enforcement; the application is not able to enforce access and information in accordance with the required policies.  An adversary is able to manipulate the queries to the database so that they can access resources beyond what is intended by the developers and system owners.
  • AC-4 Information Flow Enforcement; the application is not able to control the flow of information.  Approved authorizations may be implemented (even partially) but an adversary is still able to abuse the functionality of the application to read or modify the queries being executed by the DBMS.
  • AC-6 Least Privilege; if the exploitation of the SQLi flaw allows an adversary to do anything beyond reviewing the information for which they already have access to in the database, then the accounts which the application is using to interact with the database have been given excessive privileges.
  • CM-7 Least Functionality; if the application is vulnerable SQLi is possible that the application was not developed or implemented in such a way that the was not developed such that it only has the minimal functionality required to perform the designed tasks.  If an adversary is able to use functions and stored procedures that the staff has not removed as part of the hardware/software minimization process then this security control should be included as failing or marked as non-compliant.
  • SA-8 Security Engineering Principles; the application was most likely not designed in accordance with a system development life cycle which emphasizes security in the development of application.  SQLi can be removed from applications by implementing proper engineering controls early in the life cycle (e.g. requiring prepared statements and input validation, etc.)
  • SA-11 Developer Security Testing; if systemic flaws are identified in the application after the developer testing staff has completed testing, they the developer’s testing program either is not training to identify security vulnerabilities or the program does not have a mission to identify security vulnerabilities.
  • SC-7 Boundary Protection; if the application is externally facing or has been implemented in a hosting environment and there are no security controls which attempt to block or filter SQLi attacks, then it is possible that this security control should be included as non-compliant.
  • SC-18 Mobile Code; if exploitation of the SQLi flaw allows an adversary to inject or modify content on the application such that malicious scripts and/or resources can be included, then this requirement should be marked as non-compliant.
  • SI-10 Information Input Validation; if the application is vulnerable to SQLi then Input Validation either has not been implemented or has not been implemented properly.  Input Validation is robust technique to prevent SQLi if it has been implemented in the form of a while list.
  • SI-11 Error Handling; in the case of classic SQLi, the application returns error messages to the adversary which allows them to refine their attacks against the system (e.g. SI-11(b) and SI-11(c) apply to classic SQLi).  This requirement may not apply if the vulnerability is Blind SQLi or Inferred SQLi depending upon the detection mechanisms that the application has implemented (e.g. SQLi may not be considered to be an error condition which needs to be handled).

Besides simply providing a list of requirements which have failed as a result of the identification of SQLi within an application, in a report it is also useful to be able to provide a list of online resources about the attack/vulnerability/weakness.

Common Attack Pattern Enumeration and Classification (CAPEC)

Common Weakness Enumeration (CWE)

Open Web Application Security Project (OWASP) 2010 Top 10

  • A1-Injection. The instance of A1-Injection that is included as part of the OWASP Top 10, covers more than SQLi.  It covers the general case of injection; so LDAP injection, O/S command injection, etc are also included within the definition.

Comments are currently closed.