2019-08-29

バグハンターmageに聞くバグハンティングの方法とセキュアなサービス作りに必要なこと

バグハンターとは、Webサービスやソフトウェアなどに含まれる脆弱性を、システム改善のために探し出す人々です。バグハントの方法は非常に多岐にわたりますが、具体的な手法、使用ツール、ハントのマナーを凄腕のバグハンターに聞きました。mageの名で知られる馬場将次さんが語り下ろす実践的なノウハウは、サービスをセキュアなものにしたいエンジニアのみなさんにとっても重要な知見になるでしょう。

バグハンティングを犯罪にしないために必ず知っておきたいこと
馬場流バグハント手法「調査」「解析」「実証」。そして「普通はやらない」を無数に試す
防御のために、言語やフレームワークの実装を学ぼう。コード読解から、違和感を見つけ出す方法を実践してみる
XSSの現在。技術の進化と並走する攻撃手法の進化
セキュリティを理解するためにまずはトライしてみる

なんらかのサービスの脆弱性を探り出し、サービス運用主に報告する。ときに、発見の対価として報酬を獲得するバグハンティングというカルチャーがあります。セキュリティへの意識は高まり続ける中、脆弱性発見を“組織の外にある目”であるバグハンターを頼りにする事例が生まれつつあります。

システムやソフトウェアが抱える脆弱性やセキュリティ施策に精通したバグハンターたちは、様々な手段を使い、思いもよらない脆弱性を見つけ出します。ならば、その手段はサービス運用にあたるエンジニアにとって有効な防御策として活用できるはずです。本稿では、バグハンターとして膨大な脆弱性発見実績を持つ馬場将次（ばば・しょうじ／ @mage_1868 ）さんに、脆弱性を発見する手順やコツをお聞きしました。

馬場将次さん: 専門学校を卒業後、印刷会社に入社しIT部門で研究開発を担当。自身が作ったWebサイトが攻撃を受けたことがきっかけとなり、セキュリティや脆弱性に関心を持つ。2013年にセキュリティ競技大会に参加し、本格的にバグハンターとして活動を開始した。その後、株式会社神戸デジタル・ラボに入社し業務としてセキュリティに携わるように。現在はセキュリティ診断・検査専門企業であるイエラエセキュリティに在籍する。世界的なCTF（Capture The Flag）競技会「DEF CON CTF」の常連チーム「binja」に所属し活動を続けている。

バグハンティングを犯罪にしないために必ず知っておきたいこと

──まず、バグを探すという行為の前提をお聞きします。好き勝手にバグ探しをすることは、ときとして犯罪と同一行為にも感じられます。バグハントにおける「犯罪」と「調査」の境界はあるのでしょうか。

馬場　個人で「犯罪」と「調査」を線引きするのは非常に困難です。そのため、好き勝手にWebサイトの脆弱性を探すのは避けるべきです。今はバグハントを支援するWebサイトがあるので、そこを利用するべきでしょう。例えば、HackerOneというサイトは、脆弱性を探してほしい企業とバグハンターのマッチングサイトとしての機能を持っています。実際にHackerOne内を探ってみれば、Twitterなどの大手企業が依頼を出しているのが確認できるでしょう。

また、HackerOneでは企業とバグハンターの脆弱性報告のやりとりが公開されています。さまざまな報告を読むのは非常に勉強になります。バグの種類や発見方法も分かりますし、バグ報告の書き方も参考になります。バグハントに興味がある人は、まずこういった報告を読んでみることをおすすめします。

──バグハント / バグバウンティにはHackerOneのようなサービスが欠かせない、と。

馬場　企業とバグハンターの間にHackerOneのようなバグバウンティのプラットフォームが存在することで、企業の「バグを探してください」という意思が明確になりますし、バグ探しのルールや報酬金額も提示されています。ルールを守る限り、問題になることはまずないでしょう。近年、バグバウンティに関するWebサイトが増えたことで、企業側の理解度も上がってきた印象があります。検証環境を用意してくれる企業も以前より増えてきていますので、バグハンター、企業の両者が安心してバグハントができるようになってきています。

