トップ  > メモ一覧  > カテゴリ「セキュリティ」の絞り込み結果 : 13件

13件中 1 〜 10 表示  1 | 2  次の3件> 最後»

No.4013【引用】PDOにおける一応の安全宣言と残る問題点

PDOにおける一応の安全宣言と残る問題点
http://blog.tokumaru.org/2011/08/pdo.html

PDOにおける一応の安全宣言と残る問題点
 
8月18日にPHP5.3.7がリリースされました。このリリースにより、PDOのSQLインジェクションの問題が一応解決されたと判断しましたので、ここに「一応の安全宣言」を表明するとともに、残る問題について報告します。

PDOの問題とは何か
以前、 ぼくがPDOを採用しなかったわけ(Shift_JISによるSQLインジェクション) に て報告したように、PHP5.3.5以前のPDOにはDB接続時に文字エンコーディン...

引用元

更新:2011/08/22 10:30 カテゴリ: PHP  > セキュリティ ▲トップ

No.492 ディレクトリトラバーザル

◆対策
    ホワイトリスト法
        方法
            開いて良いファイルを配列に格納
            その配列外であれば処理中断
        例
            if (in_array($_GET['data'], (許可ファイル名の配列))) exit;
        特徴
            長所
                想定外のファイルは間違いなく開かれない
            短所
                ファイルの場所が動的な場合に扱いにくい
    サニタイズ法
        方法
            ファイル名に「basename()」をかけてから渡す
        例
            readfile('/home/myhome/data/' . basename($_GET['data']));
        特徴
            短所
                パス遡り型以外には無力
    ブラックリスト法
        方法
            ファイル名に".."があった時点で処理を中断する
        例
            if (strtr($_GET['data'], '..')) exit;
        特徴
            短所
                rootへのアクセスを許してしまう
                パス遡り型以外には無力
    open_bassdir制限をかける※オプション
        方法
            開く可能性のあるディレクトリをリストアップし、「php.ini」または「httpd.conf」に記述
        例
            php.iniに
            open_basedir = /home/myhome/:tmp/:/usr/local/lib/php/ など
        特徴
            長所
                スクリプトにはノータッチでよい
            短所
                root権限が必要
◆攻撃例1
【目標】
readfile('/home/myhome/data/' . $_GET['data']);

【方法】
http://domain.com/index.php?data=../../../etc/passwd
--------------------------------------------------------------------------------------
◆攻撃例2
【目標】
readfile('/home/myhome/data/' . $_GET['data'] . '.dat');

【方法】
http://domain.com/index.php?data=../../../etc/passwd\00

◆対策
【ホワイトリスト法】
if (in_array($_GET['data'], (許可ファイル名の配列))) exit;

【サニタイズ法】
readfile('/home/myhome/data/' . basename($_GET['data']));

【ブラックリスト法】
if (strtr($_GET['data'], '..')) exit;

basename

(PHP 4, PHP 5)

basenameパス中のファイル名の部分を返す

説明

string basename ( string $path [, string $suffix ] )

この関数は、ファイルへのパスを有する文字列を引数とし、 ファイルのベース名を返します。

パラメータ

 

path

パス。

Windows では、スラッシュ(/) とバックスラッシュ (\) の両方がディレクトリ区切り文字として使われます。 その他の環境ではスラッシュ(/)になります。

suffix

ファイル名が、 suffix で終了する場合、 この部分もカットされます。

 

返り値

指定した path のベース名を返します。

変更履歴

 

バージョン 説明
4.1.0 パラメータ suffix が追加されました。

 

 

例1 basename() の例

<?php
$path 
"/home/httpd/html/index.php";
$file basename($path);         // $file は "index.php" に設定される
$file basename($path,".php");  // $file は "index" に設定される
?>

 

参考

 

  • dirname() - パス中のディレクトリ名の部分を返す
  • pathinfo() - ファイルパスに関する情報を返す

 



chgrp> <ファイルシステム 関数
Last updated: Fri, 19 Feb 2010
 
