Secure Python code - volunteers for code review?

[andrew blah]

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

 

[Josiah Carlson]

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

 

[Cliff Wells]

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

 

[Gerhard Haering]

[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]

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

 

[Cliff Wells]

[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)

 

[andrew blah]

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