网站的十大安全措施

从应用的架构、设计和研发角度总结了构建安全应用的十大控制措施，致力于提高软件设计和开发人员的安全意识和能力，进而提升应用的安全性。这十大措施中，有的很具体，有的只是通用的分类，有的是技术性的，有的是过程相关的。

不过，仅仅指出问题往往是不够的，开发人员是应用的基础，为了开发出安全的应用，必须要为他们提供必要的帮助和支持。编写Web 应用的软件开发人员需要掌握和练习各种安全编码的技术。Web 应用的每一层，包括用户界面、业务逻辑、控制器以及数据库代码，在编写的时候都必须将安全问题牢记在心，这可能是非常困难的一项任务，因为大多数开发人员并没有太多安全方面的知识，而用来构建Web 应用的语言和框架在安全方面通常缺乏必要的控制。在需求和设计阶段，可能也会有固有的缺陷，很少有组织为开发人员提供需求规约以指导他们编写安全的代码。

1. 参数化查询

SQL 注入是Web 应用中最危险的漏洞之一，因为SQL 注入较为容易被黑客探测到并且会给应用带来毁灭性的打击。只需在你的Web 应用中注入一条简单的恶意SQL，你的整个数据库可能就会被窃取、擦除或者篡改。在运行数据库的主机上，甚至可以借助Web 应用执行危险的操作系统命令。为了防止SQL 注入，开发人员必须阻止那些不可信任的输入，这些输入将会解析成为SQL 命令的一部分。要实现这一点，最好的一种方式就是使用被称做查询参数化（Query Parameterization）的编程技术。

例如，在Java 之中，查询参数化如下所示：

2. 对数据进行编码

编码（encoding）是一个很强大的工具，它有助于防范很多类型的攻击，尤其是注入攻击。本质上来讲，编码就是将特殊字符转换成对等的字符，但是转换后的字符对于目标解析器来说不再是敏感的。关于编码的一个样例就是防止跨站脚本攻击（XSS，Cross SiteScripting）。Web 开发人员经常会动态地构建Web 页面，页面中包含开发人员构建的HTML/JavaScript代码以及数据库中的数据，而这些数据最初是由用户输入的。输入的数据应该被视为不可信任且危险的，在构建安全的Web 应用时，需要对其进行特殊的处理。当攻击者欺骗你的用户执行恶意的JavaScript 时，就会发生跨站脚本攻击或者更恰当地称之为JavaScript 注入，这些JavaScript 脚本最初是构建到Web 站点中的，XSS 攻击会在用户的浏览器中执行，因此会产生各种各样的影响。

例如，XSS 站点涂改：

XSS session 窃取：

持久化XSS（Persistent XSS）或存储XSS（Stored XSS）指的是XSS 攻击嵌入到了站点的数据库或文件系统之中了。这种XSS 更为危险，因为当攻击执行的时候，用户已经登录站点了。当将XSS 攻击置于URL 的结尾处时，会发生反射XSS（Reflected XSS），它会欺骗受害者访问该URL，当访问的时候攻击就会触发。阻止XSS的关键编程技术就是输出编码，它会在输出的时候执行，如果你

构建用户界面的话，也就是在将非信任的数据添加到HTML 中的时候。能够阻止XSS 的编码形式包括HTML实体编码、JavaScript 编码以及百分号编码（也称为URL 编码）。

3. 校验所有的输入

编写安全应用时，很重要的一点就是将所有来自于应用外部的输入（如来自于浏览器或移动客户端，来自于外部系统或文件）均视为不可信任的。对于Web 应用来说，这包括HTTP头、cookies 以及GET 和POST 参数，总而言之也就是任何攻击者可以入侵的数据。构建安全Web 应用的一个重要方法就是限制用户能够提交到Web 应用之中的输入。限制用户输入的技术称之为“输入校验”。在Web 应用的服务器端，输入校验通常会用到正则表达式。有两种输入校验，分别为“白名单”和“黑名单”校验。白名单试图定义好的输入是什么样子的，任何不匹配“好输入”定义的输入都会被拒绝。“黑名单”校验会试图探测已知的攻击，只会拒绝这些攻击和非法字符。黑名单校验更为困难，因为可以通过编码或其他伪装技术绕过，所以在构建安全Web 应用时并不推荐使用。但有些时候正则表达式是不够的，如果你的应用要处理markup，也就是不受信任的输入中会包含HTML 片段，这样的话会很难进行校验，编码也是很困难的，因为编码的话会破坏输入中的标签。此时，会需要一个能够解析和清理HTML格式文本的库，如OWASP Java HTML Sanitizer。

4. 实现适当的访问控制

授权（Authorization，Access Control）过程指的是请求要访问特定资源时，需要判断该请求是该准许还是拒绝。访问控制可能会非常复杂，在应用开发的初始阶段，需要考虑到一些“积极”的访问控制设计需求。在软件的安全设计中，

访问控制是很重要的一块内容，因此事先需要进行充分考虑：

✓强制所有的请求都通过访问控制检查

大多数的框架和语言只会检查程序员指定的特性，但是与之相反的做法是更以安全为中心的。可以考虑使用过滤器或其他的自动化机制以保证所有的请求都要经历某种类型的访问控制检查。

✓默认拒绝

结合自动化的访问控制检查，需要考虑拒绝访问所有没有配置访问控制的特性。但是通常情况下会采取相反的做法，也就是新创建的特性会自动允许所有用户访问，直到开发人员为其配置了安全检查的功能。

✓在代码中，要避免硬编码基于策略的访问控制检查

通常情况下，访问控制策略是硬编码在应用之中的。这样的话，审计或证明软件的安全性会变得非常困难且耗时。如果可能的话，访问控制策略和应用代码应该分离开来。

✓针对活动编码

在大多数的Web 框架中会将基于角色的访问控制作为主要方法。尽管在访问控制机制中，使用角色是可以接受的，但是在应用代码中针对特定的角色编码是一种反模式。在代码中要考虑用户是不是有权限访问某个特性，而不是检查用户具备什么样的角色。

✓驱动访问控制检查的是服务端的可信数据

在作出访问控制决策的时候，会涉及到很多的数据（登录的用户是谁、这个用户具备什么样的权限、访问控制策略是什么、请求的特性和数据是什么、时间是什么、地理位置是哪里），这些数据应该通过“服务器端”标准的Web 或Web 服