INJECTION TESTING & OTHER NASTIES-- PART II

In Part I the basic issues of SQL Injections was presented. However, there is more to do and their are other equally nasty issues.

• Blacklist versus Whitelist

  In the previous discussion I suggested that only:

  0 1 2 3 4 5 6 7 8 9 . -

  be allowed in a numeric field. This is a "white list" because it is what we "allow". Further, in the discussion I suggested that

  & > < / \ ; % = " # ( ) @ and '

  NOT be allowed in a character field. This is a "black list" because we "disallow" these characters.

  Generally, "white lists" are preferred over "black lists". This is because a black list assumes you know ALL the bad things that could happen -- YOU DON'T. Don't ever assume you know more than the intruder.

• Check User Input Lengths

  In addition the maximum length of the input MUST be a part of your defense. This is to prevent overflow exploits where the intruder overwhelms the application with data and then exploits the error condition. Unexpected long strings may indicate the intruder is attempting to add malicious code. So check the lengths as well as the contents.

• Clean or Dispose?

  When we encounter non-white list data or strings longer than allowed -- what action do we take. We can either:

  1. clean/scrub/sanitize

     Here we REMOVE the offending characters and let the process continue -- hoping we have removed the threat

     OR

  2. dispose of the transaction

     Here -- when we detect bad input -- we return an error message and TAKE NO ACTION. We make the user clean up the mess. We just dispose of the problem.

  There are obviously cases where the user has made an innocent typing mistake. With a benevolent approach, we tidy up their mess (i.e., remove the offending characters) and proceed with the work. Alternatively, in the malevolent approach, we spit the hated evil data back to the user and refuse to do work until they conform to our wishes (this is the extreme "all data is evil" viewpoint).

  I am personally of the malevolent school. While I may have to suffer some complaints from users (e.g., "you are awfully picky") -- I sleep better. An alternative to viewing ourselves as the malevolent Attila the Hun is to ascribe our motives to the benevolent Benjamin Franklin and his line that "an ounce of prevention is worth a pound of cure". Besides we can always tell the user WHY we are forbidding them from entering goofy data with a few computer disaster stories where a crummy user data blew up the system and everbody lost their job. They generally buy these stories. Secondly I want to impress upon the malicious intruder that I am watching their every move and intend to deal with them harsely -- Teddy Roosevelt's "speak softly and carry a big stick" approach.

