• 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.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)