in reply to This is not Flamebait
Adding to davorg's list, here are a few things that give me the willies from that site:
Many of the tools from that site haven't been updated since 1997. In itself, this should be a huge warning. Perl has evolved since that time. Wouldn't you rather use code that uses today's capabilities to their fullest? Additional security issues have been identified. Wouldn't you rather depend on something that's at least been modified in the last year?
The code doesn't use highly respected modules, such as CGI.pm. This means each script has to reinvent the wheel. It also means that it's up to the script's user to research and defend against newly identified security risks, such as DOS attacks. On the other hand, CGI.pm is continuously maintained and defends against these and other abuses.
To be fair, MSA checks some things. However, the code doesn't even cover the basics discussed in the documentation provided with the language. To my mind, this is inexcusable.
The scripts do not use tainting, STRICT, or warnings. This is a huge red flag.
Error checking is minimal. For example, Guestbook fails to verify that the data file actually opened (or closed, for that matter). This suggests that users may run into problems in high traffic situations (e.g. two users trying to enter guestbook entries at the same time) or cryptic error (Server Error 500) messages that could have been detected and handled through simple defensive programming. Along the same lines, FormMail doesn't verify success when it opens the mail server.
The solutions are, in my opinion, superficial and not designed for maintenance or extension. For example, FormMail doesn't support attachments. Sure, you can retrofit that, but compare the source of FormMail.pl to this implementation by our resident wizard. Which would you rather use?
Similarly, data storage is handled through text files, which is fine for some things, but greatly limits you when you need more. I would much rather see WWWBoard use DBI::CSV (at the very least; a real database would be preferred) than its current implementation. At a bare minimum, I'd like to see some file locking added.
The book sold through the site "devotes" eight pages to security (as an appendix, mind you), but the discussion is so superficial, it's almost useless. There are a few good ideas, but when you compare his material to documentation provided with Perl, the FAQ available on perl.com, the 19-page discussion in the Rat book, the 28-page discussion in Camel3 and related posts in the Monastery (the ones with high reputations), it becomes pretty clear that the reason his discussion is so short is due to inexperience (optimistically) or neglect (pessimistically).
Frankly, I don't want to trust my servers to code that treats such an important subject so cavalierly.
While I understand that one might play the "self-contained" card, my problem with that argument is simple: By limiting your access to the experts and their works, you force yourself to become an expert in every area. It would be more apropriate to combine the best modules the community has to offer, so that newbies can learn from good code done well, as opposed to restricted solutions done poorly.
That's not to say that you can't learn things from the code provided there; however, I would be extremely cautious deploying anything from there. Frankly, there are better resources and solutions.
What's most frustrating is that the site is often one of the first places people find when they start looking for Perl CGI scripts. They innocently assume that the code is fine ("After all, it hasn't needed an update since 1997." And, yes, I've actually heard this said) and then wonder why problems occur.
If you're really looking to improve your capabilities, register here, scour the archives, read the home nodes (and the links found there), and start participating. You'll get quality feedback from experienced, helpful people. You'll find code that works more reliably, is more flexible, and provides more overall benefit than the abandon-ware on that other site.
--f
P.S. Sorry if this is overly harsh; it's meant as constructive criticism. If MW participates here, I hope he'll take the feedback to heart and rework his free offerings so that they demonstrate more effective, appropriate, and secure practices.
|
|---|