EmotionTechテックブログ

株式会社エモーションテックのProduct Teamのメンバーが、日々の取り組みや技術的なことを発信していくブログです。

OWASP 脆弱性検査環境の構築と実施(1)- 準備

みなさん脆弱性検査は随時実施されていらっしゃいますか？

今回は、できるだけ丁寧に自前で脆弱性検査を自前のWebAPPに対して行う工程を記述します。

OWASPとは何か？

Open Web Application Security Project

の頭文字ということです。

定義的にはソフトウェアやWebアプリケーションのセキュリティ分野の研究やガイドラインの作成、脆弱性診断ツールの開発、イベント開催など多岐にわたる活動をしているオープンソース・ソフトウェアコミュニティです。

最近ではこのプロジェクト団体がきめたセキュリティ指針を指して、OWASPの原則とか指針を指すことも多いようです。

OWASP Top10と呼ばれるものが該当します。

一覧にすると下記のような項目となります。

記号 項目 備考
A1:2017 インジェクション
A2:2017 認証の不備
A3:2017 機微な情報の露出
A4:2017 XML 外部エンティティ参照 (XXE) 新たに2017で追加された項目
A5:2017 アクセス制御の不備
A6:2017 不適切なセキュリティ設定
A7:2017 クロスサイトスクリプティング (XSS)
A8:2017 安全でないデシリアライゼーション 新たに2017で追加された項目
A9:2017 既知の脆弱性のあるコンポーネントの使用
A10:2017 不十分なロギングとモニタリング 新たに2017で追加された項目不十分なロギングとモニタリングは、脆弱性診断では検査出来ない項目であるため多くのシステムで実践されていないケースを良く見かけます。

Webアプリケーションの脆弱性でとしてはこれらは確実に対策しておくべき項目の上位10を並べたものとして定義されています。脆弱性に関するコミュニティ参加時や、IPAのセキュリティ脆弱性報告レポートでは必須の有名なリスク要素として有名なため、開発者であれば一度は目にしたことがあるかと思われます。

OWASP ZAP を利用する

OWASP ZAP とは？

上記のOWASP の団体が公開している「Zed Attach Proxy」の略です。

“Zed Attack” の意味が調べきれなかったのですが、概念の提唱団体がプロユースとして開発公開している統合ペネトレーションツールのため、とりあえずペネトレーションをかけてみたいという人でも比較的手軽に統合検査を開始が可能です。

ベースはJavaのツールで、正式名称の通り起動したマシン内にプロクシを立ててProxy経由で自動・もしくは任意で脆弱性攻撃をサイトのリンクスクリーム＆クロール、ピンポイントアタックなどが実施可能な幅広いツールです。

Chrome/FireFoxなどのブラウザとの連携も取れるため敷居としては低くはないですが勘を掴むと直感的にサイト検査を行うことが可能です。

ちなみに、もともとはPAROS PROXYをベースに開発したとのことなんですが、どちらかというとインフラ・ネットワークエンジニアだとおなじみのJMeter なんかで負荷テストをかけた事がある人だと、これ絶対ベースJMeterだよね？と思うこと間違いなしですね。（もちろん細かいところを見ていくと作り込みの設計方針は脆弱性検査に特化しているため同じではないですが、それぐらい似通っている（ある意味使いやすいと言ってもよいかもしれません） そして、JMeterでも感じていた不満点も継承しており

  • Javaベースのため重い。
  • 設定の保存性がJavaベースになるため少し癖がある。
  • これはJavaだからというわけではないのかもしれないけど　動かし始めるとマシンパワーを食う。

などの問題点？は使用感として存在します。

一方Javaベースのためどんな環境でも動作させられる点はこの手のツールのユースケースとしては素晴らしい。

Win/Mac/Linux/Docker用のコンテナイメージなどなどテストと実働で切り分けて環境構築・シナリオ作成など用途に応じて構築可能です。

もっとも貧弱なリソースですと常にGCオーバーフローが発生しているのではないかと感じる程度には動作が重くはなります。

真面目に実査する際はメインの作業マシンで行わずに専用の環境を用意して実査を行うのが良いのではないかと言うのが感想でした。

自動で脆弱性の検査をかけることも可能ですが、脆弱性に対しての攻撃を行うため（しかもスパイダー形式で掘り下げていくため）、脆弱性があるかどうかの初回のチェックは手動でおこない、その後、潰し終わった確信を持ったあとのテストなどは保存した設定を利用して自動テストを行う・・・・というのが現実的な運用でしょう。

この自動テストはコマンドラインで行うと少しだけ実行マシンの負荷は減ります。（がリアルタイムで状況を見たい場合はGUIインタフェイス上で実施したくなります。）

環境を整備

このあたりは先人が散々ドキュメントを残しているので特筆するべきものがあまりないのですが、少し触るだけであれば、ローカルの作業マシン上で同様に構築すれば良いとおもいます。

