PINTO!株式会社PLAN-Bの情報発信メディア

2019.06.07

大藤 裕介

Webアプリのセキュリティ初心者がまず学ぶべき勘所! セキュリティ勉強会を主催して見つけた3つのポイント

WRITER

大藤 裕介

株式会社PLAN-B システム開発本部

2017年5月中途入社。社内のSEO関連プロダクトの開発を担当した後、新規事業のMVP開発に主担当で参画。AWSでのサーバーレスアーキテクチャや、社内プロダクトのマイクロサービス化を進める。クリーンアーキテクチャとDDDが気になる本格的牡蠣好き。

目次
    1. はじめに
    2. 勘所、の前に
    3. テキストで学んだセキュリティ知識をテストでチェック
    4. 勘所をご紹介!
      1. HTTP
      2. セッション/cookie
    5. 攻撃手法の区別
    6. まとめ

はじめに

他者とのコミュニケーション、買い物、エンターテイメント、日々の生活はインターネットなしには考えられないものとなりました。その反面、個人情報の流出やフィッシング詐欺などのWebサイトのセキュリティに関する事件・事故が多発しています。Webサービスの開発業務を日々行っているPLAN-Bのエンジニアもこのような事件・事故と無縁ではいられません。このためPLAN-Bでは全エンジニアを対象にWebセキュリティ知識のテストを行っています。

私もこのテストに合格するために勉強し、またセキュリティ勉強会を主催して全員がセキュリティテストに合格するよう活動してきました。その中で、Webセキュリティを学び始めた人が

  • 学習を進める上でおさえるべきこと
  • 学んでおくことで学習がスムーズになること

というところがわかってきました。

今回はテスト対策を行う中で考えに至った「Webセキュリティ初心者が学ぶべき勘所」を紹介したいと思います。Webサイトのセキュリティを学び始めたエンジニアの方や、社内エンジニアのセキュリティスキルを強化したい方は参考にしてみてください。

勘所、の前に

勘所を紹介する前に、PLAN-BではどのようにWebサイトのセキュリティを学習しているかを紹介します。
共通の学習用テキストを決めた
めいめいが闇雲にセキュリティ知識を学んでも開発チーム内で知識レベルに差が出てしまったり、網羅的な知識習得が難しくなります。
このため、PLAN-Bでは学習用テキストおよびテストの出題範囲としてIPAが発行している「安全なウェブサイトの作り方」改定第七版を利用し、知識の均一化を図っています。

テキストで学んだセキュリティ知識をテストでチェック

テキストを読むだけでは学習したことが身についたのか確認が行えません。このためPLAN-Bでは学習内容をチェックするため、セキュリティテストを実施しています。

例えば、次のような問題です。

●問題:XSSの対策について、「HTMLテキストの入力を許可しない場合の対策」および、「全てのウェブアプリケーションに共通の対策」の中で根本的解決として正しいものを選べ。(複数回答可)

A:入力されたHTMLテキストから、スクリプトに該当する文字列を排除する。
B:入力値の内容をチェックする。
C:クロスサイト・スクリプティングの潜在的な脆弱性対策として有効なブラウザの機能を有効にするレスポンスヘッダを返す。
D:URLを出力するときは、「http://」や「https://」で始まるURLのみ許可する。
E:ウェブページに出力する全ての要素に対して、エスケープ処理を施す。

答:D, E

テキスト持ち込みなし。部分点なし。過不足なく選択肢を選べていなければ正解となりません。テスト合格のボーダーラインも80%以上の正答率であること、と高めに設定しています。

エンジニア全員がこの難易度の問題に正答できる知識を備えているならば、テキストで語られる脆弱性を誤って作り込むことは無いですし、他エンジニアも同一内容の知識を勉強をしているので設計レビューやコードレビューで指摘がなされます。出題者の求めるレベルはなかなか高いですが、エンジニア全員にセキュリティ知識のベースができあがります。

勘所をご紹介!

「安全なウェブサイトの作り方」という名前の学習用テキストにしている以上、テキストを読み進めるにはWebで使用される技術知識を知っていることが求められます。逆説的にWebで使われる技術知識の不足が初心者の理解を妨げる要因です。
ご紹介する勘所は以下3点です。

  • HTTP
  • セッション/cookie
  • 攻撃手法の区別

HTTP

兎にも角にもHTTPの仕組みをおさえましょう。でなけれなWebセキュリティに対する正確な理解が困難です。

といっても、なにやら複雑な処理や手順を行っているわけではなく、HTTPという決まった手順でWebサーバと情報をやり取りしています。そして、やり取りしている情報は決して人間が読めないような代物ではありません。

例えばPLAN-BのコーポレートサイトのTOPページ https://www.plan-b.co.jp/ を表示する場合、以下のようなテキストを送信しています。

GET / HTTP/1.1
Host: www.plan-b.co.jp

このテキストは「www.plan-b.co.jpというホスト名の / が表す場所にあるリソースがほしいです、GETしたいです。」という命令を表しています。


対してWebサーバからは以下のような返答を返しています。

HTTP/1.1 200 OK
Date: Sat, 09 Mar 2019 14:40:23 GMT
~~~ (割愛) ~~~
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

<!doctype html>
<html>
~~~ (以下、コーポレートサイトTOPページのhtmlテキストが続く) ~~~

