Common attack methods and solutions for Web sites

After a site is established, if you do not pay attention to security problems, it is easy to be attacked, the following discussion of several vulnerabilities and ways to prevent attacks.

I. Cross-site scripting attacks (XSS)

Cross-site scripting attacks (Xss,cross-site scripting) are the most common and basic way to attack Web sites. An attacker publishes data on a Web page that contains offensive code. When a browser sees this page, a particular script is executed with the identity and permissions of the user of the browser. XSS makes it easier to modify user data, steal user information, and cause other types of attacks, such as CSRF attacks

Common workaround: Ensure that data that is output to an HTML page is escaped in HTML form

A bug in the wrong page could also cause an XSS attack. For example, page/gift/giftlist.htm?page=2 can not be found, error page directly to the URL as output, if the attacker after the URL with the attack code sent to the victim, there may be an XSS attack

Two. Cross-site request forgery attack (CSRF)

Cross-site requests forgery (Csrf,cross-site request forgery) is another common attack. An attacker can forge a request in various ways, mimicking the behavior of a user submitting a form, to modify the user's data, or to perform a specific task. To impersonate a user, csrf attacks often work with XSS attacks, but can also be done by other means, such as convincing a user to click on a link containing an attack
The ideas to be resolved are:
1. Use the POST request to increase the difficulty of the attack. A user clicks on a link to initiate a Get type request. While post requests are relatively difficult, attackers often need JavaScript to implement
2. Certify the request and make sure that the request is indeed made by the user himself and submitted, not by a third party. You can add tokens to your session to make sure that you see the information and submit it to the same person

three. Http heads attack

Whenever you view any Web site in a browser, the HTTP protocol is used, no matter what technology or framework your Web site uses. The HTTP protocol has a blank line between the response header and content, which is two sets of CRLF (0x0D 0A) characters. This empty line marks the end of headers and the beginning of the content. "Smart" attackers can take advantage of this. This attack can occur as long as an attacker has the means to "inject" any character into the headers.

To log in as an example: there is such a URL:

Http://localhost/login?page=http%3A%2F%2Flocalhost%2Findex

When the login succeeds, you need to redirect back to the page specified by the page parameter. The following is the response headers when redirection occurs.

http/1.1 302 Moved temporarily
Date:tue, 20:00:29 GMT
Server:apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 frontpage/5.0.2.2635
Location:http://localhost/index

If you change the URL, it looks like this:

Http://localhost/login?page=http%3A%2F%2Flocalhost%2Fcheckout%0D%0A%0D%0A%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E

Then the reponse at the time of redirection will look something like this:
http/1.1 302 Moved temporarily
Date:tue, 20:00:29 GMT
Server:apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 frontpage/5.0.2.2635
Location:http://localhost/checkout<crlf>
<CRLF>
<script>alert (' Hello ') </script>

This page may accidentally execute JavaScript hidden in the URL. A similar situation occurs not only on the redirect (location header), but also in other headers, such as the Set-cookie header. This attack, if successful, can do many things, such as executing scripts, setting up additional cookies (<crlf>set-cookie:evil=value), and so on.
The way to avoid this attack is to filter all response headers, except for illegal characters appearing in the header, especially CRLF.

The server generally restricts the size of the request headers. For example, the Apache server default limit request header is 8K. If more than 8k,aapche server will return the response to the request:
For most cases, 8K is large enough. It is possible for an application to store a user-entered content in a cookie that is more than 8K. An attacker who sends more than 8k header links to a victim is denied access by the server. The solution is to check the size of the cookie and limit the total capitalization of the new cookie. Reduce denial of access attacks due to too large headers

Four. Cookie attack

Cookies are very easy to access to the current Web site through Java script. You can open any Web site and enter it in the browser's address bar: Javascript:alert (Doucment.cookie) and immediately see the current site's cookie (if any). Attackers can take advantage of this feature to get your critical information. For example, in conjunction with an XSS attack, an attacker executes a specific Java script script on your browser to obtain your cookie. Assuming that the site relies solely on cookies to authenticate users, an attacker could impersonate you to do something.
Most browsers now support httponly markings on cookies, which are not available through Java script, and will greatly enhance the security of cookies if they are marked on key cookies.

Five. REDIRECT Attack

A common attack tactic is "fishing". Phishing attackers, usually sent to the victim a legitimate link, when the link is clicked, the user is directed to a specious illegal website, so as to cheat the user trust, steal user data. To prevent this behavior, we have to audit all redirect operations to avoid redirecting to a dangerous place. A common solution is a whitelist that adds legitimate URLs to be redirected to a whitelist, a non-whitelist domain redirection rejection, and a second solution is redirect tokens, Tokens are added to the legal URL and are verified when redirected.

Six. Upload file attack

1. File name attack, upload the file using the file name before uploading, may cause: the client and service side character code is not compatible, resulting in file name garbled problem; The file name contains the script, which causes the attack.

2. File suffix attack. The suffix of the uploaded file may be exe executable, JS script and other files, these programs may be executed on the victim's client, and may even be executed on the server. So we have to filter the file name suffix to exclude those that are not allowed.

3. File content attack. IE6 has a serious problem, it does not trust the content type sent by the server, but instead automatically identifies the type of file based on the contents of the file and displays or executes the file based on the type of recognition. If you upload a GIF file, put a JS attack script at the end of the file, can be executed. This attack, its file name and content type appear to be legitimate GIF pictures, but its content contains scripts, such an attack can not be excluded by file name filtering, but must scan the contents of their files to be recognized.

Common attack methods and solutions for Web sites