フレクトのクラウドblog(New): Webアプリケーションセキュリティについての社内勉強会を開いてみた(解答編)

今年も残り2ヶ月ですがこれから本気出します。エンジニアの小川(mitsuruog)です。
9/3にWebアプリケーションセキュリティというテーマで社内勉強会を開きましたが、解答編の記事を書いてませんでしたね。
すみません。

早速ですが、課題にどんな脆弱性が含まれていたのか？発表します。

回答編

架空のSNSサービスの設計に潜む脆弱性を探すというテーマでした。今回の脆弱性がある設計箇所を分類すると次のようになります。

システムの構成、サイト設計などSNSサービス全体に関わる設計に潜む問題です。

通信経路がHTTP。
- 新規Webサービスであれば、HTTPS前提にするべきです。
管理者ページURLが推測しやすい。
- 管理者ページが「/admin」となっていて非常に推測しやすいです。
- 最近では、WordPressやWebアプリケーションジェネレータ(Yeoman)など、便利なツールが増えてきましたが、デフォルト設定を利用する場合も同様の注意が必要です。

システムのセキュリティの要、認証設計に潜む問題です。

HTTP...orz
- 以下略
パスワード忘れ機能の設計ミス
- 「ユーザーID」と「秘密の質問」を入力するとパスワードが変更できてしまう仕様です。最近であれば、登録済みのメールアドレスにメールを送信するなど、ワンクッション入れたいところです。
- また、秘密の質問が「好きな色は？」となっており、万人が好きそうな色が予測できます。好きな色を固定して「リバースブルートフォースアタック」が成立しやすいです。
Cookieの設計について
- 有効期間が長いのではないか？
- Domain属性が指定されている。
- CookieのDomain属性は 指定しない が一番安全 | 徳丸浩の日記
セキュアな情報をクライアント側で保管している
- 認証後の情報をlocalstorageにて保存しています。中に「管理者フラグ」が含まれていることもあり、容易に管理者へ昇格できます。

WebAPIの設計も細かな注意点があります。

ユーザーIDの採番ルール
- もし連番で発番した場合、容易に他人のユーザーIDが推測できると思われます。
リクエストパラメータの設計ミス
- リクエストパラメータに「管理者フラグ」「ユーザーID」が含まれており、容易になりすましが可能でした。
- メッセージ取得APIのレスポンスで投稿者のユーザーIDが取得できる仕様であるため、他人になりすまして投稿が容易に可能でした。

もう、ダメダメですね。。。
設計のミスで重大なセキュリティ事故が発生した場合、システム開発会社の責任が問われることが多くなってきました。
そのため、特に認証周りの設計する際は次のようなことも留意するようにしています。

実際に受けたメンバーからは「簡単すぎる」との意見が多かったのが反省点ではありますが、セキュリティについて再復習できたいい機会だったのではないかと考えています。

このような活動を地道に続けていく事で、少しずつ強いエンジニア組織にしていきたいですね。

ではではー