最新你在项目中做过哪些安全防范措施？(1)，【架构师必备】-CSDN博客

本文链接：https://blog.csdn.net/2401_84264692/article/details/138595794

本人从事网路安全工作12年，曾在2个大厂工作过，安全服务、售后服务、售前、攻防比赛、安全讲师、销售经理等职位都做过，对这个行业了解比较全面。

最近遍览了各种网络安全类的文章，内容参差不齐，其中不伐有大佬倾力教学，也有各种不良机构浑水摸鱼，在收到几条私信，发现大家对一套完整的系统的网络安全从学习路线到学习资料，甚至是工具有着不小的需求。

最后，我将这部分内容融会贯通成了一套282G的网络安全资料包，所有类目条理清晰，知识点层层递进，需要的小伙伴可以点击下方小卡片领取哦！下面就开始进入正题，如何从一个萌新一步一步进入网络安全行业。

学习路线图

其中最为瞩目也是最为基础的就是网络安全学习路线图，这里我给大家分享一份打磨了3个月，已经更新到4.0版本的网络安全学习路线图。

相比起繁琐的文字，还是生动的视频教程更加适合零基础的同学们学习，这里也是整理了一份与上述学习路线一一对应的网络安全视频教程。

网络安全工具箱

当然，当你入门之后，仅仅是视频教程已经不能满足你的需求了，你肯定需要学习各种工具的使用以及大量的实战项目，这里也分享一份我自己整理的网络安全入门工具以及使用教程和实战。

项目实战

最后就是项目实战，这里带来的是SRC资料&HW资料，毕竟实战是检验真理的唯一标准嘛~

面试题

归根结底，我们的最终目的都是为了就业，所以这份结合了多位朋友的亲身经验打磨的面试题合集你绝对不能错过！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以点击这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

输出结果：

XSS Demo

Whitelist

如果后端直接将字符串存入数据库也是不妥的，后端也必须做处理，因为发送到后端的内容还可以通过其他方式, 前端处理并不能保障安全。

2. Cookie 的 HttpOnly

当用户的登录凭证存储于服务器的 session 中，而在浏览器中是以 cookie 的形式存储的。很多XSS攻击目标都是窃取用户cookie伪造身份认证。

可以通过在 cookie 中设置 HttpOnly 属性，js脚本将无法读取到 cookie 信息。

ctx.cookies.set(name, value, {

httpOnly: true // 默认为 true

})

3. CSP(内容安全策略)

CSP (Content Security Policy，内容安全策略)是 W3C 提出的，本质上就是白名单制度，开发者明确告诉浏览器哪些外部资源可以加载和执行。它的实现和执行全部由浏览器完成，我们只需提供配置。

CSP 大大增强了网页的安全性。攻击者即使发现了漏洞，也没法注入脚本，除非还控制了一台列入了白名单的可信主机。

两种方法可以启用 CSP：

一种是通过 HTTP 头信息的Content-Security-Policy的字段
另一种是通过网页的<meta>标签

方式1举例

Content-Security-Policy: default-src ‘self’

表示只允许加载本站资源

Content-Security-Policy: default-src https://demo.example.cn https://demo.example2.cn; object-src ‘none’

CSP 的值中，不同属性以 ; 隔开，同一属性的多个值以空格隔开。上面例子的意思就是默认允许读取 https://demo.example.cn和https://cdn.example2.net 的资源，object-src 使用的相关资源无白名单，也就是完全不允许读出。

如果使用了不符合要求的资源，浏览器会给予拦截，给出下面提示：

Refused to execute inline script because it violates the following Content Security Policy directive

我们也可以使用 meta 标签代替 HTTP 头：

<meta

http-equiv=“Content-Security-Policy”

content=“default-src https://cdn.example.net; child-src ‘none’; object-src ‘none’”

Content-Security-Policy 的常用选项有这些：

default-src: 是 src 选项的默认值，但不能覆盖以下值：base-uri、form-action、frame-ancestors、plugin-types、report-uri、sandbox
base-uri：特别说一下<base> 标签是因为孤陋寡闻的我第一次见到。指定用于一个文档中包含的所有相对 URL 的根 URL，一个文件只能有一个 <base> 标签，用起来大概是这样的：<base target="_top" href="http://www.example.com/">。
connect-src: XHR、WebSockets 等连接使用的地址
font-src：字体文件来源
img-src：图片地址
media-src：音视频地址
object-src：Flash 相关
report-uri：出现报错时提交到指定 uri，不能在标签使用
style-src：样式文件

CSRF 攻击

除了上面说的XSS攻击外，还有一种常见的攻击方式：CSRF攻击。

什么是CSRF攻击

CSRF：跨站点请求伪造（Cross-Site Request Forgeries），也被称为 one-click attack 或者 session riding。冒充用户发起请求（在用户不知情的情况下），完成一些违背用户意愿的事情（如修改用户信息，删除评论等）。

举个例子，好友小A在银行存有一笔钱，输入用户名密码登录银行账户后，发送请求给xiaofan账户转888:

http://bank.example.com./withdraw?account=xiaoA&amount=888&for=xiaonfan

转账过程中，小A不小心打开了一个新页面，进入了黑客（xiaohei）的网站，而黑客网站有如下html代码：

这个模拟的img请求就会带上小A的session值，成功的将888转到xiaohei的账户上。例子虽然是get,post请求提交表单同样会被攻击。

CSRF攻击的特点：

通常发生在第三方网站
攻击者不能获取cookie等信息，只是使用

如何防御

验证码：强制用户必须与应用进行交互，才能完成最终请求。此种方式能很好的遏制 CSRF，但是用户体验相对差。
尽量使用 post ，限制 get 使用；上一个例子可见，get 太容易被拿来做 CSRF 攻击，但是 post 也并不是万无一失，攻击者只需要构造一个form就可以。
Referer check：请求来源限制，此种方法成本最低，但是并不能保证 100% 有效，因为服务器并不是什么时候都能取到 Referer，而且低版本的浏览器存在伪造 Referer 的风险。
token：token 验证的 CSRF 防御机制是公认最合适的方案。

CSRF 与 XSS 区别

通常来说 CSRF 是由 XSS 实现的，CSRF 时常也被称为 XSRF（CSRF 实现的方式还可以是直接通过命令行发起请求等）。

本质上讲，XSS 是代码注入问题，CSRF 是 HTTP 问题。XSS 是内容没有过滤导致浏览器将攻击者的输入当代码执行。CSRF 则是因为浏览器在发送 HTTP 请求时候自动带上 cookie，而一般网站的 session 都存在 cookie里面。XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任。

点击劫持

点击劫持（click hijacking）也称为 UI 覆盖攻击。它通过一些内容（如游戏）误导被攻击者点击，虽然被攻击者点击的是他所看到的网页，但其实所点击的是另一个置于原网页上面的透明页面。

根据先点击劫持原理示意图，分析典型点击劫持攻击流程：