网络安全方面学习笔记(1)

LynnWonderLu

已于 2023-04-16 21:21:10 修改

阅读量660

点赞数

分类专栏： web security 文章标签： web安全安全

于 2020-05-24 11:53:25 首次发布

本文链接：https://blog.csdn.net/lynnwonder6/article/details/106312886

版权

web security 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

网络安全方面学习笔记(1)

文章目录

网络安全方面学习笔记(1)

2020/05/24 add CSRF SSRF

2020/12/28 add img 标签与网络安全

CSRF & SSRF

references:

浅谈CSRF与SSRF

HTTP Referer 教程 🌟🌟🌟🌟🌟

那么其实对于 CSRF XSS 等常见问题很早就进行过总结，今次引入 SSRF 再进行一次合理的汇总

XSS Cross Site Scripting

利用的是用户对指定网站的信任

Cross Site Scripting (XSS)

前端 img 标签安全问题

之前业务上有个功能实现是：鼠标移动上去预览图片，具体可以查看FE 每周问题总结中的「前端位置」章节

直接读取用户的图片 URL 并进行图片预览存在 xss 的危险，最简单的比如 url 设置为 'no" onerror="alert(0)'

再比如直接将 url 写成 evil.com/getref.php，其中脚本是可运行的攻击文件（注意这种不会在前端执行因此无安全隐患）；
其中 <img src="javascript:alert(/xss/)"> 这种语句已经在多数浏览器上不可运行。

再比如是一个普通的 url 不涉及上述安全问题，如果不过滤直接当做图片的 src 进行 load，就会存在鼠标移动上去就发起一个请求，显然这是不符合我们预期

两类问题可以总结为：

恶意 dom 结构
非图片的 URL

xss 攻击的两大要素是：

攻击者提交恶意代码
浏览器执行恶意代码

++解决方案++：

输入检查
1. 检查用户输入的内容是否合法，客户端和服务端都需要
2. 过滤用户输入的内容，将危险的元素剔除，比如
  1. DOMPurify 过滤 html 实体，将 url 中可能含有的 dom 结构过滤掉
输出检查：对要展示的页面进行 encoding，比如 django
设置 HttpOnly cookie，防止客户端通过 js 脚本读取 cookie（因为大部分的 xss 是来读取 cookie 的）
其他：
1. CSP 防止 XSS 攻击：通过配置网页的网页安全策略（CSP）来防止 xss, 它的实现和执行完全是浏览器端完成，开发者只需要进行配置即可，可以通过两种方式开启 CSP
- 通过 HTTP 头信息的Content-Security-Policy的字段。
- 通过网页的meta标签
  注：content-security-policy 其实是白名单机制，告诉了客户端哪些来源的资源可以被加载和执行。

参考 Content Security Policy 入门教程

CSRF Cross Site Request Forgery

Cross Site Request Forgery (CSRF)
利用的是网站对于用户浏览器的信任

简介

当用户在安全网站A登录后保持登录的状态，并在此时浏览了保存有恶意代码的另一个网站B。此时B站劫持用户的浏览器并以用户以登录的状态对A站发送非用户本人的操作。

当服务端没有对这次请求验证的情况下，将这次操作作为可信任的用户的操作。

主要体现在两方面：

从第三方网站向目标网站发起攻击
不会获取到用户的 cookie，只是使用

防御措施

给重要的数据交互增加验证码机制，增加带有大量噪点的验证码，防止请求被伪造，杜绝代码能够识别的简单验证码，当然了也经常被绕过
验证referer, 采用同源政策，referer 记录着数据包的来源地址，来判断请求的合法性，但是这个可以伪造，但这个技术通常用于防盗链。（通常在代码中发起请求时，浏览器会自动带上 Referer 即为当前 host）
- 验证 origin 也是一种服务端用来防御 csrf 的方式
使用 Token：服务端生成 token，并将其存储在 session 中（不再存储在 cookie 中），客户端每次请求都携带这个 token，与 session 中的 token 对比。现在通常是直接计算 token，服务端再计算一次进行对比即可。

SSRF Server-side request forgery

Server-side request forgery (SSRF)

概念：主要是利用服务器 A 的漏洞，以服务器 A 的身份向服务器 B 发起攻击（从服务端发起的请求）。服务器 B 通常是外网无法访问的内网服务器。

原理：
有的大型网站在web应用上提供了从其他服务器获取数据的功能。允许用户用指定的URL web应用获取图片，下载文件，读取文件内容。攻击者利用有缺陷的web应用作为代理攻击远程和内网的服务器（跳板）

主要原因：
漏洞形成的原因大多是因为服务端提供了从其他服务器应用获取数据的功能且没有对目标地址作正确的过滤和限制，因此 ssrf 存在于服务器 A 中。

危害：
攻击内网应用，识别企业内部的资产信息，读取敏感数据等。

防御措施

过滤返回信息，验证远程服务器对请求的响应是比较容易的方法。如果web应用是去获取某一种类型的文件。那么在把返回结果展示给用户之前先验证返回的信息是否符合标准。这样就防止了恶意攻击者利用服务端访问内网服务器相关信息。
统一错误信息，避免用户可以根据错误信息来判断远端服务器的端口状态。
限制请求的端口为 http 常用的端口，比如，80,443,8080,8090。这样可以防止攻击者利用服务端访问内网其他端口
设置服务器 A 可以访问的内网白名单，不使用黑名单或者正则以防止被绕过。
禁用不需要的协议。仅仅允许http和https请求。可以防止类似于file:///,gopher://,ftp:// 等引起的问题，这样可以避免攻击者通过服务端利用这些协议获取内网数据。

其他名词解释

防盗链： A 网站设计美观、浏览量较大，此时B网站就在网站内部引用 A 网站内容，来提高自身的浏览量，此时对于A网站来说，是存在利益问题。这就是一种需要防盗链的场景。

referer 与 origin 的区别：

Referer： Referer 请求头包含了当前请求页面的来源页面的地址，即表示当前页面是通过此来源页面里的链接进入的。
Origin：请求首部字段 Origin 指示了请求来自于哪个站点。该字段仅指示服务器名称，并不包含任何路径信息。该首部用于 CORS 请求或者 POST 请求。除了不包含路径信息，该字段与 Referer 首部字段相似。

因此有如下的不同：

referer 较 origin 会包含路径信息，而这些常常会带有用户的隐私信息。
referer 一般会包含在所有请求中（除页面协议是 file or data URI、https 请求 http 时）。而 origin 只会存在于所有的跨域请求和除GET或HEAD请求外的同源请求(即它们被添加到同源POST、OPTIONS、PUT、PATCH和DELETE请求中)。

基于以上两个不同，一般用校验 origin 的方式来防范 CSRF