susu64616109
如何利用SQL注入漏洞攻破一个WordPress网站
展开全部 要防止SQL注入其实不难，你知道原理就可以了。
所有的SQL注入都是从用户的输入开始的。
如果你对所有用户输入进行了判定和过滤，就可以防止SQL注入了。
用户输入有好几种，我就说说常见的吧。
文本框、地址栏里***.asp？中？号后面的id=1之类的、单选框等等。
一般SQL注入都用地址栏里的。
。
。
。
如果要说怎么注入我想我就和上面的这位“仁兄”一样的了。
你只要知道解决对吗？ 对于所有从上一页传递过来的参数，包括request.form 、request.qurrystring等等进行过滤和修改。
如最常的***.asp?id=123 ，我们的ID只是用来对应从select 里的ID，而这ID一般对应的是一个数据项的唯一值，而且是数字型的。
这样，我们只需把ID的值进行判定，就可以了。
vbs默认的isnumeric是不行的，自己写一个is_numeric更好，对传过来的参数进行判定，OK，搞定。
算法上的话，自己想想，很容易了。
但是真正要做到完美的话，还有很多要计算的。
比如传递过来的参数的长度，类型等等，都要进行判定。
还有一种网上常见的判定，就是判定传递参数的那一页（即上一页），如果是正常页面传弟过来就通过，否则反之。
也有对' or 等等进行过滤的，自己衡量就可以了。
注意一点就是了，不能用上一页的某一个不可见request.form（＂*＂)进行判定，因为用户完全可以用模拟的形式“复制”一个和上一页完全一样的页面来递交参数。
...
如何用 sql 注入一步步攻破一个网站
展开全部 sql注入大家都不陌生，是一种常见的攻击方式，攻击者在界面的表单信息或url上输入一些奇怪的sql片段，例如“or '1'='1'”这样的语句，有可能入侵参数校验不足的应用程序。
所以在我们的应用中需要做一些工作，来防备这样的攻击方式。
在一些安全性很高的应用中，比如银行软件，经常使用将sql语句全部替换为存储过程这样的方式，来防止sql注入，这当然是一种很安全的方式，但我们平时开发中，可能不需要这种死板的方式。
mybatis框架作为一款半自动化的持久层框架，其sql语句都要我们自己来手动编写，这个时候当然需要防止sql注入。
其实Mybatis的sql是一个具有“输入+输出”功能，类似于函数的结构，如下： select id,title,author,content from blog where id=#{id} 这里，parameterType标示了输入的参数类型，resultType标示了输出的参数类型。
回应上文，如果我们想防止sql注入，理所当然地要在输入参数上下功夫。
上面代码中高亮部分即输入参数在sql中拼接的部分，传入参数后，打印出执行的sql语句，会看到sql是这样的：selectid,title,author,content from blog where id = ？不管输入什么参数，打印出的sql都是这样的。
这是因为mybatis启用了预编译功能，在sql执行前，会先将上面的sql发送给数据库进行编译，执行时，直接使用编译好的sql，替换占位符“？”就可以了。
因为sql注入只能对编译过程起作用，所以这样的方式就很好地避免了sql注入的问题。
mybatis是如何做到sql预编译的呢？其实在框架底层，是jdbc中的PreparedStatement类在起作用，PreparedStatement是我们很熟悉的Statement的子类，它的对象包含了编译好的sql语句。
这种“准备好”的方式不仅能提高安全性，而且在多次执行一个sql时，能够提高效率，原因是sql已编译好，再次执行时无需再编译。
话说回来，是否我们使用mybatis就一定可以防止sql注入呢？当然不是，请看下面的代码： select id,title,author,content from blog order by ${orderParam} 仔细观察，内联参数的格式由“#{xxx}”变为了${xxx}。
如果我们给参数“orderParam”赋值为”id”，将sql打印出来，是这样的：select id,title,author,content fromblog order by id 显然，这样是无法阻止sql注入的。
在mybatis中，”${xxx}”这样格式的参数会直接参与sql编译，从而不能避免注入攻击。
但涉及到动态表名和列名时，只能使用“${xxx}”这样的参数格式，所以，这样的参数需要我们在代码中手工进行处理来防止注入。
结论：在编写mybatis的映射语句时，尽量采用“#{xxx}”这样的格式。
若不得不使用“${xxx}”这样的参数，要手工地做好过滤工作，来防止sql注入攻击。
SQL注入问题
通用的asp防注入程序.杜绝SQL注入隐患.提升网站安全一般的http请求不外乎 get 和 post，所以只要我们在文件中过滤所有post或者get请求中的参数信息中非法字符即可，所以我们实现http 请求信息过滤就可以判断是是否受到sql注入攻击。
IIS传递给asp.dll的get请求是是以字符串的形式，当传递给Request.QueryString数据后，asp解析器会分析Request.QueryString的信息，然后根据＂&＂，分出各个数组内的数据所以get的拦截如下： 首先我们定义请求中不能包含如下字符 '|and|exec|insert|select|delete|update|count|*|%|chr|mid|master|truncate|char|declare|xp_cmdshell 各个字符用＂|＂隔开，，然后我们判断的得到的Request.QueryString 具体代码如下程序代码：Dim sql_injdata SQL_injdata = ＂'|and|exec|insert|select|delete|update|count|*|%|chr|mid|master|truncate|char|declare|xp_cmdshell＂ SQL_inj = split(SQL_Injdata,＂|＂) If Request.QueryString＂＂ Then For Each SQL_Get In Request.QueryString For SQL_Data=0 To Ubound(SQL_inj) If InStr(Request.QueryString(SQL_Get),Sql_Inj(Sql_DATA))>0 Then Response.Write(＂alert（＂＂提交的信息中包含非法字符！＂＂）；＂) Response.End() End If Next NextEnd If这样我们就实现了get请求的注入的拦截，但是我们还要过滤post请求，所以我们还得继续考虑request.form，这个也是以数组形式存在的，，我们只需要再进一次循环判断即可。
代码如下 程序代码：If Request.Form＂＂ Then For Each SQL_Get In Request.Form For SQL_Data=0 To Ubound(SQL_inj) If InStr(Request.QueryString(SQL_Get),Sql_Inj(Sql_DATA))>0 Then Response.Write(＂alert（＂＂提交的信息中包含非法字符！＂＂）；＂) Response.End() End If Next NextEnd If现在已经实现了get和post请求的信息拦截，只需要在conn.asp之类的打开数据库文件之前引用这个页面即可。
实例：Option Explicit'//SQL注入拦截开始Dim SQL_injdata, SQL_inj, SQL_Get, SQL_DataSQL_injdata = ＂'|and|exec|insert|select|delete|update|count|*|%|chr|mid|master|truncate|char|declare＂ SQL_inj = Split(SQL_Injdata,＂|＂) If Request.QueryString＂＂ Then Call KillSQLinj(Request.QueryString)'//get方式拦截If Request.Form＂＂ Then Call KillSQLinj(Request.Form)'//post方式拦截Sub KillSQLinj(fashion) For Each SQL_Get In fashion For SQL_Data=0 To Ubound(SQL_inj) If InStr(Request.QueryString(SQL_Get),Sql_Inj(Sql_DATA))>0 Then Response.Write(＂alert（＂＂提交的信息中包含非法字符！＂＂）；＂) Response.End() End If Next Next End Sub'//SQL注入拦截结束要是回答的内容有问题，或认为不妥，请发送百度消息给我，消息内容加上本页网址哦。
。
·
c# 传参的方式能完全防止sql注入吗
展开全部 结论：如果不能够重用执行计划，那么就有SQL注入的风险，因为SQL的语意有可能会变化，所表达的查询就可能变化。
首先，什么是注入漏洞攻击呢？所谓SQL注入，就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。
通常的解决方案有过滤敏感字符，比如说过滤掉or, and , select sql等关键字，通过参数化查询解决sql注入漏洞的实例。
所谓的参数化查询（Parameterized Query 或 Parameterized Statement）是指在设计与数据库链接并访问数据时，在需要填入数值或数据的地方，使用参数 （Parameter） 来给值，这个方法目前已被视为最有效可预防SQL注入攻击 （SQL Injection） 的攻击手法的防御方式。
Microsoft SQL Server 的参数格式是以 ＂@＂ 字符加上参数名称而成. SQL 引擎的处理流程，大致为：收到指令 -> 编译SQL生成执行计划 ->选择执行计划 ->执行执行计划。
参数化查询主要做了这些事情：1：参数过滤，对传入值进行了处理，按字符语义来处理。
2：执行计划重用 为参数化查询可以重用执行计划，并且如果重用执行计划的话，SQL所要表达的语义就不会变化，所以就可以防止SQL注入，如果不能重用执行计划，就有可能出现SQL注入，存储过程也是一样的道理，因为可以重用执行计划。
...
怎么样防止Sql注入？
展开全部 （1）对于动态构造SQL查询的场合，可以使用下面的技术：第一：替换单引号，即把所有单独出现的单引号改成两个单引号，防止攻击者修改SQL命令的含义。
再来看前面的例子，“SELECT * from Users WHERE login = ''' or ''1''=''1' AND password = ''' or ''1''=''1'”显然会得到与“SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'”不同的结果。
第二：删除用户输入内容中的所有连字符，防止攻击者构造出类如“SELECT * from Users WHERE login = 'mas' -- AND password =''”之类的查询，因为这类查询的后半部分已经被注释掉，不再有效，攻击者只要知道一个合法的用户登录名称，根本不需要知道用户的密码就可以顺利获得访问权限。
第三：对于用来执行查询的数据库帐户，限制其权限。
用不同的用户帐户执行查询、插入、更新、删除操作。
由于隔离了不同帐户可执行的操作，因而也就防止了原本用于执行SELECT命令的地方却被用于执行INSERT、UPDATE或DELETE命令。
⑵ 用存储过程来执行所有的查询。
SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。
此外，它还使得数据库权限可以限制到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式攻击了。
⑶ 限制表单或查询字符串输入的长度。
如果用户的登录名字最多只有10个字符，那么不要认可表单中输入的10个以上的字符，这将大大增加攻击者在SQL命令中插入有害代码的难度。
⑷ 检查用户输入的合法性，确信输入的内容只包含合法的数据。
数据检查应当在客户端和服务器端都执行——之所以要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。
在客户端，攻击者完全有可能获得网页的源代码，修改验证合法性的脚本（或者直接删除脚本），然后将非法内容通过修改后的表单提交给服务器。
因此，要保证验证操作确实已经执行，唯一的办法就是在服务器端也执行验证。
你可以使用许多内建的验证对象，例如RegularExpressionValidator，它们能够自动生成验证用的客户端脚本，当然你也可以插入服务器端的方法调用。
如果找不到现成的验证对象，你可以通过CustomValidator自己创建一个。
⑸ 将用户登录名称、密码等数据加密保存。
加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入的数据进行了“消毒”处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了攻击者注入SQL命令。
System.Web.Security.FormsAuthentication类有一个HashPasswordForStoringInConfigFile，非常适合于对输入数据进行消毒处理。
⑹ 检查提取数据的查询所返回的记录数量。
如果程序只要求返回一个记录，但实际返回的记录却超过一行，那就当作出错处理。
---------------------------------------------------------------------------------------------------------------------------关键是明白原理，其实防范很简单的， 1.过滤SQL需要的参数中的敏感字符（注意加入忽略大小写） 2.禁用数据库服务器的xp_cmdshell存储过程，删除相应用到的dll 3.屏蔽服务器异常信息
转载请注明出处51数据库 » wordpress3.9 sql注入
