vlambda博客
学习文章列表

在任何组织中，都有一份可以访问某些服务的人员的严格列表。通常，这些服务的身份验证是通过用户名和密码完成的，但也可以使用密钥来完成验证用户身份 .

无论使用何种身份验证方法，都应始终通过安全通道（例如 SSH）进行通信。

SSH 代表 Secure Shell，它是一个用于访问远程机器中的 shell，但它也可以是一个非常有用的工具来创建代理和隧道来访问远程服务器。

让我们使用以下命令解释它是如何工作的：

/home/david:(develop) x ssh [email protected]
The authenticity of host '192.168.0.1 (192.168.0.1)' can't be established.
RSA key fingerprint is SHA256:S22/A2/eqxSqkS4VfR1BrcDxNX1rmfM1JkZaGhrjMbk.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.1' (RSA) to the list of known hosts.
[email protected]'s password:
Last login: Mon Jan 25 02:30:21 2016 from 10.0.2.2
Welcome to your virtual machine.

在这种情况下，我使用 Vagrant 来促进虚拟机的构建。 Vagrant 是一个非常流行的工具，用于自动化开发环境及其网站（https://www.vagrantup.com/) 包含有用的信息。

在第一行，我们执行 ssh [email protected] 命令。此命令尝试在 192.168.0.1 主机中以用户 david 的身份打开终端。

由于这是第一次对 IP 192.168.0.1 中的机器执行此命令，因此我们的计算机将不信任远程服务器。

这是通过在 /home/david/.ssh/known_hosts 文件夹下维护一个名为 known_hosts 的文件来完成的（在这种情况下）（这将取决于用户）。

此文件是具有相应密钥的主机列表。如您所见，以下两行说明 主机不可信任 并显示远程服务器持有的密钥的指纹，以便验证它：

The authenticity of host '192.168.0.1 (192.168.0.1)' can't be established.
RSA key fingerprint is SHA256:S22/A2/eqxSqkS4VfR1BrcDxNX1rmfM1JkZaGhrjMbk.

此时，用户应该通过检查密钥来验证服务器的身份。完成后，我们可以指示 SSH 连接到服务器，这将导致打印以下日志：

Warning: Permanently added '192.168.0.1' (RSA) to the list of known hosts.

现在，如果我们检查我们的 known_hosts 文件，我们可以看到密钥已添加到列表中， 如下：

known_hosts 文件中存储的这个密钥是远程服务器的公钥。

SSH 使用一种称为 的 密码算法 RSA。该算法围绕非对称加密的概念构建，如图所示在下图中：

非对称密码学依赖于一组密钥：一个公共密钥和一个私有密钥。顾名思义，公钥可以与所有人共享；而私钥必须保密。

用私钥加密的消息只能用公钥解密，反之几乎是不可能的（除非有人拿到另一半密钥）来拦截和解密消息。

此时，我们的计算机知道服务器的公钥，我们可以开始与服务器的加密会话。一旦我们得到终端，所有命令和这些命令的结果都将被加密并通过网络发送。

此密钥也可用于连接到没有密码的远程服务器。我们唯一需要做的就是在我们的机器中生成一个 SSH 密钥，并将其安装在服务器中的 .ssh 下名为 authorized_keys 的文件中 文件夹，known_hosts 文件所在的位置。

在使用微服务时，您可以远程登录到相当多的不同机器上，这样这种方法就变得更有吸引力了。但是，我们需要非常小心处理私钥的方式，因为如果用户泄露该私钥，我们的基础设施可能会受到损害。

正如我们之前所说，安全性是应用程序开发中的一个持续主题。无论您正在构建什么类型的软件，它总会存在安全隐患。

在我的职业生涯中，我发现在不成为全职安全工程师的情况下了解 Web 开发安全的最佳方法是遵循 OWASP 项目。 OWASP 代表 Open Web Application Security Project，他们产生了相当一个有趣的 文档（除其他外），每年称为 OWASP Top 10。

在上一节中，我们确定了软件开发人员可能面临的四个主要安全问题，所有这些问题都将在以下各节中提及。

SELECT * FROM users WHERE username = 'username' AND password = 'password'

var express = require('express');
var app = express();
var mysql      = require('mysql');

var connection = mysql.createConnection({
  host     : 'localhost',
  user     : 'me',
  password : 'secret',
  database : 'test_db'
});

