CTF study notes - cross-site scripting attack

cross site scripting attack

Introduction:

​ XSS (Cross Site Scripting), that is, cross-site scripting attack, is a common computer security vulnerability in Web applications. Malicious attackers embed malicious client-side scripts into web pages, and when users browse the web pages, the scripts will be executed on the user's browser, thereby achieving the attacker's purpose. For example, obtaining the user's cookie, navigating to a malicious website, carrying a Trojan horse, etc. With the help of a very famous sentence in the security circle: *All input is harmful. *This sentence fully reflects the essence of XSS vulnerabilities. Most of the XSS vulnerabilities are due to improper handling of user input, resulting in malicious scripts being executed in the browser. XSS is possible anywhere input submitted data is entered.

Classification:

By vulnerability cause:

1. reflective
2. storage type
3. DOM type

By output location:

1. The output is in the HTML attribute
2. The output is in the CSS code
3. The output is in JavaScript

reflective

Reflected XSS, also known as non-persistent XSS, is the most common type of XSS vulnerability. When a user accesses a URL request with XSS code, the server receives the data and processes it , and then sends the data with XSS code to the browser. After the browser parses the data with XSS code, an XSS vulnerability is finally caused. . This process is like a reflection, so it is called reflected XSS.

Non-persistent XSS vulnerabilities actually contain most of the attack data in URLs, like this:
http://www.xxxxx.com/test.asp?hi=[code]. The malicious code needs to be accessed by the user's browser to access the URL before it can be executed. The attacker usually sends the URL to the user for the user to access through the browser. However, the weird code in the URL is indeed a bit strange. In order to deceive people, the attacker can send a URL that looks good, and then jump to a malicious URL through that page, or even redirect a domain name to a malicious URL. Send that domain name to the user.
Prototype code:

<?php
echo 'your input:' - $_GET[ 'input ' ];
?>

The input value input by the client is directly output without any filtering, so the attacker can submit: http:/ /example.com/xss.php?input=<script>alert ( /xss/)</script>to attack.

storage type

Stored XSS, also known as persistent XSS, is the most dangerous type of cross-site scripting. Stored XSS vulnerabilities may occur in web applications that allow users to store data. When an attacker submits a piece of XSS code, it is received and stored by the server . When the attacker visits a page again , this XSS code is read by the program. Come out to respond to the browser , causing XSS cross-site attacks. For example, when I post a post in a forum, the forum does not process the incoming HTML, then I can post a post containing the content of the post, and then wait on the sidelines <script>[code]</script>. The person who came to see the post executed the malicious script. The persistent XSS vulnerability is to store malicious scripts in the database, and there is no warning when accessing the page. This is stored XSS.

Compared with reflective XSS and DOM XSS, stored XSS is more concealed and more harmful . The biggest difference between them is that both reflective XSS and DOM XSS must be triggered manually by the user, while stored XSS does not require manual triggering by the user .

DOM type

The full name of DOM is Document Object Model, which is the document object model . DOM is usually used to represent objects in HTML, XHTML and XML. Using the DOM allows programs and scripts to dynamically access and update the document's content, structure, and style.
The entire HTML page can be reconstructed through JavaScript, but to reconstruct the page or an object in the page, JavaScript needs to know the "position" of all elements in the HTML document. The DOM provides a structured representation of the document and defines how to access the document structure through scripts. According to the DOM, each component in an HTML document is a node. DOM-based XSS does not need to interact with the server, it only occurs in the stage of data processing by the client.

The output is in HTML

The prototype is as follows:

<input name="user" value="ii your input }}”/>

When the XSS attack payload is output in HTML attributes, the attacker needs to inject new attributes after closing the corresponding HTML attributes, or directly inject new tags after closing tags, such as input:

" onclick="alert ( /xxs/)The value attribute is closed, and a new attribute onclick is added.

or type:

"><script>alert(/xss/ )</script>This directly closes the input tag and injects the new tag.

The output is in the CSS code

The prototype is as follows:

<style type="text/css">
body {
    
    
    color:  your input ;
}
</style>

