后台做一层过滤,前台文本编辑器可以自己做一层标签过滤,不允许一些符号的输入就行了
xss攻击前端能做的有限
因为好多都是url转码来通过参数找漏洞,所以后台也要做一层过滤(例如nodejs的sql库就只允许单行sql,防止通过xss做注入)java之类的有现成多xss过滤器
剩下的就做ip黑名单吧,防止多次攻击
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天后过期,可以这样实现:
是CSRF(Cross-site request forgery) 不是你写的那个!
跨域不用担心.主流浏览器都会帮你做防御的. 问题不大,主要是你自己别给其他域的权限即可.非必要的话,以最小权限原则.
xss主要就是过滤输入输出.如果业务很多,还是找人审计代码吧.或者用比较成熟的模块.CSRF的话,1,验证来源 2加随机token之类的.
sqli主要还是过滤输入的地方.过滤/转义关键字比如select,and,or等等(有专门的防注入模块).觉得怕麻烦的话.用那些云主机的防御功能.再加个cdn基本就没事了.(对于一般的反射型跨站也适用)
安全是不容忽视的,每个开发者都知道它非常重要,真正严肃对待它的却没有几人。我们 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
我来说两句