パラメータタンパリング攻撃

パラメータタンパリング攻撃とは何か？

このサイバーセキュリティ脆弱性は、クライアントとサーバのパラメータを改ざんまたは変更するものです。一般的に、複数の手法でアクセスされ、特定のデータや認証情報、各種情報を得るために変更される重要なパラメータが対象となります。

対象となるパラメータは、販売データやユーザー認証情報など、何でもあり得ます。この攻撃では、URLクエリ文字列、クッキー、HTTPヘッダー、またはHTMLフォーム内の非表示フィールドに格納されたウェブアプリのパラメータが利用されます。これらについて詳しく学びます。

‍

パラメータタンパリングの例

HTTPヘッダー

HTTPヘッダーの意味を知らない方へ。HTTPヘッダーとは、クライアントからサーバへ、あるいはサーバからクライアントへ送られる制御情報のことです。各HTTPヘッダーは、標準ASCIIテキスト、数値、そして名前から構成されます。

参考までに、サンプルのヘッダーを示します:

Host: www.xplace.org
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Lynx/2.8.4dev.9 libwww-FM/2.14
Referer: http://www.xplace.org/login.php
Content-type: application/x-www-form-urlencoded
Content-length: 86

通常、HTTPヘッダーはウェブサーバソフトやブラウザが内部で利用しており、目立たず動作します。そのため、多くの場合、APIセキュリティポリシーの対象にはなりません。

しかし、セキュリティに関心のある開発者は、受信したヘッダーを監視することもあります。十分な安全対策が講じられていなければ、攻撃者によってクライアント側のHTTPヘッダーに不正なリンクやコードが挿入される可能性があるため、特に注意が必要です。

なお、ほとんどのブラウザがHTTPヘッダーへのアクセスを制限しているため、攻撃者が改ざんするには余分な労力が必要です。HTTPヘッダーの変更には、攻撃者が通常、Perlコードを利用したカスタムプログラムを作成するか、または無料のプロキシを活用します。どちらの場合もHTTPヘッダーの改ざんが可能です。

対策 

HTTPヘッダーの保護では、特にリファラーとして作成されるクライアント側ヘッダーの管理が難しいため、その使用を控えることが、脆弱性リスクを最小限に抑える唯一の方法です。

一方、サーバ側ヘッダーについては、暗号鍵を使用することで脆弱性から守ることが可能です。暗号鍵を加えることで、パラメータの解読が困難になり、十分なセキュリティ対策がない場合に比べ、リスクが低減されます。

‍

URLクエリ文字列

URLクエリ文字列とは、URLに「?」を付けた後の文字列のことです。基本的に、「?」以降にあるテキストがURLクエリ文字列となります。

例:

https://sample.com/over/here?name=ferret

このURLでは、「?」以降の「name=ferret」がURLクエリ文字列です。文字単位では、クエリ文字列はパラメータと値からなり、「=」で結ばれています。この例では、「name」がパラメータ、「ferret」が値を表します。

次に、URLクエリ文字列の改ざんについて考えます。熟練のハッカーであれば、パラメータを利用して巧妙に機微な値を挿入するだけで、URLクエリ文字列の改ざんおよび悪意ある操作を実行できます。

以下に、URLクエリ文字列の操作を示す簡単な例を紹介します:

http://www.easy.com/sample?visitordata=12345&copydata=1

このHTTPリクエストを用いれば、管理者はサイトの訪問者データをエクスポートできます。しかし、意図の悪い攻撃者は、このクエリ文字列を操作して、より多くのデータを輸出、あるいは盗む可能性があります。

攻撃者は、パラメータ値を変更するだけで済みます。

http://www.easy.com/sample?visitordata=12345&copydata=100000

この改ざんされたクエリ文字列パラメータにより、1件分のユーザーデータの代わりに10000件のデータがコピーされる恐れがあります。

対策

上記の例から、クエリ文字列の改ざんによって甚大な被害が発生する可能性があることが明らかです。リスクを抑えるため、最適な対策を採用することが欠かせません。

パラメータがクライアントからサーバへ送信される際、必ず認証済みのセッショントークンが付随していることを確認する必要があります。クッキーであってもパラメータであっても、その存在自体が安全性向上に寄与します。

また、ウェブアプリは操作実行前に、送信元のユーザーの正当性を確認すべきです。パラメータは、検証済みの送信元から来たと確認できて初めて処理されるべきです。

二重のクエリ文字列改ざんを防ぐため、パラメータをURLや非表示フィールドとして利用しないよう注意することが重要です。そうでなければ、利用者がパラメータを自由に変更できる状況となり、問題が発生します。

さらに、利用者がパラメータ値を閲覧できないようにすることも非常に重要です。例外なく、この実装が求められ、パスワードなどの重要な情報が表示されてはなりません。

機微なパラメータに対しては、暗号鍵を追加することが最も有効な対策です。これは、1．クエリ文字列や非表示フォームフィールド全体を暗号化する方法と、2．MD5ダイジェスト値を持つ追加パラメータを導入する方法の２通りで実施できます。前者は、利用者に値を見せず設定させないため、完全な秘密保持に優れていますが、後者は利用者が値を変更できるため、効果はやや劣ります。

‍

クッキー

クッキーは、検索項目、セッショントークン、閲覧の好みなどの情報を含む小さなデータ片です。サーバが生成し、ブラウザが収集します。ブラウザ設定や検索項目の把握など、所定の目的で使用される限り、問題はありません。しかし、クライアント側で容易に変更可能で、URLリクエストと連携する点に懸念があります。

この脆弱性を利用して、ハッカーはクッキーから重要な情報を盗むことが可能です。熟練のハッカーは、永続性・非永続性、安全・不安全といったあらゆる種類のクッキーを用いて、クッキーを利用したパラメータ改ざん攻撃を行います。

