已经拖了好久，安全学习总结，感觉没啥东西可以写的，凑活着写点吧，没办法了晚上赶出来

     在这里不写XSS、CSRF、SQL Injection、File Upload 、URL Redirection的攻击方法、原理、测试方法、防御思路这些的了

     之前已经在安全测试5个学习笔记中写了一些，而且很难概括性的全部讲到，讲讲其他的一些东西，下次看再来补充

在这之前我们先看看一些东西：我们知道很多公司都有自己的一套输入安全机制旨在阻止跨站脚本攻击。下面是一个输入安全机制的顺序：

删除任何出现的<script>表达式； 将输入截断为50字符；
删除输入的引号； 对输入进行URL编码；
如果热合输入项被删除，返回步骤<1>
如此：我们尝试构造能否越过输入安全机制

“><script>alert(“huaike”)</script>

确认是安全的，因为在一开始script表达式会被过滤，但是这只是相对来说安全，如果经过精心构造还是能被越过的

怎样去建立一个比较安全的安全机制呢？不要急，慢慢来讲…

为了确保安全，Web应用程序必须解决一个根本的问题：

核心安全问题：用户可提交任意输入

具体来说，它有三种表现形式，

用户可以敢于客户与服务器服务器间传送的数据；
用户可以按照任意的顺序发送请求，重复提交或根本不提交数据；
用户并不限于使用一种Web浏览器访问应用程序；
任何一个应用程序必须接受并处理可能为恶意的并且未经过验证的数据，会产生Web应用程序面临的核心安全问题

有问题当然要有相应的对策，核心防御机制，正是为了尽量减少这方面的问题

它有几个核心因素：

处理用户访问应用程序的数据与功能，防止用户获得未授权访问；
处理用户对应用程序功能的输入，房子错误输入造成不良行为；
处理攻击者，保证应用程序正常运转，并击败攻击者；
管理应用程序本身；
我们要关注的是<1>和<2>

处理用户访问：通常通过三方面，身份验证、会话管理、访问控制（通常多的漏洞出现在这里）

处理用户输入：这里要着重介绍

已知的处理方法有五种：

拒绝已知的不良输入，这好比设置黑名单，效率非常的低
接受已知的正常输入，跟白名单类似，虽然不错，但是用户体验上很差，不完全适用
净化：也可以称之为转义，这种方法非常有效，但是有时候必须要接受一些恶意数据
安全数据处理：并不使用应用程序的每项任务，对存在恶意输入处理的通用方法
语法检查；
这五种都是非常常用的方法，通常几种方法结合使用

在信任边界确认数据的做法也是并不少见的，

比如：

用户登录一个网站的时候通常会进行常规检查（攻击签名），登录到服务器以后要对数据库进行操作，必须要使用SQL转义再返回到服务器上，登录成功会使用SOAP服务要编码XML元字符，再发送SOAP消息到服务器，后再由服务器显示帐号信息时，要把任何用户提交的数据进行执行HTML编码。

针对不同的边界，对数据进行不同方法的处理这是非常有效的。

处理用户输入还有一个重要点是：多步确认与规范化

多步确认

讲到这里，我们回到一开始给的那个例子，如果觉得太长了，换个例子

<scri<script>pt>

这是一个在script标签中插入一个script的标签，如果过滤器只是一次过滤的话会把script标签的里面的script标签过滤，然后可怕的事情发生了，script合并在一起了，成为了一个新的script标签，其中的恶意脚本会被执行，所以能够的迭代的过滤是非常重要的。不过在这里会有人问，迭代了次数怎么确认，这个其实我也不知道，只能根据具体情况了

还有一个是规范化

（注：数据规范化的原因是能够通过HTTP安全传输特殊字符与二进制编码）

数据规范化通常会出现一个问题：

SQL注入，规范化会删除   ‘   号，然而使用URL编码，只要使用%27来代替  ‘  这样可以避过净化，如果你够狠应用程序删除这个URL编码的输入，并且进一步规范化，那么攻击者还是有办法的，输入避开确认：%%2727

这种问题是很难避免的

不存在的解决方案，递归是个好方法，但是也是有局限性的