"Same-site" and "same-origin" | Articles | web.dev
"Same-site" and "same-origin" Stay organized with collections Save and categorize content based on your preferences. "Same-site" and "same-origin" are frequently cited but often misunderstood terms. For example, they're used in the context of page transitions, fetch() requests, cookies, opening popups, embedded resources, and iframes. This page explains what they are and how they're different from
シングルサインオンのSAMLライブラリに脆弱性、認証かわされる恐れ
異なるドメイン間での認証連携規格「SAML」を使った複数のシングルサインオン（SSO）サービスに脆弱性が発見され、米セキュリティ機関CERT/CCが2月27日に脆弱性情報を公開した。 CERT/CCによると、この脆弱性を悪用された場合、リモートの攻撃者によってSAMLコンテンツが改ざんされ、SAMLサービスプロバイダーの認証をかわされてしまう恐れがある。 この問題は、SSOツールなどを提供するDuo Securityが発見した。2月27日の時点で、同社の「Duo Network Gateway（DNG）」のほか、OneLoginの「python-saml」「ruby-saml」、Cleverの「saml2-js」など、複数のベンダーのSAML処理ライブラリで脆弱性が確認されている。 CERT/CCの脆弱性情報では、CiscoやGitHub、Google、Microsoftなどが影響を受ける
RPCに特化したGoogleのセキュリティ通信ALTSとは何か - ぼちぼち日記
はじめに 昨年、Googleから Google Cloud Platform に関するWhitePaperがいくつか公開されました。その中でGoogleのサービス内部で使われている新しいALTSというプロトコルを説明した文書「Application Layer Transport Security」は、読んでみると非常に面白く、セキュアなサービス間通信には本当に何が必要なのか、といったことを改めて深く考えさせられるものでした。物理的なマシンからサービス運用まで、ALTSがカバーする範囲は幅広い領域に渡り、あの巨大なGoogleのサービスをよくここまでまとめ上げたものだとホント感心させられます。 以前から、Googleはデータセンタ内のサービス通信までも暗号化を進めていると言われていました。それは、2013年にエドワード・スノーデンが暴露した資料が、Googleのデータセンタ内部の通信データ
DDoSMon - Global DDoS Attack Monitoring
Open & Free Open for security community, Free to use and cite. Realtime DDoS Detection CDN aware, track new ip updates in realtime Instant Email Notification Elaborate Attack Report Full report with detailed break down Get insights about the attack RESTful API Integration DDoSMon with your security infrastructure. How does DDoSMon work? We have partnership with multiple network service providers,
googleの新しい時刻同期プロトコル Roughtimeとは - ASnoKaze blog
[追記] 2020年1月時点の動向について、新しく記事を書きました asnokaze.hatenablog.com Googleの「Adam Langley氏のブログ」で、新しい時刻同期プロトコルについて紹介されている。このRoughtimeは特定のタイムサーバに依存しないセキュアな方法で時刻同期を行うことを目的としたプロトコルです。すでに、googleのサーバで動作しており、roughtime.sandbox.google.com:2002に向けて公開されている専用クライアントで接続できる。 現在のセキュリティは現在の時刻に依存しており、その重要性はましています。証明書の有効期限や、OCSPレスポンス、Kerberosのチケット、DNSSECの応用やPGP鍵といった機能でも重要です。しかし、Chromeの証明書エラーのうち25%はローカルの時刻に起因するとしているとしています。 現在、最
インターノット崩壊論者の独り言 - 開いたパンドラの箱 - 長年放置されてきた DNS の恐るべき欠陥が明らかに
EPIC2014 Google Public DNS (8.8.8.8, 8.8.4.4) および Cloudflare (1.1.1.1, 1.0.0.1) 経由では本サイトにアクセスできないよう措置させて頂いております。 本日、JPRS がようやく重い腰をあげて注意喚起を発してくれましたが、その内容は危険性をよく理解して対策をとるにあたって十分な情報が含まれているとはいえません。 一方で注意深い攻撃者が探せば、ネット上にはすでに深刻な攻撃を行うのに必要な情報は十分に流れています。特に、JPRS が3月に慌てて co.jp などにこっそり入れた署名付き TXT レコードは大きなヒントに見えます。 DNS に詳しい攻撃者であれば、攻撃手法に辿りつくのは時間の問題でしょう。(すでに攻撃は行われているかも知れません) 長く秘密にしておくことは得策ではないと判断し、防御する側の心構えと手助けにし
（緊急）キャッシュポイズニング攻撃の危険性増加に伴うDNSサーバーの設定再確認について（2014年5月30日更新）
--------------------------------------------------------------------- ■（緊急）キャッシュポイズニング攻撃の危険性増加に伴う DNSサーバーの設定再確認について（2014年4月15日公開） ～問い合わせUDPポートのランダム化の速やかな確認・対応を強く推奨～ 株式会社日本レジストリサービス（JPRS） 初版作成 2014/04/15（Tue） 最終更新 2014/05/30（Fri） （対策に関するDNS運用者向け文書へのリンクを追加） --------------------------------------------------------------------- ▼最近の状況 最近、日本の大手ISPにおいてカミンスキー型攻撃手法によるものと考えら れるキャッシュDNSサーバーへのアクセスが増加している旨、JP
NTP reflection attackとNTPのトラフィック傾向
概要 janog@janog でもNTPを利用したDDoSがホットな話題となっています。弊社のトラフィック可視化ツールでも、UDP/123のトラフィックが2014年1月上旬くらいから急増している様子を確認しています。この状況の共有と、NTPへの対策の必要性を訴えかけたく思います。 発表者 高田 美紀 (エヌ・ティ・ティ・コミュニケーションズ株式会社) 資料
8.8.8.8に対するBGPハイジャックの話:Geekなぺーじ
一昨日書いた記事に対する補足です。 まず、最初にBGPハイジャックそのものは、世界各所で毎月のように発生しており、別に珍しくもない話です。 そのほとんどが、意図的にトラフィックを乗っ取る目的で行われたものではなく、単なるオペレーションミスであると言われています。 BGPハイジャックで有名なのが、2008年にYouTubeへのトラフィックをパキスタンのISPが吸い込んでしまった事件(参考：RIPE-NCC: YouTube Hijacking: A RIPE NCC RIS case study)ですが、これも意図的にやったのではなく、パキスタン国内向けのネット検閲設定が外部に漏れてしまったというオペレーションミスだったと思われます。 オペレーションミスは、漏らしてしまった側だけではない可能性もあります。 そもそも、/32などのプレフィックス長を持つ経路はフィルタされていることが多いので、普
「UPnP（libupnp）に脆弱性・WANから攻撃可能」という話の中身を調査してみた
「UPnPに脆弱性が見つかり、危険だ」というニュースがいろいろなWebサイトに掲載されていますが、例によってまた何言ってるかよく分からない部分が多かったので、調べたことを書いておきます。 目次 1. 概要2. 日本語サイトの情報源3. 「libupnpの脆弱性」は「UPnPパケットを使ったバッファオーバフロー」4. 「WANから攻撃可能」というニュースの意味5. 「WANからのSSDPリクエストを受け付ける」ルーターとは？6. 「libupnp」と「SSDPリクエストを受け付けてしまう脆弱性」の関係について7. 「WANからのSSDPを受け取ること」自体の問題8. 何があったからニュースになった？9. １月２９日にあったこと10. 本当のニュースは「Rapid7のホワイトペーパー」の公開11. ホワイトペーパーの中身12. じゃぁどうして脆弱性情報が出たのか13. 結論：見つかったのは「脆
クラウド時代はDNS Pinningが落とし穴になる | 水無月ばけらのえび日記
公開: 2011年9月3日19時50分頃 モバツイ (www.movatwi.jp)の作者えふしんさんと、Twitterでこんなやりとりをしました。 OperaってDNSのTTL考慮してない？！多くのブラウザは安全性のために短すぎるTTLを無視したりしますが (DNS Pinning)、それとはまた違う話でしょうか?AWSのElastic Load Balancingで、動的にロードバランサーのサーバが増えたり減ったりするようで、夜明けのOperaがよく全然違うサービスに繋がってしまうことがあるんですよね。少なくともクッキーは送っちゃってますよね...あー、なるほど。それはまずいですね。これは盲点でした……。 OperaやIEなどは、DNSのTTLが短く設定されていても無視してキャッシュし続ける事があります。これはDNSの負荷を減らすというだけはでなく、セキュリティ上の意味もあり、「DNS
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
