A quick cursory look of your code doesn't reveal much ... It doesn't look as if you are running under strict as there doesn't appear to be any definition of scope of some of your variables. Nevertheless, the snippet you have given doesn't show enough for any judgement to be made of its 'fitness' for any given task - There is no indication of where you are deriving some of your values from, in particular, $tempUID and $call, without which any assessment of security tightness of your code would be flawed.

A general pragma to remember with regard to CGI security is to never trust anything which comes from the browser - Irrelevant of whether it be query arguments, cookie data or user submitted information, don't trust it! This is vitally important where any of the submitted information may be used to manipulate the filesystem or process tree directly - In such instances, you should be excluding everything and then selectively permitting that which is vetted and permissable. This can lead to a great deal of code overhead but given the consequences of a failure in security, this is a little price to pay in development time.

With regard to open and security inherit to the command itself, this comes down very much to the arguments which are passed to it - There has previously been the discussion on the 2-argument invocation of open with specific reference to passed arguments. But at the end of the day, the security concerns will center on how the data is parsed and vetted prior to being passed to open - Has the data been checked for shell escape characters? Does the target file to be opened exist? Is the target file a directory or symbolic link? Are the permission and ownership rights of the target file as expected and allowed? The list goes on ...

In short, limit the allowable parameters, code defensively and don't trust anything sent from the browser.

 

perl -e 's&&rob@cowsnet.com.au&&&split/[@.]/&&s&.com.&_&&&print'