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
2

注意：‘#’，它告诉浏览器所有在它后面的东西都是个片段，也就是不作为查询的一部分。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）将其转义记载为 &lt；而如果忽略这一步骤直接生成HTML的话，浏览器会将 < 解释为标签的开始。从而就或招致恶意利用此漏洞进行的XSS攻击。

在HTML中，根据字符所处位置的不同，应当转义的元字符也会发生变化。

元素内容转义：

特征：能解释Tag和字符实体；结束边界字符为<。
转义：< 和 & 使用字符实体转义。

PHP转义函数：

htmlspecialchars($String, $quote_style, $charset)

$string ：转换对象字符串

$quote_style：转换方法。

| 转换前 | 转换后 | ENT_NOQUOTES | ENT_COMPAT | ENT_QUOTES |
| —— | ——- | ———— | ———- | ———- |
| < | &lt； | 支持 | 支持 | 支持 |
| > | &gt； | 支持 | 支持 | 支持 |
| & | &amp； | 支持 | 支持 | 支持 |
| “ | &quot； | 不支持 | 支持 | 支持 |
| ‘ | &#39； | 不支持 | 不支持 | 支持 |

一般使用最后一种即可：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转义后
<>’ “ \	< > \‘ \“ \\	&lt； &gt；\&#39；\&quot； \\

<?php
function escape_js($s){
    return mb_ereg_replace('([\\\\\'])', '\\\1', $s);
}
?>

<body onload="init('<?php echo htmlspecialchars(escape_js($_GET('name')), ENT_QUOTES, "UTF-8"); ?>')">
</body>

JS字符串字面量动态生成的对策：

按照JavaScript语法，将引号（单引号及双引号）和斜杠\及换行符等进行转义。”\“” 。如果是事件绑定函数，将JS执行结果按照字符实体进行HTML转义，并用双引号括起来。

如果是在script元素中，执行JS后，确保字符串中不存在</ 。

虽然理论上如此，但JavaScript的转义规则相当复杂，执行起来很容易产生疏漏，因此一直以来都是安全隐患诞生的温床。鉴于这种情况，最好的办法可能是避免动态生成JavaScript。然而，现实中又会经常需要传给JavaScript的参数是动态的。此时，一般使用Unicode转义的解决方案。

Unicode转义：

为了避免动态生成JavaScript带来的风险，可以采取将字母和数字以外的其他所有字符都进行转义的方法。这种方法利用了JavaScript能将Unicode代码点U+XXXX字符转义为\uXXXX的功能。

1
2

辅助方案：错误消息导致的信息泄露。

错误消息中包含对攻击者有帮助应用程序内部信息。
通过蓄意攻击使错误信息中显示隐私信息（如用户个人信息等。）

应用程序内部信息是指，发生错误的函数名、数据库的表名、列名等，这些信息都可能成为攻击的突破口。

为了解决以上问题，当应用程序发生错误时，应该仅在页面上显示“此时访问量太大，请稍后再试”等提示用户的消息。

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

记录一些学习资料

XSS基础学习笔记