WasmでJavaScriptを動かす意義 - id:anatooのブログ
ある時Twitterのタイムラインを見ていたら、「JavaScriptをWasm化して動かす意味がわからない」というような意見を見かけました。JavaScriptはブラウザに搭載されているV8のようなJavaScriptエンジンによって高速に動作するので、わざわざWasm化してもパフォーマンスは劣化するのになぜなのか?という話なんですが、これは「Wasm化=パフォーマンスのため」という考えだと意義がわからないのでこの記事ではそれについて解説します。 JavaScriptをWasm化して動かすツールやライブラリとしては、Shopifyが開発しているJavyやquickjs-emscriptenなどがあります。JavaScriptをWasm化して動かすためには、ある特定のJavaScriptエンジンをWasm向けにビルドして動かす必要がありますが、そのような用途ではQuickJSというJava
‘-‘ という名前の、中身が無いのに70万回ダウンロードされてる謎のnpmパッケージ
– という名前の JavaScript/TypeScript パッケージについて警告を発している記事が話題となっています。 このパッケージ、中身はほとんど空で、Readme と、dev で TypeScript を動かせるようにするライブラリ群を呼ぶ箇所だけのもの。 しかし、この “-” を使っている他の npm パッケージが 50個以上あり、約一年前の公開時からのトータルのダウンロード数は72万回にもなります。 しかし、”-” を読み込んでいるパッケージを見てみても、”-” が必要そうには見えません。 警告記事では、この無名のパッケージが密かに使われるようになった原因が、npm コマンドのコマンドラインを打つときのミスタイプにあるのではないかとの仮説を立てています。 つまり、someFlag というオプションを使い npm i -someFlag somepackage と打つべきところ
アクセストークンをWebWorkerで扱う - console.lealog();
というアプローチを紹介してる記事があって、なるほど？と思ったのでまとめてみる。 元記事はこちら。 Leveraging Web Workers to Safely Store Access Tokens – The New Stack 毎度のことながら、今にはじまったことではない。 元記事いわく WebWorkerであれば、メインスレッドで実行されるであろうXSSや3rdのコードから触れないので安全！ 設計としては、 メイン: まず`Worker`をロード メイン: 初期化のメッセージを`postMessage()` クレデンシャルがあるならそれを渡す ワーカー: アクセストークンの準備 受け取ったやつ or そこで`fetch()`して、オンメモリに保存 （これで準備OK） メイン: APIにリクエストしてほしいと`postMessage()` ワーカー: APIに向けてアクセストークン
Shibuya.XSS techtalk #11
Yosuke HASEGAWA @hasegawayosuke 本日のShibuya.XSSの入館IDをconnpassのメッセージでお送りしましたので、参加者のみなさまご確認くださいませ！ #shibuyaxss 2019-05-16 16:40:18
JSでDoSる/ Shibuya.XSS techtalk #11
Shibuya.XSS techtalk #11 の発表資料です。
バグハンターのためのクライアントサイドJavaScriptの静的解析 - No1zy Web Security Blog
はじめに JavaScriptは、最新のWebブラウザで最も普及した技術の1つになっています。AngularJS、ReactJS、Vue.jsなどのクライアントサイドJavaScriptフレームワークを使用して構築されたアプリケーションは、多くの機能とロジックをフロントエンドに提供します。そしてロジック、機能の増加によってクライアントサイドのAttack Safaceも増加します。これらのAttack Safaceを理解し、脆弱性を発見する方法を身に着けることが必要です。 このブログ記事では、効率よくWebアプリケーションの脆弱性を発見するために、クライアントサイドJavaScriptの静的解析に注目して説明します。 今回は脆弱性を探す対象はOWASP Juice Shopです。Juice ShopはJavaScript製の意図的に脆弱に作られたアプリケーションです。 何を探すか? セキュ
Node.jsにおけるプロトタイプ汚染攻撃とは何か - ぼちぼち日記
1. はじめに 最近わけあってNodeのセキュリティ調査をしているのですが、今年の5月に開催された North Sec 2018 でセキュリティ研究者の Olivier Arteau 氏による 「Prototype pollution attacks in NodeJS applications」という面白い発表を見つけました。 この発表の論文や発表資料、デモ動画などもgithubで公開されていますし、ちょうどタイミングよくセッション動画も最近公開されました。 github.com Olivier Arteau -- Prototype pollution attacks in NodeJS applications この発表で解説されているのは、悪意のある攻撃者が、JavaScript言語固有のプロトタイプチェーンの挙動を利用して、Webサーバを攻撃する方法です。 発表者は、npmからダ
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
npmjs.com で著名ソフトウェアによく似た名前のマルウェアが大量に発見された - Islands in the byte stream
Malicious packages in npm. Here’s what to do | Ivan Akulov’s blog People found malicious packages in npm that work like real ones, are named similarly real ones, but collect and send your process environment to a third-party server when you install them 訳: 悪意のあるパッケージがnpmで発見された。それらは、実際のパッケージによく似た名前で同じように動くが、パッケージのインストール時にプロセスの環境変数を外部のサーバに送信する。 発見されたパッケージの一覧は元エントリをどうぞ。このようなマルウェアである偽パッケージの一例をあげると、 ba
Node.jsのセキュリティ・チェックリスト | POSTD
(訳注：2016/1/5、いただいた翻訳フィードバックを元に記事を修正いたしました。) セキュリティ – 誰もが見て見ぬふりをする問題 。セキュリティが重要だということは、誰もが認識していると思いますが、真剣にとらえている人は少数だと思います。我々、RisingStackは、皆さんに正しいセキュリティチェックを行っていただきたいと考え、チェックリストを用意しました。皆さんのアプリケーションが何千人というユーザやお客様に使用される前にセキュリティチェックを行ってください。 ここに挙げたリストのほとんどは概略的なもので、Node.jsに限らず、全ての言語やフレームワークに適用することができます。ただし、いくつのツールは、Node.js固有のものとなりますので、ご了承ください。 Node.jsセキュリティ に関するブログ記事も投稿してありますので、こちらも是非読んでみてください。 構成管理 HT
フロントエンド開発のためのセキュリティ | 第1回 XSSの傾向と対策
フロントエンド開発のためのセキュリティ 第1回 XSSの傾向と対策 本シリーズではフロントエンドの開発に関係するセキュリティについて、理解を深めます。第1回目はXSS（クロスサイトスクリプティング）です。実装失敗例を挙げつつ、対策のポイントを解説します。 セキュリティはサーバーサイドの問題？ セキュリティに関わるミスは「知らなかった」ではすまされない場合が、往々にしてあります。 ちょっとしたミスでプログラムにバグを作ってしまい、サービスが一部動かなくなったとしても程度にもよりますが、すぐに修正すれば一部のユーザーに少し不便をかけてしまう程度ですむでしょう*。 *注：サービス運営 この記事ではセキュリティの技術的な側面を扱います。ユーザーに不便をかけてしまったことに対するサービス提供側の倫理的問題についてはそのつど言及はしませんが、これらの側面を軽視すべきでないことはいうまでもありません。
本当にあったフロントエンドセキュリティ怖い話
「location.hrefが信用出来ない問題」 http://hoge.com%2F@example.com/へアクセスした場合にlocation.hrefがhttp://hoge.com/@example.com/を返す （勝手にデコードされている） location.href = location.hrefで別のページに飛ぶ iOS 6.0未満、Android4.1未満の標準ブラウザで再現 Masato Kinugawa Security Blog: location.hrefの盲点 「location.hrefが信用出来ない問題」 location.hrefに@使ってなにか入れるのは普通にできる （http://hoge:huga@example.com/のlocation.hrefはhttp://hoge:huga@example.com/） location.hrefを独自解析
Javascript で暗号化
NSEG 第 40 回勉強会で、mebius こと砂原昌史さんが発表でお使いになったスライドを代理でアップロードしました。Read less
XMLHttpRequestを使ったCSRF(補足編) - 葉っぱ日記
XMLHttpRequestを使ったCSRF対策 - 葉っぱ日記を書いていて思ったけど、いまいちXHRを使ったCSRF(というかクロスオリジン通信)について理解されていないような感じだったので、ちょっと書いておきます。とりあえず日本語のリソース的には、HTTP access control | MDN が詳しくて、それを読めばだいたい事足りるんで、あとはCSRFに関連しそうな話題だけ。 Q. そもそも「クロスオリジン」って何？ スキーム、ホスト、ポートの3つの組み合わせが一致している場合を同一オリジン(same-origin)、いずれか一つでもことなる場合をクロスオリジン(cross-origin)と言います。つまり、XHRでドメインを超えて通信している場合は典型的なクロスオリジン通信となります。 Q. え？ XMLHttpReuest って他のドメインにリクエストを発行できないんじゃ い
あまり知られていない脆弱性：DOM Based XSSにご用心｜アークウェブのブログ
こんにちは、SEの進地です。 XSS（Cross Site Scripting）脆弱性の中であまり注意を払われていないタイプにDOM Based XSSというものがあります。アナウンス自体は随分と昔から行われており、webappsec.orgでも2005/7/4にAmit Klein氏が"DOM Based Cross Site Scripting or XSS of the Third Kind"を発表しています。 Web 2.0的アプリなどでのAjaxの普及でJavaScriptが多用される現在のWeb開発では、DOM Based XSSが入り込む可能性は従来よりも高まっています。そこで、今回はこのDOM Based XSSについて説明しようと思います。 DOM Based XSSとは何か？ 一般的にXSS脆弱性と聞いて思い浮かべるのは、攻撃者の悪意ある入力データ（JavaScript
swfobject.js がアレな話 - ほむらちゃほむほむ
もばいる全盛感のある世間的には今更，FLASH なんてどうでもいいし，swfobject.js 自体 2009年から更新されてないから，こんな古いものをと言われかねないような話ではあるものの，日本語での言及をあまり見てないし，つい先日もさる通信キャリアがトップページでやらかしてて多分知られてないんだろうなと思ったので書こうと思った次第． swfobject.js とは何か この記事の対象読者にとっては説明するまでもない話とはおもうけど一応前置きとして説明しておくと，swfobject.js は FLASH を web ページに埋め込むための JavaScript のライブラリ．クロスブラウザ対応してたり，面倒な HTML-tag のお作法を覚えなくても良くなったりとでデファクトスタンダードな感じのモノ．2007年とちょい古いがリクルートMTL の SWFObject v2.0 ドキュメント
:visitedセレクタを使わない閲覧履歴の抽出方 - karasuyamatenguの日記
このタイトル見ると抽象的でピンとこないがこれを見てほしい： これ見たときはビビった。全部的中。 これはたった30行のJavaScriptで実装されている。 http://oxplot.github.com/visipisi/visipisi.html このリンク先のページの下の「Do the magic」というボタンを押すと自分の履歴が見れる。 各サイトの画像がブラウザにキャッシュされているかどうかをロード所要時間から推測している。 :visitedセレクタによる訪問履歴漏れはブラウザベンダーが対応しているようだけど、画像のロードスピードはユーザの体感スピードを損わずに隠すことはできないような気がする。画面には素早く見せて、JavaScriptのAPIにはゆっくり見せるなんてことしたら、何が壊れるかわからないし。 もしかしてブラウザの訪問履歴漏れの阻止ってのは不可能なのかもしれない。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://azu.github.io/slide//2019/template-engine/template-engine-security.pdf
19 Simple Twitter Retweet Tips
地獄のJavaScriptセキュリティ