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(
XSSやCSRFリスクを軽減する、Entry Point Regulationとは - ASnoKaze blog
Entry Point Regulation とは 反射型XSS・XSSI・CSRFのリスクを軽減するユーザエージェント上の仕組みとして、W3CでEntry Point Regulationという仕様が策定中です。 Webアプリケーションの口(Entry Point)に幾つかの制限をかけることが出来ます。別オリジンからのリクエストの時に、クエリパラメータやHTTPリクエストボディ(POSTメソッド)が付いていればブロックする、と言った事がマニフェストで指示できるようになりそうです。 EPRにおけるリクエストカテゴリ 各エンドポイント(URL)はどのようなリクエストを受け付けることが可能か指定できます。その時に指定するリクエストは以下に分類されます navigational request：context frame typeは"top-level", "auxiliary", "neste
I18n.tでHTMLを出力するのにrawやhtml_safeを使ってはいけない - Qiita
みたいなのを書くわけですが、このままだと html_safe でないので自動的にエスケープされてしまいます。 <strong>tnj</strong>さんからメッセージがあります！ 悲しい！ 正しい HTML の含み方 この問題に直面した Rails I18n 初級者は、「じゃーエスケープ避けてそのまま出力させるしかなくない？」と、 raw だったり html_safe を付けてしまいがちです。 でもそうなると、もし @username にタグが含まれていた場合もエスケープされずに出力されてしまうので、簡単に XSS を引き起こしてしまいます。「ここはユーザー入力値は入らないから大丈夫だよ！」は絶対守り切れないし、変数を必要とするたびに「本当にユーザー入力値入ってこないんだっけ?」なんて判断をいちいち必要としていては時間がいくらあっても足りないので、機械に任せたいところです。 で、 Rai
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://utf-8.jp/public/20150917/owasp.pdf
