from : https://ruby-china.org/topics/19389总结web应用中常用的各种cachecache是提高应用性能重要的一个环节，写篇文章总结一下用过的各种对于动态内容的cache。文章以Nginx，Rails，Mysql，Redis作为例子，换成其他web服务器，语言，数据库，缓存服务都是类似的。以下是3层的示意图，方便后续引用： +-------+1 | Nginx | +-+-+-+-+ | | | +---------------+ | +---------------+ | | | +---+---+ +---+---+ +---+---+2 |Unicorn| |Unicorn| |Unicorn| +---+---+ +---+---+ +---+---+ | | | | | | | +---+---+ |3 +-------------+ D B +-------------+ +-------+1. 客户端缓存一个客户端经常会访问同一个资源，比如用浏览器访问网站首页或查看同一篇文章，或用app访问同一个api，如果该资源和他之前访问过的没有任何改变，就可以利用http规范中的304 Not Modified 响应头(http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5 )，直接用客户端的缓存，而无需在服务器端再生成一次内容。在Rails里面内置了fresh_when这个方法，一行代码就可以完成：class ArticlesController def show @article = Article.find(params[:id]) fresh_when :last_modified => @article.updated_at.utc, :etag => @article endend下次用户再访问的时候，会对比request header里面的If-Modified-Since和If-None-Match，如果相符合，就直接返回304，而不再生成response body。但是这样会遇到一个问题，假设我们的网站导航有用户信息，一个用户在未登陆专题访问了一下，然后登陆以后再访问，会发现页面上显示的还是未登陆状态。或者在app访问一篇文章，做了一下收藏，下次再进入这篇文章，还是显示未收藏状态。解决这个问题的方法很简单，将用户相关的变量也加入到etag的计算里面： fresh_when :etag => [@article.cache_key, current_user.id] fresh_when :etag => [@article.cache_key, current_user_favorited]另外提一个坑，如果nginx开启了gzip，对rails执行的结果进行压缩，会将rails输出的etag header干掉，nginx的开发人员说根据rfc规范，对proxy_pass方式处理必须这样（因为内容改变了），但是我个人认为没这个必要，于是用了粗暴的方法，直接将src/http/modules/ngx_http_gzip_filter_module.c这个文件里面的这行代码注释掉，然后重新编译nginx： //ngx_http_clear_etag(r);或者你可以选择不改变nginx源代码，将gzip off掉，将压缩用Rack中间件来处理： config.middleware.use Rack::Deflater除了在controller里面指定fresh_when以外，rails框架默认使用Rack::ETag middleware，它会自动给无etag的response加上etag，但是和fresh_when相比，自动etag能够节省的只是客户端时间，服务器端还是一样会执行所有的代码，用curl来对比一下。Rack::ETag自动加入etag：curl -v http://localhost:3000/articles/1< Etag: "bf328447bcb2b8706193a50962035619"< X-Runtime: 0.286958curl -v http://localhost:3000/articles/1 --header 'If-None-Match: "bf328447bcb2b8706193a50962035619"'< X-Runtime: 0.293798用fresh_when：curl -v http://localhost:3000/articles/1…
第1集:锦绣华南 http://t.cn/zWZF3Er第2集:云翔天边 http://t.cn/zWZF13x第3集:神奇高原 http://t.cn/zWZFB3A第4集:风雪塞外 http://t.cn/zWZFrmJ第5集:沃土中原 http://t.cn/zWZFdYW第6集:潮涌海岸[去旅行]
from: http://www.html-js.com/article/2134Underscore 简介Underscore 是一个JavaScript实用库,提供了类似Prototype.js的一些功能,但是没有继承任何JavaScript内置对象。它弥补了部分jQuery没有实现的功能,同时又是Backbone.js必不可少的部分。Underscore提供了80多个函数,包括常用的: map, select, invoke — 当然还有更多专业的辅助函数,如:函数绑定, JavaScript模板功能, 强类型相等测试, 等等. 在新的浏览器中, 有许多函数如果浏览器本身直接支持,将会采用原生的,如 forEach, map, reduce, filter, every, some 和 indexOf.个人感受Underscore 是一个我坚持看完的js源代码，他简单、易懂、实用，细心观察就会发现，每个函数都很简短，作为开源阅读源码，我相信Underscore是不错的选择笔记1：大量的这种方法，应该是 防止原始方法被篡改，同时加快运行速度，而且在严格模式，也不让通过arguments.callee 调用相关方法的原因吧var ArrayProto = Array.prototype, ObjProto = Object.prototype, FuncProto = Function.prototype;// Create quick reference variables for speed access to core prototypes.varpush = ArrayProto.push, slice = ArrayProto.slice, concat = ArrayProto.concat, toString = ObjProto.toString, hasOwnProperty = ObjProto.hasOwnProperty;2：void 0，开始还好奇为啥用void 0，是undefined 的缩写？后来一打听才知道，原来undefined在旧版本的浏览器中是不可以被赋值的，而新版本的浏览器是可以被赋值的，为了准确的判断，所以就有了void 0_.first = _.head = _.take = function(array, n, guard) { if (array == null) return void 0; if ((n == null) || guard) return array[0]; if (n < 0) return []; return slice.call(array, 0, n);};3：代码短小精干Underscore 代码短小精干没的说，真是精品除了 eq 这个方法长点外 其他方法都很短4：遗憾 这次走读 没记录笔记没调试本菜鸟第一次走读源码 同时欢迎大家把源码走读 放到这个专栏下 O(∩_∩)O~
from: http://witmax.cn/cache-writing-policies.htmlCache写机制参考[http://en.wikipedia.org/wiki/Cache#Writing_Policies](http://en.wikipedia.org/wiki/Cache#Writing_Policies)上的说明，Cache写机制分为write through和write back两种。Write-through- Write is done synchronously both to the cache and to the backing store.Write-back (or Write-behind) – Writing is done only to the cache. A modified cache block is written back to the store, just before it is replaced.Write-through（直写模式）在数据更新时，同时写入缓存Cache和后端存储。此模式的优点是操作简单；缺点是因为数据修改需要同时写入存储，数据写入速度较慢。 Write-back（回写模式）在数据更新时只写入缓存Cache。只在数据被替换出缓存时，被修改的缓存数据才会被写到后端存储。此模式的优点是数据写入速度快，因为不需要写存储；缺点是一旦更新后的数据未被写入存储时出现系统掉电的情况，数据将无法找回。Write-misses写缺失的处理方式对于写操作，存在写入缓存缺失数据的情况，这时有两种处理方式：Write allocate (aka Fetch on write) – Datum at the missed-write location is loaded to cache, followed by a write-hit operation. In this approach, write misses are similar to read-misses.No-write allocate (aka Write-no-allocate, Write around) – Datum at the missed-write location is not loaded to cache, and is written directly to the backing store. In this approach, actually only system reads are being cached.Write allocate方式将写入位置读入缓存，然后采用write-hit（缓存命中写入）操作。写缺失操作与读缺失操作类似。No-write allocate方式并不将写入位置读入缓存，而是直接将数据写入存储。这种方式下，只有读操作会被缓存。无论是Write-through还是Write-back都可以使用写缺失的两种方式之一。只是通常Write-back采用Write allocate方式，而Write-through采用No-write allocate方式；因为多次写入同一缓存时，Write allocate配合Write-back可以提升性能；而对于Write-through则没有帮助。处理流程图Write-through模式处理流程： [](http://upload.wikimedia.org/wikipedia/commons/thumb/c/c5/Write_through_with_no-write_allocation.png/445px-Write_through_with_no-write_allocation.png "A Write-Through cache with No-Write Allocation")A Write-Through cache with No-Write AllocationWrite-back模式处理流程： [](http://upload.wikimedia.org/wikipedia/commons/thumb/a/ad/Write_back_with_write_allocation.png/468px-Write_back_with_write_allocation.png "A Write-Back cache with Write Allocation")A Write-Back cache with Write Allocation
from: http://drops.wooyun.org/tips/11660x00 背景在统计了Alexa top 100万网站的header安全分析之后（2012年11月 - 2013年3月 - 2013年11月），我们发现其实如何正确的设置一个header并不是一件容易的事情。尽管有数不胜数的网站会使用大量有关安全方面的header，但并没有一个像样的平台能够为开发者们提供必要的信息，以辨别那些常见的错误设置。或者说，即使这些安全方面的header设置正确了，也没有一个平台能够为开发者提供一个系统的测试方法，用来测试正确与否。这些header如果设置错误了不仅会产生安全的假象，甚至会对网站的安全产生威胁。veracode认为安全性header是网络防护中非常重要的一环，并且他希望让开发者们能够简捷、正确地设置站点。如果您对某一header或设置有任何疑问，我们有极好的资源能够追踪到浏览器支持情况。 0x01 细节1. X-XSS-Protection目的这个header主要是用来防止浏览器中的反射性xss。现在，只有IE，chrome和safari（webkit）支持这个header。正确的设置0 – 关闭对浏览器的xss防护 1 – 开启xss防护 1; mode=block – 开启xss防护并通知浏览器阻止而不是过滤用户注入的脚本。 1; report=http://site.com/report – 这个只有chrome和webkit内核的浏览器支持，这种模式告诉浏览器当发现疑似xss攻击的时候就将这部分数据post到指定地址。 通常不正确的设置0; mode=block; – 记住当配置为0的时候，即使加了mode=block选项也是没有效果的。需要指出的是，chrome在发现这种错误的配置后还是会开启xss防护。 1 mode=block; – 数字和选项之间必须是用分号分割，逗号和空格都是错误的。但是这种错误配置情况下，IE和chrome还是默认会清洗xss攻击，但是不会阻拦。如何检测如果过滤器检测或阻拦了一个反射性xss以后,IE会弹出一个对话框。当设置为1时，chrome会隐藏对反射性xss的输出。如果是设置为 1; mode=block ,那么chrome会直接将user-agent置为一个空值:, URL 这种形式。参考文献Post from Microsoft on the X-XSS-Protection HeaderChromium X-XSS-Protection Header Parsing SourceDiscussion of report format in WebKit bugzilla2. X-Content-Type-Options目的这个header主要用来防止在IE9、chrome和safari中的MIME类型混淆攻击。firefox目前对此还存在争议。通常浏览器可以通过嗅探内容本身的方法来决定它是什么类型，而不是看响应中的content-type值。通过设置 X-Content-Type-Options：如果content-type和期望的类型匹配，则不需要嗅探，只能从外部加载确定类型的资源。举个例子，如果加载了一个样式表，那么资源的MIME类型只能是text/css，对于IE中的脚本资源，以下的内容类型是有效的：application/ecmascript application/javascript application/x-javascript text/ecmascript text/javascript text/jscript text/x-javascript text/vbs text/vbscript 对于chrome，则支持下面的MIME 类型：text/javascript text/ecmascript application/javascript application/ecmascript application/x-javascript text/javascript1.1 text/javascript1.2 text/javascript1.3 text/jscript text/live script正确的设置nosniff – 这个是唯一正确的设置，必须这样。 通常不正确的设置‘nosniff’ – 引号是不允许的 : nosniff – 冒号也是错误的 如何检测在IE和chrome中打开开发者工具，在控制台中观察配置了nosniff和没有配置nosniff的输出有啥区别。参考文献Microsoft Post on Reducing MIME type security risksChromium Source for parsing nosniff from responseChromium Source list of JS MIME typesMIME Sniffing Living Standard3. X-Frame-Options目的这个header主要用来配置哪些网站可以通过frame来加载资源。它主要是用来防止UI redressing 补偿样式攻击。IE8和firefox 18以后的版本都开始支持ALLOW-FROM。chrome和safari都不支持ALLOW-FROM，但是WebKit已经在研究这个了。正确的设置DENY – 禁止所有的资源（本地或远程）试图通过frame来加载其他也支持X-Frame-Options 的资源。 SAMEORIGIN – 只允许遵守同源策略的资源（和站点同源）通过frame加载那些受保护的资源。 ALLOW-FROM http://www.example.com…
作者是阿里巴巴安全工程师@卷成团变成个球的CasperKid君 。文章是CK在2011年编写的，在当下仍具有非常重要参考价值。很多web 站点存在上传验证方式不严格的安全缺陷,是web 渗透中关键的突破口 ，站长小伙伴要注意哦！0x00 上传检测流程概述0x01 客户端检测绕过(javascript 检测)0x02 服务端检测绕过(MIME 类型检测)0x03 服务端检测绕过(目录路径检测)0x04 服务端检测绕过(文件扩展名检测)黑名单检测白名单检测.htaccess 文件攻击0x05 服务端检测绕过(文件内容检测)文件幻数检测文件相关信息检测文件加载检测0x06 解析攻击网络渗透的本质直接解析本地文件包含解析.htaccess 解析web 应用程序解析漏洞及其原理0x07 上传攻击框架轻量级检测绕过攻击路径/扩展名检测绕过攻击文件内容性检测绕过攻击上传攻击框架结语下载: Upload_Attack_Framework.pdf