Node.jsにおけるprototype汚染攻撃への対策 - SSTエンジニアブログ
はじめに こんにちは、CTOのはせがわようすけです。 少し前に大津さんが Node.js におけるprototype汚染攻撃を紹介する記事を掲載されていました。 Node.jsにおけるプロトタイプ汚染攻撃とは何か どういう原理での攻撃なのかの解説は大津さんの記事を参照頂くとして、記事内で紹介されている講演の動画では最終的に任意コード実行まで至っているという点で非常に興味深いものがあります。 攻撃の経路としてはクライアントからHTTP経由でJSONをPOSTするというだけですので、いくら Object.prototype を上書きできたとしても送ることのできるデータはJSONで表現可能なプリミティブな型のみで、JavaScriptの関数は含めることはできません。 この講演動画で扱われているGhost CMSというソフトウェアでは、__proto__ 経由でテンプレートのファイル名だけでなくそ
ユーザ由来の構造化データによるSQLインジェクション | tech - 氾濫原
Kazuho's Weblog: The JSON SQL Injection Vulnerability について。元記事をはっちゃめっちゃに要約すると SQL::Maker にユーザから受けとったデコード済み JSON をそのまま突っ込むと SQL インジェクションになる場合がある SQL::Maker 側でそういったことが起こらないように strict オプションをつけたから、できればそっち使え 別に SQL::Maker に限らないから気をつけろ という話っぽい。本来であればユーザ入力をタイプチェックをすべきだけど、クエリビルダレベルでも、脆弱性にならないようにもうちょっと考慮してもいいよねという趣旨かな… strict モードは非互換なので、既存のコードが動かなくなる可能性があるようです。 Teng での対応 Teng を使っているとデフォルトで SQL::Maker がクエリビ
The JSON SQL Injection Vulnerability
tl;dr Many SQL query builders written in Perl do not provide mitigation against JSON SQL injection vulnerability. Developers should not forget to either type-check the input values taken from JSON (or any other hierarchical data structure) before passing them to the query builders, or should better consider migrating to query builders that provide API immune to such vulnerability. Note: 問題の発見者による日
Amon2とJSONとセキュリティ - tokuhirom's blog
[1]http://d.hatena.ne.jp/ockeghem/20110907/p1[2]http://www.atmarkit.co.jp/fcoding/articles/webapp/05/webapp05a.html[3] http://msdn.microsoft.com/ja-jp/asp.net/ff713315[4] http://labs.cybozu.co.jp/blog/kazuho/archives/2007/01/cross-site_including.phpあたりをよんで、JSON とセキュリティについてかんがえてみた。 ここで、有効とされている対策のうち while(1); を先頭に付与するPOST ですべて処理するといったあたりは、RESTful でないし、BK 感がひどいというか本質的ではないのでできるだけやりたくない。 また、Amon2 では互換
JSONのエスケープをどこまでやるか問題 - 葉っぱ日記
Ajaxなアプリケーションにおいて、サーバからJSONを返す場合に、JSON自体はvalidであるにも関わらず、(IEの都合で)エスケープが不足していて脆弱性につながってる場合があるので、書いておきます。 発生するかもしれない脆弱性 JSONのエスケープが不足している場合に発生する可能性のある脆弱性は以下の通りです。 JSON内に含まれる機密情報の漏えい XSS それぞれの詳細については後述します。 開発側でやるべきこと 文字列中のUnicode文字は "\uXXXX" な形式にエスケープするとともに、ASCIIな範囲であっても「/」「<」「>」「+」も同様にエスケープすることにより、前述の脆弱性を防ぐことができます。 Perlであれば、以下のような感じになります。JSON->ascii(1) に続けて、JSON文字列を正規表現で置換しているあたりがキモになります。 use utf8; u
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DeNA Engineering - DeNAエンジニアのポータルサイト