add a note add a note User Contributed Notes
basename
swedish boy
12-Oct-2009 10:43
Here is a quick way of fetching only the filename (without extension) regardless of what suffix the file has.

<?php

// your file
$file = 'image.jpg';

$info = pathinfo($file);
$file_name basename($file,'.'.$info['extension']);

echo
$file_name; // outputs 'image'

?>

引用元


更新:2010/02/22 14:17 カテゴリ: PHP  > セキュリティ ▲トップ

No.2003 SQLインジェクションとは何か?その正体とクラッキング対策。

SQLインジェクションとは何か?その正体とクラッキング対策。

世間では、今Gumblar祭りが勃発中であり、SQLインジェクションがニュースに出てくることは少なくなったが、だからと言ってSQLインジェクショ ンの脅威がなくなったわけではない。SQLインジェクションはGumblarを仕掛ける手段としても利用されることがあり、Webアプリケーションを提供 する全ての人にとって、対策を講じなければいけない驚異であることに変わりはない。SQLインジェクションという攻撃手法が認識され、大いに悪用されてい るにも係わらず、その本質に迫って解説している記事は少ないように思う。従来のWeb屋だけでなく、今やアプリケーション開発の主戦場はWebであると 言っても過言ではなく、そういう意味ではSQLインジェクションについて理解することは、全てのプログラマにとっての嗜みであると言えるだろう。

というわけで、今日は改めてSQLインジェクションについて語ってみようと思う。

SQLインジェクションとは?

SQLインジェクションは、一言で言うと不正にSQLを書き換えてしまう攻撃手法である。名前からすると データベース上のセキュリティ脆弱性のように思ってしまうかも知れないが、実はそうではなく、Webアプリケーション側の問題なのである。データベース は、安全なSQLであるか不正に書き換えられたSQLであるかを見分けることは出来ない。文法さえ正しければSQLを実行して結果をしまうのである。それ はデータベースにとって期待通りの動作であり、文法的に正しいSQLを実行するのは欠陥でも何もない。(むしろ実行出来ないのが欠陥であると言える。)つ まり、Webアプリケーション側でSQLが書き換えられた時点で、時はもう既に遅し!なのである。

従って、SQLインジェクション攻撃は特定のデータベースだけの問題ではない。MySQLはもちろんのこと、ポスグレだってオラクルだってDB2だって MS SQL ServerだってSQLインジェクションの餌食となりえるのである。なぜなら、Webアプリケーションの問題だから。おっと、もちろんFirebird もだ。

では、何故Webアプリケーション側でSQLインジェクション攻撃が可能なのか?というと、それは、WebアプリケーションがSQLを動的に組み立てるか らである。Webアプリケーションでは、まあ一番最悪な例では次のように、文字列を連結してSQL文を組み立てようとすることがある。
  1. $sql = "SELECT user, pass FROM users  
  2. WHERE user = '" + $user + "' AND pass = '" + $password + "'"  
$user や$passwordはHTMLの入力フォームから受け取った文字列であるとしよう。これは何らかのユーザー認証を仮定したものであるが、「これの何が悪 いの?」と思った人はアウト〜〜〜ッ!!である。これはまさにSQLインジェクションが可能なコードだからだ。

攻撃例

例えばユーザーとして「nippondanji」、パスワードに「fundoshi」という文字列を代入したとしよう。すると、このコードが生成するSQL文(つまりデータベースに投げられるもの)は次のようなものになる。
  1. SELECT user, pass FROM users WHERE user = 'nippondanji' AND pass = 'fundoshi'  
