アプリケーションエンジニアのためのセキュリティことはじめ

#はじめに
上司：「社内で簡単なセキュリティテストできるようにしたいから、オープンソース系の脆弱性検知ツール使えるようになってね。OwaspZapとか」
私　：「おわすぷ…なにそれおいしいの？」

そんな一幕から今年、セキュリティのお勉強を始めたエンジニア4年生です。
セキュリティ分野のバックグラウンドのないアプリケーションエンジニアが理解しやすい（と私が思う）お勉強の始め方について書きます。

#セキュリティを勉強しはじめて本当によかった
今年ちょっとした品質管理的なお仕事を担当したことをきっかけに、セキュリティの勉強を始めました。
セキュリティ、といっても本当に基礎的な部分をなめただけですが、目から鱗だったことがたくさんあって、 「これまで知らずに書いてた自分のコードが怖い！」 と、頭を抱えたくなったことも多数。

少しでも知識がつくと実際のプログラミングや設計に影響があることはもちろん、緊急の不具合調査や障害対応でも「アタリがつく」こともありました。
セキュリティ知識は成果物の品質向上だけでなく、自分の身を助けます。セキュリティを勉強しはじめて本当によかったです。

#「はじめの一歩」で困ったこと
ですが最初の頃はセキュリティのセの字から正直よくわからなくて、
本や勉強会を探してみても、情シスの人向けの製品紹介やセキュリティテストの専門家みたいな人向けのハイレベルな情報ばかり目に入って、 求める情報源になかなか辿り着けないことが悩みの種でした。

なので今回は、今年一年ちまちまとWebアプリケーションのセキュリティについてお勉強してきた内容のアウトプットをかねて、セキュリティ分野のバックグラウンドのないアプリケーションエンジニアが理解しやすい（…と私が思った）お勉強の始め方についてご紹介します。

「セキュリティとかハードル高いな……でも、今よりもっといいコード・いい設計を書きたい！」
と思っている方はぜひ、読み進めてみてください！

##dots.女子部 Advent Calendar 2016
このカレンダーは dots.女子部 Advent Calendar 2016 3日前の記事です。
他の方の記事はこちらから。
http://qiita.com/advent-calendar/2016/dots_girls

#1.そもそも脆弱性について知る
脆弱性を抱えたプログラムを生み出さないためには、

• 世の中でいまどんな脆弱性が認知されていて、
• それぞれの脆弱性をどうすると悪用できてしまって、
• 悪用されるとどんな影響を受けるのか

を知ることが大事。

Webアプリケーションで問題になる代表的な脆弱性をまとめた「OWASP TOP 10」やIPA発行の「 安全なウェブサイトの作り方」を読むと、アプリケーションエンジニアが注意すべきセキュリティの概観を理解することができます。

・OWASP TOP 10
https://www.owasp.org/images/a/a8/OWASPTop10ProactiveControls2016-Japanese.pdf

・安全なウェブサイトの作り方
https://www.ipa.go.jp/security/vuln/websecurity.html

敵を知れば百戦危うからず。試験勉強のごとく丸暗記する必要はありませんが、まずは名前だけでも知っておくといいでしょう。

#2.脆弱性が生まれる原理を知る
「セキュリティ、大事だよね。脆弱性を生まないように気を付けよう」
…と思っても、具体的に どういうコードが、設計が、脆弱性を生んでしまうのか を知らずにセキュアなコードを書くことはできません。

バグを生むのも生み出す前に葬り去るのもエンジニア。同じように、脆弱性を生んでしまうのもセキュアなコードを書くのもまたエンジニアです。

• 「SQLはプレースホルダ―を使え」というのはよく聞くけれど、なぜプレースホルダーを使うとSQLインジェクションを防げるのか？
• 「<、>、/」のようなHTMLタグに使われる文字をエスケープするコードを見たことあるけれど、ヤマカッコやスラッシュをエスケープしないと一体どういうことになるのか？

上で参照している「OWASP TOP 10」、「安全なウェブサイトの作り方」の中でも言及されていますが、わからない部分があればググればどうにかなりました。

・クロスサイトスクリプティング対策 ホンキのキホン ―― CodeZine
https://codezine.jp/article/detail/9149

・クロスサイト・リクエストフォージェリ(CSRF)と対策 ―― Webセキュリティの小部屋
https://www.websec-room.com/2013/03/05/415

