聞いてるポッドキャストでセキュリティ情報収集どうしているのかといった話題があった*1ので、いい機会だから自分の行っているセキュリティ関連の情報収集をまとめてみた。 前提 どんな人 セキュリティに興味あるWebアプリケーションエンジニア*2 興味の範囲 Webアプリケーションにまつわるセキュリティ全般 サービス開発・運用まわりに関するセキュリティ 知りたい情報 関係ありそうな脆弱性情報 興味範囲の最近の話題やトレンド その他セキュリティ関係で話題になっていそうなこと 話題やトレンドはキーワードを拾い後から調べられるように脳にインデックスを作っておくのが目的で、網羅や詳細に知ることはあまり意識していない。 情報ソース 前提に書いた知りたい情報を、各種サイト・ブログ、Twitter、Podcast から収集している。 Twitter は脆弱性情報などスピードが重要なものからトレンドまで幅広く知れ
はじめに Go Secure Coding Practice とは コンテンツ一覧 良かったところ 注意すべきところ 最後に はじめに こんにちは。SRE の izzii です。 テックタッチのエンジニア規模もそれなりに拡大し、若手の採用も進んできたため、セキュアコーディングを徹底していきたいという思いがあり、まずは意識改革ということで勉強会を実施しました。セキュアコーディングを目的とした場合には教育だけでなく Static application security testing (SAST) の導入といった方法もあるのですが、まずは自分を含めた開発メンバーにノウハウをインストールすることにしました。セキュアコーディングへの意識が高まれば、いづれ SAST の導入の際に抵抗感も少ないだろうと考えています。いきなり SAST を導入しても、誤検知が煩くて浸透しないリスクもありうると考えてい
ritouです。 背景 これまで数年に渡り、「新規登録/ログイン時に登録状態がわかるレスポンスを返してくれるな。」というお話をしてきました。 SMSやEmailを入力して認証コードなどを送るタイプのログイン方法でも同様の実装は可能であり、表向きは「認証コードを送信したよ。受け取った値を入れてくれよな。」としつつ実際は既に登録済みだからログインからこい、未登録だから新規登録から来い見たいな内容を送りつつ、画面では正規のユーザーと同様のトークンなりを送り検証が絶対通らん! みたいなのを実装したりしています。 ではこれをWebAuthnなりネイティブ機能で提供されるFIDO認証でこれを実現したいとなった時にどうしたら良いか、細かく考えたらやっぱりめんどいなって話をします。 想定する環境 パスワード認証と組み合わせる2FA用途ではなく、FIDO認証のみでログインさせる 最初にユーザー識別を行うかど
2022年8月7日、米国のクラウドコミュニケーションプラットフォームサービスを提供するTwilioは従業員がスミッシングによるアカウント侵害を受け、その後に同社サービスの顧客関連情報へ不正アクセスが発生したことを公表しました。また、Cloudflareも類似の攻撃に受けていたことを公表しました。ここでは関連する情報をまとめます。 米国2社が相次ぎ公表 TwilioとCloudflareは、従業員に対し、何者かがIT管理者からの通知になりすましたSMSを送り、記載されたURLからフィッシングサイトへ誘導される事例が発生したことを報告。 2022年8月7日 Twilio Incident Report: Employee and Customer Account Compromise 2022年8月10日 Cloudflare The mechanics of a sophisticated
【重要なお知らせ/続報】個人情報漏洩に関するお詫びとお知らせについて 2022年10月26日 2022年8月4日に公開した「【重要】個人情報漏洩に関するお詫びとお知らせについて」にて公表いたしました、弊社の会員サイト「ウェブステーション」での情報漏洩の可能性につきまして、漏洩の原因となりました画面表示を最適化するサービスを提供していた企業(株式会社ショーケース)の詳細な調査結果により、情報の一部が漏洩した可能性がある期間が、公表当時にお伝えした期間とは異なることが判明いたしました。 会員様をはじめ、関係者の皆様に多大なるご迷惑、およびご心配をおかけする事態となりましたこと、深くお詫び申しあげます。 なお、判明した期間により、新たに情報が漏洩した可能性のある会員様には、本日Eメールにてお詫びとお知らせを個別に送らせていただいております。 会員様をはじめ関係者の皆様には重ねてお詫び申しあげます
はじめに こんにちは。 セキュリティエンジニアの@okazu-dm です。 この記事は、Auth0のアクセストークンの保存方法について解説した前回の記事の補足となる記事です。前回の記事の要旨をざっくりまとめると以下のようなものでした。 Auth0はデフォルトではアクセストークンをブラウザのメモリ空間上にのみ保存するin-memory方式であり、XSSへの耐性のなさ等の理由でlocalStorageで保存することを推奨していない しかし、XSSでアクセストークンを奪取できるのはin-memory方式でも同じのはず(検証は行いませんでした)。localStorage方式を過度に忌避する必要はないのではないか なお、Flatt Securityの提供するセキュリティ診断はAuth0に限らずFirebase AuthenticationやAmazon CognitoなどのIDaaSのセキュアな利用
Cisco Talos Intelligence Groupは8月10日(米国時間)、「Cisco Talos Intelligence Group - Comprehensive Threat Intelligence: Cisco Talos shares insights related to recent cyber attack on Cisco」において、2022年5月24日に同社がサイバー攻撃を受けたと伝えた。調査の結果、従業員の個人的なGoogleアカウントがサイバー犯罪者に悪用されたことから、攻撃が始まったことがわかったと報告している。 Cisco Talos Intelligence Group - Comprehensive Threat Intelligence: Cisco Talos shares insights related to recent cyber
Products Communications Messaging Send and receive multichannel text and media messages in 180+ countries
August 3, 2022 npm query is a new top-level command as of npm v8.16.0 which accepts a Dependency Selector (as defined in the Dependency Selector Syntax Specification) & returns a filtered JSON Array/NodeList of dependencies from your project. We believe this capability has been a missing piece of the package management ecosystem; With its introduction we hope to unlock the potential for developers
さくらインターネットの田中氏は「クラウドサービスの利用が業務委託やアウトソーシングの延長として考えられていることも問題です。アウトソーシングサービスなど外注先に何かを委託する時に使われていたチェックシートを、クラウドサービスの利用でも使われていることにも疑問を感じます」と指摘する。 加えて、サービス事業者側のコスト問題もある。田中氏は「システム開発を外注する場合は1人月で数十万レベルの単価になりますが、クラウドサービスは1ユーザー当たり月額数百円、高くても数千円程度でしょう。チェックシートの個別対応コストを考えると、サービス事業者としては複雑なところです」ともコメントする。 田中氏のコメントに対して、青野氏は次のように意見する。 「結局、ユーザー企業からバラバラのフォーマットで届くセキュリティチェックシートの対応コストを誰が支払っているかというと、最終的には利用者が払うわけです。ユーザー企
README.md サブドメインをユーザーホスティングサイトに使うときのパターン hoge.example.com でユーザが作成したサイトをホスティングして、任意のJavaScriptを実行できる状態にしたいケース。 サブドメインを分けることで、Fetch APIなどはSame Origin Policyを基本にするため、別のサブドメインや example.com に対するリクエストなどはできなくなる。 一方で、CookieはSame Origin Policyではない。 デフォルトでは、hoge.example.com から example.com に対するCookieが設定できる。 これを利用したDoS(Cookie Bomb)やこの挙動を組み合わせた別の脆弱性に利用できる場合がある。 The Cookie Monster in Your Browsers - Speaker Dec
ユーザに対して、そのユーザ名のサブドメインやメールアドレスを払い出すWebサービスがあります。 しかし、特定のサブドメインやメールアドレスは特別な用途で使われているものもあります。そのようなサブドメインやメールアドレスを一般ユーザに払い出してしまうと危険です。 現在、IETFでは仕様上利用用途が決められている、それらのラベルをとりまとめる「Dangerous Labels in DNS and E-mail」というdraftが提出されています。 今回はそれを眺めていきます。 (あくまでIETFの取り組みであり、仕様上定義されているものをとりまとめています。クラウドサービスや特定ベンダーで特別利用しているものは現在含まれていません。) サブドメイン ここでとりあげるサブドメインは、利用用途が決まってるため一般ユーザに払い出すべきではありません。(例: mta-sts.example.com)
経済産業省は、本日、割賦販売法に基づくクレジットカード番号等取扱業者である株式会社メタップスペイメント(法人番号9011101027550)に対し、同法第35条の17の規定に基づく改善命令を発出しました。 1.事業者の概要 (1)名称:株式会社メタップスペイメント(以下「同社」という。) (2)代表者:代表取締役 和田 洋一 (3)所在地:東京都港区港南二丁目16番1号 品川イーストワンタワー7階 (4)事業内容:決済代行業等 2.処分内容 割賦販売法(昭和36年法律第159号。以下「法」という。)第35条の17に基づく改善命令 法第35条の16に規定するクレジットカード番号等の漏えい、滅失又は毀損の防止その他のクレジットカード番号等の適切な管理のために必要な措置として、以下の措置を講じること。 同社が同社とクレジットカード決済に係る契約を締結しているクレジットカード等購入あっせん関係販売
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く