web应用安全开发与测试
换行符%0D%0A
篡改隐藏表单——burp
cookie中true代表管理员，false代表普通用户
没有判断ID，用户可控
直接访问下步骤URL：密码重置
访问控制案例2——重置密码，找回密码，修改面
大量的xss:采用过滤器进行过滤
冲突建议：建立白名单
渗透测试：编码执行
%0D%0A 就是URL里面的换行符
http://domain.com/index.php?url=http://good.com/%0D%0ALocation:+http://bad.com 这样就跳转到了坏人的链接【只将最后的location消息头作为相应返回】
同理 XXXX/%0D%0ASet-cookie:SESSION=ABCE 【外界就能随意生成cookie值，配合回话固定攻击来针对用户发动伪装攻击】
重定向 或 生成cookie等基于外部传入参数
生成任意cookie
重定向到任意网站
·文件包含：php一些函数内容当成php解析
·框架漏洞：
stuts2：
spring：
·webserver：
jboss：
·第三方编辑器：
fck
文件上传要随机重命名，并且不能带用户可控参数
·安全防御原则：
最小权限、黑白名单等
·会话管理
1、会话清除：绝对时间清除+无操作清除
2、登陆前与登录后的sesstionid一样导致会话固定攻击
3、案例一：
·暴力破解
4、短信验证码本地生成：短信验证码出现在html、js或者在提交请求包里面
5、密码复杂度校验要在服务端，客户端进行的话，用burp抓包修改，可绕过；放客户端验证只能防误操作
6、正向锁定--登录次数锁定（固定用户遍历密码尝试），如果限制了次数，可尝试反向：
反向锁定--限制IP或mac登录次数（遍历用户密码固定）
7、案例：
本地生成
反向暴力破解
短信炸弹
验证码未一次失效
1、访问控制前传：篡改url参数：
说明有访问控制是基于url的menuid
2、垂直越权防护：url加个身份标识参数，可以在数据库中拿，或者对比当前访问的url参数与客户端提交的url参数值.
3、异步操作风险例子：验证码
考虑到性能，输入验证码提交后服务端先检查验证码是否正确，之后再提交数据，异步错开可用burp抓第二步，暴力遍历验证码破解
1、有风险的sql代码：
2、有风险的csrf代码及测试代码
