PHP」カテゴリーアーカイブ

phpMyAdminへの不正アクセスについて

なんやかんやで、昔からphpMyAdminへの不正アクセスアタックはあるもので。

以下、どんなリクエストがあるか、リストします。
※DocumentRootが/var/www/htmlの場合です

/var/www/html/MyAdmin
/var/www/html/_phpmyadmin
/var/www/html/admin
/var/www/html/cpanelphpmyadmin
/var/www/html/cpphpmyadmin
/var/www/html/db
/var/www/html/dbadmin
/var/www/html/myadmin
/var/www/html/mysql
/var/www/html/mysqladmin
/var/www/html/php
/var/www/html/php-my-admin
/var/www/html/phpMyAdmin
/var/www/html/phpMyAdmin-2
/var/www/html/phpMyAdmin-2.10.0
/var/www/html/phpMyAdmin-2.10.0.0
/var/www/html/phpMyAdmin-2.10.0.1
/var/www/html/phpMyAdmin-2.10.0.2
/var/www/html/phpMyAdmin-2.10.1.0
/var/www/html/phpMyAdmin-2.10.2.0
/var/www/html/phpMyAdmin-2.11.0.0
/var/www/html/phpMyAdmin-2.11.1-all-languages
/var/www/html/phpMyAdmin-2.11.1.0
/var/www/html/phpMyAdmin-2.11.1.1
/var/www/html/phpMyAdmin-2.11.1.2
/var/www/html/phpMyAdmin-2.6.1-pl2
/var/www/html/phpMyAdmin-2.6.1-pl3
/var/www/html/phpMyAdmin-2.6.4-pl3
/var/www/html/phpMyAdmin-2.6.4-pl4
/var/www/html/phpMyAdmin-2.6.4-rc1
/var/www/html/phpMyAdmin-2.6.5
/var/www/html/phpMyAdmin-2.6.6
/var/www/html/phpMyAdmin-2.6.9
/var/www/html/phpMyAdmin-2.7.0-beta1
/var/www/html/phpMyAdmin-2.7.0-pl1
/var/www/html/phpMyAdmin-2.7.0-pl2
/var/www/html/phpMyAdmin-2.7.0-rc1
/var/www/html/phpMyAdmin-2.7.5
/var/www/html/phpMyAdmin-2.7.6
/var/www/html/phpMyAdmin-2.7.7
/var/www/html/phpMyAdmin-2.8.2
/var/www/html/phpMyAdmin-2.8.2.3
/var/www/html/phpMyAdmin-2.8.3
/var/www/html/phpMyAdmin-2.8.4
/var/www/html/phpMyAdmin-2.8.5
/var/www/html/phpMyAdmin-2.8.6
/var/www/html/phpMyAdmin-2.8.7
/var/www/html/phpMyAdmin-2.8.8
/var/www/html/phpMyAdmin-2.8.9
/var/www/html/phpMyAdmin-2.9.0
/var/www/html/phpMyAdmin-2.9.0-rc1
/var/www/html/phpMyAdmin-2.9.0.1
/var/www/html/phpMyAdmin-2.9.0.2
/var/www/html/phpMyAdmin-2.9.1
/var/www/html/phpMyAdmin-2.9.2
/var/www/html/phpMyAdmin-3.0.0-rc1-english
/var/www/html/phpMyAdmin-3.0.0.0-all-languages
/var/www/html/phpMyAdmin-3.0.1.0
/var/www/html/phpMyAdmin-3.0.1.0-english
/var/www/html/phpMyAdmin-3.0.1.1
/var/www/html/phpMyAdmin-3.1.0.0
/var/www/html/phpMyAdmin-3.1.0.0-english
/var/www/html/phpMyAdmin-3.1.1.0-all-languages
/var/www/html/phpMyAdmin-3.1.2.0
/var/www/html/phpMyAdmin-3.1.2.0-all-languages
/var/www/html/phpMyAdmin-3.1.2.0-english
/var/www/html/phpMyAdmin-3.4.3.1
/var/www/html/phpMyAdmin2
/var/www/html/phpMyAdmin3
/var/www/html/phpadmin
/var/www/html/phpmyadmin
/var/www/html/pma
/var/www/html/scripts
/var/www/html/websql

