hacktricks/pentesting-web/hacking-with-cookies

Cookies ハッキング

htARTE（HackTricks AWS Red Team Expert） を通じて、ゼロからヒーローまでAWSハッキングを学ぶ！

HackTricks をサポートする他の方法:

• HackTricks で企業を宣伝したい場合や HackTricks をPDFでダウンロードしたい場合は、SUBSCRIPTION PLANS をチェックしてください！

• 公式PEASS＆HackTricksスワッグを入手

• The PEASS Familyを発見し、独占的な NFTsのコレクションを見つける

• 💬 Discord グループ に参加するか、telegram グループに参加するか、Twitter 🐦 @carlospolopmをフォローする。

• HackTricks と HackTricks Cloud の GitHub リポジトリに PR を提出して、あなたのハッキングテクニックを共有してください。

最も重要な脆弱性を見つけて、迅速に修正できるようにしましょう。Intruder はあなたの攻撃面を追跡し、積極的な脅威スキャンを実行し、API から Web アプリケーション、クラウドシステムまでの問題を見つけます。無料でお試しください 今すぐ。

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

---

Cookie 属性

Cookie には、ユーザーのブラウザでの動作を制御するいくつかの属性が付属しています。以下はこれらの属性についての説明です（より受動的な声で）:

有効期限と Max-Age

Cookie の有効期限は Expires 属性によって決定されます。逆に、Max-age 属性は、Cookie が削除されるまでの秒数を定義します。より現代的な手法を反映するために Max-age を選択してください。

ドメイン

Cookie を受け取るホストは Domain 属性で指定されます。デフォルトでは、これは Cookie を発行したホストに設定されており、そのサブドメインは含まれません。ただし、Domain 属性が明示的に設定されている場合、サブドメインも含まれます。これにより、Domain 属性の指定は、サブドメイン間での Cookie 共有が必要なシナリオに役立つより制限の少ないオプションとなります。たとえば、Domain=mozilla.org を設定すると、developer.mozilla.org のようなサブドメインで Cookie にアクセスできます。

パス

要求された URL に存在する必要がある特定の URL パスを示すのが Path 属性です。この属性は / 文字をディレクトリセパレータとして考慮し、サブディレクトリでも一致させることができます。

順序付けルール

同じ名前の 2 つの Cookie がある場合、送信する Cookie は次の基準に基づいて選択されます:

• 要求された URL で最も長いパスに一致する Cookie。
• パスが同じ場合は、最も最近に設定された Cookie。

SameSite

• SameSite 属性は、サードパーティドメインからのリクエストで Cookie が送信されるかどうかを指示します。3 つの設定が提供されます:
• Strict: サードパーティリクエストで Cookie の送信を制限します。
• Lax: サードパーティウェブサイトによって開始された GET リクエストで Cookie の送信を許可します。
• None: 任意のサードパーティドメインから Cookie の送信を許可します。

Cookie を構成する際には、これらの属性を理解することで、さまざまなシナリオで期待どおりに動作することを確認できます。

リクエストタイプ	例のコード	Cookie が送信される場合
リンク	<a href="..."></a>	NotSet*, Lax, None
プリレンダー	<link rel="prerender" href=".."/>	NotSet*, Lax, None
フォーム GET	<form method="GET" action="...">	NotSet*, Lax, None
フォーム POST	<form method="POST" action="...">	NotSet*, None
iframe	<iframe src="..."></iframe>	NotSet*, None
AJAX	$.get("...")	NotSet*, None
画像	<img src="...">	NetSet*, None

Invicti からの表を若干修正しています。
SameSite 属性を持つ Cookie は、ログインセッションが必要な CSRF 攻撃を緩和します。

*Chrome80（2019年2月）以降、SameSite 属性のない Cookie のデフォルト動作は Lax になります (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/).
この変更を適用した後、SameSite ポリシーのない Cookie は、最初の 2 分間は None として扱われ、その後はトップレベルのクロスサイト POST リクエストでは Lax として扱われます。

Cookies フラグ

HttpOnly

これにより、クライアントが Cookie にアクセスできなくなります（例: document.cookie を介した JavaScript など）。

バイパス

