Tighter Security with Client Supplied SSIs

Ovid has asked for the wisdom of the Perl Monks concerning the following question:

Scenario: Our company is in the process of restructuring the way we create dynamic Web sites. I am have been tasked with researching and implementing the creation of secure, scalable systems. My current problem is one that I am sure other monks have faced.

I have convinced the company that we need to switch to a templating system (probably Template Toolkit) as the first step. However, some of our clients already have rather extensive Web sites. They would like to take much of the e-commerce functionality that we have and embed them within their Web pages without having us create an entire site from scratch.

My initial thought was that all scripts would check for an SSI parameter and serve either the entire page, or the appropriate section, depending upon whether the page was called from an SSI. Unfortunately, one of our clients wants to retain the ability to access and update the HTML directly. What I don't want is the client to be able to enter something like . I would much prefer that they be able to enter a tag that we supply and have it parsed with Perl using Template Toolkit. This would involved having IIS trap calls to HTML files in their directory and pass it off to a handler script. I don't yet know how to set that up (any IISMonks out there? :), but it seems much safer than allowing them to enter SSIs.

Any thoughts or comments about this method of ensuring security?

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Comment on Tighter Security with Client Supplied SSIs

Replies are listed 'Best First'.
Re: Tighter Security with Client Supplied SSIs by $code or die (Deacon) on May 08, 2001 at 02:40 UTC
Hi Ovid, <verbose> If you want to intercept calls to HTML files, I think there are probably two ways of doing this. Create an ISAPI filter - I think this would have to be written in C or VB or something. I haven't done this but I know MS have a few samples you can download. - I think this would take a lot of time to develop so it might not be worth it for just one site You could create a new Script Mapping in IIS for .html files. Instead of letting IIS feed the html straight to the browser you could create a parser script (say it's called 'stripSSI.pl') and create a script mapping pointing to perl path/to/stripSSI.pl %s - you would need to play around with that path - I haven't done this before so it might need to be different. stripSSI.pl could then clean up the SSI and handle the template tags directly. To create a script mapping in IIS [4\|5], go to the website properties, click "Home Directory" Tab -> Configuration. You might also want to think of other ways of letting the client update HTML. It would depend on what sort of changes the client would be making and how often. One option would be to let the client upload to a 'build' subfolder with a few home-grown tags, then let them run a script which checks which filed have changed, then fills in your home-grown tags. </verbose> $code or die `$ perldoc perldoc`	[reply]

Replies are listed 'Best First'.

Re: Tighter Security with Client Supplied SSIs
by $code or die (Deacon) on May 08, 2001 at 02:40 UTC

Ovid

Create an ISAPI filter - I think this would have to be written in C or VB or something. I haven't done this but I know MS have a few samples you can download. - I think this would take a lot of time to develop so it might not be worth it for just one site
You could create a new Script Mapping in IIS for .html files. Instead of letting IIS feed the html straight to the browser you could create a parser script (say it's called 'stripSSI.pl') and create a script mapping pointing to perl path/to/stripSSI.pl %s - you would need to play around with that path - I haven't done this before so it might need to be different. stripSSI.pl could then clean up the SSI and handle the template tags directly.

$code or die

$ perldoc perldoc

[reply]