web测试安全性常见问题
一、 登录账号明文传输
1、 问题一：登录账号密码或者修改密码明文传输
现象：目前物流对内的java系统基本上都是明文传输用户名和密码的
使用火狐自带工具-开发者-网络，或者httpwatch工具很容易获取到信息
打开工具后进行被测系统正常登录软件可自动获取信息
建议：
登录使用加密传输，一般的登录都采用https方式加密协议
2、 问题二：在后台日志中明文打印出了登录的账号和密码
现象：
建议：在日志中比较敏感的信息比如密码都采用*转换显示
二、 SQL注入
1、 问题一:部分查询输入存在SQL注入风险
所谓SQL注入式攻击，就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串，欺骗服务器执行恶意的SQL命令。在某些表单中，用户输入的内容直接用来构造（或者影响）动态SQL命令，或作为存储过程的输入参数，这类表单特别容易受到SQL注入式攻击。
现象一：
原登录页面的sql:
SELECT COUNT(*) FROM Login WHERE UserName=‘admin‘ AND Password=‘123456‘
现在登录时输入：’admin’--
SELECT COUNT(*) FROM Login WHERE UserName=‘admin‘-- Password=‘123‘
因为UserName值中输入了“--”注释符，后面语句被省略而登录成功。（常常的手法：前面加上‘; ‘ (分号，用于结束前一条语句)，后边加上‘--‘ (用于注释后边的语句)）
现象二：在查询语句中输入：’ or ‘1=1 看是否会查询出所有的记录
建议：开发不要直接写静态sql语句进行查询，需要使用动态拼接SQL，对于web测试需要对查询部位进行SQL注入测试。
注：参数化查询原理：在使用参数化查询的情况下，数据库服务器不会将参数的内容视为SQL指令的一部份来处理，而是在数据库完成 SQL 指令的编译后，才套用参数运行，因此就算参数中含有具有损的指令，也不会被数据库所运行。
三、 XSS跨站点攻击
1、 问题一：部分系统存在提交表单时输入html代码和JS代码可在服务器执行的情况
跨站脚本攻击(Cross Site Scripting)恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的特殊目的，如：
<input>
<script>alert(‘xss‘)</script>
现象：文本框中输入<input>或<script>alert(‘xss‘)</script>
提交后<input>和<script>alert(‘xss‘)</script>作为代码执行了出现了输入框，而不是作为字符串存储
建议：
原则：不相信客户输入的数据
注意: 攻击代码不一定在<script></script>中，还有其他方式
1)只允许用户输入我们期望的数据。 例如： 年龄的textbox中，只允许用户输入数字。 而数字之外的字符都过滤掉。
2)对数据进行Html Encode 处理
3)过滤或移除或转义特殊的Html标签， 例如: <script>, <iframe> , < for <, > for >, " for
四、 跨站伪造
1、 问题一：构造POST请求进行请求可提交到数据库中
是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法，也是可以从第三方网站提交的
现象：如下脚步用户获取到请求地址后，可以自己构造请求消息请求参数和值，通过浏览器执行后也可以提交到数据库那说明就是存在跨站伪造
建议：
Token验证
在每个HTTP请求里附加一部分信息是一个防御CSRF攻击的很好的方法，因为这样可以判断请求是否已经授权。这个“验证token”应该不能轻易的被未登录的用户猜测出来。如果请求里面没有这个验证token或者token不能匹配的话，服务器应该拒绝这个请求。
五、 目前普遍现象Java层未做校验或未做全部校验
一般来说JS的校验都是一种辅助，实际校验都要放在服务器，如果不做JAVA校验就可能会存在
1） 使用WebSarab等代理工具绕过页面校验，直接篡改数据后往数据库中插入数据；
2） html层的校验不能防止用户伪造请求 ，如上面的token校验就是其中一个例子；
3） 按ctrl+f5强制刷新提交，出现重复提交
4） js需要浏览器下载，如果浏览器下载JS失败，按钮未灰化用户可以反复点击，可出现重复提交，那还得靠服务器端的重复提交来保证
六、 借用WebSarab工具来绕过客户端的校验，验证是否进行了服务校验
七、 借用AppScan工具来自动扫描安全性问题