XSS基础学习笔记

2023-03-25 20:09| 来源: 网络整理| 查看: 265

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和字符实体；结束边界字符为 | ； | 支持 | 支持 | 支持 || & | ； | 支持 | 支持 | 支持 || “ | ； | 不支持 | 支持 | 支持 || ‘ | '； | 不支持 | 不支持 | 支持 |

一般使用最后一种即可：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字符串字面量中南应被转义的字符：

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

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

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

【本文地址】

XSS基础学习笔记

XSS基础学习笔记

今日新闻

推荐新闻