Depends on much you want to "hack-proof" the system. Using hidden variables is sufficient for safe parameter passing, but anything that involves authentication or data that can affect the security of the system is unsafe. Far too easy to modify the page and resubmit.
I'm not completely sure of this, but I think that putting hidden variables in has the effect of tempting people who might not otherwise be interested in hacking your system.
In a site I maintain at work, I only pass a session ID in hidden variables. Each time the page is submitted, the session ID is checked in a mySQL database, and the users permissions are checked for the operation they are trying to perform. One interesting (but rarely used) side effect is that I can change a users permissions on the fly (i.e. while s/he's still logged in), and permit or yank privledges (typically, I start users with a minimum of permissions, and require them to justify any additional privledges they need).
| [reply] |
I think you might have a point about the hidden variables encouraging hackers. I suspect the word "hidden" triggers the curious.
Of course you can always check the referrer, but I accept that is not foolproof.
The hidden session id is a neat idea. Sure, it does'nt stop the occasional attempt to snarf someone else's id, but the amount of effort required outweights the simple pleasure of a vicarious hacking attempt, unlike just editing a url query-string, which can be done on the spur of the moment.
| [reply] |
It's true about attempting to snarf someone elses ID. There are a couple of packages out there generate pretty unique IDs. I use the current time in seconds plus the PID of the process of the perl instantiation when the user logged in.
This is kept in a mySQL table, along with the last time the ID was seen (each time a user accesses a page). Each time the script is called it checks to see if any of the IDs in the table are older than 15 minutes, and if they are, they're deleted. This (obviously) prevents stale IDs from being targettable. It also gives me an accounting log of people who actually logoff the application, versus leaving an unsecured PC on the network. As a side effect, it pretty much makes sure that the correct user is logged in (as opposed to sharing PCs), since the system is accessed a number of times a day, but not typically within a 15 minute user by two different users on the same PC (this is just an artifact of the local environment, and would not hold true for higher volume sights).
The system is vulnerable to packet sniffing on the local network, but truth be told, virtually no one around here is that proficient. Also, since we run on switches & routers, few people in the company can see other peoples traffic.
All in all, for my environment, it's pretty secure.
| [reply] |
