Parsing of cross-site scripting attacks and Cross-Site Request Forgery

The Cross-Site vulnerabilities mentioned here include cross-site scripting attacks, cross-site request forgery, and other same-source attacks. These attacks are currently very common attacks. This article can be viewed by Web developers or by website administrators.

The same-origin policy was initially released with Netscape's browser. Its main role was to define how browsers and related programming languages should handle security issues. The purpose of this policy is to restrict a website to access functions on other websites and allow the website to freely control the code source on the URI. In other words, only allow scripts to process other scripts, port 80, and Protocols on the same domain name.

 

Same-source attacks mainly involve several attack methods: cross-site scripting attacks, Cross-Site Request Forgery, cross-site request tracking, website cache poisoning, HTTP Response Splitting, HTTP Request Smuggling, HTML and JavaScript web scanning.

Cross-Site Scripting

XSS is a security vulnerability that allows malicious code injection into webpages. This attack is mainly used:

A. phishing or cookie Stealing aims to access restricted information.

B. Launching social engineering attacks to spoof, target other websites or

C. execute malicious code on the client of the website

This type of attack can be broken or spoofed by using the IMG mark, such as closing the window of the user's browser, opening a window with neither menus nor toolbar, and playing some spoof sounds.

1. Attack principles and types

So how is this attack carried out? In general, it is divided into two types: one is a reflection-type attack, which tracks the identity authentication of a website through cookies. Such websites are generally not safe and vulnerable to cross-site scripting attacks. Use social engineering (for example, tell the user "you have won the prize !"), If the target user is spoofed and the attacker clicks a link that injects malicious code into the standard HTML code, the attacker can access the user's cookie information (Session and authentication information ). The second is storage-type attacks. The principle is: if a website uses a backend database as the source of information for searching web pages, hackers do not inject malicious code into normal pages, instead, it injects SQL code into such a database. Therefore, every time a query result is returned from a backend database, the malicious code of the attacker is contained. It can be imagined that this attack is not targeted at any client, but infected with the user group of the entire forum and infected with a large number of easy-to-trust victims.

2. The most important thing to prevent is to protect the code.

You should restrict the display of user input information, implement filtering, and only display absolutely required information. We recommend that you verify and clear all forms of data, data sources, and URL parameters that you cannot directly control.

A practical technique is to use HTML entities (such as &) to replace special characters. To reduce the number of specific HTML characters, you must restrict user input and only allow valid code segments for the website. For example, many forums use the {B} mark to enable users to input uppercase characters. However, in typical cases, these sites do not allow you to add your own forms, so you should not allow the form. In addition, if these tags have specific syntaxes and values, you should only allow values that are consistent with their syntax (for example, the font color is a value that contains only three or six characters of the letter A-F or number 0-9, so if you allow the user to enter the entire SQL statement, that's worse .)

In addition, most cleanup routines use

Mark to replace carriage returns and line breaks, and some harmful words, such as "script", which depend on specific applications, but many websites have reasons to use such words, therefore, these measures are difficult to popularize.

The following are several unsafe examples:

Python example:
Print "<script> alert (xss); </script>"
Example of ASP:
<% = "<Script> alert (xss); </script>" %>
Writing such text directly to HTML will result in:
<Script> alert (xss); </script>
Here you can see the legal HTML, so it will be processed:
The following are several safe examples:
Python:
Print cgi. escape ("<script> alert (xss); </script> ")
ASP:
<% = HTMLEncode ("<script> alert (xss); </script>") %>
Cross-Site Request Forgery

Cross-Site Request Forgery is another same-origin policy attack, which aims to trick victims into loading a webpage containing malicious requests and require users to enter their accounts and passwords. This spoofing relies on users' trust in their identity information. Users generally think that they are only executing different tasks, but only using an HTTP request. Attackers use the user's browser to send attacks to the target site.

1. Principles of Cross-Site Request Forgery

First, attackers can publish links to malicious sites to the target site. Then, some trust users can browse malicious websites to become victims. What's more, they will become accomplices. When a user is tricked into submitting a form to the original target website (a website with a malicious link implanted initially), the user will become an accomplice of the attacker. Because the user has passed the authentication, the target website will accept the form submission request and allow the user to modify sensitive data, such as the user's own password or obtain key information from the website.

2. Protection Code

First, you must check the REQUEST link REQUEST to restrict access to POST or Web applications.

Note: Some browsers have an empty link request, which should also be blocked.

Therefore, mutual authentication is generally a token-based authentication request. That is, if a data packet contains an appropriate confidential value, the data can be pasted. This security mechanism is also enhanced by implementing the write process or validation page in multiple steps.

Summary

The same-origin policy is a concept implemented in most browsers, but it can be exploited by XSS attacks (it exploits a user's trust in a website or application ), XSRF can also be used (It exploits the trust of websites or applications on users ).

In short, our strategy is: Never trust anyone!

Think of trust as a two-way street: You will never know which direction there will be traffic. Anyone can dive into the trust relationship and abuse this trust relationship.

Therefore, I will give the following points:

1. Protect your code and client: Verify or filter all remote data input.

2. warn users not to browse at will. Educate users to know exactly where they are being navigated.