• Rolling Your Own -- A White List

  Here is some code snippets to do edit tasks and discussions of the options available:

  • Integers

    Generally we have THREE issues:

    1. Empty String

       The first task is to test the existence of ANY characters at all

    2. Length of the User Input

       Secondly, does the size of the user input excedd the maximun length expected

    3. Digits Only

       Third, does the user string contain ONLY the digits 0-9?

    Enter a integer value to be validated Enter the list of valid characters Enter the maximum number of characters Result:

    Enter some variations and watch.

    Here is the javascipt code:
    function edit_int(str,allow,max) { if (str.length < 1) return "false, no data -- an empty string"; if (str.length > max) return "false, too many characters, maximum of "+max.toString(); en=0; em=""; for (i=0;i<str.length;i++) { this_char=str.substr(i,1); ok=0; for (j=0;j<allow.length;j++) if (this_char==allow.substr(j,1))ok=ok+1; if (ok==0) { en=en+1; em=em+"<br>"+"At string location "+i.toString(); em=em+" found the non-allowable character "+this_char; em=em+" which is ASCII character number "+this_char.charCodeAt(0); } } if (en==0) return "true, user data is OK all characters are allowable"; else return "false, non-allowable characters found: "+em+"<br>"+en.toString()+" errors found."; }

  • Accounting/Finance Numbers

    While numeric values are often extremeley difficult to edit because of the myriad possibilities, accounting/finanace data is a highly constrained of set of rules. Specifically we will test for:

    1. Exactly one minus sign AND it must be the first character
    2. Exactly one decimal point and it must be followed by two digits
    3. All other characters must be 0,1,2,3,4,5,6,7,8 or 9
    4. Length cannot exceed 18 (based on the SQL assumption that decimal (numeric) data would be (18,2) for our financial accounting assumtion (this assumption may NOT apply if you are trying to restrict the maximum amount on an entry)
    5. Length cannot be less than 3 characters (i.e., ".00" is the smallest number allowable, and both "0" and "00" are both invalid because they have no decimal)
    
    

    Enter a accounting/financial value to be validated Enter the maximum number of characters Result:

    Here is the javascript code:
    function edit_af(str,max) { if (str.length < 1) return "false, no data -- an empty string"; if (str.length < 3) return "false, too few characters found less than 3"; if (str.length > max) return "false, too many characters, maximum of "+max.toString(); minus_count=0; for (i=0;i<str.length;i++) { this_char=str.substr(i,1) if (this_char=="-") minus_count=minus_count+1; } if (minus_count > 1 ) return "false, too many minus signs"; if (minus_count==1 && str.substr(0,1)!="-") return "false, minus sign in the wrong place"; decimal_count=0; for (i=0;i<str.length;i++) { this_char=str.substr(i,1) if (this_char==".") decimal_count=decimal_count+1; } if (decimal_count > 1 ) return "false, too many decimal points signs"; if (decimal_count==1) { true_loc=str.length-3 if (str.substr(true_loc,1) != ".") return "false, decimal is in the wrong place"; } en=0; em=""; allow="0123456789.-" for (i=0;i<str.length;i++) { this_char=str.substr(i,1); ok=0; for (j=0;j<allow.length;j++) if (this_char==allow.substr(j,1))ok=ok+1; if (ok==0) { en=en+1; em=em+"<br>"+"At string location "+i.toString(); em=em+" found the non-allowable character "+this_char; em=em+" which is ASCII character number "+this_char.charCodeAt(0); } } if (en==0) return "true, user data is OK all characters are allowable"; else return "false, non-allowable characters found: "+em+"<br>"+en.toString()+" error(s) found."; }

  • Character Data -- White List

    Now for the tough one. Taking the malevolent approach we will provide an allowable white list -- NOT a disallowable black list. We provide a list of valid characters with NO other constraints. We will specify what to do with the single quote (note the checkbox).

    Enter a character string to be validated Enter the list of valid characters   Enter the maximum number of characters Escape the single quote: Yes (adds the single quote to the white list -- if not found -- AND escapes ALL occurences) Result:

    
    Here is the javascript code:
    function edit_char(str,allow,max) //****************** EDIT CHARACTER { if (str.length < 1) return "false, no data -- an empty string"; if (str.length > max) return "false, too many characters, maximum of "+max.toString(); //*** check to be sure single quote is on the allowable list -- if not add it if (window.document.aform.chk1.checked) { check_for_sq=allow.indexOf("'"); if (check_for_sq < 0) { allow=allow+"'"; window.document.aform.str7.value=allow; } } en=0; em=""; for (i=0;i<str.length;i++) { this_char=str.substr(i,1); ok=0; for (j=0;j<allow.length;j++) if (this_char==allow.substr(j,1))ok=ok+1; if (ok==0) { en=en+1; em=em+"<br>"+"At string location "+i.toString(); em=em+" found the non-allowable character "+this_char; em=em+" which is ASCII character number "+this_char.charCodeAt(0); } } // //*** single quote handling // if (window.document.aform.chk1.checked) { // //*** replace them all // start_loc=0 while (str.indexOf("'",start_loc) > -1) { loc=str.indexOf("'", start_loc); temp1=str.substring(0,loc) next_loc=loc+1; temp2=str.substring(next_loc, str.length) str=temp1+"''"+temp2; start_loc=loc+2; } window.document.aform.str6.value=str; } if (en==0) return "true, user data is OK all characters are allowable"; else return "false, non-allowable characters found: "+em+"<br>"+en.toString()+" error(s) found."; }

• Other Injections
  • Meta-Refresh Injection

    Another common attack is to insert a "meta refresh" tag into a database via a form input field. When the data is subsequently displayed in the browser, the page is redirected to another page. The syntax of the meta tag is:

    <meta http-equiv="refresh" content="integer;url=some web site">

    If encountered on the HTML page, the page is "refreshed". The content parameter provides two items:

    1. an integer that says how long to wait (in seconds) before the page is redirected
    2. a web address is specified in the "url" field that defines where the page will be redirected

    All the attacker needs to do is get the tag into the database, then wait and ROFLMAO as the site's content is corrupted.

    A guest book table might have the follwing structure:

    
    idn int IDENTITY (1,1),
    fname varchar(20),
    lname varchar(20),
    comm  varchar(70),
    date_time varchar(25) primary key (idn))
    
    

    1. Click here to create table, and load some data
    2. Click here to see the resulting table (Pop-ups must be turned OFF to see the table)
    3. Click the "Close this Window" link on the popped up page.
    4. Now let us make an entry in the quest book:
    
    First name
    Last name
    Comment
    
    
    5. Now click here to see the resulting with the posting in Step 3 in the table. Wait a few seconds and ... the page gets redirected.

    Zowie!. This in and of itself is NOT a big deal. The malicious refresh does exactly what it is suppose to do. The real issue if that the INSERT program used in Step 4 uses parameters! True, there is no server side white-listing or black-listing, but to those that say that parameterization is adequate for preventing injections are wrong on this count. It may prevent an SQL injection because the parameters are NOT executed. But it does NOT prevent a meta refresh injection.

    So either a white-list with no "<" and no ">" OR a blacklist with "<" and ">" will prevent the problem.

  • Script Injections

    This is a variation where the attacker inserts script code into a table that gets executed. Consider the following script:

    <script>javascript:alert(String.fromCharCode(39,72,69,76,76,79,39));</script>

    NOTE: String.fromCharCode(39,72,69,76,76,79,39) = 'HELLO'

    1. Click here to create table, and load some data
    2. Click here to see the resulting table (Pop-ups must be turned OFF to see the table)
    3. Click the "Close this Window" link on the popped up page.
    4. Now let us make an entry in the quest book:
    

    First name
    Last name
    Comment
    
    
    5. Now click here to see the resulting with the posting in Step 3 in the table. It talks to us! Fortunately, it just says "HELLO"

    Again this injection was successful even though the SQL was parameterized. So either a white-list with no "<" and no ">" OR a blacklist with "<" and ">" will prevent the problem.