1：SQL 注入、DDos 攻击、DNS 劫持
就是通过把 SQL 命令插入到 Web 表单递交或输入域名或页面请求的查询字符串，最终达到欺骗数据库服务器执行恶意的 SQL 命令,从而达到和服务器进行直接的交互 防御： i）后台进行输入验证，对敏感字符过滤。 ii）使用参数化查询，能避免拼接 SQL，就不要拼接 SQL 语句。
2： XSS，CSRF
3：前端安全知识防止被偷袭
4： https
影响：
防御：
利用已通过认证的用户权限更新设定信息等； 利用已通过认证的用户权限购买商品； 利用已通过的用户权限在留言板上发表言论。
防御：
代码注入风险 第三方库可能包含恶意代码，攻击者可通过依赖注入后门、篡改包等方式实现代码执行。
XSS 和 CSRF 漏洞 库中未正确处理用户输入或请求，可能导致跨站脚本攻击（XSS）或跨站请求伪造（CSRF）。
依赖漏洞 库本身或其依赖存在已知安全漏洞，攻击者可利用这些漏洞进行攻击。
敏感信息泄露 库可能在日志、错误信息或配置中泄露敏感数据，如 API 密钥、用户信息等。
供应链攻击 攻击者通过篡改第三方库或其依赖，影响大量下游项目。
权限提升 某些库可能未经授权访问文件系统、网络等敏感资源，导致权限提升。
更新滞后 第三方库长期未维护或未及时修复安全问题，易被攻击者利用。
建议：
使用 CSP（内容安全策略）
通过设置 Content-Security-Policy 只允许加载指定来源的脚本。
避免动态插入外部脚本
禁止通过 eval、innerHTML、document.write 等方式插入未知来源的脚本。
校验第三方资源来源 只使用可信域名的第三方脚本，并定期审查其安全性。
子资源完整性（SRI）
使用 <script> 标签的 integrity 属性校验脚本内容，防止被篡改。
禁止跨域请求敏感数据 配置 CORS，限制外域访问敏感接口。
使用 HTTPS
sessionId=abc123Expires=Wed, 21 Oct 2026 07:28:00 GMTMax-Age=3600（优先于 Expires）Domain=.example.comPath=/accountdocument.cookie 访问，防止 XSS 窃取Lax（默认，部分跨站允许，如 GET 导航）Strict（完全禁止跨站携带）None（允许跨站；需配合 Secure）High|Medium|Low）Partitioned示例（Set-Cookie）:
Set-Cookie: sessionId=abc123; Max-Age=3600; Path=/; Domain=.example.com; Secure; HttpOnly; SameSite=Lax
请求时仅包含“名称=值”对，多个以 ; 分隔，其他属性不随请求发送：
Cookie: sessionId=abc123; theme=dark
使用加密算法生成 token
服务端保存密钥
token 内容避免敏感信息
传输时使用 HTTPS
设置有效期与刷新机制
数字证书是一种由权威机构（CA，证书颁发机构）签发的电子文件，用于证明公钥的归属和身份合法性。它在网络通信中主要用于加密和身份认证。
数字证书是现代互联网安全的基础，保障数据传输的安全与可信。
Header.Payload.Signature（三段 Base64URL 字符串，用 . 连接）
alg、类型 typ示例：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0IiwibmFtZSI6IkFsaWNlIiwiaWF0IjoxNjk5OTk5OTk5LCJleHAiOjE3MDAwMDA1OTksImlzcyI6ImFwaS5leGFtcGxlLmNvbSIsImF1ZCI6ImNsaWVudC0xIn0.
<signature>
sub、iat、exp、iss、aud 等），使用密钥（HS256）或私钥（RS256）签名并返回Authorization: Bearer <jwt>alg 获取密钥/公钥验证签名（确保未被篡改）exp（未过期）、nbf、iat、iss、aud 等sub、role）进行授权控制jti 或用户版本号（低频校验或集中网关校验）localStorage（容易被 XSS 读取）iss、aud、exp、nbf、iat，设置合理的时钟偏移容忍alg: none，固定白名单算法function authenticate(request) {
const token = readBearerToken(request.headers.Authorization)
const { header, payload, signature } = decodeJWT(token)
assertAllowedAlg(header.alg)
verifySignature(header, payload, signature, getKey(header))
assert(now() < payload.exp && now() >= (payload.nbf || 0))
assert(payload.iss === EXPECT_ISS && payload.aud === EXPECT_AUD)
return { userId: payload.sub, roles: payload.role }
}
前端请求设置
在发起跨域请求时，需设置 withCredentials: true（如 XMLHttpRequest 或 fetch）：
fetch('https://域名B.com/api', {
credentials: 'include'
})
服务端设置
Access-Control-Allow-Origin: 域名A地址
Access-Control-Allow-Credentials: true
域名 B 的 Cookie 必须设置 SameSite=None; Secure，否则不会在跨域请求中携带：
Set-Cookie: key=value; SameSite=None; Secure
OAuth2.0 是一种开放标准的授权协议，允许用户授权第三方应用访问其在某服务上的资源（如用户信息），而无需暴露账号密码。常用于“第三方登录”场景，如微信、支付宝、GitHub 登录。
用户点击第三方登录按钮
用户同意授权
授权码回调
第三方应用用授权码换取令牌
第三方应用使用令牌访问资源
OAuth2.0 是现代互联网第三方登录和授权的基础协议。
HTTP 协议本身不记录每次请求的用户身份，因此 Web 应用需通过以下方式保持用户登录状态：
Cookie 会话标识
Set-Cookie 响应头发送给浏览器。Token（令牌）机制
服务端会话存储
总结： Web 应用通过 Cookie 或 token 等机制，将用户身份信息在客户端和服务端之间安全传递，实现登录态的保持。
之所以还能正常加载，是因为 同源策略对不同资源类型、不同“风险等级”的操作规定了不同的“跨域规则”。 对于“读”脚本、图片、样式表等静态资源，浏览器默认就允许跨域 GET，所以不会触发 CORS 预检，也不会报错。
CSP 通过限制 Web 应用程序能够加载和执行的内容，来减少恶意攻击的成功率。具体来说，CSP 允许 Web 应用程序管理员定义哪些来源可以加载资源和运行 JavaScript 等代码。这些源可以是域名、协议或端口号等。 CSP 的工作流程如下：
点击劫持是一种视觉欺骗的攻击手段，攻击者将需要攻击的网站通过 iframe 嵌套的方式嵌入自己的网页中，并将 iframe 设置为透明，在页面中透出一个按钮诱导用户点击。
我们可以在 http 相应头中设置 X-FRAME-OPTIONS 来防御用 iframe 嵌套的点击劫持攻击。通过不同的值，可以规定页面在特 定的一些情况才能作为 iframe 来使用。
无加密传输 使用 ws:// 协议时，数据明文传输，易被窃听和篡改。
跨站 WebSocket 劫持 恶意网站可发起 WebSocket 连接，利用用户已登录状态进行操作。
身份认证与鉴权缺失 WebSocket 建立后，若无有效身份校验，攻击者可伪造请求。
数据注入与 XSS 未对消息内容做校验，可能被注入恶意脚本。
DoS 攻击 大量连接或恶意消息可导致服务端资源耗尽。
CSRF 风险 WebSocket 连接可被第三方网站利用，发起跨站请求。
使用 wss:// 加密协议 通过 TLS 加密 WebSocket 通信，防止窃听和篡改。
严格身份认证与鉴权 建立连接时校验用户身份，定期验证令牌或 session。
来源校验（Origin） 服务端校验请求头中的 Origin，拒绝非法来源的连接。
消息内容校验与过滤 对接收和发送的数据进行格式校验，防止注入攻击。
连接数与消息速率限制 限制单 IP 或用户的连接数和消息频率，防止 DoS 攻击。
关闭不必要的跨域 不允许任意网站建立 WebSocket 连接，限制允许的来源。
定期断开空闲连接 清理长时间无活动的连接，释放资源。
总结： WebSocket 安全需从加密、认证、校验、限流等多方面综合防护，确保数据和服务安全。
SameSite 是 Cookie 的一个属性，用于限制第三方网站在跨站请求时携带该 Cookie，从而防止 CSRF 等安全问题。
Secure 属性，仅在 HTTPS 下生效。作用： 提升 Cookie 的安全性，防止跨站请求伪造（CSRF）等攻击。
中间人攻击是一种网络攻击方式，攻击者在用户与服务器之间“中间”截获、篡改或伪造双方通信内容。攻击者可以窃取敏感信息（如账号、密码、Cookie），甚至修改数据，造成信息泄露或欺诈。
总结： 中间人攻击危害极大，需通过加密、认证等多重手段防护。
Set-Cookie: ...; Domain=.example.com; Path=/，两者均会携带该 Cookie。Domain=.com 这类公共后缀（受 Public Suffix List 限制）。Secure 仅在 HTTPS 发送。SameSite=None; Secure，且受浏览器第三方 Cookie 策略影响（可能被阻止）。auth.example.com）重定向携带临时码，在各域换取本域 Cookie。postMessage + 后端换票，不直接共享 Cookie。结论：Cookie 只能在同一可注册主域的子域间共享；跨不同主域需要借助 SSO/令牌等机制实现登录状态传递。
integrity: 资源哈希，格式：算法-Base64哈希，可并列多个算法crossorigin: 跨域资源需设置，否则可能因 CORS 失败导致 SRI 失效（常用 anonymous）<!-- JS -->
<script
src="https://cdn.example.com/app.min.js"
integrity="sha384-Base64HashHere"
crossorigin="anonymous"
></script>
<!-- CSS -->
<link
rel="stylesheet"
href="https://cdn.example.com/app.min.css"
integrity="sha384-Base64HashHere"
crossorigin="anonymous"
/>
sha384 或 sha512（更安全且兼容好）integrity="sha384-... sha512-..."# 生成 sha384
node -e "const fs=require('fs');const c=fs.readFileSync('dist/app.min.js');const h=require('crypto').createHash('sha384').update(c).digest('base64');console.log('sha384-'+h)"
openssl dgst -sha384 -binary dist/app.min.js | openssl base64 -A | sed 's/^/sha384-/'
webpack-subresource-integrityvite-plugin-subresource-integrityrollup-plugin-sriContent-Security-Policy: script-src 'self' https://cdn.example.com; style-src 'self' https://cdn.example.com
script-src、style-src 来源白名单'unsafe-inline'，改用 nonce/hash 或外链+SRIcrossorigin：CDN 响应需带 Access-Control-Allow-Origin（通常为 *），否则 SRI 校验会失败。<link rel="preload"> 不影响 SRI，但最终引用仍需带 integrity。<script
src="https://cdn.example.com/app.js"
integrity="sha384-..."
crossorigin="anonymous"
onerror="this.remove();var s=document.createElement('script');s.src='/app.js';document.head.appendChild(s)"
></script>
integrity。crossorigin 与严格的 CSP，可显著降低供应链与 CDN 篡改风险。用户想了解 iframe 的安全性，并要求以 Markdown 格式输出。我需要搜索相关信息，然后整理成 Markdown 格式的文档。
toolName: web_search
status: success
query: iframe 安全性问题与最佳实践
iframe（内联框架）是 HTML 中的一个元素，允许在当前网页中嵌入其他网页内容。虽然 iframe 能够为网页带来更丰富的内容和功能，但同时也带来了一系列安全隐患。
点击劫持（Clickjacking）：攻击者可以将目标网站嵌入到透明的 iframe 中，诱导用户在不知情的情况下点击，从而执行恶意操作。
第三方内容风险：iframe 中的内容由第三方提供，默认情况下不受我们控制，可能会运行恶意 JavaScript 脚本、Flash 插件或弹出对话框。
域名劫持风险：如果 iframe 中的域名过期被恶意攻击者抢注，或第三方网站被黑客攻破，iframe 中的内容可能被替换为恶意内容。
资源消耗：iframe 是能耗较高的 HTML 元素，过多使用可能影响页面性能。
这个 HTTP 响应头可以控制页面是否允许在 iframe 中被加载
# 不允许被嵌入
X-Frame-Options: deny
# 只允许同源页面嵌入
X-Frame-Options: sameorigin
# （已废弃）只允许指定来源的页面嵌入
X-Frame-Options: allow-from www.example.com
CSP 提供了更强大和灵活的安全控制：
# 不允许被嵌入
Content-Security-Policy: frame-ancestors 'none'
# 只允许同源页面嵌入
Content-Security-Policy: frame-ancestors 'self'
# 只允许指定来源的页面嵌入
Content-Security-Policy: frame-ancestors www.example.com
在客户端使用 JavaScript 代码防止页面被嵌入
// 基本版本
if(top != self) {
top.location.replace(location);
}
// 增强版本
<style> html{display:none;} </style>
<script>
if(self == top) {
document.documentElement.style.display = 'block';
} else {
top.location = self.location;
}
</script>
使用 sandbox 属性可以对 iframe 进行一系列限制，提高安全性
<iframe src="example.html" sandbox="allow-scripts allow-forms"></iframe>
常用的 sandbox 值：
allow-scripts：允许执行脚本allow-forms：允许提交表单allow-same-origin：允许同源访问allow-top-navigation：允许导航到顶级窗口只嵌入可信任的来源：尽量只嵌入你信任的网站内容。
使用 HTTPS：确保主页面和嵌入的 iframe 页面都使用 HTTPS 协议。
设置适当的 CSP 策略：使用 Content-Security-Policy 限制 iframe 可以加载的内容。
使用 sandbox 属性：根据需要为 iframe 设置 sandbox 属性，只授予必要的权限。
避免过度使用：iframe 会消耗较多资源，应适度使用
考虑替代方案：对于某些场景，可以考虑使用 AJAX、Web Components 等现代技术替代 iframe。
HTTPS 并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但 HTTPS 仍是现行架构下最安全的解决方案，主要有以下几个好处：