プログラマ 福重 伸太朗 ～基本へ帰ろう～

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

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

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

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

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

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

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

とりあえず、実践。

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

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

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

○XSSとは

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

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

○フォームの基本

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

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

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

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

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

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

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

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

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

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

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

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

復習&理解を深めます。

こちらを参考に記述。

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

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

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

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

復習&理解を深めます。

コチラを参考にした。

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

たとえば、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

前回に引き続き、SQLインジェクション。メモ。

こんな、方法もある。

こちらを参考にした。

脆弱性の有無の確認。
---------------------------------------------------------
脆弱性の有無

(1) SJISを使ったクライアントでPHPのaddslashesを使った場合(あるいはmagic_quote_gpcがonの場合)に脆弱性がある。ほかの言語でも同様のことを行っていれば脆弱性がある。

　なお，8.1.4 et. al. Security Release FAQによれば，PEAR DBを使っている場合にも脆弱性の可能性があるようである。

(2) フロントエンドとバックエンドのエンコーディングが異なっている場合に脆弱性がある。

(3) prepared statementを使用していれば脆弱性の可能性はない。ただし，prepared statementのようなインタフェースでありながら，実際には内部でSQL文を合成するなど，本物のプロトコルレベルのprepared statementを使っていないケースもありそうなので注意が必要である。

逆に言えば，(1)と(2)に該当しない，あるいは(3)に該当すれば脆弱性はないことになる。
---------------------------------------------------------

検証していこう。
(1) ・・・文字コードはutf-8を使用しているし、magic_quotes_gpc はoffでかつ、pg_escape_stringを利用しているのでＯＫ．
(2) ・・・ソースもDBもutf-8を使用しているのでＯＫ．
(3) ・・・利用していないが、(1)と(2)がOKなので、ＯＫ．

結論から言うと、PHP,Postgresql で開発している場合は

------------------------------------------------
(1) PostgreSQL 8.1.4，8.0.8，7.4.13，7.3.15のいずれかにアップデートする。

(2) シングルクォートをバックスラッシュでエスケープしている場合は，シングルクォートを重ねるエスケープ方法に変更する。PHPで言えば， magic_quote_gpcをoffにし，かつaddslashes()ではなくpg_escape_string()を使うようにする。

(3) (2)が難しい場合には十分注意しながらbackslash_quoteを設定する
------------------------------------------------

検証する。

(1) ・・・ 今回利用しているバージョンは、7.3.15なのでＯＫ．
(2) ・・・ magic_quote_gpcをoffにし，かつaddslashes()ではなくpg_escape_string()　を利用している。
(3) ・・・ (2)が可能なのでOK.

むむ。これは、一度やってみよう。

http://www.atmarkit.co.jp/fsecurity/special/82senderid/sender101.html

ちょい古いネタだが...。しっかり対策しないと！！

http://www.atmarkit.co.jp/fsecurity/column/ueno/33.html
http://www.itmedia.co.jp/enterprise/articles/0504/23/news005.html

■CSRFとは

　CSRFという手法は、本来受け付ける必要がない（拒否すべき）外部のWebページからのHTTPリクエスト（POSTやGET）によって、Webサイトの何らかの機能が実行されるというものである。攻撃として利用されるCSRFの特徴としては、ログイン認証を必要とするWebサイトが攻撃対象となっていることである。

パスワード大事ですから。

○強力なパスワードを作成する方法 by microsoft
http://www.microsoft.com/japan/athome/security/privacy/password.mspx

１．長くします。
　　理想は 14 文字以上です。
２．文字、数字、記号を組み合わせます。
　　パスワードに含める文字の種類を増やせば、それだけそのパスワードを推測することが困難になります。
　　※パスワードに含める文字の種類が少ない場合は、パスワードを長くする必要があります。
　　※キーボードから入力できるあらゆる文字を使用
３．自分では覚えやすく他人が推測するのは難しい単語やフレーズを使用します。
　　パスワードやパス フレーズを覚えるには、書き留めるのが一番簡単な方法です。
　　通常、紙片に書き留められたパスワードの方が、Web サイトやパスワード管理ソフトウェアなどのソフトウェア ベースの保管ツールを使用した場合に比べ、インターネット上で危険にさらされる可能性が低くなります。

○6 つの手順に従って強力で覚えやすいパスワードを作成する
１．覚えられる文章を考えます。 これが強力なパスワードやパス フレーズの基となります。 "My son Aiden is three years old" のように、記憶可能な文章を使用します。
２．コンピュータやオンライン システムでパス フレーズが直接サポートされているかどうかを確認します。 コンピュータやオンライン システムでパス フレーズ (文字間にスペース文字を使用可) を使用できる場合は、パス フレーズを使用します。
３．コンピュータやオンライン システムでパス フレーズがサポートされていない場合は、考えた文章をパスワードに変換します。 考え出した文章の各単語の最初の文字を取って、新しい意味のない単語を作成します。 上の例を使うと、"msaityo" というパスワードを作成できます。
４．複雑さを追加します。そのためには、大文字、小文字、数字を組み合わせます。
５．最後に、特殊文字で置き換えます。
６．新しいパスワードをパスワード チェッカーでテストします。

○パスワードチェッカー
http://www.microsoft.com/japan/athome/security/privacy/password_checker.mspx

＞コンピュータと人間を区別する完全に自動化された公開チューリングテスト)は チャレンジ/レスポンス型テストの一種で、ユーザが人間であるかどうかを決定する計算処理に使われる。