When the XSS attack Payload is output in CSS code, the attacker needs to close the corresponding CSS code, such as input:

#000 ; background-image: ur1( 'javascript:alert ( /xss/) ')Close the previous color attribute and inject the background-image attribute

output in javascript

The prototype is as follows:

<script>
var name='{
    
    { your input }}';
</ script>

When the XSS attack Payload is output in Javascript code, the attacker needs to close the corresponding Javascript code, such as input:

'+alert(/xss/)+'Closing the single quotation mark in front of it, injecting the attack code, it becomes

<script>
var name=' '+alert ( / xss/)+'';
</ script>

Features of XSS

The core of XSS: Get other people's cookies to log in to other people's accounts.
To launch an XSS attack, a specified JS statement needs to be triggered on the target website. The attacker mainly launches the attack through the following three triggering methods:
1. Tag method (also called XML method), such as:

<script>alert(1)</script>

2. Pseudo-agreement law, such as:

<a href=Javascript:alert(1)>123</a>
3. Event method, such as:

</img src=# onerror=alert(1) />

Commonly used on events are:

onerror
onload
onfocus
oninput

Protection and Bypass

1. Specific label filtering

Some developers think that filtering out dangerous tags (such as script, iframe, etc.) will make scripts impossible to execute, but in fact, any kind of tag, no matter whether it is legal or not, can construct XSS code, such as the following code:

<not_real_tag onclick="alert(/xss/) ">click me</not_real_tag>If the output point is in an attribute of an HTML tag or in Javascript code, then an attacker can simply close, concatenate attributes or Javascript code without introducing any new tags to execute XSS code.
At the same time, HTML5 also brings some new tags, which are easily overlooked by developers, such as the video tag. All in all, many tags can construct attack code.

2. Event filtering

Many times, developers will filter out the event attributes of many HTML tags. At this time, it is necessary to traverse all available event attributes to test whether the developer has missed anything. Commonly used event attributes are as follows. You can use Burp or write your own scripts for Fuzz during testing:

3. Sensitive keyword (character) filtering

(1) String concatenation confusion

Keyword filtering is mostly performed on sensitive variables or functions, such as cookie, eval, etc. This part of filtering can be bypassed by string splicing, encoding and decoding, and other methods.
For example: windowp['alert'](/xss/)it can become windowp['al'+'ert'](/xss/)because it is in the form of a string.

We can also use base64 encoding, the btoa function can encode a string into a Base64 string, and the atob function can restore the Base64 string, for example:

window[ atob ( "Ywxl"+"cnQ=" )](/xss/)is equivalent towindowp['alert'](/xss/)

(2) Encoding and decoding

String-based code obfuscation can be achieved not only through string splicing, but also through various encoding and decoding. Commonly used encoding methods in XSS vulnerabilities include:

• HTML hexadecimal encoding: decimal (a), hexadecimal (a)
• CSS hexadecimal encoding: Compatible with the hexadecimal representation in HTML, decimal, hexadecimal
• Javascript hexadecimal encoding: octal (\141), hexadecimal (\x61), Unicode encoding (\u61), ASCII (String.
• fromCharCode(97))
• URL encoding: %61
• JSFuck Coding

What is worth mentioning here is JSFuck coding, which can only use "[O!+" 6 characters to write Javascript programs, which has miraculous effects in some scenarios.

(3)location.*、window.name

Since the developer will filter the input sensitive keywords, you can place the XSS code in other parts that are not submitted to the server by the browser, such as location.*, window.name, etc. The structure of location.* is as follows:

http://example.com/xss.php?input=<input onfocus=outerHTML=decodeURI(location.hash)>#<img src=x onerror=alert( /xss/)>

The construction page of window.name is as follows:

<iframe src="http://example . com/xss.php?input=83Cinput%20onfocus=location=windowname%3E"name="javascript:alert (/xss/) "></iframe>

Using the location object in combination with string encoding can bypass many keyword-based filters. There is also a part of keyword filtering for sensitive symbols, such as brackets, spaces, decimal points, etc.

(4) Filter "."
In JavaScript, you can use the with keyword to set the scope of variables, and use this feature to bypass the filtering of ".", such as:
with(document )alert ( cookie ) ;