こ れのSQL文なら安全である。攻撃者は、$userや$passwordに相当する部分について様々なテクニックを使って攻撃をし、不正にログインした り、不正にクレジットカードなどの情報を入手したり、不正にデータを書き換えたりする。そして結果的に、文法は正しいが全く意味の異なるSQL文へと書き 換えてしまうことにより、攻撃を成立させるのである。SQLインジェクションに利用される書き換えのテクニックには様々なものが存在するが、例えば次のよ うなものが挙げられる。
  • クォーテーションを文字列の中に混入させる。これにより、攻撃者は新たなSQLの文法を注入=インジェクトすることが可能になる。
  • SQL文を途中でコメントアウトしてしまう。これにより、文法的に正しいSQL文を組み立てやすくなる。
  • OR 1=1など恒常的に成り立つ条件を利用する。これにより、WHERE句の条件を無視してしまう。
  • UNIONを用いて任意の情報を入手する。
  • INFORMATION_SCHEMAへアクセスしてどのようなテーブルが存在するかといった情報を入手する。
  • セミコロンを使って複数のSQL文を記述し、任意のSQL文を実行する。これにより、不正にデータを改竄してしまう。
攻撃 方法は数えあげればキリがないが、実に様々なバリエーションが存在する。(攻撃方法が分かったとしても、絶対に悪用してはいけないよ!)例えば、前述の SQL文に対してパスワードの確認をすっ飛ばしたいと思ったなら、$userに「nippondanji'#」というような値を混入させてしまうことであ る。そうすると、SQL文は次のように違った意味のものになってしまうだろう。
  1. SELECT user, pass FROM users WHERE user = 'nippondanji'#' AND pass = 'hoge'  
