WKWebView详解（三）Cookie的认识

Posted 2023-05-16

参考技术A

我们通过的服务器和客户端进行交互往往是通过https/http请求完成的，而这个协议是无连接的，但有时候我们的业务中需要实现多次请求是有一定关联性的，所以就需要约定一个信息供客户端和服务器端进行识别，这里就是用到了Cookie和Session。
客户端请求时携带上Cookie，服务器端进行识别，识别后就可以进行处理，Cookie中携带的最重要的信息就是SessionID，这个ID就可以查询到服务器端保存的Session，Session中保存了大量的该用户信息，识别后就可以通过这些用户信息对这个请求进行处理。

在WKWebView中，我们能做的就是对Cookie进行处理

作用：

客户端在一次给服务器端发送请求时，服务器端会生成一个Cookie返回给给客户端，客户端在下一次请求发送时会携带上该Cookie，这样后续请求就可以使用该Cookie来识别。

Expires：

Max-Age：

Domain：

Path：

Secure：

HttpOnly：

SameSite：

会话期Cookie： 仅作用在会话期，浏览器关闭 后就会被自动删除，会话期Cookie不需要指定Expires或Max-Age部分浏览器提供了恢复会话功能，即使关闭浏览器，会话期Cookie也会被保留下来

持久性Cookie： 生命周期取决于Expires或Max-Age指定的时间（设定的时间只与客户端相关，而不是服务器端）

有两种方法可以确保Cookie被安全的发送，并且不会被以外的参与者或脚本访问，Secure属性和HttpOnly属性

Secure属性：
只应通过被 HTTPS 协议加密过的请求发送给服务端，因此可以预防 man-in-the-middle 攻击者的攻击。但即便设置了 Secure 标记，敏感信息也不应该通过 Cookie 传输。因为 Cookie 有其固有的不安全性，Secure 标记也无法提供确实的安全保障。

HttpOnly属性：
javascript Document.cookie API 无法访问带有 HttpOnly 属性的cookie，此类 Cookie 仅作用于服务器
例如，持久化服务器端会话的 Cookie 不需要对 JavaScript 可用，而应具有 HttpOnly 属性。
此预防措施有助于缓解跨站点脚本（XSS） (en-US)攻击。

Domain 和 Path 标识定义了Cookie的作用域：即允许 哪些请求携带Cookie 。

Domain 属性：
Domain 指定了哪些主机可以接受 Cookie。如果不指定，默认为 origin，不包含子域名。如果指定了Domain，则一般包含子域名。

Path属性：
Path 标识指定了主机下的哪些路径可以接受 Cookie

SameSite attribute：
SameSite Cookie 允许服务器要求某个 cookie 在跨站请求时不会被发送，从而可以阻止跨站请求伪造攻击（CSRF）

Cookie prefixes：
对于子域访问的特性，会出现这种情况：子域上的易受攻击的应用程序可以使用 Domain 属性设置 cookie，从而可以访问所有其他子域上的该 cookie。因此cookie 的机制使得服务器无法确认 cookie 是在安全来源上设置的，甚至无法确定 cookie 最初是在哪里设置的。

Cookie中的信息是可以被访问和修改的，因此具有不安全性，需要设置身份验证/机密机制，并且如果没有设置安全环境时，不能通过Cookie存储、传输敏感信息。

在 Web 应用中，Cookie 常用来标记用户或授权会话。因此，如果 Web 应用的 Cookie 被窃取，可能导致授权用户的会话受到攻击。
常用的窃取 Cookie 的方法有利用社会工程学攻击和利用应用程序漏洞进行 XSS (en-US) 攻击。

HttpOnly 类型的 Cookie 用于阻止了JavaScript 对其的访问性而能在一定程度上缓解此类攻击。

在本站点发送其他站点的请求，以达到恶意获取请求信息的目的，比如在不安全聊天室或论坛上的一张图片，它实际上是一个给你银行服务器发送提现的请求：当你打开含有了这张图片的 html 页面时，如果你之前已经登录了你的银行帐号并且 Cookie 仍然有效。

阻止方法：

WKWebView 从 HTTP 请求中注入 cookie

【中文标题】WKWebView 从 HTTP 请求中注入 cookie

【英文标题】：WKWebView inject cookies from HTTP request

【发布时间】：2017-07-16 18:08:14

【问题描述】：

我正在开发具有WKWebView 和本机登录屏幕的 iOS 应用程序。在本机登录屏幕上，用户可以通过返回 JSON 对象和两个 cookie 的 API 调用来登录。

我要做的是，当呼叫成功并且用户转到WKWebView 屏幕时，他们也会登录到显示的网站上。

WKWebView 已经加载，所以我的问题是我应该如何处理 cookie 以便用户登录 WKWebView？ 我读过this question & answer 但这对我不起作用。 WKWebView 没有显示任何内容，所以我认为它被阻止或处于循环中。

更新 我正在使用多个 WKWebViews，我发现如果我进行 API 调用，然后转到一个 WKWebView 它工作正常，我已登录。可能这里棘手的部分是我正在使用多个 WKWebViews。

【问题讨论】：

也许这个答案对你有帮助***.com/questions/26573137/…

【参考方案1】：

我终于找到了解决我的 cookie 问题的方法。

我必须为我所有的WKWebViews 创建一个全局WKProcessPool，并且我必须在每次登录调用时从HTTPCookieStorage.shared.cookies 发送cookie，所以我返回的cookie 仍然连接到WKWebViews 和什么都没有丢失。希望这可以帮助遇到同样问题的人。

【讨论】：

我在处理 cookie 方面需要帮助

【参考方案2】：

iOS11 以优雅的方式支持您的用例WKHTTPCookieStore。通过JSON api登录并获取cookie后，在WKWebView中使用setCookie自动登录用户。

WKWebView 在 iOS11 中获得了重大更新，并开辟了许多新的有趣的可能性。 Customized Loading in WKWebView WWDC session 中有您特定用例的演示。

很遗憾，如果您需要为 iOS10 或更早版本完成此操作，这将无济于事。

【讨论】：

看起来很有希望，但我现在也需要支持 iOS 10