当前位置:千赢国际官网 > 千赢网页手机版登入 > 跨域访问和防盗链基本原理,即使用了

跨域访问和防盗链基本原理,即使用了

文章作者:千赢网页手机版登入 上传时间:2019-09-16

谈谈前后端的分工协作

2015/05/15 · HTML5 · 1 评论 · Web开发

原文出处: 小胡子哥的博客(@Barret李靖)   

前后端分工协作是一个老生常谈的大话题,很多公司都在尝试用工程化的方式去提升前后端之间交流的效率,降低沟通成本,并且也开发了大量的工具。但是几乎没有一种方式是令双方都很满意的。事实上,也不可能让所有人都满意。根本原因还是前后端之间的交集不够大,交流的核心往往只限于接口及接口往外扩散的一部分。这也是为什么很多公司在招聘的时候希望前端人员熟练掌握一门后台语言,后端同学了解前端的相关知识。

即使用了 https 也不要通过 query strings 传敏感数据

2017/10/16 · 基础技术 · HTTPS

本文由 伯乐在线 - xiaoheike 翻译,艾凌风 校稿。未经许可,禁止转载!
英文出处:HttpWatch。欢迎加入翻译组。

服务器端的 log 将明文记下完整 url;浏览器上的访问历史也会明文记下完整 url;Referrer headers 里也忠实记下完整 url,然后在别人家的 Google Analytics 上显示。

我们经常听到的一个常见问题是:“URL 中的参数是否可以安全地传递到安全网站?”这个问题常常出现在客户看了 HttpWatch 捕获的 HTTPS 请求后,想知道还有谁可以看到这些数据。

 

例如,假设在一个查询中,使用如下安全的 URL 传递密码字符串:

HttpWatch 能够显示安全请求的内容,因为它与浏览器集成,因此它能够在 HTTPS 请求的 SSL 连接对数据加密之前查看数据。图片 1

如果你使用网络嗅探器查看,例如 Network Monitor,对于同一个请求,你只能够查阅加密之后的数据。在数据包跟踪中没有可见的网址,标题或内容:

图片 2

您可以信任 HTTPS 请求是安全的,只要:

  • 未忽略任何SSL证书警告
  • Web 服务器用于启动 SSL 连接的私钥在 Web 服务器本身之外不可用。

因此,在网络层面,URL 参数是安全的,但是还有一些其他基于 URL 泄漏数据的方法:

  1. URL 存储在 Web 服务器日志中–通常每个请求的完整 URL 都被存放在服务器日志中。这意味着 URL 中的任何敏感数据(例如密码)会以明文形式保存在服务器上。以下是使用查询字符串通过 HTTPS 发送密码时存储在 httpwatch.com 服务器日志中的条目: **2009-02-20 10:18:27 W3SVC4326 WWW 208.101.31.210 GET /Default.htm password=mypassword 443 … 通常认为即使是在服务器上,存储明文密码从来都不是好想法 2.URLs are stored in the browser history – browsers save URL parameters in their history even if the secure pages themselves are not cached. Here’s the IE history displaying the URL parameter:
  2. URL 存储在浏览器历史记录中–即使安全网页本身未缓存,浏览器也会将 URL 参数保存在其历史记录中。以下是 IE 的历史记录,显示了 URL 的请求参数:图片 3

如果用户创建书签,查询字符串参数也将被存储。

  1. URLReferrer 请求头中被传递–如果一个安全网页使用资源,例如 javascript,图片或者分析服务,URL 将通过 Referrer 请求头传递到每一个嵌入对象。有时,查询字符串参数可能被传递并存放在第三方站点。在 HttpWatch 中,你可以看到我们的密码字符串正被发送到 Google Analytics图片 4

结论

解决这个问题需要两步:

  • 只有在绝对必要的情况下传递敏感数据。一旦用户被认证,最好使用具有有限生命周期的会话 ID 来标识它们。

使用会话层级的 cookies 传递信息的优点是:

  • 它们不会存储在浏览器历史记录中或磁盘上
  • 它们通常不存储在服务器日志中
  • 它们不会传递到嵌入式资源,例如图片或 JavaScript
  • 它们仅适用于请求它们的域和路径

以下是我们的在线商店中,用于识别用户的 ASP.NET 会话 cookie 示例:

图片 5

请注意,cookie 被限制在域 store.httpwatch.com,并且在浏览器会话结束时过期(即不会存储到磁盘)。

你当然可以通过 HTTPS 传递查询字符串,但是不要在可能出现安全问题的场景下使用。例如,你可以安全的使用它们显示部分数字或者类型,像 accountview 或者 printpage,但是不要使用它们传递密码,信用卡号码或者其他不应该公开的信息。

1 赞 收藏 评论

跨域访问和防盗链基本原理(一)

2015/10/18 · HTML5 · 跨域, 防盗链

原文出处: 童燕群 (@童燕群)   

一、开发流程

前端切完图,处理好接口信息,接着就是把静态demo交给后台去拼接,这是一般的流程。这种流程存在很多的缺陷。

  • 后端同学对文件进行拆分拼接的时候,由于对前端知识不熟悉,可能会搞出一堆bug,到最后又需要前端同学帮助分析原因,而前端同学又不是特别了解后端使用的模板,造成尴尬的局面。
  • 如果前端没有使用统一化的文件夹结构,并且静态资源(如图片,css,js等)没有剥离出来放到 CDN,而是使用相对路径去引用,当后端同学需要对静态资源作相关配置时,又得修改各个link,script标签的src属性,容易出错。
  • 接口问题
    1. 后端数据没有准备好,前端需要自己模拟一套,成本高,如果后期接口有改变,自己模拟的那套数据又不行了。
    2. 后端数据已经开发好,接口也准备好了,本地需要代理线上数据进行测试。这里有两个费神的地方,一是需要代理,否则可能跨域,二是接口信息如果改动,后期接你项目的人需要改你的代码,麻烦。
  • 不方便控制输出。为了让首屏加载速度快一点,我们期望后端先吐出一点数据,剩下的才去 ajax 渲染,但让后端吐出多少数据,我们不好控。