app.get('/login', function(req, res) {
  var username = req.param("username");
  var password = req.param("password");
  
  connection.connect();
  var query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'";
  connection.query(query, function(err, rows, fields) {
    if (err) throw err;
    res.send(rows);
  });
  connection.end();
});

app.listen(3000, function() {
  console.log("Application running in port 3000.");
});

SELECT * FROM users WHERE username = 'david' AND password = 'mypassword'

SELECT * FROM users WHERE username = '' OR 1=1 -- AND password = 'mypassword'

SELECT * FROM users WHERE username='' OR 1=1

app.get('/login', function(req, res) {
  var username = req.param("username");
  var password = req.param("password");
  
  connection.connect();
  var query = "SELECT * FROM users WHERE username = '" + connection.escape(username) + "' AND password = '" + connection.escape(password) + "'";
  connection.query(query, function(err, rows, fields) {
    if (err) throw err;
    res.send(rows);
  });
  connection.end();
});

var mysql = require('mysql');
var connection = mysql.createConnection({
  host: 'localhost',
  username: 'root',
  password: 'root'
});

console.log(connection.escape("' OR 1=1 --"))

Cross-site scripting

跨站脚本，也称为XSS，是一种主要影响Web应用程序的安全漏洞。这是最常见的安全问题之一，对客户的影响可能很大，因为有人可能会通过这种攻击窃取用户身份。

该攻击是一种注入第三方网站的代码，可以从客户端的浏览器中窃取数据。有几种方法可以做到这一点，但到目前为止，最常见的是来自客户端的非转义输入。

在 Internet 上的少数网站中，用户可以添加包含任意输入的评论。这种任意输入可以包含从远程服务器加载 JavaScript 的脚本标签，这些脚本可以窃取会话 cookie（或其他类型的有价值信息），让攻击者在远程计算机上复制用户会话。

XSS 攻击主要有两种 类型：persistent 和 非持久性。

persistent 类型的 XSS 包括通过 制作一个特定的文本字符串，一旦在网站上显示给用户，就会解析为攻击。此代码可以通过存储在数据库中的任意输入文本（例如论坛中的评论）注入。

non-persistent 类型的 XSS 是当攻击插入到由于糟糕的数据处理，应用程序的非持久部分。

让我们看一下下面的截图：

如您所见，我们在 http://www 中搜索了一本书（本书） .amazon.co.uk/。它不会产生任何输出（因为该书尚未出版），但它指定 您的搜索“microservices nodejs”不匹配任何产品 ，它以某种方式使用来自网络浏览器的输入作为输出。更重要的是，当我点击搜索时，亚马逊将我重定向到以下 URL：

http://www.amazon.co.uk/s/ref=nb_sb_noss?url=search-alias%3Daps&field-keywords=microservices+nodejs

我们知道 Amazon 是安全的，但如果它对 XSS 攻击敏感，我们可以修改 field-keywords 参数的值来制作一个在内容，导致攻击者能够窃取会话 cookie，这可能会导致网站出现一些 严重问题。

Output encoding

防止这种攻击的一种方法是输出编码。我们之前做过，当我们在 Input validation 部分使用 connection.escape()本章的。公平地说，我们应该验证用户输入的所有数据并对来自第三方的所有输出进行编码。这包括用户输入的内容，以及来自系统外部的信息来源。

在将问题缩小到 Web 开发时，我们必须了解需要输出编码的三个不同领域：

• CSS

• JavaScript

• HTML

最有问题的两个是 JavaScript 和 HTML，攻击者可以轻松窃取信息而无需太多努力。

通常，无论我们使用哪个框架来构建我们的应用程序，它总是具有对输出进行编码的功能。

<form action="/register" method="post">
  <input name="email" type="text" />
  <input name="password" type="password" />
</form>

<form action="/register" method="post">
  <input name="email" type="text" />
  <input name="password" type="password" />
  <input name="csrftoken" type="hidden" value="as7d6fasd678f5a5sf5asf" />
</form>

减少应用程序中的安全漏洞的最最有效的方法之一是通过系统化和知情的代码审查流程。代码审查的问题在于，它们最终总是成为意见和个人偏好的转储区域，这通常不仅不会提高代码的质量，而且还会导致最后一刻的更改，从而可能暴露我们应用程序中的漏洞。

