« 2006年10月 | メイン | 2006年12月 »

2006年11月 アーカイブ

2006年11月02日

firefox 日本語化 ( Linux )

Linuxで利用しているFirefoxが英語版だったので、日本語化。

http://www.a.phys.nagoya-u.ac.jp/~taka/linux/co4note.html
↑のページを参考にやったらできた。


****************
FireFoxの日本語化など
FireFoxのデザインを変えるには、 https://update.mozilla.org/ からテーマを選んでインストールする。

バージョンアップしたときなど、メニューなどが英語になってしまうことがある。これを日本語化するには、
http://ftp.mozilla-japan.org/pub/mozilla-japan/firefox/development/
にアクセスして、インストールされているFireFoxのバージョンのディレクトリに行き,最新の日本語パック
firefox-*.ja.langpack-*.xpiをクリックする。最初は、このサイトのソフトウェアがインストールできないというメッセージバーがでるので、そこにある[Edit Options...]によって許可した後、もう一度上のファイルをクリックする。
次に、ロケーションバーに about:config と入力し、フィルタに locale と入力。
general.useragent.locale を右クリックして、"Modify"を選び,設定を ja-JP とした後 FireFox を再起動。
****************

2006年11月14日

Poderosa

Poderosaを使ってみた。

・タブで分割できる
・コマンドポップアップ機能
・・・etc

そんなに、同時接続することはないけど、タブで分割とか、コマンドの結果をポップアップできるとかで、色々と便利そうなので、使おうと思います。
今まではputtyを使っていたけど、ちょっとお休み。

Linux に Ruby 、 Rails 、 Mysql をインストールしてアプリを動かす

※実行日は、2006年11月14日20:00前後

※以前インストールされていたrubyをアンインストール
# yum remove ruby
※ruby 1.8.5 をインストール
# cd /tmp
# wget ftp://ftp.ruby-lang.org/pub/ruby/ruby-1.8.5.tar.gz
# cd /usr/src/
# tar xzf /tmp/ruby-1.8.5.tar.gz
# cd ruby-1.8.5/
# ./configure
# make
# make test
test succeeded
# sudo make install
※rubyにパスを通す
# PATH=$PATH:/usr/src/ruby-1.8.5
# export PATH
※rubygems 0.9.0 インストール
# cd /tmp
# wget http://rubyforge.org/frs/download.php/11289/rubygems-0.9.0.tgz
# cd /usr/src/
# tar xzf /tmp/rubygems-0.9.0.tgz
# cd rubygems-0.9.0/
# sudo ruby setup.rb
# sudo gem install rails --include-dependencies
※パッケージインストール
# gem install mysql
# gem install json
※mysql インストール
# yum install mysql
※mysql スタート
# /etc/init.d/mysqld start
※再起動時に自動起動するように設定
# chkconfig --level 3 mysqld on
# chkconfig --level 5 mysqld on
※rails アプリケーション起動テスト
# cd /var
# mkdir rails_project
# cd rails_project
# rails demo
# cd demo
# ruby script/server
※http://localhost:3000/ が見れる事を確認。
※サブバージョンで管理されているファイルを持ってくる。
# cd /var/rails_project/
# svn checkout https://10.20.139.173/svn/tools/diary_report
※データベース作成
# mysql -u root
mysql> create database diary_report_development default character set utf8;
mysql> create database diary_report_test default character set utf8;
mysql> create database diary_report_production default character set utf8;
mysql> \q
※/var/rails_project/diary_report/config/database.yml に 「 socket: /var/lib/mysql/mysql.sock 」 を追記
# mysqladmin variables | grep socket
| socket | /var/lib/mysql/mysql.sock
※データベースのスキーマ作成
# rake migrate
※開発アプリケーションで起動(その前にテストアプリ終了する)
# ruby script/server
※その他、少し修正したが、エラーメッセージを見れば分かるので省略。

2006年11月28日

コマンド・インジェクション恐るべし

今、PHPであるアプリを作っていて、セキュリティを固めている途中。
今回は、コマンド・インジェクションがテーマ。XSSとかSQLインジェクションもあとでやります。

コマンド・インジェクションは一応知っていたけど、復習&実践&メモ。


こちらを参考にした

コマンド・インジェクションは簡単に言うと、
「外部から任意の OS コマンドを実行すること」
である。

上記の参考ページに書いてあるスクリプトを test.cgi に書き、
CGIの実行できるフォルダへアップする。
そして、http://~~/test.cgi?filename=|ls%20-la%20/
な感じでアクセスすると・・・。

↑こうなる!

Linux のコマンドで、ls -la と打っているとの同じだ。
あ~、恐ろしや。。


ところで、開発中のPHPのアプリに上記の脆弱性があるのかと言うと、
「ない」
である。

