登录工程,网页无图再不是梦想

2019-09-11 16:05栏目:人才招聘
TAG:

即使用了 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 赞 收藏 评论

关于作者:ThoughtWorks

图片 6

ThoughtWorks是一家全球IT咨询公司,追求卓越软件质量,致力于科技驱动商业变革。擅长构建定制化软件产品,帮助客户快速将概念转化为价值。同时为客户提供用户体验设计、技术战略咨询、组织转型等咨询服务。 个人主页 · 我的文章 · 84 ·   

图片 7

总结

从功能上来看,我实现了图片到html元素的转换,但是可能并非是最好的网页无图实现方案,因为工具转换出的HTML标签,设置了太多的阴影块,对浏览器的渲染并不友好,会对用户计算机硬件有一定的要求,特别是块大小为1(即完整还原图片)的时候,转换过程非常缓慢,如果图片再大些,极有可能导致用户浏览器崩溃,因此建议大家测试时慎用大图做测试。而且,转换后得到的html标签和样式字符串大小将有可能远远超过图片本身的大小,所以我只能说这是一种可行的技术方案,但未必是好的实现方案。(然并卵)

1 赞 4 收藏 1 评论

图片 8

关于作者:xiaoheike

图片 9

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

图片 10

OAuth 2、Open ID Connect

令牌在广为使用的OAuth技术中被采用来完成授权的过程。OAuth是一种开放的授权模型,它规定了一种供资源拥有方与消费方之间简单又直观的交互方法,即从消费方向资源拥有方发起使用AccessToken(访问令牌)签名的HTTP请求。这种方式让消费方应用在无需(也无法)获得用户凭据的情况下,只要用户完成鉴权过程并同意消费方以自己的身份调用数据和操作,消费方就可以获得能够完成功能的访问令牌。OAuth简单的流程和自由的编程模型让它很好地满足了开放平台场景中授权第三方应用使用用户数据的需求。不少互联网公司建设开放平台,将它们的用户在其平台上的数据以 API 的形式开放给第三方应用来使用,从而让用户享受更丰富的服务。

图片 11

OAuth在各个开放平台的成功使用,令更多开发者了解到它,并被它简单明确的流程所吸引。此外,OAuth协议规定的是授权模型,并不规定访问令牌的数据格式,也不限制在整个登录过程中需要使用的鉴权方法。人们很快发现,只要对OAuth进行合适的利用即可将其用于各种自有系统中的场景。例如,将 Web 服务视作资源拥有方,而将富Web应用或者移动应用视作消费方应用,就与开放平台的场景完全吻合。

另一个大量实践的场景是基于OAuth的单点登录。OAuth并没有对鉴权的部分做规定,也不要求在握手交互过程中包含用户的身份信息,因此它并不适合作为单点登录系统来使用。然而,由于OAuth的流程中隐含了鉴权的步骤,因而仍然有不少开发者将这一鉴权的步骤用作单点登录系统,这也俨然衍生成为一种实践模式。更有人将这个实践进行了标准化,它就是Open ID Connect——基于OAuth的身份上下文协议,通过它即可以JWT的形式安全地在多个应用中共享用户身份。接下来,只要让鉴权服务器支持较长的会话时间,就可以利用OAuth为多个业务系统提供单点登录功能了。

图片 12

我们还没有讨论OAuth对鉴权系统的影响。实际上,OAuth对鉴权系统没有影响,在它的框架内,只是假设已经存在了一种可用于识别用户的有效机制,而这种机制具体是怎么工作的,OAuth并不关心。因此我们既可以使用用户名密码(大多数开放平台提供商都是这种方式),也可以使用扫码登录来识别用户,更可以提供诸如“记住密码”,或者双因子验证等其他功能。

案例分析

通过使用开发者工具分析以上案例的源码,我发现其实它的实现并不难。我们知道在CSS3中新增了一个设置盒子阴影的box-shadow属性,而这个属性可以同时设置任意多个不同颜色和扩散度的阴影块,而案例正是完美的诠释了这个新属性。

既然如此,那么我们现在来做个试验,我们在任一一张图上覆盖上一个个大小相同的小方格子,我们就可以将任何一张图片分隔成一个个的小方格,我们只要知道这些小方格的大小、顺序和位置,我们就可以重组这张图片,如下对比图所示:

图片 13

但是,有个问题:box-shadow的引用颜色是单色的,而每个盒子范围内的图案是复杂的,我们如何去处理这个问题?

因为box-shadow只能设置颜色,所以这个问题的结果只有一个,找出一个能代表这个格子的颜色,那么选取哪一个颜色值就因人而异了,可以选格子四角的任意一个、可选中心点,可选格子内的任意一个点,我选择的是格子的左上角这个点。我们不难发现,如果我们尽可能的缩小格子,小到只剩下一个像素大小,我们就可以完整的还原一张图片了。

解析常见的登录场景

在简单的Web系统中,典型的鉴权也就是要求用户输入并比对用户名和密码的过程,而授权则是确保会话Cookie存在。而在稍微复杂的Web系统中,则需要考虑多种鉴权方式,以及多种授权场景。上一篇文章中所述的“多种登录方式”和“双因子鉴权”就是多种鉴权方式的例子。有经验的人经常调侃说,只要理解了鉴权与授权,就能清晰地理解登录系统了。不光如此,这也是安全登录系统的基础所在。

鉴权的形式丰富多彩,有传统的用户名密码对、客户端证书,有人们越来越熟悉的第三方登录、手机验证,以及新兴的扫码和指纹等方式,它们都能用于对用户的身份进行识别。在成功识别用户之后,在用户访问资源或执行操作之前,我们还需要对用户的操作进行授权。

图片 14

在一些特别简单的情形中——用户一经识别,就可以无限制地访问资源、执行所有操作——系统直接对所有“已登录的人”放行。比如高速公路收费站,只要车辆有合法的号牌即可放行,不需要给驾驶员发一张用于指示“允许行驶的方向或时间”的票据。除了这类特别简单的情形之外,授权更多时候是比较复杂的工作。

在单一的传统Web应用中,授权的过程通常由会话Cookie来完成——只要服务器发现浏览器携带了对应的Cookie,即允许用户访问资源、执行操作。而在浏览器之外,例如在Web API调用、移动应用和富 Web 应用等场景中,要提供安全又不失灵活的授权方式,就需要借助令牌技术。

缘起

那是一个工作日的早上,我向往常一样准时到达了工作岗位上,启动电脑,打开浏览器我偶然发现了一篇名曰《18个你可能不相信是用CSS制作出来的东西》的文章,出于职业敏感,也出于好奇我就点进去看了一看,发现其中有一个很有意思的作品:,它仅仅用一个div标签就完成了这幅作品,于是我们几个同事好奇使然,开始分析它的实现,渐渐有了下面即将介绍的工具的影子。

版权声明:本文由ag真人发布于人才招聘,转载请注明出处:登录工程,网页无图再不是梦想