XSS基础
XSS概念:
通常情况下,在Web应用的网页中,有些部分的显示内容会根据外届输入值而发生变化(会反弹恶意代码),而如果生成这些HTML的程序中存在问题,就会滋生名为跨站脚本(Cross-Site Scripting)的安全隐患。由于它和知名的CSS(层叠样式表)缩写冲突,所以经常缩写为XSS。
XSS的实质其实是HTML代码与Javscript代码的注入。但由于XSS的攻击对象是与客户对等的Browser端,因此常常不被开发者所重视。
一般意义上的XSS通常可以用简单的方法检测出来:当用户输入中某个参数的全部或其中一部分,原封不动地在源代码里出现时,我们就可以认为这个参数存在XSS漏洞。
XSS的风险:
Web应用若存在XSS漏洞,就会有如下风险:
- 用户的浏览器中运行攻击者的恶意脚本,从而导致Cookie信息被窃取,用户身份被报名顶替。
- 攻击者能获得用户的权限来恶意使用Web应用的功能。
- 向用户显示伪造的输入表单,通过钓鱼式攻击窃取用户的个人信息。
XSS漏洞总览:
- 产生地点:Web应用中南生成HTML和JavaScript的地方。
- 影响范围:Web应用全体
- 影响类型:在网站用户的浏览器中执行JavaScript,显示伪造的网站内容。
- 影响程度:中~大。
- 用户参与程度:需要—> 浏览恶意网站、点击邮件内的附属连接、浏览已被入侵的网站等。
- 对策概要:用双引号括起来属性对,转义HTML中的特殊字符。
XSS被恶意使用的三种方法:
- 窃取Cookie值
- 通过JavaScript攻击
- 篡改网页
同源策略:
同源策略:来自相同网站的页面。
不同源策略:来自不同网站的页面。
跨站脚本类型:
XSS分类:可根据不同分类方式,分为不同类型。
- 按形式分:反射型XSS 存储型XSS
- 按介质分:JSXSS FlashXSS
- 按接口分:DOM base XSS , 非DOM XSS
注:因此没有反射型XSS、存储型XSS、DOM XSS这种分类,因为分类依据都不同…
反射型XSS:
如果攻击用JavaScript代码位于攻击目标网站之外的其他网站(恶意网站或者邮件中的URL),就 称为反射型的XSS(Reflected XSS)。
窃取Cookie实例中用到的XSS攻击模式就属于反射型XSS。
反射型XSS多发生于网页将用户输入值原封不动地显示出来的情况。其中,输入值确定页面就是一个典型的例子。
存储型XSS:
有时攻击者也会将攻击用JavaScript代码保存至攻击对象的数据库中。这种模式的XSS就被称为存储型的XSS(Stored XSS)或持久性的XSS(Presistent XSS)。
存储型的XSS的典型攻击对象为Web邮箱客户端以及社交网站(Social Networking Service,简称SNS)。
存储型XSS无需攻击者费劲心思将用户引诱至恶意网站,而且即使是戒心很重的用户也会有很大的几率中招,因此对攻击者来说益处多多。
存储型XSS:
- 长期存储与服务器端
- 每次用户访问都会被执行JS脚本
客户端表单长度限制:
- 客户端源码修改限制
- 代理截断
DOM型XSS:
DOMXSS漏洞是基于文档对象模型(Document Object Model)的一种漏洞。
DOM是一套JS和其他语言课调用的API(遍历、获取、修改)。
根据XSS在DOM中输出点的不同,DOM XSS机有可能是反射型,也有可能是存储型。
1 | 注意:‘#’,它告诉浏览器所有在它后面的东西都是个片段,也就是不作为查询的一部分。IE(6.0)和Mozilla不会把这个片段发送到服务器,因此服务器端看到的只是#号前面提交的参数。这样如果#号后面填充了恶意脚本,就不会被服务器端看到。 |
两种典型的DOM过程:
反射型DOM base XSS:
- 用户输入带有参数的URL
- JavaScript处理URL并获取参数
- 通过DOM调用参数对页面进行排版。
- 通过DOM动态输出到页面上。
存储型DOM base XSS:
- 用户输入带有参数的URL或者Body域数据
- 服务器将参数存入数据库
- 通过JSON格式返回参数到页面
- 通过DOM调用参数进行排版
- 通过DOM动态输出到页面上。
XSS产生的根源:
XSS漏洞产生的原因为,生成HTML的过程中,HTML语法中含有特殊意义的字符(元字符)没有被正确处理,结果导致HTML或JavaScript被肆意注入,从而使得原先的HTML结构产生变化。为了消除元字符的特殊意义,将其转化为普通字符,就需要用到转义(Escape)处理。HTML的转义处理对消除XSS至关重要。
HTML转义:
在HTML中显示< 时,必须按照字符实体引用(Character Entity Reference)将其转义记载为 <;而如果忽略这一步骤直接生成HTML的话,浏览器会将 < 解释为标签的开始。从而就或招致恶意利用此漏洞进行的XSS攻击。
在HTML中,根据字符所处位置的不同,应当转义的元字符也会发生变化。
元素内容转义:
特征:能解释Tag和字符实体;结束边界字符为<。
转义:< 和 & 使用字符实体转义。
PHP转义函数:
htmlspecialchars($String, $quote_style, $charset)
$string :转换对象字符串
$quote_style:转换方法。
| 转换前 | 转换后 | ENT_NOQUOTES | ENT_COMPAT | ENT_QUOTES |
| —— | ——- | ———— | ———- | ———- |
| < | <; | 支持 | 支持 | 支持 |
| > | >; | 支持 | 支持 | 支持 |
| & | &; | 支持 | 支持 | 支持 |
| “ | "; | 不支持 | 支持 | 支持 |
| ‘ | '; | 不支持 | 不支持 | 支持 |一般使用最后一种即可:ENT_QUOTES
$charset:字符编码。如UTF-8、GBK。
属性值(双引号中南的内容)转义:
特征:能解释字符实体;结束边界字符为双引号。
转义:属性值用双引号括起来,< 和 & 和 “ 使用字符实体转义。
XSS的辅助性对策:
输入校验:通过检验输入值的有效性,当输入值不符和条件是就显示错误消息,并促使用户重新输入,有时也能够防御XSS攻击。
给Cookie添加HttpOnly属性:Cookie中有名为HttpOnly属性,该属性能禁止JavaScript读取Cookie值。
通过给Cookie添加HttpOnly属性,能够杜绝XSS中窃取会话ID这一典型的攻击手段。但需要注意的是其他攻击手段依然有效,所以这样只能是限制了攻击者的选择范围,并不能杜绝所有的XSS攻击。
php.init:session.cookie_httponly=On
XSS对策总结:
根本性对策(个别对策)
- HTML的元组内容:使用htmlspecialchars函数转义。
- 属性值:使用htmlspecialchars函数转义并用双引号括起来。
根本性对策(共通对策)
- 明确设置HTTL响应的字符编码。
辅助对策
- 输入校验
- 给Cookie添加HttpOnly属性。
XSS进阶
HTML组成元素
- 脚本(事件绑定)
- 事件绑定函数中的字符串字面量
- 属性值/(URL),属性位置防止双引号。
- 元素内容,元素位置防止尖角符号。
- script元素中南的字符串字面量
JavaScript问题:
之所以会混入安全隐患,是因为没有将JavaScript字符串字面量进行转义。因此,输入参数中的单引号没有被识别为字符,而是被当成了JavaScript中南字符串的结束符。
为了避免这种情况,理论上应采取如下措施:
- 首先,将数据作为JavaScript字符串字面量进行转义。
- 将得到的结果再次进行HTML转义。
JS字符串字面量中南应被转义的字符:
原字符 | JavaScript转义后 | HTML转义后 |
---|---|---|
<>’ “ \ | < > \‘ \“ \\ | <; >;\';\"; \\ |
1 |
|
JS字符串字面量动态生成的对策:
按照JavaScript语法,将引号(单引号及双引号)和斜杠\及换行符等进行转义。”\“” 。如果是事件绑定函数,将JS执行结果按照字符实体进行HTML转义, 并用双引号括起来。
如果是在script元素中,执行JS后,确保字符串中不存在</ 。
虽然理论上如此,但JavaScript的转义规则相当复杂,执行起来很容易产生疏漏,因此一直以来都是安全隐患诞生的温床。鉴于这种情况,最好的办法可能是避免动态生成JavaScript。然而,现实中又会经常需要传给JavaScript的参数是动态的。此时,一般使用Unicode转义的解决方案。
Unicode转义:
为了避免动态生成JavaScript带来的风险,可以采取将字母和数字以外的其他所有字符都进行转义的方法。这种方法利用了JavaScript能将Unicode代码点U+XXXX字符转义为\uXXXX的功能。
1 |
辅助方案:错误消息导致的信息泄露。
错误消息中包含对攻击者有帮助应用程序内部信息。
通过蓄意攻击使错误信息中显示隐私信息(如用户个人信息等。)
应用程序内部信息是指,发生错误的函数名、数据库的表名、列名等,这些信息都可能成为攻击的突破口。
为了解决以上问题,当应用程序发生错误时,应该仅在页面上显示“此时访问量太大,请稍后再试”等提示用户的消息。
PHP的情况下,禁止显示详细错误信息,只需要在php.ini中做如下设置:
display_errors = Off
HTML转义概要:
位置 | 说明 | 转义概要 |
---|---|---|
元素内容(普通文本) | 能解释Tag和字符实体。结束边界符为 <。 | < 和 & 使用字符实体转义。 |
属性值 | 能及时字符实体。结束边界字符为双引号 | 属性值用双引号括起来,< 和 & 和 ”使用字符实体转义 |
属性值(URL) | 同上 | 检验URL格式正确后按照属性值的规则转义。 |
时间绑定函数 | 同上 | 转义JavaScript后按照属性值的规则转义 |
script元素中字符串字面量 | 不能解释Tag和字符实体。结束边界字符为</ | 转义JavaScript并避免出现”</“ |
XSSer简介-确认XSS存在的工具
XSSer概述:
跨站点“Scripter”(又名XSSer)是一个自动化框架,用于检测、利用以及报告基于Web应用程序
中的XSS漏洞。
XSS是Web应用常见的漏洞。利用该漏洞,安全人员在网站注入恶意脚本,控制用户浏览器,并发起其他渗透操作。XSSer是Kali Linux提供的一款自动化XSS攻击框架。该工具可以同时探测多个网址。如果发现XSS漏洞,可以生成报告,并直接进行利用,如建立反向连接。为了提供攻击效率,该工具支持各种规避措施,如判断XSS过滤器、规避特定的防火墙、编码规避。同时,该工具提供丰富的选项,供用户自定义攻击,如指定攻击载荷、设置漏洞利用代码等。
一个自动框架、检测,利用和报告基于Web应用的XSS漏洞。
支持命令行、图形化界面。
提供绕过服务器过滤的选项,以及一些特殊的代码注入技术。
XSSer经典命令:
1 | -u URL, --url=URL 添加URL |
BeEF攻击简介
BeEF概述:
通过XSS漏洞,将hook.js脚本注入,可将中招的客户端挂起。
如果客户端浏览器关掉,则连接会断开。
可以做持久化连接。不让用户关闭浏览器,或者后台开一个小窗。
BeEF(Brower exploitation framerwork):
- 生成,交付Payload
- Ruby语言编写
- 服务器端:管理Hooked客户端
- 客户端:运行与客户端浏览器的JS脚本(hook)
降低白帽子对JS代码的要求。
BeEF主要针对浏览器(客户)进行攻击。
- 应用普遍转移到B/S架构,浏览器称为唯一客户端程序。
- 结合社会工程学方法对浏览器进行攻击。
- 攻击浏览器用户
- 通过注入的JS脚本,刘勇浏览器工具其他网站
BeEF攻击手段:
- 利用网站XSS漏洞实现攻击
- 诱使客户端访问包含hook的伪造网站
- 结合中间人攻击注入hook脚本
1 | 软件攻击模块颜色介绍: |
BeEF常见用途:
- 键盘记录器
- 网络扫描
- 浏览器信息收集
- 绑定shell
- 与Metasploit集成
学习笔记记录。与相关资料整理。
参考资料: