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 SideThe 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 SideOur 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にコピーされる。
