Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-25 14:10:41 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/hacking-with-cookies
History
Translator 040ecbaea4 Translated ['README.md', 'forensics/basic-forensic-methodology/partition
2024-03-09 13:20:56 +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 ['mobile-pentesting/ios-pentesting/ios-protocol-handlers.md', 2024-02-09 08:23:12 +00:00
README.md Translated ['README.md', 'forensics/basic-forensic-methodology/partition 2024-03-09 13:20:56 +00:00

README.md

Cookies ハッキング

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

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

Cookie 属性

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

Expires と Max-Age

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

Domain

Cookie を受け取るホストは Domain 属性で指定されます。デフォルトでは、これは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/にあります）。
  • このバイパスは、サーバーからの応答としてTRACE HTTPリクエストを送信することでバイパスできます（このHTTPメソッドが利用可能な場合）。この技術はCross-Site Trackingと呼ばれます。
  • この技術は、現代のブラウザがJSからTRACEリクエストの送信を許可しないことで回避されます。ただし、IE6.0 SP2には、TRACEの代わりに\r\nTRACEを送信するなど、この問題を回避する方法が見つかっています。
  • もう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- プレフィックスを使用することは、セキュリティと分離を向上させるための良い慣行と考えられます。

Cookies Attacks

Cookieの攻撃

カスタムCookieに機密データが含まれている場合は、そのCookieをチェックしてください（特にCTFをプレイしている場合）。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

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

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

基本的なチェック

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

高度なクッキー攻撃

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

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

パディングオラクル - 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" というユーザー名を作成できます。その後、クッキーからブロックの "a" の暗号化されたパターンを削除することができます。そして、ユーザー名 "admin" のクッキーを取得できます。

参考文献

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

Other ways to support HackTricks: