Server-side programming

Discussion in 'Python' started by Timo Virkkala, Sep 20, 2003.

  1. I'm creating a system with Python CGIs, that connect to a database. I'm
    wondering about input validation. Of course I will check the length of
    the passed parameters, to (hopefully) prevent any DOS attacks. What else
    do I need to check? Do I need to remove any SQL from the inputs?
    Anything else I might have overlooked?

    --
    Timo Virkkala |

    "In the battle between you and the world, bet on the world."
     
    Timo Virkkala, Sep 20, 2003
    #1
    1. Advertising

  2. Timo Virkkala

    Alan Kennedy Guest

    Timo Virkkala wrote:
    > I'm creating a system with Python CGIs, that connect to a database. I'm
    > wondering about input validation. Of course I will check the length of
    > the passed parameters, to (hopefully) prevent any DOS attacks. What else
    > do I need to check? Do I need to remove any SQL from the inputs?
    > Anything else I might have overlooked?


    You might not need to remove SQL from your field values. Doing so
    would probably be a non-trivial string parsing exercise.

    Most "SQL injection" attacks would be where a cracker hopes that you
    are going to embed the contents of "username" and "password" fields
    right into a string containing an SQL query, like so

    mySQLString = """
    select *
    from users
    where uname = "%s" and password = "%s"
    """ % (username, password)

    If the query returns a non-zero number of rows, then that
    username/password combination is deemed to be valid.

    The problem comes when the cracker deliberately subverts the content
    of the fields, supplying values like these, for example

    username='alan'
    password='" or 0=0 or password="'

    Which when embedded into the SQL query string gives the following
    final SQL query:

    select *
    from users
    where uname = "alan" and password = "" or 0=0 or password=""

    Which will return at least 1 row, assuming that "alan" is a valid
    username.

    Now, trying to parse the syntax of the password field, looking for SQL
    keywords such as "or", could be complex: there are quite a few
    possible ways in which the query can be textually subverted.

    AFAIK, the most effective way to prevent such attacks is to disable
    any quote characters that may be present in the password, so that they
    are treated as a part of the password string, not as delimiters in the
    SQL query string. For example

    import re
    password = re.escape(password)

    Which for the values given above would now give an SQL query of

    select *
    from users
    where uname = "alan" and password = "\"\ or\ 0\=0\ or\ password\=\""

    Does anyone know of a more effective approach to preventing SQL
    injection attacks?

    Another potential attack is the "Cross Site Scripting (XSS) Attack",
    whereby the attacker inserts javascript into a field value, which is
    then embedded into the HTML transmitted by a web app to another user,
    for example as a post in a message board.

    This hostile javascript can do any number of nasty things to users
    browsers including stealing cookies, or url-rewritten session IDs, so
    that the innocent users login session can be hijacked and abused.

    Here is an article about XSS attacks.

    http://www.cgisecurity.net/articles/xss-faq.shtml

    AFAIK, the most effective solution to preventing XSS attacks is to ban
    HTML/tags/javascript from being inserted into text strings that will
    be displayed as part of a HTML page. This could be done by

    1. Parsing the string as HTML, and stripping out <script> tags.
    2. Escaping (in the HTML sense) all field inputs, to disable markup
    special characters such as "<", ">", etc.

    Does anyone know of other potential textual attacks against web pages,
    input forms and field values?

    It would be really nice to have a central, python focussed, repository
    of these attack techniques, and how they can be prevented with python
    code. Does anyone know of such a page?

    If we get enough information from this thread, I might start up a page
    about the subject.

    regards,

    --
    alan kennedy
    -----------------------------------------------------
    check http headers here: http://xhaus.com/headers
    email alan: http://xhaus.com/mailto/alan
     
    Alan Kennedy, Sep 21, 2003
    #2
    1. Advertising

  3. Timo Virkkala

    Alan Kennedy Guest

    Timo Virkkala wrote:
    > I'm creating a system with Python CGIs, that connect to a database. I'm
    > wondering about input validation. Of course I will check the length of
    > the passed parameters, to (hopefully) prevent any DOS attacks. What else
    > do I need to check? Do I need to remove any SQL from the inputs?
    > Anything else I might have overlooked?


    You might not need to remove SQL from your field values. Doing so
    would probably be a non-trivial string parsing exercise.

    Most "SQL injection" attacks would be where a cracker hopes that you
    are going to embed the contents of "username" and "password" fields
    right into a string containing an SQL query, like so

    mySQLString = """
    select *
    from users
    where uname = "%s" and password = "%s"
    """ % (username, password)

    If the query returns a non-zero number of rows, then that
    username/password combination is deemed to be valid.

    The problem comes when the cracker deliberately subverts the content
    of the fields, supplying values like these, for example

    username='alan'
    password='" or 0=0 or password="'

    Which when embedded into the SQL query string gives the following
    final SQL query:

    select *
    from users
    where uname = "alan" and password = "" or 0=0 or password=""

    Which will return at least 1 row, assuming that "alan" is a valid
    username.

    Now, trying to parse the syntax of the password field, looking for SQL
    keywords such as "or", could be complex: there are quite a few
    possible ways in which the query can be textually subverted.

    AFAIK, the most effective way to prevent such attacks is to disable
    any quote characters that may be present in the password, so that they
    are treated as a part of the password string, not as delimiters in the
    SQL query string. For example

    import re
    password = re.escape(password)

    Which for the values given above would now give an SQL query of

    select *
    from users
    where uname = "alan" and password = "\"\ or\ 0\=0\ or\ password\=\""

    Does anyone know of a more effective approach to preventing SQL
    injection attacks?

    Another potential attack is the "Cross Site Scripting (XSS) Attack",
    whereby the attacker inserts javascript into a field value, which is
    then embedded into the HTML transmitted by a web app to another user,
    for example as a post in a message board.

    This hostile javascript can do any number of nasty things to users
    browsers including stealing cookies, or url-rewritten session IDs, so
    that the innocent users login session can be hijacked and abused.

    Here is an article about XSS attacks.

    http://www.cgisecurity.net/articles/xss-faq.shtml

    AFAIK, the most effective solution to preventing XSS attacks is to ban
    HTML/tags/javascript from being inserted into text strings that will
    be displayed as part of a HTML page. This could be done by

    1. Parsing the string as HTML, and stripping out <script> tags.
    2. Escaping (in the HTML sense) all field inputs, to disable markup
    special characters such as "<", ">", etc.

    Does anyone know of other potential textual attacks against web pages,
    input forms and field values?

    It would be really nice to have a central, python focussed, repository
    of these attack techniques, and how they can be prevented with python
    code. Does anyone know of such a page?

    If we get enough information from this thread, I might start up a page
    about the subject.

    regards,

    --
    alan kennedy
    -----------------------------------------------------
    check http headers here: http://xhaus.com/headers
    email alan: http://xhaus.com/mailto/alan
     
    Alan Kennedy, Sep 21, 2003
    #3
  4. Timo Virkkala

    Neil Hodgson Guest

    Alan Kennedy:

    > AFAIK, the most effective way to prevent such attacks is to disable
    > any quote characters that may be present in the password, so that they
    > are treated as a part of the password string, not as delimiters in the
    > SQL query string. For example
    > ...
    > Does anyone know of a more effective approach to preventing SQL
    > injection attacks?


    Separate your parameters from the SQL and rely on the database to perform
    the substitution like this:
    c.execute( \
    "select * from users where uname=:1 and pw=:2", \
    (username, password))

    This may also improve performance by allowing the database to cache the
    preparation of the statement as it stays constant.

    Neil
     
    Neil Hodgson, Sep 21, 2003
    #4
  5. At some point, Alan Kennedy <> wrote:

    > Timo Virkkala wrote:
    >> I'm creating a system with Python CGIs, that connect to a database. I'm
    >> wondering about input validation. Of course I will check the length of
    >> the passed parameters, to (hopefully) prevent any DOS attacks. What else
    >> do I need to check? Do I need to remove any SQL from the inputs?
    >> Anything else I might have overlooked?

    >
    > You might not need to remove SQL from your field values. Doing so
    > would probably be a non-trivial string parsing exercise.
    >
    > Most "SQL injection" attacks would be where a cracker hopes that you
    > are going to embed the contents of "username" and "password" fields
    > right into a string containing an SQL query, like so
    >
    > mySQLString = """
    > select *
    > from users
    > where uname = "%s" and password = "%s"
    > """ % (username, password)
    >
    > If the query returns a non-zero number of rows, then that
    > username/password combination is deemed to be valid.
    >

    [snipped useful info on doing SQL injections]
    > AFAIK, the most effective way to prevent such attacks is to disable
    > any quote characters that may be present in the password, so that they
    > are treated as a part of the password string, not as delimiters in the
    > SQL query string. For example
    >
    > import re
    > password = re.escape(password)
    >
    > Which for the values given above would now give an SQL query of
    >
    > select *
    > from users
    > where uname = "alan" and password = "\"\ or\ 0\=0\ or\ password\=\""
    >
    > Does anyone know of a more effective approach to preventing SQL
    > injection attacks?


    The problem is you're trying to create the entire query string. This
    means that *you* must be sure what is valid and what's invalid; what
    needs quoting, and what doesn't. Are you sure the above using
    re.escape will work properly for SQL queries, since it was designed
    for regular expressions? Are all corner cases covered? etc.

    The best way to do this is to allow the database module to do the
    quoting; this is explicictly supported by Python's DB-API v2
    specificiation (available as PEP 246 [1]). Most (if not all that
    you'll probably use...) database modules for python conform to this.

    Here's a concrete example using PySQLite: [untested code]

    import sqlite
    db = sqlite.connect('database.db')
    cursor = db.cursor()

    cursor.execute('''select * from users
    where uname = %(uname)s and
    password = %(password)s''',
    {'uname' : uname, 'password' : password})

    row = cursor.fetchone()
    if row is None:
    print "Access denied"

    Note how the parameters are passed as separate arguments to
    cursor.execute; the sqlite module takes care of escaping them. Note
    that not all database modules support this style of quoting; check out
    PEP 249 and the documentation of your specific module.

    [1] http://python.org/peps/pep-0249.html

    --
    |>|\/|<
    /--------------------------------------------------------------------------\
    |David M. Cooke
    |cookedm(at)physics(dot)mcmaster(dot)ca
     
    David M. Cooke, Sep 21, 2003
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page