Tag: MySQL’

phpでエラーを表示させながらプログラムを作りたい時

 - by naoki

基本的にサーバーの設定はworningや重要じゃないエラーは表示されないようになっているんだけど、新しくプログラムを書いているときにデバッグ的な感じであえてエラーやworningを出しながら作りたいときがあるんですよ。
もちろん、サーバーのphp.iniで
error_reporting = E_ALL
なんて書いてapacheを再起動しちゃえばいいわけなんですが、これだと全てのphpプログラムに影響が出てしまうんです。
そんなときは、エラーを表示させたいphpプログラムの最初の1行目に以下の2行を記入すればおk。

ini_set(‘display_errors’,true);
ini_set(‘error_reporting’,E_ALL);

コピペ代わりに!

H520s
BUFFALO Giga対応 スイッチングHub ホワイト LSW4-GT-8NS/WH

ELECOM LANケーブル CAT6準拠 Gigabit スーパーフラット ブラック 5m LD-GF/BK5

phpMyAdminの脆弱性を狙った攻撃が増加中

 - by naoki

phpMyAdminを狙う攻撃が増加だってさ。
うちの環境は最新の状態になっているから大丈夫そうだけど、某ホスティングサービスのレンサバとか大丈夫なのだろうか。
ちなみに「さくらインターネット」さんは3.3.10.3だった。

2011年の年末から2012年にかけて、phpMyAdminの脆弱性を狙った攻撃が増加しており、
注意が必要だ。いくつかのブログで、phpMyAdminの脆弱性をスキャンしたと見られる
ログが報告されている。

phpMyAdminは、PHPで実装されたMySQLの管理ツールだ。
機能が豊富で、Webインターフェイス経由でMySQLを管理できることから広く利用される一方で、
複数の脆弱性が発見されており、たびたび攻撃の標的になってきた。
古くは2009年3月に、「phpMyAdminのsetup.phpにおける任意のPHPコードを挿入される
脆弱性(CVE-2009-1151)」が発見され、学術機関を中心に被害が発生した。
また2011年7月にも、任意のコードを実行可能な2種類の脆弱性(CVE-2011-2505、CVE-2011-2506)が
発見されている。この脆弱性に関するNTTデータ先端技術のレポートによれば、
これら2つの脆弱性を組み合わせて利用し、細工したHTTPリクエストを送り付けることによって、
Webサーバの実行権限で任意のPHPコードを実行可能となってしまう。実際に同社が、
Debian6.0.2上のphpMyAdmin3.3.10を用いて検証を実施したところ、細工を施した
HTTPリクエストを介してコンフィグファイルを出力させ、任意のコマンドを実行できる
スクリプトを設置、実行できることが明らかになった。

またラックでは2011年12月16日に、phpMyAdminの脆弱性を狙った攻撃に関する被害相談が
複数寄せられていることを受け、注意喚起を行っていた。
対策は、脆弱性を修正済みのバージョン3.3.10.2/3.4.3.1以上にアップグレードすること。
また、基本的にphpMyAdminは外部に公開する必要はないため、インターネットに公開しないか、
するとしても接続できるIPアドレスを制限するといった手法も有効だ。

http://www.atmarkit.co.jp/news/201201/16/phpmyadmin.html

SQLの勉強の過程で参考になった記事@PHPプログラマがおかしがちなミスTOP10

 - by naoki

SQLの勉強をしているときに出会ったサイト。
PHPSPOT開発日記さんのエントリーで参考になったものがあったので、ここに残しておきます。
すごく初歩的なことなんだけど、独学でやってる身としては参考になりました。

以下初級PHPプログラマがおかしがちなミスTOP10参照。
参照元URL:http://phpspot.org/blog/archives/2007/01/php_71.html

「PHPプログラマがおかしがちなミスTOP10」、という記事があったので紹介。
PHP初心者だとこういうミスがよくありますね。ということで今年からPHPをはじめようと思っている人には気をつけてほしいリストです。

生でクエリを出力しない
echo $_GET[‘username’];

echo htmlspecialchars($_GET[‘username’], ENT_QUOTES);

やらないとクロスサイトスクリプティングされます。
SQLクエリに$_GET,$_POST,$_REQUESTの値を直接含めない
$sql = “select * from table where id=”.$_GET[“id”];

$sql = “select * from table where id=?”; (プレースホルダを使う)
やらないとSQLインジェクションされます。
header, session_start, setcookieを何か出力した後に実行
悪い例)
echo “HOGE”;
header(“Location:/html/”);

// echo “HOGE”;
header(“Location:/html/”);
出力処理を先に行うとちゃんとheader関数が実行されません。session_start, setcookieも同様。
何かの出力処理の前に実行したい場合は出力をバッファリングしておいて、header呼び出しの後にバッファを出力する。
ユーザクエリを元にincludeしない
include($_GET[“filename”]);
そもそもこういったコーディングは危険なので避けるべきです。サーバにあるファイルが覗かれてしまいます。
php.iniのopen_basedirによる制限などもしておいた方がよいですね
php.iniのmagic_quotes設定による自動エスケープの罠
このオプション設定によって ‘ , ” , , NUL が自動エスケープされますが、それによってデータにエスケープ文字がはいってしまうという問題がありますね。
addslashes関数による2重エスケープなんかも起こることがあります。
マニュアルに、「マジッククオートは、PHPスクリプトに入力されるデータを 自動的にエスケープする機能です。 コードでは、マジッククオートをオフにして 実行する際必要な時にデータをエスケープすることが望まれます。」とあるので、それに従った方が良さそうです。
オープンソースなプログラムなんかでは、phpの設定は関係なく、どのサーバでもちゃんと動くようにget_magic_quotes_gpc関数によって設定を調べてstripslashesで取ったりする必要がありますね。

xamppでMySQLから引っ張ってきた日本語文字列が文字化けする件

 - by naoki

コンテンツの作成・動作確認を自分のWindowsXPノートにxamppを入れてやっているんだけど、データベースから持ってきた文字列が文字化けしてしまう現象に悩まされておりました。

localで動作確認するときは文字化けとかじゃなくて、sql文が間違ってないかとかレイアウトはどうだとかの確認でやってるので、別に困ってはいなかったわけですが、気持ちよく動作確認をしたかったので、ちょっと調べてみました(本番のサーバでは文字化け起こしていないから)。

$user_name = mb_convert_encoding($user_name,”UTF-8″,”SJIS”);

↑こんな風にPHPのソースに手を加えれば解決するんだけど、実際に動作しているサーバーにコンテンツを上げると文字化けは起こさない(サーバーのcharacter-setはutf8)ので、my.iniを編集することで文字化けを解消しました。

まぁ環境をサーバを合わせたってところやね。

設定方法はmy.iniに以下を追記。

[mysqld]
default-character-set=utf8
skip-character-set-client-handshake

※utf8を環境に合わせてEUCの場合は以下のように変えれば文字化けは解消されるんじゃねーかと思います。
default-character-set=ujis

キヤノン FINE カートリッジ BC-311 3色カラ-
キヤノン FINE カートリッジ BC-310 ブラック