* For scripts that read/process files ensure there is no way a user could manipulate it to read an unintended file.
* For scripts that shell an external program ensure the parameters etc cant be altered to do something else ( for example I have a script that uses tail and takes a parameter for number of lines, I realised somebody could chain another command instead and made sure it strips out anything 'cept numbers)
* Strip out HTML tags in a paranoid fashion, to prevent any odd javascript/ssi code possibly being entered into guestbooks etc..
Am I safe enough with the kind of things I do above? I worry about buffer overflows but am pretty sure perl doesnt suffer from these because it doesnt have fixed size variables. Anyone know for sure?
Thanks!
You can also use taint [gunther.web66.com] to force Perl into 'paranoia mode' - this basically means that Perl will not trust any data obtained from outside the script, and will cause an error if such data is used in a potentially dangerous way.
a- never trust anything passed by the user. From email addresses to names.
b- length of input. Restrict the length to something known.
c- never assume that the user is going to pass only a specific set of values.
d- never allow anything input by the user to be passed on a system call.
e- parse every input value for validity. That means for length if it is a string, and size if it is numeric input. Lastly, escape the string if you absolutly must pass the string to a system call.
Buffer overflows are more a vulnerability of the server than of Perl. If the server can accept the input and put it into a system variable, then it should be safe for Perl to grab it. Still, check the length of the input to make sure it is within limits. Although, there has been some talk of an overflow in submitted form data. (Still looking for the real answer - see other post on cgi security [webmasterworld.com]).
Another good idea to improve security is to store sensitive data outside of the webserver directory tree (if possible) so that it can't be inadvertantly displayed in the browser.
It's often recommended that you check the referring URL to make sure that the script has been called from your own site - ie no one has been tampering with your form to send malicious content to your script. This is fairly easy to get around by spoofing the referring URL, but every little helps and it might deter the casual tamperer...
I had heard perl was "insecure", but nobody explained how.
-jhee
Backus - he lurks.
Perl, duct tape of the internet. I think with gig machines with gig(s) of ram becoming common, we are just now getting to the point where perl is fully functional. If you ever tried perl back in 95-96 and watched server after server come to a crawl, you would have sworn there was no way you'd ever run it - you'd get that old Timex Sinclair feeling all over again.