あなたのWebサービスの脆弱性を発見者から教えてもらう方法 - RFC9116が発表されました
先日、RFC9116が発表されました🚀 あなたのWebサービスに潜在する未知の脆弱性を誰かが見つけた時、それをあなたに連絡する方法を提示するsecurity.txtを標準化するものです。 この記事では何故これが必要だったのか、そして私たちがこれを実装する方法を簡潔に説明します。 なぜこれが必要だったのか https://securitytxt.org/のSummary(概要)にはこのように書かれています。 Webサービスのセキュリティリスクが、リスクの重大性を理解している独立したセキュリティ研究者によって発見された場合、それらを適切に開示するためのチャンネルが不足していることがよくあります。 その結果、セキュリティの問題が報告されないままになる可能性があります。 security.txtは、組織がセキュリティ研究者がセキュリティの脆弱性を安全に開示するためのプロセスを定義するのに役立つ標
colorsなどのnpmパッケージに悪意あるコードが含まれている問題について
追記: 2022年1月11日 2:29 JSTにDoS脆弱性としてセキュリティアドバイザーが出されて、悪意あるバージョン(1.4.1や1.4.2)はnpmからunpublishされ、npmの最新は安全なバージョンである1.4.0へと変更されました。 Infinite loop causing Denial of Service in colors · GHSA-5rqg-jm4f-cqx7 · GitHub Advisory Database 2022-01-08 に colors というnpmパッケージにDoS攻撃のコードが含まれたバージョンが1.4.44-liberty-2として公開されました。 GitHub: https://github.com/Marak/colors.js npm: https://www.npmjs.com/package/colors 問題についてのIssu
Log4jの深刻な脆弱性CVE-2021-44228についてまとめてみた - piyolog
2021年12月10日、Javaベースのログ出力ライブラリ「Apache Log4j」の2.x系バージョン（以降はLog4j2と記載）で確認された深刻な脆弱性を修正したバージョンが公開されました。セキュリティ関係組織では過去話題になったHeartbleedやShellshockと同レベルの脆弱性とも評価しています。ここでは関連する情報をまとめます。 １．何が起きたの？ Javaベースのログ出力ライブラリLog4j2で深刻な脆弱性（CVE-2021-44228）を修正したバージョンが公開された。その後も修正が不完全であったことなどを理由に2件の脆弱性が修正された。 広く利用されているライブラリであるため影響を受ける対象が多く存在するとみられ、攻撃が容易であることから2014年のHeartbleed、Shellshock以来の危険性があるとみる向きもあり、The Apache Software
「HTTPSはどのようにして人々を守るのか？HTTPSさえあればウェブは安全なのか？」についてMozillaが解説
インターネット上で目にする「HTTPS」や「HTTP」というワードについて、「どちらもウェブサイトの通信に関係していて、HTTPSの方がセキュリティ的に優れている」となんとなく理解はしていても、詳しいことは知らないという人は多いはず。ブラウザのFirefoxを開発するMozillaが、「HTTPSはどのようにしてインターネットユーザーを守るのか？HTTPSさえあればウェブは安全と言えるのか？」といった疑問について解説しています。 How does HTTPS protect you (and how doesn't it?) - The Mozilla Blog https://blog.mozilla.org/en/products/firefox/https-protect/ ◆HTTPSはどんな役割を持っているのか？ HTTPSは、従来のHTTPによるデータ通信をSSL/TLSプロト
GraphQL採用サービスに追加で脆弱性を報告した話 · GitHub
aini_graphql_vuln.md GraphQL採用サービスに追加で脆弱性を報告した話 前置き 個人の活動であり文責は全てmalaにあります。 網羅的に調べているわけではないので、自分が利用していたり、調査したサービスに他の脆弱性が無いことを保証するものではないです。 概要 ainiというサービス https://helloaini.com/ のGraphQLでの情報露出の脆弱性に関する記事を見て、追加で調べたところ、Webサイトやアプリ上から参照できない他のユーザーのフォロー/フォロワー関係をGraphQL経由で取得することが出来ることを発見した。 9月24日(金)の日付変わったころに報告したところ、迅速に修正された。修正されたようなので開示して良いか訪ねたところ、問題ないとの返信をもらった。 malaから問い合わせ 報告内容と、脆弱性が修正された旨をブログ、Twitter等で公
情報セキュリティに関係する基準、ガイドラインなど - rokujyouhitoma's blog
いつも見直すときに探し直す羽目になってしまうので情報セキュリティに関係する法規、基準、ガイドラインなどをまとめておく。 こうやってリストアップし俯瞰すると、多くは経済産業省、IPA。 基準、ガイドライン 営業管理秘密指針 https://www.meti.go.jp/policy/economy/chizai/chiteki/guideline/h31ts.pdf サイバーセキュリティ経営ガイドライン サイバーセキュリティ経営ガイドライン（METI/経済産業省） クラウドサービス提供における情報セキュリティ対策ガイドライン（第２版） https://www.soumu.go.jp/main_content/000566969.pdf Ref: 総務省｜報道資料｜「クラウドサービス提供における情報セキュリティ対策ガイドライン（第2版）」の公表 テレワークセキュリティガイドライン第５版（令和３
Cloudflareから簡単に「メールアドレス使い分け」ができる新サービスが登場、ワンクリックで可能なフィッシング対策も
アカウントへの侵入を防ぐためにパスワードを使い分けているという人でも、IDとして用いるメールアドレスを使い分けているというケースはあまり多くないはず。こうした現状を踏まえた新たなセキュリティ対策サービスとして、Cloudflareが2021年9月28日に、複数のメールアドレスが受信したメールを1つのメールアドレスに統合する「Cloudflare Email Routing」と、なりすましやフィッシング対策を強化する「Email Security DNS Wizard」を発表しました。 Easily creating and routing email addresses with Cloudflare Email Routing https://blog.cloudflare.com/introducing-email-routing/ Tackling Email Spoofing an
セキュリティエンジニア向けマテリアル - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 脆弱性・脅威情報収集用の巡回サイト一覧やユーザ・偉い人向けの説明資料，また，手帳に挿んでいると便利なドキュメント類をご紹介します． 実際の調査対応に使うツールについては，こちら（Windows編）とこちら（Linux編）をご参照ください． 渦中のサイトや怪しい情報源に訪問するときは，TORブラウザなどを使うことをお勧めします． （適宜更新中） 脆弱性・脅威情報収集 piyolog http://d.hatena.ne.jp/Kango/ ホットなセキュリティインシデントのまとめサイト．タイムリー． 運営しているPiyokango氏のTw
トラッキングに利用できない3rdパーティクッキー「CHIPS」の仕組み (partitioned属性) - ASnoKaze blog
3rd パーティクッキーの廃止計画が世間を賑わせています。一方で、3rdパーティクッキーには、トラッキング目的でないユースケースもあります。それらのために、3rdパーティクッキーの制限を緩和する「Cookies Having Independent Partitioned State (CHIPS)」という仕組みが検討されています。 この仕組みに則っていれば、制限のもと3rdパーティクッキーを使えるようになります。 もちろん、これはトラッキングが出来ないようになっています。 仕様: https://github.com/WICG/CHIPS Chromeの実装計画: 「Intent to Prototype: Cookies Having Independent Partitioned State (CHIPS)」 ユースケースについては、仕様の中で述べられていますのでそちらを参照ください
Fine-tune your App Transport Security settings - Discover - Apple Developer
At Apple, we believe privacy is a fundamental human right. When people connect to a public Wi-Fi hotspot, they expect to use your app to send and receive data without worrying that someone in the vicinity could intercept their connection and gain access to unencrypted data. Allowing even seemingly-innocuous data to remain unencrypted can expose people to snooping and fingerprinting by anyone on th
Let's Encryptのルート証明書切替周り(完結編) | おそらくはそれさえも平凡な日々
tl;dr 驚くべきハックにより旧Androidも引き続き証明書エラーなくサイトを閲覧できそうです いよいよ5/4に標準の証明書チェーンが切り替わります 前回までのおさらい Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる Let's Encryptの証明書切替周りその後 Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしています。現在は、IdenTrustのルート証明書(DST Root CA X3)が使われています。 正確に言うと、ISRGは新しい認証局なのでそのルート証明書の普及率も当然低く、中間証明書はIdenTrustのルート証明書でクロスサインされており、それが標準で使われています。標準がDSTになっているだけで、ISRGのルート証明書のチェーンの証明書も指定すれば今で
OpenSSLの脆弱性（CVE-2021-3450、CVE-2021-3449）に関する注意喚起
JPCERT-AT-2021-0015 JPCERT/CC 2021-03-26（新規） 2021-03-29（更新） I. 概要2021年3月25日（現地時間）、OpenSSL ProjectからOpenSSLの脆弱性（CVE-2021-3450、CVE-2021-3449）に関する情報が公開されました。OpenSSLには、X.509証明書の検証不備の脆弱性や細工した再ネゴシエーションのメッセージを処理する際にNULLポインタ参照が発生する脆弱性があります。脆弱性が悪用された場合、不正なCA証明書によって検証が回避されたり、OpenSSLが実行されているサーバーがサービス運用妨害（DoS）を受けたりする可能性があります。 脆弱性の詳細については、OpenSSL Projectの情報を確認してください。 OpenSSL Project OpenSSL Security Advisory [
え、HTTPSの転送なのにファイルも暗号化するんですか？？？
TL;DR 基本的には二重での暗号は不要 ただし、転送後も暗号化したまま使うなら、転送前から暗号化するのは良い ルールXを無邪気に追加して不整合のあるセキュリティルールを作ってはいけない はじめに 社内のセキュリティルールやスタンダードを決めるときに、HTTPSなのにVPN必須になってたりファイル暗号も必須になってたりするケースたまに見ます。今回は、それは実際に必要なことなのか？ セキュリティ的に有効なのか？ という点で考察をしていきたいと思います。 背景 二重三重に暗号化しても性能ペナルティが無いなら「なんとなく安全そうだから」でOKにしてしまいがちなのですが、これはよく考える必要があります。 というのも 「ルールXを追加することで既存のルールAと不整合が出る」 ってことは割とよくあるからです。具体的には「SCPのファイル転送は（SCPのセキュリティに不備があった時の）安全性のためにファ
ZeroSSL ならIPアドレスのサーバ証明書が取得できる - ASnoKaze blog
IPアドレスのサーバ証明書が欲しい場合があります。そうすれば、ドメインを取得せずともサーバとHTTPS通信ができるようになります。 その他にも例えばDNS over HTTPSではIPアドレスでアクセス出来るように、有効な証明書がセットされていたりします。 https://1.1.1.1 https://8.8.8.8 しかし、Let's Encryptでは、IPアドレスのサーバ証明書は取得できません ~$ sudo certbot certonly --nginx -d 160.16.124.39 Requested name 160.16.124.39 is an IP address. The Let's Encrypt certificateauthority will not issue certificates for a bare IP address.ZeroSSLでは出来
エンドツーエンド暗号化と法規制 – JPNIC Blog
dom_gov_team 2020年12月14日 インターネットガバナンス エンドツーエンド(E2E)暗号化(E2EE)とは、端末間の全部の通信経路でコンテンツを暗号化することを意味し、通信経路の途中の仲介者がデータを復号化して内容を読むことが事実上不可能となります。Whatsapp、iMessage、Signalなどのチャットサービスで主に使われているようです。利用者にとっては安心ですが、犯罪などに使われた例もあるため、法執行当局からはこれまでテロや児童虐待などの対策の際に問題となるという主張がなされてきました。 2020年秋の動きとして、E2E暗号化に関する7ヶ国共同の声明が公開され、かつEUでの決議案のリークがありました。本稿ではその内容をご紹介したいと思います。 ファイブアイズ諸国とインド・日本による声明 2020年10月11日、英国、米国、オーストラリア、ニュージーランド、カナダ
Cookieの新しい属性、SameParty属性について - ASnoKaze blog
ChromeでCookieのSameParty属性の開発が進められている (コミット)。 現在のところ「SameParty cookie attribute explainer」に説明が書かれている。 今回は、CookieのSameParty属性について簡単にメモしていく。 背景 トラッキング対策、プライバシーの観点でサードパーティクッキーは制限する方向に進んでいる。その制限をSame Partyの場合に緩和する仕組みを提供するのがSameParty属性の話である。 例えば、同一主体により運営されているドメインの異なるサイト (例えば、google.co.jp, google.co.uk) 間においては、いわゆる(cross-site contextsで送られる)サードパーティクッキーを許可しようという話です。 もともとは、First-Party Setsを活用しSameSite属性にFi
CloudflareやAppleなどが協力して新プロトコル「Oblivious DNS over HTTPS(ODoH)」を開発
CloudflareとAppleなどが協力して新しいDNSプロトコル「Oblivious DNS over HTTPS(ODoH)」を発表しました。ODoHを利用することで、これまでDNSリゾルバから確認できたクライアントの送信元IPアドレスを秘匿し、プライバシーを向上させることができます。 Improving DNS Privacy with Oblivious DoH in 1.1.1.1 https://blog.cloudflare.com/oblivious-dns/ Cloudflare, Apple and Fastly Create Improved, Private DNS https://www.webpronews.com/cloudflare-apple-and-fastly-create-improved-private-dns/ Oblivious DNS-ov
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://twitter.com/jingbay/status/1459554512365142024
【図解】https(SSL/TLS)の仕組みとシーケンス,パケット構造 〜暗号化の範囲, Encrypted Alert, ヘッダやレイヤについて～
安全なウェブサイト運営にむけて ～企業ウェブサイトのための脆弱性対応ガイド～ / 2021年3月 独立行政法人情報処理推進機構