当然,存在的问题远不止上面枚举的这些,这种传统的方式实在是不酷(Kimi 附身^_^)。还有一种开发流程,SPA(single page application),前后端职责相当清晰,后端给我接口,我全部用 ajax 异步请求,这种方式,在现代浏览器中可以使用 PJAX 稍微提高体验,Facebook 早在三四年前对这种 SPA 的模式提出了一套解决方案,quickling bigpipe,解决了 SEO 以及数据吐出过慢的问题。他的缺点也是十分明显的:

  • 页面太重,前端渲染工作量也大
  • 首屏还是慢
  • 前后端模板复用不了
  • SEO 依然很狗血(quickling 架构成本高)
  • history 管理麻烦

问题多的已经是无力吐槽了,当然他依然有自己的优势,咱们也不能一票否决。

针对上面看到的问题,现在也有一些团队在尝试前后端之间加一个中间层(比如淘宝UED的 MidWay )。这个中间层由前端来控制。

JavaScript

---------------- | F2E | ---↑--------↑--- | | ---↓--------↓--- | Middle | ---↑--------↑--- | | ---↓--------↓--- | R2E | ----------------

1
2
3
4
5
6
7
8
9
10
11
     ----------------
    |       F2E      |
     ---↑--------↑---
        |        |
     ---↓--------↓---
    |     Middle     |
     ---↑--------↑---
        |        |  
     ---↓--------↓---
    |       R2E      |
     ----------------

中间层的作用就是为了更好的控制数据的输出,如果用MVC模型去分析这个接口,R2E(后端)只负责 M(数据) 这部分,Middle(中间层)处理数据的呈现(包括 V 和 C)。淘宝UED有很多类似的文章,这里不赘述。

关于作者:xiaoheike

图片 6

简介还没来得及写 :) 个人主页 · 我的文章 · 10 ·      

图片 7

一、什么是防盗链

网站资源都有域的概念,浏览器加载一个站点时,首先加载这个站点的首页,一般是index.html或者index.php等。页面加载,如果仅仅是加载一个index.html页面,那么该页面里面只有文本,最终浏览器只能呈现一个文本页面。丰富的多媒体信息无法在站点上面展现。

那么我们看到的各类元素丰富的网页是如何在浏览器端生成并呈现的?其实,index.html在被解析时,浏览器会识别页面源码中的img,script等标签,标签内部一般会有src属性,src属性一般是一个绝对的URL地址或者相对本域的地址。浏览器会识别各种情况,并最终得到该资源的唯一地址,加载该资源。具体的加载过程就是对该资源的URL发起一个获取数据的请求,也就是GET请求。各种丰富的资源组成整个页面,浏览器按照html语法指定的格式排列获取到各类资源,最终呈现一个完整的页面。因此一个网页是由很多次请求,获取众多资源形成的,整个浏览器在一次网页呈现中会有很多次GET请求获取各个标签下的src资源。

图片 8

上图是一篇本站的博客网页呈现过程中的抓包截图。可以看到,大量的加载css、js和图片类资源的get请求。

观察其中的请求目的地址,可以发现有两类,一个是本站的43.242段的IP地址,这是本站的空间地址,即向本站自身请求资源,一般来说这个是必须的,访问资源由自身托管。另外一类是访问182的网段拉取数据。这类数据不是托管站内的,是在其他站点的。浏览器在页面呈现的过程,拉取非本站的资源,这就称“盗链”。

准确的说,只有某些时候,这种跨站访问资源,才被称为盗链。假设B站点作为一个商业网站,有很多自主版权的图片,自身展示用于商业目的。而A站点,希望在自己的网站上面也展示这些图片,直接使用:

<img src=";

1
<img src="http://b.com/photo.jpg"/>

这样,大量的客户端在访问A站点时,实际上消耗了B站点的流量,而A站点却从中达成商业目的。从而不劳而获。这样的A站点着实令B站点不快的。如何禁止此类问题呢?

HTTP协议和标准的浏览器对于解决这个问题提供便利,浏览器在加载非本站的资源时,会增加一个头域,头域名字固定为:

Referer:

1
Referer:

而在直接粘贴地址到浏览器地址栏访问时,请求的是本站的该url的页面,是不会有这个referer这个http头域的。使用Chrome浏览器的调试台,打开network标签可以看到每一个资源的加载过程,下面两个图分别是主页面和一个页面内资源的加载请求截图:

图片 9

图片 10

这个referer标签正是为了告诉请求响应者(被拉取资源的服务端),本次请求的引用页是谁,资源提供端可以分析这个引用者是否“友好”,是否允许其“引用”,对于不允许访问的引用者,可以不提供图片,这样访问者在页面上就只能看到一个图片无法加载的浏览器默认占位的警告图片,甚至服务端可以返回一个默认的提醒勿盗链的提示图片。

一般的站点或者静态资源托管站点都提供防盗链的设置,也就是让服务端识别指定的Referer,在服务端接收到请求时,通过匹配referer头域与配置,对于指定放行,对于其他referer视为盗链。

1 赞 1 收藏 评论

图片 11

本文由千赢国际官网发布于千赢网页手机版登入,转载请注明出处:跨域访问和防盗链基本原理,即使用了

关键词: 千赢国际官网