CS 318 - Week 12 Lecture - 4-17-13

*   of MANY security concerns,
    today we want to especially address:

    Cross-site scripting (XSS)
    SQL Injections

*   these are vulnerabilities that can be exploited
    when the application-tier programmer does
    not appropriately validate/sanitize/etc.
    input from the user;

*   the recommended attitude for the application-tier
    programmer:
    ANY untrusted data -- whether from an HTTP
    request, URL parameters, form fields,
    cookies, headers, etc. --
    should always be treated AS IF it might contain
    an attack --
    that is, you should not send it anywhere without
    taking steps to make sure any attacks are
    detected and neutralized;

a bit more on XSS - Cross-site scripting

*   XSS - cross-site scripting -
    is when the user can enter scripting commands,
    and they are able to be included and executed
    in some way

    ...when user-entered scripting is entered and
    processed;

*   how do you address this?
    CHECK the user-entered data in some appropriate
    fashion BEFORE inserting it into a response
    or into another page or pass it on;

    *   this might mean "stripping" tags,
    *   or neutralizing executable bits
        (turn < into <)
    *   or quitting with extreme prejudice
        if you think something "bad" has come 
	in, etc.

*   March 2012 IEEE Computer article
    "Defending against Cross-Site Scripting Attacks"
    Shar and Tan, pp. 55-62

    broadly categorizes these into 3 categories:	
    *   reflected
    *   stored
    *   DOM-based

    *   reflected (or nonpersistent) XSS holes are
        present in an applicaton when it references
	accessed user input in the outgoing web page

    *   stored (or persistent) XSS holes are present
        when an application stores user input containing
	injected code into a persistent data store
	such as a database
	and then references it in a webpage

        *   BOTH reflected and stored XSS 
	    exist when an application-tier
	    program improperly handles user
	    inputs;

    *   DOM-based XSS - appear when client-side
        scripts reference user inpus dynamically
	obtained from the Document Object Model
	(DOM) structure without proper validation

*   to fight these? DEFENSIVE CODING --
    validate and sanitize inputs!
    replacement and removal!

    *   replacement and removal -- search for
        KNOWN "bad" characters (blacklist
	comparison) --
	replacement - replace with non-malicious
	removal - simply remove them

    *   escaping methods search for characters with
        special meanings for client-side interpreters
	and removes those *meanings*

    *   restriction techniques limits inputs to
        known "good" inputs (whitelist comparison)

*   IMPORTANT THING TO KEEP IN MIND:
    no matter how much client-side
    checking of inputs you employ,
    nice choice of form elements to reduce
    user error, etc.,

    the application-tier programmer STILL
    has to treat ALL user input as
    potentially containing an attack
    (someone might make their OWN page
    leading to a site, alter it with
    a tool such as firebug, etc.)

SQL Injection
*   user-provided data is used to complete a
    SQL command, but it includes additional
    SQL (that's the SQL being injected)

*   "dynamic" SQL - a SQL command that is being
    "completed" or modified based on user
    input

    "static" SQL - hard-coded SQL

*   static SQL won't suffer from SQL injection --
    dynamic SQL might, so you want to take measures
    to prevent it

    String query = "select empl_last_name " +
                   "from empl " +
		   "where empl_num = " + infoFromUser;

    111

    111 or 1=1   -- now you'll see ALL the empl_last_names

    999 union select table_name from user_tables

    -- now you'll see the names of ALL tables in the
    --     database

*   some defense techniques

    *   avoid (when possible) dynamic SQL used with
        concatenation of user input

    *   ...if you MUST? CAREFULLY sanitize that input
        first!!!

    *   use PreparedStatements -- harder to
        inject into!
    *   use bind arguments/bind variables (for the same
        reason)
 
    *   carefully use CallableStatements (stored procedures
        and stored functions)

    *   grant/revoke 

        grant - gives a user access privileges to
	        some database object (such as a table)
	revoke - removes privileges from a user
	         for some database object (such as a table)

        4 levels of access: 
        select, insert, update, delete

        grant select
        on painter
        to abc3, bf5, st10;

        revoke insert, update, delete
        on painter
        to ghi3, dff3;

        ...nice technique if only some columns
	   need to be secured:
	   make a VIEW and grant privileges
	   JUST for that view, and not the
	   "complete" table, for example;

*   NOTE that, in PreparedStatements, you can
    only replace literals, NOT database objects
    (being precompiled...)

    ...so, sadly, you CAN'T have:

    'select * from ?'