in reply to Yet Another Variable Expansion Problem

The big security hole here is cross site scripting. This program never checks the content sent back to the user - if this system was used to maintain, say, a guestbook, readers of that guestbook could easily be the target of nefarious Java Script planted by a previous user.

Though cross - site scripting is dangerous enough (and should scare your friend) there isn't a "remote shell access" type problem here. The reason is that we can imagine lots of nasty things that could be processed in the template; but since the substitution only occurs once, it'd be hard to force the program to do something that the designer hadn't already placed inside his template file. You can't pass in a nefarious system command and expect it to be expanded and executed - the program doesn't work that way.

The REAL problem with this system is not a security one, but the fact that it only barely works. Part of the problem here is that someone works hard to learn Perl and then manages to wrap their brain's around regexes, then manages to write one that is both complicated AND works. Then you come along and tell them they've screwed up, or not thought it through.

Your friend should be justly proud of his solution - it's a difficult regex he's come up with. But it should be pointed out that it can't handle complex templates - what if the HTML writer wants to use a [ just somewhere in the template? Or have something span multiple lines? Or a CDATA section? Does the program seperate logic and design? Does your firend understand the neccessity of this? These are the issues that hand rolled templating systems fall into. Scare him with cross site scripting, but make sure he understands these issues too.

Good Luck getting him to use strict!

Cheers,
Erik