アカウント名:
パスワード:
PNG偽装のスクリプト上げられるって中々に穴が開きそうな気がするんですが
JavascriptでPNGからスクリプト抽出&実行できる環境にアップローダーの組み合わせみたいな
アップロードディレクトリをpublic_htmlの外においている安全策もPHPには有効でしょうけどクライアントで実行されるスクリプトには無力なような
デモサイトを自前で公開する方はよく考えて実装したほうがよさげ
> PNG偽装のスクリプト上げられるって> 中々に穴が開きそうな気がするんですが
いや、もう穴自体はあいてますよ。ていうか、JavaScriptコードがエンコードされたファイルはあくまで画像ファイルですので、そこからJavaScriptコードの抽出処理を行わなければまったくの無害です。
問題は、どうやってコード抽出処理を行うか。ストーリーのリンク先で説明されていますが、このJS圧縮PNGは、自己展開実行機能を持たせることも可能としています。その原理は、
・IEはContent-Typeを無視し、データの中身を見てファイル種別を判断する・そのためPNGのヘッダ情報に(コメントデータとして)HTMLのタグっぽいものを埋め込んでおくと、HTMLデータと誤認する・そこで、PNGのヘッダに、HTMLとして「画像変換されたコードを抽出実行するJavaScriptコード」を埋めこんでおくと、・画像のURLを直接ブラウザで開くと、HTMLと解釈されて抽出コードが稼働し、画像化されたコードも実行される
という流れ。この前半部分、最初に展開コードの実行をキックする流れ自体は、「JSをPNGに変換する部分」とは無関係な技です。
つまり、今回のネタとは関係なく、「画像ファイルをアップロードできるアップローダ」で、「アップロードしたそのまま生の画像」を「(imgタグ経由ではなく)URL指定でブラウザから直接開くことができる」場合、余所のサイトから、 a href="画像URL"> といった画像直リンクを踏ませることで、スクリプトインジェクションが可能になる、ということです。
インジェクションさせないためには、アップローダとして、・画像アップローダでは、(拡張子偽装がされていないかどうか)実データの形式チェックは必須ですが、それに加えて、・ファイルのブラウザ直接表示はさせない(Content-Dispositionなどのヘッダを付けて、ダウンロードさせる)・画像は、アップロードしたファイルそのままではなく、不要なヘッダは捨てるフィルタ処理を行う・REFERチェックなどで、画像直リンクは許さないなどといった対策は必要でしょう。
#一番のガンは、Content-Typeを無視するIEですが…
Macで開発してるっぽいのに、なんでIEの話が出てくるん?
すみません、自己展開処理については説明を誤読してました。JavaScriptコードを埋め込んだPNGファイルを、拡張子 html にして(Content-Type: text/html にして)、ブラウザに送り込んでますね。これなら、IEに限らずブラウザ汎用で動作します。
でも、元コメの「穴があくんじゃないのか」という疑問に対しては、画像として特殊なことはしてませんので、だからどうしたということは特になく、そもそも「HTMLデータを送りこめてる」時点で大穴、ということになります。
気になるのは、これが PNG だからという理由でセキュリティソフトのチェックをすり抜けるかどうかです。
>ストーリーのリンク先で説明されていますがIEの話なんてどこに書いてあるんです?
確かに、リンク先の説明はブラウザ汎用っぽい文章になっており、IEの話なんて書かれてないんですが、実際のところそれが動作するのはIEだけです。それ以外のブラウザ(少なくともFirefoxとChromeとOperaとSafari)は、ちゃんとContent-Typeを見て動作しますので、Content-Typeを画像と偽装したHTMLデータがHTMLとしてレンダリングされることはありません。
いや、リンク先のデモ画像もMacのブラウザ(絶対IEではない)だろ...IE憎しで頭おかしくなってないか?
すみません、確かにIE憎しが念頭にありました。#2814116 [srad.jp]に書いた通りで、拡張子をhtmlに変えてしまえばMacでも何でも動作します。元コメの「穴が空いてるかどうか」については、「IEなら元から空いている」「IE以外なら大丈夫」ってことで。
どうしてもIEに穴があることにしたいようですが、いまやContent-Typeが無視されないようにするのはサイト管理者側の責任ですよ。# 互換性のためとはいえ、デフォルトが危険な状態なのは如何なものかとは思うけど。
https://www.google.co.jp/search?q=x-content-type-options+nosniff [google.co.jp]
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
これ大丈夫かな (スコア:0)
PNG偽装のスクリプト上げられるって
中々に穴が開きそうな気がするんですが
JavascriptでPNGからスクリプト抽出&実行できる環境に
アップローダーの組み合わせみたいな
アップロードディレクトリを
public_htmlの外においている安全策も
PHPには有効でしょうけど
クライアントで実行されるスクリプトには無力なような
デモサイトを自前で公開する方は
よく考えて実装したほうがよさげ
Re:これ大丈夫かな (スコア:2)
> PNG偽装のスクリプト上げられるって
> 中々に穴が開きそうな気がするんですが
いや、もう穴自体はあいてますよ。
ていうか、JavaScriptコードがエンコードされたファイルはあくまで画像ファイルですので、そこからJavaScriptコードの抽出処理を行わなければまったくの無害です。
問題は、どうやってコード抽出処理を行うか。
ストーリーのリンク先で説明されていますが、このJS圧縮PNGは、自己展開実行機能を持たせることも可能としています。その原理は、
・IEはContent-Typeを無視し、データの中身を見てファイル種別を判断する
・そのためPNGのヘッダ情報に(コメントデータとして)HTMLのタグっぽいものを埋め込んでおくと、HTMLデータと誤認する
・そこで、PNGのヘッダに、HTMLとして「画像変換されたコードを抽出実行するJavaScriptコード」を埋めこんでおくと、
・画像のURLを直接ブラウザで開くと、HTMLと解釈されて抽出コードが稼働し、画像化されたコードも実行される
という流れ。この前半部分、最初に展開コードの実行をキックする流れ自体は、「JSをPNGに変換する部分」とは無関係な技です。
つまり、今回のネタとは関係なく、「画像ファイルをアップロードできるアップローダ」で、「アップロードしたそのまま生の画像」を「(imgタグ経由ではなく)URL指定でブラウザから直接開くことができる」場合、
余所のサイトから、 a href="画像URL"> といった画像直リンクを踏ませることで、
スクリプトインジェクションが可能になる、ということです。
インジェクションさせないためには、アップローダとして、
・画像アップローダでは、(拡張子偽装がされていないかどうか)実データの形式チェック
は必須ですが、それに加えて、
・ファイルのブラウザ直接表示はさせない(Content-Dispositionなどのヘッダを付けて、ダウンロードさせる)
・画像は、アップロードしたファイルそのままではなく、不要なヘッダは捨てるフィルタ処理を行う
・REFERチェックなどで、画像直リンクは許さない
などといった対策は必要でしょう。
#一番のガンは、Content-Typeを無視するIEですが…
Re: (スコア:0)
Macで開発してるっぽいのに、なんでIEの話が出てくるん?
Re:これ大丈夫かな (スコア:1)
すみません、自己展開処理については説明を誤読してました。
JavaScriptコードを埋め込んだPNGファイルを、拡張子 html にして(Content-Type: text/html にして)、ブラウザに送り込んでますね。
これなら、IEに限らずブラウザ汎用で動作します。
でも、元コメの「穴があくんじゃないのか」という疑問に対しては、
画像として特殊なことはしてませんので、だからどうしたということは特になく、
そもそも「HTMLデータを送りこめてる」時点で大穴、ということになります。
Re: (スコア:0)
気になるのは、これが PNG だからという理由でセキュリティソフトのチェックをすり抜けるかどうかです。
Re: (スコア:0)
>ストーリーのリンク先で説明されていますが
IEの話なんてどこに書いてあるんです?
Re:これ大丈夫かな (スコア:1)
確かに、リンク先の説明はブラウザ汎用っぽい文章になっており、IEの話なんて書かれてないんですが、実際のところそれが動作するのはIEだけです。
それ以外のブラウザ(少なくともFirefoxとChromeとOperaとSafari)は、ちゃんとContent-Typeを見て動作しますので、Content-Typeを画像と偽装したHTMLデータがHTMLとしてレンダリングされることはありません。
Re: (スコア:0)
いや、リンク先のデモ画像もMacのブラウザ(絶対IEではない)だろ...
IE憎しで頭おかしくなってないか?
Re:これ大丈夫かな (スコア:1)
すみません、確かにIE憎しが念頭にありました。
#2814116 [srad.jp]に書いた通りで、拡張子をhtmlに変えてしまえばMacでも何でも動作します。
元コメの「穴が空いてるかどうか」については、「IEなら元から空いている」「IE以外なら大丈夫」ってことで。
Re: (スコア:0)
どうしてもIEに穴があることにしたいようですが、
いまやContent-Typeが無視されないようにするのはサイト管理者側の責任ですよ。
# 互換性のためとはいえ、デフォルトが危険な状態なのは如何なものかとは思うけど。
https://www.google.co.jp/search?q=x-content-type-options+nosniff [google.co.jp]