WEB安全分析
对于Web安全是每个互联网企业都必须关注的，安全问题涉及的种类及处理方式层出不穷
从类型来说：
服务器系统，网络通讯，web应用自身：针对用户的，针对应用的
从系统架构本身来说，并没有所谓的侧重点，这几方面都是需要考虑的问题，如同木桶理论
针对服务器系统来说，补丁的更新是最至关重要的，相关系统厂商版本的维护周期必须考量系统的更新
服务器上各类服务的设置，如PHP，Nginx等都有特定的设置会危害到系统安全（在特殊情况下）
对于网络通讯
DDOS(分布式拒绝服务攻击),通过消耗服务器资源达到攻击目的，所以对于服务器资源的管控都属于对于该攻击的预防，其攻击种类是建立在TCP/IP通讯协议上，是一类攻击的总称
- IP Spoofing(IP欺骗)
- LAND attack
- ICMP floods
应用层面包括自身应用及使用的服务应用都在可实现攻击的对象列表中
预防该类攻击
- 需要维护操作系统（win需要修改注册表，linux可以通过iptables来达到效果）
- 还要修复相关web服务（nginx则提供对于IP的限制，ftp等服务需要启用验证等）
- 甚至于对于web应用（对于用户的访问最一定程度的限制，如发帖限制等）都需要做相对应的修改
web应用自身：最基本的就是SQL注入问题了，解决手段也广为流传，但通常在不注意的情况下还是会让对方有机可乘，对任何外部来源的数据都进行预处理
注入危害（SQL注入只是其中一种）针对服务
- 任何使用外部来源数据照成的应用问题都可以归类为注入攻击，例如在模块化开发中，使用类库名作为链接参数！
- 直接使用eval等系统函数出来外部来源数据等
- 应用语言自身的一些语言特性也是注入危害的来源
XSS跨站式脚本攻击 针对用户
- 网站页面在客户端执行的动态脚本成为XSS攻击的入口，通过访问后执行特殊代码实现盗取用户session，cookie等个人信息
- 这类攻击是注入式攻击的延伸，攻击对象不是服务器，而转为使用服务的用户
- 对于这类攻击，首先尽可能的避免直接将外部数据添加到HTML中输出给用户，在无可避免的情况下对展示数据进行HTML过滤
- 对于cookie在可以的情况下使用httponly，避免个人信息被修改
CSRF跨站点请求伪造 针对用户
- 通过盗用身份进行请求，实现到对应用的危害，用户在不知情的情况下，被攻击方利用自身身份进行网站访问
- 基本的预防方式就是针对每次安全性请求都添加伪随机数，也就是访问令牌，原理是，攻击者获取不到第三方的cookie，所以对于每次请求都需要的伪随机数无法进行构造
- 可以使用验证码，每次请求都需要输入一个该请求所需的验证码
- 对不同的请求添加另一个伪随机数，避免并行提交的冲突
- 将需要安全的请求都设定为POST请求，对POST请求实现以上3点
clickjacking点击劫持 针对用户
- 攻击者通过在页面构造一个不可见的iframe，实现用户的点击操作的攻击
- 配合域名劫持，将目标网页加载在一个iframe内，在其上还有一层不可见的页面
- 目前的防御方案从2方面进行：
- 服务器：X-FRAME-OPTIONS是微软提出的一个http头，专门用来防御利用iframe嵌套的点击劫持攻击，有3个值：DENY(拒绝任何域加载)SAMEORIGIN(允许同源域下加载)ALLOW-FROM(可以定于允许frame加载的页面地址)，示例：header("X-FRAME-OPTIONS:DENY");
- 客户端：对iframe样式进行处理，显示iframe，对自己的iframe添加其他样式，用js进行页面重定向
认证 针对服务
- 不算是一个攻击方式，是一个层面的缺陷
- 在设计用户认证体系中的漏洞：
- Seesion fixation：通过预先获取访问的session或者cookie的id，发送可传递id的链接给受害人，当受害人登录后，则该ID的访问获取了受害人的登录权限，2次密码
- Session保持攻击：在获取到用户权限后，通过系统缺陷保持该session的有效性，达到长久的拥有该用户的访问权限，如果能再次访问延长有效期，则最简单的方式就是刷新页面了，最长登录时限
- 对于这类问题，通常需要权衡系统的安全程序来对程序做不同程度的设置
WEB安全在很多时候需要对于实际应用进行不同的操作权衡，问题最多的还是应用本身，现在大多应用都使用框架，框架在开发过程中就需要对功能进行安全上的权衡，并且通过一定的安全守则来进行安全预防
