XSS基础学习笔记
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机有可能是反射型，也有可能是存储型。
注意：‘#’，它告诉浏览器所有在它后面的东西都是个片段，也就是不作为查询的一部分。IE（6.0）和Mozilla不会把这个片段发送到服务器，因此服务器端看到的只是#号前面提交的参数。这样如果#号后面填充了恶意脚本，就不会被服务器端看到。
如果服务器端直接读取客户端提交参数的所有，重写改写页面，就会将恶意脚本写到页面。在写页面时，需要先使用URL解码。
两种典型的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转义后 |
|---|---|---|
| <>’ " \ | < > \’ \" \\ | <； >；'；"； \\ |
function escape_js($s){
return mb_ereg_replace('([\\\\\'])', '\\\1', $s);
}
?>
<body onload="init('$_GET('name')), ENT_QUOTES, "UTF-8"); ?>')">
</body>
JS字符串字面量动态生成的对策：
按照JavaScript语法，将引号（单引号及双引号）和斜杠\及换行符等进行转义。"\"" 。如果是事件绑定函数，将JS执行结果按照字符实体进行HTML转义， 并用双引号括起来。
如果是在script元素中，执行JS后，确保字符串中不存在
虽然理论上如此，但JavaScript的转义规则相当复杂，执行起来很容易产生疏漏，因此一直以来都是安全隐患诞生的温床。鉴于这种情况，最好的办法可能是避免动态生成JavaScript。然而，现实中又会经常需要传给JavaScript的参数是动态的。此时，一般使用Unicode转义的解决方案。
Unicode转义：
为了避免动态生成JavaScript带来的风险，可以采取将字母和数字以外的其他所有字符都进行转义的方法。这种方法利用了JavaScript能将Unicode代码点U+XXXX字符转义为\uXXXX的功能。
辅助方案：错误消息导致的信息泄露。
- 错误消息中包含对攻击者有帮助应用程序内部信息。
- 通过蓄意攻击使错误信息中显示隐私信息（如用户个人信息等。）
应用程序内部信息是指，发生错误的函数名、数据库的表名、列名等，这些信息都可能成为攻击的突破口。
为了解决以上问题，当应用程序发生错误时，应该仅在页面上显示“此时访问量太大，请稍后再试”等提示用户的消息。
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经典命令：
-u URL, --url=URL 添加URL
-g Getdata 使用GET提交数据
-p POSTdata 使用post提交数据
--cookie=COOKIE 提供cookie信息
-s, --statistics 显示统计信息
-v, --verbose 展示详细结果
--reverse-check 反向连接检查
BeEF攻击简介
BeEF概述：
通过XSS漏洞，将hook.js脚本注入，可将中招的客户端挂起。
如果客户端浏览器关掉，则连接会断开。
可以做持久化连接。不让用户关闭浏览器，或者后台开一个小窗。
BeEF（Brower exploitation framerwork）：
- 生成，交付Payload
- Ruby语言编写
- 服务器端：管理Hooked客户端
- 客户端：运行与客户端浏览器的JS脚本（hook）
降低白帽子对JS代码的要求。
BeEF主要针对浏览器（客户）进行攻击。
- 应用普遍转移到B/S架构，浏览器称为唯一客户端程序。
- 结合社会工程学方法对浏览器进行攻击。
- 攻击浏览器用户
- 通过注入的JS脚本，刘勇浏览器工具其他网站
BeEF攻击手段：
- 利用网站XSS漏洞实现攻击
- 诱使客户端访问包含hook的伪造网站
- 结合中间人攻击注入hook脚本
软件攻击模块颜色介绍：
- 绿色模块：表示模块适合目标浏览器，并且执行结果客户端不可见
- 红色模块：表示模块不适合目标浏览器，有些红色模块也可正常运行
- 橙色模块：模块可用，但是结果对用户可见（例如：弹窗申请全新等）
- 灰色模块：模块未在目标浏览器测试过
BeEF常见用途：
- 键盘记录器
- 网络扫描
- 浏览器信息收集
- 绑定shell
- 与Metasploit集成
学习笔记记录。与相关资料整理。
参考资料：
https://blog.csdn.net/daxueba/article/details/77703872
http://blog.nsfocus.net/xss-advance/#_XSS