バグバウンティに積極的に取り組んでいるのは、サイボウズ社です。サイボウズ社は先に挙げたバグバウンティのプラットフォームを使わず、独自にバグハンターと直接やり取りしています。こうした取り組みはもっと評価されていいと思いますね。

──企業とルールをきっちり決めておけば安心してバグハントができそうですね。

馬場　それでも、企業とバグハンターのコミュニケーションは慎重に行うべきです。企業側はバグハントを受け入れた結果、生じるリスクを把握しきれていない場合もあります。調査目的で本番環境へのハッキングを依頼されるケースもあるのですが、意図せず機密情報データを取得してしまい、バグハンターは不正アクセスの罪に問われるリスクも想定されます。もちろん、企業にとっては情報漏えいリスクです。

また、バグハンターは調査目的でのハッキング行為による副作用や、意図とは異なるシステムへの影響を理解しておくべきです。ある調査のためにSQLインジェクションを試したところ、本番環境の全ユーザのパスワードが初期化された、という例も聞きます。

パスワードリマインダ機能に対してSQLインジェクションの試行が原因で、データ破壊が起きてしまったのです。認証周りの脆弱性調査がデータ破壊に繋がると想定できていなかったことに起因します。

SQLインジェクションとは？

外部から入力された値をSQLとして組み立てるプログラムに対して、悪意のあるSQL文を入力してデータの破壊や機密情報の取得を行う手法。以下の例では上段のコードに「--」を加えることによって「AND password」という条件をコメントアウトして無効化している。さらに「OR 1=1」という条件の追加によってどんな条件がついていても「すべて真になる」という結果になってしまう。

SELECT * FROM users WHERE name='名前' AND password='パスワード'

SELECT * FROM users WHERE name='' OR 1=1--' AND password='パスワード'

馬場　あるWebサイトがどのようなソースコードで動作していて、裏側でどんなSQLが組まれているのかはバグハンターは見ることができません。実装が分からないものに対して、攻撃のリクエストを安易に送るようなことはしてはなりません。

例示のようにどんな副作用が起き、データ破壊につながるか見通しがききませんから。ともすれば訴訟につながることもあるので、バグハンティングの手法だけを知り、安易に試すと大きなリスクを負ってしまう可能性があることは、強く認識するべきです。

──調査行為と犯罪行為の境界、またリスクに関してはどのように勉強すればいいでしょうか。

馬場　経験を積むしかない、というのが正直なところですが、まずはガイドラインを読むことをおすすめします。ガイドラインはいくつかあり、どれが最も影響力を持つかには議論があり決められませんが、以下のIPAの資料は一度目を通しておくといいでしょう。

情報セキュリティ早期警戒パートナーシップガイドライン（PDF）

例えばガイドラインには「不正アクセス禁止法に抵触しないと推察される行為の例」として以下のような文言があります。

アクセス制御による制限を免れる目的ではなく、通常の自由なページ閲覧を目的として、日付やページ番号等を表すと推察される URL 中の数字列を、別の数字に差し替えてアクセスしてみたところ、社会通念上、本来は利用できてはならないはずと推定される結果が、偶発的に起きてしまった場合。（ただし、積極的に多数の数字列を変えて試す行為等は、制限を免れる目的とみなされる可能性があります。）
『情報セキュリティ早期警戒パートナーシップガイドライン2019年版』より抜粋。

つまり、URLのパスを /2019/04/01 から /2999/94/34 という風に変更してバグを引き起こしたとしても、不正アクセス禁止法には抵触しないと“推察される”と。このように、ガイドラインを読めば、意図せぬ犯罪行為を防ぐための、一つの指標にはなります。しかし、“推察される”の記述の通り、ガイドラインは絶対のものではないことは強調しておきたいところです。

──バグバウンティのルールを統一して定めることはできないのでしょうか。

