当前位置：首页 > AI娱乐 > 正文内容

nginx check status 在Node应用中实施Web认证的四大方法

admin2周前 (06-06)AI娱乐15

本文翻译自网站撰写的《Web 》一文，感谢景庄对该文章的翻译。

安全问题正成为Web应用越来越值得关注的问题。在这之前，我们已经讨论了 Node.js的安全问题列表。为了更深入地探讨此类问题，本文将具体谈一谈有关、Token、以及其他Web认证方法。本文将从最简单的HTTP基本认证开始谈起nginx check status，进而会讨论、Token、签名，以及一次性密码结束。

HTTP基本认证

HTTP基本认证是最简单的一种Web认证方法，它通过在构造请求时提供用户名和密码的方式来提供认证。

之所以说HTTP基本认证是最简单的方法，是因为它不许要借组诸如，，或者其他数据。如果要使用HTTP基本认证，客户端必须对于每一个构造的请求都要增加请求头。用户名和密码可以不加密，但需要按照如下方法进行构造：

举个简单的例子，假如某个用户的用户名为johnnginx check status 在Node应用中实施Web认证的四大方法，密码为：

curl --header "Authorization: Basic am9objpzZWNyZXQ=" my-website.com

你可以在中看到类似的信息：

在Node.js中实现HTTP基本认证非常的简单，下面的代码片段展示了如何在中使用中间件的方式来实现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请求进行响应时nginx check status 在Node应用中实施Web认证的四大方法，可以在响应头中添加Set-头。浏览器会将该信息存放到一个容器中，如果设置在头中的请求源相同的话，那么每次请求都会附带有该信息。

可以使用来实现认证，但关键的准则需要遵守：

1. 始终使用

为了尽可能的避免XSS工具，在设置时需要始终使用标记。通过这种方式，将不会在客户端调用.中显示出来。

2. 始终使用被签名的 ( )

通过使用签名的，可以在服务器端检测是否在客户端被修改过。

我们这个也可以在中查看到到这个信息。首先让我们来看看服务器中是如何设置的：

这之后，所有的请求都使用为指定域设置的（上面设置的域为=.;）：

缺点

如今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

正如前面所说的那样，在中也可以看到的内容：

如果你正在为原声移动应用或者SPA编写API的话，JWT会是一个非常不错的选择。有一点需要记住的是：在浏览器中使用JWT你需要将它存在或者中，但这可能会导致XSS攻击。

缺点

如果要避免XSS攻击需要额外的工作。

签名

无论是使用还是Token，如果某种原因导致你的传输层被暴露的话，你的证书很容易被获取到，攻击者很容易利用你的或Token来伪装成你的真实身份。

解决该问题的一个可行方案是对请求进行签名，这里主要讨论的是API而不是浏览器来对请求签名。这是如何工作的呢？

当一个API的某个消费者准备构造请求时它必须提供签名，也就是说它必须使用私钥来对整个请求创建哈希。对于这个哈希计算你可能会使用到：

为了确保它能够正常工作nginx check status，API的消费者和创建者都需要拥有相同的私钥。一旦你获得了签名nginx check status，你需要将它附加到请求中，可以使用查询字符串，也可以采用HTTP头的形式。当然最好在附加一个日期信息，通过日期来定义签名的过期时间。

为什么需要经历这些步骤？因为即使传输层被破解，攻击者也只能读取你的流量信息，而不能伪装成你的用户帐号，如果攻击者没有私钥，攻击者就无法对请求进行签名。绝大部分的AWS服务使用的都是这种认证方法。

node-http-模块提供了对HTTP请求签名的支持。

缺点

无法在浏览器或者客户端使用，只能在API之间使用。

一次性密码 One-Time

一次性密码算法使用一个共享的密钥和当前的时间或者计数器来生成一次性密码：

这些方法可以用在使用双因素认证的应用中：当用户如键入用户密码和密码的时候，在服务器和客户端都会生成一次性密码。

在Node.js中，可以使用 notp模块来轻松的实现一次性密码。

缺点如何选择Web认证方法

如果你只是用来支持一个Web应用，使用或者Token都可以，使用的时候你需要考虑XSRF，使用JWT时你需要考虑XSS。如果你需要同时支持Web应用和移动应用，使用支持基于token认证的API。如果你构建的API会进行彼此通信，使用请求签名。

译者简介：景庄，前端工程师，关注Node.js、前端工程化。个人博客：。

欢迎加入CSDN前端交流群2：，进行前端技术交流。