Google ウェブツールキットのウェブアプリファイアウォールのサポート
注： この機能は、Citrix ADCリリース10.5.eで使用できます。
Google Web Toolkit（GWT）リモートプロシージャコール（RPC）メカニズムに従ったWebサーバーは、GWTサポートを有効にするための特定の構成を必要とせずにCitrix Web AppFirewallによって保護できます。
GWTとは何ですか?
GWTは、XMLHttpRequest、およびJavaScriptの専門知識を持っていない人々によって複雑な高性能Webアプリケーションを構築し、最適化するために使用されます。このオープンソースの無料開発ツールキットは、小規模および大規模アプリケーションの開発に広く使用されており、フライトやホテルなどの検索結果などのブラウザベースのデータを表示するためによく使用されます。GWTは、ほとんどのブラウザやモバイルデバイス上で実行することができ、最適化されたJavaScriptスクリプトを書くためのJava APIとウィジェットのコアセットを提供します。GWT RPCフレームワークは、WebアプリケーションのクライアントとサーバーコンポーネントがHTTP経由でJavaオブジェクトを交換することが容易になります。GWT RPCサービスは、SOAPまたはRESTに基づくWebサービスと同じではありません。これらは、単にクライアント上のサーバーとGWTアプリケーション間でデータを転送するための軽量な方法です。GWTは、メソッド呼び出しと戻り値の引数を交換するJavaオブジェクトのシリアル化を処理します。
GWT を使用する一般的なウェブサイトについては、
https://www.quora.com/What-web-applications-use-Google-Web-Toolkit-%28GWT%29
GWTリクエストの仕組み
GWT RPC要求は、パイプで区切られ、引数の数が可変です。これは HTTP POST のペイロードとして搬送され、次の値を持ちます。
- Content-type = text/x-gwt-rpc. 文字セットには任意の値を指定できます。
- Method = POST.
コンテンツタイプが「テキスト/ x-gwt-rpc」である場合、GETとPOST HTTP要求の両方が有効なGWT要求とみなされます。クエリ文字列は、GWT 要求の一部としてサポートされるようになりました。アプリケーションファイアウォールプロファイルの「InspectQueryContentTypes」パラメータを「OTHER」に設定して、コンテンツタイプの「text/x-gwt-rpc」のリクエストクエリ部分を調べます。
次の例は、GWT 要求の有効なペイロードを示しています。
5|0|8|http://localhost:8080/test/|16878339F02B83818D264AE430C20468| com.test.client.TestService|testMethod|java.lang.String|java.lang.Integer| myInput1|java.lang.Integer/3438268394|1|2|3|4|2|5|6|7|8|1|
リクエストは、次の 3 つの部分に分けることができます。
a)Header: 5|0|8|
上記のリクエストの最初の3桁5|0|8| は、それぞれ「バージョン、Subversion、およびテーブルのサイズ」を表します。これらは正の整数でなければなりません。
b）文字列テーブル：
http://localhost:8080/test/|16878339F02B83818D264AE430C20468| com.test.client.TestService|testMethod|java.lang.String|java.lang.Integer|myInput1| java.lang.Integer/3438268394|
上記のパイプ区切り文字列テーブルのメンバーには、ユーザーが指定した入力が含まれています。これらの入力は、Web App Firewall チェックのために解析され、次のように識別されます。
-
第 1:
http://localhost:8080/test/これはリクエスト URL です。
-
第2回:
16878339F02B83818D264AE430C20468一意の 16 進識別子。この文字列に 16 進以外の文字が含まれている場合、要求は不正な形式と見なされます。
-
第3回:
com.test.client.TestServiceサービスクラス名
-
第4回：
testMethodサービスメソッド名
-
5 回目以降:
java.lang.String|java.lang.Integer|myInput1|java.lang.Integer/3438268394データ型とデータ。非プリミティブデータ型は、
<container>.<sub-cntnr>.name/<integer><identifier>
c)Payload: 1|2|3|4|2|5|6|7|8|1|
ペイロードは、文字列テーブル内の要素への参照で構成されます。これらの整数値は、文字列テーブル内の要素数より大きくすることはできません。
GWTアプリケーション用のWebアプリケーションファイアウォール保護
Web App Firewall は、GWT RPC 要求を理解して解釈し、ペイロードにセキュリティチェック違反がないか検査し、指定されたアクションを実行します。
GWTリクエストのWeb App Firewall ヘッダーとCookieチェックは、他のリクエスト形式のものと似ています。適切な URL デコードと文字セット変換の後、文字列テーブル内のすべてのパラメータが検査されます。GWTリクエスト本体には、フィールド名だけフィールド値が含まれていません。入力値は、Web App Firewall Field Format チェックを使用して、指定した形式に対して検証できます。このチェックは、入力の長さの制御にも使用できます。入力における クロスサイトスクリプティング 攻撃と SQL インジェクション 攻撃は、Web App Firewall によって容易に検出され、阻止されます。
学習と緩和のルール：緩和ルールの学習と展開は、GWT要求でサポートされています。Web App Firewall ルールは、<actionURL> <fieldName> マッピングの形式です。GWT要求フォーマットは、フィールド名を持っていないため、特別な処理が必要です。Web App Firewall は、緩和ルールとして展開できる学習ルールにダミーのフィールド名を挿入します。-isRegexフラグは、GWT以外のルールと同じように機能します。
-
アクション URL:
1 つの RPC に応答する複数のサービスを同じ Web サーバ上に構成できます。HTTP 要求には、RPC を処理する実際のサービスではなく、Web サーバーの URL があります。したがって、HTTP リクエスト URL に基づいて緩和が適用されることはありません。これは、ターゲットフィールドの URL のすべてのサービスが緩和されるためです。GWT 要求の場合、Web App Firewall は文字列テーブルの 4 番目のフィールドにある GWT ペイロードで見つかった実際のサービスの URL を使用します。
-
フィールド名:
GWT リクエスト本文にはフィールド値のみが含まれているため、Web App Firewall は、学習したルールを推奨するときに、1、2 などのダミーのフィールド名を挿入します。
GWT学習ルールの例
POST /abcd/def/gh HTTP/1.1 Content-type: text/x-gwt-rpc Host: 10.217.222.75 Content-length: 157 5|0|8|http://localhost:8080/acdtest/|16878339F02Baf83818D264AE430C20468| com.test.client.TestService|testMethod|java.lang.String%3b|java.lang.Integer|onblur| The learn data will be as follows: > sh learningdata pr1 crossSiteScripting Profile: pr1 SecurityCheck: crossSiteScripting 1) Url: http://localhost:8080/acdtest/ >> From GWT Payload. Field: 10 Hits: 1 DoneGWT 緩和規則の例
bind appfw profile pr1 -crossSiteScripting 1 abcd -isregex NOTREGEX
ログメッセージ：Web App Firewall は、GWT要求で検出されたセキュリティチェック違反のログメッセージを生成します。不正な形式のGWT要求によって生成されたログメッセージには、簡単に識別するための文字列「GWT」が含まれています。
不正な形式のGWT要求のログメッセージの例：
Dec 5 21:48:02 <local0.notice> 10.217.31.247 12/05/2014:21:48:02 GMT ns 0-PPE-0 : APPFW Message 696 0 : "GWT RPC request with malformed payload. <blocked>”
GWTと非GWTリクエストの処理における違い：
同じペイロードによって、異なるコンテンツタイプに対して異なる Web App Firewall セキュリティチェック違反が発生する可能性があります。次の例を考えてみましょう。
5|0|8|http://localhost:8080/acdtest/|16878339F02Baf83818D264AE430C20468|com.test.client.TestService|testMethod|java.lang.String%3b|java.lang.Integer|select|
Content-type: application/x-www-form-urlencoded:
SQL インジェクションタイプが利用可能な 4 つのオプション (SQLSplCharandKeyword、SQLSplCharOR キーワード、SQLKeyword、または SQLSplChar) のいずれかを使用するように構成されている場合、このコンテンツタイプとともに送信された要求は SQL 違反になります。Web App Firewall では、上記のペイロードを処理するときに ‘&’ がフィールドセパレータであり、’=’ が名前と値のセパレータであると見なされます。これらの文字はいずれもポスト本体のどこにも表示されないため、コンテンツ全体が単一のフィールド名として扱われます。このリクエストのフィールド名には、SQL 特殊文字 (;) と SQL キーワード (選択) の両方が含まれています。したがって、4 つの SQL インジェクションタイプのオプションすべてに対して違反がキャッチされます。
Content-type: text/x-gwt-rpc:
このコンテンツタイプで送信された要求は、SQL インジェクションの種類が SqlSplCharorKeyword、SqlKeyword、または SqlSplchar の 3 つのオプションのいずれかに設定されている場合にのみ、SQL 違反をトリガーします。SQLインジェクションタイプがデフォルトオプションのSQLSplCharANDKeywordに設定されると、違反はトリガーされません。Web App Firewallは、垂直バー| をGWTリクエストで上記のペイロードのフィールド区切り文字とみなします。そのため、ポストボディはさまざまなform-field値に分割され、（上記の規則に従って）form-field名が追加されます。このスプリットによって、SQL特殊文字とSQLキーワードが個別のフォームフィールドの一部になります。
フォームフィールド 8:java.lang.String%3b -\> %3b is the (;) char
フォームフィールド 10:select
その結果、SQL インジェクションタイプが SQLSplCharに設定されている場合、フィールド 8 は SQL 違反を示します。SQLKeywordの場合、フィールド 10 は違反を示します。SQLインジェクションタイプが SQLSplCharORKeyword オプションを使用して構成されている場合、これら 2 つのフィールドのいずれかが違反を示している可能性があります。このオプションでは、キーワードまたは特殊文字の存在が検索されます。デフォルトの SQLSplCharANDKeyword オプションに対して違反は捕捉されません。これは、 SQLSplChar と SQLKeyword の両方を含む値を持つ単一のフィールドがないためです。
チップ:
- GWT サポートを有効にするために、特別な Web App Firewall 設定は必要ありません。
- コンテンツタイプはテキスト/x-gwt-rpcである必要があります。
- GWT ペイロードに適用されるすべての関連する Web App Firewall セキュリティチェックの緩和ルールの学習と展開は、サポートされている他のコンテンツタイプの場合と同様に機能します。
- 唯一のPOST要求は、GWTのために有効とみなされます。コンテンツタイプが text/x-gwt-rpc の場合、他のすべての要求メソッドはブロックされます。
- GWT 要求は、プロファイルの設定済みの POST本文制限に従います。
- セキュリティチェックのセッションレス設定は適用されず、無視されます。
- CEF ログフォーマットは、GWT ログメッセージでサポートされています。