安全规范

导出PDF

【必须】基本要求

  • 1.使用蓝鲸提供的应用开发框架,已集成基本的 web 安全防范策略(XSS、CSRF、统一登录等)

  • 2.Debug 信息禁止对外暴露(测试、正式环境禁止开启 debug 模式,建议规范错误日志,查看日志定位问题)

  • 3.访问限制( IP 或 QQ 白名单)(统一使用蓝鲸开发者中心提供的权限管理功能)

  • 4.越权操作防范和自检(用户、业务、操作权限等关联鉴权)(参考越权案例)

  • 5.权限回收(应用统一回收通知模块,定时通知业务测负责人对外部人员权限进行梳理确认,应用开发框架集成)

  • 6.内部应用对外提供API 并做好鉴权,统一由蓝鲸 ESB 封装,必须报备

  • 7.webshell 必须报备

  • 8.Flash XSS 漏洞(例如:zeroclipboard 插件,请将插件升级至最新版本)

常见 XSS 漏洞及解决方案

场景1 存储型 XSS

【定义】

把用户输入的数据“存储”在服务器端,用户浏览页面时,再从服务器端读取生成页面展现给用户

【示例】

用户输入内容直接显示在前端标签里,例如

 <h1> some_user_input</h1> 

或者

<imput type=”text” name=”address1” value=${“address”}>

蓝鲸安全规范

蓝鲸安全规范

【解决】

为了使浏览器能正确地显示这些字符,而不是去执行,我们需要使用html实体字符。

  • 1.在数据入库之前做转义,例如将 <script>转义成&lt;script&gl , 这个在蓝鲸应用开发框架提供的中间件中有实现,要确保该中间件有在使用

  • 2.对输出到前端的内容,我们也要过滤,防止因为对输入过滤被绕后,可以使用mako模版的h参数(${ name | h }

  • 3.对于不是 mako 模版渲染展示的内容,需要做html特殊字符的转义,特别注意前端的 title,name,class 等属性的赋值同样需要做转换

【测试】

对所有用户输入部分进行检测,输入

<script>alert('xss');</script>

查看展示部分是否被弹窗。

场景2 反射型 XSS

【示例】

对于用户的输入,我们有时并不是像场景1那样简单地显示在标签里,比如自动填充表单时,会用到

$("#my_input").val("some_message");

或者填充图片 src 时,会用到

<img src="some_message">

这里的 some_message 都是我们用户输入,并由后端填充的内容。此时可以通过输入如下代码提前闭合引号来进行 XSS 攻击

"><img src=x onerror=alert(1);>

经过后端传到前端之后,前端代码变为

$("#my_input").val(""><img src=x onerror=alert(1);>");

原本的赋值语句被破坏,如果是持久型的存储数据,将会持续影响正常业务。 或者变为

<img src=""><img src=x onerror=alert(1);>"

【解决】

同场景1,对输入内容做特殊字符的过滤转义

【测试】

对所有用户输入部分进行检测,输入

 "><img src=x onerror=alert(1);> 

查看展示部分是否被弹窗,以及业务功能是否受影响。

场景3:文件上传与导入

对于导入或者上传的文件,通常会忽略特殊字符的转义,这样当文件内容在前端显示的时候,会出现 XSS 攻击

【示例】

比如,Excel 导入用户数据并生成表格

蓝鲸安全规范

信息导入后传至前端表格,造成场景1中的标签内XSS 又比如,文件上传并展示

蓝鲸安全规范

在非 windows 的操作系统(如Lunix、OSX)中,文件名可以被命名为任意格式,可以包含JS代码,在上传完成后在前端显示时造成 XSS 攻击

蓝鲸安全规范

【解决】

1)对 Excel 和文件导入的数据进行校验,对特殊字符进行转义,包括不限于单引号、双引号、反引号、尖括号、&等。

2)后台对上传文件的大小、内容、类型做校验,只允许上次符合要求的文件类型

3)文件名在前端显示的时候,做 html 特殊字符转义

【测试】

在导入的 Excel 中尝试使用

<script>alert('xss');</script>

"><img src=x onerror=alert(1);>

来检查是否弹窗和业务功能完整性。 将上传的文件名命名为

"><img src=x onerror=alert(1);>.zip

或来检验是否弹窗和业务功能完整性。 常用XSS测试 payload

<img/src='x'onerror=alert(document.cookie)>

场景4 出错提示信息

【示例】

上传文件的路径写了

<script>alert(/xss/)</script>

执行的时候,路径出错,前端提示信息中有显示用户填写内容,未做过滤,导致 XSS 攻击

蓝鲸安全规范

【解决】

同场景1 前端显示用户输入的时候要做 html 特殊字符转义

【测试】

填写上传文件或者文件分发路径的地方,输入

<script>alert(/xss/)</script>

检查系统是否正常,结果是否符合预期

