什么是 OS 命令注入
上周我们分享了一篇 《Web 安全漏洞之 SQL 注入》，其原理简单来说就是因为 SQL 是一种结构化字符串语言，攻击者利用可以随意构造语句的漏洞构造了开发者意料之外的语句。而今天要讲的 OS 命令注入其实原理和 SQL 注入是类似的，只是场景不一样而已。OS 注入攻击是指程序提供了直接执行 Shell 命令的函数的场景，当攻击者不合理使用，且开发者对用户参数未考虑安全因素的话，就会执行恶意的命令调用，被攻击者利用。
Web 安全漏洞之 SQL 注入
你不知道的 npm init
前言
在现代新建一个 JS 相关的项目往往都是从 package.json 文件开始的，不过这个文件里需要的字段实在是太多了，正常人都记不住，所以 npm 官方提供了 npm init 命令帮助我们快速初始化 package.json 文件。执行之后会有一个交互式的命令行让你输入需要的字段值，当然如果你想直接使用默认值，也可以使用 npm init -y 来超速初始化。
WEB安全漏洞之CSRF
什么是 CSRF
在了解 CSRF 之前我们需要科普两个前提。首先是登录权限验证的方式有很多种，目前绝大多数网站采用的还是 session 会话任务的方式。session 机制简单的来说就是服务端使用一个键值对记录登录信息，同时在 cookie 中将 session id（即刚才说的键）存储到 cookie 中。另外我们又知道浏览器中 HTTP(s) 请求是会自动帮我们把 cookie 带上传给服务端的。这样在每次请求的时候通过 cookie 获取 session id，然后通过它在服务端获取登录信息即可完成用户权限的校验。
75CDN 增加 ES Module 支持
75CDN 是一个由奇舞团维护的静态资源托管平台，创立至今已经稳定运行了两年多的时间。近期我们增加了 ES Module 的支持，成为国内首个拥抱 ES Module 服务的静态资源库。
ES Module 是 ES6 中提出的规范，用于让 JavaScript 实现 import 导入模块的功能。其又细分为静态 import 和动态 import 两个特性，目前浏览器的支持情况如下：
| 浏览器 | 静态 import | 动态 import |
|---------------------|-------------|-------------|
| Chrome | 61+ | 63+ |
| Chrome For Android | 67+ | 67+ |
| Firefox | 60+ | 不支持 |
| Firefox For Android | 60+ | 不支持 |
| Safari | 10.1+ | 11.1+ |
| iOS Safari | 10.3 | 11.2+ |
| Edge | 16+ | 不支持 |注： 数据来源于 CanIUse
Web安全漏洞之SSRF
什么是 SSRF
大家使用的服务中或多或少是不是都有以下的功能：
- 通过 URL 地址分享内容
- 通过 URL 地址把原地址的网页内容调优使其适合手机屏幕浏览，即所谓的转码功能
- 通过 URL 地址翻译对应文本的内容，即类似 Google 的翻译网页功能
- 通过 URL 地址加载或下载图片，即类似图片抓取功能
- 以及图片、文章抓取收藏功能
简单的来说就是通过 URL 抓取其它服务器上数据然后做对应的操作的功能。以 ThinkJS 代码为例，我们的实现方法大概如下：
const request = require('request-promise-native');
module.exports = class extends think.Controller {
async indexAction() {
const { url } = this.get();
const ret = await request.get(url);
// 这里是处理抓取数据的逻辑
// ...
this.ctx.body = ret;
}
}本来是个不错的功能，但是当用户输入一个服务器可访问的内网地址，这个情况下它就会把内网的内容抓取出来展现给外网的用户。大多数公司会在内网中放置一些与公司相关的资料和关键数据，如果应用程序对用户提供的URL和远端服务器返回的信息没有进行合适的验证和过滤，就可能存在这种服务端请求伪造的缺陷，即 Server-Side Request Forgery，简称 SSRF。
小程序开发工具强制 Git 提交
遇到的问题
在小程序开发过程中，代码提交突然变成了一件非常头疼的事情。因为小程序的开发、编译、预览到最后的上传发布过程中，任何一步其实都和 Git 没有任何关系。所以之前自己一个人开发的时候，经常性的就忘记了 commit 代码，亦或是 commit 了但是没有对远端进行 push 操作。一个人开发的时候还好，多个人开发的时候再是这种操作习惯可就要把人坑惨了。
另外还有一个问题是，小程序的发布对 Git 没有强相关，所以对代码分支的要求不高。一般说来，日常的 Web 开发中，我们都是在 dev 或者 feature/xxx 分支中进行开发，test 分支进行测试，最后 master 分支合并后上线。能够严格的执行这个过程的最重要的原因是因为我们的发布系统只支持从主分支上拉取代码，强制让大家养成了良好的习惯。但是小程序中没有这种强相关，所以会经常导致主分支不是最新的版本，而可能是某个其它分支才是线上最新代码。长久以往下去，可能没有同学能够清楚最新的代码是在哪个分支了，一不小心就把分支给删除了也有可能。
使用 ndb 调试你的 Node.js 项目
代码调试按照调试方式大致分为日志（Log）和断点（Breakpoint）两种办法。其中日志就是手动的在代码中增加日志打印获取过程信息来判断问题。这种方法的好处是调试简单，一个对业务熟练的工程师通过线上良好的日志记录可以非常快的发现业务问题。但是它的缺点也非常明显，获取的内容比较单一，动态调试需要不断的在业务中增加日志打印代码。
于是乎断点调试出现了。断点调试类似于中医的望闻问切，我们通过在需要观察的点打上断点就能详细的获取到程序运行到该点时的所有上下文，并利用单步调试逐一观察程序运行状况，准确判断出问题的地方。另外利用 Chrome DevTool 我们也可以随时对线上业务进行调试，可以说是非常方便了。
初探 Gitlab CI
公司内部使用的是 Gitlab 仓库套件管理项目代码，之前把玩过的 Drone CI 是可以很好的支持 Gitlab 的，前提是需要在 Gitlab 中申请一个管理员权限的密钥方便其读取项目目录并设置 Webhook 等操作。而公司的 Gitlab 仓库权限管理很严格，我暂时还没有权限申请这个就只能放弃了。最近他们使用 Gitlab 8 （不要问我为什么是这么早的版本毕竟我们一直都在用7的）搭建了一个新的仓库，自带支持了 Gitlab CI 的功能，于是就拿来试了下。
Gitlab CI 整个流程和 Drone 以及流行的 Travis CI 都是比较类似的，通过在项目中添加一个 .gitlab-ci.yml 的配置文件，配置文件中描述构建流水线来执行任务。有的同学说为什么不试试 Jenkins，那 Jenkins 的配置那么的复杂反正我是拒绝的。
记一次换行引发的血案
话说最近真是流年不利，感觉各种BUG犹如天灾一样全部冒出来了，这不昨天又解了一个非常无语的问题，大概是关于换行和正则的臭虫，下面给大家吐槽一下。
数据“野”了
昨天同事反馈某个页面的数据没有正常显示，最开始我还以为是接口没有返回数据，结果看了下请求发现接口有正常的数据呀。没办法就一路反查回去，最后查到居然代码里接口请求抛错了？！因为定义了 Promise 的 catch 流程，所以也没有把错误抛出来。因为之前这个页面都是正常的，很久都没有改动所以我第一反应是这个数据异常了，查了半天的数据格式问题。可是问题就在于明明看到数据是正常的呀，服务端没有报错，接口数据也是可以正常解析的。最后我突然想起来，我们的接口是 JSONP 的会不会是 JSONP 功能挂了？查了一下果然是这样。
