This SmartAttack reports each page on which it finds SQL error message vulnerabilities.
An attacker might gain administrative control of your web application or database by using specially crafted SQL queries. It is also be possible to gain remote access to restricted information via queries to your database.
An attacker can execute arbitrary commands through malformed SQL injection strings. This would allow the attacker to set up a backdoor or persistent point of access into your network. Also, it might be possible to expose confidential customer information or business records by compromising your back-end database.
Improper input validation is the most common cause of this vulnerability.
Applications sometimes pass user-supplied input in SQL statements without filtering the input first. Tests with this SmartAttack inject specially formatted strings designed to create SQL statements that are not valid.
This SmartAttack can fault inject fields in HTTP queries (which typically correspond to fields in forms), particular HTTP headers, and cookies. By default, it injects fields in HTTP queries.
This SmartAttack walks the traversal and identifies HTTP requests which are candidates for fault injection. For each candidate request, the SmartAttack sends a series of fault-injected requests, trying a variety of problematic strings. The SmartAttack identifies a failure when it detects that the application generated an SQL error.
This SmartAttack can be configured to recognize error pages that are received in response to fault-injected input, allowing it to ignore legitimate responses that might otherwise appear to be faults.
SQL Injection is a type of attack that allows a remote user to pass SQL (Structured Query Language) commands and strings to a back-end database. The general risks associated with remote SQL injection are the ability of an attacker to read, modify or corrupt database records, or execute arbitrary commands on your database server. By exploiting SQL injection vulnerabilities an attacker can gain access sensitive information that helps disclose other vulnerabilities in the network, and potentially gain full control over the system on which the database is installed.
Any web application that includes a SQL interpreter is potentially vulnerable to SQL attacks, and should be configured carefully. SQL Injection involves the ability to pass malicious scripts and commands as a application parameter, resulting in the web application forwarding a dangerous script to the database or executing malicious commands.
In general, SQL injection vulnerabilities are fairly common and easy for attackers to identify, and frequently affect scripts and objects of all varieties such as CGI scripts, JSP pages, ASP, PHP applications, or any type of application with the capability to store records or query a database.
1. Create a traversal that represents the target application, or a subset of specific pages in the application.
2. Create a new job or open an existing job.
3. Add the traversal created above to the job.
4. Add this SmartAttack to the job.
5. Set the parameters or accept the defaults in the job. (See below.)
6. Run the job.
Inject Form Fields (Boolean)
This parameter controls whether HTTP
query fields will be injected. By default, all fields will be injected.
The default value is "true".
Inject Cookies (Boolean)
This parameter controls whether
individual cookies in the "Cookie" header (if present) will be
injected.
The default value is "false".
Inject A Field At A Time (Boolean)
This parameter specifies that fault
injection should happen by injecting one item at a time instead of all at once.
The injectable items are elements of GET or POST queries, individual headers,
or cookies. Field-at-a-time injection can take considerably longer but might
uncover vulnerabilities that would not be found with all-at-once injection.
(The reason for this is that some forms employ input validation only on some
but not all fields. With all-at-once injection, if any of the fields reject an input, vulnerabilities in unvalidated
fields will remain undetected.)
The default value is "true".
Stop On First Fault (Boolean)
This parameter controls whether the
SmartAttack will stop after finding the first injection value that reveals a
vulnerability in a form, or continue to find all injection values that produce
faults.
The default value is "true".
errorPageMatchExpr (regular expression)
This parameter specifies a regular
expression pattern which will be used to identify error pages by matching a
string in their content. Such error pages will be excluded from fault
detection. This mechanism is useful as a way of eliminating false positives.
The default value is "" (no regular expression).
URLs To Skip (list of regular expressions)
This parameter specifies a list of
regular expression patterns which will be matched against the URL of each HTTP
request that is a candidate for fault injection. If the URL matches one of the
patterns in the skip list, the request will not be fault injected.
The default value is an empty list.
Fields To Skip (list of regular expressions)
This parameter specifies a list of
regular expression patterns which that will be used to identify form field and
cookie names that should be excluded from fault injection.
The default value is an empty list.
Report Individual Successes (Boolean)
This parameter controls whether the
SmartAttack will issue a "Pass" report item for every request (form)
that was injected without vulnerabilities being found. By default, the
parameter is false.
The default value is "false".
Injection String Groups (enumeration)
This parameter controls which subsets
of fault injection strings are used in a test. The strings are divided into "Set
#1," "Set #2," "Set #3," and "Set #4," where
the first group consists of just a few fault injection values (those that are
typically the most effective) and the following groups add more strings. The
fourth group is very large and should be run only when comprehensive testing is
the priority and the amount of time consumed by the job run is not. The groups
are mutually exclusive and not supersets of one another, and you can choose to
run some and not others. Specifying no groups results in all strings being
used.
The default is to use the following fault injection string groups: ["Set
#1", "Set #2", "Set #3"].
Max Traversal Restarts (integer)
This parameter controls whether and
how many times a fault injector will attempt to restart a traversal if fault
injection interferes with replaying the traversal. The parameter can be set to "0"
to prevent the traversal from being restarted.
The default value is "4".
Detection Value File (string)
This parameter specifies the name of
the file that contains the fault detection strings for this SmartAttack. This
SmartAttack identifies faults by matching observed responses to the strings in
this file.
The default value is "data_FD_SQLParser.txt"
(the file).
Injection Value File (string)
This parameter specifies the name of
the file that contains the fault injection strings for this SmartAttack. Each SmartAttack
that involves fault injection is associated with its own unique file (set of
inputs), except for Buffer Overflow and Format String, which do not require separate
sets of inputs.
The default value is "data_FI_ SQLParser.txt"
(the file).
Start SmartAttack After Traversal (Boolean)
This is an advanced parameter that controls whether the SmartAttack processing (concurrent browsing, in this case) begins during the traversal or after the traversal has completed. The default is false, meaning that the processing will start during the traversal. In cases where traversals are unable to complete due to the effects of SmartAttack processes during concurrent browsing, setting this parameter to true will postpone concurrent browsing until after the traversal has completed, which allows all of the injectable requests in the traversal to be collected and injected after the traversal is over. While this allows all of the concurrent browsing to occur, it might not occur in the same context or state that it would have during the traversal. Default = "false"
Skip First N Injectable Requests (integer)
This is an advanced parameter that
specifies the number of the injectable request on which fault injection will
begin, allowing previous requests to be exempted from fault injection. In some
cases, traversals are unable to complete due to fault injection. In such cases,
this parameter can be used to pick up fault injection after the point where the
traversal was compromised in a previous job run. Because report items for
fault injector SmartAttacks identify the number of each request being injected,
you can identify the field where you wish to start and enter that number in
this parameter.
The default value is "0".
Headers To Inject (list of strings)
This parameter indicates which HTTP
headers (if any) will be injected. The parameter should specify a list of
strings with HTTP header names. By default, no HTTP headers will be fault
injected. Valid headers are "Accept", "Accept-Charset", "Accept-Encoding",
"Accept-Language", "Allow", "Authorization", "Cache-Control",
"Connection", "Content-Encoding", "Content-Language",
"Content-Length", "Content-Location", "Content-MD5",
"Content-Range", "Content-Type", "Cookie", "Date",
"Expect", "Expires", "From", "Host", "If-Match"
"If-Modified-Since", "If-None-Match", "If-Range",
"If-Unmodified-Since", "Last-Modified", "Location",
"Max-Forwards", "Pragma", "Proxy-Authorization", "Range",
"Referer", "TE", "Trailer", "Transfer-Encoding",
"Upgrade", "User-Agent", "Via", and "Warning".
The default value is an empty list.
Skip Equivalent Requests (Boolean)
This parameter controls whether the
SmartAttack will skip fault injection for requests that are equivalent to ones
that have already been injected. Requests are considered equivalent if their
query element names are the same, even if the query values differ.
The default value is "true".
Distinguish Request Cookies (Boolean)
This parameter only takes effect if
the skipEquivalentRequests parameter is true. This parameter controls whether
the SmartAttack will consider cookie values when determining whether requests
are equivalent.
The default value is "false".
Max Requests With Same URL (integer)
This parameter sets the maximum
number of requests that will be injected that have the same base URL, but
different queries.
The default value is "15".
This SmartAttack generates the following report output:
The following recommendations will help to mitigate the risk of SQL injection attacks:
· Monitor your production applications for the latest security vulnerabilities and bugs.
· Keep up to date on patches and security fixes as they are released by the vendor or maintainer
· Limit the types of characters and strings that can be passed as application parameters by configuring native application filters.
· Avoid using external SQL interpreters.
· Audit your applications frequently for points where HTML input can access interpreters.
· Ensure proper input validation is performed wherever user supplied data can be supplied, regardless of the application's relationship to a back-end database.
· Avoid the use of dynamic SQL or PL/SQL and use bound variables whenever possible.
· Enforce strict limitations on the rights to database access.
· Remove any sample applications or demo scripts that allow remote database queries.
Use structured exception handling to catch errors and prevent their exposure to the client.
If errors occur while the user is connecting to the database, be sure that you provide only limited information to the user. Detailed error SQL error messages help a malicious user reverse engineer your database structure and determine the presence or absence of database tables. Such errors also help them to refine their attacks against your database.
In order to protect against exposing sensitive information you need to implement specific security measures to catch SQL based errors and redirect users to a generic error page.
For PHP, you can control whether or not detailed error messages are presented to the client by setting the following directives. The configuration below will log errors to your server's error log, but not display the errors to the client:
See also the PHP Manual's section
Error Handling and Logging Functions
http://us2.php.net/errorfunc,
Implementing a global exception handling mechanism can enhance the security and usability of a web application by redirecting users to a custom error page whenever handled and unhandled exceptions occur. With ASP.NET you can handle errors either on the Application level, via global.asax, or on the page level via specific error handling code. Also employ mechanisms to redirect users to a custom error page whenever an exception occurs.
To set up a custom error page it is necessary to edit web.config and add a customerrors tag if it does not already exist.
The mode attribute has three settings: "On," "Off," and "RemoteOnly." When set to "On" the custom error page will be used anytime an exception occurs. When the attribute is set to RemoteOnly, it will only redirect to the custom error page in the event the client does not originate from the local machine. Local users will continue to see detailed error messages.
Use code-level structured exception handling to trap exceptions and prevent diagnostic or detailed error messages from being displayed. Implement a global exception handling mechanism in global.asax to catch any exceptions that aren't handled in your code.
There are two kinds of exceptions in Java, namely checked and unchecked exceptions.
If the client code cannot do anything, then make it an unchecked exception. If the client code will take some useful recovery action based on information in the exception, make it a checked exception.
An example of vulnerable code is below.
In this example, the details of the exception are propagated, which might cause a leak of private information.
1. Encapsulation
Never let implementation-specific exceptions propagate to the higher layers. For example, do not propagate SQLException from the data access code to the business objects layer.
This example converts SQLException or LDAPException to RuntimeException. If SQLException or LDAPException occurs, the catch clause throws a new RuntimeException. The execution thread is suspended and the exception gets reported. However, this does not corrupt the business object layer with unnecessary exception handling, since specific exceptions relating to LDAP or SQL should be handled in the tier of code that deals with it.
In addition to the above scheme, production systems should NEVER use the default error page. A custom error page should be created using the <error-page> directive in web.xml. For example, place the following within your <web-app> to catch all JSP compilation/runtime exceptions and redirect them to your custom error page:
<error-page><exception >java.lang.Exception</exception> <location>/safeErrorPage.html</location></error-page>
More information can be found at http://www.oracle.com/technology/sample_code/tech/java/codesnippet/servlets/handlingservletexceptions/handlingservletexceptions.html#how1
http://www.objectsource.com/j2eechapters/Ch18-Exception_Handling.htm
2. Clean up
Resources like database connections or network connections should be cleaned up. Even if they are only unchecked exceptions, clean up the resources using try - finally blocks.
3. Identify sources of exception
Identify all possible uncaught runtime exceptions early in the development lifecycle, then examine and modify the code to ensure that it does not provide any opportunities for hackers.
Also in web.config, set pageOutput="false" on the <trace> element to prevent trace output from being displayed. You should make the changes to a machine level web.config file to ensure that the configuration is used for all your applications on the server. Place the <trace> element inside a <location> element and set allowOverride to false:
OWASP Guide to Building Secure Web
Applications
http://www.owasp.org/
OWASP Frequently Asked Questions on Web Application Security http://www.owasp.org/documentation/appsecfaq
SQL Server Security Site
www.sqlsecurity.com
Thwarting SQL Web Hacks: Fixing insecure Web code is up to site owners http://www.varbusiness.com/sections/News/breakingnews.asp?ArticleID=49029
Detection of SQL Injection and
Cross-site Scripting Attacks
http://www.securityfocus.com/infocus/1768
SQL Injection Walkthrough
http://www.securiteam.com/securityreviews/5DP0N1P76E.html
SQL Injection in Oracle
http://www.integrigy.com/info/IntegrigyIntrotoSQLInjectionAttacks.pdf