如何看待 TJ 宣布退出 Node.js 开发，转向 Go？

Posted 2023-04-19

参考技术A

为了更新最新消息，TJ并没有退出Nodejs世界。他只是在编写系统时切换到go，而koa框架仍在维护、更新和贡献。而以es7为基础的koa v2，正在鞭打这匹马，他非常投入。与此同时，他发布的go项目目前缺乏亮点，没有人关注。我们的要求，非常类似于TJ，也将成为一个网站和一个系统。然后有一种深刻的理解:nodejs和go是不可缺少的，不要对一个世界说再见，而是用另一个世界。因此，告别推特只是一时冲动的一个玩笑。

---

Nodejs和go不能被替换:

1。Go是一种强类型语言，不支持未定义结构的Json。而网络传输，以及网络常用的nosql数据库，都是原生支持Json，从前端到数据库，一直到最后都是Json。这是太方便了。如果你使用go，你需要一个一个地定义结构，这更累人，灵活性也太低了。这真的是在折磨你自己。此外，国外性能测试、网络开发的常规操作:数据库添加和删除、响应HTTP、nodejs和go的性能几乎完全相同。

2。在编写系统时，请访问node . js，不可能与node . js一起编写。除了nodejs之外，go在系统中也比node . js更加开放。所以，你只能用go，你不能用node。Go的语法设计有一些尴尬的地方，在使用时，长期忍受许多问题。就语言本身而言，它不是基于es7所使用的舒适的node。但是在编写系统时，您只能容忍它的性能。在我们看来，基于es7的node是一个非常方便的go语言，但是它只支持单内核

参考技术B

表现性本机并发特性对于开发分布式任务非常有效，即使ES6引入的生成器只满足其需求的一半，node也没有独立的错误处理堆栈。

---

由于工作需要，TJ将参与分布式软件的开发。显然，Go是一个更合适的选择。错误处理一直是JS留下的一个深孔，需要一些时间来填充。TJ不愿意花3年的时间等待节点社区来填补所有的漏洞，也许是表达了他对node社区和核心开发团队的一些“不满”。

就个人而言，稳定的、高性能的、分布式的纯开发背景、交易系统，例如，Go、Java和c++是一个更好的选择，特别为分布式围棋而设计，只是目前的人才较少;对于web工程主要处理前台显示，节点是一个不错的选择，

毕竟性能也是公平的，前端工程师可以“赢者通吃”之前和之后，仍然看涨的节点是未来的前端和后端线。TJ是一种理性的工程师,语言只是工具,工具做什么事情,在他的告别节点文章还说,如果一个web开发或他将使用节点,

但是现在他想分布式系统的发展,所以选择一个更合适的工具golang,也不奇怪,如果你现在是老板突然嵌入式开发你将能够让你不把c和汇编?TJ文章开头说，他已经在node . js中做了很长时间的工作，所以他再次发送了正式的告别node . node社区，顺便说一下，你有兴趣维护他原来的项目吗?

Node.js中的不安全跳转如何防御详解

Node.js中的不安全跳转如何防御详解

导语：

早年在浏览器大战期间，有远见的Chrome认为要运行现代Web应用，浏览器必须有一个性能非常强劲的Java引擎，于是Google自己开发了一个高性能的开源的Java引擎，名字叫V8。在2009年，Ryan正式推出了基于Java语言和V8引擎的开源Web服务器项目，命名为Node.js。

对于任何web开发人员来说，不安全或未经验证的重定向都是重要的安全考虑因素。Express为重定向提供了本地支持，使它们易于实现和使用。Express是一种保持最低程度规模的灵活Node.js Web应用程序框架，为Web和移动应用程序提供一组强大的

什么是不安全的重定向？

对于任何web开发人员来说，不安全或未经验证的重定向都是重要的安全考虑因素。Express为重定向提供了本地支持，使它们易于实现和使用。然而，Express将执行输入验证的工作留给了开发人员。Express是一种保持最低程度规模的灵活Node.js Web应用程序框架，为Web和移动应用程序提供一组强大的功能。

下面是OWASP.org网站给出的“未经验证的重定向和转发”的定义:

如果web应用程序接受不可信的输入，可能导致web应用程序将请求重定向到不可信输入中包含的URL，则可以进行未经验证的重定向和转发。

重定向通常在登录和身份验证过程中使用，因此可以在登录之前将用户重定向到他们所在的页面。但根据业务需求或应用程序类型而有所不同，也存在其他重定向情况。

为什么要避免重定向？

不验证用户输入的重定向，可以使攻击者具备发起网络钓鱼诈骗的条件，从而窃取用户凭据并执行其他恶意操作。

注意：当在Node.js或Express中实现重定向时，在服务器端执行输入验证很重要。