1. Captchaシステムは、ランダムな文字や数字の列を画面に表示する。表示される文字は歪んでいたり一部が覆い隠されていたりして、機械が自動的に読み取ることは難しい。
2. ユーザーは画面に描かれている文字の列を読み取り、同じ文字列をシステムに入力する。
3. システムが表示した文字列とユーザーが打ち込んだ文字列が一致していれば、ユーザーは歪んだ画像を認識する能力を持っていると考えられる。システムはそのユーザーが人間であると推測する。

うーん。Formの連続Postの禁止にリファラ無効だし...IPで制限しても、違うIPでこられたらダメだし...
画像認証で、どのくらいspam防げるだろう...。

http://ja.wikipedia.org/wiki/Captcha

携帯SSLについて

１．概要
――――――――――――――――――――――――――――――――――――
概要を知りたい。
とりあえず、何も分からんので、
「携帯 ssl」でググる。

○携帯電話とSSLルート証明書
http://triaez.kaisei.org/~kaoru/ssl/cell.html
↑ここにまとまってるっぽい。

結論。3キャリアで利用したいなら。
VeriSign Class 3 Primary CA
VeriSign Class 3 Primary CA G2
VeriSign/RSA Secure Server CA
↑がいいらしい。ようするに、VeriSignが良いらしい。

↓各キャリアの資料
○DoCoMo
http://www.nttdocomo.co.jp/service/imode/make/content/ssl/spec/#taiou
○au(古くて使い物にならないかも・・・？)
http://www.au.kddi.com/ezfactory/tec/spec/ssl.html
○SoftBank
http://developers.softbankmobile.co.jp/dp/tech_svc/web/ssl.php

２．VeriSignのSSLを詳しく知る
――――――――――――――――――――――――――――――――――――
ここからは、SSLについての勉強。
VeriSignが良いらしいのは、分かったけど、
「VeriSign Class 3 Primary CA」
「VeriSign Class 3 Primary CA G2」
「VeriSign/RSA Secure Server CA」
上記は、「ルート証明書」というものらしいが、
いまいち良くわかってない。

ルート証明書とは
http://e-words.jp/w/E383ABE383BCE38388E8A8BCE6988EE69BB8.html
＞デジタル証明書を発行する認証局が、その正当性を証明するために自ら署名して発行するデジタル証明書。SSLなどで暗号通信を利用する必要のあるOSやWebブラウザには、大手認証局のルート証明書があらかじめ組み込まれており、受信した証明書が正当なものかどうかを確認するための信頼の基点となる。
＞ルート証明書はユーザが必要に応じて自分でインストールすることもできるが、通常は実績ある大手の認証機関のルート証明書がWebブラウザなどに組み込まれており、ユーザが意識することは少ない。
＞ルート証明書を発行した認証局をルート認証局(ルートCA)と呼ぶことがある。

なるほどね・・・。分かるけど、いまいちピンとこない。

SSLの基礎を復習しよう・・・。

「SSLとは」でぐぐる。

http://www.geotrust.co.jp/ssl/?id=ad_ssltoha&adp_mid=708590&adp_lid=7&gclid=CJ_m1Lmo_osCFQGZYAodbTqDxA
↑を発見！！

【SSLの基礎知識】
1.SSL暗号通信とは
SSLを利用することで、ネットワーク上で通信し合うクライアントPCとサーバの間で暗号化したデータをやり取りできるようになり、データの「盗聴」や「なりすまし」、「改ざん」、「否認」などさまざまなセキュリティ障害を防止できるようになります。

2.電子証明書とは
SSL暗号環境を構築する上で、必要不可欠であるサーバ証明書。
電子証明書は誰でも作成できますが、電子証明書の信頼性は認証局の信頼性に依存します。そのため、特に本人確認が重要となる用途では、信頼のある認証局に電子証明書を発行してもらうことによって、データの出所を確実にすることができます。

3.公開鍵暗号基盤（PKI）とは
対になる2つの鍵を使ってデータの暗号化・復号化を行なう暗号方式のことを指します。
片方は他人に広く公開するため公開鍵と呼ばれ、もう片方は本人（サーバ）だけが所持するように厳重に管理されるため秘密鍵と呼ばれます。秘密鍵で暗号化されたデータは対応する公開鍵でしか復号できず、公開鍵で暗号化されたデータは対応する秘密鍵でしか復号できません。
※公開鍵対
対でなくては機能しないため、万一片方が流出しても復号される危険はありません。一つの鍵で暗号化・復号化を行なう共通鍵暗号方式に比べ、鍵の管理がしやすく安全性が高いメリットがあります。

4.SSL通信の流れ





↑この図が分かりやすい！

なるほどなるほど！！！！

証明書がインストールされていないと、警告が出るんだ！

でも、警告が出るだけで、SSL通信は出来るんだよね・・・。
公開鍵と秘密鍵があれば・・・。

やはり、そのサイトがちゃんとした機関に、証明されているかどうかが基準になるんだな・・・。

でも、VeriSignは証明書を取得するのに、審査がないみたいなので、
どうやって信頼したらいいのか、ちょっと怪しいよね・・・が、現実なのでしょうがない。
ドメインしっかり見ないとダメってことだなー。

はてなはただ - RailsとSSL

memoです。SSLやらないといけないので...。

ヽ( ・∀・)ノくまくまー(2007-06-05)
Rails で行こう！ - Ruby on Rails を学ぶ - SSL 上で WEBrick を動かす
capsctrldays(2006-05-10)