Web安全读书笔记2

工具 拦截代理服务器
Burp Proxy   WebScarab Paros

COMRaider 显示一个控件的所有方法及其签名

隐藏表单字段 type=hidden 来保存信息
隐藏表单字段可以被编辑
方法1：
保存HTML页面源代码，编辑隐藏表单字段，然后源代码重新载入浏览器
方法2：
使用拦截代理服务器，来修改

使用拦截代理服务器 修改cookie

Reffer消息头  说明当前提出请求的页面URL
使用reffer来控制页面逻辑
如一个帮助忘记密码的用户重设密码
POST RestForgotPasswd.asp
Refer http //localhost/Forgot.asp
应用程序通过验证Refer头来判断请求是否在正确的阶段会造成漏洞，因为用户可以通过拦截代理服务器修改refer头

ASP.NET  View State
EnableViewStateMac 加入密钥散列

在HTML表单中使用maxlength设置长度大小而服务器端没有验证的时候，可以拦截提交的表单输入任何长度字符解除这种限制
试图修改 产生304 Not Modified  Etag。。。的响应 原因是浏览器已经在缓存中保存有它请求资源的副本，但浏览器请求一个已存入缓存的资源，它通常会在请求中添加另外两个消息头，If –modified-Since和If-None-Match。这些消息头告诉服务器，浏览器上次更新缓存副本和Etag的时间。Etag是一个序列号，服务器为每个可缓存的资源分配一个Etag，如果资源被修改，它也会被更新。如果服务器拥有比If –modified-Sinc消息头中指定日期更新的资源，或者当前Etag与If-None-Match不匹配，那么服务器就会在响应中提供最新的资源。否则返回304相应，告知浏览器资源没有修改，浏览器使用缓存中的副本。
如果这种情况并且需要拦截并修改浏览器保存在缓存中的资源，那么可以拦截相关请求并且删除If –modified-Since和If-None-Match消息头

使用JavaScript 验证的表单
方法1 禁用JavaScript 即可
方法2 在浏览器的输入字段输入一个良性值，然后用代理服务器拦截确认后的提交表单，然后将数据改为想要的值。
因此，在服务端也需要对数据进行一次验证。
客户端进行javascript验证的作用是改善用户体验，如果不采用客户端确认机制，更正某些格式错误需要多次提交注册页面。

表单中禁用的元素 也可以被攻击  如果应用程序处理这个参数

Applet的攻击  反编译字节码
反攻击方法 字节码模糊处理

ActiveX控件  使用逆向工程
Flasm swf反编译成字节码
Flare 反编译成ActionScript源代码
ActionScript Obfuscator   Viewer Screwer 模糊化

签名和加密数据 易于受到重传攻击  为防止这种攻击，所以应用程序要加入足够的上下文

Burp Intruder 进行密码暴力破解
一些应用程序使用设置cookie failedlogin=1 并登陆失败后递增这个值

利用不存在的用户名和用户名存在但密码错误的服务器响应时间来判断是否是一个有效的用户名

使用cookie 保存登陆证书的漏洞

登陆页面采用http 而验证后的页面采用https 也会导致漏洞
应该在加载登陆页面时候就采用https(使用https加载登陆表单)，使得用户在输入证书前验证页面是否真实可信，
因为登陆页面有可能被攻击者拦截并且更改，可能用户输入的证书会被攻击者获得 (中间人攻击)

用户伪装  后门密码

通过大量注册用户名  从而确认遭到拒绝的现有用户名

故障开放逻辑漏洞
Try{
String usrname=session.getname
String passwd=session.getpasswd
User user=db.getUser(username,passwd)
If(user==null)
{
Session.setMessage(“login failed”)
Return doLogin(session);
}
}
catch(Excepton e) {
}

Session.setMessage(“login in sussess”)           /
Return doMainMenu(session);

如果在db.getUser函数调用中出现了异常，那么就会跳转到catch块，而跳过if(user==null)的判断，照样会正常登陆，Session.setMessage(“login in sussess”)，出现漏洞


多阶段登陆漏洞
1应用程序总是认为可以访问第三阶段的用户已经完成了第一第二阶段的验证，因此它可能让直接由第一阶段进入第三阶段并提供正确证书的攻击者通过验证
2应用程序可能信任由第二阶段处理的一些数据，因为这些数据已经在第一阶段得到确认，但是攻击者可以在第二阶段操控这些数据，提供不同于第一阶段的值而更改应用程序的行为。
3 应用程序可能认为每个阶段的用户身份不发生变化。因此它不在每个阶段确认用户身份。
如果第一阶段和第二阶段的用户是不同的，但是每个阶段提交的是有效的数据对(用户名密码、用户名物理令牌)，那么有可能会通过验证。


CAPTCHA 全自动区分人类和计算机的图灵测试