ワードプレスのプラグイン開発者が知っておきたい5つのセキュリティ対策
はじめに
PC遠隔操作事件をご存じでしょうか?この事件は2012年の初夏から秋頃にかけて発生した事件です。その手口は気を引く誘導文でリンクをクリックさせてPCの重要情報を抜き出す、あるいは不正なプログラムをダウンロードさせたりして利用者のPCを遠隔操作するというものです。そして、遠隔操作されたPCは所有者にわからないようにこっそりと某所に殺人予告の書き込みや脅迫メールを送信する。
すると、この脅迫メールを受け取った人は、真犯人ではなく操作されたPCの所有者を犯人と勘違いしてしまう。このリンクをクリックさせて重要情報を抜き出すときに使われたのが、ウェブサイトのセキュリティを突いたCSRF(クロスサイトフォージェリ)による物でした。
ワードプレスも見方によってはウェブサイトと言えるので、同じようにCSRFの脆弱性を突かれることも十分に考えられます。弊社で扱っている簡単不動産PROもワードプレスを使用しているので、CSRF脆弱性への対策方法を知っておかないと、気になって私は毎日食パンを食べないと眠れなくなってしまうのです。それに、今後はワードプレスのプラグインやカスタマイズの案件も増えそうなので、この機会にセキュリティを意識したプラグイン開発方法をまとめておくことにします。
ワードプレスのプラグインを開発するに辺りメジャーな脆弱性は次の5つです。
- XSS
- CSRF
- SQLインジェクション
- ディレクトリトラバーサル
- HTTPヘッダーインジェクション
これらを上から順に、その内容とワードプレスでの対応策を見ていきます。
1.XSS(クロスサイトスクリプティング)
2010年に動画共有サイトのYouTubeがXSS脆弱性を突かれる事件がありました。多くのユーザーのコメントが表示されなくなったり、画面に「有名歌手の○○が交通事故で死亡」という類いのショッキングなデマがポップアップで表示されるなどの被害が広がりました。このほかにも不正なポップアップが出たり、悪趣味なWebサイトに転送されたりするというケースが相次いだだそうです。このようにXSS脆弱性とは、スクリプトの内容を意図せずウェブウェブサイトに埋め込み、悪意のあるコードを訪問者のブラウザに送信する攻撃手段の事です。
例えば、問い合わせフォームに次のようなスクリプトを送信すると、確認画面でjavascriptが実行されてしまい、あなたのクッキー情報が第3三者に抜きとることができてしまうでしょう。
攻撃例:
<script>alert(document.cookie);</script>
他にも確認画面のフォームでhiddenを使って次のようなコードを書いている場合も要注意です。
<input type=”hidden” name=”name”value=”<?php print $_POST[‘name’]; ?>”>
$_POSTや$_GETはユーザーが入力した内容が保存されているグローバル変数ですが、これをエスケープしないでそのまま出力すると前述した通り悪意のあるコードが実行されクッキーに保存された個人情報が抜き取られてしまうのです。
万が一、クッキーの情報を抜き取られると、ショッピングサイトなどであなたになりすまして勝手に買い物をされる危険性がある。対応策はユーザーからの入力を画面に表示する時にきちんとエスケープする事です。
XSS攻撃へのワードプレスでの対策
ワードプレスのプラグインを開発する際には、出力内容によってそれぞれ次の関数を使用すると良い。
数値 | intval() |
---|---|
HTMLや平文 | esc_html() |
タグの属性値 | esc_attr() |
URL | esc_url() |
スクリプト | esc_js() |
2.CSRF(クロスサイトリクエストフォージェリ)
2005年にmixiである珍現象が多発した。mixi上であるURLをクリックすると「ぼくはまちちゃん!」という日記が勝手にアップされてしまうというものです。実はこれはCSRFの脆弱を突いた攻撃でした。このように本来、管理者である本人しか日記をアップできないのですが、CSRF脆弱性を突かれてしまうと、第3者に管理権限を乗っ取られ、不正な操作をされてしまう恐れがあるのです。
また、最近MVCフレームワークを使ったウェブサイトでは、URLの構造は「http://xxx/コントローラ/アクション/パラメータ」となっていることが多い。ユーザーを削除する場合であれば、「http://xxx/user/delete/1」という形式です。
感のいい人なら気が付くと思いますが、一番後ろに突いているのは削除対象のユーザーIDです。そして、少し好奇心の強い人なら1を2に変えた「http://xxx/user/delete/2」というURLをブラウザに打ち込んで表示させてみたいという欲が出るかもしれません。そして実際にこのURLをブラウザに打ち込んだ場合、そのウェブサイトがCSRF対策を行っていなければ本当にIDの2のユーザーを削除できてしまう事になります。運営元にとって管理者でもない一般ユーザーに他のユーザー情報を削除されてしまってはたまりません。運営元のサポートセンターは「アカウントがしらないうちに削除されていた」という、不可解な不具合への問い合わせに追われる羽目になるでしょう。
CSRF脆弱性へのワードプレスでの対策
対処法としては、ユーザーのセッションをきちんとチェックすることです。つまり、正規のユーザーが正しい手順(きちんとサービスへログインして)で行った操作かどうかをチェックする必要があります。ワードプレスの場合はwp_nonce()や wp_nonce_field()などを適切に使ってセッションをチェックすればいいのです。
長くなってきたので続きは次回にします。
執筆者:カニ
我が家の電子レンジは専用のトースターよりもきれいに食パンを焼くことができる優秀な奴です。
もうすぐ10年目を迎えます。そろそろ掃除をするべきでしょうか。
この記事へのコメントはありません。