令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
セキュリティエンジニアを3年続けて分かったおすすめ勉強法
セキュリティエンジニアとして就職してからそろそろ3年経ちます。独断と偏見に基づき、IT初心者・セキュリティ初心者・セキュリティエンジニアの3つの時期に分け、費用対効果の良い勉強法を紹介していきたいと思います。 セキュリティエンジニアとは 「セキュリティエンジニア」という言葉は範囲が広いですが、私が今回記載する内容は脆弱性診断やペネトレーションテストに寄った内容となっています。インシデント対応やアナリスト業務などは専門ではないので、あくまで診断系の人が書いているということをご認識おきください。 そもそもセキュリティエンジニアにどのような職種が含まれるかはラックさんが分かりやすい資料を出しているのでそちらをご覧ください(サイバーセキュリティ仕事ファイル 1、サイバーセキュリティ仕事ファイル 2)。 IT初心者時代 セキュリティを学ぶ以前に基礎となるITを学ぶ時代を考えます。 学校教育 学生の場
DroidKaigi 2023にてパスキーについて話しました
株式会社MIXI 開発本部 MIXI M事業部の ritou です。 DroidKaigi 2023にてお話しさせていただきました。 資料も公開しました。 今回も発表内容全部書き出してみたをやってみます。 同時通訳ありだったので台本はできていて、この通り話せたら良いだけだったのですが実際はそううまくいかずに普通に時間なくなりました。 それではどうぞ。 これからパスキーに関するユースケースと、それに伴うユーザーエクスペリエンスの課題について発表します。 株式会社MIXIでエンジニアとして働いています。 MIXI MというサービスでID基盤の開発に携わっており、8月にパスキー対応を行いました。 その経験も踏まえて、今日はお話をさせていただきます。 また、OpenIDファウンデーションジャパンでエバンジェリストをしています。 今日はID連携とパスキーの関係についてもお話します。 この発表を通して
何故パスワードをハッシュ化して保存するだけでは駄目なのか？ - NRIネットコムBlog
不正アクセスによるIDとパスワードの漏洩を受けて、MD5によるハッシュ化について話題になっていました。システムを作る上で、パスワードの管理や認証はどう設計すべきかを考えるために、少し整理をしてみます。もし事実誤認があれば、どしどしご指摘ください。 == 2023/8/21追記 == この記事は、ハッシュの保存の仕方一つとっても、沢山の対策方法が必要であるということをお伝えするために記載しています。そして、これから紹介する手法を取れば安全とお勧めしている訳ではないので、その点をご留意いただければと思います。攻撃手法に応じての対応策の変遷を知っていただくことで、セキュリティ対策は一度行えば安全というものではないことを知って頂くキッカケになれば幸いです。 == 追記終わり == パスワードのハッシュ化 まず最初にパスワードの保存方法です。何も加工しないで平文で保存するのは駄目というのは、だいぶ認
今時の CSRF 対策ってなにをすればいいの？ | Basicinc Enjoy Hacking!
こんにちは @zaru です。今回は昔からある CSRF (クロスサイト・リクエスト・フォージェリ) の今時の対策についてまとめてみました。もし、記事中に間違いがあれば @zaru まで DM もしくはメンションをください (セキュリティの細かい部分についての理解が乏しい…) 。 2022/08/29 : 徳丸さんからフィードバック頂いた内容を反映しました。徳丸さん、ありがとうございます！ 認証あり・なしで対策方法が違う点 トークン確認方式のデメリットのクロスドメインについての言及を削除、代わりに Cookie 改変リスクを追記 Cookie 改ざん可能性について徳丸さんの動画リンクを追記 SameSite 属性で防げない具体的なケースを追記 nginx 説明が関係なかったので削除 そもそも CSRF ってなに？ 昔からインターネットをやっている方であれば「ぼくはまちちゃん」 騒動と言えば
Auth0のアクセストークンをLocal Storageに保存するのは安全？メリット・デメリットをin-memory方式と比較して検討する - Flatt Security Blog
※追記: 本記事の続編としてin-memory方式からアクセストークンを奪取するPoCを下記記事で公開しました。ぜひあわせてご覧ください。 はじめに こんにちは。 セキュリティエンジニアの@okazu-dm です。 この記事では、Auth0のSPA SDKでアクセストークンのキャッシュを有効化する際の考慮ポイントについて紹介し、それを切り口にアクセストークンの保存場所に関してin-memory方式とlocalStorage方式の2つについて解説します。 Auth0のようなIDaaSは昨今かなり普及が進んでいると思いますが、Flatt Securityの提供するセキュリティ診断はAuth0に限らずFirebase AuthenticationやAmazon CognitoなどのIDaaSのセキュアな利用まで観点に含めて専門家がチェックすることが可能です。 ご興味のある方は是非IDaaS利用部
SPA認証トークンはlocalStorageでもCookieでもない、Auth0方式はいいねというお話 - @mizumotokのブログ
SPA認証トークンをどこに保存するかは論争が絶えません。localStorageやCookieがよく使われますが、Auth0は違う方法を採用しています。この記事では、Auth0のトークン管理の方式を理解でき、トークン管理上のセキュリティへの理解を深めることができます。 SPAの認証トークンをどこに保存するか ブラウザでトークンを保存できる場所 保存場所の比較 メリット・デメリット Auth0のアプローチ トークンはインメモリに保存 OpenID Connect準拠とトークン取得のUI/UXの悪化回避を両立 Auth0のjsライブラリ ログイン アクセストークンの（再）取得 図解 ログイン アクセストークンの（再）取得 自サービス内の認証だけのもっと簡易な構成 ログイン IDトークン取得 まとめ SPAの認証トークンをどこに保存するか React やVueで認証付きSPA（Single Pa
セキュリティエンジニアのための English Reading | デジタル人材の育成 | IPA 独立行政法人 情報処理推進機構
背景 私たちは中核人材育成プログラム 第5期受講生として、1年間にわたり様々な講義を受け、演習を実施してきました。その過程で、変化し続けるサイバーセキュリティの世界では、世界中の情報を的確に収集し成長を続けることが大事であることを学びました。 世界中の情報を利用するためには英語の力、中でもリーディングの力が不可欠です。しかし、私たち日本のセキュリティエンジニアの多くは英語に苦手意識を持っており、的確な情報活用ができていないのが現状です。 本プロジェクトは、日本のセキュリティエンジニアの情報収集力・成長力レベルアップのため、その手段としての英語リーディングの意欲・能力向上を目指して企画されました。実務や学習にお役立ていただければ幸いです。 想定利用者 日本語話者のセキュリティエンジニア全般ですが、中でも「ユーザー企業や官公庁で働く実務担当者」を主なターゲットとしています。「英語はちょっと……
セキュリティツールの評価は難しい - knqyf263's blog
前から思ってたことをちょっと書かずにいられなくなったのでポエムを書きました。 背景 問題 検知している方が正しいように見えがち 条件を揃えるのが難しい 環境の再現が難しい 検知数が多い方が良さそうに見える 正解かどうかの判断が難しい カバー範囲の正確な見極めが難しい 検知されないほうが嬉しい まとめ 背景 お前誰だよってなるかもしれないので書いておくと、Trivyという脆弱性スキャナーのメンテナをやっています。 github.com とある有名な方による以下のツイートがありました。 I just discovered, during @cloudflare #SecurityWeek no less, that Trivy (the vuln scanner) doesn't detect known issues in Alpine images. Including a critica
セキュリティエンジニアが本気でオススメする開発者向けコンテンツ 20選 - Flatt Security Blog
画像出典: 書籍...記事中に掲載した販売ページ / Webサイト...スクリーンショット はじめに こんにちは。株式会社Flatt Securityの @toyojuni です。 突然ですが、弊社Flatt Securityは「開発者に寄り添ったセキュリティ」を標榜しています。Webアプリケーションなどに脆弱性がないか調査する 「セキュリティ診断」 においても、セキュアコーディング学習プラットフォーム 「KENRO」 においても、いかに開発者フレンドリーなサービスを提供できるかという点を大事にしています。 そんな弊社はお客様からさまざまな開発におけるセキュリティのアドバイスを求められることも多いのですが、その中で「開発に役に立つセキュリティ」という切り口では、なかなかまとまっているリファレンス集がないという課題に気付かされました。 そこで、社内でアンケートを実施して「開発者にオススメのセ
Webエンジニア向けセキュアコーディング学習サービス「KENRO」のトライアルを一般開放しました - Flatt Security Blog
こんにちは、Flatt Security執行役員の @toyojuni です。 弊社はWebエンジニア向けのセキュアコーディング学習プラットフォーム「KENRO(ケンロー)」を提供しています。この度、商談の中で限られたお客様にのみ提供していた「KENRO」のトライアル利用を 無償・期間無制限で一般開放 することとしましたので、そのお知らせも兼ねつつ一般開放に至った背景などをこちらのブログでお話ししようと思います。 「KENRO」とは？ 「KENRO」のトライアルとは？ トライアル一般開放の背景 トライアルはどのような人にオススメ？ トライアルの利用方法 最後に 「KENRO」とは？ 「KENRO」は、Web 開発に必要なセキュリティ技術のハンズオンの研修・学習を行うことができる、環境構築不要のクラウド型学習プラットフォームです。 https://flatt.tech/kenro これまでエ
QiitaやZennよりも便利？ IPAの資料を読もう!
はじめに 飲み物じゃないIPAをご存じでしょうか？ 漢字でいうと、独立行政法人 情報処理推進機構ですね。情報処理技術者試験を実施いる謎の組織という認識の方も多いと思います。 実はIPAはいろんなドキュメントを公開していてQiitaやZenn以上にお役立ちなサイトなのです。 まあ、AWSをどうこうとか、FireabaseやNext.jsのようなキラキラした奴は基本載ってないので特に代替えするものではないですが、ブログとかはまた種類の違った情報があるので個人的には結構使うことあります。しかも 「日本語」！ こういう感じの事をTwitterでつぶやいたところ意外にイイねをされたので、せっかくだしどんなドキュメントがあるかちょっと紹介したいと思います。 セキュリティ関連NIST文書 まずはNISTドキュメントの翻訳版！ これは良いですよね。NISTはアメリカの米国国立標準技術研究所で、セキュリティ
2020年のWebAuthnアップデート
Digital Identity技術勉強会 #iddance Advent Calendar 2020 12日めの記事です。 年末ということで、気楽に2020年のWebAuthn関連の話題を振り返ってみたいと思います。WebAuthnは2019年に一度W3C勧告になりましたが、その後も色々な実装での採用の拡大や、WebAuthn Level2という新しい改訂版の仕様策定の進展など、2020年も色々動きがありました。それらの中から、興味を惹かれた話題を解説していきます。 SafariでFace ID/Touch IDがPlatform AuthenticatorとしてサポートWebAuthn周りで今年最大の進展というと、やはりSafariのWebAuthn実装がFace ID/Touch IDをPlatform Authenticator（内蔵の認証デバイス）としてサポートしたことが挙げられ
セキュリティ視点からの JWT 入門 - blog of morioka12
こんにちは、ISC 1年 IPFactory 所属の morioka12 です。 この記事は IPFactory Advent Calendar 2020 の10日目の分になります。 IPFactory という技術サークルについては、こちらを参照ください。 本記事の最後に記載されている余談でも IPFactory の詳細を紹介しています。 はてなブログに投稿しました #はてなブログ IPFactory Advent Calendar 2020 の10日目の記事を書きました#JWT #security セキュリティ視点からの JWT 入門 - blog of morioka12https://t.co/g1MYe77hAF — morioka12 (@scgajge12) 2020年12月10日 普段は Web Security や Cloud Security 、バグバウンティなどを興味分
ドコモ口座問題であらわになった「本人確認」の誤解
「我々の本人確認が不十分だった」（NTTドコモの丸山誠治副社長）――。 NTTドコモの決済サービス「ドコモ口座」の不正利用に端を発した不正出金事件では、「本人確認」という言葉が記者会見などで何度も飛び交った。 だが、日本において「本人確認」という言葉が意味するところは明確とは言えない。NTTドコモも記者説明会で「（銀行とNTTドコモの間で）本人確認のレベルについて共通認識があったのかどうか、甘かった面がある」と認めている。 日本の法律用語としての本人確認は「身元確認」とほぼ同義だ。運転免許証やパスポートなど身分証（本人確認書類）の提示を求め、本人の氏名や生年月日、住所などを確認する。 対面での確認に加え、身分証のコピーと転送不要郵便を組み合わせて確認する手法や、アプリで本人の顔と身分証の画像データを送信してもらう手法（eKYC）もある。法律に基づく厳格な本人確認なしに、銀行は新規に口座を開
暗号鍵管理ガイドライン | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構
実際の暗号システムがセキュアに動作し続けるためには、暗号アルゴリズム自体がセキュアであるだけでは不十分で、データが保護される期間中、その暗号アルゴリズムが使用する暗号鍵もセキュアに管理されている必要があります。そのため、暗号鍵やデータのライフサイクルを踏まえた運用、安全な暗号鍵の保管、暗号鍵危殆化時の対策などを行う上で参考となるガイドラインを取りまとめています。 「暗号鍵管理システム設計指針（基本編）」の内容 「暗号鍵管理システム設計指針（基本編）」は、あらゆる分野・あらゆる領域の全ての暗号鍵管理システムを対象に、暗号鍵管理を安全に行うための構築・運用・役割・責任等に関する対応方針として考慮すべき事項を網羅的に提供し、設計時に考慮すべきトピックス及び設計書等に明示的に記載する要求事項を取りまとめたガイドラインとして作成されたものです。 具体的には、暗号鍵管理の必要性を認識してもらうために「
『脅威インテリジェンスの教科書』を公開しました！ - セキュリティコンサルタントの日誌から
2015年頃に脅威インテリジェンスという概念に出会ってから、色々調べて、講演・ブログで調査結果や自分の考えを公開してきましたが、一度その内容を体系的な資料として整理したいと考え、『脅威インテリジェンスの教科書』という形で執筆・整理したので、公開します。 脅威インテリジェンスの教科書 from Tomohisa Ishikawa, CISSP, CSSLP, CISA, CISM, CFE www.slideshare.net 先日公開した金融ISACの講演では、時間制約上、概要しかお話しできませんでした。それぞれの内容について、より詳細が知りたいという方は上記資料をご覧ください。 www.scientia-security.org なにかのご参考になれば幸いです。
私のセキュリティ情報収集法を整理してみた（2020年版） - Fox on Security
新年あけましておめでとうございます。早いものでこの記事を書くのも3回目になります。毎年年頭に更新している「私の情報収集法」について、今年も更新UPします。 ※私の方法はpiyokangoさんが2013年に書かれた「私のセキュリティ情報共有術を整理してみた。」、およびその記事の元となった根岸さんの2011年の「私のセキュリティ情報収集術」の影響を強く受けて、自分なりに試行錯誤しているものです。必ずしも多くのセキュリティ担当の方に向いている情報収集のやり方ではないかも知れません。 ■インプットに使っている情報ツール 情報収集に使っているツールはそんなに変わってません。忙しいセキュリティ担当の方は、いかにRSSをうまく使いこなすかがカギになるのかと思います。 ツール キタきつね寸評 備考（リンク） RSS Reader 去年から海外ニュースを拾うのに使い勝手が良かったので、このソフトを使っていま
このWeb APIってCSRF対策出来てますか？って質問にこたえよう - Qiita
前文 時々、このWeb APIってCSRF対策出来てますか？とか そのCSRF対策ってなんで安全なんですか？とか、そういう質問を友人・知人・同僚から受けます。 その質問に対して、都度回答をしているのですが、改めて記事としてまとめようかな、というのがこの記事です。 もし私の認識に穴・誤りがありましたら、ぜひ指摘お願いします。 前提事項 この記事中では、CSRF対策のみにフォーカスします。 そのため、以下はスコープ外です(無駄な議論回避のための前提事項です)。 セキュリティに銀の弾丸などないので、複数の脆弱性対策を組み合わせて、安全に行きましょう。 XSS脆弱性により、CSRFが可能である ブラウザの脆弱性により、CSRFが可能である XXXの脆弱性により、CSRFが可能である 前提知識 CSRF対策について語る上で必要な知識はいくつかありますが、この記事では以下の知識を前提に扱います。 ご存
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
same-site/cross-site, same-origin/cross-originをちゃんと理解する
