xp_cmdshell はストアドプロシージャ内で安全に使用できますか？他に選択肢がない状況はありますか？言い換えると、ストアドプロシージャ内での使用は、常にセキュリティの問題としてフラグを立てる必要がありますか（よく知られているソースコードアナライザーによってアドバイスされています）？
言い換えると、次のステートメントに同意しますか（直接引用）？
関数 xp_cmdshell は安全に使用できません。使用しないでください。
コメント
- なじみのない人向け" xp_cmdshell "、これは" Microsoftが提供し、マスターデータベースに格納されている拡張ストアドプロシージャです。この手順により、T-SQLコードを介してオペレーティングシステムコマンドをWindowsコマンドシェルに直接発行できます。"そうです!!
- いいえ、ありません'同意しません。それは私が知っている少なくとも2つの異なる方法を使用して絶対に安全に使用することができ、そのうちの1つはセットアップが非常に簡単です。問題は、BOLが'実際にその方法を教えてくれないことです。
回答
常にリスクです。常にレビューする必要があります。適切に軽減することができます。
正当な用途があり、場合によっては必要ですが、入力に注意してください！
コメント
- ユーザーを事前定義された操作のグループに制限する方法がないため、特権を付与すると、ユーザーは任意のコマンド文字列を実行できます。つまり、'特権の細分性を許可したり、別のコントロールが完全なコントロールになると述べたりしませんか？
- SQL Serverは私にとってセカンダリなので、'間違った例：ストアドプロシージャに対する実行権限をユーザーに付与すると、そのプロシージャをユーザーが実行できるようになります。変更することはできず、'そのストアドプロシージャで使用されるすべてのものにアクセス許可を付与する必要はありません。それを含むストアドプロシージャを実行するために
xp_cmdshell権限を付与する必要がある場合は、'間違いなく問題が発生しています。私は'必要ではないと合理的に確信しています。この手順は、通常のユーザーが所有するべきではありません。 - @TobyS …それが問題です。ある種のステートメント。簡単な答え：xp_cmdshellは悪です。長い答え：それは状況次第です。 ;）
- @ SteveS-現在のバージョンのMSSQLでは、異なる OSアカウントを設定してxp_cmdshellコマンドを実行できます。
- @JeffFerland … you " I 'は、必須ではないと合理的に確信しています。この手順は、通常のユーザーが所有するべきではありません。"それは' 100％正しいです。 'は、テーブルが関係しているかどうかをユーザーが知る必要はなく、xp_CmdShellを気にする必要はありません。はい、'セットアップは非常に簡単です。
回答
xp_CmdShellをオフにするのは、腐った肉の上にベールをかぶせるのと少し似ています。それはテーブルに誤った安心感をもたらし、ハエはまだ肉に到達することができます。説明させてください。
xp_CmdShellを使用できるのは誰ですか？そうです。「SA」権限を持つユーザー/アプリのログイン、またはプロキシを付与するという恐ろしい間違いを犯したユーザーのみが使用できます。
次の質問。xp_CmdShellをオフにしている場合、誰がオンに戻すことができるのは唯一の人ですか？もう一度修正してください。オンに戻すことができるのは「SA」プロキシを持つ人/アプリだけです。
では、xp_CmdShellがセキュリティリスクであるという本当の問題は何ですか。 ？答えは、xp_CmdShellはセキュリティリスクではないということです。不十分なセキュリティが唯一のセキュリティリスクです。ハッカーまたは悪意のある内部ユーザーが「SA」特権を使用してシステムに侵入した場合、xp_CmdShellを瞬間的にオンにすることができます。そうです、そのアクションはログに記録されますが、セキュリティが最初から大幅に不足しているという文書化された証言しか提供しません。
xp_CmdShellをオフにしても、ハッカーコードのその部分が再びオンになって実行される機会を提供する以外は、セキュリティには何の影響もありません。
もう一度言います。 xp_CmdShellはセキュリティリスクではありません。悪いセキュリティだけがセキュリティリスクです。セキュリティを修正してから、xp_CmdShellをオンにします。それは「素晴らしいツールであり、あなたは」悪いセキュリティ慣行と神話のためにそれを見逃しています。
コメント
- 私はあなたに完全に同意します、ジェフ。 syadmin権限を取得した攻撃者は、CmdExecジョブステップを使用してsaが所有するSQL Agentジョブを作成し、xp_cmdshellと同じことを実行できます。また、プロセスを開始するCLRストアドプロシージャを作成することもできます。それはxp_cmdshellとどう違うのですか？サーバーを適切に保護することが、セキュリティリスクを防ぐ唯一の方法です。
- ああ、私の古い'の友人です。フィードバックありがとうございます。 "もう一度"を参照してください。
- +1あなたは間違っていますが、私はあなたが間違っているのが好きですあなたは人々に安全性を低下させることを奨励しているので、それはひいては興味をより楽しい場所にします。はいすべてにSQLServerをインストールします。また、構成を使用して簡単に修正する方法についての追加部分もあります。気に入ってください< 3。その2020および9 / 10SQL Serverは正しく強化されませんが、もちろんDB管理者XDのせいです
- ええと…私は'あなたは同じプラスワンが間違っている。 xp_CmdShellを無効にすると、サーバーが" harden "になると考えるのが間違っているので、プラスになりたいと思います。 ' t。
回答
私は思います「使用すべきではない」というのはおそらくかなり良いアドバイスです。これは「常に安全ではない」というカテゴリではなく、xp_cmdshellは危険であり、その使用は懸念と慎重な調査の根拠となるという認識です。
そしてセキュリティリスクを回避する方法を知っていると思っていても、xp_cmdshellはおそらく使用するのに最適なツールではありません。より良い解決策がある可能性があります（偶然にもリスクが少ないものです）。
回答
“With大きな力には大きな責任が伴います。」そうは言っても、xp_cmdshellは、レドモンドから抜け出すための最悪のセキュリティ列車の難破船の1つだと思います。
編集：2020年、ペネトレーションテスターとして10年以上-xp_cmdshell最高の組み合わせであるため、私が遭遇した最も恐ろしいセキュリティリスクの1つですの;広く普及し、銀行などの重要なビジネスで使用され、最大の影響力を発揮します。 SQLmapを使用してSAを取得し、WebアプリでSQLインジェクションのみを使用してxp_cmdshell …を再度有効にすることができます。
あるエンジニアから別のエンジニアとして、マイクロソフトに感謝します。文字通り、あなたなしではこれらのシェルを入手できませんでした。
コメント
- 'は古い質問ですが、本当に言わなければなりません。' 3人があなたのトローリングを真剣に受け止めていることに驚いています。
- @spaghettidbaペンテスター
xp_cmdshell()は神からの送信であるため、私は真剣に取り組んでいます。非常に悪いのは、Microsoftの誰もこの問題を修正しようとさえ考えていないということです。 'マイクロソフトの製品やアプリケーションは脆弱であるため、マイクロソフトのプラットフォーム上に構築されていることに非常に満足しています。面白いことに、私の最初のゼロデイ攻撃は、16歳のときのMicrosoftセキュリティ製品でした。これは10年以上前のことです。 - @ rook-It '実際のPENテスターと話をすることはめったにないので、'この機会に質問する必要があります（戦いを探していません… I '正直に、そして本当にあなたの良い経験に興味があります）、もしあなたが誰かに入ることができないなら' ' SysAdminprivsを備えたgoodielockerですが、'が有効になっていても、xp_CmdShellを攻撃者として使用することはできますか？もしそうなら、それから保護する方法はありますか？
- @JeffModen。 はいなので、sqlmapはこれを非常にうまく実行します。 SAでない場合でも（クエリスタッキングのため、SQLクエリを使用してSAアカウントにログインできます）、挿入されたSQLクエリを使用してSAを取得し、任意のコマンドを再度有効にすることができます。それでもパスワードを知る必要があります…しかし、ブルートフォース攻撃を受ける可能性があり、この攻撃が考慮されなかった場合、' SAアカウントのパスワードが脆弱になる可能性があります…そして私はこれが銀行でさえ何度も起こるのを見てきました。 SQL-Serverの専門家ではありませんが、この攻撃を防ぐことができる強化があると思います…しかしデフォルトではありません!!!!勝利のためのSQLMap！
回答
SQL Server環境で使用されているセキュリティの種類、混合または統合（Windows）？ sysadmin SQL Serverの役割はいくつありますか？ MSのベストプラクティスでは、統合認証（saログインなし、SQLログインなし）と、sysadmin SQLServerロールの2つのみが必要です。これらのベストプラクティスに従うことで、露出が大幅に軽減されることを提出します。さらに、xp_cmdshell（sqlcmd以前のモードとPowershell以前）を使用すると、スケジュールされた範囲内から数百マイル離れた本番サーバーからDRサーバーにトランザクションログファイルをコピーできます。 SQLエージェントの仕事。ここでは悪はありませんが、あるポスターが述べているように、「状況によって異なります」。
回答
jl01を強調するsの答え（私は+1を付けました）…
奇妙なことに、適切に保護された安全なSQL Serverの良い方法は、実際にxp_CmdShellを有効にすることです。つまり、システムが十分に安全であれば、xp_CmdShellが有効になって使用されているなどの些細なことを心配する必要はありません。
特にSQLServer 2005の時点では、事実上理由はありません。 DBA以外のユーザーが、適切にロックダウンされたシステムのストアドプロシージャに対して、PUBLICprivおよびEXECUTEprivよりも大きいprivを持つ必要がある理由。 実際、正しく実装されていれば、PUBLIC特権を持つユーザーは、xp_CmdShellを直接実行できなくても、xp_CmdShellへの呼び出しを含むストアドプロシージャを実行できるはずです。
MSがコマンドシェルプロキシを作成したのは皮肉なことだと思います。 プライバシーの低いユーザーが、テーブルを表示することすらできないときにxp_CmdShellを直接実行できるようにします。