• ページがリクエストの応答として Cookie を送信している場合（たとえば PHPinfo ページなど）、XSS を悪用してこのページにリクエストを送信し、応答から Cookie を盗むことが可能です（https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/ で例を確認してください）。
• このバイパスは、サーバーからの応答として TRACE HTTP リクエストを送信することで回避できます（この HTTP メソッドが利用可能な場合）。この技術は Cross-Site Tracking と呼ばれます。
• この技術は、一部の特定のソフトウェアで \r\nTRACE を TRACE の代わりに IE6.0 SP2 に送信するなど、特定のソフトウェアで見つかったバイパスによって、現代のブラウザによって回避されます。
• もう一つの方法は、ブラウザのゼロデイ脆弱性を悪用することです。
• Cookie Jar オーバーフローアタックを実行することで、HttpOnly Cookie を上書きすることが可能です:

{% content-ref url="cookie-jar-overflow.md" %} cookie-jar-overflow.md {% endcontent-ref %}

• Cookie Smuggling 攻撃を使用してこれらの Cookie を外部に持ち出すことが可能です

Secure

リクエストは、通常 HTTPS を介して送信される場合にのみ、HTTP リクエストで Cookie を送信します。

Cookies プレフィックス

__Secure- で始まる Cookie は、HTTPS で保護されたページから設定する必要があります。

__Host- で始まる Cookie には、いくつかの条件があります:

• secure フラグで設定する必要があります。
• HTTPS で保護されたページから発信する必要があります。
• ドメインを指定することは禁止されており、サブドメインに送信されることを防ぎます。
• これらの Cookie のパスは / に設定する必要があります。

__Host- で始まる Cookie は、スーパードメインやサブドメインに送信することが許可されていません。この制限は、アプリケーションの Cookie を分離するのに役立ちます。したがって、すべてのアプリケーション Cookie に __Host- プレフィックスを使用することは、セキュリティと分離を向上させるための良い慣行と考えられます。

Cookies 攻撃

カスタム Cookie に機密データが含まれている場合は、それを確認してください（特に CTF をプレイしている場合）。それは脆弱性を持つ可能性があります。

Cookie のデコードと操作

Cookie に埋め込まれた機密データは常に検討すべきです。Base64 や類似の形式でエンコードされた Cookie は、しばしばデコードできます。この脆弱性により、攻撃者は Cookie の内容を変更し、変更されたデータを Cookie にエンコードして他のユーザーをなりすますことができます。

セッションハイジャック

この攻撃は、ユーザーの Cookie を盗んで、アプリケーション内のアカウントに不正アクセスを取得することを含みます。盗まれた Cookie を使用することで、攻撃者は合法的なユーザーをなりすることができます。

セッションフィクセーション

このシナリオでは、攻撃者は被害者に特定の Cookie を使用してログインさせます。アプリケーションがログイン時に新しい Cookie を割り当てない場合、元の Cookie を持っている攻撃者は被害者をなりすることができます。この技術は、被害者が攻撃者から提供された Cookie を使用してログインすることに依存しています。

サブドメインで XSS を見つけた場合 または サブドメインを制御している場合、次のリンクを参照してください:

{% content-ref url="cookie-tossing.md" %} cookie-tossing.md {% endcontent-ref %}

セッション寄付

ここでは、攻撃者が被害者に攻撃者のセッション Cookie を使用するように説得します。被害者は、自分のアカウントにログインしていると信じている間、実際には攻撃者のアカウントで操作を行うことになります。

サブドメインで XSS を見つけた場合 または サブドメインを制御している場合、次のリンクを参照してください:

{% content-ref url="cookie-tossing.md" %} cookie-tossing.md {% endcontent-ref %}

JWT Cookies

JWT に関する可能性のある欠陥について説明したページにアクセスするには、前述のリンクをクリックしてください。

Cookie で使用される JSON Web Tokens (JWT) には、脆弱性が存在する可能性があります。JWT のハッキングに関する詳細情報については、リンクされた JWT ハッキングのドキュメントにアクセスしてください。

クロスサイトリクエストフォージェリ（CSRF）

