Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

The danger of hidden fields

by Gerard (Pilgrim)
on Jul 23, 2002 at 03:40 UTC ( [id://184320]=perlquestion: print w/replies, xml ) Need Help??

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

Good Afternoon all, My current employer, with whom I have not been very long, and I only work here part time while continuing to study, has a script on our site which seems to have a security flaw.

All the scripts that the company uses were written several years ago by a programmer who no longer works here.

These scripts are used daily, but are not ever needed to be changed because they were written in such a way that hidden fields in the html form will be submitted and then the script will determine what to do. Therefore all the current employees need to concern themselves with is designing pretty looking web pages etc. and then just including the appropiate hidden fields.

This has been like this for several years and working relatively smoothly. It was not until another employee weas having trouble with her hidden fields that I chanced to look at this particular script. What I found concerned me a little.

All the customer data that is submitted to the script is as well as being emailed to us, stored in a text file. However the text file to store the data in is passed as a hidden field from the html, and there is no check to make sure that the referring page is the correct one.

My concern is that someone could submit their own html form and change the value for where it is to be saved (all the hidden fields are quite obviously named) and at least cause havoc, if not serious damage.

Is this a reasonable concern?

I have tried to explain this to my boss but as I have not yet proven my perl skills (which are somewhat limited) and this is not what I was employed for anyway, they were more than a little hesitant to listen to me.

My perl work experience is somewhat limited and so I cannot perhaps explain the risk as well as some of you with more experience.

What I am asking is if anyone has any comments that I could make to my employer, or include in a short report so that I will be allowed to fix this potential problem, that would be much appreciated.

Or if you think I am just over reacting, then let me know.
Much appreciated.

Regards,


Gerard O'Brien

Replies are listed 'Best First'.
Re: The danger of hidden fields
by fokat (Deacon) on Jul 23, 2002 at 04:26 UTC
    Well, from your description of the problem it seems to me that your attitude is correct. It bothers me that your boss should pay more attention to security.

    I know very little about your actual scenario but I think there are a few main risks here (I assume that the script allows the customer data to be written to a file which is specified via a hidden field):

    • An attacker storing "interesting" customer information in a file called /etc/password or similar, provided that your web server runs as root. By interesting customer information, I mean a set of lines providing a superuser account with a password known to the attacker. This would be very handy for cracking your webserver.

    • An attacker storing "interesting" customer information in the file $DOCUMENTROOT/index.html. Talk about a convenient way to deface your server.

    • An attacker requesting customer information from system files, such /etc/passwd or httpd.conf in order to gain knowledge about your system.

    ... Please do not take these as an extensive list. It's late and I only wrote what came to mind.

    Now, so far you've acted ethically. No matter what people tells you do not try to expose or exploit this flaw without premission from your employer. If you succeed (and this seems easy from your description), this will allow your employer to sue you. You would not be the first to suffer through this nonsense. I say this because it is very tempting to exploit this vulnerability and play a little prank to your company as a proof of concept, but this can get you in serious trouble.

    If after you ponint this to your boss, they still decide not to fix it, then leave it alone. And in a personal note, look for another job :)

    Regards

      The heart may be in the wrong place, but trusting HTTP_REFERER for a validity check is not the right solution.

      Also if you are trusting user input to name a file, what if the user names a "file" (with proper encoding of course) something like | rm -rf /?

Re: The danger of hidden fields
by BrowserUk (Patriarch) on Jul 23, 2002 at 04:14 UTC

    My first thought when I read your post was that perhaps the most effective way to convince your boss, would be a demonstration.

    Put together a page that would demonstrate how the system could be compromised on your harddisk and then show your boss how easy it would be to use.

    My second thought was that this might be dangerous to your employment prospects. If your boss decided that, even though you were showing him what and how it could be done rather than doing it, might take umbridge at you doing so.

    My third thought was that even just discussing this subject here, even without your companies name, URL or other information, could be construed as a security breach!. I did a google search on your name, and came up with only 20 hits! Hopefully, none of these is your name? At least not in anyway that is linked with your companies website? Did you ever add your name to a comment or changes: block in any of the company web pages?

    Basically, I don't have any good advice with regard to your problem, but I would strongly advise you use great caution in telling your boss how and where you got any advise you do get.

    Good luck.

      My first thought when I read browseruk s post was "Im going to try googling for his name too!"

      My second thought was "Damn! I actually found him!

      SMiTZ
        I may be young and inexperienced, however, I am not stupid. Gerard is not my real name, but rather one I have been using in chat rooms and the like for a while now. Thanks to everyone for the comments, hopefully I can get this sorted out now. Regards, Gerard
      even just discussing this subject here, even without your companies name, URL or other information, could be construed as a security breach!

      Yes it could. It would have been better if he posted anonymously, but this shouldn't be his main concern. The vast majority of people who exploit these vulnerabilities know how to find them on their own. This does little to reduce the security of his web app.

      As for informing your boss, I wouldn't make a big deal about it. Fix it, tell him you fixed a security problem, and suggest measures that would prevent the situation from arising in the future (secure programming standards, security audits, etc).

        You said:

        The vast majority of people who exploit these vulnerabilities know how to find them on their own.

        Agreed. But there is no point in making their task any easier.

        You said:

        This does little to reduce the security of his web app.

        Minor point, but it isn't his. Only worth making for what follows...

        As for informing your boss, I wouldn't make a big deal about it.

        He said:

        I have tried to explain this to my boss
        And that is his problem.

        He said:

        My current employer, with whom I have not been very long, and I only work here part time while continuing to study....

        It's very easy to forget how little respect and authority one receives, if one young (somewhat of an assumption: he could be a mature student!) or new.

        He's probably both!

        You said:

        and suggest measures that would prevent the situation from arising in the future (secure programming standards, security audits, etc).

        Exactly what he is trying to do. However, given his current lowly position in the company, the hysterisis of "it's been working fine for a couple of years", the (overused) adage of "if it ain't broke, don't fix it!" and "what does he know, he's only a kid" .

        He came here looking for advice on how to make his case, with authority, to his (apparently non-Perl/programming/security aware) boss.

        Finally, you said:

        Fix it, tell him you fixed a security problem

        He said (my highlighting):

        All the customer data that is submitted to the script is as well as being emailed to us, stored in a text file. However the text file to store the data in is passed as a hidden field from the html, and there is no check to make sure that the referring page is the correct one.

        Any fix is most likely going to need (at minimum) prodedural changes on behalf of the customers.

        Even if this were not the case, scenario (abbreviated).

        Takes code home (no authority to do it on company time)...makes a few minor changes in preparation nothing significant, just setting stuff up for the (your) 'fix'. Installs it next day...monitors it carefully functions fine. Goes home for the weekend....

        By now you can probably see where this is leading.

        The ha...sorry, cracker that saw his append and tracked him, or had been "casing the joint" for a couple of weeks, makes his move. Several (hundred) customers credit cards get used for whatever, and who gets the blame???


        Conclusions....

        You seem to misunderstand that the point is in authority and responsibilities; even though his concern may be valid, he is not authorized to fiddle with the script and will be fired if he does. Whoever has authority is responsible for validating his concerns; if the responsible party chooses to dismiss it and damage happens, then the responsible party will be blamed for the damage.

        It's the really twisted type of corporate-think that makes companies spend big $$$$ on support contracts and makes them mistrust opensource projects. Unfortunately, it's how the money goes around too, so irrational as it may seem, you either get with the program or search for a meal in other people's trashbins.

        Makeshifts last the longest.

•Re: The danger of hidden fields
by merlyn (Sage) on Jul 23, 2002 at 05:33 UTC
    I think you've mistitled this a bit. It's not the danger of hidden fields. It's the danger of trusting hidden fields.

    I've written about this subject quite a bit in my web-related columns. The most important thing to note is that client-side data isn't really all that useful in a real life situation, except to identify a particular browser. Any critical data should be encrypted or kept on server side.

    -- Randal L. Schwartz, Perl hacker

Re: The danger of hidden fields
by cLive ;-) (Prior) on Jul 23, 2002 at 04:22 UTC

    What I am asking is if anyone has any comments that I could make to my employer, or include in a short report so that I will be allowed to fix this potential problem, that would be much appreciated.

    It would be trivial to write a script to change where the data is written to. So we change it to write to a web page. Then we check to see what gets written from the form submission. then we change uploaded input to rewrite over the company's home page. Or, worse, overwrite a CGI script if we can and use that to create more havoc.

    HTTP_REFERER is NOT a secure way to check - that can be faked using LWP::UserAgent - ideal solution really depends on the specific situation.

    If you have trouble convincing your employer, simply post their URL here and I'm sure someone will demonstrate :-)

    .02

    cLive ;-)

    --
    seek(JOB,$$LA,0);

