SQL Injection

Top  Previous  Next

Database applications are vulnerable against the SQL Injection attacks unless necessary precautions are taken. An attacker who knows or guesses the database structure can access to the information which normally not allowed to do, or can cause serious damages to the stored information by entering unexpected input.

Although MoreMotion provides necessary tools to mitigate them, an MoreMotion application can also be a subject to such attacks in case of the provided tools are not utilized properly.

Example:

DELETE FROM EMPLOYEE WHERE ID = 

  @vof(ID)  

 

If the user enters such a value to the form field ID:

 
[5 OR 1 = 1 ]

 

The resolved SQL will be:
 

DELETE FROM EMPLOYEE WHERE ID = 

  5 OR 1 = 1  

 

which naturally may lead to a catastrophe.

 

More information about the SQL Injection...

Such attacks can be avoided by using data-type specifiers ('n:' , 'b:') and the 'q:' specifier for MScript symbols that refer to the user input.

DELETE FROM EMPLOYEE WHERE ID = 

  @vof(n:ID)

 

If the resolved value for the ID is not a number, since we explicitly declared with 'n:' specifier that we expect a number value, a number format conversion will occur and the SQL will not be executed.

 
Logically, the data entered into the input fields of a form should be verified before the form submission. But you cannot stop an attacker to manipulate the commands in the address bar of the browser as follows:

display.doms?pg=ShowEmployee&ID=15   (Regular command)

display.doms?pg=ShowEmpoyee&ID=15 or 1 = 1  (Manipulated Command) 

 

Therefore it is much safer to use the 'n:' specifier if a number is expected and 'q:' specifier if a string is expected when referring to the users input.

SELECT * FROM PRODUCTS
  WHERE ID = @vof(n:ID) OR NAME = '@vof(q:NAME)'

 

Built-in precautions

Regardless of 'q:', 'n:' and 'b:' specifiers are used, MoreMotion will take necessary precautions by applying the following rules:

Rule 1: If an MScript function is used inside the apostrophes (inside the SQL string constant), the apostrophes existing in  the resolved value will be doubled.

Rule 2: If an MScript function is NOT used inside the apostrophes and the preceding non-blank character on the same line is one of '=', ',' or '(' the resolved value is checked and if it contains special characters or blanks the execution of SQL is blocked with an error exception.

For the cases these rules do not apply, the developer must use the necessary specifiers explicitly.

Examples:

  SELECT * FROM PRODUCTS
  WHERE 

    NAME = '@vof(NAME)' @// Rule 1. The function is inside the apostrophes. (SAFE)

    AND ID = @vof(ID)   @// Rule 2. Preceding non-blank character is '='. (SAFE)

 

 

 

  INSERT INTO EMPLOYEE

    (ID, NAME) VALUES (

    @vof(ID), '@vof(NAME)' )  @// None of the rules apply. (NOT SAFE!)

    @vof(n:ID), '@vof(NAME)') @// Precaution is taken with 'n:' specifier. A number value is expected.