Spectre の脅威とウェブサイトが設定すべきヘッダーについて
長い記事なので先に結論を書きます。 Spectre の登場で、ウェブサイトに必要とされるセキュリティ要件は増えました。具体的に必要な対策は下記の通りです。 すべてのリソースは Cross-Origin-Resource-Policy ヘッダーを使って cross-origin なドキュメントへの読み込みを制御する。 HTML ドキュメントには X-Frame-Options ヘッダーもしくは Content-Security-Policy (CSP) ヘッダーの frame-ancestors ディレクティブを追加して、cross-origin なページへの iframe による埋め込みを制御する。 HTML ドキュメントには Cross-Origin-Opener-Policy ヘッダーを追加して popup ウィンドウとして開かれた場合の cross-origin なページとのコミュニ
AWS Amplify で Custom headers を活用したパフォーマンスと脆弱性対策
はじめにこんにちは、Finatext で保険事業にてプロダクト開発をしている @toshipon です。今回は我々のプロダクトでも活用している AWS Amplify コンソールにおける Custom headers の運用についてお話いたします。 概要Amplify 上で Custom headers を設定する手順についてご紹介いたします。Custom headers は、HTTP レスポンスのヘッダーに指定できる情報を管理するもので、主にデバッグやセキュリティ対策、情報提供に利用されます。 今回は、キャッシュを適切に有効にさせてパフォーマンスを向上させたり、XSSやクリックジャッキング等のWebアプリケーション脆弱性に対処することを目的として利用したいと思います。 また、Content-Security-Policy-Report-Only というセキュリティヘッダー（説明については
RHSB-2021-002 Privilege escalation via command line argument parsing - sudo - (CVE-2021-3156) | Red Hat Customer Portal
0 Get notified when this content is updated. Follow Please wait...
How To Secure Node.js Applications with a Content Security Policy | DigitalOcean
The author selected the Free Software Foundation to receive a donation as part of the Write for DOnations program. Introduction When the browser loads a page, it executes a lot of code to render the content. The code could be from the same origin as the root document, or a different origin. By default, the browser does not distinguish between the two and executes any code requested by a page regar
Firestore Security Rules の書き方と守るべき原則
概要と投稿の背景 本投稿では、下記の参考にした記事や動画を通じて私が学習した、Firestore Security Rules の書き方と守るべき原則についてまとめます。 まず、そのような学習に有益な情報をオープンに発信して下さっているディベロッパー・クリエイター、Google 公式の皆さんへのリスペクトと感謝を表明します。本当にありがとうございます。 私と同じ学習者・初学者の方の参考になればと思い、具体的なユースケースを想定しながら、実際のコードを含む形でまとめています。 参考にした記事や動画 本記事では、以下のような記事や動画を通じて学んだ内容をまとめています。 【公式】Firebase CLI リファレンス 【公式】Cloud Firestore セキュリティ ルールを構造化する 【公式】Cloud Firestore セキュリティ ルールの条件の記述 【公式】Firebase 公式
Trusted Typesを利用してJavaScriptからのDOM操作をセキュアに行う
ウェブアプリケーションの高度化に伴い、セキュリティに対する関心も年々高まりつつあります。特にXSS（クロスサイトスクリプティング）と呼ばれる脆弱性は簡単ながらも大きな被害をもたらします。アプリケーションの開発者は当然セキュリティを意識した開発を行うべきですが、人間の注意は万能ではなく、時に不注意から脆弱なアプリケーションを作成してしまいます。 こういった状況を改善するために、Trusted Typesという提案がなされています。Trusted Typesはよりセキュアなウェブアプリケーションを作る手段を提供し、安全性を高める補助をしてくれます。 Trusted Types HTMLやJavaScriptは非常に柔軟な仕組みを有しており、要素を動的に組み立てることが可能です。例えば以下の例を見てみましょう： const { username, email } = await api.getU
Introducing 1.1.1.1 for Families
This post is also available in 简体中文, 日本語, Deutsch and Français. Two years ago today we announced 1.1.1.1, a secure, fast, privacy-first DNS resolver free for anyone to use. In those two years, 1.1.1.1 has grown beyond our wildest imagination. Today, we process more than 200 billion DNS requests per day making us the second largest public DNS resolver in the world behind only Google. Yesterday, we
QEMUを用いた自動バイナリ防御機構の開発_公開版.pdf
20240530_IBMTechXchangeDojo_いまからでも遅くない_OpenShiftでアプリをHTTPSで公開してみる
efcl.info をhttpからhttpsへ移行するためにやったこと
サイトをHTTPSにする 2018年7月に公開されるChrome 68でHTTPなサイトは”Not Secure”と表示されるようになるので、このサイトもHTTPS化することにしました。 Google Online Security Blog: A secure web is here to stay 個人的なサイトなので適当にやってもいいですが、一応ちゃんと追跡できる方法を使ってHTTPS化することにしました。 この記事では次のことを目標しました。 https化後にhttpでアクセスしているリソースがないことをツールで確認できる 要はMixed Contentがないことを検知する方法をもつ 常時HTTPSでアクセスできるようにする Content-Security-Policy-Report-Only このサイトはJekyll + GitHub Pagesで動いている(動いていた)静的サ
俺のSMS認証がこんなに非推奨なわけがない
NISTは本当にSMS認証を非推奨としたのか。真実を追って我々はジャングルに飛び込んでいった... 8/1 13:30: 構成を一部変更・追記
Web over HTTPS
Web over HTTPS DevFest Tokyo 2016 #devfest16 2016/10/0
TLS1.3とは何か？
プロダクト拡大フェーズでプロダクト検証サイクル効率化を目指す過程で見えたもの / Streamlining Product Validation in Growth Phase
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
脆弱性から学ぶ
Webセキュリティ/study-web-security-from-vulnerability1
SOCって何_公開用_-圧縮済み.pdf
Wi-Fiによるモダン ネットストーキング
コンテナを守る技術2018/container-security-20180310
カーネルエクスプロイトによるシステム権限奪取
cookpad.com 全 HTTPS 化の軌跡