馬場　それは難しいでしょう。企業によってセキュリティに対するルールや考え方も違いますし、バグには無数のパターンがあるからです。

明確なルールがないからこそ、バグハントを行うときは企業とのコミュニケーションが大切です。企業とのコンセンサスなしにバグハントを始めてしまうと、ただの攻撃者として見られてしまうこともあります。バグハントと犯罪行為の境界を設定するのは非常に困難であることは、まず認識しておくべきですね。

馬場流バグハント手法「調査」「解析」「実証」。そして「普通はやらない」を無数に試す

──馬場さんは普段どのような手順でバグハントを行っているのでしょうか。

馬場　私の場合、基本的には「調査」「解析」「実証」という流れでバグハンティングを行います。聞いたら拍子抜けするかもしれませんが、実はバグハントはエンジニアなら誰でもできるような簡単なことから行っています。

まず「調査」ですが、Webサービスの場合はHTTPのレスポンスやリクエストを観察します。プログラミング言語やフレームワークにはクセのようなものがあって、レスポンスやリクエストを見ればある程度は特定することができます。

例えばURLのパラメータが ?name=value という値だったとします。パラメータを書き換えて ?name[]=value としたときに、 value を適当な値に書き換えた場合と異なるレスポンスが返ってくれば「このサービスの使用言語はPHPかもしれないな」と、あたりをつけることができます。

また、例外が発生するようにパラメータを書き換えたり、通常ではありえないリクエストを送ったときにフレームワーク固有のエラーメッセージがそのまま返ってくることもあります。そうなれば一発でフレームワークを特定できるので、少し作業が楽になりますね。言語固有のレスポンスやリクエストのクセなどは開発するときに使わない知識かもしれませんが、バグハンターにとっては最高の手がかりです。

言語やフレームワークが分かり、それらがOSSならばソースコードが公開されているので、それを隅々まで読み解く努力をすれば、バグを見つけられるかもしれません。バグを見つけるチャンスは誰にだってあるのです。

──バグハントでよく使うツールはありますか。

馬場　Burpなどのローカルプロキシツールを使います。こうしたツールを使えば、誰でも容易にリクエスト内容を変更でき、調査はできます。しかし、闇雲にリクエストを送っているだけでは何も分かりません。言語やフレームワークの知識を網羅的に持ち、初めて「脆弱性を見つけるためのリクエスト」の傾向が見えてきます。バグをつかむためには経験や知識が大事なのです。

ローカルプロキシツールのBurpを使うとレスポンスやリクエストをローカルコンピュータ上でキャプチャでき、リクエストを自由に書き換えることができる。

馬場　もうひとつ、HTTPのプロトコルが理解できていれば、そこから脆弱性を探ることもできます。例えばファイルアクセスをするリクエストを書き換えることで、本来見えてはいけないファイルにアクセスできてしまうケースがあります。ディレクトリトラバーサルという定番の攻撃手法ですね。

ディレクトリトラバーサルは一般的なセキュリティの教本にも載っていますが、実際に試したことはない、という方もいるでしょう。バグハンターの本質とは、こうした「普通はやらないこと」を実際に試してみることにあると考えています。

「User agentを変えてみたらどうなるのか？」「HTTPのリクエストヘッダを追加してみたら、どうなるだろうか？」など、試すべき「普通はやらないこと」は山ほどあります。そして試行してみて、おかしなレスポンスが返ってくればこちらのものです。

上のキャプチャは単純な例であるが「リクエストのURLパスを変更してサーバのホスト名が保存されているファイルにアクセスできるかどうか試してみる」など、HTTPを理解していると調査できることも増えてくる。

──バグハントは地道な作業の連続なのですね。

馬場　Burpのスキャン機能等を利用できればもっと調査がしやすいのですが、多くの場合はサーバに負荷がかかるような脆弱性スキャンツールの使用は禁止されています。

Webサイトのソースコードや構成が見えないときは、地道に一つずつ持っている知識を試してあたりをつけていくしかありません。たどり着くまでにリクエストを何百パターンか試すこともあります。

