Here are three commands often found in PowerShell scripts that you should be careful about because they can have severe side effects:
exit
“exit” is not really a command but rather part of the language. It exits PowerShell immediately, and optionally you can submit a number which will be the “error level” that callers can query.
Use “exit” only when you really want to exit PowerShell. Do not use it inside of functions or scripts designed to be called by others. Try for yourself: when you run below function, it outputs “A” and then exits. However, your PowerShell environment will close as well.
function test { "A" exit "B" }
If you want to just “exit” portions of your code without exiting the entire PowerShell environment, use “return” instead:
function test { "A" return "B" }
Set-StrictMode -Version Latest
This command makes PowerShell behave more rigid and i.e. throw exceptions when you read a variable or call a method that really does not exist. In default mode, PowerShell would simply return $null.
Enabling the strict mode is a great idea for professional PowerShell users when they write script code because PowerShell forces you to write cleaner code. However, never add this command to your production code!
For one, it makes no sense: your production code is done, so enabling rigid checks won’t change anything. What’s worse: you impose your own preferences on production machines, and this can cause unexpected (and unnecessary) exceptions. Let’s assume your code calls other code or uses commands from other modules, and their authors go with PowerShell’s lazy mode. When your code now enables strict mode, the same strict rules are applied to all code called from your code.
Even if this worked well during testing, you never know when other authors update their code, and issues do come up.
If you find “Set-StrictMode” calls in your code, simply remove them. If you like Strict Mode, enable it in your personal PowerShell profile instead, or enable it manually whenever you feel like it.
Invoke-Expression
This command takes any string and executes it as if it was a PowerShell command. While this is very powerful and sometimes plain necessary, it imposes all risks of so-called “SQL injection” security issues. Have a look:
# get user input $Path = Read-Host -Prompt 'Enter path to find .log files' # compose command $code = "Get-ChildItem -Path $Path -Recurse -Filter *.log -ErrorAction SilentlyContinue" # invoke command Invoke-Expression -Command $code
When you run this code, you get asked for a path, and when you enter i.e. “C:\Windows”, you see a list of log files. However, the executed code is directly dependent on what the user enters. When you run the code again, try this: $(Get-Service | Out-GridView; c:\Windows)
This time, PowerShell first lists all services and outputs them to a grid view window. You “injected” code by using “$()”.
Avoid Invoke-Expression wherever you can, and of course the example above was somewhat constructed. There was no need for composing string commands, and you could have submitted the user input directly to the appropriate command parameters:
# get user input $Path = Read-Host -Prompt 'Enter path to find .log files' # invoke command Get-ChildItem -Path $Path -Recurse -Filter *.log -ErrorAction SilentlyContinue
If you must use Invoke-Expression, take extreme care to validate any user input and make sure a user cannot inject code.
PowerShell Conference Europe (psconf.eu) opens June 2, 2020, in Hannover, Germany, and you can be part of it! 4 days, 3 tracks, 80 PowerShell sessions, and 40 renown speakers from around the world (including PowerShell inventor Jeffrey Snover, the PowerShell team with Steve Lee, the Amazon AWS team, and many more) are waiting for questions and discussions, providing authoritative firsthand information, tips and guidance for professional PowerShell scripters.
Find out more at http://powershell.one/psconfeu/psconf.eu-2020/about, download the mobile app with sessions and speakers at http://psconfeu.sessionize.com/, and secure your seat at https://psconf.eu/register.html.
