序

在前后端分离的开发模式下，在开发角色和功能方面最明显的变化之一是，在过去的传统中，只负责浏览器环境下开发的前端学生需要涉猎服务器层面，编写服务器代码。而一个基本的问题就是如何保证Web的安全性。

本文在前端分离模式的框架下，针对前端在Web开发中遇到的安全问题，提出了对策和注意事项，并提出了解决方案。

跨站点脚本攻击防御(XSS)

问题与解决方案

跨站点脚本(XSS)是攻击网站最常见和最基本的方法。攻击者可以在网页上发布包含攻击性代码的数据。当查看者看到此网页时，将以查看者用户的身份和权限执行特定的脚本。XSS可以轻松修改用户数据、窃取用户信息并引发其他类型的攻击，例如CSRF攻击。

防止XSS攻击的基本方法是确保输出到HTML页面的任何数据都在HTML中转义。例如，以下模板代码：

复制代码如下：文本区域名称='描述' $描述/文本区域

这段代码中的$description是模板的变量(不同模板中定义的变量语法不同，这里只是示意)，加上用户提交的数据，那么攻击者可以输入一段包含“JavaScript”的代码，这样上面模板语句的结果就变成了下面的结果：

复制代码如下：文本区域名称='描述'/文本区域脚本('你好')/脚本/文本区域

在浏览器中呈现的上述代码将执行JavaScript代码，并在屏幕上显示hello。当然，这些代码是无害的，但是攻击者可以创建一个JavaScript来修改用户配置文件或窃取cookie数据。

解决方法很简单，就是$description的值是htmlescaped，转义后的输出代码如下

复制代码如下： textarea name=' description '/textareasacripttalert(' hello！')/脚本/文本区域

上面的转义HTML代码是无害的。

中途岛的解决方案

转义页面中所有用户输出的数据

有几种情况和方法可以转义数据：

1.使用模板中提供的机制来逃避

KISSY xtemplate在中途岛被用作模板语言。

在xtemplate的实现中，两个方括号({{val}})用于从语法上解析模板数据。默认情况下，数据是HTML转义的，因此开发人员可以这样编写模板：

复制代码如下：文本区域名称='描述' { Description } }/文本区域

在xtemplate中，如果不希望输出数据被转义，则需要使用三个方括号({{{val}}})。

2.在中途显式调用转义函数

开发人员可以在Node.js程序或模板中直接调用Midway提供的HTML转义方法，对数据进行如下所示的转义：

方法一：Node.js程序中数据的HTML转义

复制代码如下： varsecurity=REQUIRE(' MidWay-security ')；//来自服务器的数据，如{html:'/textarea '，other : ' ' } data . html=security .擒纵html(data . html)；xtpl=xtpl.render(数据)；

方法2:从模板中转义HTML数据

复制代码如下： textarea name=' description ' security . escape html({ { { description } } })/textarea

注意：只有当模板内部没有转义时，才使用Security.escapeHtml来转义数据。否则里面的模板和程序会两次转义叠加，导致意外输出。

建议：如果使用ext template，建议使用模板内置的{{}}直接转义。如果使用其他模板，建议使用Security.escapeHtml进行转义。

过滤用户在页面中输出的富文本

你可能会想：“其实我就是想输出富文本。例如，一些留言板和论坛为用户提供了一些简单的字体大小、颜色、背景等功能。那么我应该如何处理这样的富文本来阻止XSS呢？”

1.使用中途岛安全提供的richText功能

中途提供richText方法，专门用于过滤富文本，防止XSS、钓鱼、cookie窃取等漏洞。

有一个留言板，模板代码可能如下：

复制的代码如下： div class='留言板' {{message}}}/div

因为message是用户的输入数据，其留言板的内容包含丰富的文本信息，所以在xtemplate这里，使用了三个大括号，默认不执行HTML转义；那么用户输入的数据假设如下：

复制的代码如下： script src=' http3360http://eval.com/eval.js'/scriptspan风格=' color:redfont-size :20 px；位置：固定；在我的message /span中，如果将上面提到的富文本数据直接输出到页面中，必然会导致eval.com站点的js被注入到当前页面中，导致XSS攻击。为了防止这个漏洞，我们只需要在模板或程序中调用Security.richText方法来处理用户输入的富文本。

调用方法类似于擒纵Html，有以下两种方式

方法1:直接在Node.js程序中调用

复制代码如下： message=security . rich text(message)；var html=xtpl.render(消息)

方法2:在模板中调用

复制代码如下： div class=' message-board ' security . rich text({ { { message } } })/div

调用Security的richText方法后，最终输出如下：

复制的代码如下： div class=' message-board ' span style=' color : red；' font-size :20 px；'我在留言区

可以看到，首先直接过滤掉会引起XSS攻击的脚本标签；同时，CSS属性位置：固定在样式标签中；样式也被过滤了。最后，输出无害的HTML富文本

了解可能导致XSS袭击的其他方式

除了页面模板中的XSS攻击之外，还有其他几种方式在Web应用程序中可能存在风险。

1.错误页面的漏洞

如果未找到页面，系统可能会报告404未找到错误，例如：http://localhost/page/not/found

404未找到页面/page/not/find不存在显然，攻击者可以利用此页面构建这样的连接，http://localhost/)，引诱受害者点击；如果错误页没有转义输出变量，将执行连接中隐藏的script alert(' hello ')/脚本。

在express中，发送404页的方法如下

