Common Web attacks and defense summary

After establishing a website, if not pay attention to security issues, it is easy to attack people, the following will discuss the situation in several loopholes and defensive approach.

A. Cross-site scripting (XSS)

Cross-site scripting attacks (XSS, Cross-site scripting) is the most common and basic method of attack WEB site. An attacker publish data contain offensive code on the page. When viewers see this page, the script will be specific to the viewer the user's identity and permissions to perform. Can be relatively easily modified by XSS user data, steal information, and cause other types of attacks, such as attacks CSRF

defense:

1, for sensitive cookie information, use HttpOnly, the document object is not found in the cookie.

2, with the information input by the user to escape.

II. Cross-site request forgery attack (CSRF)

Cross-site request forgery (CSRF, Cross-site request forgery) is another common attack. Attacker to forge a request by a variety of methods, mimic the behavior of the user to submit the form, to achieve the modification of the user data, perform a specific task or object. To fake the identity of the user, CSRF attacks and XSS attacks often meet up to do, but also through other means, such as to induce the user clicks on a link that contains attack

defense:

1. Using POST request, increasing the difficulty of attack. Users can click on a link to initiate a GET type request. The POST request is relatively difficult, attackers often require javascript to achieve

2. authenticate the request, ensure that the request is indeed my user fill out the form and submitted, rather than a third party forged particular can increase the token in the session, see the information and make sure that the information submitted is the same person

Three .Http Heads Attack

Those who view any website using WEB browser, regardless of the technology and the framework of your WEB site using, have used the HTTP protocol .HTTP agreement between the Response header and content, there is a blank line, that is, two CRLF (0x0D 0A) character. Start and end of the content of this blank line marks the headers. "Smart" An attacker could exploit this. As long as the attacker would have the means any character "injected" into the headers, this attack can occur

To landing as an example: there is such a url:

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

When the login is successful, you need to be redirected back to the page specified by the parameters of the page. Here is the response headers when the redirection occurs.

HTTP/1.1 302 Moved 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/index

If the URL changed a bit, it became like this:

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

So reponse will become when the redirection occurs following way:

HTTP/1.1 302 Moved 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>

This page may accidentally execute hidden in the URL javascript. A similar situation occurs not only in the redirection (Location header), it may also occur in other headers, as Set-Cookie header. This attack, if successful, can do many things, such as: implementation of the script, the installation of additional cookie (<CRLF> Set-Cookie: evil = value) and so on.

defense:

Filter all the response headers, removing illegal characters appear in the header, especially CRLF.

Server will generally limit the size of the request headers. For example Apache server default limit request header is 8K. If more than 8K, Aapche Server will return 400 Bad Request response:

For the most part, 8K is large enough. Suppose an application to a user input is stored in a cookie, it is possible to 8K. The attacker's header over 8k link to the victim, it will be denied access to the server. The solution is to check the size of a cookie, the new limit cookie's total capital, reducing denied access because of attacks generated header too large

IV. Authentication and Session

Hackers disabled browser JS, preventing the client-side validation, to perform certain operations.

defense:

1, hide sensitive information.

2, to encrypt sensitive information.

3, session regularly fail

V. Redirection Attack

A common means of attack is "phishing." Phishers usually send the link to a legitimate victim, when the link is clicked, the user is directed to a specious illegal websites, so as to achieve the purpose of defrauding users trust and steal user data. To prevent this behavior, we must examine all of the redirection to redirect to avoid a dangerous place.

defense:

The legitimate want to redirect url added to the white list, white list domain names on the non-repellent redirect, the second solution is to redirect token, can be validated when coupled with token, redirect url in the legal .

VI. Permissions and access control

URL parameter modification by others to achieve access page, for example, a hacker can use it to access the link to your order link on a mall

https://***.***.com/normal/item.action?orderid=51338221644

This time if the site does not verify permissions, then he can go to the link below to visit other people's orders.

https://***.***.com/normal/item.action?orderid=其他id

This way will result in the disclosure Mall others privacy.

defense:

1, add permissions system, when coupled with appropriate access can check.

VII. Unsafe storage encryption

defense:

1, the encrypted sensitive information stored

2, do not md5 encryption

Eight .SQL injection

最常见的攻击方式,所谓SQL注入,就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令,比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的,这类表单特别容易受到SQL注入式攻击.

防御:

1、表单过滤,验证表单提交的合法性,对一些特殊字符进行转义处理

2、数据库权限最小化

3、查询语句使用数据库提供的参数化查询接口,不要直接拼接SQL

九.传输层未加密

防御:

1、使用安全的https版本

2、敏感信息使用https传输

3、非敏感信息使用http传输

小编是一名有多年前端开发经验的工程师,目前转向了前端讲师岗位,作为一个老师在这里和大家定时分享一些前端和编程方面的知识,并且给大家总结和整理了一套完整的前端学习资料,想要领取并跟我一起学习的同学可以加扣扣裙:1017226689,真心希望能够帮助大家,谢谢。

Guess you like

Origin blog.csdn.net/qq_40163373/article/details/90710753