本文目录一览:
- 1、nodejs安全吗
- 2、如何评价 *** UED 的 Midway Framework 前后端分离
- 3、 *** 安全到底是做什么的?有哪些工作?
- 4、如何解决繁琐的WEB前端的XSS问题
- 5、nodejs怎么设置cookie
- 6、求大神讲讲web安全,nodejs怎么防止跨域攻击和sql注入
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和Think *** 框架中可以使用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
如何评价 *** UED 的 Midway Framework 前后端分离
【贺师俊的回答(17票)】:
泻药。
1. 这系列文章写得很好。
【注意,熟悉我的同志应该知道,我极少给出“很好”的评价。】
2. 这系列文章以及其背后的实践重新树立了 *** 系前端工程水准的领先地位。
【在此之前的一段时间内,至少从外部来看, *** 已经落后于狼系和企鹅系了。】
3. 这系列文章及其背后的实践也证明了nodejs对于前端来说不仅在工具链而且在架构层面的意义。
【注意,这系列文章中的思路其实并不新鲜,但是在 *** 这样规模而且业已非常成熟的产品中实施这样的转变,我认为是具有标志意义的。】
4. 具体细节上仍有许多改善空间,如此系列的第4篇《前后端分离的思考与实践(四)》在防御XSS时还是存在一些传统问题。这方面在参加杭 *** 的时候,我跟 *** 的herman同学有过沟通,具体就不在本问题展开了。因为这是局部问题,对整体架构影响不大。
5. 注意,以上评价的都是架构,或者说是思路。实施效果是不是好,我相信他们自己的说法。但Midway框架本身因为没有看到具体文档和代码,而且其开发的目的首要是满足 *** 的需求,因此其本身或其具体组件是否在普遍意义上适用和优秀,无法作出判断。
【徐飞的回答(19票)】:
早上看到贺老出马,也忍不住写了一篇来谈一下苏宁这样的公司对这方面的考虑。
近两年来,我一直在思考如何改进前端体系的开发模式,这里面最基础的一点就是前后端的分离。谈到前后端分离,也有一个误区,认为仅仅是以浏览器作分界,把这两部分的代码分离出来。但其实是,做这件事情的本意,是要解决开发模式的问题,也就是要分离前后端开发人员的职责。
针对不同类型的Web产品,这个分离方式是有所不同的。对于Web应用,因为它跟服务端的交互基本就是AJAX或者WebSocket接口,所以这个分离是天然的,整个前端基本都是静态HTML模板,JavaScript模块,以及CSS和相关静态资源,但是对于 *** 产品这样的形态,它的做法就不一样。
## 展示占主要部分的产品
*** 产品的展示需求很重要,图片等资源载入非常多,但相对的操作却很少,基本只有搜索商品,加购物车,结算这样的环节。传统这样的产品,多半是这么个工作流程:
交互出高保真图,前端去切图,生成静态HTML加展示效果,然后,注意,他不是自己接着往下做,而是交给另外一群开发人员,把它转换成服务端模板,比如freemarker或者velocity之类,或者是 *** arty,为什么要这么做呢?因为这类产品讲究一个首屏优化,是首屏而不是首页,这就意味着对于首屏来说,经过的环节应当尽可能少,比如说,就不能先载入客户端模板,再AJAX一个数据,然后去渲染一下。这么做的性能肯定是不如服务端把HTML生成好,然后一次请求加载的。
这个过程肯定是有一些问题的,比如说,如果开发人员B在套模板的过程中,发现原先的静态HTML部分有问题,应该怎么办?大家知道,一个对HTML和CSS都很熟悉,同时又可以写业务逻辑的前端开发人员是很稀缺的,所以,多数情况下,这两边的技能是不同的,如果是简单的页面问题,这个开发人员可能自己也就解决了,如果他解决不了,怎么办?
如果B自己不改,把他已经搞成服务端模板的代码返回给前端人员A,A也没法下手,因为已经是服务端模板,A手里没有环境,改了之后不知道对不对,不能预览。那么,B把问题告诉A,A修改他的原始版本,然后再拿给B又怎样呢?这时候B又麻烦了,他要对比两次修改的部分,把自己前一阵的修改合并进去。
所以,不管怎么搞,这里面都很折腾。
Midway这个产品,他想要解决什么问题呢?既然说前端人员没法预览模板的原因是,后端在使用服务端模板,那么,我能不能找一种两边都可用的模板,你能在服务端渲染,我也能在客户端预览?服务端跟浏览器端同时都能运行的语言是什么?只有JavaScript。
所以,大家就往nodejs里面去发掘了,一个普通的JavaScript模板库,它在浏览器端也可以渲染,在nodejs端也可以输出成HTML,这时候,那些原来负责整合模板和逻辑的人员改用nodejs,是不是就解决这问题了?
想象一下这个场景多么美好:前端来决定某个模板是服务端渲染还是客户端渲染,当首屏的时候,就在nodejs里面生成HTML,不是首屏的时候,就AJAX过来在浏览器端渲染展示。
从技术方案上看,这么做很好了,工程上又带来另外一些问题,那就是对熟练JavaScript开发人员的需求量大增。对阿里这样的公司来说,前端有大几百人,别的公司只能仰望,所以他当然可以放手一搞,但对我们苏宁这样,前端人数不大的,就麻烦了。如果我们也引入这样的方案,就面临把很大一部分Java开发人员转化成JavaScript开发人员这么一个问题,这个事情短期内肯定是无法解决的,所以反过来会增加前端这边的压力。所以暂时还用不了阿里这样的方案,只能努力先提高人员水平再看情况。
服务端引入nodejs还有别的优势,比如说请求合并等等,这个也可以用其他方式变通解决,比如加一个专门的跟现有后端同构的Web服务器,在那边干这些事。
## 展示和业务逻辑较均衡的产品
对于另外一些场景,也有类似的问题,比如支付产品,展示相对没那么重,但是又算不上Web应用,它面临另外一种情况的前后端分离。这种场景下,前端的出静态HTML和DOM操作类的JavaScript,业务开发人员负责写后端,还有另外一部分业务逻辑的 *** 。
这里的问题是什么呢?是jQuery式代码造成的协作问题。比如说:
$(".okBtn").click(function() { $.ajax(url, data) .success(function(result) { $("someArea").html(_.template("tpl", result)); });});
因为前端人员的稀缺,所以他不可能帮你把业务逻辑写出来,所以说,这里面$.ajax往里的部分,要业务人员自己写。然后,数据得到之后,又要去处理界面部分。
很多场景下,处理界面远不是这么搞个模板放上去就完事的,所以业务开发人员感到很烦闷,为了这么一点小问题,反复去找前端的人来搞,很麻烦,自己搞又特别花时间,所以都很苦闷。
这同样是一种前后端的分离,只是这个分界线不在浏览器,而在于:是否写业务逻辑。对付这种场景,解决办法就是加强JavaScript代码的规划。现在流行那么多在前端做MV*的框架,不考虑Angular这类太重量级的,来看看Backbone这样的,它到底解决了什么问题?
很多人说,Backbone虽然小,但根本不解决问题。这句话有一定道理,但前提条件是你自己的JavaScript代码分层已经做得很好了。如果做得不好,它就可以协助你解决分层的问题。
刚才那段代码,它的问题在哪里呢,在于职责不清晰。一个函数只能做一件事,这是共识,但由于回调等方式,所以不经意就破坏了函数的单一性、完整性。我们试试来拆开它。
对于一个后端开发人员来说,他为什么常常害怕写前端代码?是因为JavaScript语言吗?其实不是,我们用来写业务逻辑的时候,只会使用JavaScript一个很小的子集,对于这个子集来说,它并不存在多大的学习困难,最麻烦的地方在于DOM、BOM等东西,对于一个后端开发人员来说,如果要求他在掌握服务端代码编写的同时,还要去学这些,那真是有些不容易,所以,我们来给他省点事。
现在我们的出发点是,把这段代码拆给两个不同的人写,一个人操作DOM,另外一个人只写逻辑,绝对不操作DOM。前面这个代码拆给前端维护,后面这个拆给业务开发人员。
最老圡的方式:
a.js
$(".okBtn").click(function() { b1(data);});function a1(result) { $("someArea").html(_.template("tpl", result));}
b.js
function b1(data) { $.ajax(url, data) .success(a1);}
现在大家是不是相安无事了?
如果这么做的话,AB双方要做很多约定,也就是说,这个过程仍然是一个螺旋链。比如说,A先写点击事件的绑定,然后想起来这里要调用一个请求,就去找B写b1 *** 。B在写b1的时候,又想到他要调用一个界面展示 *** a1,然后又来找A写,来回也挺折腾。
况且,有这么一天,A在另外一个地方也想调用b1了,但是由于b1的回调已经写死了,比较蠢的办法就是在a1里面再判断,这是什么东西点击造成的,然后分别调用不同的回调。如果情况复杂,那这个代码写出来真是没法看。
如下:
a.js
var type = 0;$(".okBtn").click(function() { type = 1; b1(data);});$(".okBtn1").click(function() { type = 2; b1(data);});function a1(result) { if (type1) { $("someArea").html(_.template("tpl", result)); } else if (type2) { // ... } type = 0;}
b.js
function b1(data) { $.ajax(url, data) .success(a1);}
稍微好一些的办法是,在b1中,直接返回这个请求的promise,这样可以由调用方决定到底该干什么。
如下:
a.js
$(".okBtn").click(function() { b1(data).success(function(result) { $("someArea").html(_.template("tpl", result)); });});$(".okBtn1").click(function() { b1(data).success(function(result) { // ... });});
b.js
function b1(data) { return $.ajax(url, data);}
如果要对返回数据作统一处理,也可以很容易地在b1中,用promise重新封装了返回出来,只不过这样在a.js里面,直接调用的就不是success,而是then了。
注意到这样的代码还有问题,比如说大量的全局函数,不模块化,容易冲突。此外,没有一个地方可以缓存一些共享数据,比如说这么一个场景:
界面上两个块M和N,其中,M初始载入并加载数据,N在初始的时候不载入,而是在某个按钮点击的时候载入,而M和N中各有一个列表,数据来源于同一个服务端请求。
现在就有个问题,当N载入的时候,它的数据怎么来?比较老土的方式,肯定是载入N的时候,同时也再去请求一下数据,然后渲染到N上。
从一个角度看,如果说不重新请求,N的这个数据应当从哪里来?从另外一个角度看,如果重新请求了,发现数据跟之前的产生了变更,是否要同步给M,怎么同步给它?
我们看看类似Backbone这样的框架,它能提供怎样的机制呢?或者如果我们不用它,怎么自己把这个分层封装得更好一些?
首先,是建立一个数据模型,在它上面添加数据的缓存:
define("model", [], function() { var Model = { data: null, queryData : function(param, fromCache) { var defer = q.defer(); if (fromCache || this.data) { defer.resolve(this.data); } else { var self = this; this.ajax(url, param).success(function(result){ self.data = result; defer.resolve(result); }); } return defer.promise; } }; return Model;});
这么一来,我们在模型上作了数据的缓存,如果调用的时候加fromCache参数,就从缓存读取,否则就请求新的。为了在两种情况下,调用方接口能保持一致,把整个函数封装成promise,以便接着调用。这里的模型定义成单例了,假定是全局唯一的,可以根据需要调整成可实例化的。
这个时候,视图层就要封装DOM和事件的关联关系:
define("view", ["model"], function(Model) { function View(element) { this.element = element; this.element.selector(".okBtn").click(function() { var self = this; var fromCache = true; Model.queryData({}, false).then(function(result) { self.renderData(result); }); }); } View.prototype = { renderData: function(data) { this.element.selector("someArea").html(_.template("tpl", result)); } };});
这个时候,多个视图实例的情况下,数据也能够较好地利用。
这样,前端写这个View,后端写Model,可以作这么个分工。
这个只是很简陋的方式,在复杂场景下还有很多不足,在这里先不展开了。更复杂的场景也就是类似Web应用那种方式,稍后专门写一篇来展开。
## 小结
我们再来回顾前后端分离所要解决的问题,是分离前端和业务开发人员的职责,这个方案怎么定,是应当随着团队状况来确定的。比如阿里前端厉害,人多势众,他的前端就要往后推,去占领中间层。我们苏宁这样的公司,前端比较薄弱,只能在很多场景下,让出中间层,否则战线铺太广只能处处被动。
同一个中途岛,在不同的形势下,占还是不占,是很考验前端架构师的一个问题。
对阿里的这种实践,我们会持续围观,寻找并创造合适的出手时机。
【rank的回答(4票)】:
简单说下自己的看法。
前端不再继续「单纯」在 kissy 上下功夫,而可以考虑向后的延伸架构是一种前端的进步,这种前端架构将重定义阿里的前端工程师工作,很多互联网公司比阿里先行一步。
这个思路与与最早阿里很多前端没有碰后端(例如模板)有很大的关系,用 Node *** 作中间层能解决现面临的问题,是一种不限于解决当前问题的长远解决方案。
具体是否能解决和解决得好,在于细节,不在新,而在过渡。如,如何过渡目前 Node *** 与原来的数据交互,如何灰度过渡,工作量等。
平台化与接口化思路(后端数据接口以 Services 存在)让 amazon 收益非浅,现在后端平台化接口化在大公司趋势明显。
平台化需要更多更快的应用层开发选型,Node *** 是不错的一种。Node *** 虽然还是有些问题,但从信息面与我们自己的应用经验来看,已有慢慢成为后端 WebApplication 的一种很好的选型方案的趋势。
总的来说,是个趋势。
【Hex的回答(1票)】:
我认为这就是所谓的大前端开发模式。模式确实是好模式,但是真正实践起来,和后端工程师的沟通和协调也会遇到很多问题。
我做过的几个项目都是采用这种大前端的开发模式,前端基于Transformers框架+CodeIgniter组成大前端,这样确实可以很好的隔离前后端,项目可维护性大大提高。
【邓欣欣的回答(1票)】:
上周去杭州玩了下,和之前的阿里同事做了些技术交流,发现这一年,阿里的前端在流程改进上下了很大功夫; 题主所说的中途岛应该是 UDC 团队做的,应该说思路不是很新鲜,国外有 ebay 向 nodejs 的转型案例,国内之前也有百度音乐移动端的案例;
但对阿里前端来说,意义确是很重大,解决了合作流程中的一个很大问题:之前阿里的前端是只写静态 demo,写完给开发套模板,开发不太懂 html,漏写个标签,然后找前端调试,一来一去很折腾,是个必须干但又是个没啥技术含量的事; 中途岛可以很好的解决这类蛋疼事,但是请不要认为前端就因此会后端了,无非是之前浏览器用 ajax 请求接口,现在咱用 node http去请求呗,框架做得牛逼点,统一适配出前端的ajax 接口也不是不可能呀~~,想想嘛,为啥要用 node 呢? 牛逼直接写 java 啊。。哈哈哈~
其他的 F2E 团队也做些很不错的流程改进工具,同样不是很新鲜,但对阿里前端都是比较有意义的工具:
def: 项目构建与发布工具,与阿里的 gitlab, scm 整合,各种 脚手架,build,combo,发布,一条命令搞定,确实很方便;
dip:数据接口平台,定义业务线前后端数据格式的一个内部公共平台,基于 json-schema,好像也可以给你提供 mock 接口;
uitest:前端持续集成平台;之前这东西我是边做边吐槽的,似乎刚上线,类似 jenkis 这些,提交或者发布代码时,先帮你跑一次测试用例;目前通用测试库比较少。
Trace:好像是叫这个名字吧,监控平台,这个比较早就有了,用来监控各个业务线页面的运行状况并搜集各种用户数据,如分辨率,UA
我看来 def 和 dip 对阿里前端的作用会更大些,uitest 估计作用一般,阿里前端是不注重代码质量的,测试用例也仅在几个重要的直接影响交易的业务线会写。
【许文敏的回答(0票)】:
确实不错,从职责上来区分前后端分离才是王道,nodejs将成为前端工程师的基础技能
【猎人豆豆的回答(0票)】:
不要把简单的问题搞复杂,对于 *** 这样规模的公司,有些牵一发而动全身的改动,更好是在权衡风险和收益后再决定,我们是技术的使用者,而不要被技术牵着鼻子走.
【罗正烨的回答(2票)】:
前面前端的大牛们都说了,我换个角度聊聊。
这么讲吧,阿里的前端为什么比其它公司走的远,是因为他们有很多前端,还有很多不用写大量业务逻辑的前端大牛。大牛的作用,就是折腾。阿里的前端工程师水平在自身领域实践上已经跟得上后端。
但这个架构所谓的分离,其实是把很多原来前端不需要做的事揽到了自己的手上,增加前端架构师的KPI,让前端做了更多的事,周报好写。因为nodejs和前端都是js,所以学习成本并不算高,但是对一个技术人员的要求是比原来更高了。
但是,他们团队有很多HC,有很多钱。。所以像我这种一个产品线只有一二个前端的,要是这么玩儿,招人跟不上不说,然后还可以把自己累死。
所以技术选型和架构这种事,还是要根据自己团队的能力和招人啊。
*** 安全到底是做什么的?有哪些工作?
*** 安全可以从业的岗位有很多,比如:Web安全渗透测试员、企业信息安全主管、IT或安全顾问人员、IT审计人员、安全设备厂商或服务提供商、信息安全事件调查人员、其他从事与信息安全相关工作的人员。
一、渗透测试工程师
基本要求:对web安全整体需要有着深刻的理解和认识,具备web渗透相关的技能,熟悉渗透测试整体流程,熟悉掌握各类安全测试的工具。
岗位职责:主要负责承接渗透测试相关的项目,跟踪国际、国内安全社区的安全动态,进行安全漏洞分析、研究以及挖掘,并且进行预警。
二、安全开发工程师:
基本要求:掌握ruby、nodejs、Python、Java其中一种语言,熟悉主流的渗透攻击的原理、利用方式,能够以手工和结合工具的方式对目标系统进行渗透测试。
基本职责:负责对安全产品的开发与维护,包含安全应急等工作。
三、安全运维工程师:
基本要求:熟悉Linux操作系统,熟悉编写shell或者Python脚本,熟悉常见web安全漏洞分析与防范,包含SQL注入、XSS、csrf等。
基本职责:负责业务服务器操作系统的安全加固,系统层的应用程序的运行权限检测、评估。
如何解决繁琐的WEB前端的XSS问题
后台做一层过滤,前台文本编辑器可以自己做一层标签过滤,不允许一些符号的输入就行了
xss攻击前端能做的有限
因为好多都是url转码来通过参数找漏洞,所以后台也要做一层过滤(例如nodejs的sql库就只允许单行sql,防止通过xss做注入)java之类的有现成多xss过滤器
剩下的就做ip黑名单吧,防止多次攻击
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"属性,那么通过程序( *** 脚本、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天后过期,可以这样实现:
求大神讲讲web安全,nodejs怎么防止跨域攻击和sql注入
是CSRF(Cross-site request forgery) 不是你写的那个!
跨域不用担心.主流浏览器都会帮你做防御的. 问题不大,主要是你自己别给其他域的权限即可.非必要的话,以最小权限原则.
xss主要就是过滤输入输出.如果业务很多,还是找人审计代码吧.或者用比较成熟的模块.CSRF的话,1,验证来源 2加随机token之类的.
sqli主要还是过滤输入的地方.过滤/转义关键字比如select,and,or等等(有专门的防注入模块).觉得怕麻烦的话.用那些云主机的防御功能.再加个cdn基本就没事了.(对于一般的反射型跨站也适用)