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被恶意使用的三种方法:

  1. 窃取Cookie值
  2. 通过JavaScript攻击
  3. 篡改网页

同源策略:

  • 同源策略:来自相同网站的页面。
  • 不同源策略:来自不同网站的页面。

跨站脚本类型:

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: **

  1. 用户输入带有参数的URL
  2. JavaScript处理URL并获取参数
  3. 通过DOM调用参数对页面进行排版。
  4. 通过DOM动态输出到页面上。

存储型DOM base XSS:

  1. 用户输入带有参数的URL或者Body域数据
  2. 服务器将参数存入数据库
  3. 通过JSON格式返回参数到页面
  4. 通过DOM调用参数进行排版
  5. 通过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_NOQUOTESENT_COMPATENT_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的功能。


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

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

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

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

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


已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 技术工厂 设计师:CSDN官方博客 返回首页