前言 平时很少关注安全这块的技术,曾经也买过一本《Web前端黑客技术揭秘》但至今还没翻过,尴尬。今天的早读文章由腾讯优测@小吉带来的分享。 正文从这开始~ 最近深入了解了一下XSS攻击。以前总浮浅的认为XSS防御仅仅只是输入过滤可能造成的XSS而已。然而这池子水深的很呐。
XSS的类型 总体来说,XSS分三类,存储型XSS、反射型XSS、DOM-XSS。 存储型XSS 数据库中存有的存在XSS攻击的数据,返回给客户端。若数据未经过任何转义。被浏览器渲染。就可能导致XSS攻击; 反射型XSS 将用户输入的存在XSS攻击的数据,发送给后台,后台并未对数据进行存储,也未经过任何过滤,直接返回给客户端。被浏览器渲染。就可能导致XSS攻击; DOM-XSS 纯粹发生在客户端的XSS攻击,比如:http://www./page.html?default=French 页面代码: 该XSS攻击实现条件:
http://www./page.html?default=
满足以上三者,就会导致URL上的js代码执行:alert(document.cookie),但是攻击者可以利用这个,做你无法想象的事情。在现代浏览器中,已经做了xss过滤,一旦检测到xss,会提示报错如下: 以上便是学术上的划分的XSS攻击类型,2、3类型其实都是反射型的攻击。了解了这些,意识到XSS攻击无处不在啊。那么如何对XSS进行防御?从输入到输出都需要过滤、转义。
XSS防御—输入输出的过滤和数据转义 输入 客户端求情参数:包括用户输入,url参数、post参数。
如,http://xss.qq.com?default=12,Default值强制限制为整形。 我们的后台是node,使用joi对于输入做类型限制:
输出 即使在客户端对用户的输入做了过滤、转义,攻击者一样可能,通过截包,转发等手段,修改你的请求包体。最终还是要在数据输出的时候做数据转义。 好啦,到数据转义啦,不就是对<>,'&'这些字符做实体化转义吗?如果你认为这么简单,NO NO NO…因为浏览器解析中html和js编码不一样,以及上下文场景多样,所以对于后台输出的变量,不同的上下文中渲染后端变量,转码不一样。 下面的HTML片段显示了如何安全地在多种不同的上下文中渲染不可信数据。 情况一 数据类型:String 上下文:HTML Body 示例代码:UNTRUSTED DATA 防御措施:HTML Entity编码 情况二 数据类型:String 上下文:安全HTML变量 示例代码: 防御措施 1. HTML Attribute编码 2. 只把不可信数据放在安全白名单内的变量上(白名单在下文列出) 3. 严格地校验不安全变量,如background、id和name 情况三 数据类型:String 上下文:GET参数 示例代码:clickme 防御措施:URL编码 情况四 数据类型:String 上下文:使用在src或href变量上的不可信URLs 示例代码: 防御措施: 1. 对输入进行规范化 2. URL校验 3. URL安全性认证 4. 只允许使用http和https协议(避免使用JavaScript协议去打开一个新窗口) 5. HTML Attribute编码 情况五 数据类型:String 上下文:CSS值 示例代码: Selection 防御措施: 1. 使用CSS编码 2. 使用CSS Hex编码 3. 良好的CSS设计 情况六 数据类型:String 上下文:JavaScript变量 示例代码: 防御措施: 1. 确保所有变量值都被引号括起来 2. 使用JavaScript Hex编码 3. 使用JavaScript Unicode编码 4. 避免使用“反斜杠转译”(\'、\'或者\) 情况七 数据类型:HTML 上下文:HTML Body 示例代码: UNTRUSTED HTML 防御措施: [HTML校验 (JSoup, AntiSamy, HTML Sanitizer)] (https://www./index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Use_an_HTML_Policy_engine_to_validate_or_clean_user-driven_HTML_in_an_outbound_way) 情况八 数据类型:String 上下文:DOM XSS 示例代码: |
|