web-dev-qa-db-ja.com

画像ファイルでphpスクリプトを実行することは可能ですか？

画像アップロードのphpウェブサイトがあります。ユーザーは私のウェブサイトに画像をアップロードできます。ユーザーがアップロードした画像を使用して私のウェブサイトをハッキングできると主張しています。

サーバーにアップロードしたすべての画像をメモ帳で開きました。 1つの画像の最後の行は次のとおりです。

Àpa@ ;
<?php

echo "test ok";
?>

この画像を使用して私のウェブサイトをハッキングできますか？ユーザーがこのような画像をアップロードできないようにするにはどうすればよいですか？

web-applicationphpwebserver
18
open source guy

画像のアップロード（一般に任意のファイル）を完全に安全にすることは非常に困難です。特に、多くの攻撃ベクトルを提供するPHPでは特にそうです。

たとえば、次のように呼び出して画像を表示する場合

require($someImage);

その画像にはPHPコードが（投稿したものと同様に）内部に含まれています）、そのように解釈および実行される場合があります。

私の推測では、彼があなたのサイトを所有していると主張すれば、おそらく彼は所有しているでしょう。あなたが提供した画像自体は、print "test ok"以外は何もしませんが、そのコードは、サイトやサーバーへの不正な（完全に無制限の）アクセスを許可するコードと簡単に交換できます。

サイトにアップロードされたファイルが実際に画像であることを確認するには、Gd（またはImagick）を使用してファイルを再処理し、処理された画像を保存します。他の多くの攻撃（たとえば、ディレクトリトラバーサルやファイルの上書き）が発生する可能性があるため、特に元のファイル名を使用して元の画像を保存することはお勧めできません。

詳細： https://www.owasp.org/index.php/Unrestricted_File_Upload

13
GBC

はい、サーバーは実行できましたPHP画像ファイル内のコードそれが正しく構成されていない場合：

http://www.phpclasses.org/blog/post/67-PHP-security-exploit-with-GIF-images.html

その例が_image.gif.php_です。ファイルは有効な画像およびの両方が有効ですPHPスクリプト、画像サイズやその他のプロパティを確認するだけでは不十分です。 ストリップメタデータ でも十分ではありません。圧縮されていないGIFにはPHPが画像データとして含まれている可能性があります（不自然かもしれません）、PNGは 任意のデータチャンク 。

この欠陥は、サニティチェックが不十分なアップロードを受け入れ、特に\.(png|gif|jpg|jpeg)（_.php_アンカーなし）などのアンカーされていない正規表現を使用して、不要なファイル名（_$_など）を防止しようとしています。andPHP処理が有効になっているディレクトリからこれらの画像を提供できるようにします。ベストプラクティスは、ユーザーが指定したファイル名を使用しないことです。そのまま。

これらはかなり古典的な data validation および input validation failuresです。

PHPのインストール手順（Apache 2の場合） を実行すると、Apacheの設定に次のようになります。

_<FilesMatch "\.ph(p[2-6]?|tml)$">
    SetHandler application/x-httpd-php
</FilesMatch>
_

_$_アンカーに注意してください。これにより、_file.php.gif_がPHPによって解釈されなくなります。 （これらの手順に欠けているのは、PHPが、信頼できるコードのみを含む_<Directory>_コンテキストによって制限されており、Webサーバーユーザーが書き込みできないことを確認することです） 。）

これらの手順に従わない場合は、代わりに_mod_mime_のAddType（またはAddHandler）を使用してください。

_AddType application/x-httpd-php .php      # STOP! 
_

_mod_mime_が複数の拡張子を持つ予期しない/ を実行する可能性があるため、これは同じ問題を引き起こす可能性があります。 http://blog.dynom.nl/archives/Be-careful-with-double-extensions_20081024_25.html をご覧ください（thanks toHendrik Brummermannこれを指摘してください）。このリスクは、正しく構成された_<Directory>_コンテキストを使用して、信頼できるコードのみを許可することで軽減できます。

このドキュメント（PDF）は少し古いですが、緩和策については十分にカバーしています： http://www.net-security.org/dl/articles/php-file-upload.pdf

別の考えられる問題の原因は、安全でないinclude/requireステートメント（このPDFでも説明されています）であり、これにより、攻撃者はクエリ文字列またはHTTPリクエストヘッダーを変更することにより、アップロードされたコンテンツをincludeできます。

最近の関連する質問も参照してください： PHP画像アップロードフォーム のリスク/（getimagesizeを使用して画像を確認し、 PHPを使用して、アップロードされた画像ファイルにマルウェアがないか確認しますか？ （便利なリンクのセットが含まれています）。

20
mr.spuratic

私はあなたがLAMPを実行していると仮定します（そして他のphp設定の答えは非常に似ています）.

おそらく、彼のコードはあなたのサイトに何もできません。

Apacheがサーバーの/var/wwwからファイルを提供しているとしましょう。あなたのウェブサイトで誰かがindex.phpにアクセスしたとします。

  1. Apacheは/index.phpを探していることを受け取ります
  2. Apacheはファイル/var/www/index.phpを探します

  3. Apacheがmod_phpを実行している場合、index.phpが何らかの方法でmod_php設定ファイルのルールに一致するかどうかを確認します。 mod_php設定ファイル（おそらく/etc/Apache2/mods-available/php5.confにあります）は、おそらく以下で作成したこの最小限の例のスーパーセットです。

    <IfModule mod_php5.c>
    <FilesMatch ".+\.ph(p[345]?|t|tml)$">
        SetHandler application/x-httpd-php
    </FilesMatch>
</IfModule>
    • ファイル名が一致する場合、Apacheはphpインタープリターを介してファイルを実行し、ユーザーに提供するWebページを作成します。
    • ファイル名が一致しない場合、Apacheはユーザーにそれを提供します。
    • （これらの詳細は、ここでは関係ないと思うApacheの多くの部分をスキップします）

ユーザーがevil_image.pngなどの画像をアップロードし、その中に任意のPHPコードが含まれているとします。

また、どこかからユーザーにサービスを提供しているとします。たとえば、/images/evil_image.png（ファイルシステム内では/var/www/images/evil_image.png）とします。

誰かが/images/evil_image.pngのWebサイトにアクセスしてこの画像を取得しようとすると、Apacheは上記で概説した手順を実行します。ステップ3で、/images/evil_image.pngパターンと一致しません構成ファイルから、-phpとしてコードを実行しませんとなります。ユーザーに画像を提供するだけです。

ユーザーは内部に悪意のある細工されたテキストが保存された画像ファイルを受け取ります。重要なのは、サーバーがコードを実行しようとしていないため、コードが無効になっていることです。

そのコードを実行することは不可能だと言っているのではありません。そのコードを実行させるには、Webサーバーの設定を大幅に失敗させる必要があることをお伝えします。

1
David Mah