php防sql注入方法
1.post数据
封装转义函数 防sql注入 eag：addslashes($username);addslashes($password);
eag:防止sql注入函数封装
function deepslashes($data){
#判断$data的表现形式 并且需要处理空的情况
if(empty($data)){
return($data);
}
#高级简写 return is_array($data) ? array_map('deepslashes',$data) : addslashes($data);
#初级写法
if(is_array($data)){
#递归循环遍历处理多维数组
foreach ($data as $v) {
return deepslashes($v);
}
}else{
#单一变量
return addslashes($data);
}
#初级写法
}
2.get数据
指url 传参数导致sql发生改变
解决方案
①强制转换，使用函数intval 或者 数据类型 的关键字int
②隐式转换，通过运算，只需要+0即可
3.xss跨站脚本攻击
指恶意攻击向web页面插入html、js标签导致页面出现错误
解决方案
转义标签'<' '>'即可，有以下php函数可解决
htmlspecialchars 函数 和 htmlentites函数
eag:
function deepslashes($data){
#判断$data的表现形式 并且需要处理空的情况
if(empty($data)){
return($data);
}
return is_array($data) ? array_map('deepslashes',$data) : htmlspecialchars ($data);
}
② ThinkPHP如何防止SQL注入
（1）查询条件尽量使用数组方式，这是更为安全的方式；
（2）如果不得已必须使用字符串查询条件，使用预处理机制；
（3）使用绑定参数；
（4）强制进行字段类型验证，可以对数值数据类型做强制转换；
（5）使用自动验证和自动完成机制进行针对应用的自定义过滤；
（6）使用字段类型检查、自动验证和自动完成机制等避免恶意数据的输入；
（7）做一些过滤。
③ 如何实现php的安全最大化怎样避免sql注入漏洞和xss跨站脚本攻击漏洞
使用php安全模式
服务器要做好管理，账号权限是否合理。
假定所有用户的输入都是“恶意”的，防止XSS攻击，譬如：对用户的输入输出做好必要的过滤
防止CSRF，表单设置隐藏域，post一个随机字符串到后台，可以有效防止跨站请求伪造。
防御SQL注入。
避免SQL注入漏洞
1.使用预编译语句
2.使用安全的存储过程
3.检查输入数据的数据类型
4.从数据库自身的角度考虑，应该使用最小权限原则，不可使用root或dbowner的身份连接数据库。若多个应用使用同一个数据库，也应该为数据库分配不同的账户。web应用使用的数据库账户，不应该有创建自定义函数，操作本地文件的权限。
避免XSS跨站脚本攻击
1.假定所有用户输入都是“邪恶”的
2.考虑周全的正则表达式
3.为cookie设置HttpOnly,防止cookie劫持
4.外部js不一定可靠
5.出去不必要的HTML注释
6. 针对非法的HTML代码包括单双引号等，使用htmlspecialchars()函数。
④ php如何防止sql注入
PHP防止sql注入是一个比较低级的问题了，这个问题其实在我大一上学期做第一个个人博客的时候就已经关注过了，不过乎槐简单的说一下关于PHP防注入的方式吧。
对于现在的防注入技术其实已经成熟亏备了，对于一个站点该关心的不是防注入了，而是大规模高并发如何处理的问题，或者关于各种其他漏洞，比如现在世界上仍然有百分之80使用redis的站点存在redis漏洞，通过redis漏洞可以直接拿到机器的访问权限，一般来说都是直接给你种一个挖矿机器人来。
⑤ 在PHP中全面阻止SQL注入式攻击
一、 注入式攻击的类型
可能存在许多不同类型的攻击动机，但是乍看上去，似乎存在更多的类型。这是非常真实的-如果恶意用户发现了一个能够执行多个查询的办法的话。
如果你的脚本正在执锋迹旁行一个SELECT指令，那么，攻击者可以强迫显示一个表格中的每一行记录-通过把一个例如"1=1"这样的条件注入到WHERE子句中，如下所示(其中，注入部分以粗体显示)：
SELECT * FROM wines WHERE variety = 'lagrein' OR 1=1;'
正如我们在前面所讨论的，这本身可能是很有用的信息，因为它揭示了该表格的一般结构(这是一条普通的记录所不能实现的)，以及潜在地显示包含机密信息的记录。
一条更新指令潜在地具有更直接的威胁。通过把其它属性放到SET子句中，一名攻击者可以修改当前被更新的记录中的任何字段，例如下面的例子（其中，注入部分以粗体显示）：
UPDATE wines SET type='red'，'vintage'=' WHERE variety = 'lagrein'
通过把一个例如1=1这样的恒真条件添加到一条更新指令的WHERE子句中，这种修改范围可以扩展到每一条记录，例如下面的例子（其中，注入部分以粗体显示）：
UPDATE wines SET type='red'，'vintage'= WHERE variety = 'lagrein' OR 1=1;'
最危险的指令可能是DELETE-这是不难想象的。其注入技术与我们已经看到的相同-通过修改WHERE子句来扩展受影响的记录的范围，例如下面的例子（其中，注入部分以粗体显示）：
DELETE FROM wines WHERE variety = 'lagrein' OR 1=1;'
二、 多个查询注入
多个查询注入将会加剧一个攻击者可能引起的潜在的损坏-通过允许多条破坏性指令包括在一个查询中。在使用MySQL数据库时，攻击者通过把一个出乎意料之外的终止符插入到查询中即可很容易实现这一点-此时一个注入的引号(单引号或双引号)标记期望变量的结尾；然后使用一个分号终止该指令。现在，一个另外的攻击指令可能被添加到现在终止的原始指令的结尾。最终的破坏性查询可能看起来如下所示：
SELECT * FROM wines WHERE variety = 'lagrein'GRANT ALL ON *.* TO 'BadGuy@%' IDENTIFIED BY 'gotcha''
这个注入将创建一个新的用户BadGuy并赋予其网络特权（在所有的表格上具有所有的特权）；其中，还有一个"不祥"的口令被加入到这个简单的 SELECT语句中。如果你遵循我们在以前文章中的建议－严格限制该过程用户的特权，那么，这应该无法工作，因为Web服务器守护程序不再拥有你撤回的 GRANT特权。但是从理论上讲，这样的一个攻击可能给予BadGuy自由权力来实现他对你的数据库的任何操作。
至于这样的一个多查询是否会被MySQL服务器处理，结论并不唯一。这其中的一些原因可能是由于不同版本的MySQL所致，但是大多数情况却是由于多查询存在的方式所致。 MySQL的监视程序完全允许这样的一个查询。常用的MySQL GUI-phpMyAdmin，在最终查询之前会复制出以前所有的内容，并且仅仅这样做。
但是，大多数的在一个注入上下文中的多查询都是由PHP的mysql扩展负责管理的。幸好，默认情况下，它是不允许在一个查询中执行多个指令的；试图执行两个指令(例如上面所示的注入)将会简单地导致失败-不设置任何错误，并且没有生成任何输出信息。在这种情况下，尽管PHP也只是"规规矩矩"地实现其缺省行为，但是确实能够保护你免于大多数简单的注入式攻击。
PHP5中的银橡新的mysqli扩展(参考)，就象mysql一样，内在地也不支持多个查询，不过却提供了一个mysqli_multi_query()函数以支持你实现多查询-如果你确州模实想这样做的话。
然而，对于SQLite-与PHP5绑定到一起的可嵌入的SQL数据库引擎(参考和http: )情况更为可怕，由于其易于使用而吸引了大量用户的关注。在有些情况下，SQLite缺省地允许这样的多指令查询，因为该数据库可以优化批查询，特别是非常有效的批INSERT语句处理。然而，如果查询的结果为你的脚本所使用的话（例如在使用一个SELECT语句检索记录的情况下），sqlite_query()函数却不会允许执行多个查询。
三、 INVISION Power BOARD SQL注入脆弱性
Invision Power Board是一个着名的论坛系统。2005年五月6号，在登录代码中发现了一处SQL注入脆弱性。其发现者为GulfTech Security Research的James Bercegay。
这个登录查询如下所示：
$DB-query("SELECT * FROM ibf_members WHERE id=$mid AND password='$pid'");
其中，成员ID变量$mid和口令ID变量$pid被使用下面两行代码从my_cookie()函数中检索出：
$mid = intval($std-my_getcookie('member_id'));$pid = $std-my_getcookie('pass_hash');
在此，my_cookie()函数使用下列语句从cookie中检索要求的变量：
return urldecode($_COOKIE[$ibforums-vars['cookie_id'].$name]);
【注意】从该cookie返回的值根本没有被处理。尽管$mid在使用于查询之前被强制转换成一个整数，但是$pid却保持不变。因此，它很容易遭受我们前面所讨论的注入类型的攻击。
因此，通过以如下方式修改my_cookie()函数，这种脆弱性就会暴露出来：
if ( ! in_array( $name，array('topicsread'， 'forum_read'，'collapseprefs') ) )
{
return $this-
clean_value(urldecode($_COOKIE[$ibforums-vars['cookie_id'].$name]));
}
else
{
return urldecode($_COOKIE[$ibforums-vars['cookie_id'].$name]);
}
经过这样的改正之后，其中的关键变量在"通过"全局clean_value()函数后被返回，而其它变量却未进行检查。
现在，既然我们大致了解了什么是SQL注入，它的注入原理以及这种注入的脆弱程度，那么接下来，让我们探讨如何有效地预防它。幸好，PHP为我们提供了丰富的资源，因此我们有充分的信心预言，一个经仔细地彻底地使用我们所推荐的技术构建的应用程序将会从你的脚本中根本上消除任何可能性的SQL注入-通过在它可能造成任何损坏之前"清理"你的用户的数据来实现。