cat urls.txt | xargs -I{} wget "{}"
# Assuming urls are clean i.e. they don't have any extra parameters in the end
# if the url is like this : https://storage.googleapis.com/workbox-cdn/releases/5.1.2/workbox-cacheable-response.prod.js?v=123122
# Then you need to cut the part after '?' like the following
cat urls.txt | cut -d"?" -f1 | xargs -I{} wget "{}"

registry=https://registry_link_here
//registry_link_here/:_authToken=auth_token_here​

于是，我就尝试用以下 .npmrc格式来测试：

registry=https://registry.npmjs.org
//registry.npmjs.org/:_authToken=auth_token_here​

测试第一天-在该利用方式中，如果NPM_TOKEN有效的话，执行npm whoami命令，会收到响应。但很可惜，没有任何响应。另外，有一些文章说 .npmrc格式中的NPM_TOKEN是加密串。

测试第二天-工作到家将近晚上8点了，我又继续测试这个NPM_TOKEN。我想到在年初我读了一些跨站WebSocket劫持(CSWH)的文章，Cross Site Websocket Hijacking，所以我结合其进行了一些分析。CSWH利用的条件是，websocket只使用cookie进行通信交流，这有点像跨站请求伪造（CSRF）攻击。在BURP练习中对CSWH也有所涉及：

接着，我想看看能不能在前述获得的JS脚本中发现一些websocket信息，但一无所获。之后，我从中发现了客户端请求时，服务端产生分配的一个nonce值，经测试发现可以用它实现CSRF攻击，就这样在寻找CSWH漏洞的过程中发现了CSRF漏洞。于是我进行了上报，在另外的博文中我会作讲解。

测试第三天-经过两小时的分析，我发现其中一个JS脚本文件有点意思，可以用以下三步操作使其代码规则化。Firefox下的代码规则化：

Chrome下的代码规则化：

该文件将近有17k数量的行数，大多是webpack类代码，经过仔细分析，在其中又发现了一个NPM_TOKEN值：

并且，在其附近还存在一个私有注册链接（private registry link）：

我就想，那这个注册链接会不会是其私有仓库的链接呢，于是，我就加入了发现的NPM_TOKEN值，用下.npmrc方法进行了请求：

registry=https://private_registry_link_here
//private_registry_link_here/:_authToken=auth_token_here

执行npm whoami命令，竟然有了成功响应：srv-npm-registry-ci。

然后，我想列出它的所有NPM包信息，不行。于是，我在其JS文件中的打包信息中发现了一些私有仓库的线索，如以下这个：

因此，我用下述命令对其私有仓库进行了请求：

npm view private_repo
npm get private_repo

响应如下：

使用这种方法，我可以下载一些目标项目的私有仓库，从中发现了一些配置类JS脚本和大量的源代码。开发者在项目中明显未做权限设置。没有做深入测试，我就把漏洞上报了。漏洞在当天就被分类处理了，7天之后，我收到了$8000的奖励。

总结

1、可以从一些JS脚本文件中发现隐藏信息；
2、要学会使用浏览器的开发者工具，它们的功能超乎想像；
3、保持测试工具更新；
4、坚持不懈是关键。

参考来源：

medium