技術情報 ページ 2 ｜Webシステム開発の株式会社フラッツ

こんにちは。木村です。

今回は4.3 Executable Code in File Uploadsです。

原文の単語と全く違う言葉に置きかえている場合が多々あります。原文ページと併せて、ご覧下さい。気になる箇所や間違っている箇所があれば、どうかご指摘下さい。

では、以下訳です。

———————-

4.3 Executable Code in File Uploads

4.3 アップロードファイル内の実行可能なコード

- Source code in uploaded files may be executed when placed in specific directories. Do not place file uploads in Rails’ /public directory if it is Apache’s home directory.

- アップロードファイル内のソースコードは特定のディレクトリに置かれている時に実行される可能性があります。もしRailsの/publicディレクトリがApacheのホームディレクトリならば、アップロードファイルを置かないでください。

The popular Apache web server has an option called DocumentRoot. This is the home directory of the web site, everything in this directory tree will be served by the web server. If there are files with a certain file name extension, the code in it will be executed when requested (might require some options to be set). Examples for this are PHP and CGI files. Now think of a situation where an attacker uploads a file “file.cgi” with code in it, which will be executed when someone downloads the file.

一般に使用されているApache WebサーバにはDocumentRootと呼ばれるオプションがあります。
これはWebサイトのホームディレクトリのことで、Webサーバはこのディレクトリツリーの中にある全てを扱います。もしある拡張子を持ったファイルがあった場合、その中のコードはリクエストされた時に実行されます(いくつかのオプションが設定されている必要があるかもしれない)。PHPやCGIファイルがそれに当たります。さて、攻撃者がコードが含まれた”file.cgi”ファイルをアップロードするシチュエーションを考えてください。誰かがそのファイルをダウンロードする(リクエストを出した)時そのファイルは実行されるでしょう。

If your Apache DocumentRoot points to Rails’ /public directory, do not put file uploads in it, store files at least one level downwards.

もしApacheのDocumentRootがRailsの/publicディレクトリになっているならば、そこにアップロードファイルを置かずに、少なくとも1階層下にファイルを保存してください。

———————-

次回は4.4 File Downloadsです。

こんにちは。木村です。

今回は4.2 File Uploadsです。

原文の単語と全く違う言葉に置きかえている場合が多々あります。原文ページと併せて、ご覧下さい。気になる箇所や間違っている箇所があれば、どうかご指摘下さい。

では、以下訳です。

—————————————————————–

4.2 File Uploads

4.2 ファイルアップロード

- Make sure file uploads don’t overwrite important files, and process media files asynchronously.

- ファイルアップロードで重要なファイルを上書きしないように、また、メディアファイルを非同期的に処理するようにしてください。

Many web applications allow users to upload files. File names, which the user may choose (partly), should always be filtered as an attacker could use a malicious file name to overwrite any file on the server. If you store file uploads at /var/www/uploads, and the user enters a file name like “../../../etc/passwd”, it may overwrite an important file. Of course, the Ruby interpreter would need the appropriate permissions to do so – one more reason to run web servers, database servers and other programs as a less privileged Unix user.

多くのWebアプリケーションはユーザにファイルアップロードを許可しています。ユーザが(部分的に)指定できるファイル名を、攻撃者がサーバ上のファイルを上書きするために悪意のあるファイル名を使用するかもしれないとして、常にフィルタするべきです。もし/var/www/uploadsにアップロードファイルを保存していて、ユーザが../../../etc/passwdのようなファイル名を入力したならば、重要なファイルが上書きされるかもしれません。もちろん、Rubyインタプリタがそのように実行する許可を割り当てられている必要があります。これがWebサーバやデータベースサーバやその他のプログラムをより少ない権限のUnixユーザとして実行する理由の一つです。

When filtering user input file names, don’t try to remove malicious parts. Think of a situation where the web application removes all “../” in a file name and an attacker uses a string such as “..‭..//” ? the result will be “../”. It is best to use a whitelist approach, which checks for the validity of a file name with a set of accepted characters. This is opposed to a blacklist approach which attempts to remove not allowed characters. In case it isn’t a valid file name, reject it (or replace not accepted characters), but don’t remove them. Here is the file name sanitizer from the attachment_fu plugin:

ユーザが入力したファイル名をフィルタする時、悪意のある部分を削除しようとしないでください。Webアプリケーション上でファイル名にある全ての「../」を削除し、攻撃者が「..‭..//」というような文字列を(ファイル名の一部に)使用する状況を考えてみてください。結果、「../」という文字列になります。ホワイトリストアプローチを使用することが最良の方法です。ホワイトリストアプローチは許可された文字のセットを用いてファイル名の有効性をチェックします。これは許可されない文字を削除しようと試みるブラックリストアプローチとは反対の方法です。有効でないファイル名であった場合、拒否してください(または許可されない文字を置換する)、しかし文字を削除しないでください。attachment_fu pluginのファイル名をサニタイズする部分を次に挙げます。

A significant disadvantage of synchronous processing of file uploads (as the attachment_fu plugin may do with images), is its vulnerability to denial-of-service attacks. An attacker can synchronously start image file uploads from many computers which increases the server load and may eventually crash or stall the server.

アップロードファイルの同期的な処理(attachment_fuプラグインは同期的にイメージを処理します)の著しく不利な点ははDoS攻撃への脆弱性です。
攻撃者は多くのコンピュータからイメージファイルアップロードを同期的に開始し、サーバの負荷を増大させ、最終的にはサーバをクラッシュまたは麻痺させることができます。

The solution to this is best to process media files asynchronously: Save the media file and schedule a processing request in the database. A second process will handle the processing of the file in the background.

この解決方法はメディアファイルを非同期的に処理することが最良の方法です。メディアファイルを保存して、データベースで処理リクエストをスケジューリングしてください。
セカンドプロセスがバックグラウンドでファイルの処理を担当します。

—————————————————————–

次回は4.3 Executable Code in File Uploadsです。