ファイルシステムのセキュリティ
SQL injection could be prevented by inserting only base64_encoded data into the data base. Before searching the data base for a certain value or string base64_encode the search string and then start the query.
データベースのセキュリティ
目次
今日、ダイナミックなコンテンツを提供するウェブアプリケーションに おいてはデータベースは欠く事のできなコンポーネントとなっています。 そういったデータベースには重要な、そして秘密にすべき情報が格納 されることになるので、それらをいかにして保護するかについて十分に 考慮する必要があります。
情報を取り出したり格納するためにはデータベースに接続する必要があります。 そして適切なクエリを送信し、結果を受け取り、切断します。クエリに 使用される言語はStructured Query Language (SQL)が一般的です。アタッカー がどのようにSQLに 干渉するかについて参照してください。
皆さんがお気づきの様に、PHPそれ自体は貴方のデータベースを保護することは ありません。以下のセクションはPHPスクリプトからどのようにデータベースに アクセスし操作すればいいのか、とういことに関する非常に基本的な導入です。
このシンプルなルールを覚えて置いてください：それは「多重防衛」です。 より多くの箇所で、より多くの保護を行うことにより、アタッカーが攻撃に 成功して機密情報が漏洩する可能性は減っていきます。データベースと アプリケーションを正しくデザインすることで貴方の心配を取り除くことが できます。
データベースのデザイン
他人が用意した既存のものを使用するのでない限り、最初に行うのはデータベースの作成です。 データベースが作成されると、そのデータベースのオーナーは作成コマンドを 実行したユーザになります。通常、オーナー(とスーパーユーザー)のみが そのデータベースに対して操作を行うことが出来ます。他のユーザがデータベースを 使用するには適切な権利が与えられている必要があります。
アプリケーションはデータベースにオーナー、もしくはスーパーユーザーとして 接続しては絶対にいけません。なぜならこれらのユーザは 例えばスキーマの変更(テーブルの削除等)や全コンテンツの削除、といった あらゆるクエリーを実行することが出来るからです。
貴方が作成するアプリケーションがデータベースに対して行う操作の各方面ごとに、 操作対象となるオブジェクトに対して、出来る限り少ない権限を持った複数の ユーザを作成した方が良いでしょう。ユーザに対しては、最低限必要な権限のみを 与え、関係の無いデータへのアクセスを許可しないようにします。これは、 万が一侵入者がそのユーザの権限を以ってデータベースにアクセスした際に、 アプリケーションと関係の無いデータにまでアクセスされることを防ぐためです。
全てのビジネスロジックをウェブアプリケーション(つまり貴方のスクリプト) で実装することは推奨されません。代わりに、ビュー、トリガー、ルールといった データベースの機能を活用した方が良いでしょう。システムが更新され、 新しい機能がデータベースへのアクセスすることになった場合、個々のデータベース クライアントごとに再度同様のロジックを実装しなければならなくなります。 さらに、トリガーは透過的に、そして自動的にフィールドを扱うことが出来るので、 デバッグ時や、トランザクションのロールバック時に役立ちます。
add a note
User Contributed Notesデータベースのセキュリティ
ja4chem at yahoo dot co dot uk
17-Jan-2008 04:37
17-Jan-2008 04:37
Dave Martin
16-Aug-2007 09:15
16-Aug-2007 09:15
The posting below is at the very best extremely POV.
There is no more reason to assume you would want to change database vendor than there is to assume you might want to port your php code to Java for example. In either case, its going to be a matter of luck where your business rules sit.
Even if your business rules sit in your application, SQL is NOT portable. Oracle outer joins and pivot queries for example, can look completely different to those in other vendors software (particularly from 8i or lower). This fact alone means that changing your DB vendor requires work on your business rules either in the database or in the application.
Having your rules in the database and keeping the sql in application simple, will at least keep the work in the database if you need to change DB vendor. If you have the rules in the PHP, you'll have to change both.
x12code at yahoo dot com
14-Aug-2007 06:48
14-Aug-2007 06:48
About offloading business logic to views and queries facilitated by the database engine, I seek to avoid this as much as possible, and only do so when such would drastically improve efficiency and user response time.
For instance, where I am there is database staff and application staff. Trying to do analysis on existent applications can easily become a snipe hunt.
The database should be kept discreet as much as possible from the application, such that any database or database provider can easily be substituted with a minimum of cognitive effort on the part of the one setting up a new database. If functionality has been offloaded to the database, additional testing is required to make sure triggers and views were done correctly, again, and that they work right.
Also, keeping all business logic with the application allows all functionality and documentation to be readable in one place, which is invaluable when doing subsequent analysis on an existing application. The worst thing is to have functionality scattered here and there.
Keeping everything with the application means one group of people is responsible, as in my case, application staff. Fewer requests go back and forth. Remember, anytime someone else is brought into the picture, such as asking a DBA to create a view or trigger for you, that DBA must take responsibility over his or her work, with whatever requirements, causing more bureaucracy and administrative complexity.
me at meme dot com
28-Jun-2007 09:23
28-Jun-2007 09:23
<?php
$getal1 = 5.5;
$getal2 = 2.0;
function printDeling() {
$resultaat = global $getal1 / global $getal2;
return $resultaat;
}
function printVermenigvuldiging() {
$resultaat = global $getal1 * global $getal2;
return $resultaat;
}
function printSom() {
$resultaat = global $getal1 + global $getal2;
return $resultaat;
}
function printAftrekking() {
$resultaat = global $getal1 - global $getal2;
return $resultaat;
}
(printDeling()>=7) ? print "<font color=\"green\"> printDeling()</font>" : print "<font color=\"red\"> printDeling()</font>" ;
?>
somebody at whocares dot com
10-May-2006 06:03
10-May-2006 06:03
Encrypting user input doesn't do much to guard against SQL injection attacks. Naturally, you want to encrypt sensitive information across the wire, but if a user puts in malicious data into an input field, any encryption scheme will just dutifully unpack it at the other and and still run the SQL injection hack if you haven't guarded against it.
Encryption is not magic pixie dust to sprinkle on things to make them more secure.
30-Jun-2005 12:57
you can also chamge CHMOD for some file containing "user names" or "passwords"
webmaster at rackhouse dot net
12-Mar-2005 11:08
12-Mar-2005 11:08
On a database design point of view, you should make sure that you design databases in a manor that any query run from them need minimal input from the user and if it requires user input, that you encrypt where possible.
jjahn at SPAMSUCKS dot signicast dot com
20-Jun-2003 07:17
20-Jun-2003 07:17
I would say one of the best ways to guard against SQL injection is to use the excellent PEAR DB package. If you prepare() and execute() your queries, PEAR will automagically addslashes and handle the query depending on your RDBMS. And of course, for repeatable queries prepare and execute will give you a bit of a readability and speed increase.