Visual Studio Code における任意コード実行の問題 - 葉っぱ日記
Microsoftの提供するテキストエディタ Visual Studio Code にはローカルに保存されている特定の名前のファイルを起動時に読み込み、その内容をコードとして実行してしまう問題があります。現在のv1.7.1では問題は解消されていますが、問題が発生することを確認したv0.8.0との間のどのバージョンで問題が修正されたのかは不明です。 Microsoftでは本件を脆弱性として取り扱っているのか不明です。 以下、IPA経由でのMicrosoftとのやり取りです。 2015-10-04 IPAへの報告 2) 脆弱性を確認したソフトウエア等に関する情報 名称：Visual Studio Code for Windows (https://code.visualstudio.com/) バージョン： v0.8.0 パッチレベル： 言語： 設定情報： ※ パッチレベルについては、マイナー
脆弱性"&'\ Advent Calendar 2014 (17日目) - 葉っぱ日記
この記事は脆弱性"&'<<>\ Advent Calendar 2014の17日目の記事です。今日は少し昔話をしようと思います。がはは。 かつて、日本製TwitterのようなWassrというサービスがありました。当時、Twitterは数日に一度くらいはサービスが落ちていて、Twitterユーザーも「またか」と思いながら我慢して使うようなサービスであり、Twitterが落ちるたびにWassrはユーザーを増やすとともに、画像の添付のように当時Twitterにはまだなかった機能をどんどんアグレッシブに取り入れていく、使っていて楽しいサービスでした。 さて、そんなWassrがある日絵文字機能を導入しました。当時はUnicode絵文字もなくスマートフォンも普及しておらず、主にレガシーな携帯電話で使える絵文字をなんとかWeb上でも使えるようにしたという感じのものでした。 絵文字をパレットから選択すると
ファイアウォール内のサーバに対するShellshockを利用した攻撃 - 葉っぱ日記
2014-09-27: 該当サイト上にXSSがなくても攻撃可能であることが id:mayuki さんのコメントで判明しましたので全面的に書き直しました。ファイアウォール内であっても攻撃者はファイアウォール内のShellshock攻撃が通用するCGIのURLがわかっているだけで攻撃可能ですので早急に対応が必要です！会社のブログにも書いてますが、ファイアウォール内に置いてあるサーバで攻撃者が直接アクセスできないからといってbashの更新を怠っていると、条件によっては攻撃が可能となります。 条件としては、 そのサーバにはシェルを経由して外部コマンドを起動するCGI等が動いている(通常のShellshockの攻撃と同条件) 攻撃者がそのURLを事前に知っている(あるいは推測可能) となります。 攻撃者は、ユーザーを罠URLへ誘導し、以下のようなJavaScriptを罠ページ上で動かし、攻撃対象のW
Web StorageやindexedDBを扱う上でのセキュリティ上の注意点 - 葉っぱ日記
localStorageやsessionStorage、あるいはindexedDBのようなブラウザ上でのデータの保存が可能になったことで、これらを取り扱ううえでもセキュリティ上の注意点が必要である。 これらのストレージは、localStorageやindexedDBは永続的に、sessionStorageはブラウザやタブを閉じるまでの間データが保持され続けるので、例えばWebアプリケーションがログイン機構を持っている場合にログイン中にこれらのストレージに書き込まれたデータは、ログアウト後も当然参照および書き換えが可能である。Webアプリケーション上のアカウントに紐づいたデータをこれらのストレージに書き込んでいる場合、ログアウト後もアクセス可能なことが問題を引き起こす可能性がある。 例えばTwitterのようなサービスがあったとして、(navigator.onLineプロパティなどを利用して
XMLHttpRequestを使ったCSRF対策 - 葉っぱ日記
合わせて読んでください：Flashと特定ブラウザの組み合わせでcross originでカスタムヘッダ付与が出来てしまう問題が未だに直っていない話 (2014-02/07) XMLHttpRequestを使うことで、Cookieやリファラ、hidden内のトークンを使用せずにシンプルにCSRF対策が行える。POSTするJavaScriptは以下の通り。(2013/03/04:コード一部修正) function post(){ var s = "mail=" + encodeURIComponent( document.getElementById("mail").value ) + "&msg=" + encodeURIComponent( document.getElementById("msg").value ); var xhr = new XMLHttpRequest(); xhr
GoogleのJSON(モドキ)の先頭にwhile(1); がつく理由 - 葉っぱ日記
なぜGoogleはJSONの先頭に while(1); をつけるのか #JavaScript #HTML #Ajax #StackOverflow - Qiita これはクロスサイト・リクエスト・フォージェリ対策。違うよ！全然違うよ！ 攻撃者の作成した罠ページにてJSONを<script src="target.json">みたいに読み込んで、ゴニョゴニョやることでJSON内の機密情報に攻撃者がアクセス可能というのは合ってるけど、それを「クロスサイト・リクエスト・フォージェリ」とは言わない。無理に何か名前をつけて呼ぶとすれば、「JSON Hijacking」という俗称や、あるいは単純にクロスサイトでの情報漏えい、程度ですかね。 ちなみに、ArrayコンストラクタやObjectでのアクセサを定義してJSONをJSとして読み込んで内部にアクセスする手法は、現在のところ公にされているところでは古
私はいかにして様々なブラウザの脆弱性を発見したか - 葉っぱ日記
先日、Twitterでどのように脆弱性を見つけるかに興味あるんだろうかと書いたら、意外に色々な人から反応があったので、これまでに自分が見つけた脆弱性のいくつかについてどういう経緯で見つけたのかちょっと書いてみます。 JVN#89344424: 複数のメールクライアントソフトにおける、添付ファイルによりメールクライアントソフトが使用不能になる脆弱性 これは、添付ファイル名にUnicodeの円記号を含めておくと、メーラ側でShift_JISに変換する際にバックスラッシュに変換されてしまって想定外のディレクトリに添付ファイルが展開されてしまったり、あるいは「©on」のような名前のファイルを添付しておくことでShift_JISに変換してCONというファイルを開こうとしてメーラが固まってしまうという問題です。これは、私自身が文字コードの問題について調べ始めた初期段階で、Unicodeからの変換で問題
JSONのエスケープをどこまでやるか問題 - 葉っぱ日記
Ajaxなアプリケーションにおいて、サーバからJSONを返す場合に、JSON自体はvalidであるにも関わらず、(IEの都合で)エスケープが不足していて脆弱性につながってる場合があるので、書いておきます。 発生するかもしれない脆弱性 JSONのエスケープが不足している場合に発生する可能性のある脆弱性は以下の通りです。 JSON内に含まれる機密情報の漏えい XSS それぞれの詳細については後述します。 開発側でやるべきこと 文字列中のUnicode文字は "\uXXXX" な形式にエスケープするとともに、ASCIIな範囲であっても「/」「<」「>」「+」も同様にエスケープすることにより、前述の脆弱性を防ぐことができます。 Perlであれば、以下のような感じになります。JSON->ascii(1) に続けて、JSON文字列を正規表現で置換しているあたりがキモになります。 use utf8; u
ブラウザでJavaScriptが動く時代がやってきた！ - 葉っぱ日記
というわけで、昨日から話題沸騰の Javascript PC Emulator すごいですね。JavaScript で書かれた x86 PC エミュレータ上で Linux 動かして、入ってる tcc 使えばそこそこのソースもコンパイルして動いたり。 もとのディスク容量が少ないので、適当な母艦を用意して、こんな感じ で新しいディスクイメージ作って、CocProxy や Fiddler の AutoResponder を使って root.bin へのリクエストをローカルのファイルに差し替えてやれば、好きなファイルも入れられますね。 というわけで、SpiderMonkey を入れて動かしてみました。ブラウザ内でJavaScriptが動くなんてムネアツですね！ 手順としては、コンパイルの簡単な SpiderMonkey 1.7 を x86 の32ビットマシンで -static 付きでビルドして、r
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
