mirror of https://github.com/carlospolop/hacktricks synced 2025-02-17 22:48:32 +00:00

History

Translator e8bd413fdd Translated ['pentesting-web/deserialization/nodejs-proto-prototype-pollu		2024-01-01 19:09:41 +00:00
..
cookie-bomb.md	Translated to Japanese	2023-07-07 23:42:27 +00:00
cookie-jar-overflow.md	Translated to Japanese	2023-07-07 23:42:27 +00:00
cookie-tossing.md	Translated to Japanese	2023-07-07 23:42:27 +00:00
README.md	Translated ['pentesting-web/deserialization/nodejs-proto-prototype-pollu	2024-01-01 19:09:41 +00:00

README.md

クッキーのハッキング

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

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

HackTricksにあなたの会社を広告したい、またはHackTricksをPDFでダウンロードしたい場合は、サブスクリプションプランをチェックしてください！
公式のPEASS & HackTricksグッズを入手する
The PEASS Familyを発見する、私たちの独占的なNFTsのコレクション
💬 Discordグループに参加するか、テレグラムグループに参加するか、Twitter 🐦 @carlospolopmをフォローする。
HackTricksのGitHubリポジトリとHackTricks CloudにPRを提出して、あなたのハッキングのコツを共有する。

最も重要な脆弱性を見つけて、より早く修正します。Intruderは攻撃面を追跡し、積極的な脅威スキャンを実行し、APIからウェブアプリ、クラウドシステムまで、テクノロジースタック全体にわたる問題を見つけます。今日無料で試す。

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

クッキーの属性

Expires & Max-Age

Expiresはクッキーが削除される有効期限を設定します
Max-ageはクッキーが削除されるまでの秒数を設定します (これを使用してください、もう2009年ではありません)

Domain

Domain属性はどのホストがクッキーを受け取ることができるかを指定します。指定されていない場合、属性はデフォルトでクッキーを設定した同じホストになりますが、サブドメインは除外されます。Domainが指定されている場合、サブドメインは常に含まれます。したがって、Domainを指定することはそれを省略するよりも制限が少なくなります。しかし、サブドメインがユーザーに関する情報を共有する必要がある場合に役立ちます。

例えば、Domain=mozilla.orgを設定すると、developer.mozilla.orgのようなサブドメインでクッキーが利用可能になります。しかし、設定しない場合、クッキーはサブドメインに送信されません。

サブドメイン sub.example.comがドメイン属性を**.example.comで設定したクッキーは、親ドメインへのリクエストで送信されます**。

Path

Path属性は、Cookieヘッダーを送信するためにリクエストされたURLに存在する必要があるURLパスを示します。%x2F ("/")文字はディレクトリセパレータと見なされ、サブディレクトリも一致します。

順序

2つのクッキーが同じ名前を持っている場合、送信されるのは：

URLパスに一致する最長のパスを持つもの
同じパスを持つ場合は、最新のもの

SameSite

これは、クッキーが他のドメインから送信されるかどうかをブラウザに指示します。3つの可能な値があります：

Strict: クッキーは第三者のウェブサイトによるリクエストと共に送信されません。
Lax: クッキーは第三者のウェブサイトによって開始されたGETリクエストと共に送信されます。
None: クッキーは任意の第三者ドメインから送信されます

リクエストタイプ	例コード	クッキーが送信される時
リンク	<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 属性を持つクッキーは、ログインセッションが必要なCSRF攻撃を緩和します。

*Chrome80（2019年2月）から、SameSite属性のないクッキーのデフォルトの挙動はlaxになることに注意してください (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/)。
この変更を適用した後、一時的にChromeでSameSiteポリシーのないクッキーは、最初の2分間はNoneとして扱われ、その後トップレベルのクロスサイトPOSTリクエストに対してLaxとして扱われます。

クッキーのフラグ

HttpOnly

これにより、クライアントがクッキーにアクセスするのを防ぎます（例えば、document.cookieを介してJavascriptで）。

バイパス

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

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

Cookie Smuggling攻撃を使用してこれらのクッキーを流出させることが可能です

Secure

リクエストは、リクエストが安全なチャネル（通常はHTTPS）を介して送信される場合にのみ、HTTPリクエストでクッキーを送信します。

クッキーのプレフィックス

__Secure- プレフィックス: 安全なページ（HTTPS）からsecureフラグを設定する必要があります。

__Host- プレフィックス: secureフラグを設定する必要があり、安全なページ（HTTPS）からでなければならず、ドメインが指定されていない（したがって、サブドメインには送信されない）こと、そしてパスは/でなければなりません。

__Host-プレフィックス付きのクッキーは、スーパードメイン（サブドメインからドメインへのクッキー）またはサブドメイン（ドメインからサブドメインへのクッキー）に送信することはできません。したがって、アプリケーションのクッキーを隔離したい場合、すべてに__Host-をプレフィックスとして付けるのは悪い考えではありません。

クッキーの攻撃

何らかのカスタムクッキー（sessionID、ユーザー名、メールアドレスなど）が含まれている場合、それを確実に悪用しようと試みるべきです

クッキーのデコード

クッキーが何らかのBaseエンコーディング（Base64など）または類似のものを使用している場合、それをデコードし、内容を変更し、任意のユーザーになりすますことができるかもしれません。

セッションハイジャック

クッキーを盗んで、アプリケーション内でユーザーになりすます

セッション固定

攻撃者はウェブページからクッキーを取得し、被害者に同じクッキーを使用してログインするためのリンクを送ります。ユーザーがログインするときにクッキーが変更されない場合、攻撃者はクッキーを通じてユーザーになりすますことができるかもしれません。

サブドメインでXSSを見つけた場合、またはサブドメインを制御している場合、以下を読んでください：

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

セッション寄付

攻撃者は自分のセッションを被害者に送ります。被害者はすでにログインしていることに気づき、自分のアカウント内にいると思いますが、行動は攻撃者のアカウント内で行われます。

サブドメインでXSSを見つけた場合、またはサブドメインを制御している場合、以下を読んでください：

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

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

空のクッキー

ブラウザは空の名前のクッキーを許可します

document.cookie = "a=v1"
document.cookie = "=test value;" // empty name
document.cookie = "b=v2"

送信されたクッキーヘッダーは以下の結果となります：

a=v1; test value; b=v2;

より興味深いことに、何らかの方法で空のクッキーを設定するベクターを持っている場合、他の任意のクッキーを制御できます：

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

setCookie("", "a=b"); // this sets the empty cookie to a=b

ブラウザ内部では空の名前のクッキーとして設定されますが、これにより送信されるクッキーヘッダーが生成されます：

a=b;

意味するところは、すべてのウェブサーバーが、クッキーaが値bに設定されていると解析するということです。

Chromeのバグ - `document.cookie`の破損

もしユニコードのサロゲートコードポイントがセットされたクッキーに含まれている場合、document.cookieは永続的に破損し、空の文字列を返すようになります。

document.cookie
// "a=b;"
document.cookie = "\ud800=meep";
document.cookie
// ""

いくつかのウェブサーバー、JavaウェブサーバーのJetty、TomCat、Undertow、PythonウェブフレームワークのZope、そしてPythonウェブサーバー/フレームワークのcherrypy、web.py、aiohttp server、bottle、webobは、クッキー文字列を誤って解析することがわかっています。これは、古いクッキー引用メカニズムであるRFC2965の残存サポートによるもので、引用文字列の定義にRFC2616を使用しています。

具体的には、これらのサーバーは、セミコロンに遭遇しても、二重引用符（dquoted）で囲まれたクッキー値を読み続けます。これは問題です。なぜなら、セミコロンはクッキー文字列内のキーと値のペアを分けるために使われるべきだからです。

例えば、ブラウザが3つのクッキー、RENDER_TEXT、JSESSIONID、そしてASDFを送信した場合：

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

これらのサーバーは、それらを単一のクッキー値として解釈し、3つの別々のクッキーではなく。

これによりセキュリティリスクが発生します：攻撃者がクロスサイトスクリプティング（XSS）アクセスを得た場合、このバグを使用してHttpOnlyクッキーなどの機密クッキーを抜き取ることができます。

クッキーインジェクション

JavaのUndertow、PythonのZope、およびPythonのstdlib http.cookie.SimpleCookieおよびhttp.cookie.BaseCookieを使用するサーバーは、誤ってクッキーを解析し、次のクッキー名/値ペアを開始するために間違った区切り文字を使用していることがわかっています。これにより、攻撃者は1つのクッキー値のみを制御しながら複数のクッキーを偽装することができます。

Undertowの場合、クォートされたクッキー値の終わりの後すぐに次のクッキーの解析を開始し、セミコロンを待たずに：

LANGUAGE="en-us" CSRF_TOKEN="SPOOFED_VALUE"

Zope は次のクッキーをカンマで解析し始めます：

LANGUAGE=en-us,CSRF_TOKEN=SPOOFED_VALUE

And Python's SimpleCookie と BaseCookie は、スペース 文字で次のクッキーの解析をすぐに開始します：

LANGUAGE=en-us CSRF_TOKEN=SPOOFED_VALUE

以下は、攻撃技術に関するハッキングの本の内容です。関連する英語テキストを日本語に翻訳し、同じマークダウンおよびhtml構文を保持して翻訳を返してください。コード、攻撃技術名、ハッキング用語、クラウド/SaaSプラットフォーム名（Workspace、aws、gcpなど）、'leak'という単語、ペネトレーションテスト、およびマークダウンタグなどの翻訳は行わないでください。また、翻訳とマークダウン構文以外の余分なものは追加しないでください。

その結果、cherrypy、web.py、aiohttp サーバー、bottle、webob（Pyramid、TurboGears）は、このタイプの攻撃に対して脆弱です。

この問題は重大なセキュリティ上の影響をもたらします。例えば、WebアプリケーションがクッキーベースのCSRF保護を使用している場合、攻撃者は偽造されたCSRFトークンクッキーを注入してこの保護をバイパスすることができます。さらに、Pythonのhttp.cookieパッケージでは、最後の重複するクッキー名が以前のものを上書きするため、このタイプの攻撃は特に容易です。

さらに、__Secure- および __Host- クッキーのスプーフィングは、安全でないコンテキストで悪用される可能性があります。また、クッキーがバックエンドサーバーに渡される設定では、バックエンドサーバーがスプーフィングに対して脆弱であるがフロントエンドサーバーがそうでない場合、クッキー注入により認証バイパスが発生する可能性があります。

特に脆弱なクッキーチェック

基本的なチェック

ログインするたびにクッキーが同じである。
ログアウトして、同じクッキーを使用してみる。
同じアカウントに2台のデバイス（またはブラウザ）で同じクッキーを使用してログインしてみる。
クッキーに情報が含まれているか確認し、変更してみる。
ほぼ同じユーザー名で複数のアカウントを作成し、類似点が見られるかチェックする。
"私を覚えておいて" オプションが存在する場合は、それがどのように機能するかを確認する。存在し、脆弱である可能性がある場合は、他のクッキーを使用せずに私を覚えておいてのクッキーを常に使用する。
パスワードを変更した後でも以前のクッキーが機能するか確認する。

高度なクッキー攻撃

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

非常に似ているユーザー名で多くのアカウントを作成し、アルゴリズムがどのように機能しているかを推測してみる。
ユーザー名をブルートフォースする。クッキーがユーザー名の認証方法としてのみ保存されている場合、ユーザー名 "Bmin" のアカウントを作成し、クッキーの各ビットをブルートフォースすることができます。なぜなら、試したクッキーの中には "admin" に属するものがあるからです。
パディング オラクルを試す（クッキーの内容を復号化できます）。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としてヌルベクトルを使用することが推奨されているため、このタイプの完全性チェックは脆弱になる可能性があります。

攻撃

ユーザー名 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" がどのように暗号化されるかを知っていれば、ユーザー名を "a"*(ブロックのサイズ)+"admin" として作成できます。その後、クッキーから "a" のブロックの暗号化されたパターンを削除できます。そして、ユーザー名 "admin" のクッキーを手に入れることができます。

参考文献

https://blog.ankursundara.com/cookie-bugs/

最も重要な脆弱性を見つけて、より早く修正します。Intruderは攻撃面を追跡し、積極的な脅威スキャンを実行し、APIからウェブアプリ、クラウドシステムまでの技術スタック全体で問題を見つけます。今日無料で試してみてください。