一行目で「OK」といっていますね。Webサーバは「リソースをGETしたいです」と言っていた送信者に対して求められていた場所にあるHTMLソースを送ってくれたようです。

HTTPの仕組み

送ってもらったHTMLをブラウザが読み取ることでブラウザにWebページの画面が表示されます。
検索サイトを利用して調べ物したり、ECサイトで買い物をするなどインターネットで行われる通信の多くは、例のような送信者とWebサーバがひたすらテキストベースの命令とその返答をやりとりすることで行われています。

セッション/cookie


初学者が意外と見落としがちなのが、セッションとcookieではないでしょうか。

「名前は聞いたことあるけど、何をやっているのおぼろげにしかわからない…。」
テキストを読み進んでもセッション/cookieの理解がおぼろげでは、テキストの内容が腑に落ちず理解が進みにくいですよ。

この点については、セッション/cookieがなぜ生まれたのかを知ることが大切です。

前節で解説したHTTPにはユーザの状態を記憶/管理する仕組みはありません。なぜならWebの仕組みは論文などの研究成果をリンクさせて情報検索を容易にするために生まれたものだからです。
論文を読んでもらうという目的ために、論文閲覧者の操作状況などの状態をWebサーバが知っておく必要は無いはずです。Wikipediaを閲覧するだけのために、あなたはログインを行いますか?

しかし、

  • SNSで近況を投稿するとき、あなたはSNSサイトにログインしますよね?
  • ECサイトで買い物をする場合、あなたはカートに商品をいれますし、別の商品を探してる最中に突然カートに入れた商品が消える、なんてことないですよね?

などなど、現在のWebではWebサーバ側でユーザのログイン有無や、ユーザの操作を覚えておくこと、ひっくるめてユーザの状態を覚えて管理する機会が非常に多いです。ユーザの状態を管理する仕組みがHTTPでSNSやECサイトのカート機能を実現しているのがセッション/cookieです。


ユーザがWebサイトを回遊している一連のやり取りをセッションと呼び、Webサーバはユーザごとに1つのセッションを識別するID、セッションIDを割り当てます。
ECサイトならログイン有無やカートの中身はWebサイトがセッション中のやり取りとして覚えています。
しかし、Webサイトは不特定多数の人が利用します。ユーザごとに一意なセッションIDが割り当てられていますが、誰がどのセッションIDに対応するユーザなのか名乗り出てもらわないとわかりません。つまり、ユーザが「私はこのセッションIDでWebサーバとやり取りをしています」と言ってもらわないとWebサーバはユーザを区別できません。

セッションIDだけではユーザーを区別できない


ここでcookieの出番です。cookieはWebサイトで利用される情報をユーザのWebブラウザに保存したものです。cookieはWebサイト毎にブラウザに保存され、セッションIDはこのcookieの中に保存されます。
そしてユーザがWebサイトにアクセスするときcookieに保存されている情報も一緒にWebサイトにわたします。つまり、Webサイトはユーザから「私はこのセッションIDだよ」と教えてもらっています。こうすることでWebサイトはユーザを区別することができます。

攻撃手法の区別


攻撃手法を正確に理解し、それぞれの攻撃に応じて対策することが重要です。ある攻撃手法には有効な対策が、別の攻撃手法に対しては必ずしも対策になるわけではありません。学習したWebセキュリティ知識を活かすには、攻撃手法を区別して学習することも心がけてください。

とはいえ、クロスサイトスクリプティング、クロスサイトリクエストフォージェリ、HTTPヘッダインジェクションetc.. 英語の攻撃名が並べられてどの攻撃名がどのような手法であるのか混乱しがちです。経験を積んだサーバサイドエンジニアもつまずきがちな点ですから、初心者ならいわんや。

日本語に翻訳してイメージを掴みましょう。英語の攻撃名をそのまま覚えるのではなく、日本語に読み替えて攻撃名の意味をとらえるとそれぞれの攻撃がどんなことをするのかわかりやすくなりますよ。

例えば

  • クロスサイトスクリプティング → サイトを横切った(cross site)スクリプトの実行(scripting)。
  • クロスサイトリクエストフォージェリ → サイトを横切った(cross site)リクエストの偽造(request forgery)

のように日本語に訳してみると

  • 似たような名前だけれど異なる攻撃手法であり、どのようなことを行う攻撃なのかが区別をつけられる。
  • とはいえ、どちらもサイトを横切るという意味からユーザを攻撃対象のサイトとは別の罠サイトに誘導して、罠サイトから攻撃対象サイトに対して何やら悪いことを行う。

といったことが意識できるようになりました。

まとめ

Webサイトのセキュリティを勉強する上でセキュリティ初心者が学ぶべき勘所として以下の点を紹介しました。

  • Webで使われる基本的な技術知識
     – HTTP
     – セッション/cookie
  • 攻撃手法の区別

これらの点を抑えておけばWebのセキュリティのことは万事理解!万事解決!とはいかないです。が、私達が学習用テキストとして採用した「安全なウェブサイトの作り方」をはじめセキュリティ知識を初学者が理解するための足がかりになるのではと考えています。

インターネットが生活に深く入り込んだ現在、Webに関わるエンジニアはセキュリティの考慮も欠かせない業務であり、求められる知識となっています。この記事を機に、Webサイトのセキュリティについて興味を持っていただけたなら幸いです。