产品开发生命周期中用于安全代码审查的专门阶段有助于大幅减少交付到生产环境的错误数量。

软件工程师面临的问题是，他们的思维被训练来构建运行良好的东西，但他们没有发现缺陷的心态，尤其是围绕他们构建的东西。这就是为什么你不应该测试你自己的代码（比开发时进行的测试更进一步），更不用说安全测试你的应用程序了。

但是，我们通常在团队中工作，这使我们能够审查其他人的代码，但我们必须以有效的方式进行。

代码审查需要与编写软件一样多的脑力，尤其是在您审查复杂代码时。你不应该花费超过两个小时来审查相同的功能，否则会错过重要的缺陷，并且对细节的关注会降低到令人担忧的程度。

这在基于微服务的架构中不是什么大问题，因为功能应该足够小，以便在合理的时间内阅读，尤其是当您与作者讨论他正在尝试构建的内容时。

您应该始终遵循两阶段审查，如下所示：

此项目列表必须预先确定，并取决于您公司正在构建的软件的性质。

通常，在代码审查期间检查代码安全问题的项目列表非常大，但我们可以将其缩小到以下组件：

如果我们检查此列表，我们将能够确定我们应用程序中最大的安全问题。

Seneca 在日志记录方面非常。在 Seneca 中可以配置很多选项，以便获取有关一切工作方式（如果工作正常）的所需信息。

让我们看看 日志记录如何与一个小型应用程序一起工作：

var seneca = require("seneca")();

seneca.add({cmd: "greeter"}, function(args, callback){
  callback(null, {message: "Hello " + args.name});
});

seneca.act({cmd: "greeter", name: "David"}, function(err, result) {
  console.log(result);
});

这是可以编写的最简单的 Seneca 应用程序。让我们按如下方式运行它：

seneca  node index.js
2016-02-01T09:55:40.962Z 3rhomq69cbe0/1454579740947/84217/- INFO hello Seneca/1.0.0/3rhomq69cbe0/1454579740947/84217/-
{ message: 'Hello David' }

这是使用默认日志记录配置运行应用程序的结果。除了我们在代码中使用的 console.log() 方法之外，还有一些关于 Seneca 被记录的内部信息。有时，您可能只想记录您的应用程序正在生成的内容，以便您可以调试应用程序而不会产生任何噪音。在这种情况下，只需运行以下命令：

seneca  node index.js --seneca.log.quiet
{ message: 'Hello David' }

但是，有时，系统中会出现奇怪的行为（甚至是使用的框架中的错误），而您想要获取有关正在发生的事情的所有信息. Seneca 也支持这一点，如以下命令所示：

seneca  node index.js --seneca.log.print

前面的命令 将打印无穷无尽的信息，这些信息可能没有帮助。

为了减少 Seneca 生成的日志记录量，对记录到输出的内容进行了细粒度控制。让我们看一下以下几行：

2016-02-01T10:00:07.191Z dyy9ixcavqu4/1454580006885/85010/- DEBUG register install transport {exports:[transport/utils]} seneca-8t1dup
2016-02-01T10:00:07.305Z dyy9ixcavqu4/1454580006885/85010/- DEBUG register init seneca-y9os9j
2016-02-01T10:00:07.305Z dyy9ixcavqu4/1454580006885/85010/- DEBUG plugin seneca-y9os9j DEFINE {}
2016-02-01T10:00:07.330Z dyy9ixcavqu4/1454580006885/85010/- DEBUG act root$       IN o5onzziv9i7a/b7dtf6v1u9sq cmd:greeter {cmd:greeter,name:David} ENTRY (mnb89) - - -

它们是来自前面代码示例的日志输出的随机行，但它会为我们提供有用的信息：这些条目是 Seneca 框架上不同操作（例如插件、注册和操作）的调试级日志行。为了过滤它们，Seneca 提供了对我们想要查看的级别或操作的控制。考虑以下示例：

node index.js --seneca.log=level:INFO

这只会输出与 INFO 级别相关的日志：

seneca  node index.js --seneca.log=level:INFO
2016-02-04T10:39:04.685Z q6wnh8qmm1l3/1454582344670/91823/- INFO hello Seneca/1.0.0/q6wnh8qmm1l3/1454582344670/91823/-
{ message: 'Hello David' }

