[译] Martin Fowler - Web 应用安全基础

为了便于分析这个漫画所要表达的含义，我们假设这个成绩追踪系统有一个用于增加新的学生信息的函数：

void addStudent(String lastName, String firstName) {
        String query = "INSERT INTO students (last_name, first_name) VALUES (""
                + lastName + "", "" + firstName + "")";
        getConnection().createStatement().execute(query);
}

如果输入的参数是"Fowler"与"Martin"，那么最终构造出的SQL语句为：

INSERT INTO students (last_name, first_name) VALUES ("Fowler", "Martin")

不过如果输入的是上面那娃的名字，那么整个待执行的SQL语句就变成了：

INSERT INTO students (last_name, first_name) VALUES ("XKCD", "Robert’); DROP TABLE Students;-- ")

实际上，这个SQL语句一共执行了两个操作：

INSERT INTO students (last_name, first_name) VALUES ("XKCD", "Robert")

DROP TABLE Students

最后的--注释是为了屏蔽余下的内容，保证整个SQL语句能够稳定执行。类似于这样的攻击载荷能够执行任意的SQL语句，换言之，攻击者能够在数据库内像这个应用系统一样做任何事情。

对于上文描述的这种场景，如果只是依赖于简单的清洗过滤，肯定无法应付所有的攻击载荷，这也不是一个正道。基本上能够采取的方法就是所谓的参数绑定，譬如JDBC中提供的PreparedStatement.setXXX()方法，参数绑定可以将像SQL这样的可执行代码与需要进行编码、过滤的内容区分开来：

void addStudent(String lastName, String firstName) {
        PreparedStatement stmt = getConnection().prepareStatement("INSERT INTO students (last_name, first_name) VALUES (?, ?)");
        stmt.setString(1, lastName);
        stmt.setString(2, firstName);
        stmt.execute();
 }

一般来说，一个功能比较全面地数据访问层都会提供这种参数绑定的功能，开发者在开发的时候就要注意将所有的不受信任的输入通过参数绑定生成SQL语句。

有时候我们开发时会遇到一个两难的问题，即是好的安全性与干净整洁的代码之间的冲突。为了保证安全性往往需要我们增加些额外的代码，不过在上面的例子中我们还是同时达成了较高的安全性与好的代码设计。使用绑定的参数不仅能使应用系统免于注入攻击，还能通过在代码与内容之间构建清晰的边界来增加整个代码的可读性，并且与手动拼接相比还能大大简化构造可用的SQL的过程。当你用参数绑定来代替原本的格式化字符串或者字符串拼接来构造SQL的时候，你会发现还能用全局的绑定方程来完成这一工作，这又会大大增加整个代码的整洁度与安全性。

有一个常见的错误思维就是觉得存储过程能够避免SQL注入攻击，但是这个只有在你是通过参数绑定的方式传入参数的情况下。如果存储过程本身也是用的字符串连接的方式，那么同样存在SQL注入攻击的风险。类似的，像ActiveRecord、Hibernate或者.Net Entity这样的框架，也是只有在用参数绑定来构造SQL的情况下才会进行SQL注入清洗。

最后，还有一个常见的错觉就是NoSQL数据库不会被SQL注入攻击影响。这肯定是不对的，所有的查询语言，无论是不是SQL都需要在可执行代码与输入的内容之间划定明晰的边界来防止参数混淆可执行的命令。攻击者会不停寻找能够在运行时打破这种边界隔离的方法从而进行潜在的攻击。即使是Mongodb，采用了二进制的协议与多种语言特定的API都会存在被注入的风险，譬如$where这个操作符。

避免直接从用户的输入中构建出SQL或者等价的NoSQL查询语句

在查询语句与存储过程中都使用参数绑定

尽可能使用框架提供好的原生的绑定方法而不是用你自己的编码方法

不要觉得存储过程或者ORM框架可以帮到你，你还是需要手动调用存储过程

NoSQL 也存在着注入的危险

当我们着眼于系统的输入输出的时候，还有另一个重要的店需要考虑进去，就是传输过程中数据的保密性与完整性。在使用原始的HTTP连接的时候，因为服务器与用户之间是直接进行的明文传输，导致了用户面临着很多的风险与威胁。攻击者可以用中间人攻击来轻易的截获或者篡改传输的数据。攻击者想要做些什么并没有任何的限制，包括窃取用户的Session信息、注入有害的代码等，乃至于修改用户传送至服务器的数据。

