クライアントからファイル サイズの制限を設定し、クライアントがログ ファイルをアップロードする頻度を調整して、WL 分析サーバー上のサーバーのサービスを拒否できないようにするにはどうすればよいでしょうか?
アプリケーションのセキュリティ チェックを行ったところ、次の結果が得られました。
ログ インジェクションは、攻撃者がログ ビューアで観察したときに、ログ エントリの一部として悪意のあるコードを実行する目的で挿入できる場合に発生します。システムで発生したすべてのイベントを表示するには、アプリケーション ログ ファイルに送信されたすべてのデータを維持する必要があります。これらのログ ファイルは、端末からフル機能の Web アプリケーションまで、複数の手段を介してエンド ユーザーが表示できます。潜在的に悪意のある文字または制御文字がこれらのビューアーのいずれかに表示される前にサニタイズされていない場合、ログを表示しているエンド ユーザーに影響を与える可能性があります。
インスタンス:
- 「https://company.com/アプリケーション名/apps/services/loguploader」
再現する手順：
- burp のような HTTP プロキシを介してアプリケーションをプロキシします。
- アプリケーションにサインインする
- アプリケーションは /loguploader にリクエストを送信します。
圧縮されたコンテンツはファイル /var/mobile/Applications//Documents/wl.analytics.log からのものであることに注意してください
注: アプリケーションがこれに対して本当に脆弱かどうかをテストするには、wl.analytics.logファイルを変更し、サイズを増やしてローカルで変更し、変更されたファイルが受け入れられたかどうかを確認するために loguploader サービスが呼び出された後にサーバーで調べる必要があります。
次の URL にアクセスしました。
以下は、上記のリンクからの情報のカップルです。
このwl.analytics.queuesパラメーターは、Worklight Server がメモリー内に保持するキューの最大数を決定します。Analytics Platform にポストする前にすべてのキューがいっぱいになると、Worklight Server はキューが空になるまで、クライアントから受信したデータをドロップします。
wl.analytics.queue.sizeパラメータは、各キューが保持できる個々の要素の数です。これらのパラメータの調整は影響します
サーバーが一度に保持する個々の分析イベントの数は ですwl.analytics.queues * wl.analytics.queue.size。これら 2 つのパラメーターを定義するときは、この事実を考慮してください。設定が低すぎると、サーバーが異常にビジーな場合に大量の分析データがドロップされる可能性があります。これらの値を高く設定しすぎると、Worklight Server で使用されるメモリーが多すぎる可能性があります
上記の詳細から、値を正しく設定すると、オーバーフローのために価値の高いファイルのアップロードがドロップされるようです。
しかし、セキュリティ上の問題に対処するために正しい値を設定する必要があるかどうかはわかりません。これで問題は解決しますか?
WL サーバー バージョン 6.2.0.1
リバティ バージョン 8.5.5.1