上記に該当するURLの方は変更した方がよろしいかと。

では。

PHPでのバイト数の取得方法について

久々の更新でございます。

画面から入力された文字列のバイト数をPHPで取得する際にハマったので。

調べてみると、まず最初に目に付くのは「strlen()を使え」と。

しかしながら、環境によっては「strlen()がmb_strlen()にオーバーライドされる」との事。

で、下記のようにすれば取得出来ます、とのエントリを見つけたのでやってみたのですが・・・

$str_length = strlen(bin2hex($data)) / 2;

結果、ダメでした。
検証環境のサーバ設定にもよるのかもだけど、下記のようにバイト数が返却されるので、全角半角が混ざった文字列の場合、正確にバイト数が取得出来なかったのです。

1バイト(半角文字):2バイトの16進数で返却される
2バイト(全角文字):6バイトの16進数で返却される

結局、下記のように1文字ずつ調べて、というベタベタな感じに。

$str_length = 0;
for($i=0;$i<mb_strlen($data);$i++) {
  if(strlen(bin2hex(mb_substr($data, $i, 1))) == 6) {
    $str_length = $str_length + 2;
  } else {
    $str_length = $str_length + 1;
  }
}

もっとうまいやり方はあるんだろうけど、時間も無かったし。。

いずれ修正しよう。

CodeIgniter 2.0.2 + Oracle 10.2.0.3 の接続について

あまり日本語のエントリが無かったので、ちょっと書いてみる。
PHP+Oracleの環境については、手前味噌ですがこちらの記事を参照。
CodeIgniterの環境設定については、ユーザガイドを参照。

動作検証を実施したサーバ環境は、以下。
・CentOS 4.8
・Oracle 10.2.0.3
・Oracle Instant Client 11.0.2
・PHP 5.3.2
・CodeIgniter 2.0.2

設定したコンフィグの内容は以下。
application/config/database.php


$db[‘default’][‘hostname’] = ‘//DB_SERVER_IP:PORT/SID‘;
$db[‘default’][‘username’] = ‘USER_ID‘;
$db[‘default’][‘password’] = ‘PASSWORD‘;
$db[‘default’][‘database’] = ‘DATABASE_NAME‘;
$db[‘default’][‘dbdriver’] = ‘oci8’; ← コレ。「OCI8」のドライバを指定する
$db[‘default’][‘dbprefix’] = ”;
$db[‘default’][‘pconnect’] = TRUE;
$db[‘default’][‘db_debug’] = TRUE;
$db[‘default’][‘cache_on’] = FALSE;
$db[‘default’][‘cachedir’] = ”;
$db[‘default’][‘char_set’] = ‘utf8’;
$db[‘default’][‘dbcollat’] = ‘utf8_general_ci’;
$db[‘default’][‘swap_pre’] = ”;
$db[‘default’][‘autoinit’] = TRUE;
$db[‘default’][‘stricton’] = FALSE;


こんな感じで。

これであとはModel作ってSQL発行すればOK。
ActiveRecordでも問題無し。
簡単でした。

ちなみに、Oracleでシーケンスを取得するのにはこんな感じで。

function get_seq() {
  $this->db->SELECT(‘SEQUENCE_NAME.nextval as nextval’,FALSE)->FROM(‘dual’);
  $query = $this->db->get();
  return $query->result();
}

SELECT に 「FALSE」付けてあげないと、うまく取得出来ないです。
※勝手に「”」「’」とか付けちゃうので

では。

さくらインターネットの共用サーバでEC-CUBEのモバイル版を動かす

現在運用中のEC-CUBEのサイトがある。

さくらインターネットの共用サーバで動作している。

で、今まではPCサイトのみで動作していたのだが、モバイル版もカスタマイズして使えるようにして欲しいと。

専用サーバの場合、ゴリゴリとサーバ自体の設定をいじれるから問題無いのだが、さくらの共用サーバはそうもいかない。

インストールされた状態のままでもうまく動かない。

色々やって、うまく動くようになったので、備忘録。

1) SC_DbConn.phpの修正(data/class/SC_DbConn.php)

DB接続部分でなにやらエラーが出てうまく動かなかったので、コンストラクタのDB接続部分をこんな感じで修正。