この攻撃は、現在認証されている Web アプリケーションでログインしているユーザーに、望ましくないアクションを実行させることを強制します。攻撃者は、脆弱なサイトに送信されるすべてのリクエストと共に送信される Cookie を悪用することができます。

空の Cookie

（元の研究で詳細を確認してください） ブラウザは、名前のない Cookie を作成することを許可しており、JavaScript を使用して次のように示すことができます:

document.cookie = "a=v1"
document.cookie = "=test value;" // Setting an empty named cookie
document.cookie = "b=v2"

以下は送信されたCookieヘッダーの結果です：a=v1; test value; b=v2;。興味深いことに、空の名前Cookieが設定されると、他のCookieを制御する可能性があります。特定の値に空のCookieを設定することで、他のCookieを操作できます。

function setCookie(name, value) {
document.cookie = `${name}=${value}`;
}

setCookie("", "a=b"); // Setting the empty cookie modifies another cookie's value

これにより、ブラウザはaという名前のクッキーと値bを持つクッキーとして解釈されるクッキーヘッダを送信します。

Chromeのバグ：Unicodeサロゲートコードポイントの問題

Chromeでは、設定されたクッキーにUnicodeサロゲートコードポイントが含まれている場合、document.cookieが破損し、その後空の文字列が返されます。

document.cookie = "\ud800=meep";

これにより、document.cookie が空の文字列を出力し、永続的な破損を示します。

解析の問題によるCookieスマグリング

（詳細はオリジナルリサーチを参照してください） Java（Jetty、TomCat、Undertow）やPython（Zope、cherrypy、web.py、aiohttp、bottle、webob）など、いくつかのWebサーバーは、古いRFC2965サポートのためにCookie文字列を誤って処理します。これらのサーバーは、セミコロンを含む場合でも、ダブルクォートで囲まれたCookie値を通常はキーと値のペアを区切るはずのセミコロンとして読み取ります。

RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";

Cookie Injection Vulnerabilities

(詳細は元の研究を参照してください) サーバーによるクッキーの誤った解析、特にUndertow、Zope、Pythonのhttp.cookie.SimpleCookieおよびhttp.cookie.BaseCookieを使用するサーバーは、クッキーインジェクション攻撃の機会を作成します。これらのサーバーは新しいクッキーの開始を適切に区切らず、攻撃者がクッキーを偽装することを可能にします：

• Undertowは、セミコロンなしで引用された値の直後に新しいクッキーを期待します。
• Zopeは、次のクッキーの解析を開始するためにコンマを探します。
• Pythonのクッキークラスは、スペース文字で解析を開始します。

この脆弱性は、クッキーをベースとしたCSRF保護に依存するWebアプリケーションにおいて特に危険であり、攻撃者がスプーフィングされたCSRFトークンクッキーを注入し、セキュリティ対策を迂回する可能性があります。この問題は、Pythonが重複するクッキー名の処理によって悪化し、最後の出現が以前のものを上書きする点に関して懸念があります。また、安全でないコンテキストでの__Secure-および__Host-クッキーについても懸念があり、クッキーがスプーフィングに対して脆弱なバックエンドサーバーに渡されると認可バイパスが発生する可能性があります。

Extra Vulnerable Cookies Checks

基本的なチェック

• クッキーはログインごとに同じです。
• ログアウトして同じクッキーを使用してみてください。
• 同じクッキーを使用して同じアカウントに2つのデバイス（またはブラウザ）でログインしようとしてみてください。
• クッキーに情報が含まれているかどうかを確認し、それを変更してみてください。
• ほぼ同じユーザー名で複数のアカウントを作成し、類似点が見られるかどうかを確認してください。
• 存在する場合は「remember me」オプションを確認して、その動作を確認してください。存在し、脆弱性がある場合は、常に他のクッキーなしで「remember me」のクッキーを使用してください。
• パスワードを変更した後も以前のクッキーが機能するかどうかを確認してください。

高度なクッキー攻撃

ログイン時にクッキーが同じ（またはほぼ同じ）ままである場合、おそらくクッキーはアカウントのいくつかのフィールドに関連していることを意味します（おそらくユーザー名）。その場合は次のようにできます：

