php几个安全函数

htmlspecialchars() 函数
htmlspecialchars() 函数把一些预定义的字符转换为 HTML 实体。查看源代码的时候可以看到转义编码
预定义的字符是：
& （和号） 成为 &
" （双引号） 成为 "
' （单引号） 成为 '
< （小于） 成为 &lt;
> （大于） 成为 &gt;
htmlspecialchars(string,quotestyle,character-set)
string 必需。规定要转换的字符串。 
quotestyle 可选。规定如何编码单引号和双引号。
   ?ENT_COMPAT - 默认。仅编码双引号。
   ?ENT_QUOTES - 编码双引号和单引号。
   ?ENT_NOQUOTES - 不编码任何引号。
character-set 可选。字符串值，规定要使用的字符集。
   ISO-8859-1 - 默认。西欧。
   ISO-8859-15 - 西欧（增加 Euro 符号以及法语、芬兰语字母）。
   UTF-8 - ASCII 兼容多字节 8 比特 Unicode
   cp866 - DOS 专用 Cyrillic 字符集
   cp1251 - Windows 专用 Cyrillic 字符集
   cp1252 - Windows 专用西欧字符集
   KOI8-R - 俄语
   GB2312 - 简体中文，国家标准字符集
   BIG5 - 繁体中文
   BIG5-HKSCS - Big5 香港扩展
   Shift_JIS - 日语
   EUC-JP - 日语 
addslashes() 函数
addslashes() 函数在指定的预定义字符前添加反斜杠。
这些预定义字符是：
单引号 (')
双引号 (")
反斜杠 (\)
NULL
默认情况下，PHP 指令 magic_quotes_gpc 为 on，对所有的 GET、POST 和 COOKIE 数据自动运行 addslashes()。不   

要对已经被 magic_quotes_gpc 转义过的字符串使用 addslashes()，因为这样会导致双层转义。遇到这种情况时可以   

使用函数get_magic_quotes_gpc() 进行检测。
三个魔术引号
magic_quotes_gpc 影响到 HTTP 请求数据（GET，POST 和 COOKIE）。不能在运行时改变。在 PHP 中默认值为 on。 
magic_quotes_runtime 如果打开的话，大部份从外部来源取得数据并返回的函数，包括从数据库和文本文件，所返回   

   的数据都会被反斜线转义。该选项可在运行的时改变，在 PHP 中的默认值为 off。 
magic_quotes_sybase 如果打开的话，将会使用单引号对单引号进行转义而非反斜线。此选项会完全覆盖     

   magic_quotes_gpc。如果同时打开两个选项的话，单引号将会被转义成 ''。而双引号、反斜线 和 NULL 字符  

   将不会进行转义。 
对初学者很有用 魔术引号在 PHP 中用来实现避免初学者的代码更危险。尽管 SQL 注入在魔术引号打开的情况下仍然有可能实现，但起码

系统的风险减少很多了。 
方便使用 当向数据库中插入数据时，魔术引号所做的就是自动对所有的 GET、POST、COOKIE 数据运用 addslashes() 函数。 
为什么不用魔术引号
可移植性 编程时认为其打开或并闭都会影响到移植性。可以用 get_magic_quotes_gpc() 来检查是否打开，并据此编程。 
性能 由于并不是每一段被转义的数据都要插入数据库的，如果所有进入 PHP 的数据都被转义的话，那么会对程序的执行效率产生一定的

影响。在运行时调用转义函数（如 addslashes()）更有效率。 尽管 php.ini-dist 默认打开了这个选项，但是 php.ini-recommended 默

认却关闭了它，主要是出于性能的考虑。 
不便 由于不是所有数据都需要转义，在不需要转义的地方看到转义的数据就很烦。比如说通过表单发送邮件，结果看到一大堆的 \'。针

对这个问题，可以使用 stripslashes() 函数处理。stripslashes() 函数删除由 addslashes() 函数添加的反斜杠。
如果不能修改服务器端的配置文件，使用 .htaccess 也可以。范例如下： 
php_flag magic_quotes_gpc Off
网上说addslashes有一个漏洞，mysql_escape_string和mysql_real_escape_string同样也如此， 
字符集设为GBK时，0xbf27本身不是一个有效的GBK字符，但经过 addslashes() 转换后变为0xbf5c27，前面的0xbf5c是个有效的GBK字符，

所以0xbf5c27会被当作一个字符0xbf5c和一个单引号来处理，结果漏洞就触发了。 
我的问题是，如果我的页面部分和数据库用GBK意外的字符集，比如说UTF8，是不是这个漏洞就对我构不成威胁？
addslashes的问题在于黑客可以用0xbf27来代替单引号，而addslashes只是将0xbf27修改为0xbf5c27，成为一个有效的多字节字符，其中

的0xbf5c仍 会被看作是单引号，所以addslashes无法成功拦截。
当然addslashes也不是毫无用处，它是用于单字节字符串的处理，多字节字 符还是用mysql_real_escape_string吧。
mysql_real_escape_string 必须在(PHP 4 >= 4.3.0, PHP 5)的情况下才能使用。否则只能用 mysql_escape_string ，两者的区别是：
mysql_real_escape_string 考虑到连接的当前字符集，而mysql_escape_string 不考虑。
mysql_real_escape_string() 函数转义 SQL 语句中使用的字符串中的特殊字符。
下列字符受影响：
\x00
\n
\r
\
'
"
\x1a
如果成功，则该函数返回被转义的字符串。如果失败，则返回 false。
语法
mysql_real_escape_string(string,connection)
string 必需。规定要转义的字符串。 
connection 可选。规定 MySQL 连接。如果未规定，则使用上一个连接。

感言：

看来安全上还是有很多漏洞的啊！在拼接sql语句的时候特别要消息，尤其是将那些传过来的值直接拼接到sql语句是很危险的事， 数据库注入，核心就是数据库语句拼接上做文章，管住这一点就能让所有注入毫无办法，可是做到这点还真不容易，虽然addslashes()函数有一定功能，但是那只能防止一部分，或者说低级的注入，将那些关键字符用unicode编码，可以将一些关键字符用对应的unicode编码代替，这样就能逃过addslashes()函数的检查了。上网站上线后，关闭display_errors是明智的选择。htmlspecialchars(),则是另一个需要注意的问题，尤其在类似留言板，提交后能显示提交字符的地方，这个函数还是很管用的