認証と認可についての知識が必要になったので、基礎的なことを学んでいます。 一切何も知らない状態から手当たり次第に細かく調べるのは大変だったので、超サマリを整理してみようと思います。 この本は「個々の要素に詳しくなる必要はないんだけど、概要くらいはさっと把握しておきたい」とか「手当たり次第に詳細調査をする前に、一瞥してこれから踏み込もうとしている領域の超俯瞰マップを作る」という感じで使うことを想定しています。 同じ様な方の役に立ったら、とても嬉しいです。 この本は筆者の理解に連動して追記修正される可能性があります。
世界一わかりみの深いOAuth入門
画像出典: 書籍...記事中に掲載した販売ページ / Webサイト...スクリーンショット はじめに こんにちは。株式会社Flatt Securityの @toyojuni です。 突然ですが、弊社Flatt Securityは「開発者に寄り添ったセキュリティ」を標榜しています。Webアプリケーションなどに脆弱性がないか調査する 「セキュリティ診断」 においても、セキュアコーディング学習プラットフォーム 「KENRO」 においても、いかに開発者フレンドリーなサービスを提供できるかという点を大事にしています。 そんな弊社はお客様からさまざまな開発におけるセキュリティのアドバイスを求められることも多いのですが、その中で「開発に役に立つセキュリティ」という切り口では、なかなかまとまっているリファレンス集がないという課題に気付かされました。 そこで、社内でアンケートを実施して「開発者にオススメのセ
「OAuthで認証してます」 「SSOってSAMLのこと？」 「OIDCってOAuthの上位互換？」 このあたり、言葉の形が似ていて普通に混ざります。 で、混ざったままでも開発は進んでしまうので、なおさら厄介です。 ただ、ここで詰まる原因は「専門用語が多いから」じゃなくて、もっと単純で、種類の違う言葉が同じレイヤーに置かれがち だからだと思っています。 体験の名前（SSO） 信頼のつなぎ方（フェデレーション） 登場人物の役割（IdP / SP） 受け渡しのルール（OAuth / OIDC / SAML） レイヤーを分ければ、用語が多くても意外と迷子になりません。この記事はそのための整理です。 TL;TD 認証（AuthN）：あなたは誰？ 認可（AuthZ）：あなたは何ができる？ SSO：1回ログインで複数サービスを使える「体験」 フェデレーション：別システムの認証結果を「信頼して受け取る」
1Passwordを使って、ローカルにファイル(~/.configや.env)として置かれてる生のパスワードなどを削除した 最近、コミットはされないがローカルのディレクトリに置かれている.envのようなファイルから生のパスワードやAPI Tokenを削除しました。 これは、ローカルでマルウェアを実行した場合に、ローカルに置かれている生のパスワードやAPI Tokenを盗まれる可能性があるためです。 最近は、npm install時のpostinstallでのデータを盗むようなマルウェアを仕込んだりするソフトウェアサプライチェーン攻撃が多様化しています。 Compromised PyTorch-nightly dependency chain between December 25th and December 30th, 2022. | PyTorch What’s Really Goin
訂正(2022/10/12 15:00) 本文中で「Twitter日本法人に内容証明郵便を発送した」と書いていましたが、 これは「Twitter本社（アメリカ）の日本担当者に内容証明郵便を発送した」の間違いでした。 今朝いきなり凍結されましてね…… pic.twitter.com/025nwyqdZJ— gecko (@gecko535) 2022年6月9日 アカウントを取り戻しました！！！！！！！！！！！— gecko655 (@gecko655) 2022年10月6日 2022年6月9日10時〜2022年10月6日12時の間、Twitterの @gecko655 のアカウントは凍結されていました。 この記事では、凍結解除されるまでに何をやったか、凍結解除のためにどのくらい費用がかかったか等を記録していきます。 なんで凍結されたの？ 凍結されたあとにやったこと 公式の異議申し立てフォーム
これらが24時間、macOS上で動いています。PCを閉じない限り止まりません。 全体のアーキテクチャはこうです: ポイントは、Claude CLIを「考えるパーツ」として使っていること。データの取得・加工はPythonで行い、「この情報をどう要約するか」「このメールは返信が必要か」といった判断だけをClaudeに任せています。 カテゴリ別: 何を自動化したか 1. メール処理（最も効果が大きかった） Before: 1日3回、3つのメールアカウント（個人・大学・就活用）を開いて確認。返信を書くのに30分〜1時間。 After: 10分ごとにGmail APIで全アカウントのメールを取得。AIが4段階に分類。 具体例: 教授からの「明日のミーティングの件」→ reply判定 → カレンダーから空き時間を取得して返信下書きを生成 学会からのCFP通知 → see判定 → Slackに1行通知
SPA認証トークンをどこに保存するかは論争が絶えません。localStorageやCookieがよく使われますが、Auth0は違う方法を採用しています。この記事では、Auth0のトークン管理の方式を理解でき、トークン管理上のセキュリティへの理解を深めることができます。 SPAの認証トークンをどこに保存するか ブラウザでトークンを保存できる場所 保存場所の比較 メリット・デメリット Auth0のアプローチ トークンはインメモリに保存 OpenID Connect準拠とトークン取得のUI/UXの悪化回避を両立 Auth0のjsライブラリ ログイン アクセストークンの（再）取得 図解 ログイン アクセストークンの（再）取得 自サービス内の認証だけのもっと簡易な構成 ログイン IDトークン取得 まとめ SPAの認証トークンをどこに保存するか React やVueで認証付きSPA（Single Pa
ritouです。このしずかなインターネットにおける初投稿です。 おそらく、このしずかなインターネットのID連携では次のような設計になっていま「した」。問い合わせをさせていただき、対応いただきました。 これまでもQiitaなどで同様の実装例が紹介されていた際にはコメントさせていただいていたものですので、アンチパターンの紹介記事として読んでいただければと思います。 「Googleアカウントでログイン」ではじめると、ユーザーが作成され、Googleから受け取ったメールアドレス([email protected])が設定される 次回から「Googleアカウントでログイン」をすると、Googleから受け取ったメールアドレスでユーザーを参照 試しに、次のような流れで動作を確認してみます。 「Googleアカウントでログイン」でアカウント作成([email protected]) 「メールアドレス変更」
2023/10/05 Offersさんのイベントでの資料です。 https://offers.connpass.com/event/295782/ イベント後の満足度アンケート（5点満点）の結果は以下になります。 5点: 49% 4点: 39% 3点: 8% 2点: 4% こちらの…
SECCON Beginners Live 2023「JWTセキュリティ入門」の発表資料です。
このビデオは、2021 年 10 月 6 日に開催された 「挫折しない OAuth / OpenID Connect 入門」の理解を深める会 のプレゼンテーション録画です。 2021 年 9 月 18 日発売の「Software Design 2021 年 10 月号」では、OAuth/OIDC が特集され、「挫折しない OAuth/OpenID Connect 入門・API を守る認証・認可フローのしくみ」と題し、Authlete 代表の川崎貴彦が寄稿しました。 本プレゼンテーションでは記事のポイントや、理解を深めるために重要なポイントについて、著者の川崎がお話しします。 文字起こしはじめに目次記事の第1章、第2章、第3章は、こういう目次になっています。 ここからピックアップして、 こんなことを話してます、というところを、 紹介したいと思います。 自己紹介Authlete 社の代表取締役
今から二ヶ月ほど前、10/1 に Yahoo! トラベル のリニューアルが完了しました。このリニューアルは、一休.com と Yahoo! トラベルの2システムを一つに統合することで実現しました。 ご存知の通り、ヤフーと一休は同じグループに所属する企業です。ざっくりいうと「同じグループで2つの宿泊予約システムを開発し続けるのは効率が悪いよね」という話があり、今回のシステム統合に至っています。 Yahoo! トラベルと一休のシステム統合は、(1) 2017年頃にホテルの空室管理や予約、決済、精算業務などを担うバックエンドのシステム統合を行い、そして (2) 今回 2021年春先から半年ほどをかけて、ユーザーが利用する画面も含めた全面統合を行いました。全面統合は総勢で 50名ほどのディレクター、エンジニア、デザイナーが関わる一休的には大きな規模のプロジェクトになりましたが、目立ったトラブルもな
おはようございます、ritouです。 この話に乗っかっていきます。 3行で ログアウト時にJWTを無効化できない実装は今後脆弱性診断で「OWASP Top 10 2021違反」と指摘されるようになりそう(今も個別にされてるかもしれないけど) JWTは単純なフォーマットなので、ステートレスなセッション管理においてログアウトしたときに文字列自体を無効化できない件は独自エンコード方式(一般的にフレームワークのCookieストアと呼ばれているもの)でも起こり得る 「セッションID vs JWTで内包」 以外にも 「セッションIDをJWTに内包」もあり得る。既存の機能を残しつつ「JWTで武装」する選択肢も考えてみてはどうか。 ステートレスなセッション管理でログアウトの際に文字列自体を無効化できない問題 これは前から言われていますし、駆け出し何とか勢のQiita記事に書かれるぐらいには一般的です。 2
パスキーによる認証を開発したとき、パスキーの安全性をどう評価するのが妥当なのか検討していた。もちろんフィッシング耐性が高いというような特性については把握していて、サービス利用者にとって便益の多い認証であることはわかっている。ただそれが、例えばパスワードとTOTPを組み合わせた多要素認証に対して、どちらがより安全と言えるのか。これを一言に表すのはあまり簡単ではない。 パスキーは多要素認証なのか 多要素認証というのは、something you know、something you have、something you are の3種類の要素のうち複数を組み合わせる認証を言う語だ。 多要素認証は単一種類の要素による認証と較べて飛躍的に安全である。例えば、物理的な鍵は something you have であるが、それが盗まれてしまえば安全ではない。鍵が複数あっても、一度に盗まれてしまうかもし
DevelopersIO 2021 Decadeで「全員がOAuth 2.0を理解しているチームの作り方」というテーマで話させていただきました。 DevelopersIO 2021 Decade で「全員がOAuth 2.0を理解しているチームの作り方」というテーマで話させていただきました。 スライド 話した内容 なぜ人類は OAuth 2.0 に入門し続けるのか なぜ OAuth 2.0 をチームに根付かせたいのか 開発フローとしてコードレビューがある 仕様がわからないと、レビューができない コードと仕様のすり合わせのために仕様が分かる必要がある OAuth 2.0 はまあまあややこしい OAuth 2.0 では登場人物が4人いて、それぞれがいろんなやりとりをします。 それぞれのやりとりにパラメーターがあるので、誰が誰にどういう値をどうして送る、みたいなところまで考えるとまあまあやや
【累計5000部突破（商業版含む）🎉】 SAMLaiの道は果てしなく険しい。 本書では、SAML2.0で一般的に多く使用されるフローであるWeb Browser SSOのSP-initiatedとIdP-initiatedと呼ばれるものを中心に、SP側の目線でなるべく簡潔に解説します。 SAML認証に対応してほしいと言われても、もう頭を抱える必要はありません。 筆者自身も何もわからない状態からもがき苦しみながらSAML SPを実装し、数年間サービスを運用してきました。 そのつらい経験を踏まえて、SPを実装する上で今まで触れられることのなかった ・どういう設計が必要か？ ・何を気をつけなければならないか？ のエッセンスを詰め込みました。 SAMLはエンタープライズ用途では求められることが非常に多く、歴史もそれなりに長いものですが、実装する上で必要な体系的な情報はなぜかほとんどありません。
追記 作者のcatnose99さんがより詳細を解説してくださいました zenn.dev /追記 ポエム特化のZenn2との噂の「しずかなインターネット」を使いはじめたので、ユーザーとしてどんな技術が使われているのかを確認していく。 sizu.me おもむろにbuiltwith.comにかけてみる。 builtwith.com ここで分かる情報はブラウザのDevTools眺めてても得られるのであまり収穫はない。 前段にCloudflareのCDNサーバーがいて Next.jsで生成されたレスポンスを返している ことがわかる。 この時点ではキャッシュのみCloudflareなのか、Pages/WorkersでNext.jsのSSRごと動かしているのかは判断できない。 認証 Set-Cookie: __Secure-next-auth.session-token=が含まれているのでNextAut
OAuthにおける認可コード横取り攻撃とその対策 2021年7月5日 前回の記事で示したように、カスタムURLスキームを偽装した不正アプリは正規アプリへのディープリンクを乗っ取れる。この挙動の悪用シナリオとして、正規アプリと認可サーバー間のOAuthフローにおける認可コード横取り攻撃が知られている。この攻撃への対策を把握するためにiOS環境でシナリオを再現し、PKCEの有効性を確認した。 要約 OAuth 2.0の拡張機能であるPKCEを導入することで認可コード横取り攻撃を無効化できる。OAuth 2.0の仕様では、認可サーバーはネイティブアプリをクライアント認証できない。そのため、認可サーバーは認可コードを横取りした不正アプリと正規アプリを識別できない。しかし、PKCEの仕組みにより認可サーバーは正規アプリを識別できるようになり、認可コード横取り攻撃の検知が可能となる。 ネイティブアプリ
ritouです。 ここ数年、ユーザー認証のお話をさせていただいている中、最近ようやく「パスキー認証はね、入れとかないと」みたいな雰囲気になってきましたが、しかしその一方で、「パスキー認証のこういうところが好きになれない」といったご意見も当初からいただいています。今回は、その中の「こうしたらやられる」と言う主張、つまりパスキー認証に対する現状の脅威、考えられる対策 について整理しましょう。 ユーザー認証の現状とこれから ユーザー認証はここ数年、脅威の認識と対策の繰り返しの中で変化してきました。 パスキー登場までの経緯については、 “パスワードレス認証への道" ユーザー認証の変遷とパスキーの関係 にて整理しています。 3行でまとめると、次のようになります。 パスワード認証のみの利用は、パスワードの使い回しによる他サービスへの影響範囲を考えても、極めて危機的な状況である 一般的に使われている「パ
OCHaCafe Season4 #4の資料です． デモのソースコード等は
https://aiau.connpass.com/event/365588/
はじめに Wikipedia の JWT (JSON Web Token) に関する記事が誤っていたので、2020 年 5 月 9 日、英語版、日本語版ともに修正を行いました。 修正前の記事では、JWT のことを「JSON をベースとしたアクセストークンのためのオープン標準である」と説明していました。しかし JWT は用途を限定しない汎用的なデータフォーマットです。アクセストークンのフォーマットとして JWT を採用することは、JWT の応用事例の一つに過ぎません。なお、アクセストークンのフォーマットは必ずしも JWT とは限りません。→ 参考:『図解 JWS/JWE/JWT/IDトークン/アクセストークンの包含関係』 JWT を知らない状態で OAuth と OpenID Connect の学習を始めると、「JWT はアクセストークンのための技術である」、「JWT はユーザ認証のための技
SPAやモバイルアプリから利用するAPIを開発する際の、トークン認証のお話です。 どの認証ライブラリを使うべきという話ではなく、トークン認証の論理的な設計について考察します。 私自身も結論が出ていないので、色んな意見が聞けると嬉しいです。 出発点 ユーザテーブルにアクセストークンを持つのが最も安直な発想だと思います。 ログイン成功時にアクセストークンを発行し、該当ユーザレコードにセット。 同時に有効期限もセットします。 認証時には、アクセストークンが存在し有効期限内であれば、認証を通過させ、 そうでなければ認証失敗とします。 ログアウト時には、該当ユーザレコードのアクセストークンを空にします。 発行日時を持ち、システム内に定義された有効期間をもとに、認証時に計算する方法もあると思います。 Laravel Sanctum 等はそういう実装です（しかもデフォルトでは有効期限なし）。 有効かどう
これは、豆蔵デベロッパーサイトアドベントカレンダー2022第8日目の記事です。 JSON Web Token(JWT)の単語を目にすることがよくあると思いますが、それと一緒に認証と認可や、RSAの署名や暗号化、そしてOpenIDConnectやOAuth2.0までと難しそうな用語とセットで説明されることも多いため、JWTって難しいなぁと思われがちです。しかし、JWT自体はシンプルで分かりやすいものです。そこで今回は素のJWTの説明からJWS、そしてJWT(JWS)を使った認証を段階的に説明していきます。 おな、この記事はJWT全体の仕組みや使い方の理解を目的としているため、以下の説明は行いません。 RSAやHMACなど暗号化やアルゴリズムの細かい説明 JWTを暗号化するJWEとJSONの暗号鍵表現のJWKについて OpenIDConnectとOAuth2.0について 記事は上記のような内容
// auth.ts import NextAuth from "next-auth" import GitHub from "next-auth/providers/github" export const { auth, handlers } = NextAuth({ providers: [GitHub] }) // middleware.ts export { auth as middleware } from "@/auth" // app/api/auth/[...nextauth]/route.ts import { handlers } from "@/auth" export const { GET, POST } = handlers // src/auth.ts import { SvelteKitAuth } from "@auth/sveltekit" impor
はじめに 認証や認可の実現方法は、システム開発における頻出の関心事の一つかと思います。そんな中、JSON Web Token（JWT）／OAuth2.0／Open ID Connect（OIDC）という言葉もよく耳にするところです。 しかし、「JWTって結局どう使うの？」「OAuth2.0やOIDCってJWTとどう関係するの？」「OAuth2.0とOIDCの違いって何？」という疑問を持つ方も多いのではないでしょうか。 また、JWTに「署名」や「検証」といったキーワードが絡んでくると、途端にハードルが上がったように感じるものです。 これらのキーワードについては既に沢山の記事が公開されていますが、本記事では以下に焦点を当てて解説していこうと思います。 JWT／OAuth2.0／OIDCの関係性を明らかにする OAuth2.0／OIDCより先にJWTを理解することで混乱を防ぐ JWTをシステム開
NewsPicksの高山です。 この記事はUzabase Advent Calendar 2021の23日目の記事です。昨日は我らが赤澤剛さんによるAWS Organizationの記事でした。 去る2021年10月12日に突然NewsPicksのサービスでFacebookログインやFacebookへの投稿ができなくなりました。この状態は12月13日まで2ヶ月もの間継続していて、ユーザーさんには不便を強いてしまいました。 米Facebook本社とメールでやりとりしていましたが、メール返信に何週間も待たされ、Facebook日本法人に助けてもらってようやく解決に至ることができました。 この苦労話はいくらでもできるのですが、今回はセキュリティの切り口で書いていきます。 Facebookの「データ保護評価」 データセキュリティ項目 「すべてのプラットフォームデータストレージ(すべてのデータベース
SPAのアプリケーションで、外部のIdPを使ってOpenID Connect によるログイン機能を開発しようと考えています。IDトークンの保存先として、ブラウザのCookieかサーバーのDBに保存するかの2つの案があると思っています。調べた限り、サーバーサイドで持つべきという意見が多いように見えますが、以下のような背景がある中で開発しても、ブラウザのCookieでは持つべきなのではないのでしょうか？ - IDトークン自体にも、個人の属性（氏名等）情報は無いことを確認している - サーバーサイドでIDトークンの署名検証をして、IDトークンの改ざんが無いか確認する - Http Only属性：JSによるCookieへのアクセスを防ぐため - Secure属性：流出防止のため - SameSite=strict：CSRF対策のため 結論から言えば、「どちらでもよい」となります。しかし、恐らく話は
こんにちは。アドカレ12/24の記事を簡単にではありますが書かせていただきました。(25日のポストで遅刻ですが) Digital Identity技術勉強会 #iddanceのカレンダー | Advent Calendar 2023 - Qiita はじめに 本日のテーマ：思わず天を仰いでしまうID関連システムトラブル 本日のテーマは、みんな大好き「トラブル」の話です。CIAM(Consumer Identity and Access Management)領域のさまざまなシステムにさまざまな立場で関わり、さまざまなトラブルに遭遇してきた経験を踏まえて、クリスマスの合間の気楽な読み物として記載しましたので、一息ついていただければ幸いです。 今回はトラブルの中でも思わず「天を仰いでしまう」激ヤバトラブルにフォーカスして、私的ランキング形式でお届けしたいと思います。 天を仰ぐトラブルとは？ 私
ritou です。 みんなが待っていたデジタル認証アプリの情報が公開されました。 開発者向けのガイドライン、APIリファレンスなどのドキュメントも公開されています。 今回は開発者視点でどんな作りになっていて、利用するために理解が必要となる標準化仕様はどのあたりなのかを取り上げます。ちょっとOIDCのRPやOAuthのClient実装経験のある開発者向け、ぐらいの内容です。 概要 公開された情報からすると デジタル認証アプリサービス(アプリ+バックエンド)はマイナンバーカードを用いた当人認証を実施 現在は都度マイナンバーカードを利用する必要がありますが、いずれはスマホに保存されたカード情報を使ってもっと楽になりそう ID連携のIdentityプロバイダとして認証イベント情報、基本4情報といった属性情報を民間/行政サービスに提供 民間/行政サービスは認証イベント情報に含まれるユーザー識別子を利
Note 本記事は、2018 年公開の以下の Blog の内容が、現在の機能/技術にマッチしない内容になってきたことを踏まえ、2023 年現在の機能/技術を元に改めて考え方をおまとめしたものとなります。以前に公開した Azure AD が発行するトークンの有効期間について (2018 年公開) の記事は参考のためそのまま残し、新しく本記事を執筆しました。 こんにちは、Azure & Identity サポートの金森です。 Azure AD (AAD) は、Microsoft 365 をはじめ様々なクラウド サービスの認証基盤 (Identity Provider / IdP) として利用されています。その重要な機能としてユーザーの認証が完了したら、アプリケーションに対してトークンを発行するというものがあります。あるサービス (Teams や Exchange Online、他に Azure
はじめに こんにちは。 セキュリティエンジニアの@okazu-dm です。 この記事は、Auth0のアクセストークンの保存方法について解説した前回の記事の補足となる記事です。前回の記事の要旨をざっくりまとめると以下のようなものでした。 Auth0はデフォルトではアクセストークンをブラウザのメモリ空間上にのみ保存するin-memory方式であり、XSSへの耐性のなさ等の理由でlocalStorageで保存することを推奨していない しかし、XSSでアクセストークンを奪取できるのはin-memory方式でも同じのはず(検証は行いませんでした)。localStorage方式を過度に忌避する必要はないのではないか なお、Flatt Securityの提供するセキュリティ診断はAuth0に限らずFirebase AuthenticationやAmazon CognitoなどのIDaaSのセキュアな利用
ritouです。今日はこの話です。 SSO=一度ログインしたら複数RPに一括でログイン可能みたいなイメージに対して、OIDCでの動きは個々のRPがそれぞれ自分達向けのIDTokenを受け取りそれを信用してログイン状態にするだけ。 https://t.co/R4qNOrcY8h— 👹秋田の猫🐱 (@ritou) 2025年5月9日 ここで扱うSSO（シングルサインオン）とは、一般的に「一度の認証処理で、複数の独立したシステムやサービスへアクセス可能になる仕組み」を指します。 本稿では、このSSOをID連携の主要な実現手段の一つであるOIDC (OpenID Connect) がどのように実現するのかについて解説します。 ID連携を用いないSSOの実現方法：単一セキュリティドメイン内でのアプローチ まずID連携について触れる前に、単一のセキュリティドメイン（ID管理が一元的に行われる範囲）
ritou です。 一日遅れましたが、アドカレ最終日の記事です。 qiita.com 一個誰かが忘れてる以外は埋まってますね！特に中盤までのAuthlete無双ありがとうございます。 前日(24日)の記事も大作でございました。 zenn.dev 今回は巷でよく言われている「OAuthは認可、OIDCは認証」ってフレーズについて整理しましょう。 「OAuthは認可」わかる OAuthは(最近だと3rdパーティーに関わらず)あるアプリケーションに対して安全なリソースアクセスの提供を実現するための仕様です。 リソースオーナーはそのアプリケーション自身かもしれないし、アプリケーションのユーザーかもしれません。 リソースアクセスを提供する側が認可し、利用する側は認可されてリソースアクセスをします。これは特に問題ないでしょう。 「OIDCは認証」わかる？ OIDCは認証、これはどういう意味かわかります
※追記: 本記事の続編としてin-memory方式からアクセストークンを奪取するPoCを下記記事で公開しました。ぜひあわせてご覧ください。 はじめに こんにちは。 セキュリティエンジニアの@okazu-dm です。 この記事では、Auth0のSPA SDKでアクセストークンのキャッシュを有効化する際の考慮ポイントについて紹介し、それを切り口にアクセストークンの保存場所に関してin-memory方式とlocalStorage方式の2つについて解説します。 Auth0のようなIDaaSは昨今かなり普及が進んでいると思いますが、Flatt Securityの提供するセキュリティ診断はAuth0に限らずFirebase AuthenticationやAmazon CognitoなどのIDaaSのセキュアな利用まで観点に含めて専門家がチェックすることが可能です。 ご興味のある方は是非IDaaS利用部
MCP logo ©︎ 2024–2025 Anthropic, PBC and contributors | MIT license はじめに こんにちは、GMO Flatt Security株式会社 セキュリティエンジニアのAzaraです。普段は、クラウドセキュリティや Web アプリケーションのセキュリティを専門領域にしています。 本稿は MCP のセキュリティを前後編で解説するものの後編です。前編では MCP のセキュリティを、利用者の視点から考察しました。 後編となる本稿では、攻撃者視点から脅威や攻撃手法を整理します。そのうえで、日々増えていく MCP Server の提供者が、これらの脅威やセキュリティ課題をどのように考慮し対策を講じるべきかを解説します。 また、GMO Flatt Securityは日本初のセキュリティ診断AIエージェント「Takumi」や、LLMを活用したア
きっかけ 昨年(2021年9月ごろ)に徳丸さんのこのツイートを見て、「2022年にはJWTを用いたセッション管理に代表される、ステートレスなセッション管理は世の中に受け入れられなくなっていくのだろうか？」と思っていました。 OWASP Top 10 2021 A1に「JWT tokens should be invalidated on the server after logout.」（私訳:JWTトークンはログアウト後にサーバー上で無効化すべきです）と書いてあるけど、どうやって無効化するんだ? ブラックリストに入れる?https://t.co/bcdldF82Bw— 徳丸 浩 (@ockeghem) 2021年9月10日 JWT大好きな皆さん、ここはウォッチしないとだめですよ。これがそのまま通ったら、ログアウト機能でJWTの即時無効化をしていないサイトは脆弱性診断で「OWASP Top
2022年4月16日(日本時間)にアナウンスがあった、Heroku/Travis-CIのOAuthトークンの流出および悪用を受けて、ユーザーとしてやっておくといいことをまとめました。 GitHubのOrganizationのオーナー向けと個人向けで分けてあります。 追記: 複数の補足のコメントを頂き、記事にも取り込んでいます。ありがとうございます！ 注意 執筆者はGitHub, Heroku, Travis-CIの専門家ではありません。この記事は誤っている可能性があります。 この記事は現在調査中の問題について書かれています。最新情報は必ず公式サイトをご確認ください。 GitHub Heroku Travis CI インシデントの概要 GitHubがHerokuとTravis-CIのOAuthアプリケーションに発行したトークンが流出・悪用したことで、それらの連携が有効だった多くのOrgani
by Esther Vargas Twitterは2023年2月にAPIの無料提供を終了することを発表し、有料APIへの移行を進めるために外部サービスの無料APIへのアクセスを遮断し始めています。そんな中、無料APIだけでなくTwitterアカウントを利用した外部サービスへのログインも遮断され始めていることが、ソーシャルアグリゲーションサービス・FlipboardのCEOを務めるMike McCue氏によって報告されました。 In addition to turning off their API, #Twitter has also inexplicably turned off access for users to sign in to #Flipboard and other platforms with Twitter SSO. This is an unacceptable b
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く