こういう単純で根本的な疑問を解消して、自分が書く設計・コードとアプリケーションのセキュリティを紐づけて理解できるようになってからは、セキュリティに関するインプットが一気に楽しくなりました。

#3.脆弱性を再現させる
理解したら実践しましょう。壊しても大丈夫な環境(ローカルの開発環境など)は手元にありますか？

コードもコマンドも知ってるだけでは片手落ち。技術を身につけるには書いて実践することが一番です。

こういう単純な操作をするだけで、手元のアプリの脆弱性を炙り出すことができます。

• 入力フォームに<script>alert(document.cookie)</script>と入力して送信
• ブラウザのURLからGETパラメータを書き換えてリクエスト送信
• 登録ボタンや更新ボタンを二度押し
• 入力フォームの確認画面でブラウザからHTMLを書き換えて送信

作業自体はとても単純。これが脆弱性試験の初歩の初歩です。
IPAの言葉を借りると、「ウェブ健康診断」と言うべきでしょうか。

・「ウェブ健康診断仕様」（「安全なウェブサイトの作り方」別冊）
https://www.ipa.go.jp/files/000017319.pdf

ちなみに、HTMLの改ざんとかよくわからない…という方はブラウザの開発者ツールを使いましょう。

・初心者がブラウザーでデバッグするための基礎知識
http://www.atmarkit.co.jp/ait/articles/1407/11/news031.html

##砂場環境を作る
手元にいじれる環境がない場合は、超単純なアプリケーションを作りましょう。
フォームの入力、確認、完了画面だけのシンプルなアプリをEclipse上でローカルホストで動かすだけで十分です。

ちなみに脆弱性試験の練習用にはフレームワークを利用せずに生の言語を使うことをおすすめします。フレームワークは開発者が意識せずとも脆弱性を作り込まないように、内部でよしなにやってくれていることが多いので。

##セキュリティ勉強用の環境を手に入れる
実は車輪の再発明をする必要はありません。
脆弱性を盛り込んだセキュリティ学習用のサイトがオープンソースで配布されています。

・OWASP BWA (The Broken Web Applications) とは？
https://www.pupha.net/archives/827/

・VirtualBoxでわざと脆弱性を持たせたサーバの作り方　～やられサイト構築～
http://aiaru.hatenablog.com/entry/2015/03/20/223442

Owasp BWAはイメージファイルが配布されているので、手元のVirtualBoxに登録するだけで、意図的に脆弱性が埋め込まれたテストサイトを砂場に遊ぶことができます。

#4.脆弱性検知ツールを使ってみる
ここまで抑えたら、いよいよツールをさわってみましょう。

・OWASP Zed Attack Proxy Project
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

オープンソースの脆弱性診断ツールはいくつかありますが、アプリケーションレイヤーの技術者にはOwaspZapがおすすめです。その理由は、OwaspZapが アプリケーション開発者が自分たちでアプリの脆弱性検査ができる ことをコンセプトに作られたツールだから。
他のツールを使ったことないからわかりませんが、操作は比較的簡単とのこと。セキュリティの専門知識がなくても、リクエスト・レスポンスの概念など、最低限のWebの知識があれば扱うことができます。

立ち上げたらとりあえずURLを指定するだけで、脆弱性を炙り出すためのパラメータを含んだ大量のリクエストを対象のドメインに投げつけます。Let's ZAP!!

はい、これほんとただの攻撃ですね。ローカルのサーバ以外にうっかりかけちゃうと、とんでもない迷惑行為(不正アクセス禁止法違反？)です。おかしなデータが登録されることでアプリが壊れ、立ち上がらなくなることもあります。用法を守って正しく扱いましょう。

一度送ったリクエストを再送したり、一部改変して送りつけたり、ファズとよばれる大量の脆弱性検知用のパラメータをピンポイントに送りつけたりと、色々できます。やり放題です。砂場であそびつくしましょう。

脆弱性の原理を知り、攻撃者の視点をほんのさわりでも得られたことは、セキュアなシステムをつくる第一歩です。昨日よりも安全なシステムをつくりましょう！

以上。
dots.女子部 Advent Calendar 2016 3日目
「アプリエンジニアのためのセキュリティことはじめ」 でした！