⑴ web页面怎样做sql注入测试
直接在地址栏输入表达式进行测试.
示例：www.xx。net?id=1'or'1'='1
⑵ 安全测试中sql的注入是什么意思
所谓SQL注入，就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来说，它是利用现有应用程序，将（恶意）的SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。 比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的，这类表单特别容易受到SQL注入式攻击．
一般来说要阻止sql注入，需要前后端配合表单的内容进行验证。我是前端的，只要对表单的输入绑定change事件，对其中的内容进行正则验证，阻止用户输入特殊字符（比如\转义字符）。
⑶ 如何测试一个网站是不是可以被SQL注入
SQL注入通过网页对网站数据库进行修改。它能够直接在数据库中添加具有管理员权限的用户，从而最终获得系统管理员权限。黑客可以利用获得的管理员权限任意获得网站上的文件或者在网页上加挂木马和各种恶意程序，对网站和访问该网站的网友都带来巨大危害。
防御SQL注入有妙法
第一步:很多新手从网上下载SQL通用防注入系统的程序，在需要防范注入的页面头部用来防止别人进行手动注入测试。
可是如果通过SQL注入分析器就可轻松跳过防注入系统并自动分析其注入点。然后只需要几分钟，你的管理员账号及密码就会被分析出来。
第二步:对于注入分析器的防范，通过实验，发现了一种简单有效的防范方法。首先我们要知道SQL注入分析器是如何工作的。在操作过程中，发现软件并不是冲着“admin”管理员账号去的，而是冲着权限(如flag=1)去的。这样一来，无论你的管理员账号怎么变都无法逃过检测。
第三步:既然无法逃过检测，那我们就做两个账号，一个是普通的管理员账号，一个是防止注入的账号，如果找一个权限最大的账号制造假象，吸引软件的检测，而这个账号里的内容是大于千字以上的中文字符，就会迫使软件对这个账号进行分析的时候进入全负荷状态甚至资源耗尽而死机。下面我们就来修改数据库吧。
1.对表结构进行修改。将管理员的账号字段的数据类型进行修改，文本型改成最大字段255(其实也够了，如果还想做得再大点，可以选择备注型)，密码的字段也进行相同设置。
2.对表进行修改。设置管理员权限的账号放在ID1，并输入大量中文字符(最好大于100个字)。
3.把真正的管理员密码放在ID2后的任何一个位置(如放在ID549上)。
我们通过上面的三步完成了对数据库的修改。
另外要明白您做的ID1账号其实也是真正有权限的账号，现在计算机处理速度那么快，要是遇上个一定要将它算出来的软件，这也是不安全的。只要在管理员登录的页面文件中写入字符限制就行了，就算对方使用这个有上千字符的账号密码也会被挡住的，而真正的密码则可以不受限制。
⑷ 如何检测sql注入
不要拼接SQL语句，即防止传入参数问题，
举例：
select * from a where password = ' 变量 '；
假如传入的变量是： ' or 1=1 or 1='，那么最后这个语句就是：
select * from a where password = '' ' or 1=1 or 1=''；
你说会得到什么结果
如果你使用ADO，则尽量使用parameter方式传入参数，不要自己拼接sql语句，要拼接的话，确保传入参数不是可以破坏原sql语句的变量
⑸ 哪些工具可以用来测试sql注入漏洞
SQL注入漏洞有哪些 SQL注入攻击是当今最危险、最普遍的基于Web的攻击之一。所谓注入攻击，是攻击者把SQL命令插入到Web表单的输入域页面请求的查询字符串中，如果要对一个网站进行SQL注入攻击，首先需要找到存在SQL注入漏洞的地方
⑹ sql注入里面的1=1 1=2测试法有什么用
我觉得应该是 or 1=1 或者 and 1=2，or 1=1 表示条件一定会成立。 and 1=2表示条件一定不会成立。
比如一条语句 select password from users where username='xxx' or 1=1.
⑺ SQL注入求教学希望有网站可以测试
SQL注入是多少年前的 东西了。包括现在主流的IIS,Apache,Tomat 搭建的基础环境 都可以在全局方面去防范SQL注入了。
如果你想测试 建议你去一些老的网站 asp 的 去尝试。
⑻ SQL注入点检测
WebCruiser - Web Vulnerability Scanner (Web应用漏洞扫描器)
WebCruiser - Web Vulnerability Scanner, a compact but powerful web security scanning tool! It has a Crawler and Vulnerability Scanner(SQL Injection, Cross Site Scripting, XPath Injection etc. ). It can support not only scanning website, but also Prooving of concept for web vulnerabilities: SQL Injection, Cross Site Scripting, XPath Injection etc. WebCruiser是一个小巧但功能不凡的Web应用漏洞扫描器，它能够对整个网站进行漏洞扫描，并能够对发现的漏洞（SQL注入，跨站脚本，XPath注入等）进行验证；它也可以单独进行漏洞验证，作为SQL注入工具、XPath注入工具、跨站检测工具使用。
功能简介：
* 网站爬虫（目录及文件）；
* 漏洞扫描（SQL注入，跨站脚本，XPath注入）；
* 漏洞验证（SQL注入，跨站脚本，XPath注入）；
* SQL Server明文/字段回显/盲注；
* MySQL字段回显/盲注；
* Oracle字段回显/盲注；
* DB2字段回显/盲注；
* Access字段回显/盲注；
* 管理入口查找；
* GET/Post/Cookie 注入；
* 搜索型注入延时；
* 自动从自带浏览器获取Cookie进行认证；
* 自动判断数据库类型；
* 自动获取关键词；
* 多线程；
* 高级：代理、敏感词替换/过滤;
* 报告；
---------------------------------------------------
Function:
* Crawler(Site Directories And Files);
* Vulnerability Scanner(SQL Injection, Cross Site Scripting, XPath Injection etc.);
* POC(Proof of Concept): SQL Injection, Cross Site Scripting, XPath Injection etc.;
* GET/Post/Cookie Injection;
* SQL Server: PlainText/FieldEcho(Union)/Blind Injection;
* MySQL/Oracle/DB2/Access: FieldEcho(Union)/Blind Injection;
* Administration Entrance Search;
* Time Delay For Search Injection;
* Auto Get Cookie From Web Browser For Authentication;
* Report Output.
⑼ sql注入 安全测试 靠参数过滤可行吗
首先：我们要了解SQL收到一个指令后所做的事情：具体细节可以查看文章：SqlServer编译、重编译与执行计划重用原理在这里，我简单的表示为：收到指令->编译SQL生成执行计划->选择执行计划->执行执行计划。具体可能有点不一样，但大致的步骤如上所示。接着我们来分析为什么拼接SQL字符串会导致SQL注入的风险呢？首先创建一张表Users:CREATETABLE[dbo].[Users]([Id][uniqueidentifier]NOTNULL,[UserId][int]NOTNULL,[UserName][varchar](50)NULL,[Password][varchar](50)NOTNULL,CONSTRAINT[PK_Users]PRIMARYKEYCLUSTERED([Id]ASC)WITH(PAD_INDEX=OFF,STATISTICS_NORECOMPUTE=OFF,IGNORE_DUP_KEY=OFF,ALLOW_ROW_LOCKS=ON,ALLOW_PAGE_LOCKS=ON)ON[PRIMARY])ON[PRIMARY]插入一些数据：INSERTINTO[Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES(NEWID(),1,'name1','pwd1');INSERTINTO[Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES(NEWID(),2,'name2','pwd2');INSERTINTO[Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES(NEWID(),3,'name3','pwd3');INSERTINTO[Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES(NEWID(),4,'name4','pwd4');INSERTINTO[Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES(NEWID(),5,'name5','pwd5');假设我们有个用户登录的页面，代码如下：验证用户登录的sql如下：selectCOUNT(*)fromUserswherePassword='a'andUserName='b'这段代码返回Password和UserName都匹配的用户数量，如果大于1的话，那么就代表用户存在。本文不讨论SQL中的密码策略，也不讨论代码规范，主要是讲为什么能够防止SQL注入，请一些同学不要纠结与某些代码，或者和SQL注入无关的主题。可以看到执行结果：这个是SQLprofile跟踪的SQL语句。注入的代码如下：selectCOUNT(*)fromUserswherePassword='a'andUserName='b'or1=1—'这里有人将UserName设置为了“b'or1=1–”.实际执行的SQL就变成了如下：可以很明显的看到SQL注入成功了。很多人都知道参数化查询可以避免上面出现的注入问题，比如下面的代码：classProgram{="DataSource=.;InitialCatalog=Test;IntegratedSecurity=True";staticvoidMain(string[]args){Login("b","a");Login("b'or1=1--","a");}privatestaticvoidLogin(stringuserName,stringpassword){using(SqlConnectionconn=newSqlConnection(connectionString)){conn.Open();SqlCommandcomm=newSqlCommand();comm.Connection=conn;//为每一条数据添加一个参数comm.CommandText="selectCOUNT(*)fromUserswherePassword=@PasswordandUserName=@UserName";comm.Parameters.AddRange(newSqlParameter[]{newSqlParameter("@Password",SqlDbType.VarChar){Value=password},newSqlParameter("@UserName",SqlDbType.VarChar){Value=userName},});comm.ExecuteNonQuery();}}}实际执行的SQL如下所示：execsp_executesqlN'selectCOUNT(*)fromUserswherePassword=@PasswordandUserName=@UserName',N'@Passwordvarchar(1),@UserNamevarchar(1)',@Password='a',@UserName='b'execsp_executesqlN'selectCOUNT(*)fromUserswherePassword=@PasswordandUserName=@UserName',N'@Passwordvarchar(1),@UserNamevarchar(11)',@Password='a',@UserName='b''or1=1—'可以看到参数化查询主要做了这些事情：1：参数过滤，可以看到@UserName='b''or1=1—'2：执行计划重用因为执行计划被重用，所以可以防止SQL注入。首先分析SQL注入的本质，用户写了一段SQL用来表示查找密码是a的，用户名是b的所有用户的数量。通过注入SQL，这段SQL现在表示的含义是查找(密码是a的，并且用户名是b的，)或者1=1的所有用户的数量。可以看到SQL的语意发生了改变，为什么发生了改变呢？，因为没有重用以前的执行计划，因为对注入后的SQL语句重新进行了编译，因为重新执行了语法解析。所以要保证SQL语义不变，即我想要表达SQL就是我想表达的意思，不是别的注入后的意思，就应该重用执行计划。如果不能够重用执行计划，那么就有SQL注入的风险，因为SQL的语意有可能会变化，所表达的查询就可能变化。在SQLServer中查询执行计划可以使用下面的脚本：DBCCFreeProccacheselecttotal_elapsed_time/execution_count平均时间,total_logical_reads/execution_count逻辑读,usecounts重用次数,SUBSTRING(d.text,(statement_start_offset/2)+1,((CASEstatement_end_offsetWHEN-1THENDATALENGTH(text)ELSEstatement_end_offsetEND-statement_start_offset)/2)+1)语句执行fromsys.dm_exec_cached_plansacrossapplysys.dm_exec_query_plan(a.plan_handle)c,sys.dm_exec_query_statsbcrossapplysys.dm_exec_sql_text(b.sql_handle)d--wherea.plan_handle=b.plan_handleandtotal_logical_reads/execution_count>4000ORDERBYtotal_elapsed_time/execution_countDESC;