──ツールを使わずブラウザから脆弱性を調査することもあるかと思いますが、こういった場合がどのようなアプローチをとるのでしょうか。

馬場　ここでも大事になってくるのは、「普通はやらない」を試すことです。ECサイトを調査するときを例にして考えてみましょう。ECサイトには商品の購入や決済が必ずあります。

商品を選ぶ
個数を入力する
購入する

これが通常の大まかなフローだと思います。ここで、例えば「購入数をマイナスにしてみる」という「普通はやらない入力」をすることがバグ調査の基本になります。

また、UIのインタフェースを注意深く見るのも重要です。あえて入力制限を強くしているような部分はバグが発生しやすいから塞いでいるとも考えられます。

──そうやって「調査」で得たものをどのように「解析」していくのでしょうか。

馬場　解析は調査と重なる部分が大きいのですが、フレームワークや言語が分かればソースコードを読むだけで脆弱性に繋がる挙動の見当がつきます。他にもHTTPレスポンスを見て分かったことを解析し、得られた情報によって様々なアプローチを取っていきます。解析では引き出しが多ければ多いほど有利になるので、初心者と経験者の差は「解析」で顕著に現れるかもしれません。

解析の結果、使っているアプリケーションやツールが分かれば過去に発見された脆弱性を試すこともできます。例えば画像のリサイズのためにサーバでImageMagickを使っていることが調査で分かったとします。ImageMagickには、過去「特定の画像フォーマットでOSコマンドを含ませたファイルを処理させることによって、そのコマンドを強制的に実行させることができる」という危険な脆弱性がありました。

この脆弱性を試しに使ってみるだけでもサーバのImageMagickのバージョンの見当がつきます。また、どの程度セキュリティ対策をしているのかもレスポンスによって分かってきます。使っているアプリケーションやツールのバージョンに関する情報も、バグハンターにとっては重要なヒントになるのです。

──バージョンアップは疎かになりがちなので、非常に身が引き締まる思いです。

馬場　油断した部分から脆弱性というのは生まれます。ツールやライブラリの過去の脆弱性は検索すれば多数出てきますし、仮にモダンな技術を取り入れていたとしても、古いコードが残っているとそこを攻められてしまう。いわゆる「秘伝のタレコード」なども危ういんです。

──「調査」「解析」に続く、「実証」とはどのような作業なのでしょうか。

馬場　「調査」「解析」はバグを探す作業ですが、「実証」はサービスの運用主に向けた作業です。報告をする企業に見つけた脆弱性がどれほど危険で、どんな驚異があるのかを理解してもらわなければなりません。

口頭の説明や資料だけではたいてい理解してもらえないので、バグハンティングのルールを逸脱しない範囲で攻撃コードをこちらで作り、実践して説明します。バグは再現性があって初めて信じてもらえることが多いので。

防御のために、言語やフレームワークの実装を学ぼう。コード読解から、違和感を見つけ出す方法を実践してみる

──先ほど「ソースコードを読むことがヒントになる」と教えていただきました。しかし、言語もフレームワークも常に進化していて堅牢さも増していると思いますが、バグハンターから見ると違うのでしょうか。

馬場　私の考えでは、フレームワークで作られたWebサイトは逆に脆弱性が見つけやすいです。バグハントはソースコードが公開されていない状態で行うことの方が多いため、OSSの公開されているソースコードは大きなヒントになります。

フレームワークの膨大なソースコードを読むのは大変ですが、読んで理解さえすれば挙動が分かります。そのため私たちの中ではOSSを読んで脆弱性を探すような、運に左右されず、努力すれば成果が出るバグハントを「やるだけ」と呼んでいます（笑）。

フレームワークは確かに堅牢になってきていますが、人間はミスをする生き物です。いくら優れたシステムであったとしても、どこかに必ずバグは発生してしまいます。だからこそ開発者はフレームワークの中の実装を理解することが大切なんです。実装を理解してない状態というのは、自分で作ったWebサイトなのにブラックボックスになっているということと同じです。セキュリティの観点では危険な状態です。

