{% set baseFontFamily = "Open Sans" %} /* Add the font family you wish to use. You may need to import it above. */

{% set headerFontFamily = "Open Sans" %} /* This affects only headers on the site. Add the font family you wish to use. You may need to import it above. */

{% set textColor = "#565656" %} /* This sets the universal color of dark text on the site */

{% set pageCenter = "1400px" %} /* This sets the width of the website */

{% set headerType = "fixed" %} /* To make this a fixed header, change the value to "fixed" - otherwise, set it to "static" */

{% set lightGreyColor = "#f7f7f7" %} /* This affects all grey background sections */

{% set baseFontWeight = "normal" %} /* More than likely, you will use one of these values (higher = bolder): 300, 400, 700, 900 */

{% set headerFontWeight = "normal" %} /* For Headers; More than likely, you will use one of these values (higher = bolder): 300, 400, 700, 900 */

{% set buttonRadius = '40px' %} /* "0" for square edges, "10px" for rounded edges, "40px" for pill shape; This will change all buttons */

After you have updated your stylesheet, make sure you turn this module off

How to Test for SQL Injection Bugs - Step 2

by Serge Truth on January 18, 2011

Test SQL InjectionSQL Injection is a common type of web database related vulnerability.   SQL injection is common to web site applications that interact with a database backend.  These sites construct SQL commands or queries based on user input.  For example they might search a product database based on a description a user typed in a web form.  An application is vulnerable to SQL injection when it builds SQL queries without filtering the user's input, without using store procedure, or without binding parameters variables.  This can lead to an attacker adding additional clauses, conditions, or even commands that execute along the original query. Attackers can use SQL Injection bugs to execute different types of attacks such as data theft and tampering, authentication bypass, information disclosure, and elevation of privileges.

Below is a summary of steps needed for testing for SQL injection bugs

  • Step 1:  Understand SQL injection attack scenarios
  • Step 2:  List high risk components and entry points
  • Step 3:  Start testing and exploring
  • Step 4:  Tune of test data
Step 2: List High Risk Components and Entry Points

The next step for SQL Injection testing is to list all the places where code builds SQL statements from user supplied input; to understand how and where our application manipulates statement and talks to a database.  The most common are:

  • Search web pages
  • Profile-related web pages
  • Authentication forms
  • E-Commerce or financial account-related pages
  • Database interaction public API's and DCOM methods
  • Database system-level clients

Identify all high risk components

After understanding the details of SQL Injection, list their high risk components in a table that includes the method that hosts the code, the name of the query string if available, and the variable names that influence the construction of the query 

Look at code like the one shown in the scenarios above; code where SQL statements are built using web input.  Then list all of these web pages as high risk components.

Match High Risk Components with Entry Points

After listing all areas in the application where SQL statements are built at run-time, you  must identify the ways in which data gets to these places.  For example, you listed a web page named "search.asp" above that constructs SQL statements dangerously.  Here you list how this page gets its input; what are its entry points.  Keep in mind that entry points can be both intended (expected by the program or application) and unintended (unexpected by program or application).  A common list of entry points for SQL injection high risk components include:

  • URL bar contents
  • Web form input values
  • Web service methods
  • Network packets
  • Public API's
  • DCOM methods
  • Application UI text fields
  • Inter Process Communication pipe

The first three are the most common entry points for web services and application.  Nonetheless, always look for new entry points additional entry points not listed here.  Make sure that the data manipulated by the component at risk is not passed by any other means.

Ideally by the end of step 2 you will have a table like the one shown above to systematically guide test execution.

Topics: developer guidance, application security

Most Recent

What's Trending

Featured Resource