クロスサイトスクリプティング(XSS)という脆弱性のためにサイト作成が阻害されたと思ったら、OSコマンドインジェクションが原因だった

XSS (Cross Site Scripting) Did Not Prevent Me From Completing My Website And OS Command Injection Prevented Me From It


 

なぜ阻害されたのか

前回書いた記事、複数フォルダのExcel・Word・Powerpointファイルを開いて保存して閉じるだけのマクロでは、ソースコードを掲載できない、という事態があり、私にとって大きな学びになりました(現在は解消済み)。

これは「クロスサイトスクリプティング(以下、XSS)」と呼ばれるセキュリティホールに対する対策を講じたことが原因だと思っていました。

しかし、「OSコマンドインジェクション」と呼ばれるセキュリティホールに対する対策を講じたことが原因でした。

これら2つを防ぐためなどに「WAF(Web Application Firewall)」を設定したことがソースコードを掲載できなかった原因です。

最初は、「XSS」が原因だと思っていましたが、調べていくうちに「OSコマンドインジェクション」が原因だとわかってきました。

この記事では、「XSS」と「OSコマンドインジェクション」の両方を説明し、どうして阻害されたのかを明らかにしたいと思います。

 

「XSS」とはなにか

「XSS」という脆弱性があると、攻撃者はそれを利用して、サイト作成者である私ではなく、サイトを見るユーザの皆さんを攻撃します。

今までの攻撃者は、自分のサイトを閲覧したユーザに対して攻撃していました。しかし、「XSS」の脆弱性を突く攻撃者は、自分のサイトではなく、脆弱性を持ったさまざまな、数多くのサイトを利用してユーザを攻撃します。

主な攻撃は、「Cookieの盗難」「ページの改ざん」「投稿者(Author)の権限悪用」です。「Cookieの盗難」では、Cookieにユーザ名やパスワードを保存しているようなサイトだと、その盗んだ情報をもとに二次被害が発生する可能性があります。「ページの改ざん」では、まったく関係ない情報を表示したり、問い合わせフォームに入力した情報を全く別の攻撃者のサイトに送ることも可能です。「投稿者(Author)の権限悪用」では、本来権限のない攻撃者が権限を奪い取り、削除できないはずのファイルを削除してしまうこともあり得ます。

しかし、これらの脆弱性は、「WordPress4.9.8」では対策されています。

私の使っている「XSERVER」でも、「WAF(Web Application Firewall)設定」がなされています。これは「Wordpress」に限らず、ウェブアプリケーション全般にかかわる設定です。

 

サニタイジングとはなにか

「XSS」の脆弱性の対策として、「投稿者(Author)」のブログ編集や、ユーザの問い合わせフォームからの入力の際に、「入力チェック」をして、特殊文字の無害化(サニタイジング)をすることです。

そもそも、「XSS」とは入力した文字列を、Wordpressのようなウェブアプリケーションが、HTTPやHTMLで定義されているいくつかの特殊文字としてそのまま出力してしまうことによって起こります。

ですから、そのような文字を無害な文字に置き換え(無害化)してやればいいわけです。

ここでは、ブログ製作に関係する「HTML」のサニタイジングについて説明します。

 

HTMLのサニタイジング

「HMTL」は「タグ」と「本文」に分けられます。

<p>ここでは、ブログ製作に関係する「HTML」のサニタイジングについて説明します。</p>

「タグ」はブラウザに表示されない「<p>」や「</p>」部分で、「本文」はブラウザに表示される「ここでは、ブログ製作に関係する「HTML」のサニタイジングについて説明します。」の部分です。

本文のサニタイジング

本文で特殊文字となるのは「<」「>」「&」の3つです。

<pre><span style="font-size: 12pt;"><code>With CreateObject("WScript.Shell")
    Const ARGUMENT_WINDOW_MINIMIZED As Long = 7
    .Run "cmd /c" & myCmd, ARGUMENT_WINDOW_MINIMIZED, True
End With</code></span></pre>

ここに挙げたソースコードは、3つの特殊文字、「<」「>」「&」のサニタイジングを済ませています。

「<」は「&lt;」、「>」は「&gt;」、「&」は「&amp;」に変更しました。

タグのサニタイジング

タグで特殊文字になるのは「"(ダブルクォーテーション)」、「'(シングルクォーテーション)」の2つです。

<pre><span style="font-size: 12pt;"><code>With CreateObject("WScript.Shell")
    Const ARGUMENT_WINDOW_MINIMIZED As Long = 7
    .Run "cmd /c" & myCmd, ARGUMENT_WINDOW_MINIMIZED, True
End With</code></span></pre>

上記のソースコードとまったく同一ですが、タグについてサニタイジングを済ませています。

「"(ダブルクォーテーション)」は「&quot;」に、「'(シングルクォーテーション)」は「&#39;」に変更しました。

 

ところが、話はそこで終わらなかった

上記のサニタイジングをおこなっても、「WAF」の設定を「ON」にしている限り、次のようなエラーはなくなりませんでした。

なぜサニタイジングをおこなってもエラーがなくならないのか、まったくわかりませんでしたので、次に取るべき手段がわかりませんでした。

そこで、上記ソースコードに含まれる単語ごとに削ってはアップし、削ってはアップし、エラーが起きるかどうかを見極めました。

何度目かのトライでとうとう原因を突き止めました。

cmd

この「cmd」のせいでエラーが起きていたのでした。

じゃあ、これは何のエラーなのかと調べたところ、「OSコマンドインジェクション」という脆弱性であることがわかりました。

 

OSコマンドインジェクションとは何か

WordPressなどのウェブアプリケーションがウェブサーバのシェルを呼び出してコマンドを実行する動作のことです。

具体例としてよく挙げられるのが、メールアドレスを入力して実行すると、mailコマンドを利用してメールを送信するウェブアプリケーションです。

WordPressの問い合わせフォームもそれに含まれます。

私の例では、「cmd」がエラーに該当する文字列ですが、WindowsではコマンドプロンプトでOSの中核部分を操作する命令です。

UNIX系ではbashやcshにあたります。

 

OSコマンドインジェクションの対策

じゃあ対策は何なのか、ということになりますが、基本的にはサニタイジングになります。

上述の「<」「>」「&」「"」「'」の5文字をサニタイジングします。

しかし、「cmd」という文字列をサニタイジングはできません。

ですので、取れる手段は2つです。

1つは、「WAF」を設定すること。

2つ目は「cmd」を全角文字にすることです。

「WAF」を設定しなければ、「cmd」という半角文字を記事中に表示することができますが、それでは脆弱性が残ってしまいます。

ですので、「WAF」を設定したうえで「cmd」を全角文字で表示することによって、脆弱性に対処しつつ、「cmd」という文字を表示することが可能になります。

 

ようやくわかった

最初、「XSS」が原因だと思ったのは、XSERVERに対する問い合わせメールの返答からでした。「XSS」が原因だと思われます、と返答には書いてありました。

ところが、原因は「XSS」ではなく、「OSコマンドインジェクション」でした。

ようやく原因がわかったものの、めんどうなことには変わりありません。

しかし、どうしても「cmd」という文字列はブログを書くのに不可欠なので、使わざるを得ません。

これからは、注意書きとともに「cmd」を使っていこうと思っています。

コメントを残す