我们并不能替用户选择所使用的网络，他们很有可能使用一个开放的，任何人都可以窃听的网络，譬如一个咖啡馆或者机场里面的开放WiFi网络。普通的用户很有可能被欺骗地随便连上一个叫免费热点的网络，或者使用一个可以随便被插入广告的网路当中。如果攻击者会窃听或者篡改网路中的数据，那么用户与服务器交换的数据就好不可信了，幸好我们还可以使用HTTPS来保证传输的安全性。

HTTPS最早主要用于类似于经融这样的安全要求较高的敏感网络，不过现在日渐被各种各样的网站锁使用，譬如我们常用的社交网络或者搜索引擎。HTTPS协议使用的是TLS协议，一个优于SSL协议的标准来保障通信安全。只要配置与使用得当，就能有效抵御窃听与篡改，从而有效保护我们将要去访问的网站。用更加技术化的方式说，HTTPS能够有效保障数据机密性与完整性，并且能够完成用户端与客户端的双重验证。

随着面临的风险日渐增多，我们应该将所有的网络数据当做敏感数据并且进行加密传输。已经有很多的浏览器厂商宣称要废弃所有的非HTTPS的请求，乃至于当用户访问非HTTPS的网站的时候给出明确的提示。很多基于HTTP/2的实现都只支持基于TLS的通信，所以我们现在更应当在全部地方使用HTTPS。

目前如果要大范围推广使用HTTPS还是有一些障碍的，在一个很长的时间范围内使用HTTPS会被认为造成很多的计算资源的浪费，不过随着现代硬件与浏览器的发展，这点计算资源已经不足为道。早期的SSL协议与TLS协议只支持一个IP地址分配一个整数，不过现在这种限制所谓的SNI的协议扩展来解决。另外，从一个证书认证机构获取证书也会打消一些用户使用HTTPS的念头，不过下面我们介绍的像Let"s Encrypt这样的免费的服务就可以打破这种障碍。

对于网站的安全认证依赖于TLS的底层的支持，如果客户端只是根据网站说它自己是谁就是谁，那么攻击者可以轻易的使用中间人攻击来模拟站点，从而绕过所有协议提供的安全机制。在使用了TLS协议之后，一个网站可以用它的公钥证书来证明它自己是谁。在某些系统中客户端也需要用公钥证书证明自己是谁，不过大部分情况下受限于为用户管理证书的复杂性，这个并没有广泛使用。除非一个网站证书的真实性已经经过了验证，不然客户端在收到一个证书的时候也要通过一定的手段来验证证书的真实性。而在Web浏览器或者其他的应用中，往往是通过一个第三方的称作CA的机构来管理证书并且提供验证功能，包括验证这个证书与证书所属网站的真实性。

如果我们通过其他渠道已经能够提前得知某个证书是否可信，那也就没必要再经过第三方机构进行仲裁。譬如一个移动APP或者其他应用在分发的时候就会内置一些证书从而在使用时来验证站点是否真实可信。大部分关于HTTPS是否可信的指示会在浏览器访问某个HTTPS的站点的时候显示出来，如果没有的话浏览器会显示一个告警信息来警告用户不要访问不可信的站点。

在测试的时候我们可以自己创建配置一个证书用于HTTPS认证，不过如果你要提供服务给普通用户使用，那么还是需要从可信的第三方CA机构来获取可信的证书。对于很多开发者而言，一个免费的CA证书是个不错的选择。当你搜索CA的时候，你可能会遇到几个不同等级的证书。最常见的就是Domain Validation(DV)，用于认证一个域名的所有者。再往上就是所谓的Organization Validation(OV)与Extended Validation(EV)，包括了验证这些证书的请求机构的信息。虽然高级别的证书需要额外的消耗，不过还是很值得的。

