Web安全问题的凸显致使得安全防护人员实施大量的安全机制来抵御攻击，尽管各种安全机制设计细节和执行效率可能千差万别，但几乎所有Web应用采用的安全机制在策略上都具有相似性，都离不开核心的几个基本原则和主要措施。
一、基本原则
1、缺省安全
缺省安全可以说是Web安全中最基本、最重要的原则，可以归纳为白名单、黑 名单的思想以及最小权限原则。
黑名单、白名单思想应该都很熟悉，最典型的例子莫过于制定防火墙的访问控制策略时，如果网站只提供Web服务，那么正确的做法是使用白名单，只允许服务器的80和443端口对外提供服务，屏蔽除此之外的其他端口；而如果使用黑名单，则有可能出现问题，比如黑名单策略是不允许SSH端口对外开放，那么就要对SSH的默认端口22进行检查，而实际工作中，部分工程师会私自改变SSH的端口号，从而导致安全策略出现漏洞。除此之外，在防止SQL注入攻击中，使用白名单思想就是只允许用户提交特定类型的数据，比如数值型数据，而如果使用黑名单思想，就需要对很多字符进行过滤，包括引号、注释符号、OR等。再比如,在防止跨站脚本攻击时,可以只允许用户使用<a>、 <img>等需要用到的标签,这就是白名单思想,而如果是禁止使用<script>和<ifram>等标签,则是黑名单思想。对于黑名单和白名单这两种方式,网络安防人员需要根据不同的场景进行选择，有些场合适合使用黑名单，而有些场合使用白名单，但是更多地使用白名单，系统会变得更加安全。
最小权限原则就是只授予主体必要的权限，而不要过度授权。
比如文件上传漏洞出现的一个原因就是上传的脚本拥有可执行权限，如果将上传文件存放的目录的权限进行设置，取消它的执行权限，那么就杜绝了文件上传漏洞，这就是最小权限原则的体现。
2、数据与代码分离
数据与代码分离原则广泛适用于由于“注入”而引发的安全问题，在使用该原则时，需要严格区分代码和数据段。
比如下所示，有一段HTML源码，假设中间的变量var是用户可以控制输入的，称之为数据段，那么如果用户输入这样的一段内容，<script src="http://www.evil.com/"></script>，就很有可能触发跨站脚本攻击，因为这个数据段它包含了不可信任的代码。而如果该页面确实要执行JavaScript脚本用于弹出一个对话框，那么数据段应该变为alert()函数的参数，用户只能控制对话框显示的内容，从而杜绝了恶意脚本的执行，这就是数据与代码分离的原则。
# 数据段与代码段
<html>
<head>test</head>
<body>
$var # $var数据段
</body>
</html>
<html>
<head>test<head>
<body>
<script>
alert("$var") # $var数据段
<script>
</body>
</htmi>
3、不可预测性
不可预测性原则能够有效对抗篡改和伪造攻击。很多时候攻击者能够实现伪适的原因是所有的数据都已经知道了，因此可以伪造。如果使用一个随机的token来保护敏感的数据，就可以防止伪造了。比如提交转账时使用的表单，三个input控件的值都很容易伪造，但是再加上一个随机的token字段，攻击者就不能轻易的相造相同的表单了。
# 0ee6ba45e3d00bc218980e61cb9b0803是随机token值,使用随机token保护数据
<form action="http://www.dvwa.com/vulnerabilities/csrf/#" method="GET">
<input value="1000" name="money">
<input value="1000" name="money_conf">
<input value="提交" name="Change">
<input value= "0ee6ba45e3d00bc218980e61cb9b0803" name="user_token">
</form>
二、主要措施
1、处理用户访问
几乎任何的Web应用都必须满足一个中心的安全要求，即处理用户访问其数据与功能，防止用户获得未授权访问。通常情况下，用户都分为几种类型，如匿名用户、正常用户和管理用户,不同用户只允许访问不同的数据和功能。在处理用户访问的过程中，大多数Web应用都会使用三层相互关联的安全机制，分别是身份验证、会话管理和访问控制，这三种机制相互依赖，因此任何一个部分存在缺陷都可能使Web应用遭受攻击。
现在绝大部分Web应用还是使用传统的身份验证模型，即要求用户输入用户名和密码，这种模型看似简单，但是在实现的过程中，还是经常存在缺陷，比如攻击者可以恶意猜测用户密码，或者利用逻辑漏洞等，因此为了确保安全，还需要增加一些安全机制，比如限制用户重复登录的次数，增加短信验证码等功能。
身份验证通过之后的任务就是管理用户的会话了，而Cookie机制是实现用户会话管理最常规的方法，因此会话管理的有效性基本上取决于Cookie的安全性。可以通过给Cookie设置httponly属性，来限制客户端JavaScript直接访问cookie，从而杜绝利用跨站脚本攻击实现Cookie劫持。当然，还有其他的机制用于实现会话管理，比如重复提交证书等等，其中的原理基本上都是一样，要确保Cookie或者证书这些信息的私密性。
除了身份验证和会话管理，处理用户访问最后一步就是要实施正确的访问控制机制，而典型的访问控制机制要求都较为复杂，因此容易存在大量的安全漏洞，使得攻击者能够获得未授权访问，这就要求安防人员对每一项功能进行严格的访问控制测试。
2、处理用户输入
Web安全最基本一个假设就是所有用户的输入都不可信。大量针对Web应用的不同攻击都与提交错误的数据有关，攻击者可以专门设计这类输入，引各种各样的攻击行为。
处理用户输入的方法主要包括3种：
- 一是拒绝已知的不良输入(黑名单)
- 第二就是接收已知的正常输入(白名单)
- 第三就是净化,将数据中可能存在的恶意内容彻底删除掉或者进行适当的编码和转义
黑名单最常见的就是过滤包含各种特殊符号的数据，比如引号、注释符号，或者其他字符；白名单只允许特定的数据通过，比如就只能接收数值型的数据。对于黑名单这种方式，用户可以通过调整输入来绕过过滤，因此并不是完全安全的，而相比较而言，白名单的方式就更加可靠。
但是，很多情况下，用户必须输入具有特殊含义的数据，就不能简简单单通过黑名单和白名单的原则了，可以使用净化的方式，对特殊的字符进行转义，保证它们是安全的，然后在输出的过程中在转义回来。
3、处理攻击行为
在处理完用户访问和用户输入之后，Web安全是不是万无一失了呢？显然不是，再好的安全机制都有可能存在漏洞，从而遭受到攻击者蓄意攻击。因此，还必须设计一套完整的机制来处理这些意想不到的攻击行为，这里面主要包括维护日志，发出警报,修复漏洞等一系列措施。
对于注重安全的Web应用，日志应记录的事件应该至少包括以下几项：一是所有与身份验证功能有关的事件，比如登录成功或登录失败；二是关键的数据库访问操作，比如修改密码，转账等等；三是被访问控制机制阻止的访问企图。
通过查看日志中的信息可以帮助安防人员调查所有的攻击企图，然而有些时候需要立即采取行动，实时响应攻击企图，这就需要在网站中增加一套警报机制，警报的异常事件一般比日志文件中记录的事件更加敏感和重要，主要包括以下几种：
- 一是应用程序异常（如收到由单独一个IP地址或用户发出的大量请求,这就表明应用程序正在受到攻击）
- 二是数据库异常(比如数据库中大量数据集中被删除或修改等等)
- 三是包含已知攻击字符串的请求
- 四是请求中普通用户无法查看的数据被修改。
这些常见的功能目前很多Web应用程序防火墙都能够很完善地进行支持，因此有选择性地给网站上增加一个Web应用程序防火墙就显得很有必要了。
不管是维护日志，还是发出警报，它们都是用于帮助安防人员在确定了攻击行为之后，及时地修补漏洞。如果网站的漏洞出现在操作系统或者Web服务器软件中，这就需要及时更新补丁，而如果漏洞是网站自身功能的缺陷，就需要进一步完 善网站的功能。
网友评论