用意したもの

  • Ubuntuのインスタンス（AWSのEC2インスタンスで用意しました）
    • スペック：m5n2xlarge　環境構築時にはm5.largeで構築をはじめましたが実査中にあまりにも動作が重いため2xlargeまでスペックをあげました。
    • Ubuntu は20.04LTS の入っているイメージ（AMI）を利用しました
      • CLI用に別途ECSで立ててもいいんでしょうがそのあたりは自動テストが必要になった時点で考えればいい気がします。

      というかその場合はECSよりもGCPのCloud Runのほうが手軽かもしれませんね。これは検証まで進めていないです。

    • ストレージ（ブロックデバイス）は数回試すためであれば20GB 程度でも問題ありませんが、レポートが巨大なものになることがあるためレポート用保管のEBSを別途アタッチすることをおすすめします。
      • 本論ではありませんが、レポートが吐き出されたらS3などに退避させて書き出されたレポートは削除する　などを実施したほうが安全です。
    • 外部からのテストと言う体裁を取りたいためGIPはアタッチしました。
    • InboundではsshとRDPのポートを開けてZAPでの作業アクセスはRDP経由でGUIログインを行ってもらい作業をする形を取りました。
    • LinuxでのUserに関しては下記のように設定しました。
      • チーム共通で実施する脆弱性テスト用の共用アカウント
      • 個人が脆弱性テストをのシナリオのテスト・開発・試用を行いたい場合ように個人アカウント 基本的には個人アカウントでシナリオテストを行い、セーブした内容をチーム共有アカウントがわにフィードバックしてメンバ共有するようなイメージです。

ZAP導入作業

汎用的なUbuntuのサーバ（GUI入り）とユーザの初期設定さえ終わればあとは下記のコマンドのコピペで使えるようになります。

$ sudo apt-get update 
$ sudo apt-get install gdebi-core wget
$ wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
$ sudo gdebi google-chrome-stable_current_amd64.deb
$ sudo apt install default-jre openjdk-11-jre-headless

## 2022/02/09時点でのJavaのバージョン確認
$  java -version
openjdk version "11.0.13" 2021-10-19
OpenJDK Runtime Environment (build 11.0.13+8-Ubuntu-0ubuntu1.20.04)
OpenJDK 64-Bit Server VM (build 11.0.13+8-Ubuntu-0ubuntu1.20.04, mixed mode, sharing)
  • OWASP ZAPのインストール
  • なのでgit で引っ張って来るこだわりがある人はgitで引っ張ってくればいいのではないかな？
  • まぁ特にこだわらないので
$ cd ~/Downloards
## 最新版を確認してDLすれば良い
$ wget https://github.com/zaproxy/zaproxy/releases/download/v2.11.1/ZAP_2.11.1_Linux.tar.gz
$ tar xvfz ~/Downloads/ZAP_2.8.0_Linux.tar.gz
$ mkdir -r ~/Documents/Tools
$ mv ~/Downloads/ZAP_2.8.0 ~/Documents/Tools/
  • ここまでで導入は完了しているはずです。

OWASP ZAP の起動

ここからはRDP環境にログインした状態で作業をします。

上記で解凍したZAPのディレクトリに移動

＄ cd　~/Documents/Tools/ZAP_2.8.0/
$ sh ./zap.sh

これで起動するんですが、二回目以降、shでは起動がうまくいかないことがあります。

その場合は

$ bash ./zap.sh

で、問題なく起動します

BASH指定のコマンドss

起動成功画面

この画面が出れば起動中のはずです

初回起動時に

  • プラグインの更新
  • セッションの保存方法を確認されます

とりあえず

  • 検査に必要なプラグインにチェックを入れる（よくわからなかったら後ほど追加削除できるので更新のみ）
  • 最上段の「タイムスタンプをつけてセッションを保存」を選択しておく

で問題ありません。

プラグイン（Add-On の管理画面）

Add-On一覧＆アップデート管理画面
Add-On一覧管理画面

マーケットプレイスではサードパーティ製のAdd-ONの検索追加も可能です

マーケットプレイス画面
マーケットプレイス画面

また公式のAdd-onページでも様々なCommunity Add-ONが見つけられるので用途に応じて入れてみるといいですね。

公式マーケットプレイス
公式マーケットプレイス

長くなったので次回実際に使ってみます。

おわりに

次回は実際にOWASPZAPを利用した初回の脆弱性検査を実施しレポートを出したサンプルをお見せします。

Emotion Techではメインシステムの開発だけではなく、エンジニアの開発環境の見直しを一緒に考えていくメンバーも募集中です。この記事や他の記事を見て弊社に興味をもっていただけましたら、ご応募お待ちしております。

hrmos.co

hrmos.co

hrmos.co