还可以按动作类型过滤，挺有意思的。当您使用微服务时，了解流中发生的事件链是审核故障时需要查看的第一件事。通过 Seneca 为我们提供的对日志记录的控制，只需执行以下命令即可：

node index.js --seneca.log=type:act

这将产生 以下输出：

如您所见，所有 前面的行都对应于 act 类型，甚至更多，如果我们从上到下跟随命令的输出，我们确切地知道 Seneca 反应的事件顺序及其顺序。

跟踪请求也是一项非常重要的活动，有时，它甚至是法律要求，特别是如果您在金融领域工作。同样，Seneca 非常擅长跟踪请求。对于每个呼叫，Seneca 都会生成一个唯一标识符。这个标识符可以在调用的所有路径中被追踪到，如下所示：

var seneca = require("seneca")();

seneca.add({cmd: "greeter"}, function(args, callback){
  console.log(this.fixedargs['tx$']);
  callback(null, {message: "Hello " + args.name});
});
seneca.act({cmd: "greeter", name: "David"}, function(err, result) {
  console.log(this.fixedargs['tx$']);
});

在这里，我们将包含 Seneca 中的事务 ID 的字典记录到终端。因此，如果我们执行它，我们将得到以下输出：

2016-02-04T10:58:07.570Z zl0u7hj3hbeg/1454583487555/95159/- INFO hello Seneca/1.0.0/zl0u7hj3hbeg/1454583487555/95159/-
3jlroj2n91da
3jlroj2n91da

您可以看到 Seneca 中的所有请求是如何被跟踪的：框架分配一个 ID 并跨端点传播。在这种情况下，我们所有的端点都在本地机器上，但是如果我们将它们分布在不同的机器上，ID 仍然是相同的。

有了这个唯一的 ID，我们将能够在我们的系统中重建客户数据的旅程，并且 使用相关的时间戳对请求进行排序，我们 可以准确了解用户在做什么，每个动作花了多少时间，与延迟相关的可能问题是什么，等等。通常，结合断路器输出信息的日志记录允许工程师在非常短的时间内解决问题。

到目前为止，我们一直在使用console.log()将数据输出到日志中。这是一个不好的做法。它破坏了日志的格式并将内容抛出到 标准输出。

再次，塞内卡来救援：

var seneca = require("seneca")();

seneca.add({cmd: "greeter"}, function(args, callback){
  this.log.warn(this.fixedargs['tx$']);
  callback(null, {message: "Hello " + args.name});
});

seneca.act({cmd: "greeter", name: "David"}, function(err, result) {
  this.log.warn(this.fixedargs['tx$']);
});

让我们看看 Seneca 产生了什么输出：

seneca  node index.js
2016-02-04T11:17:28.772Z wo10oa299tub/1454584648758/98550/- INFO hello Seneca/1.0.0/wo10oa299tub/1454584648758/98550/-
2016-02-04T11:17:29.156Z wo10oa299tub/1454584648758/98550/- WARN - - ACT 02jlpyiux70s/9ca086d19x7n cmd:greeter 9ca086d19x7n
2016-02-04T11:17:29.157Z wo10oa299tub/1454584648758/98550/- WARN - - ACT 02jlpyiux70s/9ca086d19x7n cmd:greeter 9ca086d19x7n

如您所见，我们现在使用记录器输出事务 ID。我们生成了 WARN 消息，而不是简单的控制台转储。从现在开始，我们可以使用 Seneca 日志过滤器来隐藏我们操作的输出，以便专注于我们正在尝试查找的内容。

Seneca 提供以下五个级别的日志记录：

产生不同级别的日志的一种方法是使用相关函数。正如我们之前所见，我们调用this.log.warn() 来记录警告。如果我们调用 this.log.fatal() 方法，我们将记录一个致命错误，与其他级别相同。

通常，INFO、DEBUG 和 WARN 将是最常用的日志级别。

HTTP 代码经常被忽略，但它们是标准化远程服务器响应的非常重要的机制。

当 程序（或用户）向服务器发出请求时，可能会发生一些事情，如下所示：

如您所见，可能性是无穷无尽的。我们现在遇到的问题是 HTTP 是为机器之间的通信而创建的。我们如何处理机器将读取这些代码的事实？

HTTP 以一种非常优雅的方式解决了这个问题：每个请求都必须使用 HTTP 代码来解决，并且这些代码具有指示代码性质的范围。