Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

acme (189)

acme
  (email not shown publicly)
http://www.astray.com/
Leon Brocard (aka acme) is an orange-loving Perl eurohacker with many varied contributions to the Perl community, including the GraphViz module on the CPAN. YAPC::Europe was all his fault. He is still looking for a Perl Monger group he can start which begins with the letter 'D'.

Journal of acme (189)

Tuesday October 08, 2002
09:27 AM

Security

[ #8244 ]
A lot of us write code which is available on the Net, whether it be network servers, application frameworks, mod_perl handlers, or CGI scripts. We have to think about security. I've recently done a security audit of some code at $work and the main thing I can say is thank god I wasn't doing a code review too ;-). Anyway, the most important thing to remember is that you shouldn't trust information that the user can change - that includes CGI parameters, HIDDEN form elements, and HTTP headers. Always quote DBI values - use bind parameters. Oh, and use warnings, strict and taint. That will catch most of your problems. I've recently read OWASP's A Guide to Building Secure Web Applications which contains most of the problems (but could go into a great deal more detail while describing solutions). Security is important, mkay?

List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Security 3 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I've been waiting for a book that actually goes into decent detail about this, but have yet to find anything.

    I'm currently writing a talk, for possible use at next year's YAPC::Europe, that discusses how QIIS approached some of these problems when rewriting their core product. I was horrified to see how easy it was to break the code, and even more horrified that knowing that it was flawed, no-one had plugged the holes earlier!

    With all the dangerous CGI scripts out there, $someone could make a killing ou

    • With all the dangerous CGI scripts out there, $someone could make a killing out of a CGI Security book.

      I forsee a flaw in your cunning plan. You're assuming that the monkeys that write these dangerous CGIs realise that they ought to buy such a book

      (And a more subtle flaw - that the non-monkeys aren't so arrogant to assume that they know everything already, and hence don't buy your book)

      • It is a flaw, but there enough very clever people about who have done talks about web security, that a joint venture might be better than the sum of the parts.

        I also think that, most well written and authoritive books, do eventually get the recognition they deserve.

        With a bit of good karma from the community and well received press reviews, I would imagine many new perl CGI programmers might even be embarrassed to admit they don't have it.

        Okay so I was wearing rose-tinted glasses for that last bit ;)

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.