Skip to content

Instantly share code, notes, and snippets.

@Stacksmashers101
Created April 15, 2021 04:30
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save Stacksmashers101/c6b9ea92f42c23473170bb3acc8fc5fe to your computer and use it in GitHub Desktop.
Save Stacksmashers101/c6b9ea92f42c23473170bb3acc8fc5fe to your computer and use it in GitHub Desktop.
Injection attacks occur when data is sent to an interpreter which contain unintended commands with the data that are run by the interpreter. The most common injection flaw in web applications are SQL, but it is also possible to have injection flaws effect LDAP queries, XPath queries, and OS commands. We are going to cover SQL injections, but the techniques used to validate and control the input to the SQL interpreter are applicable to the other types of injections.
the same can be performed in b2evolution CMS 7.2.3 in the User Registration section, leading to remote code execution via SQL Injection (SQLi)
In the earlier Database chapter you saw the use of the cfqueryparam tag. It is one of the simplest steps you can take to help prevent SQL injection attacks on your web application, but it can only be used in the WHERE clause, INSERT values, and UPDATE values of an SQL statement. Other parts of an SQL statement require more work to protect against it. The example below is using cfqueryparam, but it is still susceptible to SQL injection attack through the ORDER BY clause.
<cfparam name="url.state" default="" />
<cfparam name="url.orderby" default="LASTNAME" />
<cfquery name="request.listing" datasource="cfartgallery">
SELECT FIRSTNAME, LASTNAME, EMAIL, THEPASSWORD, ADDRESS
FROM table
WHERE 1=1
<cfif Len(url.state)>
AND STATE = <cfqueryparam cfsqltype="cf_sql_varchar" value="#url.state#" />
</cfif>
ORDER BY #url.orderby#
</cfquery>
By validating the URL parameters against a list of values we know to be good while changing all references from the URL scoped variables to variables we explicitly set, the SQL injection vulnerability is removed. The cfparam's were also removed because they are now redundant from the use of StructKeyExists() in the if statements.
<cfscript>
// list of valid values
variables.validStates = "CA,CO,DC,FL,GA,NM,NY,OK,SD";
// check what was passed against list of valid values
if ( StructKeyExists(url, "state") AND ListFind(variables.validStates, url.state) ) {
variables.state = url.state;
} else {
variables.state = "";
}
if ( StructKeyExists(url, "orderby") AND ListFind(variables.validOrderBys, url.orderby) ) {
variables.orderby = url.orderby;
} else {
variables.orderby = "LASTNAME";
}
</cfscript>
While the above code removes the SQL injection, it can be made better. First, remove the hard coded list of States and reuse the query used to generate the list of States for the filter in the validation. Next, change the ‘Order By’ values from columns used in the database to a structure that references them. While this example has some pretty common and guessable columns names, the main purpose is to make it more difficult for an attacker to get knowledge of the database structure the web application is using.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment