• Jeff Moden (3/24/2013)


    Michael L John (3/21/2013)


    I stand corrected.

    BUT I also stand by the statement because unfortunately poor security seems to be the norm. It seems as if DBA's are so busy with everything else that security is overlooked.

    I will amend the statement to be:

    "xp_cmdshell CAN be a security risk"

    But it's not. The only people that can use it are people with "SA" privs or if someone was dumb enough to grant a proxy to a user. Anyone with "SA" privs can turn it on even if it's off. It's like saying that using Powershell is a risk. It's not unless a malicious person gets in with the right privs to use it. If a malicious user with the right privs gets into your server, it's not going to matter if you use xp_Cmdshell or not and it sure won't matter if it's turned off or not. The malicious user will simply turn it on.

    If the DBAs are too busy to mind their primary job, that of security, then it might be time to have a "come to Jesus" meeting with them. No application and no user should have "SA" privs and THAT's the only way you're going to keep xp_CmdShell from being used maliciously. It's not a risk. It's a symptom of really bad security. You should be able to have stored procedures that use xp_CmdShell up and running just fine and be perfectly secure. If you can't, then the system is at risk even if xp_CmdShell is turned off.

    To me, your reasoning is analog to:

    Why would I bother locking the doors when I leave my house when a malicious contractor installing a sprinkler system at my home could simply drive the Bobcat Tractor they're using to dig trenches through my front door and take anything they wanted.

    No one I know would subscribe to that line of thinking so why apply it to securing a database?

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato