数据库安全

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

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

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

add a note

User Contributed Notes 4 notes

down

-20

Chris Travers ¶

9 years ago


Regarding where to put logic, it's really best not to be dogmatic about this.  Putting logic in the db can have some security advantages but it has other security gotchas (for example, SQL injection inside a stored procedure may be possible in some environments).  Similarly it can have some portability advantages and disadvantages.

The real question is that you want to ask what you want to be portable.  If you put it in the db, it becomes easier to integrate programs written in different development environments with a minimum of security gotchas.  If you put it in the application, then you have to create the interfaces on that level in middleware.  Both approaches are doable.  On the other hand if you are writing software you want to be deployable in MS SQL shops and Oracle shops, then you have to write portable SQL (avoiding gotchas) and put the logic in the application.

When we started rewriting the LedgerSMB codebase, we decided to move logic into the db because this would make it easier to retrofit security onto a very insecure codebase (by not trusting the application), and because we wanted to support languages other than Perl.  A few years later this is bearing fruit and indeed I am reading the manual because I am writing integration libraries in PHP.  I am not much of a PHP guy (I haven't programmed PHP since PHP 4.x) but I can write modules that let folks write code to interface securely with LedgerSMB's database logic.  You can think of the stored procedures as being named queries which are shared between applications, or as API's to the database.  But again, this approach is not universally applicable.

If portability between db's is not a major requirement, then I think the best approach is to do as much as possible in SQL queries and put those in the database.  A couple hundred lines of SQL can replace a couple thousand lines in Perl or PHP, and is fundamentally easier to debug.  Of course that won't work for everyone.

down

-22

x12code at yahoo dot com ¶

14 years ago


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.

down

-41

Anonymous ¶

16 years ago


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

down

-57

Dave Martin ¶

14 years ago


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.

add a note

官方地址：https://www.php.net/manual/en/security.database.php

有任何技术问题请点击这里网站运营推广招聘

IT PHP 编程语言 Linux 开发编程科技 Elasticsearch HTML/CSS/XML 网络 JAVA 数据库面试 NoSQL C/C++ Golang Git 算法操作系统正则表达式 Redis 互联网 MySql JavaScript 运维软件国际架构设计 Mac OS TCP/IP Excel Vim Windows Socket Oracle VR MongoDB Python 运营 MemCache 商业硬件电子娱乐设计 nginx 摄影游戏 WordPress HTTP 团建数码电器

php7 安装fileinfo扩展 preg_split — 通过一个正则表达式分隔字符串 php位值,解决 PHP 中 usort 在值相同时改变原始位置的问题 [PHP] inet_pton/inet_ntop IP地址转换函数 [鸟哥]PHP_INT_MIN 和 -9223372036854775808 PHP 8.1 adodb手册 ADORecordSet对象 Composer的Packagist资源 opcache预加载 array_multisort() 多字段排序 PHPMailer设置utf8 PHPMailer字符集CharSet mysql面试题纯php实现DES以及TripleDES加密算法 PHP json解析（json_decode）页面工具支持php7的性能采集扩展 [原创]诡异的php-fpm超时问题 laravel框架查看sql语句方式 php中几种注释规范 adodb连接mysql多个数据库的问题

略微加速

PHP官方手册 - 互联网笔记

数据库安全

目录

User Contributed Notes 4 notes