Server Side Template Injection, 服务端模板注入，最初由James Kettle在2015年的黑帽大会上讲解。来自小米安全的安全工程师——Dayeh（呆爷），主要从模版注入Flask方向为大家带来了精彩的分享。 模板注入相较于其他注入，例如xss、sql注入、xml注入等攻击，其本质思想是一致的，服务器端接受了用户的输入，未做验证或过滤便作为模板内容的一部分，在进行模板渲染时候，发生了代码执行。目前有很多模板引擎，都可能存在这样的问题。本次议题结合Flask框架及其使用的Jinja2模板，讲解了模板注入的原理、注入手段和一些绕过方式，以及结合Python沙盒逃逸思路的一些攻击手段，最后针对模板注入漏洞的发现及防御进行了一些讨论。 模板注入基本成因 沙箱逃逸的思路 绕过防御 使用JINJA2沙箱

web安全之XSS攻击demo，配合我个人博客使用，谢谢各位的捧场

数据分析：2016年网站漏洞数据分析 数据分析：2016年网站DDoS攻击数据分析 数据分析：2016年挂马事件 Web安全——2017 360公司的技术实力：漏洞挖掘能力 360公司的技术实力：大数据应用能力 360公司的社会责任：同时提供面向个人和企业的安全产品 网站安全解决方案：了解现状，监测风险 网站安全解决方案：云＋端纵深防御体系 尝试应用防御新手段：RASP 面向企业的Web安全整体框架 Web安全进阶

应用程序安全风险 A1 – 注入 A2 –失效的身份认证和会话管理 A3 –跨站脚本（XSS） A4 - 不安全的直接对象引用 A5-安全配置错误 A6-敏感信息泄漏 A7 - 功能级访问控制缺失 A8 – 跨站请求伪造CSRF A9 - 使用已知含有漏洞的组件 A10-未验证的重定向和转发

目录 1 、Web API 安全威胁 2 、Web API 安全漏洞 3 、WAF Web API 漏洞防护 4 、Web API 安全开发建议

需求在哪里？ 为什么不能简单一点？ 畅想高级玩法

大纲 • 由应用安全说起 • 传统REST API安全测试 • 基于Swagger的REST API 的安全测试

Web应用随着互联网模式的蓬勃应用而越来越成为轻客户端的首选，而同时随着越来越多的Web应用的普及和发展，安全问题也愈加受到各个厂商和互联网公司的重视。但所谓“解铃还需系铃人”，coding的问题终究还需要coder来解决，无论对于安全服务工程师还是对于普通开发工程师，在面对Web安全问题时终究要把其脉、摸其底，以往的渗透测试工程师讲Web安全或侧重漏洞原理，或侧重漏洞演示，本期沙龙由IDF实验室核心成员魏志伟分享程序员角度的Web安全。

业务逻辑漏洞，它本身不是咱们说的网络层，系统层，代码层，它本身是跟人相关的，它称之为业务设计缺陷。接下来锅涛老师就给大家全方位讲解一下，在我们程序开发过程中，怎么去规避。除了学会如何规避，还将引发你去思考，思考这个漏洞它是怎么让黑客发现的，就是大家经常会说的一句话，如果你不知道漏洞是怎么来的，那你的防护永远是被动。 业务多样化发展 有“利益”的地方就有黑客 也许各位已经对以下漏洞”司空见惯“ 从黑客攻击角度分析未来攻击的主战场 黑客为什么要平衡攻击成本 为何“业务逻辑漏洞”成为黑客的主战场 黑无止境的根源 业务场景中分析业务逻辑”漏洞“ 衍生的“业务逻辑漏洞” 黑客比我们更了解我们的”业务逻辑“ 业务场景之密码重置 0x00(注册)任意用户注册 0x00(注册)遍历用户 0x00(登录)撞库 0x00(登录)手势密码解锁 0x00(登录)身份认证三部曲 0x00(找回密码)任意用户密码重置 0x00(找回密码)客户端验证码 0x01(交易)任意申贷信用额度 0x02(支付)支付密码绕过 0x03任意支付密码修改 应对法则

安全测试并不遥远 安全测试并不陌生 与”其他“测试的相似之处 目标类似 过程类似 测试用例有重合 探索 怀疑的态度 安全测试从何做起 安全起步“三板斧” 转换视角 改变模拟对象 使用专用测试工具 来个栗子吧！ “栗子”的场景 栗子“七步骤 ”栗子“中测试用例 总结