この例では、クォーテーションによって文字列が意図しないところで閉じており、なおかつハッシュ記号(#)以降はコメントアウトされてしまっているので、パスワードの値が何であってもユーザーが存在すればログイン出来てしまうのである!

もう一つ例を紹介しよう。次は、氏名からユーザーを検索するコードだと仮定して欲しい。
  1. $sql = "SELECT user, first_name, last_name, prof FROM users  
  2. WHERE MATCH(first_name, last_name) AGAINST ('" + $search + "')"  
例えばこのコードの$searchに対して「Mikiya」と入力すると次のようなSQL文になる。
  1. SELECT userpassword FROM users WHERE MATCH(first_name, last_name) AGAINST('Mikiya')  
あ あ、可愛そうなSQL・・・。このSELECT文を書き換えると、最悪の場合任意の情報をデータベースから抜き出すことが可能になる。例えば、検索語のと ころに「') LIMIT 0 UNION SELECT user, first_name, last_name, 1 FROM users ORDER BY RAND() LIMIT 10 #」という文字列を入れたとしよう。すると、このSQL文は次のようになってしまう。
  1. SELECT user, pass FROM users WHERE MATCH(first_name, last_name) AGAINST('') LIMIT 0 UNION SELECT user, first_name, last_name, 1 FROM users ORDER BY RAND() LIMIT 10 #')  
お わかりだろうか?全く意味の異なるSQL文であるが、これは文法的には正しい。そして、意図しない情報(この場合は任意のユーザーのパスワード10個)を 抜き出しているのである。UNIONを利用すれば任意のテーブルから任意の情報を取り出すことが可能であり、それはそれは恐ろしい攻撃が成立してしまうの である。しかも、UNIONを使ってINFORMATION_SCHEMAにアクセスすればどのようなテーブルが存在するかが把握出来るので、攻撃者は思 いのままに情報を入手出来てしまうだろう。

このように、SQLインジェクションは本当にヤバい攻撃なのである。

対策編

SQLインジェクションの最も確実で根本的な対策は、プリペアードステートメントを利用することである。問題は、SQLを組み立てる過程にあるので、動的にSQLを組み立てなければ原理的にはSQLインジェクションは発生しない。Web のフォームから受け取った値は、パラメータとしてプリペアードステートメントに渡せばいいわけである。ただし、プリペアードステートメント自身を動的に組 み立ててしまうと元の木阿弥なので注意しよう!また、せっかくプリペアードステートメントを利用しても、その中でストアドプロシージャを呼び出し、ストア ドプロシージャ内で動的なSQLの組み立てをやっていた・・・などということにもならないように注意したい。

何らかの事情によってプリペアードステートメントが利用出来ない場合は動的にSQLを組み立てるしかないが、その場合はWebのフォームから受け取った値 をチェックしたりエスケープしたりしてフィルタするしかない。例えば入力される値が数字であると分かっていれば、正規表現で不正な入力を簡単にはじくこと ができるだろう。文字列の場合にはしっかりとエスケープする必要があるが、攻撃者はフィルタをすり抜けて不正なシングルクォーテーションを混入させる手法 の発見に血道をあげており、フィルタの開発と攻撃手法の確立はいたちごっこであると言える。(今は完全に見えてもどこかに穴があるかも知れない。穴がひとつでも存在していれば一巻の終わりなのだ!)Webアプリケーションファイアウォールを使ってフィルタを強化するのもアリだろう。

ただし、フィルタはWebから受け取った値だけを対象にするだけでは不十分である。いったんデータベースへ不正な値を格納させておいてから、それを攻撃に 利用する「セカンドオーダーインジェクション」という手法が存在するので、フィルタはSQLを組み立てるのに利用する値全てに適用する必要があるので注意 しよう。

UNIONなどを使った攻撃では、そのSQL文を実行するユーザーが入手出来る情報なら、ありとあらゆるものが入手出来てしまう。従って、「このサービス はあんまりアクセスが多くないから・・・」などと思って油断してはならない。どれだけアクセスが少なかろうとも、SQLインジェクション攻撃が成立してし まった時の被害の大きさに違いは無いからである!油断しないこと!それが一番大事なSQLインジェクション対策であると言える。

その他の対策としては、データベースのセキュリティを徹底したり、大事な情報(パスワードやクレジットカード番号など)をアプリケーション側で暗号化して からデータベースに突っ込んだり、ハニーポットを仕掛けておいたり、といった基本的なことが考えられる。O/Rマッパーを使うのも有効である。(フィルタ が備わっていたり、自動的にプリペアードステートメントを使ってくれたりすることがあるため。)

まとめと宣伝

SQLインジェクションはとても恐ろしい攻撃であり、どのようなデータベース製品であろうとも、ひとたびSQLが書き換え られてしまうとそれを防ぐことは出来ない。そのためにはWebアプリケーション側でしっかりと対策をしておく必要がある。本稿ではSQLインジェクション の原理と対策について説明したが、何よりも重要なことは皆がSQLインジェクションの驚異を認識し、危機感を持つことである。そして、皆で協力し、対策を 講じるためのノウハウがWebに蓄積していくことが重要だと思う。この投稿も皆さんのお役に立てれば幸いである。

現在執筆中の書籍にも、SQLインジェクションの話が出てくるのだが、この記事よりもうちょっと(かなり?)詳しく説明している。春に発売する予定なので乞うご期待!!皆さん買って下さいw

引用元

更新:2010/01/14 10:33 カテゴリ: PHP  > セキュリティ ▲トップ

No.1802 SQLサニタイズ

addslashesを使わず

mysql_real_escape_string

(PHP 4 >= 4.3.0, PHP 5)

とか

PDO::quote

(PHP 5 >= 5.1.0, PECL pdo >= 0.2.1)

とか使うべし


※注意
mysqlとのコネクションを確立済みである必要がある

MySQL 接続。 指定されない場合、mysql_connect() により直近にオープンされたリンクが 指定されたと仮定されます。そのようなリンクがない場合、引数を指定せずに mysql_connect() がコールした時と同様にリンクを確立します。 リンクが見付からない、または、確立できない場合、 E_WARNING レベルのエラーが生成されます。

引用元

更新:2009/12/01 17:03 カテゴリ: PHP  > セキュリティ ▲トップ

No.1801 addslashesがいけてない理由

SJISで意図せずエスケープされてしまう恐れがある

詳細
 ↓


<内部コードがSJISで、magic_quotes_gpc=offの場合>
データーベースにクエリ文を送る場合、変数に対しaddslashesでエンコードが必要だが、
―⊇そソЫ綾噂化浬棺欺興圭現構砂蚕悉十晶申製曾遜箪捗貼峠能判表塀暴冥予僚禄
の文字に関しては、Shift_JISの2バイト目にエスケープの対象となる文字なので、

$str="本能";
$str=addslashes("$str");
$str="本能\";

となってしまい、
$query="INSERT INTO  test1 (str) VALUES('本能\')";
$result = mysql_query($query);
となってしまって
1064: You have an error in your SQL syntax near ''能\')' at line 1
のエラーとなってしまう。


これを改善する為には、
(1) Shift_JISでソースを書かない
(2) 一時的にEUC-jpやUTF-8などのコードに変換する
(3) 自作のaddslashesを作成する
(3') addslashesしたあとに自作関数で取り除く
の方法があり、

(2)の場合(私は結果的にこちらを選びました。)

function addslashes_sjis($sjis) {
	$euc=mb_convert_encoding($sjis,EUC,SJIS);
	$euc=addslashes($euc);
	$sjis=mb_convert_encoding($euc,SJIS,EUC);
	return $sjis;
}

(3') の場合(佐川さんの作られた関数)
function addslashes_ext3($sjis) {
  /*
   * 機能: 区切り文字(\xff)を入れて、ASCIIのみをaddslashesする。
   * 警告: 区切り文字が$sjisに含まれていた場合の動作は保証外。
   * 注意: ereg_replaceは\x00をサポートしていないことがあるので、
   *       \xffを使う。preg_replaceは、\x00をサポートしている。
   */

  // 文字コードの範囲
  $sjis_high = "[\x81-\x9f\xe0-\xfc]";
  $sjis_low  = "[\x40-\x7e\x80-\xfc]";
  $ank       = "[\x01-\x7f\xa0-\xdf]";

  // とりあえず、addslashesしちゃう
  $escaped = addslashes($sjis);

  // 問題が発生する文字列があるか調べる
  if (ereg("($sjis_high\\\\)\\\\", $escaped)) {
    // 問題がありそう。一文字ずつに分解する。
    $raw_char =
    $esc_char = explode("\xff",
                        ereg_replace("(${sjis_high}${sjis_low}|$ank)",
                                     "\\1\xff", $sjis));
    // 一文字ずつしらべる
    for($i=0; $i<count($raw_char); $i++)
      if (strlen($raw_char[$i]) == 1)
        $esc_char[$i] = addslashes($raw_char[$i]); // ASCIIのときはaddslashes
    // くっつける
    $escaped = implode("", $esc_char);
  }
  return $escaped;
}

PHPの言語解析器では、理解できないエスケープ記号は、そのまま出力するので
$str=addslashes_sjis("東十条");
//$str="東十条";
$query="INSERT INTO test.test1 (str) VALUES('$str')";
でもかまわないが、


一方 他の言語(例えばPerl)の言語解析器では、
英数字の前についた\は、特殊な意味を持ち、
記号の前の \ はその文字をエスケープしている...と解釈され
$str="東十\条";
$query="INSERT INTO test.test1 (str) VALUES('$str')";
でないと正しくINSERTされない。

引用元

更新:2009/12/01 16:59 カテゴリ: PHP  > セキュリティ ▲トップ

No.1321 IEのバグ,仕様によるセキュリティホール

IE のバグ,仕様によるセキュリティホール

今日は、MAIL ヘッダインジェクションをやろうと思っていたのだが、実は、過去にやっていました。>< http://nuts-choco.net/?p=38 ってことでIE (Google Chome も? もしかしてApple Web Kit なので Safariも??)

a の href属性などに 以下のように書くとJavascriptが実行できるが、IEの動作として、javascript の文字の間にヌルバイト、タブ、改行の制御コードを入力された状態でも、javascriptが実行されるとのこと。

<a href=”javascript:alert(‘good morning’)”>Hello</a>

<a href=”java
(タブ)scr(タブ)ipt:alert(‘good morning’)”>Hello</a>

実際に実験してみましたところ、二つとも正常にアラートが表示されました。
しかも、Google Chrome でも IEでも! Firefoxは上しか動作しませんでした。

good morning alert

固定のHTMLの場合、特に問題がないのですが、PHPなどで動的に制御を行う場合、上記の挙動を利用して、Javascriptが実行されてしまいます。

htmlspecialchars だけではチェックできないので、制御コードを除去した上で、javascript の文字を除去するといった方法があります。

preg_replace(‘/javascript/i’, ‘’, preg_replace(‘/[\x00-\x20\x22\x27]/’, ‘’, $strings));

preg_replace を二回使います。

引用元

更新:2009/08/14 09:57 カテゴリ: PHP  > セキュリティ ▲トップ

No.1233 ヌルバイトとは? ヌルバイト攻撃とバイナリセーフ関数

ヌルバイトとは、バイナリファイルの終端を表す文字列(C言語)のこと。 
\0 や \x00 で表現

・PHPのバイナリセーフでない関数は、バイナリデータの処理が正しくできない。

例: 
test.php

$test = “iCanFly\0 <script>alert(‘this is virus!’)</script>\n”;

echo (!ereg(‘\W’ $test))  ? $test : exit;

コマンドで、 php test.php と打ちます。 
上記の処理は、英数字以外の文字列の場合は、exitになるはずなのに、結果として、 $test が書き出されています。 
バイナリセーフでない関数は、ヌルバイトが終端として判断してしまうので、それ以降の文字列の判別を行わなくなります。

\0 を意図的に挿入することで、それ以降に 悪意のあるスクリプトを挿入し、意図しない挙動をプログラムに実行させることや、不要なディレクトリにアクセスさせたり、スクリプトの中身を見られるようなことになっていまいます。ちなみに 
echo (!mb_ereg(‘\W’ $test))  ? $test : exit; とすると 
きちんと exit されました。

バイナリセーフの関数を使うか、きっちりバリデート処理をさせるようにして、対処するのがいいと思います。

str_replace(‘\0’, $data);

ただ、単純にバリデートしてしまうと、バイナリファイルが扱えないので、上記の処理の前に、ヌルバイト処理をするか否かの判別をさせてから状況分けをしたほうがよさそうです。

◆定番

function sanitize( $arr )
{
    if ( is_array( $arr ) ) {
        return array_map( 'sanitize', $arr );
    }
    return str_replace( "\0", "", $arr );
}

$_GET    = sanitize( $_GET );
$_POST   = sanitize( $_POST );
$_COOKIE = sanitize( $_COOKIE );


◆発展

ちなみにOpenPNEは以下のようなバリデート式です。

http://trac.openpne.jp/browser/OpenPNE/trunk/webapp/lib/OpenPNE/Validator.php

295 
// NULL バイト・制御文字(HT,LF,NBSP以外)をすべて削除

296 
$value = preg_replace("/[\x{0}-\x{08}\x{0b}-\x{1f}\x{7f}-\x{9f}\x{ad}]/u", ”, $value);

$value = preg_replace("/[\x{0}-\x{08}\x{0b}-\x{1f}\x{7f}-\x{9f}\x{ad}]/u", ”, $value);
アスキー制御文字で検索


10:37:28
OpenPNEでntrimで制御文字を除去することになった起源

引用元

更新:2009/08/05 10:47 カテゴリ: PHP  > セキュリティ ▲トップ

No.1268 改行コードを利用したHTTPヘッダインジェクションやMailヘッダインジェクション

改行コードを利用した HTTPヘッダインジェクションやMailヘッダインジェクション
というものがあった。

URLに改行コード (%0D%0A)を含ませることで、クッキーを操作することができるというもの。

$url = html

例: http://URL/%0D%0ASet-Cookie:SID=aaaaaa

利用者に上記のようなURLにアクセスさせることで、SIDがセッション情報とした場合、その利用者のセッション情報を書き換えることができてしまいます。
↓前やったセッションハイジャックが可能なサイトの場合、上記の攻撃が有効になります。
http://nuts-choco.net/?p=18

URLやメールのヘッダの場合は改行コードの除去が必要になるので注意です。


◆OpenPNEでは

ちなみにOpenPNEは以下のようなバリデート式です。

http://trac.openpne.jp/browser/OpenPNE/trunk/webapp/lib/OpenPNE/Validator.php

295 
// NULL バイト・制御文字(HT,LF,NBSP以外)をすべて削除

296 
$value = preg_replace("/[\x{0}-\x{08}\x{0b}-\x{1f}\x{7f}-\x{9f}\x{ad}]/u", ”, $value);

$value = preg_replace("/[\x{0}-\x{08}\x{0b}-\x{1f}\x{7f}-\x{9f}\x{ad}]/u", ”, $value);
アスキー制御文字で検索

備考



 

引用元

更新:2009/08/05 09:51 カテゴリ: PHP  > セキュリティ ▲トップ

No.1234 バイナリセーフではない関数の一部

バイナリセーフではない関数の一部

ereg(), ereg_replace(), eregi(), eregi_replace(),
split(), spliti(),
include(), include_once(), require(), require_once()
fopen(), file_get_contents(), readfile(), basename()


バイナリセーフでない関数の例として、引数のファイル名に NULL バイトが含まれていると NULL バイトまでの部分をファイル名として認識する関数や制御構造には、以下のものがあります(おそらく、これら以外にもあると思います)。

  • fopen()

  • readfile()

  • file(), file_get_contents()

  • include(), include_once()

  • require(), require_once()

  • basename()

以下の POSIX 互換の正規表現関数も NULL バイトが含まれている文字列を正しく処理できませんので、気をつける必要があります。

  • ereg(), eregi()

  • ereg_replace(), eregi_replace()

  • split(), spliti()

また、途中でバイナリセーフに変更された関数や制御構造もあります。詳しくは、PHP 4 ChangeLog を binary safe というキーワードで検索してみると、他にもいくつか見つかります。これらの関数は、PHP のバージョンによって NULL バイトの扱いを気にする必要があるかもしれません。

  • strip_tags()

    PHP 4.3.2 からバイナリセーフに変更されています。

  • fgetcsv()

    PHP 4.3.5 からバイナリセーフに変更されています。

  • file()

    PHP 4.3.0 から、指定されたファイルの内容に NULL バイトが含まれていても、正しい結果を返すようになりました。

  • foreach, each()

    PHP 4.3.3 から、ハッシュのキーに NULL バイトが含まれていた場合でも正しく処理できるように変更されています。PHP 4.3.2 以前では、ハッシュのキーに NULL バイトが含まれていた場合、誤動作の原因となる可能性があります。また、ハッシュの値に扱いに関してはこの問題はありません。


引用元

更新:2009/07/29 10:00 カテゴリ: PHP  > セキュリティ ▲トップ

No.1122 allow_url_fopenとセキュリティ

allow_url_fopen はOFFにすべし

  1 <?php
  2 $a="/etc/php.ini";
  3 $file = file_get_contents($a, "r");
  4 var_dump($file);

とかやっちゃうと、サーバ内のファイルをふつーに見られちゃうよ(サーバないディレクトリとかを指定されると)
ユーザからのデータをfile_get_contents とかで取得し出力とかするとだめ

URLを指定しパースし出力したい場合は、simple_pieなどのライブラリを使用すべし!

引用元

更新:2009/07/07 10:16 カテゴリ: PHP  > セキュリティ ▲トップ
13件中 1 〜 10 表示  1 | 2  次の3件> 最後»

FuelPHP

Mac

web開発

プロマネ

マネタイズ

プレゼン

webサービス運用

webサービス

Linux

サーバ管理

MySQL

ソース・開発

svn・git

PHP

HTML・CSS

JavaScript

ツール, ライブラリ

ビジネス

テンプレート

負荷・チューニング

Windows

メール

メール・手紙文例

CodeIgniter

オブジェクト指向

UI・フロントエンド

cloud

マークアップ・テキスト

Flash

デザイン

DBその他

Ruby

PostgreSQL

ユーティリティ・ソフト

Firefox

ハードウェア

Google

symfony

OpenPNE全般

OpenPNE2

Hack(賢コツ)

OpenPNE3

リンク

個人開発

その他

未確認

KVS

ubuntu

Android

負荷試験

オープンソース

社会

便利ツール

マネー

Twig

食品宅配

WEB設計

オーディオ

一般常識

アプリ開発

サイトマップ

うずら技術ブログ

たませんSNS

rss2.0