Ubie プロダクトプラットフォーム所属の nerocrux です。今回は Ubie において、 LINE ログインを成功させるために工夫したことをいくつか紹介したいと思います。 面白いこともすごいこともやってないし、対象読者もよくわかりませんが、興味があったら読んでみてください。 はじめに 症状検索エンジン「ユビー」について Ubie では、症状検索エンジン「ユビー」(以下、ユビーと呼ぶ)という一般ユーザー向けのサービスを展開しています。ユーザーが簡単な質問を回答することで、関連する病名や、適切な受診先情報を得ることができるサービスとなっています。 ユビーは Web ブラウザ経由で利用されることが多いですが、iOS / Android のネイティブアプリも提供しています。 ユーザーがユビーを利用する際に、ユビーのアカウントを作成することで、一貫性のある問診・受診・受診後のフォローアップ体
米国国土安全保障省サイバーセキュリティインフラセキュリティ庁(CISA)は2024年6月18日(米国時間)、ネットワークセキュリティにおけるガイダンスを公開した。CISAは以下のように説明している。 ガイダンスは、CISAの他、連邦捜査局、ニュージーランドおよびカナダのセキュリティ責任者が共同執筆した。あらゆる規模の企業の経営者に対し、ネットワークアクティビティーの可視性を高めるゼロトラスト、SSE(Security Service Edge)、SASE(Secure Access Service Edge)などのより堅牢(けんろう)なセキュリティソリューションへの移行を推奨している。加えて、このガイダンスは、従来のリモートアクセスとVPNの導入に関連する脆弱(ぜいじゃく)性、脅威、慣行およびリモートアクセスの誤った構成によって組織のネットワークにもたらされる固有のビジネスリスクを組織がよ
はじめに はじめまして!レバテック開発部でレバテックプラットフォーム開発チームに所属している塚原です。 直近に認証・認可周りの改修を予定しているため、チーム内で認証・認可の基礎からOAuth・OpenID Connectの仕組みを学ぶ勉強会を実施しました。今回はそこで学んだことのうち、認証・認可の基礎とOAuthの仕組みをまとめます。また、WebフレームワークとしてHono、JavaScriptランタイムとしてBunを使って、OAuthクライアントを実装してみます。 対象読者 認証と認可の違いってなんだっけ...?という人 Basic認証やDigest認証てなんだっけ...?という人 OAuthはライブラリ使って実装してるから仕組みよくわかっていない...という人 OAuthのクライアントの実装って何をすればいいんだっけ...?という人 認証・認可の基礎 2024/7/18 追記 こちらで
はじめに 2023年4月に基盤エンジニアとして Ubie に入社しました nerocrux です。主に Ubie の ID 基盤の開発と保守運用を担当しています。 この記事は、2023 Ubie Engineers アドベントカレンダー 5 日目の記事となります。 Ubie では、モジュラモノリスを採用しつつ、マイクロサービスアーキテクチャも採用しており、領域によってサービスを分けて、それぞれの担当チームが開発と保守運用をしています。 クライアントから一つのリクエストを受け取ったあとに、Ubie のバックエンドではリクエストを受け取ったサービスだけがそのリクエストを処理することもあれば、別のサービスにディスパッチし、複数のサービスがひとつのリクエストを処理して結果を返すこともあります。 マイクロサービス間の通信が Ubie の内部で発生したとしても、必ずしも無制限で自由に行われていいわけで
ムーザルちゃんねるのムーです。今回は zaru さんと、Next.js のセキュリティについて話しました。 セキュリティについては様々あると思いますが、今回は以下の3点をピックアップして話しました。 Client Components の Props から露出する Server Actions の引数に注意 認証チェックをやってはいけない場所、やって良い場所 これらは、Next.js 入門者がうっかりとやってしまうリスクがあるものです。 このような罠は、アプリケーション自体は正常に動くので、知らないうちにはまってしまいますし、自力で気づくのも難しいものです。もしも知らないものがあれば、ぜひご確認ください。 楽しくて、安全な Next.js 生活をお送りください! Client Components の Props から露出する これは、シンプルで当たり前といえば当たり前ですが、Client
脆弱性検査をしていてしばしば出くわすのは、他人のCookieの値を操作できるとXSSやセッション固定等の攻撃が成功するようなWebアプリケーションです。 このようなアプリがあると、業界的には「Cookie Monsterという問題がありまして、、、でも、、、基本的に現状のブラウザではリスクは低いです」みたいな話がされることが多いのではないかと思います。 本日の日記では、それ(Cookie Monster)以外にも状況によっては考慮すべきことがある、という話をしたいと思います(過去の日記でも少し書いた話ですが、もう少しちゃんと書いておこうと思います)。 通信経路上に攻撃者がいる 被害者のブラウザとサーバの通信経路上に、アクティブな攻撃者がいると想定しましょう。 そのような状況では、攻撃者は正規のサーバになりかわってブラウザと通信をしたり、ブラウザと正規のサーバで交わされる通信に介入することが
英語の「Authentication」を整理する ここからは先ほどの分類で言うところの「ユーザ認証」としての「認証」、つまり英語の「Authentication」に該当する「認証」について、さらに整理を進めていきます。 先ほど、「ユーザ認証」を「システムを利用しようとしているユーザを、システムに登録済みのユーザかどうか識別し、ユーザが主張する身元を検証するプロセス」と説明しました。「ユーザの識別」と「身元の検証」はユーザ認証に欠かせませんが、実際は他にも「ユーザの有効/無効状態の確認」や「検証に成功した場合の身元の保証(アクセストークンの発行等)」などの処理も一般的にユーザ認証のプロセスには含まれます。 ここで冒頭の「○○認証」を振り返りましょう。パスワード認証、SMS認証、指紋認証、顔認証は実はここで言うユーザ認証には該当せず、ユーザ認証中の一処理である「身元の検証」を担っていることがお
CSRF 対策は One Time Token を form なりに付与して、サーバ側でチェックすれば良い。 それをデフォルトでサポートしてるフレームワークなどもあるし、なくてもライブラリでいくらでも対応できる。 どうせ完全にステートレスなサービスはなかなかないので、サーバ側に redis や memcache を用意するのも別に大変じゃない。 なので、 CSRF 対策として Token を付与するのは、最も安全で推奨できる方式ではある。 っていうのを踏まえた上で、もう SameSite=Lax デフォルトだけど、今でも Token 必須なの?みたいなのがたびたび話に出るので、いい加減まとめる。 前提 この話は、スコープがどこなのかによって話が多少変わるので、そこを絞る。 今回は Passive ではなく Active に対策していく場合を考えるので、前提をこうする。 SameSite=l
新年あけましておめでとうございます。毎年この時期に更新している「私の情報収集法(2024年版)」を今年も公開します。 ■はじめに サイバー攻撃は国境を越えて発生するため、ランサムウェア、フィッシング、DDoS攻撃など、近年のサイバー脅威の常連となっている攻撃者(脅威アクター)が主に海外にいることを考えると、世界の脅威動向を理解することが年々重要になっています。 海外から日本の組織が受けるサイバー攻撃の多くでは、国際共同オペレーション等の一部のケースを除き、日本の警察が犯罪活動の協力者(出し子、買い子、送り子)を摘発することはあっても、サイバー攻撃の首謀者(コアメンバー)を逮捕するまで至るケースはほとんどありません。 誤解を恐れずに言えば、日本の組織は海外からの攻撃を受け続けているのに、海外で発生したインシデントや攻撃トレンドの把握が遅れ、対策が後手に回っているケースも多いように感じます。最
はじめに こんにちは!AWS事業本部コンサルティング部の和田響です。 AWS re:Invent 2023では、ラスベガスにて現地参加していました。 この記事では、現地で公聴したBreakout Sessionの「SEC227 | Improving security through modern application development」について紹介します。 概要 In this session, explore security practices used in modern application development and how these address common security challenges found in legacy applications. Learn patterns for integrating security early in t
概要 どうもukmashiです。今年は年末なのに、年末感がなくて逆にびっくりしますね。 年末で時間を持て余してるので、燻製を作りながら、年末に仕事で練っていたフロントエンドにおける認可について、整理しようと思います。 なお、RBACやPBACなどの認可の種類に対する考え方については基本的に触れません。 本記事は2部作です。 本記事は3部作になりました。 フロントエンドの認可ついて(1)← 本記事 ReactやVueを始めとして、SPA、Next.js、Nuxt.jsに関する認可についてまとめます。 フロントエンドの認可ついて(2) 後半では、FEとBEで認可の処理が二元化してしまうのをどうクリアするかの提案です。 フロントエンドの認可ついて(3) 2での提案を具体的にReactのコードとして落とし込みました 本記事での用語 話を始める前に、用語整理しておきます。 Page ブラウザで描画さ
*本記事は STORES Advent Calendar 2023 6日目の記事です こんにちは。セキュリティ本部のsohです。 現在、弊社ではスマホアプリ診断内製化の準備を進めています。 同じようにスマホアプリの脆弱性診断を内製化したい、というニーズがある会社は多く存在しますが、実際のところ、スマホアプリを対象とした脆弱性診断士の確保は困難であり、外部ベンダーの方にすべてお願いせざるを得ないケースも多いかと思います。 また、その情報の少なさから、スマホアプリ診断を実施したいと考えている開発者や脆弱性診断士にとっても、「何をやればいいのか」「何から始めればいいのか」がわからないものである場合は多いかと思います。 そこで、この記事では「スマホアプリ診断って実際何をしているのか」と疑問を持つ方をターゲットとして、一般的なスマホアプリ診断の検証要件や検証方法について解説します。 要件とガイドライ
ritou です。 これで話しました。 pwanight.connpass.com 発表資料と発表内容を公開します。 発表資料 speakerdeck.com 発表内容 台本チラ見しながら話したので実際にはこのとおりになってなかった部分もあります。 今日は、パスキーについて話します。 細かい自己紹介は省略します。 色々宣伝したいものがありますがブログに書きます。 今日の内容ですが、初めにパスキーの概要についてざっと触れます。 続いてWebアプリケーションにパスキーを導入するとなった場合にどこから手をつけるべきかというところに触れた後、一番の悩みどころになりそうなログインのUI/UXについて紹介します。 概要からいきましょう。 パスキーの紹介記事もたくさん出ているので要点だけまとめます。 パスキーとは「パスワードが不要な認証方式」であり、それを支える仕様はFIDOアライアンスとW3Cにより策
Architecture styles define how different components of an application programming interface (API) interact with one another. As a result, they ensure efficiency, reliability, and ease of integration with other systems by providing a standard approach to designing and building APIs. Here are the most used styles: SOAP: Mature, comprehensive, XML-based Best for enterprise applications RESTful: Popul
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く