http://wenku.baidu.com/view/a7141087bceb19e8b8f6bac6.html
http://sec.chinabyte.com/230/8863730_2.shtml
http://www.ltesting.net/html/89/92689-166810.html
后来找了很多有关这方面的东西，于是概括一下，主要就是
测试下面那些内容了(一些文绉绉的理论就不讲啦，我只是总结测试动作)：
一、没有进行xss过滤的情况:
a、url中的所有参数值用 '"></script><script>alert("hello,my girl!")</script> 代替测试:
现象：跳出“hello，my girl!”提示框；
b、text框输入 '"></script><script>alert("hello,my girl!")</script>，点击提交：
现象：没有正常写入数据库；或查看阅览页面或者从数据库显示时，没有被转义；
c、副文本编辑器输入<img nerror = "alert(123)" src=http://xxx.com>;
现象：没有正常写入数据库；查看阅览页面或从数据库显示时，出现js错误或者排版出现问题；
d、在数据库字段中写入'"></script><script>alert("hello,my girl!")</script>，查看页面显示：
现象：跳出alert；或者页面出现js问题等；查看源代码时，没有进行转义；
注意点：
1、很多时候，html代码的<title >和<meta >中的参数会显示数据库的产品名呀，或者其他有可能显示乱码的参数，所以这种地方也需要注意，以'"/></script><script>alert("hello,my girl!")</script>为例，就会跳出alert值，或者显示</script><script>alert("hello,my girl!")</script>不应该显示的值，因为被",或者/>拦截了。
2、有些html链接，如果url是×××.产品名.html的时候，如果产品名或者其他参数有可能会是乱码的时候，它会把前面的一些单引号或者双引号先优先使用了，以'"/></script><script>alert("hello,my girl!")</script>为例，url = "×××.'"/></script><script>alert("hello,my girl!")</script>"，这样的情况的话，页面就会显示/></script><script>alert("hello,my girl!")</script>"这样的不应该显示的值。
3、如果你的网站有搜索框，那就用包含这样的值的产品名进行搜索，有可能搜索不出来，有可能是页面跳出alert值，或者页面出现了不该出现的代码行等。
4、主要点就是输入框，显示，链接，url输入，搜索等。
二、关于crsf：
1、搜索在所有我数据提交的地方，是否都加了token值；
2、修改数据提交出的crsf，再提交，是否能正常提交，是否提示数据超时；
3、每个不同的用户登录后，token值是否都是新值。
注意点：
a、虽然加token貌似看起来不难，看到有什么提交按钮就加上token就好了，所以很多时候开发会忘记软更新的时候加上token。比如说，删除这个动作是每条数据产生的时候，跟在数据后面的url链接。我在测试这个的时候，对应的开发就忘记了所有软更新的token添加。所以这个地方需要特别注意；
b、还有一点是，每个用户登录后的token是不一致的。比如说a用户这一次登录后token值是1111，b用户这一次登录后2222.但登录后，不管什么操作，token值就是一致了。意思是比如a用户产生的token值是1111，那这个值将伴随他直到他下一次重新登录。
这次我测试的部分只有这两个部分，关于sql注入等，还没有涉及，下次有机会整理。
另一个就是在URL最后随意输入一些字符或数字，结果，新闻模块那出现了问题，暴露了网站的一些信息，又一个bug，高兴下。。。。。。。
下面把今天看到的有关sql注入方面的知识整理如下：
SQL注入是一种攻击方式，在这种攻击方式中，恶意代码被插入到字符串中，然后将该字符串传递到SQL Server的实例以进行分析和执行。任何构成SQL语句的过程都应进行注入漏洞检查，因为SQL Server将执行其接收到的所有语法有效的查询。一个有经验的、坚定的攻击者甚至可以操作参数化数据。
SQL注入的主要形式包括直接将代码插入到与SQL命令串联在一起并使其得以执行的用户输入变量。一种间接的攻击会将恶意代码注入要在表中存储或作为元数据存储的字符串。在存储的字符串随后串连到一个动态SQL命令中时，将执行该恶意代码。
注入过程的工作方式是提前终止文本字符串，然后追加一个新的命令。由于插入的命令可能在执行前追加其他字符串，因此攻击者将用注释标记“--”来终止注入的字符串。执行时，此后的文本将被忽略。
以下脚本显示了一个简单的SQL注入。此脚本通过串联硬编码字符串和用户输入的字符串而生成一个SQL查询：
var Shipcity;
ShipCity = Request.form. ("ShipCity");
var sql = "select * from OrdersTable where ShipCity = '" + ShipCity + "'";
用户将被提示输入一个市县名称。如果用户输入Redmond，则查询将由与下面内容相似的脚本组成：
SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond'
但是，假定用户输入以下内容：
Redmond'; drop table OrdersTable--
此时，脚本将组成以下查询：
SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'
分号(;)表示一个查询的结束和另一个查询的开始。双连字符(--)指示当前行余下的部分是一个注释，应该忽略。如果修改后的代码语法正确，则服务器将执行该代码。SQL Server处理该语句时，SQL Server将首先选择OrdersTable中的所有记录（其中ShipCity为Redmond）。然后，SQL Server将删除OrdersTable。
只要注入的SQL代码语法正确，便无法采用编程方式来检测篡改。因此，必须验证所有用户输入，并仔细检查在您所用的服务器中执行构造SQL命令的代码。本主题中的以下各部分说明了编写代码的最佳做法。
验证所有输入
始终通过测试类型、长度、格式和范围来验证用户输入。实现对恶意输入的预防时，请注意应用程序的体系结构和部署方案。请注意，设计为在安全环境中运行的程序可能会被复制到不安全的环境中。以下建议应被视为最佳做法：
如果一个用户在需要邮政编码的位置无意中或恶意地输入了一个10 MB的MPEG文件，应用程序会做出什么反应？
如果在文本字段中嵌入了一个DROP TABLE语句，应用程序会做出什么反应？
测试输入的大小和数据类型，强制执行适当的限制。这有助于防止有意造成的缓冲区溢出。
输入字符 | 在Transact-SQL中的含义 |
; | 查询分隔符。 |
' | 字符数据字符串分隔符。 |
-- | 注释分隔符。 |
/* ... */ | 注释分隔符。服务器不对/*和*/之间的注释进行处理。 |
xp_ | 用于目录扩展存储过程的名称的开头，如xp_cmdshell。 |
举例说明对数据库防SQL注入
SQL注入是防止数据库攻击的一个有效策略。攻击者将注入一个SQL语句到另外一个语句中，这个通常会损坏你的数据库。有数据库接口的Web站点通常在SQL注入的时候容易受到攻击，因为它们是基于动态的SQL；下面是一个简单的例子：
在一个ASP页面中会请求用户输入名字和密码，然后将下面的字符串发送到数据库中：
SELECT FROM users WHERE username =
’whatever’ AND password = ’mypassword’
这看起来很安全，实际上不是，一个用户可能会这样输入他的名字：
’ OR 1>0 --
当把这个输入到SQL语句中的时候，结果可能会象这样：
SELECT FROM users WHERE username
= ’’ OR 1>0 -- AND password = ’’
这个注入语言将通过语句暴露密码。这将导致所有的用户名都会在用户列表中，所以，任何用户都可以进入到你的系统中。
最简单阻止注入分类是分析SQL串并移动语句之前的任何“--”的发生。
同时，你要小心注入的时候含有分号，因为分号是给SQL语句分界。如果一个用户的名字是下面这个：
’ OR 1>0 ; DELETE Customers ; --
WEB攻击
Windows SQL injection (site contain /admin/login.asp or just login.asp page)
Instead password use one of this string
' or 1=1--
" or 1=1--
or 1=1--
' or 'a'='a
" or "a"="a
') or ('a'='a
") or ("a"="a
如果一个用户怀有恶意，那么他可以使用多种方法看穿你的系统，但是，最简单的方法就是避免动态的SQL，用存储过程来代替。使用SQL来遍历参数，注入上面所提到的将会产生进程错误，并且存储进程将不会被执行。
