本文目录一览：
- 1、如何解决繁琐的WEB前端的XSS问题
- 2、NodeJS（Express框架）实现 Token 验证免密登录 (一)
- 3、求大神讲讲web安全，nodejs怎么防止跨域攻击和sql注入
- 4、nodejs安全吗
- 5、ecshop 跨站脚本攻击漏洞
- 6、nodejs怎么设置cookie
如何解决繁琐的WEB前端的XSS问题
后台做一层过滤，前台文本编辑器可以自己做一层标签过滤，不允许一些符号的输入就行了
xss攻击前端能做的有限
因为好多都是url转码来通过参数找漏洞，所以后台也要做一层过滤（例如nodejs的sql库就只允许单行sql，防止通过xss做注入）java之类的有现成多xss过滤器
剩下的就做ip黑名单吧，防止多次攻击
NodeJS（Express框架）实现 Token 验证免密登录 (一)
看文章之前，强烈建议先把项目拉取下来！案例来自小弟的开源项目 「项目Github」
文章内容只是个人学习的一些总结经验，不具有权威性，这是 Node 服务端的实现，后面会写前端的实现
常见的 Token 验证方式种:
推荐阅读：
JWT 超详细分析
说一说几种常用的登录认证方式，你用的哪种
推荐阅读：
JSON Web Token 入门教程
JSON Web Token - 在Web应用间安全地传递信息
首先我们先安装 jsonwebtoken 和 express-jwt 这两个中间件
jsonwebtoken : 用于生成 Token 。它也有解析 Token 的功能
express-jwt : 用于解析 Token（比 jsonwebtoken 解决方便） , 它把解析之后的数据，存放到 requset.user 中
如果你看了上面 JWT 介绍的文章，就知道 JWT 是由三部分组成的，分别是 载荷(Payload) 、 头部(Header) 、 签名(Signature) 。
jsonwebtoken 给我们提供了 sign(payload, secretOrPrivateKey, [options, callback]) 方法。sign 方法对应的其实就是 JWT 签名(Signature) 的动作
payload：荷载 ，参数类型：对象secretOrPrivateKey：自定义的密钥，密钥属于敏感信息。参数类型：字符串options：可以配置 header 、荷载、指定算法类型。参数类型：对象callback：回调
眼尖的朋友应该发现， payload 和 options 两个 参数 都可以配置荷，下面有例子。根据自己的习惯选择就好
Payload 部分 JWT 规定了7个官方字段,这些字段都是可选字段。可直接以对象的形式传给 payload 参数。
options 中也可以接受以上七个字段，不过字段名称有所区别。
除此之后 options 提供了 algorithm 和 header ，分别对应使用的加密算法和 JWT 的 Header 部分，其实 algorithm 应该也是属于 Header 部分的。
说了这么多，其实我们一般常用的只有 exp(expiresIn) 和 algorithm 这两个字段，
例子一：
token 的有效时间是配置在 option 里
例子二：
我们也可以在 payload 里配置有效时间
jsonwebtoken 除了生成 token 外，还提供了解析验证 token 的方法， jwt.verify(token, secretOrPublicKey, [options, callback]) 。
这里就不演示了， 感兴趣的朋友可以参考文档： 「JsonWebToken」
express-jwt 是针对 express 框架开发的 JWT Token 验证中间件。我先来简单说以下它的用法。
主要有两种方式，一种是哪些请求需要验证就往哪里加验证；另外一种是先给全部请求加上验证，再给不需要验证的请求配置 白名单 。
方式一：
看完上面的例子，很显然不符合我们的逾期，一个正常的项目有个几十个 api 是分分钟的事。我们不可能一个个给他加上检验
方式二：
这种方式是不是方便很多，而且更美观，维护起来也更方便
Token 解析出来的用户信息，默认存放在 req.user , 可以直接 req.user.userId 来使用生成 Token 时填进去的用户id
你也通过 requestProperty 和 resultProperty 来设置用户信息存放的对象。
这里就不展开，详细文档参考： express-jwt
可以使用 app.use() 来注册处理验证不通过的情况
到这里 Token 的生成、验证、检验不通过错误处理就完成了。 Token 生成一般是在登录之后生成，并返回给前端，前端拿到 Token ,并在每次请求 api 的时候携带上 Token , Token 就相当于这个用户的身份，不要轻易泄露。
Token一旦签发，不能主动让它失效，只能等待它有效期过才能失效。也就是说就算你修改了密码，之前的 Token 也还是有效的。你可以修改后端生成 Token 时使用的密钥，不让之前的 Token 检验通过，但是这就表示之前所有生成 Token 都失效了，做不到针对某个用户进行注销。这显然也不合适的。 所以用户修改密码时，前端一般都要清除之前保存的 Token,再重获取新的 Token
有朋友应该会想到在后端把 Token 储存起来，每一个用户对应一个 token。修改账号时，再生成一个新的 Token 覆盖之前的 Token，但这就违背了使用 Token 的目的，Token 的使用很大程度就为了减少服务器的压力。把尽可能多的信息存储在客户端而不是服务端。
使用 Token 可以防御 CSRF 攻击，之前写过一篇关于网络安全的文章，感兴趣的朋友可以看一下 「XSS 攻击、CSRF 攻击、SQL 注入、流量劫持（DNS 劫持、HTTP 劫持）—— 浏览器安全」
求大神讲讲web安全，nodejs怎么防止跨域攻击和sql注入
是CSRF(Cross-site request forgery) 不是你写的那个!
跨域不用担心.主流浏览器都会帮你做防御的. 问题不大,主要是你自己别给其他域的权限即可.非必要的话,以最小权限原则.
xss主要就是过滤输入输出.如果业务很多,还是找人审计代码吧.或者用比较成熟的模块.CSRF的话,1,验证来源 2加随机token之类的.
sqli主要还是过滤输入的地方.过滤/转义关键字比如select,and,or等等(有专门的防注入模块).觉得怕麻烦的话.用那些云主机的防御功能.再加个cdn基本就没事了.(对于一般的反射型跨站也适用)
nodejs安全吗
安全是不容忽视的，每个开发者都知道它非常重要，真正严肃对待它的却没有几人。我们 RisingStack 希望你能认真对待这一问题——这就是我们整理这份清单来帮助你的原因，你的应用在被成千上万用户使用前必须要做安全检查。
这份清单大部分内容是通用的，不仅适用于Node.js，同样适用于其他语言和框架，只是一些明确给出了在Node.js中使用的方法。同时推荐你去阅读我们的引导文章 Node.js security，如果你刚开始使用Node.js，推荐你看这篇文章 first chapter of Node Hero。
配置管理
HTTP 安全头部
有些关于安全的HTTP头部是你的网站必须要有的：
Strict-Transport-Security 强制将HTTP请求替换为HTTPS请求
X-Frame-Options 防止点击劫持
X-XSS-Protection 开启跨站脚本攻击（XSS）的过滤，大多数现代浏览器支持这个设置
X-Content-Type-Options 禁用浏览器对响应内容MIME类型的嗅探，严格使用响应的Content-Type的值
Content-Security-Policy 能有效防止多种攻击，包括跨站脚本和跨站注入
Node.js开发者可以使用Helmet模块置这些头部，代码如下：
var express = require('express');
var helmet = require('helmet');
var app = express();
app.use(helmet());
Koa和ThinkJS框架中可以使用koa-helmet来设置这些头部，当然有关安全的头部不止这些，更多请看Helmet和MDN HTTP Headers。
在大多数架构里这些头部可以设置在web服务器的配置中（Apache、Nginx），不需要对应用代码进行改动。在Nginx中的配置：
# nginx.conf
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header Content-Security-Policy "default-src 'self'";
有一个完整的Nginx配置文件，帅气的传送门在此。
如果你想快速检查你的网站是否有了所有的必须头部，请使用这个在线检查器。
客户端的敏感数据
当发布前端应用时，确保你的代码里永远不会包含API密码和证书，因为它可以被任何人看到。
没有自动化的方法去检查你在代码里写了敏感数据，但是有两个可以降低向客户端暴露敏感数据风险的方法：
使用 pull requests 提交代码
定期 code review
ecshop 跨站脚本攻击漏洞
这几天刚处理一下360这个提示，方法如下：
ecshop是php语言
PHP的htmlentities()或是htmlspecialchars()。
根据360提示是哪个页面，具体看是get或者post的哪个变量进行输入输出。
举例：
$member_name = htmlentities($member_name);
增加一层这样的过滤后，就会比较安全了。
nodejs怎么设置cookie
var http = require('http');
http.createServer(function (req, res) {
// 获得客户端的Cookie
var Cookies = {};
req.headers.cookie req.headers.cookie.split(';').forEach(function( Cookie ) {
var parts = Cookie.split('=');
Cookies[ parts[ 0 ].trim() ] = ( parts[ 1 ] || '' ).trim();
});
console.log(Cookies)
// 向客户端设置一个Cookie
res.writeHead(200, {
'Set-Cookie': 'myCookie=test',
'Content-Type': 'text/plain'
});
res.end('Hello World\n');
}).listen(8000);
console.log('Server running at ');
如果去掉其中几句，就是官方给出的例子，除了表明返回一个页面多简单外，一点用也没有。
var http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Hello World\n');
}).listen(8000);
console.log('Server running at ');
我们通过http.createServer的回调来处理所有请求与响应，因此什么有用的东西都在它们上面。Cookie位于req对象的headers对象上，为一个字符串，通常为了方便我们将它们转换成一个对象。
写入一个Cookie其实就是在首部设置一个键值对，上面是简单方式，它实际上可以这样：
res.writeHead(200, {
'Set-Cookie': ["aaa=bbb","ccc=ddd","eee=fff"],
'Content-Type': 'text/plain'
});
但真正使用时，我们的Cookie并非这样简单的的格式：
Set-Cookie: =[; =]
[; expires=][; domain=]
[; path=][; secure][; HttpOnly]
console.log('Server running at ');
HttpOnly 属性： 这是微软对Cookie做的扩展。如果在Cookie中设置了"HttpOnly"属性，那么通过程序(JS脚本、Applet等)将无法读取到Cookie信息，这样能有效的防止XSS攻击。
var http = require('http');
http.createServer(function (req, res) {
// 获得客户端的Cookie
var Cookies = {};
req.headers.cookie req.headers.cookie.split(';').forEach(function( Cookie ) {
var parts = Cookie.split('=');
Cookies[ parts[ 0 ].trim() ] = ( parts[ 1 ] || '' ).trim();
});
console.log(Cookies)
// 向客户端设置一个Cookie
res.writeHead(200, {
'Set-Cookie': 'SSID=Ap4GTEq; Expires=Wed, 13-Jan-2021 22:23:01 GMT;HttpOnly ',
'Content-Type': 'text/html'
});
res.end('Hello World\nscriptconsole.log(document.Cookie)/script');
}).listen(8000);
console.log('Server running at ');
然后多刷几次页面，我们发现我们还能在控制台看到SSID=Ap4GTEq这个属性，但在前端我们看不到它（当然在firebug中能看到）。
Secure属性： 当设置为true时，表示创建的 Cookie 会被以安全的形式向服务器传输，也就是只能在 HTTPS 连接中被浏览器传递到服务器端进行会话验证，如果是 HTTP 连接则不会传递该信息，所以不会被窃取到Cookie 的具体内容。同上，在客户端我们也无法在document.Cookie找到被设置了Secure=true的Cookie键值对。Secure属性是防止信息在传递的过程中被监听捕获后信息泄漏，HttpOnly属性的目的是防止程序获取Cookie后进行攻击。我们可以把Secure=true看成比HttpOnly更严格的访问控制。
path属性： 指定可访问Cookie的目录。例如："userId=320; path=/shop";就表示当前Cookie仅能在shop目录下使用。
domain属性： 指定可访问Cookie的主机名.主机名是指同一个域下的不同主机，例如：和gmail.google.com就是两个不同的主机名。默认情况下，一个主机中创建的Cookie在另一个主机下是不能被访问的， 但可以通过domain参数来实现对其的控制，其语法格式为："name=value; domain=CookieDomain";以google为例，要实现跨主机访问，可以写为： "name=value;domain=.google.com";这样，所有google.com下的主机都可以访问该Cookie。
Expires属性：指定过期时间，格式为"name=value;; expires=GMT_String"; 其中GMT_String是以GMT格式表示的时间字符串，超过这个时间，Cookie将消失，不可访问。例如：如果要将Cookie设置为10天后过期，可以这样实现：