Secure Python code - volunteers for code review?

Discussion in 'Python' started by andrew blah, Oct 13, 2004.

  1. andrew blah

    andrew blah Guest

    Hello

    I have recently released catchmail - a free (BSD license) open source
    Python utility www.users.bigpond.net.au/mysite/catchmail.htm

    This script processes in and outbound emails and stores them to a
    database.

    The source code is here:
    http://www.users.bigpond.net.au/mysite/current/catchmail.py

    It's not a very long script (about 300 lines or so).

    I'm quite concerned however about security and I'd like catchmail to be
    as secure as possible. What can be done to verify the security of this
    script?

    I would really value it if any security aware Python guru was able to
    review the code from a security perspective. It would be good to
    ensure that python or sql code planted in an email or an attachment
    could not execute and break out of the script - or that any other
    security issue might arise. But how - I don't have anything near the
    level of Python expertise required to properly assess this script for
    security risk? If someone has the time to do a code review it would be
    much appreciated.

    Thanks in advance

    Andrew Stuart
    andrew dot stuart at xse dot com dot au
     
    andrew blah, Oct 13, 2004
    #1
    1. Advertising

  2. > I would really value it if any security aware Python guru was able to
    > review the code from a security perspective. It would be good to
    > ensure that python or sql code planted in an email or an attachment
    > could not execute and break out of the script - or that any other
    > security issue might arise. But how - I don't have anything near the
    > level of Python expertise required to properly assess this script for
    > security risk? If someone has the time to do a code review it would be
    > much appreciated.


    You can save yourself many concerns by encoding your data in some
    fashion that cannot be understood by the database to mean anything. Hex
    works well for that.

    In terms of general script security, you should be more specific about
    what you are worried about.

    - Josiah
     
    Josiah Carlson, Oct 13, 2004
    #2
    1. Advertising

  3. andrew blah

    Cliff Wells Guest

    On Tue, 2004-10-12 at 20:52 -0700, Josiah Carlson wrote:
    > > I would really value it if any security aware Python guru was able to
    > > review the code from a security perspective. It would be good to
    > > ensure that python or sql code planted in an email or an attachment
    > > could not execute and break out of the script - or that any other
    > > security issue might arise. But how - I don't have anything near the
    > > level of Python expertise required to properly assess this script for
    > > security risk? If someone has the time to do a code review it would be
    > > much appreciated.

    >
    > You can save yourself many concerns by encoding your data in some
    > fashion that cannot be understood by the database to mean anything. Hex
    > works well for that.


    A more straightforward way is to simply use prepare() religiously. This
    also avoids the headache of having to decode your data if you use a
    different program to access it (such as psql or mysql).

    Regards,
    Cliff

    --
    Cliff Wells <>
     
    Cliff Wells, Oct 13, 2004
    #3
  4. On Tue, Oct 12, 2004 at 10:25:58PM -0700, Cliff Wells wrote:
    > [Josiah Carlson requests a security review of his code storing/receiving
    > email data from a PostgreSQL database]
    >
    > A more straightforward way is to simply use prepare() religiously.
    > This also avoids the headache of having to decode your data if you
    > use a different program to access it (such as psql or mysql).


    There's no prepare() in the DB-API. Letting the database module do the
    quoting should be enough to stay clear of SQL injection attacks.

    And this his code does, from what I can see. The SQL stuff is hard to
    read for me, though. Maybe the database access code should be factored
    out more and put in a class of its own.

    -- Gerhard
     
    Gerhard Haering, Oct 13, 2004
    #4
  5. On Tue, Oct 12, 2004 at 08:52:31PM -0700, Josiah Carlson wrote:
    > You can save yourself many concerns by encoding your data in some
    > fashion that cannot be understood by the database to mean anything.
    > Hex works well for that.


    Looks like overkill to me. If you let the DB-API do the quoting (by
    providing both SQL statements and parameters to the execute method,
    which he does), you're on the safe side IMO.

    Using TEXT and VARCHAR fields for emails is the way to go IMO. No need
    for any fancy BLOB/BYTEA column types, because emails cannot contain
    chr(0) anyway. If you want to search and/or compare, then you should
    be aware of possible charset issues, though.

    -- Gerhard
     
    Gerhard Haering, Oct 13, 2004
    #5
  6. andrew blah

    Cliff Wells Guest

    On Wed, 2004-10-13 at 16:53 +0200, Gerhard Haering wrote:
    > On Tue, Oct 12, 2004 at 10:25:58PM -0700, Cliff Wells wrote:
    > > [Josiah Carlson requests a security review of his code storing/receiving
    > > email data from a PostgreSQL database]
    > >
    > > A more straightforward way is to simply use prepare() religiously.
    > > This also avoids the headache of having to decode your data if you
    > > use a different program to access it (such as psql or mysql).

    >
    > There's no prepare() in the DB-API. Letting the database module do the
    > quoting should be enough to stay clear of SQL injection attacks.


    Ah, right. Too much language switching and not enough sleep (it's
    8:00AM here and I haven't seen a bed yet) :p

    --
    Cliff Wells <>
     
    Cliff Wells, Oct 13, 2004
    #6
  7. andrew blah

    andrew blah Guest

    Thank you all very much for your helpful comments. I will take them
    into account.

    A few people credited me here with having written the code. Kind - but
    I'm the project lead - not the person who wrote the code. The code was
    written by Mark Hammond - that would explain why it is well written.

    Thanks again to all for the comments and guidance - most helpful.
    Regards

    Andrew Stuart
     
    andrew blah, Oct 17, 2004
    #7
    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.
Similar Threads
  1. Replies:
    0
    Views:
    338
  2. Josiah Carlson
    Replies:
    1
    Views:
    357
    Andrew Clover
    Oct 13, 2004
  3. www
    Replies:
    51
    Views:
    1,502
  4. Brett Cannon
    Replies:
    3
    Views:
    241
    Paul Rubin
    Feb 19, 2008
  5. M.-A. Lemburg
    Replies:
    0
    Views:
    86
    M.-A. Lemburg
    Feb 27, 2014
Loading...

Share This Page