JavaScriptでインジェクションリスクがある関数／機能など
Last Updated on: 2018年8月9日Webブラウザに対するJavaScriptコードのインジェクションは サーバー側のコードが原因（サーバー側のPHP、Ruby、Python、JavaScriptが原因） クライアント側のコードが原因（クライアント側のJavaScriptが原因） サーバーとクライアント（上記の両方） で起きる可能性があります。ここでは主にクライアント側が関係するケースで注意しなければならない箇所を紹介します。 どこが危険なのか？ ブラウザ上のJavaScriptの場合、ECMAScriptの基本として実装されている機能、DOM機能として実装されている機能があります。更にこの他にもHTMLやCSS機能もあり複雑です。SVGなどこの他の標準にもJavaScriptが記述できるモノがあります。 JavaScriptを実行可能となる部分へユーザー入力データを出力す
VueをSSRに乗せると容易にXSSを生み出す場合がある件について - Qiita
はじめに 最近Vue.jsを頻繁に使用するのですが、他のSSR(サーバーサイドレンダリング)の仕組みと組み合わせる場合、容易にXSSを生み出してしまうケースが存在するので、注意喚起も兼ねて事例を紹介させていただきます。 9月7日 追記を追記しました 前提 サーバーサイドで動的に要素をレンダリングするシステムとVue.jsを組み合わせた場合 この記事はrailsのSSRとの組み合わせで解説しますが、プレーンなPHP等、動的にHTMLをレンダリングシステムとの組み合わせでも発生します。 サンプルコード まず、こちらのコードをご覧ください。 user.erb <div id="app"> <div class="user"> <%= @user.name %> </div> <button v-on:click="registerFavorite" data-user-id="<%= @user
JS自動レビューツール"jswatchdog"を公開しました - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。kintone 開発チームの天野 (@ama_ch) です。すっかり春らしくなりましたね。 少し前に JS の自動レビューツール jswatchdog をオープンソースで公開しましたので、こちらで紹介させていただきます。 使い方 https://kintone.github.io/jswatchdog/ 上記の URL を開き、左側のエディタに JS コードを貼り付けるだけです。 右側に修正が必要な箇所が表示されるので、適宜修正します。 特徴 バリバリの開発者じゃなくても使いやすい一画面完結の Web インターフェース lint ツールでお馴染みの構文チェックの他、知らずに脆弱性を作り込むことを避けるため、XSS の可能性がある箇所にも警告を表示 内部的には、JS の静的構文チェックツールとして ESLint と JSHint を組み込んでいます。 さらに XSS の可能性があ
ブラウザ上でMarkdownを安全に展開する - 葉っぱ日記
不特定のユーザーが入力したMarkdownをブラウザ上でJavaScriptを使ってHTMLに変換するという場面においては、JavaScriptで変換してHTMLを生成するという処理の都合上どうしてもDOM-based XSSの発生を考えないわけにはいかない。かといって、MarkdownをパースしHTMLを生成するという処理すべてをXSSが存在しないように注意しながら自分で書くのも大変だし、markedやmarkdown-jsなどの既存の変換用のJSを持ってきてもそれらがXSSしないかを確認するのは結構大変だったりする。 そういった場合には、Markdownから生成されたHTMLをRickDOMを通すことで、万が一HTML内にJavaScriptが含まれていたとしてもそれらを除外し、許可された要素、許可された属性だけで構築された安全なHTMLに再構築することができる。さらに、そうやって生成
フロントエンド開発のためのセキュリティ | 第1回 XSSの傾向と対策
フロントエンド開発のためのセキュリティ 第1回 XSSの傾向と対策 本シリーズではフロントエンドの開発に関係するセキュリティについて、理解を深めます。第1回目はXSS（クロスサイトスクリプティング）です。実装失敗例を挙げつつ、対策のポイントを解説します。 セキュリティはサーバーサイドの問題？ セキュリティに関わるミスは「知らなかった」ではすまされない場合が、往々にしてあります。 ちょっとしたミスでプログラムにバグを作ってしまい、サービスが一部動かなくなったとしても程度にもよりますが、すぐに修正すれば一部のユーザーに少し不便をかけてしまう程度ですむでしょう*。 *注：サービス運営 この記事ではセキュリティの技術的な側面を扱います。ユーザーに不便をかけてしまったことに対するサービス提供側の倫理的問題についてはそのつど言及はしませんが、これらの側面を軽視すべきでないことはいうまでもありません。
知っていれば恐くない、XMLHttpRequestによるXSSへの対応方法
知っていれば恐くない、XMLHttpRequestによるXSSへの対応方法：HTML5時代の「新しいセキュリティ・エチケット」（3）（1/2 ページ） 連載目次 皆さんこんにちは。ネットエージェントのはせがわようすけです。前回は、同一オリジンポリシーを突破する攻撃の代表的事例であるXSSについて、特にDOM based XSSと呼ばれるものについて解説しました。今回はその続きとして、XMLHttpRequestによるXSSを解説します。 XHR Level 2によるリモートからのコード挿入によるXSS 従来、XMLHttpRequest（以下、XHR）は、表示しているドキュメントと同じオリジン（オリジンについては第1回を参照）としか通信できませんでしたが、現在の主要なブラウザーではXHR Level 2と呼ばれる実装により、オリジンを超えて通信することが可能になっています。 これは、Jav
JavaScript: / の \ によるエスケープのみによるセキュリティ対策は禁止
Last Updated on: 2018年8月4日RFC 4696をもう一度読みなおしてみると/もエスケープ可能文字に定義してありました。JavaScriptのエスケープシークエンスの処理の部分も間違っていたので全面的に書き直します。 RFC 4696（JSON）の定義では string = quotation-mark *char quotation-mark char = unescaped / escape ( %x22 / ; ” quotation mark U+0022 %x5C / ; \ reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ; r
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つのケースを取り上げたいと思います。 ケ
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
JavaScript文字列の動的生成におけるエスケープ - 葉っぱ日記
「JavaScript文字列を動的生成する」と一言で言っても、例えば <html>... <script> // HTML内のscript要素内に生成 var s = "ここに動的生成される"; </script> だったり、 <div onclick='foo("ここに動的生成される");'> だったり、 <script src="external.js"></script> // external.js var s = "ここに動的生成される"; だったり、さらに複雑な組み合わせだったりといろんな状況があって、基本的には「JavaScriptとしてのエスケープ」に加えてその外側の(場合によってはネストしている)コンテキストに応じたエスケープが必要、という話。 で、面倒だったら var s = decodeURIComponent( "ここに動的生成される" ); にして、生成する側はU
JavaScript文字列のエスケープ
これらの中で注目すべきは ‘ と ” と \ です。シングルクォート、ダブルクオートは文字リテラルを作成する為に利用され、\ でエスケープできることです。つまり、文字リテラルの最後に \ が現れると文字列の終端が無くなります。単独で不正なJavaScriptの挿入が可能になる訳ではありませんが、プログラムの構造が破壊される事を意味します。 PHPにはJavaScript文字列用のエスケープ関数が用意されていません。htmlspecialchars()やhtmlentities()で代用している場合も多いと思います。しかし、これらの関数ではJavaScript文字列のエスケープを十分に行う事ができません。 JavaScriptプログラムの構造が破壊される例 <?php $msg1 = 'test string\\'; $msg2 = ');alert(document.cookie); //
Masato Kinugawa Security Blog: Referrer文字列によるXSS
リファラを使ったXSSの小ネタです。 今回取り上げるのは、ターゲット自身が、細工したページを経由することでつけられたリファラによって攻撃を受けるケースです。このような攻撃の場合は、現実に経由可能なページからでしか攻撃文字列を送りこむことができません。 例えば、以下のように、document.referrerをそのままdocument.write()しているページがあるとします。 http://vulnerabledoma.in/location/ リファラを書き出している部分でXSSできるでしょうか。 IEでは単純です。 IEはURLのクエリに、エンコードせずに「"<>」などを含めることができるので、これらを含むURLから、リファラを書き出しているページへ遷移させれば、XSSが起きます。 http://l0.cm/xss_referrer.html?<script>alert(1)</sc
届け出が急増するDOM Based XSS
2012年10月～12月において、IPAにDOM Based XSSの脆弱性に関する届出が急増した。日本語で解説された資料が少ないDOM Based XSSの脆弱性について2回に分けて解説する。第1回ではDOM Based XSSの脆弱性について概要や対策が必要なアプリについて解説し、第2回ではコードを交えての対策方法を解説する。 XSSの脆弱性とは？ DOM Based XSSとは、XSS（cross-site scripting：クロスサイト・スクリプティング）の脆弱性の一種である。まずは、XSSの脆弱性について解説する。 XSSの脆弱性とは、端的に言えば「攻撃者が用意した不正なJavaScriptをWebページに埋め込める問題の一つ」である（図1）。不正なJavaScriptを埋め込む方法は何パターンか存在するが、ここでは説明を割愛する。 これはつまり、攻撃者が悪意のあるJavaSc
innerHTMLでscriptする - Thousand Years
innerHTMLにscriptを代入しても評価されず無視されるのはIEの仕様なのでいいとしてその回避策。最近、昔あの方法で出来たんだけどいつの間にかできなくなってるコードが出てきている気がします(気のせいにしておこう)。 以下は一般的な動かないコード。 <div id="foo"></div> <script type="text/javascript"> document.getElementById('foo').innerHTML = "<script type='text/javascript'>alert('動かない')<"+"/script>"; </script> 以下は動くコード。 <div id="foo"></div> <script type="text/javascript"> document.getElementById('foo').innerHTML =
XMLHttpRequestオブジェクトを使ったTRACEメソッド送信のブラウザ対応状況を確認してみる - 思い立ったら書く日記
HTTPのTRACEメソッドを悪用する古い攻撃手法に「Cross Site Tracing(XST)」というものがあります。この攻撃手法を悪用すると、第三者が Cross Site Scripting（XSS）の脆弱性が存在するWeb サイトとブラウザの間でやり取りされる HTTP リクエスト・ヘッダを取得できてしまいます。この手法は一般的に HTTP リクエスト・ヘッダに含まれる Authorization ヘッダや Cookie ヘッダを奪取するために悪用されるようですね。 XST では一般的に JavaScript でXMLHttpRequest オブジェクトを悪用するようですが、最新のブラウザでも XMLHttpRequest オブジェクトで TRACE メソッドの HTTP リクエストを送信できるのでしょうか。というのも、W3C の XMLHttpRequest オブジェクトに関
jQuery 1.8 で XSS 対策に .parseHTML メソッドが追加
jQuery の $ 関数はセレクタによる絞り込み、HTML 生成、ready イベントコールバックの3つのケースに使われますが、開発者がセレクタとして想定したものが HTML 生成として解釈され、XSS を引き起こすことがあります。次のコードは HTML と解釈され、error イベントハンドラに指定された alert が実行されます。 $("#<img src=/ onerror=alert(1)>"); 防衛策として jQuery 1.9 では $ 関数に渡すことのできる HTML に見える文字列の制約を厳しくするため、従来は認識できた文字列が認識できなくなる場合の回避策および、特に単独の要素を生成したり、外部のデータから文字列を生成する場合のために $.parseHTML を使うことをおすすめするとリリース記事に書いてあります。 .parseHTML メソッドの実装を見ると戻り値が
情報セキュリティ技術動向調査（2011 年上期）：IPA 独立行政法人 情報処理推進機構
この何年かでWebアプリケーションは、サーバ上のみでプログラムが動作するものから、多くのJavaScriptコードがWebブラウザで動作し、背後でサーバと連携して、リッチかつスムーズな操作感を提供するものへと進化してきた。このことは、Webブラウザ上に悪意のスクリプトを送り込む「スクリプト注入（XSS）」攻撃を、より防止しづらく、悪用の懸念がより大きなものに変化させた。本稿は、WebアプリケーションにAjax等の進化をもたらした技術について振り返るとともに、スクリプト注入対策を考慮すべき新たな文脈について論じるものである。 Ajax（Asynchronous JavaScript and XML）[1]は、必要となるデータを非同期でWebサーバから取り寄せつつ、Webブラウザの画面上でなめらかな操作性を提供する形態のJavaScriptプログラムのことである。かつてのブラウザにおいてはこの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
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:
innerText(textContent)/innerHTMLを使ったHTMLエスケープは充分でないので今すぐやめろ、お前たちはもう終わりだ - TODESKING
yuga.jsのXSS直したバージョンがなかなかリリースされないので勝手に直したやつ
