使用ESAPI执行器时如何使用运算符>>？

Question

While using the ESAPI executor to run a simple command such as:

C:\\Windows\\System32\\cmd.exe /c echo test >> D:\\wow\\test.txt

while the C:\Windows\System32\cmd.exe is the executable file. and the /c echo test >> D:\wow\test.txt are parameters. The problem is that the codec ruins the operator >> (which means avoiding it or referring to it as a String. so the output will be just be printing the "test >> D:\wow\test.txt".

Answer 1

The codec is doing exactly what it should be doing. Maybe an overly simple example would make that more clear as to why this is the correct behavior.

Let's suppose you have a web application where you have a user upload a document and then you run a spell-check on it for them and send them back the corrected results. For sake of simplicity, left's assume that you have set the current working directory to be specific to each user using your service and that you have a "spellcheck.bat" that takes a single filename as an argument and you planned to execute the string:

C:\Windows\System32\cmd.exe /c C:\spelling\spellcheck.bat userFilename > spelling-errors.txt

where userFilename is the name of the users uploaded file. Your intent is to run spellcheck.bat with the user's uploaded file and filename and the read and display the 'spelling-errors.txt' file back to the user. (IRL, that would probably be a temp file in a different directory, but I want to make this simple.)

So what happens if 'userFilename' contains a '>' character? Surely you want that quoted appropriately, do you not? Because otherwise an attacker might be able to overwrite some file that you don't want to be overwritten, including things like your web.xml or other configuration / properties files. Because running something like (say)

C:\Windows\System32\cmd.exe /c C:\spelling\spellcheck.bat myDoc.txt >sucker.txt > spelling-errors.txt

is going to create 'sucker.txt' and if that filename exists, it will be truncated and replaced by the output of "spellcheck.bat myDoc.txt". That is probably NOT what you want.

So preventing file I/O redirection operations via '<', '<<', '>', and '>>' is intended. If you really want to allow them (and I recommend against it), then you will have to parse your own command string based on what you want to allow.

Also, while I'm not sure it is true for Window's cmd prompt shell, it certainly is true for *nix shells that one can also do command execution in the redirection as part of the file redirection. For example, in bash, I can do something like this

cat < $(ls foo)

and if the file 'foo' exists, the 'ls foo' command will list the output foo, so this command becomes:

cat < foo

and we just end up taking stdin for the 'cat' command from the file 'foo'. But an attacker could do something much more nefarious with it. Of course, the OS codec also prevents '$(...)' style command substitutions, but I hopefully have made my point.