Update:
Arshan Dabirsiaghi noted that if you use cmd.exe, /bin/sh, or any other equivalently chainable executable loader, you can still introduce command injection vulnerabilities in .NET in Java. See the Webgoat lesson for an example of this.
Rudolph Araujo pointed out an interesting security note on MSDN about the CreateProcess function (which is called by Process.Start()) regarding the fact that unintended executables may be executed if there is whitespace in the path.
Dan Cornell made two really cool test projects for Java and .NET. Both of them demonstrated that a healthy set of shell meta-characters are ineffective at introducing new commands into system calls in Java and .NET.
System calls should probably be avoided in any case, since the executables aren't constrained by the security features of managed languages. However, it certainly seems like this threat is pretty well mitigated in these platforms, at least until someone finds a vulnerability.
Original:
Command injection (also called shell injection) can be a huge problem. Recently, I was working on an old Perl/CGI system that allowed command injection through the system command that ultimately led to a reverse shell on the web server.
I was trying to develop some examples of command injection in .NET, using the Process.Start method. The Process.Start method takes a file and arguments as parameters. You can't specify additional commands through meta-characters like semi-colons (;) and pipes (|). Java seems to be similarly invulnerable - according to this OWASP page:
There are many sites that will tell you that Java's Runtime.exec is exactly the same as C's system function. This is not true. Both allow you to invoke a new program/process. However, C's system function passes its arguments to the shell (/bin/sh) to be parsed, whereas Runtime.exec tries to split the string into an array of words, then executes the first word in the array with the rest of the words as parameters. Runtime.exec does NOT try to invoke the shell at any point. The key difference is that much of the functionality provided by the shell that could be used for mischief (chaining commands using "&", "&&", "|", "||", etc, redirecting input and output) would simply end up as a parameter being passed to the first command, and likely causing a syntax error, or being thrown out as an invalid parameter.
Obviously, if you let the user specify the first argument (the file name) then you are in trouble, but that's not really injection. Additionally, if you get into native/unmanaged code in your app you lose any protection. Those caveats aside, are Java and .NET impervious to command injection?
URL shortening is definitely on the "hot this spring" list - the list of services is growing, there's news of a $2M funding, and all the cool content-constrained tweets and Facebook status updates are sporting bit.ly, is.gd, and ewerl.com links. It seems like a simple enough service, but what about the security implications? A quick Google search finds a discussion of drive-by attacks and phishing. It's true that we don't know the domain of a tiny URL, and may get sent to something decidedly unfriendly. Many of the URL shortening sites have implemented previews to help out here.
What about cross-site scripting? I know that I suggested using tinyurl for a reflected XSS attack demo a while ago. As a simple proof of concept, here's a reflected XSS vulnerability on xssed.com and the payload for both is.gd and bit.ly. Are there any URL shortening services out that incorporate a NoScript-style anti-XSS approach?
What about cross-site request forgery? Bit.ly allows you to preview the full URL if you download their Firefox add-on, which may help you avoid obvious attacks.
Maybe a Site Advisor-like blacklist to prevent links to known bad guy sites?
Does anyone care? Do I need to write my own secure URL shortening service so I can raise $3M in funding and buy a really long foosball table for the break room?