Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-15 09:27:32 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/hacking-with-cookies
History
Translator workflow e90c803209 Translated to Japanese
2023-07-07 23:42:27 +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 to Japanese 2023-07-07 23:42:27 +00:00

README.md

クッキーのハッキング

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

クッキーの属性

Expires & Max-Age

  • Expiresは、クッキーが削除される有効期限を設定します。
  • Max-ageは、クッキーが削除されるまでの時間を秒単位で設定します（これを使用してください、もはや2009年ではありません）。

Domain

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

たとえば、Domain=mozilla.orgと設定した場合、クッキーはdeveloper.mozilla.orgなどのサブドメインで利用できます。しかし、指定しない場合、クッキーはサブドメインに送信されません。

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

Path

Path属性は、要求された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/pentesting-article-1/)で例を確認してください）。
  • この技術は、サーバーからの応答（このHTTPメソッドが利用可能な場合）であるTRACE HTTPリクエストによってバイパスされる可能性があります。この技術はクロスサイトトラッキングと呼ばれます。
  • この技術は、現代のブラウザではTRACEリクエストをJSから送信できないことによって回避されます。ただし、IE6.0 SP2に対してTRACEではなく\r\nTRACEを送信するなど、特定のソフトウェアでこれをバイパスする方法が見つかっています。
  • 別の方法は、ブラウザのゼロデイ脆弱性を悪用することです。
  • クッキージャーオーバーフローアタックを

セキュア

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

クッキーの接頭辞

__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 Cookie

前のリンクをクリックして、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の破損

セットされたクッキーに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としてヌルベクトルを使用することが推奨されているため、このタイプの整合性チェックは脆弱性を持つ可能性があります。

攻撃

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

参考文献

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