PHP フレームワークをステップバイステップで作成する (13)

前回は、コントローラーがデータをビューに転送する方法について説明しました。今日は主に、プログラム内のコードをより「安全」にする方法について説明します。その後、モデルについて説明します。続いてビューの作り方です。最後にコントローラーの機能拡張について説明します。

この記事は、私のスキルが限られているため、PHP フレームワークの作成についての基本的な理解を目的として書いているため、専門家はコメントしないでください。今は時間が限られているので、1記事書くのに2～3日かかることもありますが、1記事あたりの執筆時間は1時間以内に抑えて書いているので、多少の誤差はあるかもしれません。コードにはバグがたくさんあります、ごめんなさい！ ！

PHP 愛好家の方は、記事の最後に積極的に返信してください。このようなコミュニケーションは、私の PHP スキルを向上させるだけでなく、書き続ける勇気にもなります。ありがとうございます。 ！

多くの人は、何も注意せずに PHP コードを作成します。多くの警告が発生すると、次のようなエラー報告を直接ブロックします。これは非常に大きな問題だと思います。 >

1

1

2 $a = $_GET['a'];

<テーブル>

2

1

echo $a;

$a = $_GET['a'];

<テーブル> 1

echo $a;

GET メソッドで渡されるパラメータに が含まれている場合、プログラムは非常に正常ですが、渡されない場合は警告がスローされます。 ！

1

2	$a = isset($_GET['a']) ? $_GET['a'] : '';

私のアプローチは、まず error_reporting を E_STRICT に設定して、プログラムからの警告を禁止することです。 ！

1

echo $a;

<🎜> このコードは次のように変更する必要がある場合があります: <🎜><🎜><🎜> <🎜> <🎜> <🎜> <テーブル> <🎜><🎜>1<🎜><🎜> <🎜><🎜><🎜> <🎜> <🎜> <テーブル> <🎜><🎜>2<🎜><🎜> <🎜><🎜>$a = isset($_GET['a']) ? $_GET['a'] : '';<🎜><🎜> <🎜> <🎜> <🎜> <🎜> <🎜> <🎜> <テーブル> <🎜><🎜>1<🎜><🎜> <🎜><🎜>echo $a;<🎜><🎜>

この問題に加えて、PHP に特有の @ 記号もあり、多くの人がエラーをブロックするためにこれを使用することを好みますが、プロジェクトが大規模な場合、これを使用すると良いことよりも害が大きいと思います。 、エラーが発生します。このエラーはブロックされているため、このエラーの場所を見つけるのは非常に困難です。 ！

例外処理に関しては、try catch はかなりのオーバーヘッドを伴いますが、プログラムの堅牢性のためには必要な try catch は必要だと個人的には考えています。

さて、ここまで言うと安全とは関係ないように思えますが、私にとってはそれらも「安全」の一環です。

ここで、10 日間かけて簡単なブログ システムを作成し、Wanwang から仮想ホストまたは VPS を購入し、ドメイン名を申請し、Web サイトを登録し、コードをデプロイしたとします。その後、ユーザーは www.test.com などのドメイン名を介してブログ システムにアクセスできるようになります。ブログ システムは非常に人気があり、短期間で多くの人気を集めました。しかし、ある日突然、Web サイトが何かに気付いたことがあります。急に調子が悪くなった、どうする？

オンラインで PHP 構成ファイルの error_reporting をオンにして、オンラインでデバッグしますか?

正直に言うと、私も以前にオンラインでブログ システムをデバッグしたことがあります。上記の状況と異なるのは、ブログの管理が面倒なため、ブログへのアクセス数が非常に少ないことです。

Web サイトへのアクセス数が多い場合、オンラインでデバッグすることは不可能です。では、どうすればよいでしょうか。

ログを記録します。Web サイトが失敗する前にログを書き込んでいる場合は、プログラムが失敗した後、ログ ファイルを開くだけで、失敗の場所を確認して修復できます。このままでOK！ ！

さて、私はあなたのクラスメートであり、私もあなたのブログシステムの開発に参加したと仮定します。しかし、私は少し前にあなたと少し衝突しました。私はあなたのブログを破壊したいと思っています。システムが落ちる、どうやって破壊するのか？