res.send(404，'对不起，我们找不到那个！这里，开发人员需要注意错误页面(404或其他错误状态)的处理。如果错误消息的返回内容包含路径信息(其实更准确的说是用户输入的信息)，那么就需要进行escapeHtml。

随后，错误处理的安全机制将在Midway框架中完成。

中途岛解决方案补充说明

其他模板引擎

中途岛默认支持xtemplate模板，但未来可能会支持其他模板，如jade、小胡子、ejs等。目前主流的模板中，缺省转义和非转义的输出变量都有提供，这就需要开发人员特别注意它们的安全性。

对逃跑的其他支持

除了从页面输出的普通数据和富文本数据之外，有些场景还包含其他可能需要转义的情况。Midway提供了以下常用的转义方法供开发人员使用：

转义Html过滤指定HTML中的字符，并防止XSS漏洞。jsEncode用JavaScript转义输入字符串，用unicode转义中文。带单引号和双引号的escapeJson不破坏Json结构的转义功能，只转义json结构中的名字和vaule。擒纵器jsonforjsvar可以理解为jsEncode擒纵器Json如下。

复制的代码如下： var JSON TEXT=' { ' script ' : ' script ' } '；console.log(SecurityUtil .擒纵JSON(jsonText))；//{ ' script ' : ' script ' } var jsontext=' { ' hello ' : ' script ' } '；console.log(SecurityUtil .擒纵jsonforjsvar(jsonText))；//{ ' u4f 60 u 597d ' : ' script ' } var str=' alert( ' hello ')'；console . log(securityutil . jsencode(str))；//警报('u4f60u597d ')

防止跨站点请求伪造攻击(CSRF)

问题与解决方案

名词解释：表单：一般指浏览器用于客户端提交数据的表单；包括标签、ajax提交数据、表单提交数据等。而不是HTML中的表单标记。

跨站点请求伪造(CSRF)是另一种常见的攻击。攻击者通过各种方式伪造请求，模仿用户提交表单的行为，从而修改用户数据或执行特定任务。

为了冒充用户的身份，CSRF攻击经常配合XSS攻击，但也可以使用其他手段：例如，诱导用户点击包含攻击的链接。

解决CSRF进攻的思路分为以下两步

1.增加攻击难度。GET请求很容易创建，用户可以通过点击链接发起GET请求，而POST请求相对困难，攻击者往往需要JavaScript来实现。因此，确保表单表单或服务器接口只接受POST类型的提交请求可以提高系统的安全性。2.对请求进行身份验证，以确保请求由用户自己填写或发起并提交，而不是由第三方伪造。

普通用户修改网站信息的过程如下

用户请求修改信息(1)-网站显示用户修改信息的形式(2)-用户修改信息并提交(3)-网站接受用户修改的数据并保存(4)，但CSRF攻击不会走这条路线，而是直接伪造用户在步骤2提交的信息。

直接跳到步骤2(1)-伪造要修改的信息并提交(2)-网站接受攻击者修改的参数数据并保存(3)只要能区分这两种情况，就能防止CSRF攻击。那么如何区分呢？是验证步骤2中提交的信息，以确保数据来自步骤1中的表单。具体验证过程如下：

用户请求修改信息(1)-网站显示修改信息的空白表单，其中包含特殊令牌并保存在会话中(2)-用户修改信息并提交，并将令牌信息发回服务器(3)-网站将用户发回的令牌与会话中的令牌进行比较，然后接受用户修改的数据。而保存这种方式，如果攻击者伪造了要修改的信息并提交，就没有办法直接访问会话，所以也就没有办法得到实际的令牌值；请求被发送到服务器，当服务器检查令牌时，它发现不一致，所以它直接拒绝请求。

中途解

禁用GET提交表单

如果服务器不接受GET提交的表单数据，会给攻击者带来很大的难度；因为通过在页面上构造一个A标记href属性或一个img标记src属性来构造一个请求是非常容易的，所以如果你想POST它，你必须使用一个脚本来实现它。

使用CSRF令牌验证请求

由于中途岛不涉及淘宝分布式会话和令牌验证的逻辑，在中途岛框架中，服务器和客户端之间只转发令牌，本身不做实际的验证工作。流程如下：

后续：中途岛，Node.js和淘宝的分布式会话对接后，可以考虑在中途岛层自动验证令牌；毕竟安检越早，费用越低。

建议：在中途可以判断请求中是否有代币值。如果修改操作中没有令牌，您可以直接在中途层认为它不安全，并丢弃请求。

其他安全问题

有以下几种常见的网络安全问题，这里只简单介绍一下，并将继续继承到Midway框架中。

HTTP Headers安全CRLF注入攻击者试图在响应头中注入两个CRLF特殊字符，导致响应数据格式异常，从而注入脚本和其他拒绝访问攻击。默认情况下，每个请求都会带来cookie，服务器通常会限制cookie的大小，这导致，如果用户客户端cookie被设置为超过某个阈值，那么用户将无法再访问网站。cookie防盗一般通过JavaScript(XSS漏洞)获得，因此请尝试将cookie设置为仅http并添加cookie过期时间。WebX之前有更好的解决方案；这次中途岛不负责设置和验证cookie，只负责将它们转发到WebX级别进行检查

关于Node.js

XSS等注入漏洞是所有漏洞中最容易被忽视的，占互联网攻击总数的70%以上；当开发人员编写Node.js代码时，他们应该时刻提醒自己永远不要相信用户的输入。

例如，下面的例子。

var mod=fs . readfilesync(' path ')；如果路径来源于用户输入，那么假设用户输入了/etc/password，就会读取不该读取的内容，导致密码泄露的风险。var结果=eval(JSonval)；确保jsonVal是json，而不是用户输入.其他可能包含用户输入的地方，请确保用户输入是我们期望值的总结

在前端分离模式下，传统的前端开发人员可以开始编写后端代码。虽然从架构上讲，他们只负责模板层，但也会接触到大量的后端代码；所以安全性对前端来说是一个很大的挑战。