単純な例で言えばRuby on RailsのModelの挙動などもそうです。RailsのModelはデフォルトでは、すべてのカラムをDBから取得してきます。それをそのままフロント側に送ってしまうと、レスポンスを見られたときにデータがすべて見えてしまいます。

また、フロントエンドのフレームワークにも同じことが言えます。JavaScriptのフレームワークでも抜け道のような脆弱性が発見されています。少し古い話題ですがAngularJSにはテンプレートインジェクションというXSSの脆弱性がありました。英語ですが、こちらの記事に丁寧にまとめられています。

XSS（クロスサイトスクリプティング）

ユーザがなんらかのWebサイトにアクセスしたときなどに、悪意のあるスクリプトを実行されてしまう脆弱性。「Twitterなどで悪意のあるURLをシェアし、クリックした相手のCookie値を盗む」などもXSS攻撃に分類される。

馬場　HTMLを動的に出力する際は、エスケープ処理をしていれば大丈夫という認識が一般的だと思います。従来のHTMLならば、タグには <> 記号などしか使われていなかったため単純なエスケープで防げていました。しかし、以下のコードを見てください。

<html ng-app>
<head>
<script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.4.7/angular.js"></script>
</head>
<body>
<p>
<?php
$q = $_GET['q'];
echo htmlspecialchars($q,ENT_QUOTES);?>
</p>   
</body>
</html>

{{constructor.constructor('alert(1)')()}}

上記コードはPortSwigger Web Security Blogより引用。

馬場　上段の echo htmlspecialchars($q,ENT_QUOTES);?> の部分に任意のユーザ入力値がHTMLエスケープされた状態で挿入されます。 htmlspecialchars のエスケープ処理は従前では <> だけでよかったのですが、 AngularJSの場合、ng-app属性を持つHTML要素内に {} を使用してコードを記述可能です。この {} に任意のJavaScriptのコードを挿入することが過去のバージョンではできていたのです。現在のバージョンではAngularJSのサンドボックス機能の強化によって簡単なJavaScriptのコードは実行できないようになっているのですが、下段のように constructor オブジェクト内のFunction オブジェクトを用いると、ユーザが入力したJavaScriptが簡単に実行できてしまうのです。

テンプレートインジェクションはJavaScriptフレームワークが一般化したからこそ出現した手法です。フレームワークを使うと安全 / 危険ということではなく、フレームワークの中身を読み実装を学ぶことが重要なのです。実装が見えないから防御策を講じにくくなってしまう。開発者はフレームワークを使うのであって、フレームワークに使われている状態にならないようにするのが大事だと思います。

──ソースコードを読んで脆弱性を見つけるコツなどはあるのでしょうか。

馬場　これに関してはフィーリングが大きいですね……。例えば文章を読んでいるときに誤字脱字があると違和感を覚えることがあるでしょう。同じように、ソースコードを読むための特殊な方法があるわけじゃなく、ひたすらコードを読んで見ていくだけです。

ただそれだとあまりにも抽象的なので、脆弱性のあるコードの具体例を出しましょう。以下は「ユーザがアップロードしたファイルを保存し、とある外部コマンドでそれを処理する」というflaskフレームワークを利用したPythonの疑似コードです。どこに脆弱性があるか、考えてみてください。

import flask, subprocess
...
file = flask.request.files['file']
filename = file.filename
file.save(filename)
...
subprocess.call('/path/to/command ' + filename. shell=True)

馬場　まず目立つところからいきましょう。最後の行で、外部からの入力値をOSコマンドに含めて実行している箇所はかなり危険です。

アップロードしたファイル名にLinuxのシェルコマンドの区切り文字である ; を使用することで、後続に好きなコマンドを指定し実行することができてしまいます。OSコマンドインジェクションという手法です。かなり極端な例示なので、さすがに現実にはありえないだろ、と言いたくなりますが（笑）。

