タリーズの件、CSPが設置されていたら防げていたという話がありますが、それは正しいでしょうか？ CSPを設定していなかったとしても、想定していない外部へのリクエストが発生していないか、定期的にチェックすることも大事ですよね？ | mond
タリーズの件、CSPが設置されていたら防げていたという話がありますが、それは正しいでしょうか？ CSPを設定していなかったとしても、想定していない外部へのリクエストが発生していないか、定期的にチェックすることも大事ですよね？ タリーズのサイトからのクレジットカード情報漏えいについて、CSP(Content Security Policy)やintegrity属性（サブリソース完全性）の重要性がよくわかったという意見をX(Twitter)上で目にしましたが、これらでの緩和は難しいと思います。 まず、CSPの方ですが、今回の件では元々読み込んでいたスクリプトが改ざんされたと考えられるので、オリジンとしては正規のものです。evalが使われていたのでCSPで制限されると考えている人が多いですが、evalは難読化のために使われているので、evalを使わないことは可能です。個人的には、難読化しない方が
ECサイトのクロスサイトスクリプティング脆弱性を悪用した攻撃 - JPCERT/CC Eyes
攻撃者は、はじめに標的のECサイトの注文フォームに対し、不正なスクリプトを含んだ文字列を入力し、購入処理を行います（図1の①）。その結果、ECサイトの購入処理の部分にXSSの脆弱性が存在する場合、ECサイトの管理画面を閲覧した管理者は不正なスクリプトが実行され、クレデンシャル情報の窃取や、ECサイトへの簡素WebShellの設置などが行われます（図1の②～④）。その後、攻撃者によってECサイトにWebShellやユーザーの情報窃取を行うJavaScriptなどが設置されます。設置された“情報窃取JavaScript”によってECサイトを利用するユーザーのクレジットカード情報等を窃取され、“情報保存ファイル”としてECサイト内に保存されます（図1の⑤）。攻撃者は定期的なWebShellへのアクセスを行うことでこれらの情報を窃取していたと推測されます（図1の⑥）。 なお、攻撃者は、一連の攻撃の
Trusted Typesを利用してJavaScriptからのDOM操作をセキュアに行う
ウェブアプリケーションの高度化に伴い、セキュリティに対する関心も年々高まりつつあります。特にXSS（クロスサイトスクリプティング）と呼ばれる脆弱性は簡単ながらも大きな被害をもたらします。アプリケーションの開発者は当然セキュリティを意識した開発を行うべきですが、人間の注意は万能ではなく、時に不注意から脆弱なアプリケーションを作成してしまいます。 こういった状況を改善するために、Trusted Typesという提案がなされています。Trusted Typesはよりセキュアなウェブアプリケーションを作る手段を提供し、安全性を高める補助をしてくれます。 Trusted Types HTMLやJavaScriptは非常に柔軟な仕組みを有しており、要素を動的に組み立てることが可能です。例えば以下の例を見てみましょう： const { username, email } = await api.getU
HTML5のLocal Storageを使ってはいけない（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Randall Degges - Please Stop Using Local Storage 原文公開日: 2018/01/26 著者: Randall Degges 日本語タイトルは内容に即したものにしました。 画像は元記事からの引用です。 初版公開: 2019/10/19 追記更新: 2024/04/05 -- リンク情報を記事末尾に移動しました 本気で申し上げます。local storageを使わないでください。 local storageにセッション情報を保存する開発者がこれほど多い理由について、私にはさっぱり見当がつきません。しかしどんな理由であれ、その手法は地上から消えてなくなってもらう必要がありますが、明らかに手に負えなくなりつつあります。 私は毎日のように、重要なユーザー情報をlocal storageに保存す
安全な文字列であると型で検証する 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
Content Security Policy Level 3におけるXSS対策 - pixiv inside
こんにちは、セキュリティエンジニアのkoboです。ピクシブには2018年4月に入社しており、セキュリティ観点でのアプリケーション開発や脆弱性報奨金制度の運用などを行っています。 本記事では、現在ピクシブの一部のサービスで取り組んでいるContent Security Policyについて知見を共有します。 概要 Content Security Policy (CSP) は、XSSを主としたウェブアプリケーションセキュリティの問題を軽減するために考案されたブラウザのセキュリティ機構です。 ウェブアプリケーションは、 Content-Security-Policy ヘッダをHTTPレスポンスに含めることで、意図していないJavaScriptの実行やリソースの読み込みをブラウザ側で制限することができます。 CSPは2012年頃よりブラウザに実装されていますが、2016年のGoogleの調査によ
iframe sandbox は万能ではない - 葉っぱ日記
HTML5で導入されたiframe要素のsandbox属性は、そのiframe内のコンテンツに対しJavaScriptの実行を始め様々な制約を課すことでセキュリティの向上に役立つ機能である。例えば、以下のように指定されたiframeでは、iframe内からformのsubmitなどはできるが、iframe内でのJavaScriptの実行やtarget=_blankなどによってウィンドウを開くことなどは禁止される。 <iframe sandbox="allow-forms" src="..."></iframe> sandbox属性に明示的に allow-scripts という値を指定しない限りはiframe内では直接的にはJavaScriptは実行できないが、かといってiframe内から間接的にJavaScriptを必ずしも実行させることが不可能かというとそうでもない。 sandbox属性
攻撃者視点で見る Service Worker / PWA Study SW
PWA Study( https://web-study.connpass.com/event/65267/ ) で発表した資料です。
5文字で書くJavaScript/ Shibuya.XSS techtalk #10
Shibuya.XSS techtalk #10 の発表資料です。
どのようにして5,000ドルのGoogleマップXSSを発見したか | POSTD
数ヵ月前、私はGoogleマップを、もっと正確に言うとGoogleストリートビューを利用しました。Googleストリートビューは子供の頃に思い描いた未来的なテレポートみたいで、とても気に入っています。私は、普段そうするように、その時もアドレスバーを見ました。2014年のいつ頃からか、パラメータは単なるクエリの文字列ではなくなり、その代わりに感嘆符で区切られた英数字の奇妙な寄せ集めになったようです。 難解で、現在のところ公開されたドキュメンテーションもなく、多くの人々に毎日使用され、リバースエンジニアリングが可能なプロトコル。こういうコードを目の前にすると、私は解読したくてウズウズしてきます。 私はブラウザのWebコンソールも見てみました。AJAX APIへのリクエストが同じようにエンコードされていただけではなく、もしレスポンスの一部が画像だった場合、その他のレスポンスは暗号を用いたバイナリ
ElectronアプリのXSSでrm -fr /を実行する - Qiita
Electronアプリでxssを発生させると任意のコードが実行できるらしいのでrm -fr /を試してみます。 想定 web版とelectron版のあるチャットアプリケーションという設定です。攻撃者が用意したリンクをクリックすると、PC内のすべてのファイルを消し去るというシチュエーションを考えてみます。 用意 環境はホストmac OSX、ゲストにubuntu14.04環境をvagrantを利用し用意しました。 expressでリストとフォームからなる脆弱性のあるチャットをつくります。エスケープ処理をしてないので、任意のコードが実行できる状況です。 'use strict'; const path = require('path'); const express = require('express'); const app = express(); const ejs = require(
Safe JavaScript Templating
Safe JavaScript Templating Automatic Contextual XSS Escaping made robust, easy, and fast Is XSS defense too hard? Cross Site Scripting (XSS) has topped the list of OWASP Top 10 Web Application Security Risks over a decade. We all know its consequence is terrible, allowing attackers to compromise a website and exfiltrate sensitive user information. But what makes it so hard to be eliminated from we
ECMAScript 6 from an Attacker's Perspective - Breaking Frameworks, Sandboxes, and everything else
ECMAScript 6 from an Attacker's Perspective - Breaking Frameworks, Sandboxes, and everything else ECMAScript 6, in short ES6, has been boiling in a copper pot for many years by now and step-by-step, browser vendors come forward to taste the first sips of this mystery soup. So, ES6 is no longer a theoretic language but already crawled across the doorstep and now lurks under your bed, ready for the
React.js に XSS 対策を求めるのは間違っているだろうか
Transcript 1. React.js に XSS 対策を 求めるのは間違っている だろうか #edomaesec 2015 5/30 LT 2. @clariroid 3. くらりど 4. React.js 5. React.js 6. React.js 青い紐 7. React.js • UI を構築する JavaScript ライブラリ 8. React.js • UI を構築する JavaScript ライブラリ • Virtual DOM 9. React.js • UI を構築する JavaScript ライブラリ • Virtual DOM • Component Composable 10. React.js • UI を構築する JavaScript ライブラリ • Virtual DOM • Component Composable • Server-side R
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
これからのフロントエンドセキュリティ
Prototype Pollution in Kibana
GitHub - cure53/DOMPurify: DOMPurify - a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks. Demo:
Tangled World of Web Technology ― Are we safe?
GitHub - Metnew/uxss-db: 🔪Browser logic vulnerabilities :skull_and_crossbones:
HTML5 セキュリティ その 4 : DOM based XSS 編