如果攻击者发现用户没有验证外部用户提供的输入，他们可能会利用这个漏洞在论坛、社交媒体和其他公共场所发布专门设计的链接，让用户点击它。

从表面上看，这些URL看起来合法且对用户来说并无威胁，这是因为所有这些要重定向的URL都包含目标的主机名：

https://example.com/login?url=http://examp1e.com/bad/things

但是，如果服务器端重定向逻辑未验证输入url参数的数据，则用户可能最终会访问黑客所提前设置的网站（examp1e.com），满足攻击的需求！以上只是攻击者如何利用不安全重定向逻辑的一个例子。

不安全重定向例子并将其直接传递到Express res.redirect()方法中。因此，只要用户通过身份验证，Express就会将用户重定向到输入或提供的URL。

var express = require(‘express‘);
var port = process.env.PORT || 3000;
var app = express();
app.get(‘/login‘, function (req, res, next) {
if(req.session.isAuthenticated()) {
res.redirect(req.query.url);
}
});
app.get(‘/account‘, function (req, res, next) {
res.send(‘Account page‘);
});
app.get(‘/profile‘, function (req, res, next) {
res.send(‘Profile page‘);
});
app.listen(port, function() {
console.log(‘Server listening on port ‘ + port);
});

输入验证有助于防止不安全的重定向

通常，最好避免在代码中使用重定向和转发。如果你一定需要在代码中使用重定向，则首选的方法是使用映射到特定目标的预定义输入，这被称为白名单方法。以下就是实现这种方法的一个具体样本步骤：

1.baseHostname会确保任何重定向都将用户保留在研究人员的主机上；

2.redirectMapping是一个对象，它将预定义的输入（例如，传递给url paramer的内容）映射到服务器上的特定路径；

3.validateRedirect()方法会判断预定义的输入是否存在，如果它们存在，则返回要重定向的适当路径；

4.研究人员修改了/login逻辑，然后将baseHostname+redirectPath变量连接在一起，这就避免了任何用户提供的输入内容直接传递到Express res.redirect()方法中；

5.最后，研究人员使用encodeURI()方法作为额外的安全保证，确保连接字符串的URI部分被正确编码，以允许干净的重定向。

//Configure your whitelist
var baseHostname = "https://example.com";
var redirectMapping = {
‘account‘: ‘/account‘,
‘profile‘: ‘/profile‘
}
//Create a function to validate whitelist
function validateRedirect(key) {
if(key in redirectMapping) {
return redirectMapping[key];
}else{
return false;
}
}
app.get(‘/login‘, function (req, res, next) {
if(req.session.isAuthenticated()) {
redirectPath = validateRedirect(req.query.url);
if(redirectPath) {
res.redirect(encodeURI(baseHostname + redirectPath));
}else{
res.send(‘Not a valid redirect!‘);
}
}
});

其他重定向场景

在某些情况下，将每个组合列入白名单是不切实际的，不过有些安全平台仍然希望重定向用户并将其保留在域内某些边界内。当外部提供的值遵循特定模式（例如16个字符的字母数字字符串）时，最好这样做。字母数字字符串是理想的，因为它们不包含任何可能引入其他攻击的特殊字符，例如目录/路径遍历（依赖于诸如…和向后/向前斜杠之类的字符）。

例如，安全平台可能希望在用户登录后将其重定向回电子商务网站上的特定产品。由于电子商务网站对每种产品都有唯一的字母数字值，因此安全平台可以通过始终根据RegEx白名单验证外部输入来实现安全重定向。在本文所讲的样本在，研究者用的是productId变量。

//Configure your whitelist
var baseHostname = "https://example.com";
app.get(‘/login‘, function (req, res, next) {
productId = (req.query.productId || ‘‘);
whitelistRegEx = /^[a-zA-Z0-9]{16}$/;
if(productId) {
//Validate the productId is alphanumeric and exactly 16 characters
if(whitelistRegEx.test(productId)) {
res.redirect(encodeURI(baseHostname + ‘/item/‘ + productId));
}else{
//The productId did not meet the RegEx whitelist, so return an error
res.send(‘Invalid product ID‘);
}
}else{
//No productId was provided, so redirect to home page
res.redirect(‘/‘);
}
});

最后，安全平台发出警告，警告用户他们正在被自动重定向是值得重视的。如果安全平台有意将用户重定向到域外，则可能需要在流程中创建一个中间页面，该页面会发出如下警告，并包含用户要重定向到的URL。

 

注：本文是以Hailstone为例进行讲解的，Hailstone是一个应用程序安全平台，它有查找代码中的漏洞功能。

本文翻译自：https://blog.hailstone.io/how-to-prevent-unsafe-redirects-in-node-js

同步发布：  https://www.geek-share.com/detail/2751082347.html