(5) Filter "("
In JavaScript, you can bypass the filtering of "()" by binding an error handling function and passing parameters using the throw keyword, such as:
window.onerror=alert; throw 1;

(6) Filter spaces
You can use newline characters 0x09, 0x10, 0x12, 0x13, OxOa and other characters to replace spaces between tag attributes to bypass filtering, such as:

http://example.com/xss.php?input=<img%0asrc=x80aonerror=alert ( /xss/)>

You can also use "/" instead of spaces between the tag name and the first attribute, such as:

<input/onfocus=alert(/xss/)>

(7) svg tags
The rules followed by the tags and statements inside svg are directly inherited from xml instead of html. The difference is that the script tags inside svg can allow some binary or encoded characters (such as entity encoding)
http://example.com/xss . php?input=1"><svg><script>alert%26823x28;1号26%23x29</script></svg>

4. Bypass caused by character set encoding

pikachu range practice

Reflective xss (get)

Interface display:

Here we see that the interface is an input box, and the input content will be displayed on the url, indicating that it is a GET request parameter. We can attack directly on the url. We try to simply let it pop up a box to try and enter <script>alert("123")</script>.

But we noticed that this input box has a length limit, and we cannot directly enter the above large string, so we bypass the length.

Here are the following ways:

1. Pass parameters directly in the url,?message=<script>alert("123")</script>&submit=submit&submit=submit
2. F12 to bring up the console, use the selector in the upper left corner, find the box, you can see the code of maxlength=20, double-click to select and change this 20, and then try the following. The modification here can only take effect for one round, and it needs to be modified again after refreshing.
3. Use burpsuite to capture packets, and then pass parameters. After we use this method to pass parameters, we can directly find the statement we passed in in the return packet, as it is, so we can also judge that there is an xss vulnerability.
4. 

Reflective xss (post)

For this level, you must log in with the admin account before proceeding. That is to give us experience

If you want to get the cookie, then enter the payload:<script>alert(document.cookie)</script>

This will get the admin cookie

Stored xss

There is a message board on this level page, enter the payload: <script>alert(document.cookie)</script>and the cookie will pop up. And you can see that there is a piece of data in the message table (although the data is not displayed, there is a delete button).

And we can also find the code we entered in the return packet of the captured packet.

And stored xss will also lead to an additional result, that is, when we use other browsers to come to this level page, the same bullet box will appear. It shows that stored XSS can harm all users who visit the affected pages.

DOM type xss

This level is a test of simple bypassing skills. For this question, you only need to press F12 to open and view the source code, and you will find that it has given you all the source code.

I also told you how to bypass it. In fact, how to bypass the general ctf questions depends on you to try it yourself.

DOM type xss-x

These two questions are similar, except that if you want to trigger what you input, you must click the hyperlink below. That is to say, the code is hidden in the a tag

xss touch typing

What this question wants to tell us is that when we do not find that the code we injected is executed at the front end, it may be executed in the background . In this level, we log in to the background, inject the payload in the front end and refresh the background, we will find that a frame pops up on our back-end page. Looking at the code, we found that the content we entered was indeed transmitted to the background page.

Xss filtering

This question tests simple filtering, because we found that it <script>alert("123")</script>was filtered out directly after injection, so we can use the event trigger method<img src="#" οnerrοr=alert(document.cookie)> to inject normally

htmlspecialchars of xss

At this level, you will find that the injected content is completely output to the page and becomes a hyperlink, so consider that there is an a tag here. Therefore, in this level, we only need to close the attribute of the a tag and use onclick to trigger it.

But this level tried to close the a tag and found that it didn't work because the angle brackets were filtered out, but we can close the tag attribute because the single quotes were not filtered out.

href output of xss

In this question, we found that the left and right angle brackets and single quotes are encoded by html, so we choose the pseudo-protocol trigger method and use the payload:

javascript:alert(document.cookie)

js output of xss

This question puts the content we entered <script>into the tag, and it is not encoded. So we close the field and write the script code directly. Input payload: ';alert(123);//