|
伴随着RESTful架构风格的大量应用微服务架构的流行，一些本来难以察觉到的安全问题也逐渐开始显现出来。在我经历过的各种采用RESTful微服务架构风格的应用中，某些安全问题几乎在每个应用中都会出现。然而它们并非是什么高深的技术难题，只不过是借着微服务的流行而显得越发突出，这些都可以通过一些安全实践来避免。本文将一些典型的问题列举出来，希望能引起开发团队的注意，帮助他们绕过这些安全问题的“坑”。 1. 遗漏了对资源从属关系的检查 一个典型的RESTful的URL会用资源名加上资源的ID编号来标识其唯一性，就像这样:/users/<USER ID>，例如：/users/100 一般而言用户只能查看自己的用户信息，而不允许查看其它用户的信息。在这种情况下，攻击者很可能会尝试把这个URL里面的USER ID从100修改为其他数值，以期望应用返回指定用户的信息。不过由于这个安全风险太显而易见，绝大多数应用都会对当前请求者的身份进行校验，看其是否是编号为100的用户，校验成功才返回URL中指定的用户信息，否则会拒绝当前请求。
对于URL中只出现一个资源的情况，绝大多数应用都已经做了安全防御，然而重灾区出现在URL中包含多个资源的时候。 以用户查看订单的RESTful URL为例：/users/100/orders/280010，应用只检查了当前请求发起者是否是编号为100的用户，以及编号为280010的订单是否存在，有很大的概率没有检查URL中的订单和用户之间的从属关系。其结果是，攻击者可以通过修改URL中的订单编号，从而遍历系统中的所有订单信息，甚至对不属于他/她的订单发起操作，例如取消订单。 上面的例子中只有两个资源，如果URL中资源数量继续增加，这种从属关系校验缺失的情况只会更加普遍。 解决这一问题的方法极其简单，只要发现URL里面出现了两个或者两个以上的资源，就像下面这样： /ResourceA/<ResourceA Id>/ResourceB/<ResourceB Id>/ResourceC/<ResourceC Id> 在对资源进行操作之前，就得先检查这些资源之间的从属关系，以确保当前请求具有相关的访问、操作权限。 2. HTTP响应中缺失必要的 Security Headers HTTP中有一些和安全相关的Header，通过对它们的合理使用，可以使得应用在具备更高的安全性的同时，并不会显著增大开发者的工作负担，有着“低成本高收益”的效果。不过绝大多数情况下，这些Header是默认关闭的，直播，因此很多应用中也就缺失了这些Security Headers。一些典型的Security Headers如下：
X-Frame-Options 为了防止应用遭受点击劫持攻击，可以使用X-Frame-Options: DENY明确告知浏览器，不要把当前HTTP响应中的内容在HTML Frame中显示出来。 X-Content-Type-Options 在浏览器收到HTTP响应内容时，它会尝试按照自己的规则去推断响应内容的类型，并根据推断结果执行后续操作，而这可能造成安全问题。例如，一个包含恶意Java代码的HTTP响应内容，虽然其Content-Type为image/png，但是浏览器推断出这是一段脚本并且会执行它。 X-Content-Type-Options就是专门用来解决这个问题的Header。通过将其设置为X-Content-Type-Options: nosniff，浏览器将不再自作主张的推断HTTP响应内容的类型，而是严格按照响应中Content-Type所指定的类型来解析响应内容。 X-XSS-Protection 避免应用出现跨站脚本漏洞（Cross-Site ing，简称XSS）的最佳办法是对输出数据进行正确的编码，不过除此之外，现如今的浏览器也自带了防御XSS的能力。 要开启浏览器的防XSS功能，只需要在HTTP响应中加上这个Header：X-XSS-Protection: 1; mode=block。其中，数字1代表开启浏览器的XSS防御功能，mode=block是告诉浏览器，如果发现有XSS攻击，则直接屏蔽掉当前即将渲染的内容。 Strict-Transport-Security 使用TLS可以保护数据在传输过程中的安全，而在HTTP响应中添加上Strict-Transport-Security这个Header，可以告知浏览器直接发起HTTPS请求，而不再像往常那样，先发送明文的HTTP请求，得到服务器跳转指令后再发送后续的HTTPS请求。并且，一旦浏览器接收到这个Header，那么当它发现数据传输通道不安全的时候，它会直接拒绝进行任何的数据传输，不再允许用户继续通过不安全的传输通道传输数据，以避免信息泄露。 3. 不经意间泄露的业务信息 会说话的ID (责任编辑：本港台直播) |
