Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 14:40:37 +00:00

Translator 9e88c7b712 Translated ['forensics/basic-forensic-methodology/specific-software-file

2024-02-05 20:22:21 +00:00

22 KiB

Raw Blame History

Cookiesハッキング

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

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

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

最も重要な脆弱性を見つけて修正を迅速化します。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/).
この変更を適用した後、ChromeではSameSiteポリシーのないCookieは最初の2分間はNoneとして扱われ、その後はトップレベルのクロスサイトPOSTリクエストではLaxとして扱われます。

Cookieフラグ

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メソッドが利用可能な場合）。この技術はクロスサイトトラッキングと呼ばれます。
この技術は、一部の特定のソフトウェアで\r\nTRACEをTRACEの代わりにIE6.0 SP2に送信するなど、特定のソフトウェアでこのバイパスを見つけることができます。
もう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を送信します。

Cookieプレフィックス

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

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

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

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

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-クッキーについても懸念があり、クッキーがスプーフィングに対して脆弱なバックエンドサーバーに渡されると認可バイパスが発生する可能性があります。

Extra Vulnerable Cookies Checks

Basic checks

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

Advanced cookies attacks

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

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

Padding Oracle - Padbuster examples

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」のクッキーを取得できます。

参考文献

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