Don't ask to ask, just ask | |
PerlMonks |
Re: CGI.pm Filter out recurring NULL Bytesby afoken (Chancellor) |
on May 25, 2016 at 21:50 UTC ( [id://1164145]=note: print w/replies, xml ) | Need Help?? |
I started playing around with a filter that can do it. But I'm not sure where would be the best place to implement the filter. Should it do all the names and values of the param's or just as it calls them by name and only filter the values of the names? No. Don't run stupidly guessing filters over your input, that wastes CPU time at best or opens other security holes at worst. Validate your input. Don't accept data that does not pass validation. Enabling taint mode (see perlsec) forces you to validate your input. That does not make your code absolutely secure, but it prevents oversights. Imagine the simple-and-stupid integer calculator example:
Should any of these tests fail, abort all further processing and emit an error page, typically with an HTTP status code of 400 (BAD REQUEST). Don't even try to do anything else before all parameters are validated. Especially do not try to open database connections or to aquire locks. Your attacker usually can send much more requests than you expect, so your machine may run out of resources quite fast. So your script must get rid of invalid or malicious requests as fast as possible, using as few resources as possible. Update: For your real application, you should create a similar list (or table) of requirements and checks for all parameters. If you don't expect file uploads, you can disable the upload handling in CGI.pm, see $CGI::DISABLE_UBLOADS in the CGI documentation. When you validate parameter values, you want to check against a white list, i.e. specify allowed values. Blacklisting is not reliable. Validating file uploads is a little bit tricky: CGI.pm can attempt to limit the size of POST requests, but at that point, the web server may already have accepted an insanely large request. You may want to limit the request size in the webserver, too. Even well-behaved browsers allow uploading arbitary junk, and things get worse when someone intentionally generates invalid uploads with malicious filenames, malicious mime types, malicious data in the file. So you have to validate all data you use from file uploads, and you have to validate the file contents. Just looking at some magic numbers like file, File::MMagic, and File::MimeInfo::Magic do, is not sufficient. See https://quadhead.de/storing-javascript-code-in-gif-images/ for a simple demo, http://jklmnn.de/imagejs/ for a tool to generate images containing executable javascript code. Alexander
-- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
In Section
Seekers of Perl Wisdom
|
|