Webサービスのセキュリティを強化する方法を考えてみた

　こんにちは！@wakky_404です。

　この記事はAteam Hikkoshi Samurai Inc. & Ateam Connect Inc.（エイチーム引越し侍、エイチームコネクト） Advent Calendar 2019 8日目の記事になります。

　今回、過去の事例(自己含む)からWebサービスや会社のセキュリティを強化する方法を考えてみました。
　発言は個人のものになりますが「こんな策も有効ではないか」など何かあれば優しめにマサカリいただけると大変ありがたいです！！

きっかけとなった とある朝の出来事

　Advent Calendar何書こう・・・（´-`）.｡oOと平和に考える私の前に一件の不穏なメールが届きます。

「お客さまのアカウントにログインが行われました」

　メールの送信元は以前利用していたCtoCアプリで、もちろんログインもしておらず、記載されていたログイン端末も一切心当たりがないもの。
　焦る私は、自身でサービスへログインを試みるも「ログイン情報が間違っています」の連続。
　アカウントを乗っ取られる前に..!とパスワードリセットメールを送信&パスワードを変更。

　・・・しまった、どのパスワードが流出していたのだろう😨
と同時に下記のことを感じました。

• ログイン通知がなければ流出に気づいていなかったこと
• パスワードリスト型攻撃が日常茶飯事になっているであろうこと
• パスワードリセットをしても、犯人の強制ログアウトが行われていないのではという懸念(=現在も個人情報が見られてしまっているのではないかという不安)

最近特に厄介だと感じる攻撃 3種

1. パスワードリスト型攻撃

　いわずと知れた「漏洩済みIDとパスワードの組み合わせリスト」を基にログインする攻撃です。
　私が朝受けたログインもこの攻撃と思われるもので、ログイン端末は「Android4.2スマホ(2014) 解像度1920x1080」で、恐らくPCのAndroid仮想マシンからの攻撃と思われます。
　リスト型攻撃による被害事例一覧(jamhelper.com)によると、公表されるものだけでも毎年数千〜数十万件のアカウントが被害にあってしまっているようです。あくまで攻撃の事実を公表している企業に限りますが、ポイントやECなど、個人情報&お金の絡むサービスが多い印象でした。
　最近の2019年5月に46万件の個人情報が漏洩していることを考えると、今もユーザの多くがメールアドレス+パスワードをサイトで使い回していることが考えられます。

2.2段階認証も突破するフィッシングサイト

　パスワードリスト型攻撃の対策として多要素認証が効果的と言われてきましたが、最近「2段階認証にも対応する作成キットが出回っている」とのニュースが話題になっていました。
　産経新聞の記事によると、警視庁発表のフィッシングサイト被害額は今年1~8月に3億円弱だったのに対し、作成キットが出回ったとされる9月は4億円以上と急激に被害が拡大しているようです。

3. 組織、取引先を装うメール攻撃（標的型攻撃）

「組織」を標的とし、実在する人物/取引先を装いメールを送信/返信する攻撃です。
こちらは最近特に猛威を振るっているとされるEmotet(IPAの記事)などがあり、添付ファイルを開くなどで感染すると、そのPCを起点としてメール攻撃、ランサムウェアのダウンロード・ネットワークへの拡大などを行われる恐れがあります。
　多くの組織では取引先との連絡にメールを用いることが多いと思いますが、取引先を装うメールが届いても多忙の中気づくことは難しいと思われます。
　似た攻撃で「ビジネスメール詐欺」というものもあり、振込先変更メールを送信するなど、ビジネスに大きく影響を及ぼしてしまいそうなものも厄介に感じます。
　2018年の仮想通貨 数百億円流出事件は記憶に新しいと思いますが、この時の手法も「メールで長期的にやり取りし、担当者を信頼させての攻撃」でした。

攻撃と防御の現状

※ややソースの公開日が古いですが、認識としては大きく変わっていないと考えています。

1. 攻撃の多くは金銭目的

• 攻撃者の利益は投資額の140倍(産経新聞)
  • より利益の出る、金銭を取り扱うサイトに攻撃が集中
  • セキュリティが弱いと思われるサイトに攻撃しログイン情報を取得

2. 企業が攻撃に気づくまで半年以上。世界平均は205日! (マイナビニュース)

3. 9割の企業は外部から指摘を受けるまで攻撃に気づかなかった (TRENDMICRO)

セキュリティを強化する方法

最悪のケースを考え、漏洩前提で実装する

1. ユーザログイン時、ログインの事実をメールで通知する

• ユーザからの問い合わせが行われれば、早く気づけ被害の最小化に
• ログインIPアドレス、ユーザエージェントなどをメールに載せておくと調査時便利
• 頻度：毎回、普段のログイン環境と異なる際のみなど

2. パスワードリセット時、ログイン中端末を全てログアウトできるようにする

• LINEやTwitterで実装されており、リスト型攻撃の多い昨今ではこの機能がユーザの安心を実現
• 基本的にログアウトしないようなアプリだと逆効果の可能性も
  • ユーザがID/パスワードを一切覚えておらず逆に攻撃者に完全に乗っ取られる可能性

3. IPAの「安全なウェブサイトの作り方」でウェブセキュリティへの理解を深めておく

4. ログイン試行回数に上限を設ける

• 個人的にですが下記のようなこともあり「n時間にn回まで」よりは「数回以上失敗でロック(メール宛に解除リンクを送信し、ユーザがクリックするまでログイン無効化)」&「連続で失敗するIPアドレスを一定時間制限」の方が有効と感じています
• ここ数年でログイン試行回数の制限を回避する動き
  • 2014年の航空会社の不正アクセス事件では、逆総当たり攻撃と呼ばれる「パスワード固定でユーザIDを変動させる」攻撃で被害（通常ID毎にn回まで制限するため、IDを変更されるとロックが発生しない）
  • 自動プログラムによるログインを試行する頻度が数時間〜数日に1回と、長期間でログイン制限にひっかからない

5. (優先度低) ユーザのパスワードをまとめてリセットできる機能を管理画面に

• 有事の際に初動対応の時間を短くし、少しでも被害を少なく
• 誤使用に注意

パスワードリスト型攻撃に備える

1. ログイン条件を複雑化

• パスワードで下記を必須化
  • 大文字
  • 記号、特殊文字
  • (一般的ではないものの自社特有のワードなど)
• ユーザの負担は増えますが流出済みの情報と一致しないためにも必須

2. 2要素認証を用いる

• ログイン時、ランダムな数字を携帯電話のショートメッセージ(SMS)やメールアドレス宛に送信
• iOS端末の場合、新規端末にApple IDでログインしようとすると既存デバイスで許可ボタンを押し、表示される4桁の数字を入力
• 先述の通り、フィッシングサイトでも効いてしまう

3. パスワードを無効化する

• 進む「パスワード無効化」の動き
  • パスワードを段階的に無効化 (Yahoo!Japan)
    • IDと一時パスワードを都度発行し実現
      • ユーザにSMSやメールを送信し、ユーザは届いた番号を入力しログイン
  • FIDO、日本での最新動向を披露--LINEやドコモもパスワードレスへ (ZDNet)
    • 秘密鍵がユーザに保存され、サーバには公開鍵が保存される
      • FIDOの仕組み (公式)

4. (実験的)メールアドレス・パスワードが漏洩済みかチェック

• ユーザの許可を得て、メールアドレスやパスワードが流出済みかを定期チェックするなど
  • ';--have i been pwned? のAPIを使って流出したパスワードかチェックする

フィッシングサイト対策

1. 検索結果をモニタリング

• 自社ドメイン以外でサービスの文言を含むページなど
• 見つかれば、Google検索にindexされないようフィッシングサイト申請(Google)

2. ユーザに気づいてもらえる策を講じる

• メールに電子署名を付与
• メールフォーマットを固定など (フィッシング対策ガイドライン)

標的型攻撃対策

1. 添付ファイルは開かない

• 添付の旨を電話や別手段等で確認する
  • 先方のPCがマルウェアに感染していた場合はこの方法で防げない
• どうしても添付ファイルを開く場合、Windows10のSandboxモードで開く(仮想マシンのようなもの/Windows10 Pro/Enterpriseのみ)

2. なりすまし検知などのあるサービスを利用する

• GSuiteなど

3. 定期的な啓発を忘れない

4. メール送信訓練を行う

• 事前告知なしに標的型攻撃メールを送信し、開封率などを計測

より強力にするために

システム/会社を診断する

注意

• スキャン対象は自社内に絞り、外部に向けて利用しないこと
• インフラ、クラウドなど許可を得ておくこと
• ネットワークペネトレーションなどは負荷がかかる

1. Web脆弱性診断

• WebアプリケーションにXSSやSQLインジェクションなど、攻撃できてしまう隙がないか
• OWASP ZAP、Burp Suiteなどのツールを用いる
• 「やられサーバ」で練習する

2. ネットワークペネトレーションテスト

• サーバなど、バージョンが古く脆弱性が存在するものがないか
• 外部からのアクセスを遮断している場合などでも、ネットワーク内のPC1台がマルウェアに感染した場合などを想定
• Nessusなどのツールで確認

3. レッドチーム演習

• 攻撃者目線でシステムや会社の穴を探す
  • ビルに侵入できる経路はないか
  • システムに攻撃できる場所はないか
  • 電話で緊急時を装うなどしパスワードを聞くソーシャルエンジニアリングなど
• リクルートなど国内企業でも導入していることがあり、Microsoftなどでは防御のブルーチームにも分かれ切磋琢磨

最後に

　長くなってしまいましたが、パスワードレスや有事の対処がスムーズに行えるシステムなど、利便性も追求しつつユーザが安心して快適に利用できるようなサービスを作っていきましょう！

お知らせ

エイチームグループでは一緒に活躍してくれる優秀な人材を募集中です。
興味のある方はぜひともエイチームグループ採用ページ（Webエンジニア詳細ページよりお問い合わせ下さい。
あるいは、Qiita Jobsの引越し侍Webエンジニアチーム、自社サービスWebエンジニア／インフラからサービス改善まで！、求む！引越し侍大規模リプレイスにおけるフロントエンドのリードエンジニア募集！の記事をみて、興味が出てきた方は是非Qiita Jobsのチャットでメッセージをください。

明日

明日は偉大なる先輩@anneauの記事です！
明るく元気な記事を楽しみにしています?!