BLOG

ブログ

2020年6月19日

Webシステム開発におけるテスト工程での不具合検出と安全性の検証について

Webシステム開発におけるテスト工程での不具合検出と安全性の検証について

 

Webシステムの開発においてテスト工程では画面(ブラウザ)からの操作による正常系・異常系の動作が要件に合っているかというテストは勿論ですが

ツールを使用する事で様々な視点からのセキュリティ、盤石性の検証を行っております。
この記事では検証に使用しているツールを一部ご紹介すると共に
そのツールを使用する事により何を検証し、何を防げるのかという内容を掲載しております。
(各ツール共に多様な機能を擁しており目的に応じて様々な使い方がありますが、本記事ではテストの目的に沿った使い方の一例をご紹介しております。)

 

目次:

 

1. セキュリティテスト

 

使用ツール:OWASP ZAP, brakeman(Ruby-Railsプロジェクト)
参考サイト:
https://www.zaproxy.org/
(OWASP ZAP公式サイト)
https://github.com/presidentbeef/brakeman
(brakeman)

 

 

OWASP ZAPについて

テスト内容:
画面(ブラウザ)からの操作を記録し実際の操作を想定したシステムの脆弱性を検出

検出できる脆弱性の一例

 

クロスサイトスクリプティング

悪意のあるユーザーが不正なスクリプトをデータとして登録することで、
別のユーザーがそのデータを取得する際に悪意のあるスクリプトがブラウザで実行されてしまう脆弱性

 

SQLインジェクション

サーバーへの問い合わせ情報にSQL(データベースへの問い合わせ言語)文を混入させることで
サーバー上でSQLが実行され意図せぬデータの改ざん、搾取等が行われる攻撃手段

その他にも様々なシステムの脆弱性に対し自動検出を行ってくれます。
詳しくは以下公式サイト(英語)に掲載されています。

https://www.zaproxy.org/docs/desktop/addons/active-scan-rules/

 

 

Brakemanについて

テスト内容:
ソースコードの静的分析ツール(Ruby on Railsのプロジェクトに限る)

 

Ruby on Railsで開発されたプログラムのソースコードを
自動で分析、検証、セキュリティの脆弱性を検出

OWASP ZAP同様にクロスサイトスクリプティングやSQLインジェクションの原因となりうる
脆弱性を伴うソースコードの書き方、ロジックを検出できます。
ブラウザからの操作を想定して検証を行うOWASP ZAPに対し、
プログラムのソースコードそのものを検証します。

 

 

2. 負荷テスト

使用ツール:JMeter
テスト内容:
ブラウザからの一連の操作を記録、指定回数自動実行しサーバーに負荷をかけ本番環境で想定される負荷に耐えうる設計かテストを行う

このテストではブラウザから実際にシステムにアクセス、操作を行った内容を記録し
JMeterを使い同様のリクエストを大量にサーバーに送信し、負荷に耐えうるかを検証します。
検証を行う為一時的にテスト環境を本番同等の構造に変更し、
想定されるアクセス数にバッファを見込んだ数のリクエストをJMeterからサーバーに送信します。

一例として
・1日辺りのアクセスが1万件程を想定、特にアクセスが集中する時間帯に1分あたり200件程が想定される場合
200件*2倍のバッファ=400件/分のリクエストをサーバーに送信
送信時のアプリケーションサーバー、データベースの負荷(CPU使用率, メモリ使用率等)を確認し
本番運用に耐えられるかを判断致します。

 

 

3.権限テスト

 

使用ツール:Postman
テスト内容:
アプリケーションに対して直接リクエストを送信(問い合わせ)を行い、アプリケーション上で権限の制御が行えていることを検証
システムの要件によっては、ログインしているユーザーによって取得できて良いデータ、取得できてはいけないデータ(他顧客の情報等)が存在するケースがあります。
画面上では取得できてはいけない情報が表示されないことを確認する事は勿論ですが
このテストではアプリケーションに対して直接リクエストを送信することで
本来取得できないはずのデータを取得できてしまわないかという検証を行います。

一例として
あるアプリケーションで支社A(ID:100)と支社B(ID:101)のユーザーが存在し、ログインしたユーザーによって自身が権限を持っている支社の顧客データが参照できるシステムがあったとします。

ブラウザから支社Aの情報のみ閲覧できるユーザーでログインした場合、ブラウザからはログイン情報が送信され
サーバー上からは支社A(ID:100)のデータが返されます。

画面上から支社B(ID:101)のデータを取得するUIが表示されていないことは確認できますが
悪意のあるユーザーがツール等を使いサーバーに送信しているリクエストを編集し
「ID:100の顧客情報をください」というリクエストを
「ID:101の顧客情報をください」と書き換えられた場合、
アプリケーション側で適切に制御が出来ていない場合企業Bの情報を返してしまう事になりかねません。
この検証ではPostmanを使い実際に権限のないデータに対してリクエストを送信しても
サーバーからはエラーが返ってきて対象のデータが取得できないことを検証します。

コメントを投稿できません。