精华内容
下载资源
问答
  • Web Cache原理,你真的造吗?

    万次阅读 2016-08-14 11:47:28
    一、Web Cache 在介绍Web cache时,我们需要简单介绍缓存的理解 1.1 缓存解释 缓存通常是基于键值对来缓存的,键通过hash计算后,存放于内存某个空间,所以键可以理解为索引。而值是存放在内存空间或是磁盘...

    一、Web Cache

    在介绍Web cache时,我们需要简单介绍缓存的理解

    1.1 缓存解释

    缓存通常是基于键值对来缓存的,键通过hash计算后,存放于内存某个空间,所以键可以理解为索引。而值是存放在内存空间或是磁盘空间上。

    当用户的用户请求送达至Web服务器,Web服务器会对URL进行hash计算,然后比对缓存(hash表)中的键。如若命中,则根据与之对应的值找到数据存放的位置(这里的值可以理解为指针,指着对应数据存放的位置),从而获取到缓存的结果。


    1.2 工作原理

    • 1.2.1    缓存命中


    ① 客户端请求某个Web数据,会先送至缓存服务器中,缓存服务器本身会监听80号端口接收用户请求

    ② 当Web缓存服务器收到用户请求之后,会将这个请求送达至代理进程中

    ③ 进程拆除用户请求报文中的应用层首部,TCP首部,IP首部等,从而获取到请求报文中的URL

    ④ 对URL进行hash计算,然后和缓存服务器中hash表中的缓存键进行比对,若一致则缓存命中

    ⑤ 在对应的值所指向的内存或硬盘空间上找到对应的内容数据

    ⑥构建成响应报文,直接返回给客户端

    • 1.2.2    缓存未命中


    ① 客户端请求某个Web数据,会先送至缓存服务器中,缓存服务器本身会监听80号端口接收用户请求

    ② 当Web缓存服务器收到用户请求之后,会将这个请求送达至代理进程中

    ③ 进程拆除用户请求报文中的应用层首部,TCP首部,IP首部等,从而获取到请求报文中的URL

    ④ 对URL进行hash计算,然后和缓存服务器中hash表中的缓存键进行比对,不一致则缓存未命中

    ⑤ 代理服务器会自行封装成请求报文,把自己当做http的客户端,向上游服务器发起请求

    ⑥ 若内容存在,上游服务器会构建成响应报文,返回给代理服务器。

    ⑦ 当代理服务器收到响应之后,会检查该对象是否可以缓存,如若可以,会对URL进行hash之后生成一个键,存放到对应的hash表中

    ⑧ 在相应的内存或磁盘空间上存储对应的内容数据

    ⑨ 当操作完成之后,会将数据构建成相应报文,然后响应给客户端

    1.3 扩展

    在用户自己内部的浏览器会有自己的缓存(私有缓存),当用户请求一个首页的时候,会向代理服务器请求,之后缓存在本地的一些链接或者图片,如果在本地存在缓存,那么就直接响应给用户,而无需再向代理服务器请求。所以我们的缓存是有存在多级的

    二、缓存失效

    现在存在一个问题,那就是如果我们的缓存失效了应该如何处理,正常而已如果缓存过期了,我们应该不再使用此缓存。所以缓存是具有TTL(生命时间值)值的,当这个TTL值过期之前,我们可以正常使用此缓存对象,一旦过期,请求一方就只能到比他更高一级的下一层缓存中的后端服务器去请求资源。

    假设某个缓存对象可以缓存7天,但是在第2天,后端服务器已经修改了此对象,那么此时应该如何处理。所以用户如果直接从缓存中获取到的数据就已经不是最新的了。这样可能会导致缓存有效期过期之前用户将无法获取有效的结果。那么如果处理呢?

    2.1 缓存的方式

    • 基于绝对时间缓存
      在http 1.0时使用的是绝对时间来缓存,可以理解精准的时间算法

    • 基于条件式缓存

    到 1.1版本以后,对其缓存功能进行了扩展,引入了几种功能

    1、引入相对时长过期时间
    2、引入强大可缓存对象控制功能(哪些数据能缓存以及不能缓存)
    3、引入条件式缓存

    2.2 基于绝对时间

    比方说,此次缓存时为中国时区的2016年7月3日9:00 缓存的,缓存的TTL值为7天,那么过期时间应该就是 7天之后(2016年7月10日)9:00 过期,但是如果是在美国,或者欧洲,因为时区的不同,使用绝对时间将会导致缓存缓存不

    2.3 基于条件式缓存

    • 基于最后一次缓存时间后询问式验证请求

    当用户访问同一个URL时,会发现在自己的缓存空间中存在一个相同的缓存对象,此时他不会了立即使用此缓存,而是去向上游服务器去验证这个缓存是否过期。主动向服务器发起验证请求,去请求一个URL,而且会发一个独特的请求首部(If-Modified-Sinces:time),询问在此时间之后(也就是缓存对象建立的时间之后),你是否发生了修改。如果后端服务器发现此资源未修改,会响应304(原始数据未修改)的响应码,由于资源未改变,所以此处发送的仅仅是响应码,数据无需发送。当客户端接收到响应后,就会直接使用本地的缓存。

    如果后端服务器发现此资源已经修改,那么会找到对应的资源,然后发一个200(原始数据已修改)的响应码,并将资源发送给客户端。当客户端接收到后,会替换原先缓存下来的结果,并在浏览器上进行显示。
    但是基于时间来记录判定其实并不理想,假设用户发验证时,而你的服务器时间并未到那个时间,那么就会无法验证缓存时间了。

    • 基于标签(tag)进行条件式请求

    在服务器端,每一个文件、或者是资源,每次版本修改之后都会附带一个tag(这个tag可能是一个随机生成的数,所以可以理解具有唯一性)。当用户请求资源后,会发送一个独特的请求首部(If-None-Match:tag),会将本地缓存的tag发送给服务器端,询问资源的tag是否匹配,匹配则资源未改变,响应304响应码,否则资源已改变,响应200响应码。

    所以这样就不会担心基于时间记录时所产生的各种问题。

    三、HTTP的缓存工作模式

    3.1 基于缓存过期时间

    1、当用户第一次访问资源时,缓存服务器不存在对应的缓存对象,那么此时缓存服务器会向后端服务器请求数据,后端服务器会数据响应给缓存服务器,并附带Cache-Control首部信息,表示缓存的时间。然后缓存服务器会将数据缓存于本地,然后将数据响应给客户端。

    2、当客户端再次请求同一个资源时,如果缓存时间未到期,那么此时缓存服务器会直接将用户请求的资源直接响应给客户端。

    3、如果当客户端请求资源时发现缓存服务器里的缓存周期已过期,那么此时缓存服务器会向后端请求资源,并将信息资源缓存于本地,而此时也更新了缓存的TTL值,然后响应给客户端。

    3.2 基于条件式缓存

    1、当客户端第一次请求资源时,由于缓存服务器并没有响应的缓存资源,那么此时缓存服务器会向后端服务器发起资源请求。当后端服务器收到请求后,会响应缓存服务器的请求,并附带Last-Modified:time的首部信息,缓存服务器会将资源及Last-Modified信息缓存于本地,然后一同也将这些信息响应给客户端。

    2、客户端发起资源请求,如果缓存服务器有对应的资源缓存条目,但是此时客户端不会直接使用,而是发送了If-Modified-Since:time请求首部给后端服务器,来询问是否数据未修改。如数据未修改,会返回304的响应码,那么此时客户端会直接使用缓存服务器里的资源。

    3、类似上面的方法,但是如果后端服务器响应的是200(数据已修改)的响应码时,那么缓存服务器会接受下这段响应信息,并将数据缓存于本地,然后再讲资源 + Last-Modified响应信息发回给客户端。

    3.3 组合应用HTTP首部

    根据上面的介绍,我们知道,如果基于时间来判断,可能会导致数据不准确的情况。而使用基于条件式的缓存可以弥补基于时间的不足,但是它自身还有一个缺点,那就是需要不断的去询问后端服务器的数据。这样就消耗占用了后端服务器的资源以及带宽。所以我们可以使用基于两种方式的合并来完成缓存失效判断。

    1、第一次用户访问,那么类似前面介绍的方法,不同的是,此时缓存服务器会记录 Etag信息和 Cache-Control信息。

    2、如果客户端请求的相同的资源,如果缓存未过期,那么此时使用的仍然是缓存服务器上的资源。

    3、当缓存服务器的资源已失效,那么客户端会向后端服务器发起If-None-Match:Etag请求首部,向后端服务器确认资源是否已被修改,如果资源未修改,此时服务器会响应304(资源未修改)的响应码,那么缓存服务器会更新TTL值,并响应给客户端。

    展开全文
  • Cached and Confused: Web Cache Deception in the Wild(Web 缓存欺骗) Seyed Ali Mirheidari (University of Trento)——是一个博士学生 Sajjad Arshad Northeastern University(东北大学,是做一名网络安全...

    Cached and Confused: Web Cache Deception in the Wild(Web 缓存欺骗)

    • Seyed Ali Mirheidari (University of Trento)——是一个博士学生
    • Sajjad Arshad Northeastern University(东北大学,是做一名网络安全研究员,发的顶会超多,锁住)
    • Kaan OnarliogluAkamai Technologies (阿卡迈科技公司)
    • Bruno Crispo University of Trento &KU Leuven(计算机科学与信息工程学院(DISI)教授
      特伦托大学国际信息通信技术博士学院院长,猜测是一作的导师,但是没二作论文多)
    • Engin Kirda Northeastern University(东北大学 做的是系统统,软件和网络安全(重点是网络安全,二进制分析,恶意软件检测,也发了很多论文,锁住)
    • William Robertson Northeastern University (一查google schoolar好强!“我的研究涉及广泛的系统、网络和软件安全问题,目标是使网络空间对每个人都更安全。”)

    综上,东北大学的SECURITY好强!

    扒到的LAB
    iSecLab(网页不更新了,但18年的顶会质量较高)
    LAB: THE NORTHEASTERN UNIVERSITY SYSTEMS SECURITY LAB (感觉和我自己在的实验室去年发的论文数差不多)
    Cybersecurity and Privacy Institute

    Abstract

    1. 大规模的测试工作:作者提出了第一项大规模研究,该研究量化了340个高 AlexaTop 5K中的个人资料网站。作者发现表明,在**Web缓存欺骗 (WCD)**公开披露两年后,许多受欢迎的站点仍然脆弱。
    2. 测试后的建议:我们对流行的CDN提供商的经验实验强调了这样一个事实:网络缓存不是即插即用技术。

    Introduction

    现状:在一般情况下,为了提高CDN缓存模式地效率,同时保护CDN缓存访问者的隐私性。缓存的最佳选择包括经常访问的图像,软件和文档下载,流媒体,样式表以及大型静态HTML和JavaScript文件。 最近的一项科学测量还估计,CDN提供者为Alexa Top 1K提供了超过74%的服务,这表明CDN和更一般的Web缓存在Internet中发挥着核心作用。
    攻击:在2017年,Gil提出了Web缓存欺骗(WCD)攻击,该攻击可以诱使Web缓存错误地存储内容,并因此使攻击者在未经授权地情况下放访问该内容。其核心是源服务器和WEB缓存之间的路径混淆。在这两点上,对请求的URL的不同解释导致对给定对象的可缓存性存在分歧。
    本文工作

    1. 在本文中,作者首先介绍了对Alexa Top 5K中295个站点的WCD的大规模测量和分析。结果显示,许多处理敏感数据和私人数据的高知名度网站都受到了WCD的影响,并且很容易受到网络攻击。然后,作者讨论了可最大化WCD潜在破坏力的其他路径混淆方法,并在对340个站点​​的扩展数据集进行的后续实验中证明了它们的影响。
    2. 除此之外,作者提供了有关WCD严重性的新颖见解——利用WCD来窃取其他类型的敏感数据,包括安全令牌,解释将WCD漏洞提升为注入向量的先进攻击技术,以及通过对收集到的数据进行进一步分析来量化我们的发现。
    3. 最后,作者对流行的CDNproviders进行了实证分析,记录了它们的默认缓存设置和自定义机制。

    Background & Related Work

    在本节中,作者概述了Web缓存欺骗(WCD)攻击的工作原理,并讨论了相关概念和技术,例如Web缓存,路径混淆和现有的WCD扫描程序。

    Web Caches

    对于Web服务器及其最终用户而言,在Internet上反复传输大量使用的大型Web对象是一个昂贵的过程,尤其是面对Internet基础结构和路由问题的常见技术问题时,可能导致网络延迟增加,并导致Web应用程序无响应。 为了解决这个问题,Internet设置了Web缓存机制,并且用于Internet通信的各个步骤(通常是多个步骤)。例如,浏览器和反向代理服务器。

    特别是,Web缓存是Content Delivery Networks(CDN)的关键组成部分,它为用户提供Web性能和可用性服务。 通过在全球范围内部署大规模分布的共享缓存代理网络(也称为边缘服务器),CDN的目标是尽可能多地从其最接近客户端的缓存中满足请求,从而在此过程中卸载原始服务器。 由于涵盖了从简单的个人站点到大型企业等不同市场领域的多个受欢迎的CDN提供程序的结果,Web缓存已成为Internet基础结构的核心组成部分。

    缓存的最常见目标是静态但经常访问的资源。 其中包括静态HTML页面,脚本和样式表,图像和其他媒体文件,以及大型文档和软件下载。(非静态对象的缓存并不常见,并且与WCD攻击无关。本文没讨论。)

    HTTP / 1.1规范定义了可在服务器响应中包含的Cache-Control header,以向通信路径上的所有Web缓存发信号通知如何处理传输的对象。 例如,标题“ Cache-Control:no-store”指示不应存储响应虽然规范指出Web缓存必须尊重这些标头,但是Web缓存技术和CDN提供程序为用户提供了配置选项,以忽略和覆盖标头指令。 实际上,一种常见且简单的配置方法是基于资源路径和文件名创建简单的缓存规则,例如,指示Web缓存存储所有扩展名为jpg,ico,css或js的文件。

    Path Confusion

    随着Web应用程序的大小和复杂性的增长,Web服务器引入了复杂的URL重写机制,以实现高级应用程序路由结构以及提高可用性和可访问性。举个例子,http://www.somehost.com/Blogs/2006/12/,URL重写后变为
    http://www.somehost.com/Blogs.aspx?year=2006&month=12 1

    但可能存在Web服务器并没有告知外部其对复杂URL重写机制的结果,并以一种意想不到的(可能是不安全的)方式处理URL。 这称为路径混乱

    干净URL方案使用从Web服务器的内部资源组织中抽象出来的结构,从而提供了一种 面向API的更具可读性的表示形式。例如,对于一个给定的Web服务,可以选择example.com/index/v1/v2来代替URLexample.com/index.php?p1=v1&p2=v2。

    当用户使用example.com/index/img/pic.jpg访问相同的Web服务的情况。用户和通信路径中的所有技术(例如,Web浏览器,缓存,代理,Web应用程序防火墙)可能会误解此请求期望返回一个图像文件,并相应地处理HTTP响应(例如,网络缓存可能选择存储响应有效负载)。 但是,实际上,Web服务将在内部将此URL映射到example.com/index.php?p1=img&p2=pic.jpg,并使用HTTP 200状态代码返回index.php的内容。请注意,即使img / pic.jpg是Web服务器上不存在的任意资源,HTTP 200状态代码将错误地指示请求已按预期成功处理。

    基于路径混淆的著名攻击类别是相对路径覆盖(RPO)

    • 挖个坑:相对路径覆盖(RPO)

    Web Cache Deception

    为了利用WCD漏洞,攻击者制定了满足以下两个属性的URL:

    1. Web服务器必须将该URL解释为对带有私有信息的不可缓存页面的重新请求,并且它应该触发成功的响应。 2.同一URL必须由中间Web缓存解释为对匹配有效缓存规则的静态对象的请求。

    接下来,攻击者使用社交工程渠道诱使受害者访问此URL,这将导致错误地缓存受害者的私人信息。 然后,攻击者将重复该请求并获得对缓存内容的访问权限。

    攻击步骤:

    1. 攻击者诱骗受害者访问请求/account.php/nonexistent.jpg的URL。 乍一看,它似乎引用了图像文件,但实际上并未指向服务器上的有效资源。
    2. 请求到达了Web服务器并被处理。 此示例中的服务器应用重写规则来丢弃请求对象的不存在的部分,这是流行的Web服务器和应用框架工作的常见默认行为。 结果,服务器会发送回成功响应,但实际上是体内包含了account.php的内容,其中包含受害者帐户的私人详细信息。 Web缓存不知道服务器上发生的URL映射,因此将响应存储为响应,并将其解释为静态图像。
    3. 攻击者访问相同的URL,导致缓存命中,并授予他未经授权的访问受害者的缓存帐户信息。

    由于其安全性和高破坏力,WCD引起了媒体的广泛关注。 主要的Web缓存技术和CDN提供商也做出了回应,一些针对客户的已发布配置强化指南。 最近,Cloudflare宣布了对HTTP响应内容类型进行新检查的选项,以缓解攻击。
    预防手段:
    研究人员发布了用于扫描和检测WCD的工具,例如,作为Burp Suite扫描仪的扩展或作为独立工具。 作者注意到这些工具是针对渗透测试的,旨在直接在测试人员的控制下对Web属性进行针对性的扫描。 也就是说,通过设计,他们可以在不确定的前提下操作,通过简单的相似性进行信息公开测试并编辑距离检查,否则需要人工监督和解释结果。

    3. Methodology

    用到的工具

    1. 子域名枚举工具:Sublist3r、aquatone、Amass
    2. Google OAuth

    3.1 Stage 1: Measurement Setup

    仅当易受攻击的站点管理最终用户的私人信息并允许对该数据执行敏感操作时,WCD攻击才有意义。 因此,提供身份验证机制的站点是攻击的主要目标,因此也是我们进行测量的主要目标。第一阶段是识别此类站点并为其创建测试帐户。

    1. 域发现。此阶段开始于访问初始测量池中的站点(例如Alexa Top n)。然后,我们通过使用开源智能工具执行子域发现来增加站点覆盖率。我们将这些新发现的主要站点的子域(过滤那些响应HTTP(s)请求的子域)添加到种子池。
    2. 帐户创建。接下来,作者在每个站点上创建两个测试帐户:一个用于受害者,另一个用于攻击者。 作者为每个帐户填充唯一的虚拟值。 接下来,作者手动浏览每个受害者帐户,以发现应视为私人信息(例如,姓名,电子邮件,地址,付款帐户详细信息,安全问题和响应)或用户创建的内容(例如,评论,帖子,内部消息)的数据字段。 作者使用预定义的标记填充这些字段,随后可以在缓存的响应中搜索这些标记以检测成功的WCD攻击。 另一方面,攻击者帐户无需输入数据。
    3. Cookie收集。成功登录种子池中的站点后,爬虫程序将为受害人帐户和攻击者帐户收集两组cookie。 这些被保存在一个饼干罐中,以在随后的测量步骤中重复使用。 请注意,作者采取了多种措施来确保我们的抓取工具在作者的实验过程中保持身份验证。 考虑到Cookie的过期时间戳记,作者的抓取工具会定期进行重新认证。 此外,搜寻器使用正则表达式和黑名单来避免访问页面上的常见注销链接。

    3.2 Stage 2: Attack Surface Detection

    域抓取:在第二阶段,我们的目标是从种子库中的域映射到一组页面(即completeURL),这些页面随后将进行WCD漏洞测试。 为此,我们在这些池中的每个域上运行一个递归搜寻器,以记录指向该站点页面的链接。
    URL Grouping 作者通过按查询字符串参数名称或数字路径参数对这些URL进行分组,将发现的URL转换为抽象表示。 URL的这种过滤可显着加快测量速度,并在阶段3中通过冗余扫描来避免过度消耗目标站点的资源。出于类似原因,我们在每个域收集500个唯一页面后停止了攻击面检测爬虫。
    在这里插入图片描述

    3.3 Stage 3: WCD Detection

    针对第2阶段中发现的每个URL发起WCD攻击,并分析响应以确定是否已成功利用WCD漏洞WCD攻击。

    1. 作者设计了一个引用不存在的静态资源的攻击URL。 特别是,我们在原始页面“ /.css”后面附加。 作者使用随机字符串作为文件名,以防止站点的普通最终用户巧合地请求相同的资源
    2. 作者从受害者帐户发起对此攻击URL的请求并记录响应。
    3. 作者从攻击者帐户发出相同的请求,并保存响应以进行比较。
    4. 最后,我们通过省略保存在Attacker cookie jar中的所有会话标识符,以未经身份验证的用户身份来重复攻击。 我们稍后将分析对此步骤的响应,以确定没有身份验证凭据的攻击者(例如,当站点不提供开放或免费注册时)是否也可以利用WCD漏洞。

    标记提取。 一旦执行了上述攻击方案,作者首先会在攻击者的响应中搜索在阶段1中输入到受害者帐户中的标记,以检查是否公开了私有信息。如果攻击者帐户所请求的URL中存在受害者标记, 攻击者必须已经收到受害者的错误缓存的内容,因此,目标URL包含一个可利用的WCD漏洞。 由于这些标记携带相对较高的熵,因此该方法不太可能产生假阳性。(这句话不是很理解,和香农熵有什么关系)

    秘密提取。 作者扫描攻击者的响应,以发现通常用作Web应用程序安全机制一部分的秘密令牌。这些检查包括普通机密(例如CSRF令牌,会话标识符)以及任何其他特定于应用程序的身份验证和授权令牌(例如API凭据)。作者还检查与会话相关的资源,例如动态生成的JavaScript,这些资源中可能包含私有信息并包含秘密信息。

    为了提取候选者泄漏的机密信息,作者扫描了攻击者的响应以获取名称和值对,其中(1)名称包含我们的一个关键字(例如,csrf,xsrf,token,state,client_id),或(2)值具有随机成分。作者在隐藏的HTMLform元素,从HTML锚点元素提取的查询字符串以及内联JavaScript变量和常量中检查这些名称和值对。 同样,我们提取HTMLscript元素中引用的随机文件名。我们首先通过从目标字符串中删除字典单词(即使用10,000个常见英语单词的列表),然后在其余部分计算Shannon熵,来执行所有随机性测试。(这里也不是很理解)

    3.4 Verification and Limitations

    研究人员反复报道,大规模的Internet测量,特别是那些使用自动搜寻器的测量,很容易被旨在阻止恶意机器人和内容抓取工具的安全解决方案阻止或提供假内容。 作者在方法中的大多数步骤中都使用了真正的浏览器(例如Google Chrome)。

    请注意,本文有几个重要的限制……作者强调,本文的结果代表了一个下限。

    3.5 Ethical Considerations

    1. 性能方面的考虑。以最大程度地减少对扫描站点的性能影响以及对其操作员造成的不便。作者在每个方面都说了说
    2. 安全方面的考虑。 作者的方法完全避免危害爬网站点或其最终用户的安全。
    3. 负责任的披露。
    4. 可重复性。

    4 Web Cache Deception Measurement Study

    (Q1)WCD漏洞的普遍程度是多少? (§4.2)
    (Q2)WCD漏洞是否会暴露PII? (§4.3)
    (Q3)可以使用WCD漏洞来抵抗针对Web应用程序攻击的防御吗? (§4.3)
    (Q4)未经身份验证的用户可以利用WCD漏洞吗? (第4.3节)

    4.1 Data Collection

    作者配置了搜寻器以在实验时从Alexa Top 5K中识别出易受攻击的站点。 为了可扩展地创建测试帐户,我作者提供了通过Google OAuth进行用户身份验证选项的网站筛选了此初始衡量指标种子库。 此筛选过程将本次评估中考虑的网站范围缩小到295个。表2汇总了我们的爬网统计信息。
    在这里插入图片描述

    4.2 Measurement Overview(WCD漏洞的普遍程度是多少?)

    **Alexa排名。**爬虫从包含收集到的数据集的295个站点中识别出16个站点(5.4%)包含WCD漏洞。 图3展示了Alexa Top 5K中所有站点和易受攻击站点的分布。 由此可见,脆弱站点的分布与爬网站点的数量大致成正比。 也就是说,作者的数据并不表明WCD漏洞的发生率与站点受欢迎程度相关。
    在这里插入图片描述
    内容交付网络(CDN)。 作者使用一组启发式方法在HTTP标头中搜索知名的供应商字符串,我们用相应的CDN标记了每个域和站点。 表3显示了此标记的结果。 请注意,许多站点使用多个CDN解决方案,因此前四行的值总和可能会超过我们在最后一行中报告的总数。
    在这里插入图片描述
    响应代码。 表4列出了针对易受攻击的站点观察到的HTTP响应代码的分布。 该分布由“ 404未找到”控制,虽然这可能不直观,但实际上确实是根据RFC 7234允许的行为。 另一方面,虽然只有12个站点泄漏了具有200 OK响应的资源,但是作者对这些漏洞进行手动检查时,作者注意到从此类资源中泄漏了更多的PII。
    在这里插入图片描述
    缓存标头。表5显示了从易受攻击的站点收集的与缓存相关的标头的细分。 在特定情况下,作者注意到尽管存在其语义禁止缓存的标头(例如“ Pragma:no-cache”,“ Cache-Control:no-store”),携带这些标题的页面无论如何都会被缓存,因为发现它们容易受到WCD的攻击。 这一发现表明,站点管理员确实利用了Web缓存提供的配置控件,这些控件允许站点覆盖标头指定的缓存策略。这种观察的结果是,用户代理无法使用缓存标头来确定资源是否实际上已经存在, 是否被缓存。 这对于依赖缓存头推断WCD漏洞存在的WCD检测工具具有重要意义。
    在这里插入图片描述

    4.3 Vulnerabilities

    表6总结了在收集的数据中发现的漏洞类型,并通过手工检查进行了标记。
    PII. 16个脆弱站点中的PII.14泄漏了各种PII,包括名称,用户名,电子邮件地址和电话号码。 除了这四个主要类别之外,还发现了其他多种PII类别被泄漏。 其他PII的广泛示例包括财务信息(例如帐户余额,购物历史记录)和健康信息(例如烧掉的卡路里,步数,重量)。 虽然很容易忽略此类信息,但作者注意到,上述PII可以用作高效的鱼叉式网络钓鱼攻击的基础鱼叉式钓鱼网络网络

    Security Tokens. 使用第3节中描述的基于熵的过程,我们还分析了数据的存在性,表明安全令牌泄漏了。然后,作者通过使用浏览器访问易受攻击的站点并检查怀疑是否存在泄漏的令牌的存在来手动验证作者的发现。最后,作者使用在测量过程中建立的测试帐户,手动验证了每类泄漏令牌的代表性示例是否具有可利用性。

    在16个易受攻击的站点中,有6个泄漏了会话有效的CSRF令牌,尽管存在已部署的CSRF防御

    • 挖个坑:CSRF防御

    但攻击者仍可以使CSRF攻击。其中3个是在用于保护POST请求的隐藏表单元素中发现的,而其他4个是在嵌入式JavaScript中发现的,这些JavaScript主要用于发起HTTP请求。我们还发现2个站点泄漏了GET请求的URL查询参数中的CSRF令牌,这与GET请求应该是幂等的约定有些矛盾。

    16个易受攻击的站点中有6个在嵌入式JavaScript中泄漏了会话标识符或特定于用户的API令牌。这些会话标识符可用于模拟易受攻击站点上的受害者用户,而API令牌可用于以受害者用户身份发出API请求
    在这里插入图片描述
    Authenticated vs. Unauthenticated Attackers. 作者在第3节中介绍的方法包括一个检测步骤,旨在通过访问缓存的页面而不在请求中发送任何已存储的会话标识符来发现未经身份验证的用户是否可以利用可疑的WCD漏洞。 这种自动检查仅在少数情况下失败。 更糟糕的是,手动检查故障案例显示,每个爬虫都产生了假阴性,实际上,所有剩余的漏洞也可以由未经身份验证的用户利用。 这意味着WCD作为一类漏洞,往往不要求攻击者对易受攻击的站点进行身份验证才能利用这些漏洞。

    4.4 Study Summary

    发现295个站点中有16个站点来自Alexa排名前5K的Web缓存欺骗(WCD)漏洞。

    1. 我们注意到,虽然这不是所扫描站点的一大部分,但这些站点在Alexa排名中的位置可预见到大量用户
    2. 我们发现,缓存标头的存在是不可靠的,用于指示是否缓存资源的指示器,这意味着在扫描站点以查找WCD漏洞时,依赖于此信号的现有检测工具可能会无意中产生假阴性
    3. 我们发现易受攻击的站点泄漏了PII,这对于发动鱼叉式攻击或安全令牌很有用,这些令牌可用于模拟受害者用户或绕过重要的Web安全防护。
    4. 最后,此处发现的WCD漏洞不需要攻击者对易受攻击的站点进行身份验证,这意味着具有限制性注册过程的站点无法不受WCD漏洞的影响

    5 Variations on Path Confusion

    从攻击者的外部角度来看,通常无法可靠地预测缓存规则,从而导致了制作攻击URL的猜测工作的过程。 基于此观察,作者假设:当探索路径混淆技术的变化时,可能会增加触发缓存规则和有效Web服务器响应的可能性,并有可能最初不受WCD漏洞的网站上有出现WCD漏洞。为了检验我们的假设,我们在2019年7月的第一次实验后14个月进行了第二轮测量。

    具体来说,作者重复了我们的方法,但是尝试尝试使用不同的路径混淆技术制作的有效负载,以确定可以通过路径混淆变化利用多少页面。在本研究中,我们使用了扩展的种子池,其中包含来自原始集合的295个网站,以及从Alexa Top5K中随机选择的另外45个网站,总计340个。特别是,作者在不使用Google OAuth的网站中选择了这些新网站,以试图消除潜在的与之前的测量中存在偏差。 此决定的负面结果是,我们必须完全手动执行帐户创建步骤,从而限制了我们可以以此方式纳入研究的网站数量。最后,我们通过仅在前500个页面中选择和利用页面来修改URL分组方法,如果内容中至少有一个标记,则对于我们的目的而言,效率更高,对目标的资源消耗更少。 在下文中,我们描述了这个实验并提出了我们的发现。

    5.1 Path Confusion Techniques

    回顾一下我们的分析和表4,在大多数情况下,我们的WCD测试都导致404 Not Foundstatus代码的出现,这表明Web服务器返回的错误页面不太可能包含PII。 为了增加引发200 OK响应的机会,同时仍然触发缓存规则,我们在先前的工作的基础上提出了下面的其他路径混淆技术,如图4所示。图4中第一种是原始的方法。
    在这里插入图片描述
    编码换行符(\ n)。 Web服务器和代理通常以换行符作为停止解析URL的标志,而丢弃URL字符串的其余部分(请参见图4b)。 我们设计此URL的目的是为了利用Web服务器对这些服务器在换行符之后放置路径组件(即服务器seesexample.com/account.php),但是前面放置了缓存代理,而缓存代理却不能正确地解码换行符(代理则是seesexample.com/account.php% 0Anonexistent.css)。 结果,对该URL的请求将导致成功的响应,并且缓存将基于不存在的文件扩展名认为这是静态内容的情况下存储内容。

    编码分号(;)。 某些Web服务器和Web应用程序框架接受URL中用分号分隔的参数列表。 但是,服务器前面的缓存代理可能未配置为识别此类列表。 我们在图4c中介绍的路径混淆技术通过在分号后附加不存在的静态文件名来利用这种情况。 在成功的攻击中,服务器将解码URL并返回例如example.com/account.php的响应,而代理将无法解码分号,将example.com/account.php%3Bnonexistent.css作为资源,尝试缓存不存在的样式表。

    编码磅(#)。 Web服务器通常将磅字符作为HTML片段标识符进行处理,因此,在首次出现URL时便停止对其进行解析。 但是,代理及其缓存规则可能未配置为对井号进行解码,从而导致它们处理整个URL字符串。 我们在图4d中呈现的路径混淆技术再次利用了Web服务器和Web缓存之间URL的这种不一致解释,并且以与上面编码的换行符类似的方式工作。 也就是说,在这种情况下,Web服务器将成功响应example.com/account.php,而代理将尝试缓存example.com/account.php%23nonexistent.css。

    编码问号(?)。 此技术如图4e所示,其目标是具有未配置为解码和忽略以问号开头的标准URL查询字符串的缓存规则的代理。 因此,Web服务器将生成一个有效的响应,例如example.com/account.php,而代理将缓存该响应,并错误地将同URL解释为example / account.php%3Fname = valnonexistent.css。

    5.2 Results

    Pearson的χ2检验

    作者在第二项实验中针对“路径参数”技术呈现的结果与我们的第一次测量结果不同。这表明,在两次实验之间的14个月的间隔中,网站操作员在收到通知后解决了该问题,或者网站结构或缓存规则发生了变化,从而缓解了现有漏洞或暴露了新的易受攻击页面。特别是,作者在之前的实验中发现了16个易受攻击的站点,而在第二次研究中发现了25,而这两个站点之间的重叠只有4个。

    在本次实验中,作者发现了25个易受攻击的网站,其中有20个属于先前使用295个使用Google OAuth的网站,而5个是新选择的不使用GoogleOAuth的网站。为了测试这两组网站之间的漏洞发生率分布是否显示出统计学上的显着差异,我们应用了Pearson的χ2检验,其中漏洞发生率被视为分类结果变量,OAuth /非OAuth网站集为比较组。作者获得了1.07的检验统计量和0.30的p值,表明结果独立于对照组,并且发病率分布在典型选择的显着性水平上没有显着差异(即p> 0.05)。也就是说,我们对种子库的选择并没有偏见我们的发现。

    • 挖个坑:Pearson的χ2检验 泊松检验

    响应代码。 我们在表7中提供了针对易受攻击页面观察到的服务器响应代码。请注意,与原始路径相比,观察到的200条OK响应的数量与某些新的路径混乱版本形成了鲜明的对比。两种新的路径混淆技术确实能够引起成功服务器响应的数量显着增加,这与返回私有用户信息的机会更高相关。 其余两个变体的表现更接近原始技术。
    在这里插入图片描述
    漏洞。 在此实验中,我们总共确定了25个漏洞站点。表8显示了使用不同路径混淆变化检测到的易受攻击的页面,域和站点的细分。总体而言,原始的路径混淆技术导致相当成功的攻击,利用了68.9%的页面和14个站点。尽管如此,这些新技术组合仍然可以利用98.0%的页面,以及25个易受攻击站点中的23个,表明它们显着增加了成功攻击的可能性。
    在这里插入图片描述

    表9中的结果证实,每个路径混淆的变化都能够攻击一组不易受其他技术攻击的独特页面/域/站点,证明使用多种技术会增加成功利用的机会。 实际上,在25个易受攻击的站点中,只有11个只能使用我们在此处介绍的一种变体来开发,而不能使用路径参数技术。
    在这里插入图片描述

    总而言之,我们在本节中提出的结果证实了我们的假设,即与仅使用最初提出的路径参数技术相反,使用路径混乱的变化来发起WCD攻击会增加成功利用漏洞的可能性。 此外,在此过程中,有两个探索出的变体会引起更多的“ 200 OK”服务器响应,从而增加了Web服务器返回有效私人信息的可能性。

    6 Empirical Experiments

    在本节中,我们将提供两个实验性经验,以演示不同的缓存设置对WCD的影响,并讨论我们对流行CDN提供商默认设置的探索。

    6.1 Cache Location 位置

    成功的WCD攻击可能要求攻击者正确地将受害者与其连接到的同一边缘服务器作为目标,该边缘服务器存储了缓存的敏感信息。
    我们通过从一台计算机上执行我们方法的受害者互动来测试此实际约束的影响美国马萨诸塞州波士顿市,并从意大利特伦托的另一台服务器发动攻击。我们对第5节中所述的第二种措施中确认容易受到攻击的25个站点中的每一个进行了重复测试,结果表明我们的攻击未能如我们所预测的那样对19个站点失败,因此需要进行调整以将目标对准正确的缓存服务器。令人惊讶的是,其余6个站点尽管标头表明它们是通过CDN(3个Akamai,1个Cloudflare,1个CloudFront和1个Fastly)提供的,但仍然可以利用。
    在仔细检查流量后,我们在“快速”示例中发现标头,表明在其意大利区域记录了缓存未命中,然后在波士顿地区进行重试,导致缓存命中,从而导致了成功的攻击。我们无法利用暴露给我们的数据服务器来探索剩余的情况。
    众所周知,许多CDN提供程序都使用分层缓存模型,其中内容即使从孩子驱逐[3,20],也可以从父缓存中获得。上面的“快速”示例说明了这种情况,并且对于其余情况也是一个合理的解释。另一个可能性是,易受攻击的站点使用的是由其CDN提供程序开头的单独的集中式服务器端缓存。不幸的是,如果没有清楚地了解专有CDN的内部结构以及对站点所有者基础结构的可见性,就无法确定确切的缓存交互。
    我们的实验证实,缓存位置是成功的WCD攻击的实际限制,在这种攻击中,分布式缓存服务器是分布式的。不仅如此,而且还表明在
    某些情况下攻击是可行的,而无需进行其他流量操纵。

    6.2 Cache Expiration 过期

    Web缓存通常会存储对象很短的时间,然后在对象过期后将其逐出。当Web缓存负载沉重时,驱逐也可能过早发生。因此,攻击者可能只有有限的机会才可发起成功的WCD攻击,直到Web缓存删除缓存的敏感信息为止。
    为了衡量缓存过期对WCD的影响,我们以1小时,6小时和1天的延迟重复了我们的方法的攻击交互。3我们发现在每种情况下分别可利用16、10和9个站点。
    这些结果表明:在现实攻击情形中,利用是可行的,因为受害者和攻击者与Web缓存的交互之间存在延迟。话虽这么说,缓存最终将逐出敏感数据,这意味着具有**较短延迟的攻击更有可能成功。**我们还注意到,我们对每个站点使用随机选择的易受攻击页面进行了此测试,因为这足以满足我们的目的。实际上,给定站点上的不同资源可能具有不同的缓存过期时间,从而对可能的攻击施加了额外的限制。

    6.3 CDN Configurations 配置

    作者对CDN缓存配置进行了实验。作者与四个主要CDN提供商创建了免费或试用帐户:Akamai,Cloudflare,Cloud-Front和Fastly。我们仅测试了每个供应商提供的基本内容交付解决方案,并未启用诸如Web应用程序防火墙之类的附加功能。我们强调,主要的CDN提供商提供了丰富的配置选项,包括站点所有者以编程方式与其流量进行交互的机制。对CDN功能和相应的WCD向量进行系统,详尽的分析是一项非常艰巨的任务,超出了本文的范围。我们在本节中提出的结果仅旨在提供高层次的见解,以了解在建立安全可靠的系统方面必须投入多少精力CDN环境以及默认设置的行为。

    配置。 这里讲了一下每个缓存配置都需要了哪些内容。

    6.4 Lessons Learned

    我们在本节中提供的经验证据表明,正确配置Web缓存不是一件容易的事,此外,与发动攻击相比,检测和修复WCD漏洞的复杂性高得不成比例。如上所述,许多主要的CDN供应商不要在其默认配置中做出符合RFC的缓存决策[21]。即使基于文件扩展名的限制性更强的默认缓存规则也容易出现安全问题;例如,如果配置错误,Akamai和Cloudflare都可以缓存包含税款报表的动态生成的PDF文件。


    1. URL重写 ↩︎

    展开全文
  • Web cache缓存技术概述

    2011-07-26 22:26:43
    本文首先描述了Web缓存系统的基本要素及理想属性,然后介绍目前围绕Web缓存技术已经开展的研究,最后讨论Web缓存技术需要进一步研究的问题。 关键字 WWW 缓存技术 代理 1 引言 WWW是互联网上最受欢迎的...
    WW是互联网上最受欢迎的应用之一,其快速增长导致网络拥塞和服务器超载,缓存技术被认为是减轻服务器负载、降低网络拥塞,减少客户访问延迟的有效途径之一。本文首先描述了Web缓存系统的基本要素及理想属性,然后介绍目前围绕Web缓存技术已经开展的研究,最后讨论Web缓存技术需要进一步研究的问题。
    

    关键字 WWW 缓存技术 代理

    1 引言

    WWW是互联网上最受欢迎的应用之一,其快速增长造成网络拥塞和服务器超载,导致客户访问延迟增大,WWW服务质量问题日益显现出来。缓存技术被认为是减轻服务器负载、降低网络拥塞、增强WWW可扩展性的有效途径之一,其基本思想是利用客户访问的时间局部性(Temporal Locality)原理,将客户访问过的内容在Cache中存放一个副本,当该内容下次被访问时,不必连接到驻留网站,而是由Cache中保留的副本提供。

    Web内容可以缓存在客户端、代理服务器以及服务器端。研究表明,缓存技术可以显著地提高WWW性能[1][2],它可以带来以下好处:

    (1)减少网络流量,从而减轻网络拥塞;

    (2)降低客户访问延迟,其主要原因有:①缓存在代理服务器中的内容,客户可以直接从代理获取而不是从远程服务器获取,从而减小了传输延迟;②没有被缓存的内容由于网络拥塞及服务器负载的减轻而可以较快地被客户获取;

    (3)由于客户的部分请求内容可以从代理处获取,从而减轻了远程服务器负载;

    (4)如果由于远程服务器故障或网络故障造成远程服务器无法响应客户请求,客户可以从代理中获取缓存的内容副本,使得WWW服务的鲁棒性(Robustness)得到了加强。

    Web缓存系统也会带来以下问题:

    (1)客户通过代理获取的可能是过时的内容;

    (2)如果发生缓存失效,客户的访问延迟由于额外的代理处理开销而增加。因此在设计Web缓存系统时,应力求做到Cache命中率最大化和失效代价最小化;

    (3)代理可能成为瓶颈。因此应为一个代理设定一个服务客户数量上限及一个服务效率下限,使得一个代理系统的效率至少同客户直接和远程服务器相连的效率一样。

    目前,围绕Web缓存系统及其最优化问题已经开展了广泛而深入的研究,这些研究工作主要是围绕代理的作用展开的。

    2 Web缓存系统的理想特性

    一个理想的Web缓存系统应具有以下特性:

    (1)快捷性:缓存系统应该能够有效地降低客户的访问延迟;

    (2)鲁棒性:鲁棒性意味着可用性,客户希望Web服务随时可用;

    (3)透明性:缓存系统对客户应是透明的,客户得到的结果仅仅是快速的响应和良好的可用性;

    (4)可扩展性:Web缓存系统应能够随着网络规模和密度的不断增长而很好地进行扩展;

    (5)高效性:Web缓存系统给网络带来的开销越小越好;

    (6)适应性:缓存系统能够适应客户请求和网络环境的动态变化,这涉及到缓存管理、缓存路由、代理配置等,对于获得理想的缓存性能至关重要;

    (7)稳定性:Web缓存系统采用的方案不应给网络带来不稳定;

    (8)负载均衡:一个理想的缓存方案应能够将负载均匀地分发到整个网络,以避免某一个代理或服务器成为瓶颈或Hot spot点,而造成系统一部分甚至整个系统性能下降;

    (9)异构处理能力:随着网络规模和覆盖域的不断增大,网络将跨越一系列不同的硬件和软件体系结构。Web缓存系统应能够适应不同的网络体系结构;

    (10)简单性:简单的方案容易实现且易被普遍接受,一个理想的Web缓存方案配置起来应简单易行。

    围绕上述特性,一个Web缓存系统必须解决好以下问题:

    (1)缓存体系结构:缓存代理在网络中如何组织和配置;

    (2)代理合作:代理间如何合作,相互合作的代理可以提高命中率而改善缓存系统的性能;

    (3)缓存路由:当一处缓存代理失效时,如何将请求向其它缓存代理转发;

    (4)缓存替换算法:当缓存空间不够时,缓存内容如何替换;

    (5)缓存一致性:即缓存内容的时效性问题,如何防止缓存的内容过时;

    (6)内容预取:代理如何决定从服务器或其它代理处进行内容预取以减少客户的访问延迟;

    (7)负载平衡:如何解决网络中的“Hot spot”现象;

    (8)缓存内容:什么样的内容可以被缓存。

    在设计Web缓存系统时,必须涉及上述问题。

    3 Web缓存方案概述

    3.1 Web缓存体系结构

    一个Web缓存系统的性能取决于其客户群的大小,客户群越大,缓存的内容被再次请求的可能性就越高。相互合作的Cache组可能会提高命中率而提高缓存系统的性能,因此缓存系统的体系结构应确保代理间能够有效地进行合作。典型的缓存体系结构有以下几种:层次式、分布式和混合式。





    图1 Web缓存系统体系结构图

    3.1.1 层次式缓存体系结构

    Harvest项目[3]首先提出了层次式Web缓存体系结构。在层次式缓存体系结构中,Cache在网络呈多级配置,如图1(a)所示。为简单起见,假定有四级:底层Cache、局域层Cache、区域层Cache、广域层Cache。底层是客户/浏览器Cache,当客户端Cache不能满足客户的请求时,该请求被转发到局域层Cache,如果仍然得不到满足,则该请求被转发到区域层Cache直至广域层Cache。如果该请求在各级Cache中都得不到满足,则请求最终被转发到服务器。然后服务器对该请求的响应自顶向下地发送给客户,在沿途的每一个中间层Cache中留下一个副本。请求相同内容的其它请求则自下而上地进行转发,直到在某一级Cache中得到满足。

    层次式缓存体系结构带宽效率高,点击率较高的Web内容可以快速高效地分布到网络中。但该体系结构也存在一些不足[4]:

    (1)建立层次式缓存体系结构,缓存服务器必须配置在网络中关键的访问点上,缓存服务器间需相互合作;

    (2)每一级Cache都会带来额外的延迟;

    (3)高层Cache可能会成为瓶颈并带来较长的排队延迟;

    (4)同一个内容的多个副本被保存在不同的Cache中,整个系统Cache空间利用率不高。

    3.1.2 分布式缓存体系结构

    针对层次式缓存结构的上述缺陷,一些研究者提出了分布式缓存体系结构,在这种结构中,只有低层Cache,如图1(b)所示。文献[5]中的分布式Web缓存结构中,没有超出局域层的中间Cache层,Cache之间相互协作以处理失效。为了确定将客户请求转发给哪一个局域层Cache来获取失效的内容,每一个局域层Cache保留一份其它局域层Cache中缓存内容的目录信息,以便发生失效时将客户请求准确地转发到相应的局域层Cache。缓存阵列路由协议CARP [6](Cache Array Routing protocol)是一种分布式缓存方案,它将URL空间分割成不同的部分,将每一部分指定给一组松散耦合的Cache组,每个Cache只能缓存具有指定给它的URL的Web内容,从而可以根据客户请求内容的URL来确定将请求转发给哪一个Cache。

    在分布式缓存结构中,大多数的网络流量都发生在网络底层,不容易产生网络拥塞,Cache空间利用率高,且可以更好地实现负载共享,容错性更好。然而,一个大规模的分布式缓存系统的配置可能会遇到几个问题:连接次数较多、带宽要求高、管理困难[4]。

    3.1.3 混合式缓存体系结构

    混合式体系结构如图1(c)所示,同级Cache采用分布式缓存结构,相互合作。Harvest集团设计的互联网缓存协议ICP(the Internet Cache Protocol)支持从RTT最小的父Cache或邻居Cache中获取相应的内容。

    3.1.4 缓存体系结构的优化

    研究表明[4]层次式缓存体系结构和分布式缓存结构相比,层次式缓存体系结构具有较短的连接时间,因此将较小的文档缓存在中间层Cache中可以减少访问延迟;分布缓存结构具有较短的传输时间和较高的带宽利用率。理想的方案就是将二者结合起来,充分发挥各自的长处,同时减少连接时间和传输时间。

    3.2 缓存路由

    出于对Web缓存系统扩展性的考虑,大多数缓存系统将大量的Cache分散在互联网上,这样带来的最大问题是如何快速地定位缓存有所需内容的Cache,这就是缓存路由问题。该问题有点类似于网络路由,但却不能用同样的方式解决。传统的网络路由可依地址聚类(层次式的地址表示使得地址聚类成为可能)而进行,但是在WWW中,具有相同URL前缀或服务器地址前缀的文档未必发送给相同的客户,难以对路由地址进行聚类,这样缓存路由表将大得难以管理。此外,缓存内容不断更新,过时的缓存路由信息将导致缓存失效。为降低Cache失效的代价,理想的缓存路由算法应该将客户的请求路由到下一个代理,该代理具有较高的命中可能性且位于或接近于客户到服务器的网络路径上。

    3.2.1 缓存路由表法

    Malpani等人[7]将一组Cache组合起来,当客户的请求被转发到指定的Cache时,如果该Cache缓存有请求的内容,则将其发送给客户,否则通过IP组播将请求转发给同组的其它Cache,由缓存有相应内容的Cache对客户的请求进行响应,如果所有Cache中都没有缓存请求的内容,则该请求被转发到源服务器。Harvest[3]缓存系统将Cache组织成层次式结构并使用Cache解析协议ICP(Internet Cache Protocol),当发生Cache失效时,低层Cache在将客户请求转发到上一层Cache前,首先查询兄弟节点Cache是否缓存有相应的内容,以避免顶层Cache超载。自适应Web缓存系统[8]为每一个服务器建立Cache树,树中的Cache被组织成相互重叠的多点传送组,一个请求通过这些传送组来获取相应的缓存内容。该方法对每一个服务器构造不同的Cache树,因此没有根结点的超载问题,自配置性和鲁棒性都比较好。但是对点击率较低的内容请求可能会经过较多的Cache,产生较大的Cache通信开销,作者建议通过限制请求经过的Cache数来解决该问题。

    3.2.2 哈希函数法

    Cache阵列路由协议CARP[6]使用一个基于阵列成员列表和URL的哈希函数来确定一个Web对象确切的缓存地址或一个Web对象应缓存在什么地方。在Summary Cache[9]中,每个代理保存一个同组中其它代理所缓存内容的URL摘要信息,该代理在转发客户请求时检查这些摘要信息以确定将请求转发给哪一个代理。为减小开销,这些摘要信息定期进行更新。试验表明该系统可以显著地减少Cache间的信息数量、带宽消耗以及协议带来的CPU开销,而保持和ICP几乎一样的缓存命中率。

    3.3 Cache替换算法

    Cache替换算法是影响代理缓存系统性能的一个重要因素,一个好的Cache替换算法可以产生较高的命中率。目前已经提出的算法可以划分为以下三类:

    (1)传统替换算法及其直接演化,其代表算法有:①LRU(Least Recently Used)算法:将最近最少使用的内容替换出Cache;②LFU(Lease Frequently Used)算法:将访问次数最少的内容替换出Cache;③Pitkow/Recker[10]提出了一种替换算法:如果Cache中所有内容都是同一天被缓存的,则将最大的文档替换出Cache,否则按LRU算法进行替换。

    (2)基于缓存内容关键特征的替换算法,其代表算法有:①Size[10]替换算法:将最大的内容替换出Cache;②LRU—MIN[11]替换算法:该算法力图使被替换的文档个数最少。设待缓存文档的大小为S,对Cache中缓存的大小至少是S的文档,根据LRU算法进行替换;如果没有大小至少为S的对象,则从大小至少为S/2的文档中按照LRU算法进行替换;③LRU—Threshold[11] 替换算法:和LRU算法一致,只是大小超过一定阈值的文档不能被缓存;④Lowest Lacency First[12]替换算法:将访问延迟最小的文档替换出Cache。

    (3)基于代价的替换算法,该类算法使用一个代价函数对Cache中的对象进行评估,最后根据代价值的大小决定替换对象。其代表算法有:①Hybrid[12] 算法:算法对Cache中的每一个对象赋予一个效用函数,将效用最小的对象替换出Cache;②Lowest Relative Value[13] 算法:将效用值最低的对象替换出Cache;③Least Normalized Cost Replacement(LCNR)[14]算法:该算法使用一个关于文档访问频次、传输时间和大小的推理函数来确定替换文档;④Bolot等人 [15]提出了一种基于文档传输时间代价、大小、和上次访问时间的权重推理函数来确定文档替换;⑤Size—Adjust LRU(SLRU)[16] 算法:对缓存的对象按代价与大小的比率进行排序,并选取比率最小的对象进行替换。

    总之,为了使Cache命中率最大化,围绕Cache替换算法已经开展了大量的工作,但是替换算法的性能很大程度上取决于WWW访问的特性,还没有哪一种替换算法能够对所有Web访问模式都优于其它算法。

    3.4 缓存一致性

    Web缓存系统可以减小访问延迟,但带来了一个副作用:缓存的副本提供给客户的可能是过时的内容,因此必须有一套缓存一致性机制来确保缓存的内容能够及时进行更新及有效性确认,以便为客户提供最新的内容。

    目前主要有两种缓存一致性类型:强缓存一致性和弱缓存一致性。

    3.4.1 强缓存一致性

    (1)客户端确认:对于每一次访问,代理都认为缓存的内容已经过时并随请求发送一个“IF—Modified —Since—date”报头到服务器。如果在指定的时间后该内容发生了变化,则服务器将更新后的内容发送给代理并最终发送给客户;如果请求内容未修改,则发回 “304”响应,表示文档未修改,缓存内容继续有效。

    (2)服务器确认:当服务器检测到一个内容发生变化时,服务器向所有最近请求过该内容并有可能缓存该内容的客户发送作废信息[17]。该方法要求服务器必须保存一个访问该内容的客户链表以便发送作废信息,当客户数量很大时,该方法将变得不适用,同时,该链表本身也可能过时,造成服务器向许多已经不再缓存该内容的客户发送作废信息。

    3.4.2 弱缓存一致性

    (1)自适应TTL[18] (Time To Live)机制:通过观察一个文档的生存期来调整其生存时间,从而解决缓存一致性问题。如果一个文档在一个相当长的时间内都未修改过,它往往不会再发生变化。这样,一个文档的生存期属性被赋予一个该文档目前“年龄”(等于目前时间减去上一次修改的时间)的百分比。自适应TTL法可以将一个文档过时的可能性控制在<5%的范围内。大多数的代理服务器都使用该机制,但是这种基于文档生存期的缓存一致性机制并不能确保缓存内容的有效性。

    (2)捎带作废机制

    Krishnamurthy等人提出使用捎带作废机制来提高缓存一致性的效率。他们提出了三种机制:①捎带确认PCV[19](Piggyback Cache Validation)机制:利用代理发送给服务器的请求来提高缓存一致性。例如,当一个代理向服务器发出请求时,它捎带一系列缓存的但可能过时的来自该服务器的内容进行有效性确认;②捎带作废PSI[20](Piggyback Service Invalidation)机制:其基本思想是当服务器对代理进行响应时,把一系列上次代理访问后变化的内容告诉代理服务器并由代理将这些内容作废,从而延长其它缓存内容在Cache中的缓存时间;③PSI和PCV混合机制[21]:该机制根据代理上次请求作废的时间距当前时间间隔的大小来确定采用何种机制,以实现最佳的总体性能。如果这个时间间隔较小,则使用PSI机制,否则使用PCV机制来对缓存内容进行确认。其基本原理是时间间隔越小,与PSI一起发送的作废数量就小,但随着时间的增长,发送作废的开销将大于请求确认的开销。

    3.5 内容预取

    Web缓存技术可以提高Web性能,但研究表明[22],不管采用何种缓存方案,最大缓存命中率通常不大于40~50%。为进一步提高缓存命中率,引入了预取技术。预取技术本质上是一种主动缓存技术,其基本思想是在处理客户的当前请求时,利用客户访问内容或模式的先验知识,对客户接下来的请求内容进行预测,并利用客户请求的间隙将预测内容缓存在Cache中,从而更好地隐藏延迟,提高服务质量。

    早期研究集中在浏览器/客户与Web服务器之间进行内容预取,当代理被引入后,人们的研究兴趣转到了代理与服务器之间的预取技术研究。研究表明预取技术可以有效地降低客户访问延迟,但预取技术仍饱受争议,原因有二:

    (1)内容预取是一种实时性要求较高的任务,它主要利用客户请求的间隔进行,而这个间隔一般情况下小于一分钟[23],如果在这段时间内不能完成预取任务,预取将变得毫无意义。因此对预取算法的效率有较高的要求。

    (2)内容预取是通过加重服务器负载及增加网络流量为代价来降低客户端响应时间的,因此对预取的准确度有较高的要求。同时,一个预取模型在确定预取文档的数量时,必须考虑客户的访问特性、服务器负载及网络流量状况,如果抛开这些因素来进行预取可能会造成事与愿违的效果。

    总之,一个良好的预取模型,效率、准确度要高,付出代价小。围绕预取的高效性和准确性还需做进一步的研究。

    3.5 负载平衡

    当众多客户同时从一台服务器获取数据或服务时就会发生Hot Spot现象,导致服务器性能下降甚至失效。目前处理该问题的方法大多数是使用某些复制策略将被请求的内容分贮在互联网上,从而将负载分散到多个服务器(代理)上[24],避免单个服务器成为为瓶颈。

    3.6 缓存内容

    一个代理可能发挥多种作用,除进行数据缓存外还可以进行连接缓存和计算缓存。连接缓存指在客户与代理、代理与服务器间使用持久连接,来减少建立TCP连接开销及服务器发送时的慢起动开销,从而减小客户访问延迟时间[25]。计算缓存可以看作是Web服务器可以将它们的部分服务迁移到代理,以减轻服务器瓶颈,其应用之一就是动态数据缓存,通过代理来缓存动态数据并将一部分计算迁移到代理,由代理来产生和维护缓存的动态数据,从而提高客户获取动态数据的性能。

    4 需要进一步研究的问题

    围绕Web缓存技术已经开展了大量的研究并取得了丰硕成果,但仍有一些问题需做进一步的研究。这些问题包括:

    (1)客户访问模式研究:通过研究客户的访问模式,从而更好地进行缓存管理和内容预取,提高缓存命中率;

    (2)动态数据缓存:目前Web缓存命中率不高的一个重要原因是相当一部分内容(私有数据、授权数据、动态数据等)不能被缓存。如何使得更多的数据可以缓存以及如何减小客户访问非缓存页面的访问延迟已经成为提高Web性能的关键问题;

    (3)Web流量特征:缓存系统的效率在于Web访问流的时间局部性以及良好的Cache管理策略,理解Web客户产生的负载特性对于更好地设计和提供Web服务具有重要意义;

    (4)代理配置:要获得良好的Web性能,代理的配置至关重要,代理配置策略的理想标准是:自组织、高效路由、负载均衡、行为稳定等,围绕此问题还需做进一步的研究。

    总之,提高Web性能的前沿研究在于开发扩展性、鲁棒性、适应性、稳定性好、高效且能够较好地配置在当前及今后网络中的缓存方案。
    展开全文
  • CDN之Web Cache

    2018-06-09 14:06:00
    1. Cache工作方式 Web Cache 作为一种网页缓存技术,可以在用户访问网站服务器的任何一个中间网元上实现。...当 Web Cache 作为代理使用时,通常工作在正向代理或者透明代理的模式,Web Cache 可以在这两...

    1. Cache 的工作方式

    Web Cache 作为一种网页缓存技术,可以在用户访问网站服务器的任何一个中间网元上实现。根据 HTTP 协议的定义,在一次网页访问中,用户从客户端发出请求到网站服务器响应请求内容的交互过程中,通常会涉及 4 个关键的网元:用户、代理、网关和 Web 服务器。当 Web Cache 作为代理使用时,通常工作在正向代理或者透明代理的模式,Web Cache 可以在这两种模式下实现访问内容副本的缓存和服务;Web Cache 应用最多的地方还是在网关上,这也是 CDN 的典型应用场景,网关通常工作在反向代理模式。

    1.1 正向代理

    正向代理(Forward Proxy)方式下,使用者需要配置其网络访问的代理服务器地址为 Cache 设备的地址,内网用户对互联网的所有访问都通过代理服务器代理完成。使用者也可以仅对特殊应用设置代理服务器,此时仅该类访问需要通过代理服务器代理完成。通常正向代理的缓存设备支持冗余配置,从而保证代理系统的稳定性和可用性。共向代理的工作示意图如下:
    1382048-20180608112305246-644320423.png
    如上示例,用户主机和代理服务器部署在同一网络环境中,用户主机地址为 192.168.10.101,正向代理服务器的地址为 192.168.10.1,用户想要访问的外网服务器地址为 172.16.10.200。通常用户需要为所使用的主机配置正向代理服务器地址(192.168.10.1)和服务端口(8080),之后请求流程如下:

    • 用户在上网时其主机对外网服务器的数据传输首先要传输给正向代理服务器;
    • 代理服务器检查代理缓存中是否保存了用户请求数据,如果有则直接返回给用户,如果没有缓存请求内容,则正向代理服务器负责发送用户主机请求数据到外网目标服务器,同时接收并缓存外网服务器响应数据,同时将响应数据反馈给用户主机。

    注:在执行正向代理功能时也可以完整安全认证和访问控制功能,比如可以设置某些特定用户在工作时间访问外网站点,或者禁止访问某些外部站点。

    正向代理部署示例:
    1382048-20180608112240442-137308609.png

    1.2 反向代理

    在反向代理(Backward Proxy)方式中,用户不需要配置代理服务器地址,Cache 设备的地址作为被访问域的服务地址写入 DNS 记录,并利用 Cache 设备的内容路由/交换能力完成代理访问。反向代理和其他代理方式的区别是,反向代理专门对定制的内容进行加速,如域名 streambc.com 之中的所有网页内容或域名 streamde.com 之中的所有流媒体内容。

    反向代理工作原理示意图

    1382048-20180608113919915-425035781.png
    代理服务器(Cache)和应用服务器(Server)部署在同一网络环境中,用户主机地址为 192.168.10.101,应用服务器地址为 172.16.10.200,反向代理服务器地址为 172.16.10.1,应用服务器对外访问地址为反向代理服务器地址 172.16.10.1,用户直接访问代理服务器获取应用服务器提供的服务,而不需要配置任何代理服务。大致流程如下:

    • 用户首先发送数据请求到外网的反向代理服务器;
    • 代理服务器检查代理缓存中是否保存了用户请求的数据,如果有则直接返回给用户;
    • 如果没有缓存请求的内容,则反向代理服务器将用户主机请求数据发送给应用服务器,同时接收应用服务器响应数据并反馈给用户主机,同时缓存用户请求相关内容。

    在执行反向代理功能时,代理服务器响应了大部分应用访问请求,大大减轻了应用服务器的负载压力。

    1.3 透明代理

    透明代理(Transparent Proxy)方式下,用户的浏览器不需要配置代理服务器地址,但是用户的路由设备需要支持 WCCP 协议(Web Cache Control Protocol)。路由器配置了 WCCP 功能后,会把指定的用户流量转发给 Cache,由 Cache 对用户提供服务。另一种方案是利用 4 层交换机将用户的流量转发给 Cache,由 Cache 对用户提供服务。使用 WCCP 或 4 层交换机都可以支持负载均衡,可以对多台 Cache 平均分配流量。

    透明代理可以看做是通过网络设备或协议实现的正向代理工作模式,因而具备很多与正向代理相同的特点。

    透明代理工作原理示意图

    1382048-20180608132729984-385654706.png
    与正向代理部署方式类似,用户主机和代理服务器部署在同一网络环境中,用户主机地址为 192.168.10.101,正向代理服务器的地址为 192.168.10.1,目标应用服务器地址为 172.16.10.200。大致流程如下:

    • 用户访问目标服务器时不需要配置任何代理服务,直接将服务请求的目标地址设置为应用服务器 IP 地址;
    • 用户主机请求数据在发往目标主机前被透明代理截获,透明代理检查代理缓存中是否保存了用户请求数据,如果有则直接返回给用户;
    • 如果没有缓存请求内容,透明代理服务器则将用户主机请求数据发送给目标服务器,同时监听外网服务器响应用户请求数据,用户主机保持相关数据在缓存中以便后期服务网内相同的访问请求。

    2. 基于 HTTP 协议的 Web 缓存技术

    Web Cache 技术的主要目的是通过对内容副本进行缓存来满足后续相同的用户请求,使用 Cache 设备分担用户对源站点访问负载,从而提高 Web 站点的请求响应速度和用户访问并发量。在 CDN 系统中,Web Cache 多采用反向代理工作方式,用于衡量该设备的关键性能指标,包括:用户访问并发数(即请求链接数量)、数据分发吞吐量(带宽)、丢包率、响应时间、服务命中率等。

    2.1 性能指标

    2.1.1 并发量

    采用 Web Cache,一方面能够大大提高 Web 站点并发用户数量,提高 Web 站点的响应速度,另一方面由于 Web Cache 本身硬件配置的高低限制了其处理性能,在设计 Web Cache 初期就需要规划好其能够处理的用户访问并发量,从而使 Web Cache 在完成部署后能够使用户并发量达到预期值。

    2.1.2 吞吐率

    Web Cache 的吞吐率是指单位时间内能够处理、转发的数据量大小,吞吐率是衡量缓存设备处理速度的重要性能指标。Cache 设备的吞吐率由 CPU 性能、网络接口卡性能、数据传输总线的大小、磁盘速度、内存缓冲器容量,以及软件对这些部件进行管理的有效程度共同决定。在实际应用中,Web Cache 的吞吐率还要依赖于网络传输带宽速度和应用协议本身的传输效率。如果接入 Internet 的网络带宽较低,则 Web Cache 设备对外服务的吞吐率瓶颈就会出现在网络接入点。

    2.1.3 命中率

    Cache 的服务命中率就是为用户提供内容服务时,如果该节点已缓存了要被访问的数据,可以直接为用户提供服务,这就叫命中;如果没有的话,CDN 需要到内容源服务器取,就是未命中,需要回源,命中率 = 命中数/总请求数,这里所指的命中率是 Cache 服务 HTTP 请求命中率。

    2.1.4 响应时间和丢包率

    请求响应时间指用户发起内容访问请求到刘篮球获取到内容之间的时间,是 Web 用户体验最重要的因素之一。响应时间主要有以下几个方面决定。

    • DNS 解析时间:DNS 解析是用户访问页面或者请求服务的第一步,通常此时间在 0.18~0.3 秒为正常,小于 0.18 秒为优良。
    • 建立连接时间:指的是 IE 浏览器和 Web 服务器建立 TCP/IP 连接所消耗的时间,建立连接时间主要考量服务器硬件的处理性能,建立连接时间在 0.15~0.3 秒为正常,小于 0.15 秒为优良。
    • 重定向时间:指从收到 Web 服务器重定向指令到 Web 服务器提供的第一个数据包之前的消耗时间,此时间通常小于 0.1 秒。
    • 收到第一个包时间:指从 IE 浏览器发送 HTTP 请求结束开始,到收到 Web 服务器返回的第一个数据包消耗的时间。收到第一个包时间主要考量动态或回源的性能,此时间在 0.2~0.4 秒为正常。
    • 图片下载时间:通常采用 150KB 大小的图片下载所使用的时间来评测 CDN 元素级加速性能,此时间在 1~2 秒为正常。
    • 页面总下载时间:指页面所有内容全部到达浏览器的时间,总下载时间主要表示的是页面的总体耗时,不同类型的站点评定标准不同,通常此时间要求在 10 秒内。
    • 丢包率:指的是 Web Cache 响应数据传输过程中所丢失的数据包数量占所发送数据包的比率,丢包率越高会导致重传的数据量越大,从而延长 Cache 响应时间。

    2.2 内容存储机制

    存储是 Web Cache 对缓存内容进行 "持久化" 的容器和载体,内容存储方案的设计将直接影响 Web Cache 的服务器命中率、响应速度和投资成本。

    常见存储技术:

    • 共享存储:设备性能好、稳定和可靠性高,但投资成本较高;
    • 分布式系统服务方式:可以基于廉价存储介质提供大容量、高性能、高可靠的存储服务,但是对部署实施技术要求较高,且该技术可能引入额外的网络时延,因此更适合流媒体等服务使用。
    • 本地附加存储(DAS):Web Cache 缓存对象大小平均为 10~12KB,因此适合使用该存储技术。

    2.3 内容更新机制

    Web Cache 遵循以下基本规则:

    1. 如果 HTTP 响应头信息告诉 Cache 不要缓存,那么 Cache 就不会缓存相应内容。
    2. 如果对某内容的请求信息是需要认证或者安全加密的,Cache 也不会缓存相应内容。
    3. 如果在 HTTP 响应中没有 ETag 或者 Last-Modified 头信息,Cache 会认为缺乏直接的更新度信息,默认该内容不可缓存。
    4. 一个缓存的副本如果含有以下信息,Cache 会认为它是足够新的,会直接从缓存中送出,而不会向源服务器发送请求:
      • 含有完整的过期时间和寿命控制的头信息,并且内容仍在生存期内。
      • 浏览器已经使用过这个缓存副本,并且在同一个会话中已经检查过内容的新鲜度。
    5. 如果缓存的内容副本已经旧了,Cache 将向源站服务器请求校验,用于确定是否可以继续使用当前副本继续服务。如果校验后发现副本的原件没有变化,Cache 会避免从源站服务器重新获取副本。

    2.3.1 Cache 与源站服务器之间的校验

    1. 源站服务器向 Cache 返回内容响应消息时,会附带一个验证信息,Cache 在缓存内容时保存这个验证信息。
    2. 当有用户请求该内容时,如果 Cache 发现缓存内容过期,就是用验证信息生成一个 "有条件" 的请求来向源服务器请求验证。
    3. 源服务器在收到这样的请求以后,将请求中包含的验证信息与自己本地的验证信息进行比较。如果两个验证信息相等,那么返回一个带有特定状态码(比如 304 Not Modified,表示内容未修改过)且消息主体内容为空的响应消息,表示副本可以继续使用;如果两个验证信息不相等,源站服务器就会向 Cache 传输一个包含新内容的完整响应消息。

    "有条件" 的验证包括正验证和负验证,如果请求中要求服务器与消息附带的验证信息必须相等(使用请求消息的 "If-Match" 头)的则是正验证,如果要求两者不相等(使用请求消息的 "If-None-Match" 头)的是负验证。

    验证可以分为强验证或弱验证。

    • 强验证:是要验证所访问内容的每一个字节都没有变化,因为有任何的变化都会使相应的验证信息发生变化。强验证如使用 ETag,几乎所有的场合都可以使用。
    • 弱验证:只验证所访问内容的语义有没有发生大的变化,验证信息只有在内容语义有明显的改变时才会发生变化。若验证信息可以应用于不要求精确一致的情况下,通常一个访问内容的修改时间可以被认为是弱验证信息。

    2.4 Web Cache 优化

    1. HTTP 连接聚合

    HTTP 连接聚合的原理是,将多个短连接转换成一个长连接,从而减少连接。HTTP 连接聚合可以大大减少服务器频繁开启和关闭 TCP 连接处理所带来的资源消耗。

    2. HTTP gzip 压缩

    实现 HTTP 传输内容压缩地配制方法主要是当 Web Server 响应客户端时回传采用 gzip 格式对文本文件进行压缩,并将 HTTP 头信息 Content-Encoding 字段设置为 gzip 属性。

    转载于:https://www.cnblogs.com/jimodetiantang/p/9154716.html

    展开全文
  • Web Cache缓存

    千次阅读 2008-11-23 19:01:00
    这是一篇知识性的文档,主要目的是为了让Web缓存相关概念更容易被开发者理解并应用于实际的应用环境中。为了简要起见,某些实现方面的细节被简化或省略了。如果你更关心细节实现则完全不必耐心看完...Web缓存如何工作
  • web cache说明

    2011-01-07 22:43:00
    Web cache 说明关键字: web cache 说明 原文(英文)地址: http://www.mnot.net/cache_docs/ 版权声明:署名-非商业性使用-禁止演绎 2.0 这是一篇知识性的文档,主要目的是为了让Web缓存相关概念更容易...
  • Web缓存工作原理

    千次阅读 2017-12-21 16:15:40
    但除了一些微妙的细节之外,Web缓存的基本工作原理大多很简单。对一条HTTP GET报文的基本缓存处理过程包括7个步骤: 接收——缓存从网络中读取抵达的请求报文解析——缓存对报文进行解析,提取URL和各种首部查询...
  • Web相关Cache介绍

    千次阅读 2011-03-14 19:20:00
    Web相关Cache介绍 简介 Cache,中文意思是缓存,是用来将频繁访问的数据,存储于用户本地或者是访问速度很快的存储介质上,以便于提高访问速度及响应时间,我们的电脑的C PU中也有调整缓存,不过我今天这里说的是...
  • Web缓存的工作原理

    千次阅读 2018-08-13 15:32:09
    Web缓存的工作原理 所有的缓存都是基于一套规则来帮助他们决定什么时候使用缓存中的副本提供服务(假设有副本可用的情况下,未被销毁回收或者未被删除修改)。这些规则有的在协议中有定义(如HTTP协议1.0和1.1),...
  • 本地客户端会检查Cache-Control(max-age)缓存是否过期,(max-age)为过期时间 Last-Modified 上次修改时间 配合If-Modified-Since或者If-Unmodified-Since使用 对比上次修改时间验证资源是否需要更新 ETag ...
  • 怎样建设WEB Cache

    2009-12-23 22:48:34
    怎样建设WEB Cache计算机网络技术的成熟和不断发展使之成功地应用在了许多领域当中。其中,Internet可以说是大家最为熟悉,同时也是最为成功的一个范例,因为它已经***到了人们工作、生活、学习和娱乐的方方面面。...
  • Web基础:缓存

    2019-03-06 20:47:47
    Cache 缓存的概念: 使用缓存(cache)的站点会监听客户端向服务器发出的请求,并根据相应的缓存设置保存服务器端反馈的数据。 例1: HTML页面、图片等文件。如果用户再次使用相同的URL发送请求,请求不会直接发向...
  • web cache及squid框架介绍

    千次阅读 2012-12-05 09:54:00
    web cache及squid框架介绍  学习和从事web cache相关了东东已经有大半年的时间了,回想下这段时间,还是有很多东西可以分享的!  Cache,中文意思是缓存,是用来将频繁访问的数据,存储于...
  • web工作原理

    千次阅读 2016-10-30 11:27:39
    web工作原理 本文仅作为本人日常学习积累,文中的观点及知识若有不足,还请谅解。
  • web缓存原理分析

    千次阅读 2018-03-22 14:29:18
    为什么2月份会停更一个月的博客呢? … 过年是一个原因, ... 上班真的很辛苦, 每天感觉挺累的, 书也好久没有看了, 今天恰逢没有新需求, 项目在提测之际来写下一遍转载的文章, 主要记录一下在各处搜索到的关于web缓存...
  • Web缓存投毒

    2020-05-16 17:04:42
    什么是web缓存投毒(web cache poisoning) Web缓存投毒是利用Web服务器和缓存的行为,将有害的HTTP响应提供给其他用户。 Web缓存投毒分为两个阶段...Web缓存工作原理 如果服务器必须分别对每个HTTP请求发送新的响应,
  • Springboot-cache原理与源码

    千次阅读 2018-11-12 16:31:07
    Java Caching:定义了5个核心接口,分别是CachingProvider, CacheManager, Cache, Entry 和 Expiry。 CachingProvider:定义了创建、配置、获取、管理和控制多个CacheManager。一个应用可以在运行期访问多个...
  • Web 安全恩仇录:漏洞原理

    千次阅读 2018-04-12 10:41:44
    本课程主要内容为 Web 常见漏洞分析,同时会介绍在各个阶段需要做什么事,该课程利用的攻防平台是 Kali Linux 以及一些 Linux 和 Windows 靶机,按照主次会依次介绍 OWASP 10 的漏洞类型。通过学习本课内容,能够...
  • Java知识体系最强总结(2021版)

    万次阅读 多人点赞 2019-12-18 10:09:56
    也算是记录自己在从事编程工作的成长足迹,通过博客可以促进博主与阅读者的共同进步,结交更多志同道合的朋友。特此分享给大家,本人见识有限,写的博客难免有错误或者疏忽的地方,还望各位大佬指点,在此表示...
  • WEB之http协议工作原理

    千次阅读 2011-09-24 22:57:15
    除了TCP/IP协议,http可以说是最重要,且使用最多的网络协议...本节简要介绍一下http协议的工作原理。 假设现在有一个html文件:http.html, 存放在Web服务器上,其URL为www.myweb.com/http.html ,文件内容为: HTML
  • WEB缓存原理

    2015-10-23 08:55:51
    web缓存基本原理
  • html5的离线工作原理

    2017-06-26 16:06:16
     大家都知道Web App是通过浏览器来访问的,所以离线状态下是无法使用app的。其中web app中的一些资源并不经常改变,不需要每次都向服务器发送请求。这时应运而生的离线缓存就显得尤为突出。通过吧需要离线缓存储的...
  • Web缓存欺骗攻击

    千次阅读 2017-09-04 10:19:50
    Omer Gil早在今年年初就在他的博客上发表了有关于Web缓存欺骗攻击技术的博文,随后他在BlackHat USA 2017 和 BSides Tel-Aviv 2017 上对这种攻击技术进行了演示,并做了更深入的研究。 在他发布的“Web 缓存...
  • 这是一篇知识性的文档,主要目的是为了让Web缓存相关概念更容易被开发者理解并应用于实际的应用环境中。为了简要起见,某些实现方面的细节被简化或省略了。如果你更关心细节实现则完全不必耐心看完本文,后面参考...
  • ES写数据的过程 ES写数据的底层原理

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 65,638
精华内容 26,255
关键字:

webcache工作原理