Re: The danger of hidden fields
by wardk (Deacon) on Jul 23, 2002 at 14:25 UTC
    Having worked in a few large shops, I suspect what you are describing is an internal application (firewalled off), therefore the concern by management about getting cracked is minimal.

    If this is a serious application, as opposed to lets say an internal app that collects suggestions for the departments next picnic location, then you should perhaps push your point. Before doing so, make sure you can articulate how this can be a problem (which is one reason you are here now, a good start)...what are the ramifications of having bad data? i.e. Can someone give themselves a raise?, modify their vacation days? put their daily pizza order on the company card? obtain a staple and paperclip supply above and beyond the maximum allowed? If the risk is trivial, and management isn't interested in hearing about good coding practice, then back off and treat this as a learning experience.

    If you have a traditional Dev/test/prod type environment, then your risk of demonstrating the flaw is greatly diminished. Since you admit being new to Perl (as well as the company) I would suggest garnering some support from those more experienced, someone who is respected by your management/peers (is there a "guru" around?). Another option depending on the size of the company is to speak directly to a representative of a IT support dept, preferrably security. Explain the scenario and ask for advice. If they are doing their job, they will quite possibly take the ball and just run with it (be sure that your manager knows you are seeking their consultation, so he/she's not blindsided by a overzealous security analyst).

    Appears to me like you are simply being a conscientous employee. Hopefully you work in a place where such behavior is valued. good luck.

Re: The danger of hidden fields
by Aristotle (Chancellor) on Jul 23, 2002 at 13:27 UTC
    I have tried to explain this to my boss but as I have not yet proven my perl skills (which are somewhat limited) and this is not what I was employed for anyway, they were more than a little hesitant to listen to me.

    This is not a Perl question. It's general secure programming practice; whether the CGI program is written in Perl, C, Lisp, bash or any other language wouldn't matter here, the issue at heart is that it was written to trust user input.

    Explain to your boss that the problem is really serious. Ask them if they would agree to be given a demonstration. Cover your back at every step of the road in case you are unjustly reproached at a later date: get written confirmations whenever possible and try to always have a coworker come along to meetings. Do not go ahead and just make a demonstration. If necessary, offer to do so in spare, unpaid time. If you are given the go-ahead, make several demonstrations: the boss may lack the technical understanding to deduce how far reaching the problem really is if you only make a single one. Come up with serious attacks; deface the site, fiddle with /etc/passwd etc; whatever comes to mind. Make sure, obviously, to back up the altered files prior to the demonstration. If you are refused the chance to explain, at least make sure you can prove you did what could be expected of you so that if any damage happens, the responsibility is with those who dismissed your concerns.

    Good luck.

    Makeshifts last the longest.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://184320]
Approved by rob_au
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others wandering the Monastery: (4)
As of 2024-03-29 11:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found