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の調査によ
Vue.js で XSS を作り込まないために気を付けること - セキュアスカイプラス
はじめに はじめまして、福岡オフィスで働いている前平です。 セキュアスカイ・テクノロジーでは、すでにいくつかのカテゴリのブログを発信していますが、技術を気軽に発信したり、エンジニアが普段の業務でどのような技術に触れているのかを紹介したりすることを目的として、新しく「エンジニアブログ」が立ち上がりました。 本記事では、最近になってようやく (汗) 検証した Vue.js でのクロスサイト・スクリプティング (XSS) について紹介します。 なお、本記事の内容は私見に基づくものであり、所属組織を代表するものではありません。 前提 本記事では Vue.js を使って XSS の脆弱性を作ってしまうようなケースを説明しますが、その他の JavaScript のライブラリ/フレームワークを使った場合でも同様のリスクがある可能性があります。 検証で利用したバージョン Vue.js v2.5.16 (サ
XSSフィルターの使い方/ Shibuya.XSS techtalk #9
2017/3/30 に行われた Shibuya.XSS techtalk #9 の発表資料です。
XSS Attack Tips / 今日から始めるXSS - http80
日々の健全なXSSにお役立てください。 ●極力短いコードでXSS 本題に入る前に軽く整理します。オーソドックスなXSSであれば、おなじみの次のようなコードになるでしょう。 "><script>alert(document.cookie)</script> *1 しかしながら、Reflectedするのにもかかわらず、場合によっては文字数制限という問題にぶち当たることもあるかと思われます。その場合、より短いコードでXSSを成功させる必要性があります。どこにReflectedされるかによって書き方は変わりますが、大まかには下記のどれかになるでしょう。 ◆HTML Body(HTML構文内) BAD: <input type="text" value="<?php echo $GET['name']; ?>"> PoC: "><script>alert(1)</script> (28文字) PoC
地味に書きためていくWeb開発セキュリティのキホン - f-shin (@fshin2000) の日記
XSS対策 インターネットから送られてくる入力値は絶対に信用しない。（post /get に留まらず、URLそのもの、Headerの中身や、画像のexif情報なども！） 情報を出力する時のescapeは、文脈にあわせて変える。htmlに出す場合とJavaScriptに出す場合、CSVに出す場合、JSONに出す場合でescapeの方法が変わる！ echoする時は、基本全部にescape。コントローラ側の文脈に依存する「この変数にそもそもescapeは必要か？否か？」に任せると、後で技術的負債化する！ そうではなく「ここの出力方法が適切か？」を一目でチェックできるようにすると簡単にチェックできる。あとから数千個、数万個をチェックする人の身になってコードを書く。 外部からの引数で、処理を分岐する場合は、必ず値を比較して想定する文字に一致した時のみ処理するように書く。 絶対に、そのままの値を引き回
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(
明日から使える?! PATHでXSSする技術/ Shibuya.XSS techtalk #7
Shibuya.XSS techtalk #7 の資料です。
クロスサイトスクリプティング対策 ホンキのキホン - 葉っぱ日記
本稿はCodeZineに2015年12月28日に掲載された記事の再掲となります。 クロスサイトスクリプティング(XSS)は、古くから存在し開発者にもっともよく知られたセキュリティ上の問題のひとつでありながら、OWASP Top 10でも2010年に引き続き2013年でも3位と、未だに根絶できていない脆弱性です。 本記事では、Webアプリケーションの開発においてXSSを根絶するために必要な対策の基本を本気でお伝えします。 はじめに OWASPでは開発者に向けたセキュリティ対策のためのドキュメントやチートシートを多数用意しており、XSSへの対策としても「XSS (Cross Site Scripting) Prevention Cheat Sheet」というドキュメントが用意されています。 ただし、このXSS Prevention Cheat Sheetはシンプルなルールを定めたチートシートで
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属性
PHP入門書のSQLインジェクションとXSS対策をあらためて調べてみた
継続的にPHP入門書のセキュリティ問題を確認していますが、今回は「やさしいPHP 第3版」を取り上げ、今どきのPHP入門書のセキュリティ状況を報告したいと思います。 やさしいPHP やさしいシリーズ 単行本 – 2008/2/29 やさしいPHP 第2版 (やさしいシリーズ) 単行本 – 2010/8/28 やさしいPHP 第3版 (「やさしい」シリーズ) 大型本 – 2014/9/26 上記のように、2008年に初版が出版された後2回の改版がありました。 第2版ではクロスサイトスクリプティング(XSS)の説明が追加され、第3版ではXSSに加えSQLインジェクションの説明が追加されました。つまり、初版ではこれらの説明はなかったということです。 第3版におけるSQLインジェクションの対策方法はプレースホルダによるもので、結果として本書にSQLインジェクション脆弱性は見当たりません（パチパチパ
Content-Security-Policy と nonce の話 - tokuhirom's blog
Content-Security-Policy の nonce を利用すると、XSS の脅威をかなり軽減できます。 そこで、Web Application Framework ではデフォルトで対応したほうがよいのではないか、という旨を @hasegawayosuke さんから教えて頂いたので、実装について考えてみました。 とりあえず CSP の nonce はどういうものなのかを考慮するために、コード例を探していたのですが、実際に動くサンプルというものが nonce 関連のもので見当たりませんでした。 そこで、実際に動くサンプルを用意しました。 https://github.com/tokuhirom/csp-nonce-sample 以下は Sinatra で書かれたサンプルコードです。 require 'sinatra' require 'securerandom' get '/' d
スクリプトインジェクション入門 - Qiita
はじめに 今回の記事は PHP を想定しています。 PHP は WEB サイトで最も使われていて、初心者がとっつきやすく、セキュリティーホールのあるシステムを最も多く生み出し続けている言語ですよね(￣▽￣；) そこで WEB プログラミングの初心者の方をターゲットに、出来るかぎり分かりやすく書いてみます。 というのは建前で、今週末にある PHP セキュリティのお勉強会の予習です。 記事の内容を他人の公開サーバーで試すと犯罪になる場合もあるので注意してね。 セキュリティを確保するにはシステムのアップデートが欠かせませんが、PHP は後方互換性に乏しく、バージョンアップが高コストなため、問題のあるバージョンのまま放置されたシステムになりやすく危険な言語だと思っています。 これは Ruby も同じで、私が言語を選べるなら、どちらも使いません。 堅い言語なら Java か C#(ASP.NET)、
フロントエンド開発のためのセキュリティ | 第1回 XSSの傾向と対策
フロントエンド開発のためのセキュリティ 第1回 XSSの傾向と対策 本シリーズではフロントエンドの開発に関係するセキュリティについて、理解を深めます。第1回目はXSS（クロスサイトスクリプティング）です。実装失敗例を挙げつつ、対策のポイントを解説します。 セキュリティはサーバーサイドの問題？ セキュリティに関わるミスは「知らなかった」ではすまされない場合が、往々にしてあります。 ちょっとしたミスでプログラムにバグを作ってしまい、サービスが一部動かなくなったとしても程度にもよりますが、すぐに修正すれば一部のユーザーに少し不便をかけてしまう程度ですむでしょう*。 *注：サービス運営 この記事ではセキュリティの技術的な側面を扱います。ユーザーに不便をかけてしまったことに対するサービス提供側の倫理的問題についてはそのつど言及はしませんが、これらの側面を軽視すべきでないことはいうまでもありません。
Masato Kinugawa Security Blog: U+2028/2029とDOM based XSS
ECMAScriptの仕様では、0x0A/0x0D以外にU+2028/2029の文字も改行とすることが明記されています。 これはあまり知られていないように思います。 以下はアラートを出します。 <script> //[U+2028]alert(1) </script> 知られていないだけでなく、知っていたとしても、スクリプトで文字列を処理するときに、U+2028/2029まで考慮する開発者がどれだけいるのかという話です。 実際、U+2028/2029を放り込むと文字列リテラル内にその文字が生のまま配置され、エラーが出るページは本当にたくさんあります。まあ、エラーがでるだけなら、大抵の場合大きな問題にはなりません。 ところが、U+2028/2029によってXSSが引き起こされてしまう場合というのを最近実際に見ました。 Googleのサービスで見つけた2つのケースを取り上げたいと思います。 ケ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ウェブアプリケーションセキュリティ超入門 | Slideshare
Browser's XSS Filter Bypass Cheat Sheet
[PDF] Electronの倒し方
OWASPでビルトイン・セキュリティ一覧
Code4Sec | LinkedIn
Node.js のセキュリティの話
