Protecting Against Malicious Code Injection

re: Protecting Against Malicious Code Injection

Mike — Fri, 24 Nov 2006 19:29:57 GMT

So let's say you have a situation where you _need_ to include user input in an invoke-expression statement.

What would be the best approach to escaping the input? I imagine the usual characters like " ' ; etc would need to be backticked. Perhaps there needs to be a standard function for this kind of thing?

re: Protecting Against Malicious Code Injection

PowerShellTeam — Sat, 25 Nov 2006 22:38:29 GMT

It really depends on what you mean by "include the user input". If you just want to use it as data, put it in a variable and then reference the variable:

$i = read-host

invoke-expression 'write-output $i'

There is no need to quote the user's input since it's just a value. Of course there's also no reason to use invoke-expression in this case since

write-output $i

will work fine. Perhaps you can expand on the scenario where you need to include the user's input?

-bruce

--------------------------

Bruce Payette [MSFT]

PowerShell Technical Lead

Microsoft Corp.

re: Protecting Against Malicious Code Injection

PowerShellTeam — Mon, 27 Nov 2006 20:05:47 GMT

Another thing to keep in mind is what you consider to be your trust boundary.

Most commonly, improper use of Invoke-Expression will just result in buggy code -- the user might use a semicolon and wonder why they are getting an error message. For that reason, you should avoid Invoke-Expression when dealing with user input unless necessary.

If the user is running your script on their own machine under their own credentials, then you don't have to worry about the security aspects of Invoke-Expression, as they could just as easily do whatever they wanted to trick your script into anyways. If you've taken input from an untrusted user on the network, an untrusted user on a web page input field, or some other untrusted source, THEN you should be extremely conservative with what input you allow.

Code injection attacks become attacks once they cross a trust boundary. If they don't cross a trust boundary, they are just a complicated and buggy way of doing what a user could already do.

Lee