数据库的防sql注入是作为一个网站开发程序员的常识,作为php程序员,想要解决这个问题,有很多种方法,今天就来谈一谈:
首先:不要使用mysql_escape_string了,它已被弃用,请使用mysql_real_escape_string或者addslashes代替它。
那么mysql_real_escape_string和addslashes的区别呢?
第一:
与addslashes对比,mysql_real_escape_string同时还对\\r、\ 和\x1a进行转义。看来,这些字符必须正确地告诉MySQL,否则会得到错误的查询结果。这是不使用addslashes进行转义的原因之一。
第二:
addslashes不知道任何有关MySQL连接的字符集。如果你给所使用的MySQL连接传递一个包含字节编码之外的其他编码的字符串,它会很愉快地把所有值为字符‘、“、\和\x00的字节进行转义。如果你正在使用不同于8位和UTF-8的其它字符,这些字节的值不一定全部都是表示字符‘、“、\和\x00。可能造成的结果是,MySQL接收这些字符后出现错误。
如果要修正这个bug,可尝试使用iconv函数,将变量转为UTF-16,然后再使用addslashes进行转义。
这是不使用addslashes进行转义的另一个原因。
下面是具体的示例:
addslashes V.S. mysql_real_escape_string
在GBK里,0xbf27不是一个合法的多字符字符,但0xbf5c却是。在单字节环境里,0xbf27被视为0xbf后面跟着0×27(‘),同时0xbf5c被视为0xbf后面跟着0x5c(\\)。
一个用反斜杠转义的单引号,是无法有效阻止针对MySQL的SQL注入攻击的。如果你使用addslashes,那么,我(攻击者,下同)是很幸运的。我只要注入一些类似0xbf27,然后addslashes将它修改为0xbf5c27,一个合法的多字节字符后面接着一个单引号。换句话说,我可以无视你的转义,成功地注入一个单引号。这是因为0xbf5c被当作单字节字符,而非双字节。
想要避免这种漏洞,使用mysql_real_escape_string、准备语句(Prepared Statements,即“参数化查询”)或者任意一款主流的数据库抽象类库(推荐使用PDO)。
- WAMP环境搭建之APACHE配置 2015-03-25
- Maximum execution time of 30 seconds exceeded故障解决 2015-03-20
- HTML实体的妙用 2015-03-03
- PHP代码中的一句话木马 2015-03-03
- PCRE(正则表达式)匹配中文最权威汇总 2015-02-11