Designing a testcase system for browsers | ブラウザによるテストケースシステムの設計

The testcase system is an important piece to the WBTS project. It went through a few design changes while I was working on it. It is made up of two parts, the client side and the server side.

Client Side
The client side code is just a single javascript object called TestCase. It allows you in your testcase to store the following information:
1. input: A quick summary of the input to your testcase like document.cookie = 0x00-0xff.
2. output: The output of the test, if there is any. You can supply your own html formatting as well.
3. description: A quick description of the test like: "Inject headers into xhr object"
4. target host: The host name you expect the request to becoming from (usually only used for SOP tests).
5. expected result: What you expect the result to be like: "null" or "exception"
6. result: The actual result of the test.
7. test passed: Did the test pass or fail? (Usually true or false).

There are two methods of running a test. For simple tests, you can fill out the object, run a test then just call the testcase objects saveTest method. For more complex, or dangerous testcases you can use the savePreTest method. This allows you to set up all the test information and store it in a temporary document. You then run the test. If the test causes the browser to stop, the blade automation system will call a failTest method, indicating that it was unable to complete. This also causes the temporary data to be copied into the real results database.

Here is an example testcase:

Lines 6-12 are used to ensure our testcase function "f" fires when the window finishes loading.
Lines 15-25 create a string of bytes to be used as input.
Line 26 URL decodes the data into their "raw" form.
Line 27 creates a cookie value.
Line 29 sets the testcase input (this will be directly visible in the results database).
Line 30 sets the description.
Line 31 is the actual test, creating a cookie for the document, then making a request to a special resource. After showRequest is called via XHR, the "save_test" call back function will have access to the response data and our testcase object.
Line 36 takes the response data and sets that as our output.
Line 37-38 tries to remove the cookie data.
Line 39 finally saves the test to our results database.
It should be noted, each testcase is called with a query parameter called client_id. This value is generated by the blade automation system and used for tracking purposes. A request to a testcase would look like: http://www.attacker.com/testcases/headertests/sometest.html?client_id=<some unique id>

Server Side
Our test case system is mapped to /tc/ on all virtual hosts. It offers three resources: saveTest, savePreTest, and failTest. They are not very complicated, they just take in the data as POST parameters. A few fields are base64 encoded for storage as it may contain invalid UTF-8 bytes which may cause MongoDB to throw an error. savePreTest will store data in a temporary database. The pretest data contains the testcase information configured for a failure result. This way, when failTest is called, it can just copy the information into our results database.

WBTSプロジェクトのためにテストケースシステムが大事。作りながら何回もデザインが変更した。テストケースシステムは二つの部分（クライアント側とサーバー側）がある。

クライアント側
クライアントサイドコードはTestCaseというのJavaScriptオブジェクトだけである。このオブジェクトが以下のような情報を保存する：
1. input（入力）: テストケースの簡単な概要。例：document.cookie ^ 0x00 - 0xff。
2. output　（出力）: テストの出力。HTML様式もできる。
3. description: テストケースの説明。例： 「XHRオブジェクトにヘッダーをインジェクトする。」
4. target host: テストケースの実行されるホスト名。普段は、SOP専用
5. expected result(予想通りの結果）: 例: 「null」または「exception」
6. result （結果）: 実際のテスト結果。
7. test passed　（テストの成否）: テストは失敗か正解だったか。普段は 「true」か「false」。

（上記のコードーを見て。）
Line 6-12 Windowがロードーするのを完成したら「ｆ」という関数を実行する。
Lines 15-25 テストの入力による、文字列を作成する。
Line 26 データーをURLデコードする。
Line 27 クッキー値を作成する。
Line 29 テストケースの入力を設定する。(この情報は結果DBで見られるようにする）
Line 30 説明を設定する。
Line 31　これが実際のテスト。ドキュメントのクッキーを作成、特別なWebリソースに呼び出す。XHRでshowRequestを呼び出した後は「save_test」のコールバック関数を呼び出す。この関数がレスポンス情報とTestCaseのオブジェクトにアクセスできる。
Line 36 レスポンス情報を出力に設定する。
Line 37-38 クッキーを削除する。
Line 39 テストの結果をDBに送信する。
実は、「client_id」と言うパラメーターは格テストケースに送信する。トラッキングのため、この「client_id」値はbladeシステムによって作られたものだ。例えば、下記のようなURLはテストケースのリクエスト。
http://www.attacker.com/testcases/headertests/sometest.html?client_id=<some unique id>

サーバー側
テストケースシステムは全部のVirtualHostsで「/tc/」にマップした。このシステムは三つのリソース「saveTest」、「savePreTest」、「failTest」を実装する。そんなに複雑ではない。POSTでのパラメーターだけ受信する。テスト結果が不正なUTF-8バイトを持っているかもうしれないので、多少のDBフィールドはbase64エンコードする必要がある。エンコードしないと、MongoDBがエラーを発生する。「savePreTest」リソースはテストデータをDBに一時的に保存する。テストが失敗する場合、bladeシステムは「failTest」に呼び出すと一時的なDBから結果DBにコピーされる。

Introducing... WBTS | WBTSの紹介

For those that know me, probably know I've been working a lot on a personal project called WBTS. WBTS is a Web Browser Testing System for finding bugs. I built it using the twisted python framework. But what exactly is WBTS?
1. A cross-platform web application server supporting SSL, Virtual Hosts, processors for various web languages and the ability to include your own. All built on python's stupid fast Twisted framework.
2. A built in DNS server to allow records to be created on the fly, as well as built-in DNS
rebinding functionality accessible via web requests.
3. A cross-browser JavaScript test case framework that allows you to quickly create new test cases for various browser bugs using different automation methods. The framework hooks into MongoDB to store the results in an easily search-able data store.
4. Lots of test cases both from public sources such as WebKit's LayoutTests, old known
browser vulnerabilities taken from Mozilla Firefox's and Google Chrome's bug tracker
systems as well as ones created by myself.
5. A slick management Web UI to review test results and configure WBTS.
6. Future plans to implement a fully featured fuzzing framework.

See the screen shots below!

たぶん知ってるけど、最近僕はWBTSというプログラムを作っている。WBTSというのは脆弱性を見つけるためのウェブブラウザテスティングシステムです。このアプリケーションはTwisted　Pythonのフレームワークで作ったものだ。でも、WBTSとは何でしょか？

1. SSL,VirtualHosts,自分の好きな言語をサポートされているクロスプラットホームのWebアプリケーションサーバーです。
2. 組み込みDNSサーバーが一瞬的に記録を作られ、WebのURIアクセスすると、DNSリバインディング攻撃ができる。
3. 複数のオートメーション方法で簡単にテストケースを作られるクロスブラウザテストケースシステム。このシステムがテストの結果をMongoDBに保存します。
4. WebKitのLayoutTests、古いのMozillaとChromeの脆弱性と自分の作ったのたくさんのテストケースが入っている。
5. カッコイイWebUIで結果をレビューし、WBTSの設定も簡単にできる。
6. Fuzzingシステムを作る予定もある。

以下のようなWBTSの画像を見てください！
1. Cross Platform UI! (Windows) | クロスプラットホームUI!　（windows版）


2. DNS Server Settings | DNSサーバーの設定


3. Test case results | テストケースの結果


4. Various WBTS Settings | いろいろなWBTSの設定