CGI Tutorial

[Lawrence D'Oliveiro]

Re: CGI Tutorial

In message <mailman.1294.1 159995176.10491 .python-list@python.org >, Clodoaldo
Pinto Neto wrote:

2006/10/4, Tim Chase <python.list@ti m.thechases.com >:
>

>The code is very dangerous...all owing any ol' schmoe to run
>arbitrary code on your server. At the barest of minimums, I'd
>plaster the code with warnings that this is a Very Dangerous
>Thing(tm) to do.

>
I though the danger was so obvious that i didn't bother. Now i have
issued a warning.

I wonder whether warnings are enough. People are still going to copy and
paste the dodgy code from your tutorial into their site. The only way
around this is to offer good, robust code to begin with.

[Steve Holden]

Re: CGI Tutorial

Lawrence D'Oliveiro wrote:

In message <mailman.1374.1 160073684.10491 .python-list@python.org >, Steve
Holden wrote:
>
>

>>Credit card numbers should be encrypted in the database, of course, but
>>they rarely are (even by companies whose reputations imply they ought to
>>know better).

>
>
How would encryption help? They'd still have to be decrypted to be used.

Indeed they would, but with proper key management the probability that
they can be stolen from a database in their plaintext form is rather
lower. Just last week a police employee in my class told us of an
exploit where a major credit card copmany's web site had been hacked
using a SQL injection vulnerability. This is usually done with the
intent of gaining access to credit card data.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

[Lawrence D'Oliveiro]

Re: CGI Tutorial

In message <mailman.98.116 0379324.11739.p ython-list@python.org >, Steve
Holden wrote:

Lawrence D'Oliveiro wrote:

>In message <mailman.1374.1 160073684.10491 .python-list@python.org >, Steve
>Holden wrote:
>>
>>

>>>Credit card numbers should be encrypted in the database, of course, but
>>>they rarely are (even by companies whose reputations imply they ought to
>>>know better).

>>
>How would encryption help? They'd still have to be decrypted to be used.

>
Indeed they would, but with proper key management the probability that
they can be stolen from a database in their plaintext form is rather
lower. Just last week a police employee in my class told us of an
exploit where a major credit card copmany's web site had been hacked
using a SQL injection vulnerability. This is usually done with the
intent of gaining access to credit card data.

If they can do that, it doesn't seem much of a step to compromise the code
that decrypts the credit card data, as well. Keeping it encrypted, when the
key needs to be kept at the same (in)security level, is just
security-through-obscurity.

[Paul Rubin]

Re: CGI Tutorial

Lawrence D'Oliveiro <ldo@geek-central.gen.new _zealandwrites:

lower. Just last week a police employee in my class told us of an
exploit where a major credit card copmany's web site had been hacked
using a SQL injection vulnerability. This is usually done with the
intent of gaining access to credit card data.

>
If they can do that, it doesn't seem much of a step to compromise the code
that decrypts the credit card data, as well. Keeping it encrypted, when the
key needs to be kept at the same (in)security level, is just
security-through-obscurity.

Keys in such sites are supposed to be kept more secure than the stuff
in the db.

[Steve Holden]

Re: CGI Tutorial

Lawrence D'Oliveiro wrote:

In message <mailman.98.116 0379324.11739.p ython-list@python.org >, Steve
Holden wrote:
>
>

>>Lawrence D'Oliveiro wrote:
>>

>>>In message <mailman.1374.1 160073684.10491 .python-list@python.org >, Steve
>>>Holden wrote:
>>>
>>>
>>>
>>>>Credit card numbers should be encrypted in the database, of course, but
>>>>they rarely are (even by companies whose reputations imply they ought to
>>>>know better).
>>>
>>>How would encryption help? They'd still have to be decrypted to be used.

>>
>>Indeed they would, but with proper key management the probability that
>>they can be stolen from a database in their plaintext form is rather
>>lower. Just last week a police employee in my class told us of an
>>exploit where a major credit card copmany's web site had been hacked
>>using a SQL injection vulnerability. This is usually done with the
>>intent of gaining access to credit card data.

>
>
If they can do that, it doesn't seem much of a step to compromise the code
that decrypts the credit card data, as well. Keeping it encrypted, when the
key needs to be kept at the same (in)security level, is just
security-through-obscurity.

It depends on what level of compromise they obtain through SQL
injection. It does represent a significant additional burden on
attackers before sensitive data becomes known. Clearly if someone mounts
a successful privilege escalation attack then potentially everything on
the system is compromised.

Note further, by the way, that credit card numbers need not necessarily
be decrypted to be used: if you are the credit card processor (rather
than a merchant requiring payment) then you can instead encrypt the card
number provided by the user and use that as your database key.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden