安全
在线手册：中文 英文
PHP手册

数据库安全

Table of Contents

今时今日，数据库系统已经成为各个动态网站上 web 应用程序的重要组成部分。由于非常敏感和机密的数据有可能保存在数据库中，所以对数据库实施保护就显得尤为重要了。

要从数据库中提取或者存入数据，就必须经过连接数据库、发送一条合法查询、获取结果、关闭连接等步骤。目前，能完成这一系列动作的最常用的查询语言是结构化查询语言 Structured Query Language (SQL)。可以看看攻击者是如何篡改 SQL 查询语句的。

PHP 本身并不能保护数据库的安全。下面的章节只是讲述怎样用 PHP 脚本对数据库进行基本的访问和操作。

记住一条简单的原则：深入防御。保护数据库的措施越多，攻击者就越难获得和使用数据库内的信息。正确地设计和应用数据库可以减少被攻击的担忧。

安全
在线手册：中文 英文
PHP手册
PHP手册 - N: 数据库安全

用户评论:

r at rpl dot name (25-Feb-2011 02:09)

you can keep your database vendor portable by using an encapsulation class such as adoDB for php or other framework like zend, codeigniter/cake/symphony,
it will add more header to the processing power (debatable) but it will far reduce the time to develop the app, and the DB.

ja4chem at yahoo dot co dot uk (17-Jan-2008 03:37)

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.

Dave Martin (16-Aug-2007 08: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 05: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 08: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 05: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 11:57)

you can also chamge CHMOD for some file containing "user names" or "passwords"

webmaster at rackhouse dot net (12-Mar-2005 10: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 06: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.