2つ目はファイルを保存している処理で、Pythonの仕様を突いた攻撃が可能だと考えられます。Python2¹はプログラム実行の際、処理速度を上げるため一度インポートされたモジュールは モジュール名.pyc というコンパイル済みの中間ファイルが生成され、次回実行時はその中間ファイルが読み込まれます。この言語仕様を理解していると、上記のコードから「flask.pycというファイルをアップロードしたらどうなるだろう」と発想できます。

上記2つの例は入力値やファイルチェックのバリデーションを入れておけば防げるかもしれない単純なもので、コードをよく読めば防ぐことができます。

OSコマンドインジェクション

メールアドレス記入欄などのように、ユーザが任意で入力ができる箇所に、プラグラム上でOSコマンドを実行させるような値を入力する攻撃。OSのコマンドが強制的に実行されてしまうため、非常に大きなリスクとなる。

──言語仕様を理解していると脆弱性を見つけるための視野が広くなりそうですね。

馬場　そのとおりです。バグを見つける上でも言語仕様の理解は重要です。DBに保存するときにIDを言語側で発行しているユーザテーブルがあったとします。開発者は標準関数を使って乱数でIDを発行していたため、安全だと考えるでしょう。しかし、この標準関数の内部実装の乱数生成が、推測可能であることを知る攻撃者からすると、「開発者は推測できないと思い込んでいるID値」をある程度は推測できてしまう可能性があるのです。

──仕様の理解がいかに重要か分かります。では、バグハンターの視点から、開発者がコードを書くときにセキュリティレベルを高く保つためには、どのような点に配慮するべきだと思いますか。

馬場　ルールを決めてセキュアコーディングをしていくのがひとつの方法でしょう。ただし、ルールでガチガチにしなければならないので、開発者の自由度が低下してしまう側面もあります。要件と実装のせめぎあいが生じ、開発期間が長くなってしまう場合もあるでしょう。これは非常に判断が難しい問題で、企業の文化や開発人員の数にも左右されます。最適解というのはなかなかないかもしれません。

XSSの現在。技術の進化と並走する攻撃手法の進化

──XSSは古典的な攻撃手法ですが、進化しているのでしょうか。

馬場　ブラウザも進化しているので単純なXSSは防げるようになりました。しかし逆にブラウザからカメラにアクセスできたり、録音できたり、会話型のインターフェイスがあったりと多機能になったことで、攻撃手法も増えました。

例えば、とあるCTFでWeb Speech APIを利用し、ブラウザから録音した音声を共有できるWebサービスに、XSSの脆弱性が存在する、という問題が出題されたのです。

FLAGを所持している攻撃対象のユーザ環境ではスマートスピーカーが動いていて、このユーザに対して「OK google what is the flag」という音声を送り、スマートスピーカーによって読み上げられたFLAGを、XSSを利用してWebサービスから録音させて奪取する、というものでした。CTFのお題とはいえ、昔では考えられない攻撃手法ですね。

また、XSSとは異なりますが、クロスサイトサーチという手法も存在します。公開、非公開が区別されている掲示板のようなサイトで、検索機能を利用して非公開のテキストを引き出される攻撃手法で、検索実行時のレスポンスの差分を悪用したものです。

なんらかのサイトで検索をした際、「1件もヒットしない場合」と、「1件以上のヒットがある場合」のレスポンスが異なる場合があります。さらに、1件もヒットがないにも関わらず、レスポンスに差異がある場合があるのです。これが非公開の文章がシステム内部で検索に引っ掛かった際のレスポンスだと見当がついてしまい、非公開の文章が解析されてしまうリスクが生じます。

── 進化という面では、近年、クラウドサーバも一般化してきました。クラウドサーバだからこそ内包する脆弱性などはありますか。

馬場　自社で管理していないからこそ、配慮すべき部分はあります。例えば、SSRF（Server Side Request Forgery）はクラウドサービスが一般化したことにより、脅威を増した攻撃手法だと言えます。

