Marty, David's explaining it pretty well, but let me take another crack at it. I was in your position about a year ago and got royally (and publically) flamed on the perl beginners list by a security admin for deigning to give CGI advice without knowing this, so I got what you might call a crash course!
As David says, the place that you can see the "hidden" variables is in the page where the form is, before you submit it. It is true that once you submit it, you don't see them go, and once you arrive at the target script, they are not available. But they can be discovered by looking at the page source before submission. So what? The user can't change the page source, right? Well, wrong. Anyone could save a copy of the page to their own file system, modify the "hidden" values there, and submit that modified page to your server! Your server script may or may not be checking the "referer" [sic] environment variable to ensure that only submissions originating from your site are valid. If it's not, this bogus and potentially malevolent request would get right through! But wait, there's more! Even if your script *did* check the referer, that's no protection either! An experienced programmer can easily use Perl's LWP module or its equivalent in some other language to make the request with a faked referer variable. So really, POST variables are no more secure than GET variables, it just takes a little more doing to fake them. Does this matter in your situation? If it's a session id, it seems to me that either it's the correct session id that you gave them, or it's something else they made up, in which case it's probably invalid and so your script will just ignore it or throw an error. (It's theoretically possible I suppose that they might guess a number that's someone else's current session id, but that seems extremely unlikely.) And if you're passing it to log them off, even if they attempt to use it again, they'll be logged off by then, so it won't work anymore anyway. (But then, why does it even matter if it's hidden or not?) So in the end, it's your decision. But it's important that you understand it all so that you can make an informed decision. By the way, I'm still not a security expert, so don't take my word as the final one either! - John --- Marty Landman <[EMAIL PROTECTED]> wrote: > At 06:06 AM 6/25/02 -0500, David T-G wrote: > > >If the variables are in the page to be in the form > to be > >sent back via POST, then the user can find them, > period. > > > >Try it yourself: set up something via POST and then > surf to the page > >and then "view source" or the equivalent in your > browser (and if there > >isn't an equivalent then find a browser, even if > just for a moment, > >that DOES have it) and look and see your data > hanging right out there > >for all to see. > > David, > > Sorry but I don't get what you mean here. When I > have a page call a program > with info from a form being posted then the program > picks up the data and > then creates whatever output web page is > appropriate. The posted data comes > in via STDIN so unlike a GET where the data is > actually part of the URL, in > a POST it isn't viewable from the browser. ===== "Now it's over, I'm dead, and I haven't done anything that I want; or, I'm still alive, and there's nothing I want to do." - They Might Be Giants, http://www.tmbg.com __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
