Why is SendKeys bad practice?

Question

When dealing with signal interrupt issues, the Ctrl-C SIGINT would close my ssh session. (I'm sure you've all heard this before, and I'm certainly sick of it too - so I won't bother explaining that further.) In short, I could achieve the desired result by using the SendKeys function.

Now many people discourage using SendKeys unless it is absolutely necessary. The method is often bashed for security flaws, but the only viable reason I see (but don't fully grasp) was that it could fill the keyboard buffer - which if poorly handled, could lead to undesired system results.

Every other reason was just the generic "It causes security issues. Don't use it." I read that it could significantly help to block both mouse and keyboard interaction during the process, such as using BlockInput.

I feel that undesired system results could result from nearly anything these days. I want to know, specifically, why it is such a "bad practice" to use this approach when programming, and to actually understand these security flaws.

Answer 1

This used to be a valid security concern before UAC. For instance, you could issue ATL+CTRL+DEL or to copy information from one application to a malicious one or run key scripts without the user's consent.

It's likely though, that many applications (even direct x) will block SendKeys and you will get security exceptions.

Use SendMessage or SendInput as alternatives.

With the introduction of .NET 3 and user account control, these gaps have been closed. In fact, windows 8 was just rated secure for the government this week.

Some applications like Outlook might raise exceptions (for good reason) if you try to sendkeys. Also, there's likely no harm in your application using it, the potential harm is malicious software misusing the feature.