Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる | おそらくはそれさえも平凡な日々
追記: その後の動きについて書きました → Let's Encryptの証明書切替周りその後 このサイトはLet's Encryptで証明書発行しているのでタイトルの件が気になったのだが、どうもあまり話題になっていない。恥ずかしながらSSL周り詳しいわけじゃないので、誤っているかも知れない。識者の意見を求む。 Let's Encryptが使われているサイトがAndroid7.1以前のバージョンで今年の9月29日以降見られなくなる可能性がある 延命策は用意されそうだが、それも来年の9月29日まで Let's Encryptのルート証明書切り替え計画に起因している Let's Encryptのルート証明書の変更 Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしている。現在は、IdenTrustのルート証明書(DST
Site Isolation 及び Web のセキュリティモデルの更新 | blog.jxck.io
Intro Origin は Web におけるセキュリティモデルの一つとして、コンテンツ間の Communication に関する境界を定義し、リソースを保護してきた。 しかし、 Spectre の発覚以降、 Communication に関する制限だけではなく Isolation によるメモリレベルでのアクセス制御が必要となった。 そこで現在作業されているのが、 CORB, CORP, COEP, COOP といった仕様群であり、これは Web におけるセキュリティモデルの更新作業と見ることができる。 概要と現状について解説する。 DEMO & Resources 量が多いため、動作する DEMO と関連リソースは、ページ下部にまとめてある。 CORS による Cross Origin Communication の制限 CORS は、平たく言えば、リソース提供元(サーバ)が、クライアン
最新のブラウザで変わるCookieの取り扱いやPrivacyの考え方
2020/02/13 DevSumi 発表資料
ドメイン殺しにやられた話。SNS時代の外部URL遷移は超キケン - Crieit
先日、長いこと閉鎖していたサービスを復活させました。 OGP changer https://ogpc.ga/ これは、SNS共有用のURLを発行するサービスです。閉鎖に至ったのには大きな理由がありました。 短縮URLサービスのドメインを殺された きっかけは弊サイトが管理する別の短縮URLサービス「URL Shortener」(lmp.tw)の悪用でした。 URL Shortenerは純粋な短縮URLサービスです。ユーザー数が少ないため、他よりも短いURLを取得できるのがウリでした。 ところが。 短縮URLサービスでテロられたこんなことあるんか — ウラル (@barley_ural) April 12, 2019 まさかの事態に。 何が起きたのか？ lmp.twドメインが全てTwitterに弾かれ、一切ツイートできないようになっていました。既にツイートされたリンクを踏むと、全てのページで
Web Storage: セッショントークンのマシな手段 ― cookieとセキュリティ面を比較してみる | POSTD
最近、私は「セッショントークンを、cookieの代わりに Web Storage (sessionStorage/localStorage)に保存するのは安全ですか？」ということを尋ねられました。このことについてGoogleで検索したところ、検索結果の上位のほとんどが「Web storageはcookieに比べてかなりセキュリティが弱く、セッショントークンには不向きである」と断言していました。透明性のため、私はこの逆の結論に至った理論的根拠を公に書くことにしました。 Web Storageに関する議論の中核として言われるのは、「Web StorageはsecureフラグやHttpOnlyフラグといったcookie特有の機能をサポートしていないため、攻撃者が容易に盗み取ることが可能」というものです。path属性についても言及されます。私は、これらの機能それぞれについて調べてみました。そして、
Cookie の性質を利用した攻撃と Same Site Cookie の効果 | blog.jxck.io
Intro Cookie はブラウザによって保存され、紐づいたドメインへのリクエストに自動で付与される。 この挙動によって Web におけるセッション管理が実現されている一方、これを悪用した攻撃方法として、 CSRF や Timing Attack などが数多く知られており、個別に対策がなされてきた。 現在、提案実装されている SameSite Cookie は、そもそもの Cookie の挙動を変更し、こうした問題を根本的に解決すると期待されている。 Cookie の挙動とそれを用いた攻撃、そして Same Site Cookie について解説する。 Cookie の挙動 Cookie は、 Set-Cookie によって提供したドメインと紐づけてブラウザに保存され、同じドメインへのリクエストに自動的に付与される。 最も使われる場面は、ユーザの識別子となるランダムな値を SessionI
window.open() がイベントごとに一度しか呼び出せなくなりました | Firefox サイト互換性情報
Firefox 65 で、複数のポップアップウィンドウが同時に開かれるのを防ぐため、ポップアップブロッカーが改良されました。window.open メソッドの呼び出しはイベントごとに 1 回のみ許容され、もし後続の呼び出しが行われた場合はブラウザーによってブロックされます。より良いユーザー体験のためには、いずれにしても複数ポップアップやタブを開くことは避けるべきでしょう。
安全な文字列であると型で検証する Trusted Types について | blog.jxck.io
Intro 脆弱性の原因となる DOM 操作の代表例として elem.innerHTML や location.href などが既に知られている。 こうした操作対象(sink) に対して、文字列ベースの代入処理を行う際に、一律して検証をかけることができれば、脆弱性の発見や防止に役立つだろう。 そこで処理前の文字列に対し、処理後の文字列を安全であるとして明示的に型付ける TrustedTypes という提案がされている。 まだ未解決の部分が多い提案だが、現時点での仕様と実装を元に、このアイデアについて解説する。 WICG/trusted-types Intent to Experiment: Trusted Types Sink XSS などの原因となる DOM 操作として、 DOM に直接文字列を展開する処理がある。 element.innerHTML location.href scri
パスワードなくします ヤフー、スマホに指紋でログイン：朝日新聞デジタル
ヤフーは、スマートフォンでサービスにログインするとき、パスワードを使わずに指紋認証だけで済む仕組みを２３日から始めた。アンドロイド搭載スマホで、ウェブブラウザー「グーグルクローム」の最新版を使う場合が対象だ。 利用するスマホで指紋を設定すると、ヤフーのサービスを利用するときに、画面で指紋を照合するだけでログインできるようになる。 利用者の指紋情報をヤフー側に登録せず、スマホでの照合結果だけをサーバーに送信してログインする。ヤフー側には指紋情報が保存されない。登録した端末からだけ利用できるため、第三者が利用者の指紋情報を入手しても、別の端末からはログインできない。 ｉＯＳは、ヤフーが採用した生体認証の規格を使っていないため、今回の仕組みは利用できない。 ヤフーが「パスワードなし」の取り組みを進めるのは二つの理由からだ。 ヤフーのサービスには、月１億３千万回のログインがある。１ユーザーにすると
IPA ISEC セキュア・プログラミング講座：Webアプリケーション編 第4章 セッション対策：リクエスト強要（CSRF）対策
リクエスト強要（CSRF：Cross-site Request Forgery）とは、別のサイトに用意したコンテンツ上の罠のリンクを踏ませること等をきっかけとして、インターネットショッピングの最終決済や退会等Webアプリケーションの重要な処理を呼び出すようユーザを誘導する攻撃である。 ブラウザが正規の Webコンテンツにアクセスした際には毎回、セッションを維持するために所定の Cookie、Basic認証データあるいは Digest認証データがブラウザから Webサーバ宛に送出されるという性質を、この攻撃は悪用する。 ユーザの意図に反することを検証できないWebアプリケーション この攻撃の対象となるのは、トランザクション投入のきっかけとなったフォーム画面が自サーバから供給（POST）されたものであることを確認していない Webアプリケーションである。言い換えれば、ブラウザから自動的に得られ
パスワードに依存しない認証「WebAuthn」をChrome/Firefox/Edgeが実装開始、W3Cが標準化。Webはパスワードに依存しないより安全で便利なものへ
Google、Mozilla、マイクロソフトが「WebAuthn」の実装を開始。これによって「FIDO2」の普及が期待され、Webブラウザから指紋認証や顔認証などで簡単にWebサイトへのログインや支払いの承認といった操作が実現されそうだ。 多くのWebアプリケーションは、ユーザーの認証にユーザー名とパスワードの組み合わせを用いています。 しかしユーザー名とパスワードの組合わせを用いる方法にはさまざまな問題が指摘されています。身近なところでは、安全なパスワードを生成することの手間や、安全性を高めるためにパスワードの使い回しを避けようとした結果発生する多数のパスワードを管理することの手間などがあげられます。 そしてこうしたパスワードの不便さが結果としてパスワードの使い回しを引き起こし、いずれかのサイトで万が一パスワードが流出した場合にはそれを基にしたリスト型攻撃が有効になってしまう、などの状況
webpack-dev-server/middleware security issues
TL;DREd Morley from Mozilla reported a security issue.I found some other security issues.These issues was fixed in webpack-dev-server@^2.4.3, webpack-dev-server@^1.16.4, webpack-dev-middleware@^1.10.2.Fixes are breaking changes for insecure configurations.Don’t use disableHostCheck or Access-Control-Allow-Origin: *DisclaimerI’m not a security expert so maybe some details are incorrect/inaccure. Th
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CookieのDomain属性は *指定しない* が一番安全
IPA-安全なウェブサイトの作り方2021年改訂第7版.pdf