mirror of https://github.com/carlospolop/hacktricks synced 2024-11-25 14:10:41 +00:00

History

Translator d20ceb0354 Translated ['forensics/basic-forensic-methodology/partitions-file-system		2024-03-26 15:55:19 +00:00
..
cookie-bomb.md	Translated ['mobile-pentesting/ios-pentesting/ios-protocol-handlers.md',	2024-02-09 08:23:12 +00:00
cookie-jar-overflow.md	Translated ['mobile-pentesting/ios-pentesting/ios-protocol-handlers.md',	2024-02-09 08:23:12 +00:00
cookie-tossing.md	Translated ['README.md', 'backdoors/salseo.md', 'cryptography/certificat	2024-03-17 16:50:32 +00:00
README.md	Translated ['forensics/basic-forensic-methodology/partitions-file-system	2024-03-26 15:55:19 +00:00

README.md

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を提出する。

Try Hard Security Group

{% embed url="https://discord.gg/tryhardsecurity" %}

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

Expires および Max-Age

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

Domain

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

Path

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

順序付けルール

同じ名前の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/).
この変更を適用した後、Chrome では、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/ にあります）。
このバイパスは、サーバーからの応答（この HTTP メソッドが利用可能な場合）が送信される TRACE HTTP リクエストを使用することで回避できます。この技術は Cross-Site Tracking と呼ばれます。
この技術は、現代のブラウザが JS から TRACE リクエストの送信を許可しないことによって回避されます。ただし、IE6.0 SP2 などの特定のソフトウェアで \r\nTRACE を TRACE の代わりに送信するなど、これに対するいくつかのバイパスが見つかっています。
もう1つの方法は、ブラウザのゼロデイ脆弱性を悪用することです。
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- プレフィックスを使用することは、セキュリティと分離を向上させるための良い慣行と考えられます。

Cookieの上書き

したがって、__Host-接頭辞のCookieの保護の1つは、サブドメインからの上書きを防ぐことです。たとえば、Cookie Tossing attacksを防ぎます。Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper)というトークでは、例えば、パーサーをだまして、サブドメインから__HOST-接頭辞のCookieを設定することが可能であることが示されています。たとえば、先頭に"="を追加したり、先頭と末尾に"="を追加したり...:

または、PHPでは、Cookie名の先頭に他の文字を追加することが可能で、それらはアンダースコア文字に置き換えられることで、__HOST- Cookieを上書きすることが可能でした:

Cookie攻撃

カスタム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";

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

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

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

追加の脆弱なクッキーチェック

基本的なチェック

クッキーはログインごとに同じです。
ログアウトして同じクッキーを使用してみてください。
同じクッキーを使用して同じアカウントに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としてヌルベクトルを使用することが推奨されているため、この種の整合性チェックは脆弱になる可能性があります。

攻撃

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

ECB

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

検出方法と攻撃方法:

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

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

パターンがあるはずです（使用されるブロックのサイズで）。したがって、「a」の暗号化されたブロックのサイズ +「admin」を持つユーザー名を作成できます。その後、クッキーから「a」のブロックの暗号化されたパターンを削除できます。そして、ユーザー名「admin」のクッキーを取得できます。

参考文献