• 非常に類似したユーザー名で多くのアカウントを作成し、アルゴリズムがどのように機能しているかを推測してみてください。
• ユーザー名をブルートフォースしてみてください。クッキーがユーザー名の認証方法としてのみ保存されている場合、ユーザー名が「Bmin」のアカウントを作成し、クッキーの各ビットをブルートフォースしてみてください。その中には「admin」に属するクッキーの1つが含まれる可能性があります。
• Padding Oracleを試してみてください（クッキーの内容を復号化できます）。padbusterを使用してください。

Padding Oracle - Padbusterの例

padbuster <URL/path/when/successfully/login/with/cookie> <COOKIE> <PAD[8-16]>
# When cookies and regular Base64
padbuster http://web.com/index.php u7bvLewln6PJPSAbMb5pFfnCHSEd6olf 8 -cookies auth=u7bvLewln6PJPSAbMb5pFfnCHSEd6olf

# If Base64 urlsafe or hex-lowercase or hex-uppercase --encoding parameter is needed, for example:
padBuster http://web.com/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6
7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 8 -encoding 2

Padbusterは複数の試行を行い、どれがエラー条件であるか（有効ではない条件）を尋ねます。

その後、クッキーの復号化を開始します（数分かかる場合があります）。

攻撃が成功した場合、任意の文字列を暗号化してみることができます。たとえば、user=administratorを暗号化したい場合

padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator

この実行では、文字列user=administratorが含まれたクッキーが正しく暗号化およびエンコードされます。

CBC-MAC

クッキーには値が含まれ、CBCを使用して署名される可能性があります。その後、値の整合性は、同じ値を使用してCBCを使用して作成された署名です。 IVとしてヌルベクトルを使用することが推奨されているため、この種の整合性チェックは脆弱になる可能性があります。

攻撃

1. ユーザー名administの署名を取得します = t
2. ユーザー名rator\x00\x00\x00 XOR tの署名を取得します = t'
3. クッキーに値**administrator+t'**を設定します（t'は（rator\x00\x00\x00 XOR t）XOR tの有効な署名になります = rator\x00\x00\x00

ECB

クッキーがECBを使用して暗号化されている場合、脆弱になる可能性があります。
ログインするときに受け取るクッキーは常に同じでなければなりません。

検出方法と攻撃方法:

ほぼ同じデータ（ユーザー名、パスワード、メールなど）を持つ2つのユーザーを作成し、与えられたクッキーの中にパターンを見つけようとします

例えば「aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa」という名前のユーザーを作成し、クッキーにパターンがあるかどうかを確認します（ECBは同じ鍵でブロックごとに暗号化するため、ユーザー名が暗号化されると同じ暗号化されたバイトが現れる可能性があります）。

パターンがあるはずです（使用されるブロックのサイズで）。したがって、一連の「a」がどのように暗号化されるかを知っている場合、ユーザー名を作成できます: "a"*(ブロックのサイズ)+"admin"。その後、クッキーから1つのブロックの「a」の暗号化されたパターンを削除できます。そして、ユーザー名「admin」のクッキーを取得できます。

参考文献

• https://blog.ankursundara.com/cookie-bugs/
• https://www.linkedin.com/posts/rickey-martin-24533653_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd

最も重要な脆弱性を見つけて、より速く修正できるようにします。Intruderは攻撃対象を追跡し、積極的な脅威スキャンを実行し、APIからWebアプリケーション、クラウドシステムまで、技術スタック全体で問題を見つけます。無料でお試しください 今すぐ。

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

**htARTE（HackTricks AWS Red Team Expert）**で**ゼロからヒーローまでのAWSハッキング**を学びましょう！

HackTricksをサポートする他の方法：

• HackTricksで企業を宣伝したい場合やHackTricksをPDFでダウンロードしたい場合は、SUBSCRIPTION PLANSをチェックしてください！
• 公式PEASS＆HackTricksのグッズを入手する
• The PEASS Familyを発見し、独占的なNFTsコレクションを入手する
• 💬 Discordグループまたはtelegramグループに参加するか、Twitter 🐦 @carlospolopmをフォローする
• HackTricksとHackTricks CloudのGitHubリポジトリにPRを提出して、自分のハッキングトリックを共有する