AWSのEC2では http://169.254.169.254/ にアクセスするとそのインスタンスの情報が取得できるという仕様があります。この仕様を悪用し、EC2上のサーバから任意のリクエストが送信でき、そのレスポンスを観測できる場合、クレデンシャル情報を奪われてしまう恐れがあります。

この脆弱性は本来、アクセス制御をしておくことで防げます。しかし、そもそもエンドポイントがあること自体を知らないユーザもいるため、セキュリティ施策に抜け漏れが発生してしまうのです。これが仮に自社サーバであり、仕様が把握しやすい状況であれば起きなかったかもしれません。

──「自社サーバとクラウドサーバのどちらがセキュアか？」というのはよく議論されます。バグハンターの視点ではどうでしょうか。

馬場　どちらとも言えません。状況に応じて使い分けるべきでしょう。クラウドならば物理的な攻撃を受けるリスクも低い。しかし、自社以外の企業や人員が巨大な権限を持っているという状態を、リスクのひとつと解釈できます。もっとも、これはクラウドサービスに限った話ではありませんが……。一方で、自社サーバならば権限は原則的に社内ですべて管理されているはずで、そこはセキュリティ上の強みです。

セキュリティを理解するためにまずはトライしてみる

── 開発者がWebサイトを作る際にキュリティ面で確認しておくべき点などはありますか。

馬場　「これを守れば大丈夫！」と断言はできませんが、IPAのガイドラインは参考になると思います。ガイドラインにあるセキュリティ項目を理解して、リリース前にチェックするだけでも効果的です。IPAのチェックリストは以下の『セキュリティ実装チェックリスト』を参照してみてください。

あとはバグハンターのように脆弱性を探すことに時間をかけられないなら、セキュリティツールを使うのもいいかもしれません。有料ですがBurpのPro版に備わっているスキャナー機能のような脆弱性診断ツールを利用すれば、ブラックボックスなWebサイトでもクローリングして自動で診断してくれます。

XSSやディレクトリトラバーサルなどの基本的な攻撃手法への対応状況も確認できるので、セキュリティの知識に自信がなくても、ある程度の脆弱性はあぶりだすことができます。

──開発でのリソースが少なく納期がギリギリ、という状態もあると思います。最低限これはやっておくべきセキュリティ施策はありますか。

馬場　「これだけ！」と絞ることはできません。全部気にしてほしいです。注意点を絞って説明しても、それらには必ず抜け道が存在してしまうのが実際です。

ただ、どうしても時間がない、という状況であればWAF（Web Application Firewall）を使うのはありだと思います。ある程度の予算はかかってしまいますが、Webサイトと利用者間の通信をWAFがチェックしてくれるので、攻撃コードがあれば防いでくれます。自作も可能ですが、今はAWS WAFなどもあり、比較的手軽に導入できるでしょう。

──開発においてセキュリティは後回しにされてしまう場合もあるでしょう。馬場さんから見てこうした状況をどう感じますか。

馬場　バグハンターの立場でなくとも、危険だと言わざるをえません。一番多い脆弱性は「人間のミス」だと考えています。ミスを防ぐためには相応の時間を割くしかなく、怠ると攻撃者にすぐに脆弱性を突かれてしまいます。

ただ、いきなりセキュリティを徹底するのは難しいでしょう。大きなチームならばなおのことです。ですから、まず大事にしてもらいたいのは、「こういう攻撃があるから、防御策を試してみよう」というトライアルのマインドです。本を読んだり、ネットで見たりして、攻撃手法を知り、その攻撃に対する防御手法をひとつ覚えるだけでも開発の中でのセキュリティへの意識が変わると思います。

また、繰り返しになりますが、言語やフレームワークの実装を知ることが大事です。そもそも、実装に明るくなければ使いこなせませんし、ソースコードを読み込むことで、セキュリティの理解も深まります。開発に活かし、セキュリティに活かすためにソースコードはぜひ目を通してもらいたいですね。

取材：megaya　{$image_7}megayaのブログ

*1:Python3では中間ファイルの仕様が若干異なる。