セキュリティトークンを識別するための secret-token URI Scheme の提案仕様 (RFC8959) - ASnoKaze blog
2021/01/30 追記:RFC8959で標準化されました https://www.rfc-editor.org/rfc/rfc8959.html セキュリティートークンを間違えて公開してしまうセキュリティインシデントが増えています。例えば、シークレットやトークンをソースコードに埋め込んだままコミット・公開してしまったりなどです。 機械的にセキュリティトークンを識別できるようになれば、意図せずそのようなセキュリティトークンがコミットされたり公開されるのを機械的に防げるようになります。 先日IETFに提出された「The secret-token URI Scheme」という仕様ではsecret-token URI Schemeを定義し、セキュリティトークンを識別できるようにします。 例 トークンにsecret-token:を付けます secret-token:E92FB7EB-D882-4
独りで学ぶ 論文検索｜学ぶ素人｜note
皆さんは「学術論文」を読んだことがあるでしょうか。 大学生や大学院生なら、自分の分野の論文は読んでいることでしょう。 情報が広く共有される現代でも、 「学術論文は専門家や研究者が読むもの」 「普通の市民は論文など読めない」 というイメージは今でもかなり強いように感じます。 私はこれを非常に「もったいない」と思っています。 実際には、「素人が専門の論文にアクセスする」ためのハードルは年々下がっているからです。 今や、素人でも「専門家が読んでいるのと同じ文献」をその気になれば読める時代になりました。 にもかかわらず「科学論文を読む素人」や「分野外の論文を読む学徒」が増えないのは、「論文の読み方」を大学以外でなかなか習えない、というのが一つの障壁になっているのかもしれません。 「論文の調べ方」「論文の読み方」に王道などありませんが、今回はあくまで私の例として、論文を探して読むためのハウツーを簡単
安全な文字列であると型で検証する 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 scrip
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