场景5 通过用户输入提前闭合 <script> 代码

利用浏览器解析 html 的原理,通过用户输入内容将 <script> 标签提前闭合,导致后续的 js 代码直接暴露在前端页面

【示例】

如下简单的三段代码就可以导致 script 提前闭合,user_variable 的渲染正式使用 mako 渲染的常见场景:

<script>
    var user_variable = "</script>";
</script>

蓝鲸安全规范

【解决】

mako 渲染时,将用户输入的信息在 Python 中以 base64 的形式输出到 html 中,这样用户输入的所有特殊符号都被转换成字母,不会导致 html 解析时 script 标签提前闭合。 最后运用用户变量之前使用js的base64解码转换一次

蓝鲸安全规范

常用 XSS 测试 payload

(1)	<script> alert('xss')</script>
(2)	http://localhost/x.html#<script> alert('xss')</script>
(3)	<script src=http://www.qq.com></script>
(4)	“><script>alert(1)</script>
(5)	“><img src=x onerror=alert(“xss”)>
(6)	"><iframe src=javascript:alert(1)></iframe>
(7)	</script>

常见越权漏洞及解决方案

常见越权分类

1.平行越权

场景1:普通用户A可以访问到普通用户B的数据

场景2:用户可以通过修改请求链接或参数,访问到其它本应无权访问的数据

2.上下越权

普通用户可以执行管理员的操作

场景1 :对 get 请求中显式的 URL 更改进行越权

蓝鲸安全规范

对如图的 URL 格式,在没有严格判断的情况下,特别是后台采用 API 模式时,用户通过随意更改 /detail/ 后面的数字,可以绕过权限判断访问任意的页面。

【解决】

对所有增、删、改、查的功能中,对用户暴露出的 API,都要进行严格的权限判断

对用户身份,需要操作的 id 需要做严格的校验,建议在 URL 中加入业务字段,根据业务字段判断用户是否有操作权限

【测试】

将 URL 中的 id 更改为权限外的页面 id,检查是否能越权访问以及返回页面是否符合预期

场景2: 对 post 请求中的预置参数更改进行越权

一些固定的 post 参数,如 hidden 属性的 input,或 ajax 的 data 中在页面返回时就确定的信息,都是可能被修改的

蓝鲸安全规范

如图,页面在后端渲染时确定了一个 report_id,用户点击按钮时就会拿这个 id 去下载相应的文件。如果在下载逻辑中没有进行权限控制,则可能被修改 id 来下载任意文件,造成越权。

【解决】

同场景1,完善各个视图函数的权限控制。

【测试】

使用 Postman 或其他 chrome 插件来模拟、修改POST请求

使用 fiddler 抓取请求包,修改 post 请求中的参数

场景3: 非管理员用户访问管理界面

通常app中会设定一个管理员界面,方便进行一些配置工作。一般的做法是前端进行控制,管理界面的 url 不会暴露给非管理员用户,但是不排除非管理员通过各种手段获取到所有 url 并进行访问。

【解决】

后台管理相关的操作,需要在后台对操作用户进行权限校验,避免非法用户的访问

【测试】

用普通用户的帐号尝试访问管理员界面或者管理操作的 cgi

常用越权测试方法

1.测试点1

获取A用户操作请求到的数据包,用B用户身份来请求,看返回数据(可在页面操作后,使用 fiddler 抓取请求包,在使用B用户身份请求)

2.测试点2

蓝鲸安全规范

1)修改请求链接中的业务 ID 等数据后,发起请求,判断是否有越权

2)修改请求参数中的业务 ID,用户名等数据后,发起请求,判断是否有越权(用 fiddler 抓包)

常见CSRF漏洞及解决方案

场景1 json_hijacking

【漏洞描述】

Json hijacking 是 csrf 漏洞的一种,CGI 以 JSON 形式输出数据,黑客控制的第三方站点以 CSRF 手段强迫用户浏览器请求 CGI 得到 JSON 数据,黑客可以获取敏感信息

【漏洞检测】

使用工具获取 json 数据。

【漏洞修复】

可使用以下任意办法防御 JSON Hijacking 攻击 1)在请求中添加 token(随机字符串)

2)请求 referer 验证(限制为合法站点,并且不为空)

【注意事项】

在线 json 防御被外域恶意调用只限制了 referer,但是允许空 referer 访问:比如本地 html,还有某些伪协议远程调用时是没有 referer 的。从而导致问题持续。所以空 referer 也是不安全的

【解决】

蓝鲸应用开发框架已经集成了 django 的 csrf 中间件来预防 csrf 攻击,一般比较重要的增删改操作都会使用 post 请求,一般不会出现问题。但是如果是 get 请求去获取敏感信息的话,就有可能存在上述问题,建议用 get 方式获取所以有敏感信息的 cgi, 要不换成 post 要不加 referer 校验

本文档是否对您有帮助?