はじめに 最近のAI関連技術の進化は目まぐるしいですよね。私たちfreeeの開発組織でも、世の中のトレンドに追従、あるいは先回りする形でGitHub Copilotや社内から安全にLLMを利用するための基盤整備にも取り組んできました。そして2025年、これまでの検証フェーズを経て、AI活用をさらに加速させるべく、AIツールの本格導入を進めています。 現在、freeeの開発現場では主に GitHub Copilot、Cline、そしてDevinといったAIツールが活用されています（他にも細かなツールはありますが！）。特に最近全開発者向けに開放されたClineは、今後の開発スタイルを変える可能性を秘めていると注目しています。 この記事では、そのClineを全社導入するにあたり、私たちがどのように考え、どのような課題に直面し、そしてどう対策してきたのかをお伝えできればと思います。この記事が、AI
CVE-2024-9956 - PassKey Account Takeover in All Mobile Browsers In this blogpost I will go over a vulnerability I found in all major mobile browsers that allowed an attacker within Bluetooth range to take over PassKeys accounts by triggering FIDO:/ intents. TLDR An attacker within bluetooth range is able to trigger navigation to a FIDO:/ URI from an attacker controlled page on a mobile browser, al
開発本部 MIXI M事業部の ritou です。 本投稿はMIXI DEVELOPERS Advent Calendar 2023 ２日目の記事です。 先日、MIXI Mはパスキーによる認証をサポートしました。 それに続き、Google/Appleアカウントを利用したソーシャルログインをサポートしましたので紹介します。 経緯 MIXI Mではサービス開始当初から、デフォルトの認証方法であるSMS/Email OTPを超える安全性と利便性、そして費用面のバランスを実現できる認証方法を検討していました。 パスキーによる認証をサポートしたことにより、安全性、利便性とフィッシング耐性を享受できるようになりました。これまでのようなSMSやメール送信を行わないことにより、送信コストの削減という効果もあります。しかし、非対応環境やクロスプラットフォームでの利用、そしてまだまだパスキー自体の認知度が低い
個人的に「Webサービスの公開前チェックリスト」を作っていたのですが、けっこう育ってきたので公開します。このリストは、過去に自分がミスしたときや、情報収集する中で「明日は我が身…」と思ったときなどに個人的にメモしてきたものをまとめた内容になります。 セキュリティ 認証に関わるCookieの属性 HttpOnly属性が設定されていること XSSの緩和策 SameSite属性がLaxもしくはStrictになっていること 主にCSRF対策のため。Laxの場合、GETリクエストで更新処理を行っているエンドポイントがないか合わせて確認 Secure属性が設定されていること HTTPS通信でのみCookieが送られるように Domain属性が適切に設定されていること サブドメインにもCookieが送られる設定の場合、他のサブドメインのサイトに脆弱性があるとそこからインシデントに繋がるリスクを理解してお
ritou です。 これについての話です。 この辺りずっとやってると「認証認可について詳しくなりたいです！」「OIDCに興味があります！」みたいなところから「何をやればいいですか！？」みたいなことを聞かれたりします。(やりたいことやればいいじゃんと思いつつ) 昔は 年に一回ぐらいIdPを作りましょう なんて言っていた時期がありますが、まぁそう簡単にできるものでもありません。ふじえさんの記事をdisっているわけではないですが、OIDCのところから始めても他にやることが多すぎて結構つらいのです。 何から始めたら良いか 現状のおすすめとしては、 Webアプリケーションフレームワークを使って単一アプリケーションを動かして、既存コードを追ったり拡張できるならやってみて色々細かい部分を理解するところから始めましょうというところです。 なんと、ひと昔前にQiitaに溢れたようなやり方ですが どのフレーム
(4/14 表記揺れなどのコメントいただいたので、少し修正、追記しました。) ritouです。 私のタイムラインによく出てくる、この辺りの話っていつになってもしっくりこない人が多いと思います。 OAuth認証👮 : アプリケーションがユーザー情報取得を提供するAPIを叩いて受け取ったユーザー識別子を使って新規登録やログインさせてはいけない。OIDCのIDTokenを使え ユーザーIDが取得できればログインさせていいのではないか IDTokenはユーザーIDを含むJWTだが、どうしてこれは良いのか デジタル庁が進めるマイナンバーカードを用いた個人向け認証アプリケーション(以下、認証スーパーアプリ)の用途 マイナンバーカードを用いた本人確認は既にいくつかの民間サービスで使われているが、ログインに使えるとはどういう事なのか デジタル庁からは スマホ用電子証明書搭載サービス という物も出ているが
【8/5追記】 いつもご愛顧いただきありがとうございます。ニコニコ運営チームです。 大変お待たせいたしました。 8月5日（月）15時より、新バージョン「帰ってきたニコニコ」として、「ニコニコ」サービスを再開いたしました。 バージョン名の詳細などについては下記お知らせをご確認ください。 8/5ニコニコサービスの再開と新バージョン「帰ってきたニコニコ」のお知らせ 帰ってきたニコニコをよろしくお願いいたします。 【8/1追記】 いつもご愛顧いただきありがとうございます。ニコニコ運営チームです。 2024年8月5日（月）からのニコニコ動画・ニコニコ生放送をはじめとする「ニコニコ」サービスの再開にあたり、再開状況の詳細をお知らせいたします。 また、サービス再開を記念して、ニコニコでは8月5日（月）よりさまざまイベントも開催いたします。 詳しくは下記お知らせをご確認ください。 8/5ニコニコサービスの
DNSは趣味でやっているだけですし有識者のレビューを経ているわけでもないので誤りを含むかもしれませんが、DNS界隈には優しい人しかいないのできっと丁寧に指摘してくれるはずです。 追記：めちゃくちゃ丁寧にレビューしていただいたので修正いたしました。森下さんほどの方に細かく見ていただいて恐れ多いです...（学生時代に某幅広合宿で森下さんの発表を見てDNSセキュリティに興味を持った） 4万文字を超える大作、おつかれさまです。わかりやすく書けていると思いました。 ざっと読んで、コメントしてみました。ご参考まで。https://t.co/bVj5WeFHQr https://t.co/ku5NOx6ua8— Yasuhiro Morishita (@OrangeMorishita) 2024年2月19日 要約 背景 詳細 DNSSECとは？ DNSSECの可用性 鍵タグの衝突 攻撃内容 SigJam
はじめに こんにちは。 セキュリティエンジニアの@okazu-dm です。 この記事は、Auth0のアクセストークンの保存方法について解説した前回の記事の補足となる記事です。前回の記事の要旨をざっくりまとめると以下のようなものでした。 Auth0はデフォルトではアクセストークンをブラウザのメモリ空間上にのみ保存するin-memory方式であり、XSSへの耐性のなさ等の理由でlocalStorageで保存することを推奨していない しかし、XSSでアクセストークンを奪取できるのはin-memory方式でも同じのはず(検証は行いませんでした)。localStorage方式を過度に忌避する必要はないのではないか なお、Flatt Securityの提供するセキュリティ診断はAuth0に限らずFirebase AuthenticationやAmazon CognitoなどのIDaaSのセキュアな利用
長いので答えだけ知りたい 暗証番号(PIN)無しで利用者証明が可能な特定機関認証を使用しているからです。 特定機関認証は特定機関認証用の公開鍵証明書と秘密鍵をあらかじめ提供されている必要があるため、汎用的には使えません。 マイナンバーカードの保険証利用について マイナンバーカードの保険証利用が宣伝されるようになりました。 マイナンバーカードの保険証利用について（被保険者証利用について）より引用 マイナンバーカードの健康保険証利用申込はマイナポータルなどから行います。 マイナンバーカードの健康保険証利用について～医療機関・薬局で利用可能～より引用 このマイナンバーカードの保険証利用ではマイナンバーを利用することはありません。マイナンバー法により定められた「特定個人情報の提供の制限」で認められる利用範囲ではないからです。このことは公式のFAQにも書いてあります。 Ｑ９．医療機関・薬局がマイナン
自社のクラウド環境に侵入され、データベースから経営に欠かせないデータを持ち出される。バックアップも消され、データを取り戻したければ、身代金を支払うよう要求される──企業にとって絶対に直面したくない事態の一つだ。しかしこのシチュエーションをあえて再現し、訓練という形で自社のCEOに身代金まで要求した企業がある。クラウド会計サービスを提供するfreeeだ。 freeeは2021年10月、標的型攻撃とランサムウェアを組み合わせたシナリオを基に全社的な訓練を実施。AWS上のDBからデータを盗み出し、バックアップを消した上で、自社のCEOに社内SNSを通して身代金を要求したという。訓練を主導したのは、製品やサービスのセキュリティ向上を目指す社内組織「PSIRT」だ。 訓練を実施した背景には、情報システム部などのIT部門だけでなく、経営層まで巻き込みたい考えがあったという。同社のPSIRTが取り組んだ
鍵がいっぱいあるよこの記事は Eureka Advent Calendar 2021 の 13日目の記事です。 はじめにこんにちは、エウレカ SREチーム のハラダです！ 2020年頃から今年にかけて、 エウレカのSREチームとSecurityチームではAWS IAMのセキュア化を注力ポイントのひとつとして、継続的に取り組んできました。 本記事では、その実践から学んできたIAM管理で守るべき大原則および、具体的にどうやってセキュアな理想像に近づけてきたか、今後の方向性などを話したいと思います。 Why “IAM” so important ?そもそもなんでIAMが注力ポイントなの？と疑問に思われる方もいるでしょう。 クラウドの大きな強みである「すべてをAPI経由で操作できる」という性質ゆえに、IAMは大きなAttack Surfaceでもあります。 Gartner社の予測によると、2023
おはようございます、ritouです。 先日のWWDC2021の "Move beyond passwords" というセッションにて発表された "Passkeys in iCloud Keychain" という仕組みについてどんなものかを紹介します。 developer.apple.com WebAuthn 数年前からパスワード認証を置き換えると言われ続けている認証技術の一つである "WebAuthn" (やFIDO)という技術をご存知でしょうか。(ご存知ない方は "WebAuthn builderscon" "WebAuthn droidkaigi" などで検索してみましょう) 今回の話をするにあたって、WebAuthnがどんなものかをある程度理解しておく必要があります。 公開鍵暗号の仕組みを利用 パスワード認証のようにユーザーとログイン対象のWebアプリケーションがパスワードを共有する
前回の記事で (Perfect) Forward Secrecy (FS) のテーマを取り上げたが、これは TLS/SSLだけに限定した話ではない。そこで今回はメールやチャットなどのメッセージングの話題を取り上げたいと思う。 PGP メールにおける End-to-Endの暗号化としては Pretty Good Privacy (PGP) が以前から広く使われている。NSAの内部情報をリークした Edward Snowden氏もジャーナリストと連絡を取るにあたって、必ずPGPによる暗号化を行うように要求したという。さて、PGPでは各メッセージの暗号化に使われるセッション鍵 (毎回ランダムに生成される) を受信者の公開鍵で暗号化して送る。また各メッセージのハッシュに対して送信者の秘密鍵を用いて署名を行う。一方の受信者は自身の秘密鍵でセッション鍵を復号し、この鍵で暗号化されたメッセージを復号する
お疲れ様です。ritouです。 OAuth 2.0 / OIDC 実装の刺激が欲しくなったので(?)、Authlete 社が公開しているナレッジサイトの OIDC / OAuth 2.0 に関する部分を読むことにしました。 kb.authlete.com この記事は、OAuth 2.0 / OIDC を完全に理解した上で Authlete というプロダクトについてなんとなくイメージがついていないとニヤニヤできないかもしれません。 Authlete は "サードパーティーアプリケーションから Web APIへのアクセス制御を行うために必要とされる『認可』の仕組みを提供するクラウドサービス" ですとどこかに書いてありました。 これは個人的な考えですが、RFCなどで定義された仕様を利用するプロダクトというのは、仕様で定義されている機能を設計/実装と、仕様で定義されていない部分や複数の仕様で定義さ
ちょっとでもセキュリティに自信がないなら、 Firebase Authentication を検討しよう （※ こちらの参照記事の内容自体に不備があるとか甘いとか指摘するものではないんですが、勝手に枕として使わせてもらいます） 上記記事は、Firebase Authenticationが提供するJavaScript APIを使ってJWTのトークンを取得し、自前のサーバにHTTPのヘッダで送りつけて検証をさせることで、認証の仕組みをセキュアかつかんたんに実現しよう、という内容です。 このようにJavaScriptのAPIでトークンを発行して自前バックエンドのAPI認証につかう方法はAuth0のSDKなどでも行われていますので、IDaaSをつかってSPAを開発する場合には一般的なのかもしれません。 話は変わりますが、SPAの開発に携わっている方は「localStorageにはセッション用のトー
0. 短いまとめ 300万以上の証明書の失効を迫られたLet's Encryptのインシデントは「Golangでよくある間違い」と書かれているようなバグが原因でした。 1. はじめに、 Let's Encryptは、無料でサーバ証明書を自動化して発行するサービスを行う非営利団体として2014年に設立されました。 2015年にサービス開始されると証明書の発行数はぐんぐん伸び、先月末のプレスリリースでは累計10億枚のサーバ証明書を発行したことがアナウンスされました「Let's Encrypt Has Issued a Billion Certificates」。CTLogの調査から、2020年2月末の時点では有効な全証明書の38.4%がLet's Encryptの証明書であるとみられています「Certificate Validity Dates」。 無料の証明書を提供してもらえるのは非常に嬉し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く