常用的几个验证：
1.输入框输入>书名号，看是否会被截断
2.不登陆直接访问已登录才能看到的页面，或访问一些没权限的页面用url，下载url
3.靠浏览器的后退或前进按钮（注销后
4.密码是否简单，多次失败登录，重要信息传参是否明文
5.一些readonly的信息是否能被修改提交
6.seasion是否过期，session id生成是否有规律，session互窜
Appscan常用设置：
高级设置（1=I.E.、2=firefox、3=chrome）
登陆管理：记录，固定输入，cookie
1. 手动探索一下自己认为重要的内容，加进去测试内容里面，注意核心的功能是否有被测试到
2. 自己可以设置去除一些重复的路径和文件（swf），例如静态的网站（论坛/新闻001.html ），提高扫描效率
3. 设置扫描的策略，不同严重性和类别关注的内容是不一样的，如xss，sql这些是必选的，低的可以不要
4. 登陆是否成功，不成功就扫描不到很多内容了
5. url是否超时，服务器会不会受不了（并发进程）
Web渗透测试可以从以下几个方面考虑：
1.SQL Injection(SQL注入)
(1)如何进行SQL注入测试?
首先找到带有参数传递的URL页面,如 搜索页面,登录页面,提交评论页面等等.
注1:对 于未明显标识在URL中传递参数的,可以通过查看HTML源代码中的"FORM"标签来辨别是否还有参数传递.在<FORM> 和</FORM>的标签中间的每一个参数传递都有可能被利用.
<form id="form_search" action="/search/" method="get">
<div>
<input type="text" name="q" id="search_q" value="" />
<input name="search" type="image" src="/media/images/site/search_btn.gif" />
<a href="/search/" class="fl">Gamefinder</a>
</div>
</form>
注 2:当你找不到有输入行为的页面时,可以尝试找一些带有某些参数的特殊的URL,如HTTP://DOMAIN/INDEX.ASP?ID=10
其 次,在URL参数或表单中加入某些特殊的SQL语句或SQL片断,如在登录页面的URL中输入HTTP://DOMAIN /INDEX.ASP?USERNAME='HI' OR 1=1
注1：根据实际情况,SQL注入请求可以使用以下语句:
' or 1=1- -
" or 1=1- -
or 1=1- -
' or 'a'='a
" or "a"="a
') or ('a'='a
注2：为什么是OR， 以及',――是特殊的字符呢？
例子：在登录时进行身份验证时，通常使用如下语句来进行验证：sql=select * from user where username='username' and pwd='password'
如 输入http://duck/index.asp?username=admin' or 1='1&pwd=11，SQL语句会变成以下：sql=select * from user where username='admin' or 1='1' and password='11'
' 与admin前面的'组成了一个查询条件,即username='admin',接下来的语句将按下一个查询条件来执行.
接 下来是OR查询条件,OR是一个逻辑运 算符，在判断多个条件的时候，只要一个成立，则等式就成立，后面的AND就不再时行判断了，也就是 说我们绕过了密码验证，我们只用用户名就可以登录.
如 输入http://duck/index.asp?username=admin'--&pwd=11，SQL语 句会变成以下sql=select * from user where name='admin' --' and pasword='11',
'与admin前面的'组成了一个查 询条件,即username='admin',接下来的语句将按下一个查询条件来执行
接下来是"--"查询条件,“--”是忽略或注释,上 述通过连接符注释掉后面的密码验证(注:对ACCESS数据库无 效).
最后,验证是否能入侵成功或是出错的信息是否包含关于数据库服务器 的相关信息;如果 能说明存在SQL安 全漏洞.
试想,如果网站存在SQL注入的危险,对于有经验的恶意用户还可能猜出数据库表和表结构,并对数据库表进行增删改的操 作,这样造成的后果是非常严重的.
(2)如何预防SQL注入?
从应用程序的角度来讲,我们要做以下三项工作:
转义敏感字符及字符串(SQL的敏感字符包括“exec”,”xp_”,”sp_”,”declare”,”Union”,”cmd”,”+”,”//”,”..”,”;”,”‘”,”--”,”%”,”0x”,”><=!-*/()|”,和”空格”).
屏蔽出错信息：阻止攻击者知道攻击的结果
在服务端正式处理之前提交数据的合法性(合法性检查主要包括三 项:数据类型,数据长度,敏感字符的校验)进行检查等。最根本的解决手段,在确认客 户端的输入合法之前,服务端拒绝进行关键性的处理操作.
从测试人员的角度来讲,在程序开发前(即需求阶段),我们就应该有意识的将安全性检查应用到需求测试中,例如对一个表单需求进行检查时,我们一般检验以下几项安全性问题:
需求中应说明表单中某一FIELD的类型,长度,以及取值范围(主要作用就是禁止输入敏感字符)
需求中应说明如果超出表单规定的类型,长度,以及取值范围的,应用程序应给出不包含任何代码或数据库信息的错误提示.
当然在执行测试的过程中,我们也需求对上述两项内容进行测试.
2.Cross-site scritping(XSS):(跨站点脚本攻击)
(1)如何进行XSS测试?
<!--[if !supportLists]-->首先,找到带有参数传递的URL,如 登录页面,搜索页面,提交评论,发表留言 页面等等。
<!--[if !supportLists]-->其次,在页面参数中输入如下语句(如:Javascrīpt,VB scrīpt, HTML,ActiveX, Flash)来进行测试：
<scrīpt>alert(document.cookie)</scrīpt>
最后,当用户浏览 时便会弹出一个警告框，内容显示的是浏览者当前的cookie串,这就说明该网站存在XSS漏洞。
试想如果我们注入的不是以上这个简单的测试代码，而是一段经常精心设计的恶意脚本，当用户浏览此帖时，cookie信息就可能成功的被 攻击者获取。此时浏览者的帐号就很容易被攻击者掌控了。
(2)如何预防XSS漏洞?
从应用程序的角度来讲,要进行以下几项预防:
对Javascrīpt,VB scrīpt, HTML,ActiveX, Flash等 语句或脚本进行转义.
在 服务端正式处理之前提交数据的合法性(合法性检查主要包括三项:数据类型,数据长度,敏感字符的校验)进行检查等。最根本的解决手段,在确认客户端的输入合法之前,服务端 拒绝进行关键性的处理操作.
从测试人员的角度来讲,要从需求检查和执行测试过程两个阶段来完成XSS检查:
在需求检查过程中对各输入项或输出项进行类型、长度以及取 值范围进行验证，着重验证是否对HTML或脚本代码进行了转义。
执行测试过程中也应对上述项进行检查。
3.CSRF:(跨站点伪造请求)
CSRF尽管听起来像跨站脚本（XSS），但它与XSS非常不同，并且攻击方式几乎相左。
XSS是利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。
XSS也好，CSRF也好，它的目的在于窃取用户的信息，如SESSION 和 COOKIES，
(1)如何进行CSRF测试？
目前主要通过安全性测试工具来进行检查。
(2)如何预防CSRF漏洞？
这个我们在这就不细谈了
4.Email Header Injection(邮件标头注入)
Email Header Injection：如果表单用于发送email,表单中可能包括“subject”输入项（邮件标题），我们要验证subject中应能escape掉“ ”标识。
<!--[if !supportLists]--><!--[endif]-->因为“ ”是新行，如果在subject中输入“hello cc:spamvictim@example.com”，可能会形成以下
Subject: hello
cc: spamvictim@example.com
<!--[if !supportLists]--><!--[endif]-->如果允许用户使用这样的subject，那他可能会给利用这个缺陷通过我们的平台给其它用 户发送垃圾邮件。
5.Directory Traversal(目录遍历)
（1）如何进行目录遍历测试？
目录遍历产生的原因是：程序中没有过滤用户输入的“../”和“./”之类的目录跳转符,导致恶意用户可以通过提交目录跳转来遍历服务器上的任意文件。
测试方法：在URL中输入一定数量的“../”和“./”，验证系统是否ESCAPE掉了这些目录跳转符。
（2）如何预防目录遍历？
限制Web应用在服务器上的运行
进 行严格的输入验证，控制用户输入非法路径
6.exposed error messages(错误信息)
（1）如何进行测试？
首 先找到一些错误页面，比如404,或500页面。
验证在调试未开通过的情况下，是否给出了友好的错误提示信息比如“你访问的页面不存 在”等，而并非曝露一些程序代码。
（2）如何预防？
测试人员在进行需求检查时，应该对出错信息 进行详细查，比如是否给出了出错信息，是否给出了正确的出错信息。
1， 问题：没有被验证的输入
测试方法：
数据类型(字符串，整型，实数，等)
允许的字符集
最小和最大的长度
是否允许空输入
参数是否是必须的
重复是否允许
数值范围
特定的值(枚举型)
特定的模式(正则表达式)
2， 问题：有问题的访问控制
测试方法：
主要用于需要验证用户身份以及权限的页面，复制该页面的url地址，关闭该页面以后，查看是否可以直接进入该复制好的地址
例：从一个页面链到另一个页面的间隙可以看到URL地址
直接输入该地址，可以看到自己没有权限的页面信息，
3 错误的认证和会话管理
分析：帐号列表：系统不应该允许用户浏览到网站所有的帐号，如果必须要一个用户列表，推荐使用某种形式的假名(屏幕名)来指向实际的帐号。
浏览器缓存：认证和会话数据不应该作为GET的一部分来发送，应该使用POST，
4 问题：跨站脚本(XSS)
分析：攻击者使用跨站脚本来发送恶意代码给没有发觉的用户，窃取他机器上的任意资料
测试方法：
• HTML标签：<…>…
• 转义字符：&(&);<(<);>(>); (空格) ;
• 脚本语言：
• 特殊字符：‘ ’ < > /
• 最小和最大的长度
• 是否允许空输入
例：对Grid、Label、Tree view类的输入框未作验证，输入的内容会按照html语法解析出来
5，缓冲区溢出
分析：用户使用缓冲区溢出来破坏web应用程序的栈，通过发送特别编写的代码到web程序中，攻击者可以让web应用程序来执行任意代码。
6，注入式漏洞
例：一个验证用户登陆的页面，
如果使用的sql语句为：
Select * from table A where username=’’ + username+’’ and pass word …..
Sql 输入 ‘ or 1=1 ―― 就可以不输入任何password进行攻击
7，不恰当的异常处理
分析：程序在抛出异常的时候给出了比较详细的内部错误信息，暴露了不应该显示的执行细节，网站存在潜在漏洞，
8，不安全的存储
没有加密关键数据
例：view-source：http地址可以查看源代码
在页面输入密码，页面显示的是 *****, 右键，查看源文件就可以看见刚才输入的密码
9，拒绝服务
分析：攻击者可以从一个主机产生足够多的流量来耗尽狠多应用程序，最终使程序陷入瘫痪。需要做负载均衡来对付。
10，不安全的配置管理
分析：Config中的链接字符串以及用户信息，邮件，数据存储信息都需要加以保护
程序员应该作的： 配置所有的安全机制，关掉所有不使用的服务，设置角色权限帐号，使用日志和警报。