** After the establishment of a website, if you do not pay attention to security issues, it is easy to be attacked, the following discussion on the vulnerability of the focus and the method of placing attacks. **

A, SQL injection:

The so-called SQL injection is to trick the server into executing malicious SQL commands by inserting SQL commands into a Web form submission or query string for entering a domain name or page request. Specifically, it is the use of existing applications, the ability to inject malicious SQL commands into the background database engine execution, it can be a Web form by entering malicious SQL statements to get a vulnerability of the database on the website, rather than according to the designer intended to execute SQL statements. For example, many film and television websites leaked VIP members’ passwords mostly through WEB forms submitted query characters burst out, which are particularly vulnerable to SQL injection attacks.

Principle: SQL injection attacks is by constructing a special input as a parameter to a web application, and some combination of these input is mostly in the SQL syntax, by executing SQL statements and execution of the attacker’s to the operation, its main reason is that the program did not carefully to filter the user input data, the illegal data into the system. According to relevant technical principles, SQL injection can be divided into platform layer injection and code layer injection. The former is caused by insecure database configuration or database platform vulnerabilities; The latter is mainly due to the programmer not filtering the input carefully and thus performing illegal data queries.

The reason:

  1. Improper type handling
  2. Unsafe database configuration
  3. Improper query set processing
  4. Improper error handling
  5. Improper escape character handling
  6. Multiple submissions were mishandled

Methods:

  1. Never information user input. Verify user input, either through regular expressions or by limiting the length; Convert single quotes and double “-“, etc.
  2. Never use dynamically assembled SQL, instead use parameterized SQL or use stored procedures directly for data query access
  3. Never use database connections with administrator privileges. Use separate, limited database connections for each application

4. Don’t store confidential information directly, encrypt or hash passwords and sensitive information.

5. The exception information of the application should be displayed as little as possible. It is better to use custom error information to wrap the original error information

6. Auxiliary software or website platforms are generally used for SQL injection detection, and SQL injection detection tools such as JSKY and MDCSOFT SCAN are generally used for software detection. Mdcsoft-ips can effectively defend against SQL injection and XSS attacks

XSS (Cross-site Scripting)

Cross-site scripting attacks (XSS) are the most common and basic method of attacking WEB sites. Attackers publish data containing offensive code on web pages. When the viewer sees the page, the specific script is executed with the viewer’s user identity and permissions. XSS makes it easier to modify user data, steal user information, and cause other types of attacks, such as CSRF attacks.

Workaround: Ensure that data output to HTML pages is escaped in HTML fashion

An XSS attack can also be caused by a bug in the wrong page, such as page /gift/ giftlist.htm? Page =2 not found. The error page outputs the URL as is. If an attacker sends the victim an attack code after the URL, an XSS attack may occur.

**** Cross-site Request Forgery Attack (CSRF) :

Cross-site Request Forgery (CSRF) is another common attack. An attacker counterfeits a request through various methods, mimicking the behavior of a user submitting a form, so as to modify the user’s data or perform a specific task. CSRF attacks are often done in conjunction with XSS attacks to impersonate users, but they can also be done by other means, such as tricking the user into clicking on a link that contains an attack.

Solutions:

1. POST requests are used to increase the attack difficulty. The user clicks on a link to initiate a GET request. POST requests are relatively difficult, and attackers often need javascript to implement them

2. Authenticate the request to ensure that it was actually filled out and submitted by the user and not forged by a third party. You can add tokens to the session to ensure that the same person sees and submits the information

****Http Heads attack:

Whenever you view any WEB site in a browser, no matter what technology or framework your WEB site uses, HTTP is used. HTTP protocol has an empty line between the Response header and content, namely two groups of CRLF (0x0D 0A) characters. This blank line marks the end of headers and the beginning of Content. “Smart” attackers can take advantage of this. This attack can occur whenever an attacker has a way to “inject” arbitrary characters into HEADERS.

Take login for example: there is a URL: http://localhost/login? page=http%3A%2F%2Flocalhost%2Findex

When the login is successful, you need to redirect back to the page specified by the page parameter. Here is the response Headers when the redirect occurs.

HTTP/1.1 302 Moved TemporarilyDate: Tue, 17 Aug 2010 20:00:29 GMTServer: Apache mod_fcgid / 2.3.5 mod_auth_passthrough mod_bwlimited/FrontPage 1.4/2.1/5.0.2.2635 Location: http://localhost/indexCopy the code

Suppose we change the URL to look like this:

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

The reponse when the redirection occurs looks like this:

HTTP/1.1 302 Temporarily Date: Tue, 17 Aug 2010 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>Copy the code

This page might accidentally execute javascript hidden in the URL. A similar situation can occur not only with Location headers, but also with other headers, such as set-cookie headers. This attack, if successful, can do many things, such as executing scripts, setting extra cookies (set-cookie: EVIL =value), etc.

To avoid this attack, filter all response Headers to remove illegal characters in headers, especially CRLF.

Servers typically limit the size of the Request Headers. For example, the Apache Server limits the Request header to 8K by default. If the number exceeds 8K, Aapche Server will return 400 Bad Request response:

For most cases, 8K is sufficient. If the application saves something entered by the user in a cookie, it can exceed 8K. If an attacker sends a header link larger than 8K to the victim, the server will reject the access. The solution is to check the size of cookies, limit the total capitalization of new cookies, and reduce access denial attacks caused by too large headers.

V. ****Cookie attack:

It is very easy to access the cookies of the current website through JavaScript. You can open any website and type: javascript:alert(doucment.cookie) into your browser’s address bar to instantly see the cookies (if any) for your current site. Attackers can use this feature to gain access to critical information about you. For example, in conjunction with an XSS attack, an attacker executes a specific JavaScript script on your browser to retrieve your cookies. Assuming the site relies solely on cookies to authenticate users, an attacker could impersonate your identity to do something.

Now most browsers support cookies on the HttpOnly mark, where the flag of the cookie can not be obtained through JavaScript, if the key cookie on this mark, will greatly enhance the security of cookies

Redirect attack:

A common means of attack is “fishing”. Phishing attacks usually send victims a legitimate link, when the link is clicked, the user is directed to a plausible illegal website, so as to achieve the purpose of cheating users trust, stealing user information. To prevent this behavior, we must audit all redirects to avoid redirecting to a dangerous place. A common solution is to whitelist valid urls to be redirected and reject non-whitelisted domain names when redirected. The second solution is to redirect tokens, which are added to legitimate urls and validated when redirected.

Vii. File upload attack:

1. File name attack: The uploaded file uses the original file name, which may cause: Character codes on the client and server are incompatible, resulting in garbled file names. The file name contains the script, thus causing the attack.

2. File suffix attack: The suffix of an uploaded file may be an exe executable program or JS script. These programs may be executed on the victim’s client or even on the server. So we must filter file name suffixes to exclude those that are not permitted.

3. File content attack, IE6 has a very serious problem, it does not trust the content type sent by the server, but automatically identifies the file type according to the file content, and according to the recognized type to display or execute the file. If you upload a GIF file and put a JS attack script at the end of the file, it can be executed. An attack whose file name and content Type appear to be legitimate GIFs, but whose content contains scripts, cannot be ruled out by file name filtering, but must be identified by scanning the file contents.

The above is a summary of the details of common WEB front-end attacks and solutions