// 既に接続されていないか、新規接続要望の場合は接続する。
if(!isset($objDbConn->connection) || $new) {
if($dsn != "") {
$objDbConn = DB::connect($dsn, $options);
$this->dsn = $dsn;
// ここから下3行を追加
$buf = $objDbConn->prepare('SET NAMES utf8');
$objDbConn->execute($buf);
mysql_set_charset("utf8");
} else {
if(defined('DEFAULT_DSN')) {
$objDbConn = DB::connect(DEFAULT_DSN, $options);
$this->dsn = DEFAULT_DSN;
} else {
return;
}
}
}

2) php.iniをばらまく

さくらサーバの場合、html/mobile配下に設置されている.htaccessが効かないので、php.iniにして、その配下のディレクトリ全てにばらまく。

$ cd html/mobile
$ mv .htaccess .htaccess.bk
$ vi php.ini
mbstring.language=Japanese
output_handler=null
mbstring.encoding_translation=Off
magic_quotes_gpc=Off
mbstring.internal_encoding=UTF-8
variables_order=EGPS
session.auto_start=Off
session.use_trans_sid=On
$ cp ./php.ini ./cart/
$ cp ./php.ini ./contact/
$ cp ./php.ini ./entry/
$ cp ./php.ini ./forgot/
$ cp ./php.ini ./frontparts/bloc/
$ cp ./php.ini ./guide/
$ cp ./php.ini ./mypage/
$ cp ./php.ini ./products/
$ cp ./php.ini ./regist/
$ cp ./php.ini ./shopping/
$ cp ./php.ini ./unsupported/
$ cp ./php.ini ./user_data/

とりあえず、こんな感じでうまく動くようになりました。

でわ。

PHP(PDO)+Oracle=too large for buffer and was truncated

ハマったので。

PHP 5.1.6

Oracle 10.2.3

にて。

PDO_OCIでPHPとOracleとを繋いでる環境でエラーじゃないけど、Warningが出た。

Warning: PDOStatement::fetch(): column X data was too large for buffer and was truncated to fit it in test.php on line XXX

VARCHAR2のカラムからデータを取得すると出た。

正常にデータが取得出来てるっぽかったけど、おしりの何バイトかが切れてた。

おぉ、trancateされてる。

色々調べてみたところ、全角文字が入ってるとダメだった。

さらに調べてみると、原因が分かった。

Oracle:SJIS

PHP:UTF-8

これが原因だった。

OracleはSJISなので、全角文字は2バイト。

PHPはUTF-8なので、全角文字は3バイト。

PDO_OCIの場合、テーブルのカラムの型と長さを参照してバッファを決めるようで。

全角文字が入っていた場合、そのバッファが溢れる事があるのです。

なんせ、2バイトだと思っていた全角文字が3バイトだったので。

VARCHAR2(20)のカラムに、全角文字が10文字入っていた場合、SJISならば20バイトなので、OK。

しかし、UTF-8だと30バイトになってしまうので、受け取る側のバッファが溢れてしまう、という事。

対応どうしようか・・・

と考え、

/etc/sysconfig/httpd

をちょっと編集してみた。

# cd /etc/sysconfig/

# vi httpd

export NLS_LANG=Japanese_Japan.UTF8

↓に変更

export NLS_LANG=Japanese_Japan.JA16SJIS

# /etc/rc.d/init.d/httpd restart

Warnningは出なくなったけど、文字化けした。

DBから取得してる根っこの部分でSJIS→UTF-8の変換をかけようかと考えたのですが、symfony+doctorineという事もあり、断念。

だって、調べるの面倒だから・・・

テーブルのカラム長の定義を1.5倍すれば回避出来るけど、運用案件では無理なので断念。

結果、PDO_OCIのソースをちょっと直して対応する事に。

# cd /usr/local/src

# cd PDO_OCI-1.0

# vi oci_statement.c

510行目付近に有る記述

col->maxlen = data_size;

col->maxlen = data_size*1.5;

# ./configure

# make

# make install

PDOがOracleのテーブルのカラムの長さを取得してる部分で、その長さを1.5倍してあげれば大丈夫。

この対応方法が良いかどうかは疑問が残るが、とりあえずはこれで回避しよう。

でわ。