本文翻译自RisingStack 网站Gergely Nemeth撰写的《 Web Authentication Methods Explained 》一文,感谢 景庄 对该文章的翻译。
安全问题正成为Web应用越来越值得关注的问题。在这之前,我们已经讨论了 Node.js的安全问题列表 。 为了更深入地探讨此类问题,本文将具体谈一谈有关Cookie、Token、以及其他Web认证方法。 本文将从最简单的HTTP基本认证开始谈起,进而会讨论Cookie、Token、签名,以及一次性密码结束。
HTTP基本认证是最简单的一种Web认证方法,它通过在构造请求时提供用户名和密码的方式来提供认证。
之所以说HTTP基本认证是最简单的方法,是因为它不许要借组诸如Cookie,Session,或者其他数据。 如果要使用HTTP基本认证,客户端必须对于每一个构造的请求都要增加Authorization请求头。 用户名和密码可以不加密,但需要按照如下方法进行构造:
举个简单的例子,假如某个用户的用户名为john,密码为secret:
curl --header "Authorization: Basic am9objpzZWNyZXQ=" my-website.com
你可以在Chrome中看到类似的信息:
在Node.js中实现 HTTP基本认证 非常的简单,下面的代码片段展示了如何在Express中使用中间件的方式来实现HTTP基本认证:
import basicAusth from 'basicAuth'; function unauthorized(res) { res.set('WWW-Authenticate', 'Basic realm=Authorization Required'); return res.send(401); } export default function auth(req, res, next) { const {name, pass} = basicAuth(req) || {}; if (!name || !pass) { return unauthorized(res); } if (name === 'john' && pass === 'secret') { return next(); } return unauthorized(res); }
当然,你可以在更高层达到这个目的,例如在 nginx 中进行配置。
缺点
这看起来很简单是不是?那么HTTP基本认证的缺点是什么呢?如下:
对于服务器而言,当它需要对接收到的HTTP请求进行响应时,可以在响应头中添加Set-Cookie头。 浏览器会将该信息存放到一个Cookie容器中,如果设置在CookieHTTP头中的请求源相同的话,那么每次请求都会附带有该Cookie信息。
可以使用Cookie来实现认证,但关键的准则需要遵守:
为了尽可能的避免XSS工具,在设置Cookie时需要始终使用HttpOnly标记。通过这种方式,Cookie将不会在客户端调用document.cookies中显示出来。
通过使用签名的Cookie,可以在服务器端检测Cookie是否在客户端被修改过。
我们这个也可以在Chrome中查看到到这个信息。首先让我们来看看服务器中是如何设置Cookie的:
这之后,所有的请求都使用为指定域设置的cookie(上面设置的域为domain=.linkedin.com;):
如今JWT(JSON Web Token)随处可见——这里仍然有必要看看这其中潜在的安全问题。
我们首先来看下什么是JWT。JWT包括三个部分:
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
在Koa应用中加入JWT只需要几行代码:
var koa = require('koa'); var jwt = require('koa-jwt'); var app = koa(); app.use(jwt({ secret: 'very-secret' })); // protected middleware app.use(function *() { // content of the token will be available on this.state.user this.body = { secret: '42' }; });
示例用法(检查token的有效性或内容,可以使用 jwt.io )
curl --header "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ" my-website.com
正如前面所说的那样,在Chrome中也可以看到tokens的内容:
如果你正在为原声移动应用或者SPA编写API的话,JWT会是一个非常不错的选择。有一点需要记住的是: 在浏览器中使用JWT你需要将它存在LocalStorage或者SessionStorage中,但这可能会导致XSS攻击。
如果要 避免XSS攻击 需要额外的工作。
无论是使用Cookie还是Token,如果某种原因导致你的传输层被暴露的话,你的证书很容易被获取到, 攻击者很容易利用你的Cookie或Token来伪装成你的真实身份。
解决该问题的一个可行方案是对请求进行签名,这里主要讨论的是API而不是浏览器来对请求签名。这是如何工作的呢?
当一个API的某个消费者准备构造请求时它必须提供签名,也就是说它必须使用私钥来对整个请求创建哈希。 对于这个哈希计算你可能会使用到:
为了确保它能够正常工作,API的消费者和创建者都需要拥有相同的私钥。一旦你获得了签名,你需要将它附加到请求中, 可以使用查询字符串,也可以采用HTTP头的形式。当然最好在附加一个日期信息,通过日期来定义签名的过期时间。
AWS请求签名流程
为什么需要经历这些步骤?因为即使传输层被破解,攻击者也只能读取你的流量信息,而不能伪装成你的用户帐号, 如果攻击者没有私钥,攻击者就无法对请求进行签名。绝大部分的AWS服务使用的都是这种认证方法。
node-http-signature 模块提供了对HTTP请求签名的支持。
无法在浏览器或者客户端使用,只能在API之间使用。
一次性密码算法使用一个共享的密钥和当前的时间或者计数器来生成一次性密码:
这些方法可以用在使用双因素认证的应用中:当用户如键入用户密码和密码的时候,在服务器和客户端都会生成一次性密码。
在Node.js中,可以使用 notp 模块来轻松的实现一次性密码。
如果你只是用来支持一个Web应用,使用Cookie或者Token都可以,使用Cookie的时候你需要考虑XSRF, 使用JWT时你需要考虑XSS。如果你需要同时支持Web应用和移动应用,使用支持基于token认证的API。 如果你构建的API会进行彼此通信,使用请求签名。
原文链接: Web Authentication Methods Explained
译者简介: 景庄,前端工程师,关注Node.js、前端工程化。个人博客: http://wwsun.github.com 。
欢迎加入CSDN前端交流群2:465281214,进行前端技术交流。