mirror of https://github.com/carlospolop/hacktricks synced 2024-11-16 09:48:14 +00:00

History

Translator 9d988c6898 Translated ['generic-methodologies-and-resources/exfiltration.md', 'gene		2023-09-03 01:45:18 +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 ['generic-methodologies-and-resources/exfiltration.md', 'gene	2023-09-03 01:45:18 +00:00

README.md

クッキーのハッキング

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

サイバーセキュリティ企業で働いていますか？ HackTricksで会社を宣伝 したいですか？または、最新バージョンのPEASSにアクセスしたり、HackTricksをPDFでダウンロード したいですか？SUBSCRIPTION PLANSをチェックしてください！
The PEASS Familyを見つけてください。独占的なNFTのコレクションです。
公式のPEASS＆HackTricksのグッズを手に入れましょう。
💬 Discordグループまたはテレグラムグループに参加するか、Twitterでフォローしてください🐦@carlospolopm。
ハッキングのトリックを共有するには、PRを hacktricks repo と hacktricks-cloud repo に提出してください。

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

{% 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 が domain 属性を持つクッキーを設定した場合、親ドメインへのリクエストで送信されます。

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として扱われます。

Cookieフラグ

HttpOnly

これにより、クライアントがクッキーにアクセスできなくなります（例えば、Javascript経由でのdocument.cookieなど）。

バイパス方法

ページがリクエストの応答としてクッキーを送信している場合（例えば、PHPinfoページなど）、XSSを悪用してこのページにリクエストを送信し、応答からクッキーを盗むことができます（https://hackcommander.github.io/pentesting-article-1/で例を確認してください）。
サーバーからの応答として、TRACE HTTPリクエストをバイパスすることができます（このHTTPメソッドが利用可能な場合）。この技術はクロスサイトトラッキングと呼ばれます。
この技術は、モダンブラウザではTRACEリクエストをJSから送信できないようにすることで回避されます。ただし、IE6.0 SP2に対してTRACEではなく\r\nTRACEを送信するなど、特定のソフトウェアでこれを回避する方法が見つかっています。
別の方法は、ブラウザのゼロデイ脆弱性を悪用することです。
HttpOnlyクッキーを上書きすることができます。Cookie Jarオーバーフローアタックを実行することで：

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

Cookie Smuggling攻撃を使用してこれらのクッキーを外部に流出させることができます。

Secure

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

クッキーの接頭辞

__Secure-接頭辞：セキュアなページ（HTTPS）からsecureフラグと共に設定する必要があります。

__Host-接頭辞：セキュアなページ（HTTPS）からsecureフラグと共に設定する必要があり、ドメインが指定されていない（したがって、サブドメインに送信されない）必要があり、パスは/である必要があります。

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

クッキー攻撃

もし、セッションID、ユーザー名、メールアドレスなどの機密データを含むカスタムクッキーを見つけた場合、それを悪用することを試みるべきです。

クッキーのデコード

クッキーがベースエンコーディング（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"

これにより、送信されるCookieヘッダーは次のようになります：

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;

意味するところは、すべてのWebサーバーは、cookie aが値bに設定されたものとして解析します。

Chromeのバグ - document.cookieの破損

もしセットされたcookieにUnicodeサロゲートコードポイントが含まれている場合、document.cookieは永久に破損し、空の文字列を返します。

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

クッキーのスマグリング

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

具体的には、これらのサーバーは、ダブルクォート（dquoted）のクッキー値に遭遇した場合でも、セミコロンが出現するまでクッキー文字列の読み取りを続けます。これは問題です、なぜならセミコロンはクッキー文字列内のキーと値のペアを区切るために使用されるべきだからです。

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

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

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

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

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

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

Undertowの場合、セミコロンを待たずに、引用符で囲まれたクッキー値の終わりの直後に次のクッキーの解析を開始します。

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

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

LANGUAGE=en-us,CSRF_TOKEN=SPOOFED_VALUE

そして、PythonのSimpleCookieとBaseCookieは、次のクッキーをスペース文字で解析し始めます：

LANGUAGE=en-us CSRF_TOKEN=SPOOFED_VALUE

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

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

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

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

基本的なチェック

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

高度なクッキー攻撃

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

非常に類似したユーザー名で多くのアカウントを作成し、アルゴリズムがどのように機能しているかを推測してみてください。
ユーザー名をブルートフォースしてみてください。クッキーがユーザー名の認証方法として保存される場合、ユーザー名が「Bmin」のアカウントを作成し、クッキーの各ビットをブルートフォースしてみてください。試すクッキーの1つは「admin」に属するクッキーです。
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」のクッキーを取得できます。

参考文献

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

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