まず、データベースの名前が Test であるとします。このデータベースにはユーザー テーブルがあり、ブログ登録システムのコードは次のとおりです。

<テーブル>

01

01

02	$username = $_POST['username'];

03	$password = $_POST['password'];

<テーブル>

04	if(empty($username) empty($password)) {

<🎜>02<🎜><🎜> <🎜><🎜>$username = $_POST['username'];<🎜><🎜> <🎜> <🎜> <テーブル> <🎜><🎜>03<🎜><🎜> <🎜><🎜>$password = $_POST['パスワード'];<🎜><🎜> <🎜> <🎜> <テーブル> <🎜><🎜>04<🎜><🎜> <🎜><🎜>if(empty($username) empty($password)) {<🎜><🎜>

05	//跳转到注册界面并提示用户名或密码未填写

06

exit();

07

}

08

//连接数据库

09	//假设DB类封装了很多SQL操作，析构的时候自动关闭数据库连接，具体过程不写了

10	//$db是一个数据库DB类的实例，存在两个方法

11	//$db->isUsernameExists判定是否用户名是否存在

12	//$db->query 执行一条SQL语句

13	if(!$db->isUsernameExists($username)) {

14	$db->query("insert into user (username,password) values ('" . $username . "','" . $password. "')");

15	//设置session并跳转

16

exit();

17

} else {

18	//跳转到注册界面并提示用户名已存在

19

exit();

20

}

このコードには何か問題がありますか? 多くの PHP プログラマーは「SQL インジェクションが言いたいだけではないのですか?」と軽蔑するでしょう。

確かに、これは SQL インジェクションの問題です。この問題はすでに非常に古くから知られているようですが、なぜ私がまだそれについて話すのでしょうか。

これは、以前に学校の後輩が書いた PHP プロジェクトをいくつか見たことがありますが、彼らは基本的にこの問題を考慮していませんでした。もちろん、オンライン SQL に従っている場合です。注入方法を試してみると、PHP がこの問題を自動的に解決してくれたように見えます。実際、それを解決するには、特殊文字の前にバックスラッシュを追加します。

まず、SQL インジェクションが失敗した理由について話しましょう。 php.ini で自動エスケープが設定されている場合、PHP はデータを DB に挿入する前にデータをエスケープします。

この問題について考える必要はないようですが、実際には PHP がこれを実行してくれるため、プログラムを別の Linux サーバーに転送すると、その上で PHP が実行されることになります。サーバー .ini 設定ファイルが自動的にエスケープされないように設定されている場合、プログラムに突然大きな問題が発生することになります。コードのセキュリティをサーバー設定に依存すべきではありません。では、どうやってこれを実現するのでしょうか？

幸いなことに、PHP には特殊文字をエスケープする addlashes 関数がすでにありますが、残念なことに、PHP マニュアルを見ると、次のことがわかりました。

デフォルトでは、PHP 命令 magic_quotes_gpc がオンになっており、主にすべての GET、POST、COOKIE データに対してaddlashes() が自動的に実行されます。二重エスケープになるため、magic_quotes_gpc によってエスケープされた文字列に対して addslashes() を使用しないでください。この状況が発生した場合は、関数 get_magic_quotes_gpc() を使用して

を検出できます。

では、どうすればよいでしょうか? 幸いなことに、PHP には、magic_quotes_gpc がオンになっているかどうかを判断する get_magic_quotes_gpc 関数が用意されているので、次のような addlashes 関数をカスタマイズできます。

1

1

2 function myAddslashes($str) { <🎜> <🎜> <🎜> <テーブル> <🎜><🎜>2<🎜><🎜> <🎜><🎜>関数 myAddslashes($str) {<🎜><🎜>

3	if(get_magic_quotes_gpc()){

4	return addslashes($str);

5

}

6

}

実は、この問題を解決する別の方法があります:

1. PDO を使用して DB にアクセスします。PDO で PDOStatement->bindParam を使用すると、PDO がこれらすべてを自動的に実行します。個人的には、PDO は非常に有望だと思います。 ！

2. get_magic_quotes_gpc がオンの場合、最初にstripslashesを呼び出してエスケープ文字を削除し、データベースに挿入する前にmysql_real_escape_stringを使用します。個人的には、この方法の方が最初の方法よりも信頼性が高いと思います。 ！

もちろん、ここまで言うと SQL インジェクションが何なのか知らない子もいるかもしれませんが、SQL インジェクションのプロセスについて簡単に説明します。SQL インジェクションに慣れている人はそのまま通過できます。このセクション。

上記の例によれば、ユーザーがパスワードフィールドに入力した値が a');drop table user;... であると仮定すると、SQL を実行するときの SQL ステートメントは次のようになります:

ユーザー (ユーザー名,パスワード) 値に挿入 ('ユーザー名','a');ドロップ テーブル ユーザー;...')

この SQL は、まずユーザー テーブルにレコードを挿入し、次にテーブル全体を削除します。 。 。 。 SQL で問題が発生しました。

しかし、SQL にエラーがあるかどうかに関係なく、10,000 人のメンバーがいるブログの場合、ユーザー テーブルが失われるのはかなり大きいと思います。また、データベースに接続するユーザーの権限を変更すると、テーブルを削除できなくなりますが、これは永続的な解決策ではありません。SQL インジェクションの脆弱性を解決する方が確実です。

さて、SQL インジェクションの話は終わったので、XSS (クロスサイト スクリプティングの脆弱性) の問題について話しましょう。

PHP スクリプトがあります:

1

1

2	echo $_GET['a'];

<🎜><🎜><🎜> <🎜> <🎜> <テーブル> <🎜><🎜>2<🎜><🎜> <🎜><🎜>エコー $_GET['a'];<🎜><🎜>

コードに問題があると述べましたが、上記のように警告がスローされる場合がありますが、犯罪者がパラメータを渡すときに使用すると、この問題はさらに深刻になります。

ここで、このスクリプトにアクセスするための URL が http://localhost/test.php?a=a であると仮定します。パラメータ a の値を a に設定します。これを渡すのは問題ありません。ですが、これを変更して URL が

になったとします。

http://localhost/test.php?a=<script>location.href="http://www.tmall.com"</script>、スクリプトが実行されるとジャンプ天猫のホームページへ、なんて怖いのでしょう！ ！

これが Tmall にジャンプせず、ハッカーが設定した URL にジャンプした場合、ハッカーはあなたの Cookie 情報を取得し、Cookie を偽造してあなたの ID ブログ システムにログインできる可能性があります。 。 。 。あなたが知っている。

この問題を解決する方法も非常に簡単で、文字列をエスケープするだけです。実際、このメソッドを呼び出した後はスクリプトを実行できません。スクリプトを実行するにはどうすればよいでしょうか? 使用方法の詳細については、マニュアルを参照してください。

この問題を解決した後、別の問題について説明します。これは CSRF (クロスサイト リクエスト フォージェリの脆弱性) です。 ！ ！

ここで、メッセージの内容がリッチ テキストであると仮定します。絵文字の HTML コードは です。ユーザーが入力したと仮定します。この式は、提供されたリッチ テキスト エディターを通じて作成されており、問題はありません。しかし、これを使用せずに、img タグを使用して別のことを実行した場合はどうなるでしょうか。

どうやって行うのですか?とても簡単で、img タグの src 属性を変更するだけです:

メッセージを送信した後、画像が表示できないことがわかりました。しかし、これはまったく合法的な画像リンクではありません。ユーザーがこのメッセージ ページを開くたびに、実際に www.tmall.com にアクセスすることになります。この URL がハッカーの URL に変更されると、結果がわかります。 。 。

実はこの他にもファイルのアップロードなどの抜け穴がありますが、時間の関係でここでは触れません。

私がこれについて話しているのは、セキュリティの問題が実際には非常に重要であり、実際にはプログラミング時に考慮しなければならないことがたくさんあることを説明するためです。

本来なら今日はフレームワークでこれらの問題をどう解決するかについて話すつもりでしたが、予想通り1時間以上かかってしまったので次回にお話します。