当你申请到了证书之后，你就可以开始配置你的服务器支持HTTPS了。虽然HTTPS啊，包括TLS/SSL的原理好像要个密码学的PHD学位才能理解，但是要把他们配置着用起来还是很容易的呦。不同的加密算法与站点使用的协议的版本差异会大大影响到它能够提供的通信的安全级别。所以咋才能一方面保证我们站点的安全性另一方面又保证那些使用老版本的浏览器的用户也能正常使用网站服务呢？这里要推荐下Mozilla提供的Security/Server Side TLS工具，可以协助来自动创建适用的Web服务器的配置。

现在我们经常碰到一些网站仅仅只用HTTPS来保护部分资源，有些情况下只会保护一些对于敏感资源的提交操作。另一些情况下，部分网站只会将HTTPS用于自认为敏感的资源上，譬如一个用户登录之后才能见到的东西往往是HTTPS加密的。而现在的麻烦事还有很多站点并未使用HTTPS来保护自己，导致整个网站还处于被中间人攻击的危险之下。笔者很是建议这类网站应该直接关闭掉HTTP端口从而强制性让用户转到HTTPS，虽然这并不是一个理想的解决方案，不过估计是最好的解决方法。

如果是在Web浏览器中呈现的资源，那可以添加一个HTTP请求转发的配置，来将所有的HTTP请求转发到HTTPS端口上，譬如：

# Redirect requests to /content to use HTTPS (mod_rewrite is required)
RewriteEngine On
RewriteCond %{HTTPS} != on [NC]
RewriteCond %{REQUEST_URI} ^/content(/.*)?
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [R,L]

让用户从HTTP迁移到HTTPS可以来避免使用原始的HTTP请求带来的风险。为了帮助站点把用户从HTTP迁移到HTTPS，现代的浏览器支持一个非常强力的安全特征叫做HSTS(HTTP Strict Transport Security)，来告诉浏览器我这个站点只会接收来自于HTTPS的请求。这个特性最早来自于2009年的Moxie Marlinspike"s提出的一个用于演示基于HTTP的潜在危险的SSL剥离攻击。可以用如下的设置来启用这个特性:

Strict-Transport-Security: max-age=15768000

上述的设置会告诉浏览器只和使用HTTPS的站点进行交互，HSTS是一个非常重要的强制使用HTTPS的特性。一旦开启之后，浏览器会自动把不安全的HTTP请求切换到HTTPS，尽管用户没有显式的输入"https://"。而在浏览器端开启HSTS特性只需要添加如下的一行代码：

    ...

    # HSTS (mod_headers is required) (15768000 seconds = 6 months)
    Header always set Strict-Transport-Security "max-age=15768000"

不过现在并不是所有的浏览器都支持HSTS特性，你可以通过访问 Can I use. 来看看你面向的用户常用的浏览器能不能使用。

浏览器目前有内建的安全机制来避免包含敏感信息的Cookie暴露出来。在Cookie中设置secure标识位能够强制让浏览器只会用HTTPS来传递Cookie，如果你已经使用了HSTS也要记得这样设置来保护Cookie。

即使你全站都用了HTTPS，也还是有几个地方可能导致敏感信息的泄露的。譬如如果你直接把敏感数据放在URL里面，然后这个敏感的URL又被缓存在了浏览器的历史记录里。除此之后，如果包含了敏感信息的站点被链接到了其他的网站中，那么在用户点击链接之后整个敏感数据就会被放在Referer Header中然后传送过去，然后就呵呵了。另外，有时候因为大家都懂的原因我们会使用一些代理然后允许他们监控HTTPS的流量，也是有危险地，这个时候就要在Header中来关闭缓存从而降低风险。笔者建议你可以参考OWASP Transport Protection Layer Cheat Sheet 来收获一些有用的建议。

最后一步，你要仔细验证你的配置是否有效。有很多的在线工具可以帮你做这件事，譬如SSL Lab的SSL Server Test能够帮你深度分析你的HTTPS的配置，再看看是不是有啥地方配错了。这个工具会在发现了新的攻击手段与协议更新之后实时更新，所以多用用它还是个很不错的事情嗷。

啥地方都要用HTTPS

采用HSTS来强制使用HTTPS

别忘了从可信的证书机构中请求可信证书

不要乱放你的私钥

用合理的配置工具来生成可靠地HTTPS配置

在Cookie中设置"secure"标识

不要把敏感的数据放在URL中

隔一段时间就要好好看看你的HTTPS的配置，表过时了