多くの方は非永続性クッキーは変更できないと思われがちですが、Winhexなどのツールにより変更が容易になるため、これは誤解です。また、SSL保護はクッキーの転送中のみ有効で、その後は保護されません。

主に、クッキーの改ざんは配列やユーザー認証に不可欠なセッショントークンに対して行われます。多くのクッキーが旧式のBase64エンコード方式で管理され、暗号保護が施されていないため、攻撃者にとって改ざんは容易です。

対策 

クッキーの改ざんが容易であっても、適切で強固な対策を実施することでリスクは大幅に低減されます。有効な対策の一つは、1つのセッショントークンを用いる方法です。

このセッショントークンは、サーバ側キャッシュに保管された参照プロパティと連携させ、転送中のデータが正常な状態を維持し、安定したリソースとして返されるようにします。

クッキーを利用した設定を行う際、ウェブアプリがユーザー情報に注意を払うようにすることも重要です。そのため、アプリはユーザーIDと対応するセッションテーブルを確認する必要があります。

また、クッキー内に不正またはありえない値が含まれていないかを検出するため、侵入検知フックを活用することも効果的です。

最後に、初期段階での改ざんを防ぐため、クッキーの暗号化が重要です。ここで疑問となるのは、クッキーをどのように暗号化するかという点です。

クッキーのハッシュ化、対称暗号化、到着時のハッシュ比較などの手法で実現可能です。

HTMLフォームフィールド

HTMLフォームフィールドは、ウェブアプリ利用者が何らかの選択をする際に生成されるHTMLページの一部です。この選択はフォームフィールドの値として保存され、HTTPリクエストの形でウェブアプリへ送信されます。

主にGETやPOSTリクエストで使用され、HTMLフォームフィールドに加え、非表示フィールドとして値を保持することもあります。非表示フィールドはブラウザに表示されず、送信時にパラメータとして収集されます。

種類にかかわらず、すべてのHTMLフォームフィールドは利用者側で操作可能です。利用者は任意の値を入力し、HTMLリクエストの処理を制御できます。よく見られる操作として、HTMLの編集、ソースの表示、保存などがあります。

例を見てみましょう。

例えば、ユーザー名とパスワードを送信する基本的なフォームを備えたウェブアプリがあるとします。アプリはHTTPリクエストを使用し、SSL暗号化で保護されています。フロントエンドには、本人確認のために「Username」と「Password」という2つのフィールドが設けられています。

アプリや開発者が長いユーザー名やパスワードの入力を避けたい場合、これらの最大文字数を事前に設定することで、長いパラメータによるバッファオーバーフローの挿入も防止できます。

しかし、熟練のハッカーはこの制限を回避する方法を見出す可能性があります。ページを保存し、最大長のタグを削除した上で、プライベートブラウザから再度アクセスすれば、HTMLフォームフィールドのパラメータ改ざんが可能です。

改ざんによく利用されるフォームフィールドパラメータには、value、read-only、disabled などがあります。

開発者にとって、非表示フォームフィールドはブラウザ内の簡易なデータ保管手段として機能し、ウィザード形式のアプリでデータ転送に広く使用されます。

対策

HTMLフォームフィールドの危険性は多岐にわたるため、適切な対策が求められます。まず、非表示フォームフィールドを1つのセッショントークンに置き換える方法が広く用いられています。

非表示フィールドは目に見えないため、改ざんがあっても発見が困難ですが、そのため対応が遅れる恐れがあります。

次の対策として、フォーム内の非表示フィールドに含まれるname/valueペアを1つの文字列に統合する方法があります。あまり知られていませんが、公に現れることのないシークレットキー、いわゆる Outgoing Form Message を追加の非表示フィールドとして組み込むことが可能です。

フォームが Outgoing Form Message を含む形で提出されると、受信したname/valueペアはシークレットキー付きの Incoming Form Message として統合され、その後、自動的にMD5ダイジェストが計算されます。

Incoming Form Digest と Outgoing Form Digest が収集され、慎重に比較されます。値が一致しなければ、非表示フィールドが改ざんされたことが確実です。

ただし、このプロセスの正確性を維持するため、Outgoing Form Message と Incoming Form Message のname/valueペアは同じ順序と形式で連携される必要があります。

この対策は、HTMLフォームフィールドの改ざんだけでなく、URLの改ざん対策にも有効です。

‍

パラメータ改ざんの脆弱性を防ぐには？

ウェブやAPIで適切に対処しなければ、大きな被害を引き起こす恐れがあります。そのため、APIセキュリティの専門家は、早期かつ有効なパラメータ改ざん対策の実施を推奨しています。ここでは、貴社にとって有用な対策を紹介します:

• クライアント側およびサーバ側の入力にホワイトリスト形式を使用する - 事前に定義・承認された内容と一致する場合にのみ、リクエストや入力を許可する標準的な方法です。
• A Firewall - 入出力トラフィックを制御し、セキュリティリスクを低減するための効果的な手法です。機能豊富なクラウドWAFを利用することで、どのエコシステムにあるAPIやマイクロサービスにも対応できます。
• Encryption - ユーザーセッションクッキーに対して使用することで、改ざんの可能性を低く抑えることが可能です。
• No Explicit Passing - 前述の通り、クライアント側のクッキーは主要なセキュリティ判断に含めるべきではありません。クエリ文字列以外のパラメータは、改ざんのリスクが低くなります。

締めの言葉

デジタルソリューションのセキュリティは、すべての開発者にとって最優先事項です。ウェブやAPIにおけるパラメータ改ざんの対策は、暗号化の利用、クライアント側クッキーの取り扱いの見直し、そして効果的なクラウドWAFの利用など、堅実なセキュリティ対策の一環として実施すべきです。