他にどんな原因が考えられるかと言うと、コチラを参考に調べた結果。

(1) 直接指定(シェルスクリプト)
(2) open()関数の使用(Perl) ←さっきやったやつ。
(3) 引数をシェルに渡す関数の使用(ほとんどの言語)

それで、今回のアプリで脆弱性がないか調べる。

(1) 直接指定(シェルスクリプト)
シェルスクリプトで書いていないので、ありえない。

(2) open()関数の使用(Perl) ←上記でやったやつ。
Perlで書いていないので、ありえない。

(3) 引数をシェルに渡す関数の使用(ほとんどの言語)
PHPにもシェルコマンドを実行できるメソッド(system)はあるが、利用していないので、ありえない。
けど、とりあえずやってみた。


うーむ。しっかり実行される。恐ろしや。


上記のことから、コマンドインジェクションはない!
と言えると思う。

他に、Webアプリでコマンド・インジェクションの可能性があったら教えてください(^^;

PHP バッファオーバーフロー

今、PHPであるアプリを作っていて、セキュリティを固めている途中。
今回は、バッファオーバーフローがテーマ。XSSとかSQLインジェクションもあとでやります。
復習&理解を深めます。

今回のアプリを設置するサーバーには、PHP4.4.1 がインストールされている。

こちらによると、「 wordwrap() 」という関数に脆弱性がある模様。バージョンは、5.1.2 と 4.4.2。なのでこの記事からは問題は感じられない。
また、wordwrap() は使っていないので問題ない。

ついでに、すべてのフォーム入力欄に対して文字制限を設けているので、大きなデータは入ってこないようにしている。

XSS対策

今、PHPであるアプリを作っていて、セキュリティを固めている途中。
今回は、XSSがテーマ。SQLインジェクションもあとでやります。

XSSは一応知っていたけど、復習&実践&メモ。

こちら
こちら
こちらを参考にした。

とりあえず、実践。

<script>alert("XSS");</script>

↑をフォームに入力、実行してみる。

うむ。見事に実行可能。何されるか分からん。


○XSSとは


--------------------------------
XSSが問題になるのは、「ブラウザに出力する」処理の部分でプログラムミスがある場合に起こる。
HTTPおよびHTML中において、特別な意味を持つ文字として定義されている文字がいくつかある。有名なところで「<」と「>」は、HTMLの構成を記述するためのタグの開始と終了を表すための区切り文字として使用する、という特別な意味を持っている。
--------------------------------

と言うことで、さっそく対策。


まず、基本から復習しよう。


○フォームの基本


入力値を受取る → それを処理 → 出力する
          ↑        ↑
        [入力チェック] [サジタイニング]

この流れを忘れてはいけない。

・[入力チェック]
これは、「OSコマンドインジェクション」「SQLインジェクション」「バッファオーバーフロー」といったXSS以外のセキュリティホールの対策となる場合がほとんどなので、とっても重要。

 * 入力値として許可する値かどうかチェック
 * 入力文字数のチェック

基本中の基本なので、まずはしっかり行う。

※注意点
 * サーバ側で行う
   javascript とかでチェックしたつもりにならないように!
 * すべてのパラメータに対して行う
   ラジオボタンとか、チェックボックスとかも同じだよ!
 * 毎回行う
   たとえば、 入力→確認→完了 というフォームの流れがあったとする。
   確認ページでhiddenフィールドにフォームの入力を保存したりする場合、
   入力→確認 はチェックしたけど、 確認→完了 はチェックしていないのではなんの意味もない!


○特殊文字のサニタイジング(無害化)


上記の、入力チェックを行っていれば、入力チェックを確実に行っていれば、かなりセキュリティレベルの高いアプリケーションが出来上がっているはず。でも、まだ完璧ではない。

サジタイニング(無害化)する文字列は、実は、アプリごとに違うのである。
たとえば、最終的に「,(カンマ)」で区切られるCSVにデータが保存される場合、「,(カンマ)」がフォームに入力され、そのまま登録されると困るだろう。
このように、サジタイニング(無害化)する文字列は、各自考えることになる。
以下は、代表的なものを示す。

・HTML
 * 本文の場合
   本文で特殊文字となる文字は、「<」「>」「&」の3つである。
 * タグの場合
   まず、属性値は必ず「"(ダブルクオーテーション)」または「'(シングルクオーテーション)」で囲む。これはW3Cが推奨しているのと同時に、サニタイジングが必要な特殊文字を限定することになるので、忘れずに行ってほしい。「"」で囲った場合の特殊文字は「"」だけとなる。同様に「'」で囲った場合は「'」だけとなる。それぞれ、「"」と「'」に変換することでサニタイジング完了となる。

要するに、特殊文字が含まれなければよいということである。

具体的に、PHPで言うとhtmlのソースに、
htmlspecialchars( 変数 )
と行えばよい。
※htmlspecialchars() で 「'」の無害化はオプションである。なので、「"」で囲ったほうが良い。

・HTTP
ここまではHTMLに入力値を出力する話だったが、ちょっと視野を広げてHTTPまで踏み込んでみよう。
こちらには、Set-Cookie ヘッダについて書いてある。HTTPヘッダに入力値を含む場合にもサニタイジングが必要になると言うことです。
Set-Cookie ヘッダの場合は「;」が属性の区切りを表す特殊文字であるなど、ヘッダによってさまざまな特殊文字が存在するので、それらの処理も忘れずに行う必要がある。

以上のようなことに、気を付けてXSS対策を行おう!

Forceful Browsing(強制的ブラウズ)

復習&理解を深めます。

こちらを参考に記述。

Forceful Browsing(強制的ブラウズ)とは、
手法としてはとても単純で、「ブラウザにURLを入力する」というだけだ。

でも、あなどってはいけない。

たとえば、データをためるのにCSVを利用していて、CSVファイルがブラウザで直接アクセスしてあるところにおいてあったらどうだろう。
http://~~~/○○.csv これで丸見えである。

現在では、フレームワークを利用するのがごくごく当たり前になってきているので、ブラウザでアクセスできるところに重要なファイルを置くと言うことは、あまりないと思うが、初歩的かつかなりダメージの大きいものなので、注意したいですね。

Path Traversal(パスの乗り越え)

復習&理解を深めます。

コチラを参考にした。

Path Traversal(パスの乗り越え):
アプリケーションに渡されるパラメータを基にファイルの読み込みをしている場合に、この危険がある。

たとえば、

open FILE, "[変数].html";

というプログラムで動的に、ページを表示していたとする。
この[変数]に /etc/passwd%00 と入力されたら。
/etc/passwdの内容がすべて出力されてしまうことになる。
※詳しくはコチラをみてね。

ただ、これもフレームワークを利用していると、ほととんど、404と返って来ると思う。

実際、いま僕が作っているアプリもそうだった。

ただ、これも、もし実行できたらかなりクリティカルなセキュリティーホールであるので、注意したい。

2006年11月29日

SQL Injection(SQLインジェクション:SQLの挿入)

今回の学習のテーマは、SQL Injection(SQLインジェクション:SQLの挿入)です。
復習&理解を深めます。

こちらを参考に学習。
うーん@ITはすばらしい情報ばかりだ。


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


Webサイトを構成する要素の1つにデータベースがある。Webアプリケーションからデータベースを操作するために使われるのがSQLで、このSQLを偽造してデータベースの操作をしてしまおう、というのがこの攻撃だ。プリケーションの裏にデータベースがあり、データベースと連携してサービスを行っているシステムが攻撃対象となる。データベースに含まれるデータすべてを奪われる、削除されるなどの被害が想定される。

うーん。恐ろしい攻撃です。

ということで、仮にフォームを作って、記事に書いてある現象を確認してみる。
実際にやってみると、やっぱり実感がわく。うーん。怖い攻撃です。とっても簡単だし。


対策の1つは、ごく当たり前の「入力値チェック」と「サニタイジング」だ。
注意すべき文字列は、「 SQL92での特殊文字 」 だ。
具体的に言うと
----------------------------------
空白 ( ) → 文字列やコマンドの区切りに使われる
" ' ,    → 文字列の区切りに使われる
-      → 負の数を表すために使われる
.      → フィールドの指定に使われる
& + / |  → 演算子として使われる
:      → 数の設定に使われる
;      → コマンドの区切りに使われる
< = >   → 演算子として使われる
% ? * _  → 正規表現で使われる
----------------------------------

たくさんあるので、可能な限り英数字だけに入力制限する方が安全だ。

実は、今回データベースライブラリとして利用している「 ADOdb 」には、入力文字列をクオートするメソッドがある。
[ qstr ]
今回は、これを利用しようと思う、実験したらちゃんと、入力文字列をクオートしてSQLインジェクションを防いでくれました!

もう1つの対策として、準備済みSQL文(プレースホルダ、バインドメカニズムと呼ばれることもある)を使う方法がある。

バインドメカニズムについては、コチラの「バインドメカニズムを活用しよう」に分かりやすく載っている。
PHPでバインドメカニズムを実践する場合は、コチラだ。

2006年11月

Sun Mon Tue Wed Thu Fri Sat
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30

Map

About 2006年11月

2006年11月にブログ「プログラマ 福重 伸太朗 ~基本へ帰ろう~」に投稿されたすべてのエントリーです。過去のものから新しいものへ順番に並んでいます。

前のアーカイブは2006年10月です。

次のアーカイブは2006年12月です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。