[高危]SQL注入漏洞（盲注）请问怎么解决？
是礼品添加那里？
我查询连接是在那，但是目录下没有找到这个目录
那我建议你直接暂时将这个文件从服务器上删除，等到要用的时候再放上去，或者bug已经被修复了
这个文件的真实路径在哪呢，找不到哦！
/control-&gift.php/model-&gift.class.php这两个删除应该要安全一些，可以自己先备份这两个文件。
真是太感谢你了，请问你说要删除这个就能解决问题，但是这两个文件是什么文件，能干什么，等我却这个文件是不是有必要删除的时候我在删除。
这两个文件是用于 在财富商城里，添加兑换的奖品的。如果你的运营还没到这个程度，其实是用不着这两个文件的，也不会影响其他功能的使用。为了安全起见，你可以备份这两个文件在自己本地。然后删除服务器上的这两个文件。如果真的出现问题，你可以直接把这两个文件再上传会服务器。应该问题不大
其他回答(1)
相关已解决
Can not connect to MySQL
Can not connect to MySQL【安全常识】挖漏洞你必须知道的那些事儿！SQL注入漏洞、XSS跨站脚本漏洞……
高危漏洞包括SQL注入漏洞、XSS跨站脚本漏洞、页面存在源代码泄露、网站存在备份文件、网站存在包含SVN信息的文件、网站存在Resin任意文件读取漏洞。
SQL注入漏洞：网站程序忽略了对输入字符串中包含的SQL语句的检查，使得包含的SQL语句被数据库误认为是合法的SQL指令而运行，导致数据库中各种敏感数据被盗取、更改或删除。
XSS跨站脚本漏洞：网站程序忽略了对输入字符串中特殊字符与字符串（如&&'"&&&iframe&）的检查，使得攻击者可以欺骗用户访问包含恶意Java代码的页面，使得恶意代码在用户浏览器中执行，从而导致目标用户权限被盗取或数据被篡改。
页面存在源代码泄露：页面存在源代码泄露,可能导致网站服务的关键逻辑、配置的账号密码泄露，攻击者利用该信息可以更容易得到网站权限，导致网站被黑。
网站存在备份文件：网站存在备份文件，例如数据库备份文件、网站源码备份文件等，攻击者利用该信息可以更容易得到网站权限，导致网站被黑。
网站存在包含SVN信息的文件：网站存在包含SVN信息的文件，这是网站源码的版本控制器私有文件，里面包含SVN服务的地址、提交的私有文件名、SVN用户名等信息，该信息有助于攻击者更全面了解网站的架构，为攻击者入侵网站提供帮助。
网站存在Resin任意文件读取漏洞：安装某些版本Resin服务器的网站存在可读取任意文件的漏洞，攻击者利用该漏洞可以读取网站服务器的任意文件内容，导致网站被黑。
中危漏洞包括网站存在目录浏览漏洞、网站存在PHPINFO文件、网站存在服务器环境探针文件、网站存在日志信息文件、网站存在JSP示例文件。
网站存在目录浏览漏洞：网站存在配置缺陷，存在目录可浏览漏洞，这会导致网站很多隐私文件与目录泄露，比如数据库备份文件、配置文件等，攻击者利用该信息可以更容易得到网站权限，导致网站被黑。
网站存在PHPINFO文件：网站存在PHPINFO文件，这个是PHP特有的信息文件，会导致网站的大量架构信息泄露，该信息有助于攻击者更全面了解网站的架构，为攻击者入侵网站提供帮助。
网站存在服务器环境探针文件：网站存在服务器环境探针文件，该文件会导致网站的大量架构信息泄露，该信息有助于攻击者更全面了解网站的架构，为攻击者入侵网站提供帮助。
网站存在日志信息文件：网站存在日志信息文件，该文件包含的错误信息会导致网站的一些架构信息泄露，该信息有助于攻击者更全面了解网站的架构，为攻击者入侵网站提供帮助。
网站存在JSP示例文件：网站存在JSP示例文件，该文件的弱口令会导致网站的大量架构信息泄露，该信息有助于攻击者更全面了解网站的架构，为攻击者入侵网站提供帮助。
低危漏洞包括页面上存在网站程序的调试信息、网站存在后台登录地址、网站存在服务端统计信息文件、网站存在敏感目录。
页面上存在网站程序的调试信息：页面上存在数据库信息，例如数据库名、数据库管理员名，该信息有助于攻击者更全面了解网站的架构，为攻击者入侵网站提供帮助。
网站存在后台登录地址：网站存在后台登录地址，攻击者经常使用这个地址进行网站的后台登陆，比如弱密码、表单绕过、暴力破解等，从而得到网站的权限。
网站存在服务端统计信息文件：网站存在服务端统计信息文件，该文件会导致网站的一些架构信息泄露，该信息有助于攻击者更全面了解网站的架构，为攻击者入侵网站提供帮助。
网站存在敏感目录：网站存在敏感目录，例如 /upload /database /bak，该信息有助于攻击者更全面了解网站的架构，为攻击者入侵网站提供帮助。
漏洞的危害有哪些
SQL注入漏洞的危害不仅体现在数据库层面，还有可能危及承载数据库的操作系统；如果SQL注入被用来挂马，还可能用来传播恶意软件等，这些危害包括但不限于：
数据库信息泄漏：数据库中存储的用户隐私信息泄露。
网页篡改：通过操作数据库对特定网页进行篡改。
网站被挂马，传播恶意软件：修改数据库一些字段的值，嵌入网马链接，进行挂马攻击。
数据库被恶意操作：数据库服务器被攻击，数据库的系统管理员帐户被窜改。
服务器被远程控制，被安装后门：经由数据库服务器提供的操作系统支持，让黑客得以修改或控制操作系统。
破坏硬盘数据，瘫痪全系统。
XSS跨站脚本漏洞的危害包括但不限于：
钓鱼欺骗：最典型的就是利用目标网站的反射型跨站脚本漏洞将目标网站重定向到钓鱼网站，或者注入钓鱼Java以监控目标网站的表单输入，甚至发起基于DHTML更高级的钓鱼攻击方式。
网站挂马：跨站后利用IFrame嵌入隐藏的恶意网站或者将被攻击者定向到恶意网站上，或者弹出恶意网站窗口等方式都可以进行挂马攻击。
身份盗用：Cookie是用户对于特定网站的身份验证标志，XSS可以盗取用户的Cookie，从而利用该Cookie获取用户对该网站的操作权限。如果一个网站管理员用户Cookie被窃取，将会对网站引发巨大的危害。
盗取网站用户信息：当能够窃取到用户Cookie从而获取到用户身份时，攻击者可以获取到用户对网站的操作权限，从而查看用户隐私信息。
垃圾信息发送：比如在SNS社区中，利用XSS漏洞借用被攻击者的身份发送大量的垃圾信息给特定的目标群体。
劫持用户Web行为：一些高级的XSS攻击甚至可以劫持用户的Web行为，监视用户的浏览历史，发送与接收的数据等等。
XSS蠕虫：XSS 蠕虫可以用来打广告、刷流量、挂马、恶作剧、破坏网上数据、实施DDoS攻击等。
信息泄露漏洞的危害
CGI漏洞大多分为以下几种类型：信息泄露、命令执行和溢出，因此危害的严重程度不一。信息泄露会暴露服务器的敏感信息，使攻击者能够通过泄露的信息进行进一步入侵；命令执行会对服务器的安全造成直接的影响，如执行任意系统命令；溢出往往能够让攻击者直接控制目标服务器，危害重大。
内容泄露漏洞：会被攻击者利用导致其它类型的攻击，危害包括但不局限于：
内网ip泄露：可能会使攻击者渗透进入内网产生更大危害。
数据库信息泄露：让攻击者知道数据库类型，会降低攻击难度。
网站调试信息泄露：可能让攻击者知道网站使用的编程语言，使用的框架等，降低攻击难度。
网站目录结构泄露：攻击者容易发现敏感文件。
绝对路径泄露：某些攻击手段依赖网站的绝对路径，比如用SQL注入写webshell。
电子邮件泄露：邮件泄露可能会被垃圾邮件骚扰，还可能被攻击者利用社会工程学手段获取更多信息，扩大危害。
文件泄露漏洞：可能会导致重要信息的泄露，进而扩大安全威胁，这些危害包括但不局限于：
帐号密码泄漏：可能导致攻击者直接操作网站后台或数据库，进行一些可能有危害的操作。
源码泄露：可能会让攻击者从源码中分析出更多其它的漏洞，如SQL注入，文件上传，代码执行等。
系统用户泄露：可能会方便暴力破解系统密码。
漏洞解决方案
SQL注入漏洞解决方案
1.解决SQL注入漏洞的关键是对所有来自用户输入的数据进行严格检查、对数据库配置使用最小权限原则2.所有的查询语句都使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中。
3.对进入数据库的特殊字符（'"&&&*;等）进行转义处理，或编码转换。
4.确认每种数据的类型，比如数字型的数据就必须是数字，数据库中的存储字段必须对应为int型。
5.数据长度应该严格规定，能在一定程度上防止比较长的SQL注入语句无法正确执行。
6.网站每个数据层的编码统一，建议全部使用UTF-8编码，上下层编码不一致有可能导致一些过滤模型被绕过。
7.严格限制网站用户的数据库的操作权限，给此用户提供仅仅能够满足其工作的权限，从而最大限度的减少注入攻击对数据库的危害。
8.避免网站显示SQL错误信息，比如类型错误、字段不匹配等，防止攻击者利用这些错误信息进行一些判断。
9.在网站发布之前建议使用一些专业的SQL注入检测工具进行检测，及时修补这些SQL注入漏洞。
XSS跨站脚本漏洞解决方案
1.假定所有输入都是可疑的，必须对所有输入中的、iframe等字样进行严格的检查。这里的输入不仅仅是用户可以直接交互的输入接口，也包括HTTP请求中的Cookie中的变量，HTTP请求头部中的变量等。
2.不要仅仅验证数据的类型，还要验证其格式、长度、范围和内容。
3．不要仅仅在客户端做数据的验证与过滤，关键的过滤步骤在服务端进行。
4．对输出的数据也要检查，数据库里的值有可能会在一个大网站的多处都有输出，即使在输入做了编码等操作，在各处的输出点时也要进行安全检查。
5．在网站发布之前建议测试所有已知的威胁。
页面存在源代码泄露解决方案
1. 配置好服务端语言解析，防止解析失败而导致源码泄露；
2. 关闭网站错误调试机制，防止因为报错而导致源码泄露。
网站存在备份文件解决方案：删除检测出的备份文件，或者将这类文件从网站目录下移走。
网站存在包含SVN信息的文件解决方案：删除网站目录下的SVN信息，不要使用SVN目录作为网站的目录。
网站存在Resin任意文件读取漏洞解决方案：删除resin_doc相关目录与文件。
网站存在目录浏览漏洞：关闭Web容器（如IIS/Apache等）的目录浏览功能，比如：
1.IIS中关闭目录浏览功能：在IIS的网站属性中，勾去“目录浏览”选项，重启IIS；2.Apache中关闭目录浏览功能：打开Apache配置文件httpd.conf，查找 “Options Indexes FollowSymLinks”，修改为“ Options -Indexes”(减号表示取消)，保存退出，重启Apache。
网站存在PHPINFO文件解决方案：删除检测出的PHPINFO文件。
网站存在服务器环境探针文件解决方案：删除检测出的探针文件，比如：iprober.php、phpcheck.php、jspcheck.jsp、DotNetInfo.aspx、aspcheck.asp等。
网站存在日志信息文件解决方案：删除检测出的日志信息文件。
网站存在JSP示例文件解决方案：删除JSP示例文件。
页面上存在数据库信息解决方案：关闭数据库的错误调试机制，防止因为SQL语句错误导致数据库报错信息显示到页面上。
页面上存在网站程序的调试信息解决方案：关闭网站程序的调试机制，这个机制经常被用于网站的测试调试，该机制能显示出很详细的网站报错信息。
网站存在后台登录地址解决方案
1.将后台登录地址隐藏，改个不容易猜到的路径；
2.配置好后台登录地址的访问权限，比如只允许某个IP或IP段的用户访问。
网站存在服务端统计信息文件解决方案：删除检测出的服务端统计信息文件。
网站存在敏感目录解决方案：这些目录经常用于存放敏感的文件，可以考虑从网站目录中分离出，或改个不易猜测到的路径，并配置好访问权限。
来源：http://www.moonsec.com/post-728.html
敬请持续关注……
责任编辑：
声明：该文观点仅代表作者本人，搜狐号系信息发布平台，搜狐仅提供信息存储空间服务。
今日搜狐热点& 浏览内容
SK企业网站管理系统SQL注入漏洞
SK企业网站管理系统存在SQL注入,影响非常严重几乎涉及所有该程序
关键字：inurl:/Html/About.sk.asp?ID=，
表段:sk_admin 字段:adminname、password默认后台是/server先判断下有注入么 & ‘ 号判断 或者 and 1=1 和 and 1=2进行判断看操作如果存在注入点即把搜到的注入点放啊D然后登录后台地址即可 (猜解出来的密码是经过MD5解密的需要先去解密)
关注我们，实时联系
通知公告?如果喜欢本站可以直接点击！?点击此加入晓残博客会员群！?本站免费提供加密解密服务！?如果你有意向广告合作点击！
<a href="//www.exehack.net/5208.html" title="WordPress WordPress <= 4.9.6任意文件删除漏洞可重装
博客统计日志总数：546 篇评论数目：2194 条标签总数：43 个页面总数：8 个分类总数：17 个友链总数：24 个建站日期：运行天数：2753 天最后更新：51CTO旗下网站
一个罕见的MSSQL注入漏洞案例
这里作者准备分享一个在去年Google赏金计划中发现的相当罕见漏洞，也是作者在整个渗透测试生涯中唯一一次遇到的。
作者：xiaix来源：FreeBuf| 14:29
这里作者准备分享一个在去年Google赏金计划中发现的相当罕见漏洞，也是作者在整个渗透测试生涯中唯一一次遇到的。
目标网站使用了微软 SQL Server 数据库并且其中一个存在 SQL 盲注。你问我怎么知道的?当然是通过触发真/假条件判断的。
http://bounty/yadayada.asp?id=8888'+AND+'1'+LIKE+'1 --& 页面正常显示
http://bounty/yadayada.asp?id=8888'+AND+'2'+LIKE+'1 --& 页面显示空白
这里没什么特别的地方，就是一个常见的 SQL 注入测试，但随后问题来了：
1. 手工测试表明存在 SQL 盲注漏洞
2. 但扫描器/SQLMap 不起作用
3. 好像使用了存储过程方法(不确定)
我尝试了多种方法提供 POC 但没有一种能够成功，再进一步研究后发现，应用程序只会对用户权限提交的整数值进行响应。
对此我一点办法也没有，直到发现了 v1d0q 提供的一个方法 https://rdot.org/forum/showthread.php?t=826 (ps:俄语，小编表示看不懂啊(ノ=Д=)ノ┻━┻)
当时这对我来说是种全新的方法，但令人惊讶的是这样真的管用!
http://bounty/yadayada.asp?id=8888'+AND+(@@TEXTSIZE&@@LANGID)+AND+'1'+LIKE+'1 --& 页面正常加载
http://bounty/yadayada.asp?id=8888'+AND+(@@LANGID&@@TEXTSIZE)+'1'+LIKE+'1 --& 页面显示空白
进一步阅读后发现，我实际上是在尝试查询 MSSQL 里是否存在 Transact-SQL 其返回类型为 int 或 smallint。通常，返回类型都有自己自身的值。例如：
@@LANGID 默认通常为 0 (英语)
@@TEXTSIZE 可能比 1000 大
继续进行测试，我尝试使用其他 Transact-SQL 语句来确保结果不为假，的确最终大部分的查询语句都返回为真:)
在提交了这个有限的 POC 给网站的所有者后，非常幸运的他们确认了这个漏洞并给予奖励!
下面是在一台测试服务器上进行的实验：
声明：我仍然没有理解这到底是为什么，还需要在后续花一些时间进行研究以找到原因:)【编辑推荐】【责任编辑： TEL：（010）】
大家都在看猜你喜欢
头条热点聚焦关注热点
24H热文一周话题本月最赞
讲师：29407人学习过
讲师：490人学习过
讲师：461人学习过
精选博文论坛热帖下载排行
在网络应用越来越复杂的今天，传统的网络应用已经不能满足企业和用户的需要，这就对网络管理员、信息管理部门提出了更高的要求。本书介绍了...
订阅51CTO邮刊如何从根本上防止 SQL 注入？
我的图书馆
如何从根本上防止 SQL 注入？
【pansz的回答(30票)】:
要想解决这个问题很简单，但都不是在层面的，通过框架或者词法分析的方法本质上是在 SQL 之上再增加了一个适配层，用户的输入先经过了某个适配层的处理然后才进入 SQL 语句。而参数化查询看起来是绕开了 SQL，但不能阻止程序员非要使用 SQL 进行查询。
而这些方法都违背了题主问题的本意。题主的本意不是问如何解决 SQL 注入问题，而是问能否从数据库自身的层面解决 SQL 注入问题，但这个问题在 SQL 内不可能解决。
SQL 注入的本质在于它是一个语言而不是一个特定格式的API。所以你无法单独的给它传输参数什么的，只能整体的执行一条语句。只要用户输入的东西可以直接进入 SQL，一个元素就可以变成一条语句，那么 SQL 注入就无法防止。
更明确一些，这个问题并不是 SQL 语言特有的，而是只要 API 是一个语言，这个问题就必然存在。除非这个数据库的 API 并不以语言的方式提供，而是以某种不灵活不方便（但更安全）的方式。
我认为，要想完全从数据库本身解决这个问题，唯一的方法只能是不用 SQL ，不使用支持 SQL 的数据库，数据库的 API 以某种并非文本语言的方式提供。——纯粹数据库的角度，只要用 SQL 语言发命令的这种方式仍然存在，你就没法挡住手残的程序员，除非完全禁止掉 SQL。
【知乎用户的回答(32票)】:
首先反对目前排名较高的 及 两位对参数化查询的理解
第一，参数化查询是DB本身提供的功能
第二，各种语言的库在实现参数化查询时可以采用以下两种策略，姑且称之为
真·参数化查询：将带参数的语句及参数分别发送给DB，这种情况能100%防注入，因为对于DB来说，参数的值绝对不会作为语义要素来解析，据我所知JDBC是这种实现方式
伪·参数化查询：将拼接以后的plain SQL发给DB，只不过在拼接过程中会进行校验及转义，据我所知PHP的PDO默认是采用这种实现，不过可以通过设置开关切换为真·参数化查询，个人目前无法理解为什么要放着DB本身提供的正确实现而兜个大圈子，而且这样并不能完全避免风险，因为不能保证目前的校验及转义是否还有没考虑到的情况
从两位的回答来看貌似是认为DB没有提供参数化查询机制，语言层面的参数化查询都是通过伪·参数化查询来实现的
第三，回答题主的问题，答案是，不能，DB已经把能做的都做到了，一方面，DB已经提供了两种查询方式分别能正确地适用不同场景，但是DB不可能阻止程序层面错误地使用，首先，plain SQL有存在的必要，但是你无法识别程序送过来的plain SQL到底是写死的还是通过拼接来的
结论，防止的责任仍然是在程序这边，应该正确地使用DB提供的机制
以下为新增，本来是打算回复 的，不过后来觉得修改答案更合适
其实这就是我所想表达的重点，“数据库提供的功能”这种说法可能会引入歧义，在此重新定义一下，所谓的“数据库提供”指的是，数据库服务端（严格来说是具体到SQL分析引擎）接收到的就是“带参数的SQL语句+参数值”二者分离，与之相对的“非数据库提供”指的是，数据库服务端接收到的是一条单独的SQL语句，其中的参数已经被处理成了具体的值，这个过程是由客户端（可能是最终程序，也可能是某些框架，或者数据库驱动）完成的，这二者是有本质区别的，在第一种实现中，SQL语法引擎明确地知道参数的位置是一个整体，不会再对其进行语法及语义处理，而第二种则不然，参数值仍然会被进行语法及语义处理，客户端所做的就是通过验证、转义等方式尽量地避免参数被解析成语义动作，不同于第一种方式，没有从根本上解决用户的输入可能被作为指令这一隐患
从题主的评论来看题主应该是清楚这个机制的，那现在我们来再次回答题主的问题，设想一下为了达到这个目标我所能想到的数据库这边可以做哪些尝试（欢迎补充）
1. 废弃plain SQL ，强制使用参数化查询（并且是上述的真·参数化查询）
这其实没有解决任何问题，首先，使用plain SQL的需求是真实存在的，当然我们假设可以通过空的参数列表来变相进行plain SQL的查询，那这和plain SQL又有何区别，其次，参数化查询仍然是由“带参数的SQL”和参数列表两部分组成的，无法识别和避免程序员在第一部分采用拼接
2. 完全抛弃SQL，提供结构化的接口，例如类似select(tableName, fields, condition)这种机制
这会使得接口异常复杂，且不一定应付得了复杂查询，想想LINQ吧
所以结论仍然是，数据库本身在这个问题上已经做到足够好了，前提是使用者正确地使用其提供的功能
【Ivony的回答(14票)】:
根本上杜绝的方案太多太简单了，SQL注入这种攻击手段说白了和直接把门踹开偷东西一样Low，这么多年一爆再爆我也很震精。不过想想其实都是一群小白拿着几十年前的小白写的东西改改用才会这样的。
有人非说我没回答问题，OK，根本的手段就是参数化查询或者做词法分析。
的答案的确是说到了一个关键，也就是如果支持文本式的指令，那这事儿是没有办法杜绝的，只能在外面套上一个壳，也就是词法分析。
但是现代数据库却不是只提供了SQL文本查询，参数化查询也是标准API之一，当然还有存储过程，这些高级的API都可以有效的杜绝SQL注入这种问题。在MySQL都支持存储过程的今天，还有这么多注入漏洞实在是让人费解。
不使用支持SQL的数据库过于偏颇了，几乎所有的关系型数据库都支持SQL查询，但也提供了安全的查询方式。
【李楠的回答(11票)】:
SQL 注入其实是利用「歧义」的攻击手段：建造程序时候拼写的 SQL 本意，和实际攻击中生成的 SQL 不一样。
PreparedStatement 仅仅是降低概率，并算不上根本上防止。如果 PreparedStatement 里面写出漏洞被利用呢？再比如 rails 的 ActiveRecord 这种 ORM/DAO 方案，还有一些敏感字符过滤方案，都是降低 SQL 注入的概率。
上面有人说废掉 SQL 就如何如何，其实这种东西比如「对象数据库」，「NOSQL」一直有人搞。问题是：你能保证新的 DB 交互方式中，也没有「歧义」？有交互（哪怕不是基于文本）就有「歧义」，功能越强大复杂就越容易利用「歧义」（即使把 ORM/DAO 方案搞的能全面封装 SQL ，那他们出现漏洞的概率也一定增加）。
简而言之，利用「歧义」的攻击手段永远都会存在。废掉 SQL 也没有用 － 他不再叫 SQL 注入了你的数据就安全了？
但是，今天从实际的应用看，清晰的编程规范，结对/自动化代码 review ，加大量现成的解决方案（PreparedStatement，ActiveRecord，歧义字符过滤， 只可访问存储过程 balabala）已经让 SQL 注入的风险变得非常低了。
今天如果被攻击成功，恐怕更多的是意识，而非技术问题。
【余天升的回答(6票)】:
SQL注入并不是一个在SQL内不可解决的问题，这种攻击方式的存在也不能完全归咎于SQL这种语言，因为注入的问题而放弃SQL这种方式也是因噎废食。首先先说一个我在其他回答中也曾提到过的观点：没有（运行时）编译，就没有注入。
SQL注入产生的原因，和栈溢出、XSS等很多其他的攻击方法类似，就是未经检查或者未经充分检查的用户输入数据，意外变成了代码被执行。针对于SQL注入，则是用户提交的数据，被数据库系统编译而产生了开发者预期之外的动作。也就是，SQL注入是用户输入的数据，在拼接SQL语句的过程中，超越了数据本身，成为了SQL语句查询逻辑的一部分，然后这样被拼接出来的SQL语句被数据库执行，产生了开发者预期之外的动作。
所以从根本上防止上述类型攻击的手段，还是避免数据变成代码被执行，时刻分清代码和数据的界限。而具体到SQL注入来说，被执行的恶意代码是通过数据库的SQL解释引擎编译得到的，所以只要避免用户输入的数据被数据库系统编译就可以了。
现在的数据库系统都提供SQL语句的预编译（prepare）和查询参数绑定功能，在SQL语句中放置占位符'?'，然后将带有占位符的SQL语句传给数据库编译，执行的时候才将用户输入的数据作为执行的参数传给用户。这样的操作不仅使得SQL语句在书写的时候不再需要拼接，看起来也更直接，而且用户输入的数据也没有机会被送到数据库的SQL解释器被编译执行，也不会越权变成代码。
至于为什么这种参数化的查询方式没有作为默认的使用方式，我想除了兼容老系统以外，直接使用SQL确实方便并且也有确定的使用场合。
多说一点，从代码的角度来看，拼接SQL语句的做法也是不恰当的。
DELETE FROM planet WHERE name = 'mercury';DELETE FROM planet WHERE name = 'venus';DELETE FROM planet WHERE name = 'earth';DELETE FROM planet WHERE name = 'mars';我修改一下那个很经典的笑话：程序员不应该执行删除地球这样的SQL语句，而是写删除一个行星，然后将地球当作参数传入。
$stmt = $mysqli-&prepare("DELETE FROM planet WHERE name = ?");$stmt-&bind_param('s', "earth");$stmt-&execute();
更多阅读：
【李普君的回答(6票)】:
SQL注入导致的安全问题数不胜数，为什么这么多年来同样的问题一再发生？
为什么呢？为什么呢？
看了下大部分答案都没理解到 SQL 注入的本质，我的解决方案是 “语法糖”，先留个坑，做好饭了再来详解。
再等等吧。
【CosmiaFu的回答(7票)】:
SQL注入根本就不是漏洞而是功能，这就像是操作系统的管理者权限一样
Windows 98 权限系统脆弱
XP有权限系统了，恩，结果有人用管理员账户裸奔
Vista 加了UAC，结果有人F*ck UAC
Windows 8 自带防病毒，结果有人，下了来历不明的软件，被defender隔离然后关掉实时保护，被询问UAC授权毫不犹豫就授权，结果这些人反过来说Windows太脆弱
想要安全去用ipad吧。。。
事实证明，开发者无论多么关心安全性，总会有2B的用户绕开各种限制把事情搞遭然后归咎于开发者。
强制使用参数化查询能解决问题？别逗了，我拼接完了然后传个空参数进去不行？你要是说必须要有参数，那那些本来就不带参数的语句怎么办？
====================================================================
你们以为废掉SQL就行了？真是图样图森破，自称文艺的2B程序员会扔掉driver直接发byte-stream过去，这下无解了，你们感受一下
【知乎用户的回答(0票)】:
防sql注入过滤引号就好了，防HTML注入过滤标签就可以，为啥楼上这么多人唠叨题主不对，就不写一下正确方法呢？
【赵雨函的回答(4票)】:
怎么老有这类问题……PreparedStatement 是用来干啥的……为啥非要自己拼 String…
【周亮的回答(0票)】:
1. 校验，包括客户端校验以及服务端校验，比如id只能为数字，那么输入就必须是数字，不符合输入要求的字符不允许连接到SQL中。
2. 权限，在上一层次上隔离非获得授权的访问。
杜绝SQL注入，功夫本在SQL之外
【Wuvist的回答(3票)】:
这事从根本上说是人的问题，提供再好的api，二逼程序员都有办法把它用烂。sql能注入，不用sql？成，那html注入又怎么说？
根本办法就是把人给换了。
对于任何一个合格的程序员来说，防止sql注入根本就不是一个事。
【季文昊的回答(3票)】:
补充一下 。网上查询了一下，不单单是Java的JDBC，通常关系型数据库产品都会支持Prepared Statement这种特性（详见）。也就是，含有占位符的SQL语句先行一步传递到RDBMS上面进行预编译，然后再传递实际的参数，最后执行SQL。这样从根本上可以杜绝题主说的利用占位符参数这一种SQL注入。
但是根据上面回答，发现其实还有其他形式的可以被称作为SQL注入的攻击方式（如，缓存溢出、终止字符）是Prepared Statement无法解决的。
【冯哲的回答(2票)】:
楼主并不是问如何防止SQL注入的。 而是问这么频繁而简单的问题为什么一再发生？数据库厂商是不是应该做些什么。
首先，这并不是一个复杂的问题。其次，在这一点上数据库厂商能做的已经都做了。
已经说的很清楚了。出问题的是plain sql。plain sql意味着数据库厂商给了程序员100%的权利。如果要从数据库厂商方面100%杜绝。就只能是禁止了plain sql。但这不可能，因为plain sql的需求是确实存在的。就像linux不给你root权限一样。
所以真正的问题在程序员方面。以我的经验，有两种比较典型的情况，
第一种：程序员太菜，太懒，太忙。由于各种大意，或者压根不知道这么一回事而导致的。通常来说，这类情况多输出现在初级程序员身上。但是也有资深的程序员犯这种低级错误。人都有具体的情况。每天的休息状况，情绪，状态都不同。只要是人就难免有出错的时候。
第二种：程序架构复杂，人数多，设计不够好就会出问题。比如数据从前端到数据库经历的代码是3个人写的。每个人都可以处理，但由于沟通，设计不利。每个人都认为别人会处理。就过导致谁都没处理。
我能想到的经常发生的，就是这两种了。希望大家再补充。
由此可见，这个问题实际上不是一个数据库的问题了。而是一个软件开发管理问题了。所以，从这一点上来说。是不可能100%杜绝的。就像你不能要求程序员的代码100%没bug一样。那如何解决的。我能想到的最好的办法就是：
1，给出清晰地架构设计，明确验证数据的地方。
2. 测试，测试，测试！！！
3. 对于项目经理来说，如果发生注入的情况了。要检查发生的原因，根据具体情况，如果真是因为程序员出现了不应给的疏忽，并且经常出现的话。就真的要换人了。
【徐明明的回答(0票)】:
这不是技术上做不到吧，而是开发系统的是个新人，他可能压根就不知道啥是SQL注入以及危害，又没有有经验的同事给review一下。技术上来说比如Java里面，当往SQL里面塞参数的时候，用PreparedStatement而不是手动去拼接不就ok了。
【姚冬的回答(1票)】:
持续集成的时候引入一个静态代码扫描脚本即可。
【朱智超的回答(0票)】:
其实ORM开发也是个好方法。如果sql语句的话， 就来绑定参数。
【吴永志的回答(0票)】:
1. 参数化查询是访问数据库的驱动程序提供的，会保证参数本身只作为值，而不是作为SQL被数据库编译。
2.被SQL注入的唯一可能是SQL能被数据库编译，如果不经过此阶段，能注入什么？
【胡途的回答(0票)】:
Prepared Statement
ODBC/JDBC/ADO/OLEDB等驱动都支持。
【FrankMeng的回答(0票)】:
使用存储过程作为应用程序访问数据库的唯一接口。另外，这也是唯一可以实现应用程序与数据库松耦合的方式。
存储过程分两种，一种是“平直”的不需要在内部动态拼写SQL的，这种自然不会被注入。另一种是需要在内部动态拼写SQL的然后用sp_executesql调用的。sp_executesql的参数规范为：
sp_executesql @statement= 'DELETE FROM TableA WHERE ID = @ID'
,@params =N'@ID INT' --SQL语句中的参数定义
,@ID = @pID --为SQL语句中的参数赋值
只要保证在拼接@statement的过程中不使用任何从存储过程参数传直接进来的数据直接拼接就不会被注入，如果一定要这么做，做一下映射即可，总之不能直接拼接。
推一荐：&&|&&
喜欢该文的人也喜欢