常见安全漏洞整理

常见安全漏洞整理

整理一波常见的安全漏洞，如果你对web安全 / 漏洞攻击感兴趣，可以尝试耐心看完。笔者花心思整理了几个小时，不是搜索，查询，CV。有漏洞原理、案例讲解、漏洞产生流程的分析和常见的防护方案。

Q1-越权漏洞

1. 水平越权

• 相同权限的不同用户可以相互访问

2. 垂直越权

• 权限低的用户可以访问到权限高的用户

Q2-CSRF漏洞

漏洞简介

• CSRF（Cross-site Request Forgery，跨站请求伪造）
• 挟持用户在当前已登录的Web应用程序上执行非本意操作的攻击方法，可简单描述为“攻击者盗用了你的身份，以你的名义发送恶意请求”。

漏洞危害

• 盗取用户隐私数据（如个人信息/关系链信息等）
• 篡改目标网站上的用户数据（如改密/改身份信息/转虚拟资产/发送消息等）
• CSRF蠕虫（如传播不良信息/刷关注/刷排行/扩大风险范围等）

漏洞产生流程

1. 用户登录业务网站A，并在本地生成cookie
2. 在未登出A网站的同时，用户在恶意网站B访问了恶意构造链接（多为诱导点击）
3. B网站可通过JS代码等方式实现在用户不知情的情况下，利用浏览器特性（自动携带受害者在A网站的cookie）向A网站发起访问，并对数据进行增删改查等操作

漏洞防护

1. 验证 HTTP Referer 头部确保请求来源合法
2. 使用csrf token 保证客户端和服务端一一对应
3. 使用 SameSite Cookie，限制cookie发送范围

Q3-逻辑漏洞

漏洞简介

• 逻辑漏洞没有固定的套路，泛指定义了一组业务规则，但没做好校验，让恶意用户绕过规则造成损失的漏洞。可产生各种危害，比如窃取系统财产、窃取别的用户隐私等。

漏洞场景

1、绕过限制获取利益

场景描述

用户绕过权限活动高权限用户的利益，如领取高级vip的礼包

漏洞修复

执行sql做好权限校验，校验用户的 userid 与操作者是否符合、level 是否支持操作

2、并发攻击

场景描述

某积分抽奖的业务逻辑是先抽奖（逻辑多处理慢）再扣积分，由于没用事务，同个账号大量请求并发时会中多次奖但是分还不够扣。恶意用户并发发送请求抽奖，造成抽奖成功多次，但是积分没扣成功。

漏洞修复

解决办法是加用户粒度的分布式锁，并且先扣积分再抽奖。

3、浮点精度利用

场景描述

用户绕过权限活动高权限用户的利益，如领取高级vip的礼包

漏洞修复

对参数做严格校验，需要正整数的就严格校验正整数，允许输入负数、浮点数、字符串都可能带来风险，特别是js这种类型不敏感的语言。

4、前后环节容错机制没对齐的利用

场景描述

修改订单数据可以实现超低价格购买。
如，平台价格计算为，商品单价 *商品数量。用户修改数据商品数量为 0.001 那么100元的商品只需要支付一分钱

漏洞修复

对参数做严格校验，需要正整数的就严格校验正整数，允许输入负数、浮点数、字符串都可能带来风险，特别是js这种类型不敏感的语言。

Q4-XSS漏洞

漏洞简介

• Cross-Site Scripting（跨站脚本攻击）简称 XSS，是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。利用这些恶意脚本，攻击者可获取用户的敏感信息如 Cookie、SessionID 等，进而危害数据安全。

• 根据攻击来源，xss 攻击可分为存储型、反射型、dom型三种。

类型	存储区	插入点
存储型XSS	后端数据库	HTML
反射型XSS	URL	HTML
DOM 型XSS	后端数据库/前端存储/URL	前端JavaScript

• 存储区：恶意代码存放的位置。
• 插入点：由谁取得恶意代码，并插入到网页上。

漏洞场景

1）存储型 XSS

• 存储型 XSS 的攻击步骤：

1. 攻击者将恶意代码提交到目标网站的数据库中。
2. 用户打开目标网站时，网站服务端将恶意代码从数据库取出，拼接在 HTML 中返回给浏览器。
3. 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
4. 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。
   这种攻击常见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信等。

2）反射型 XSS

• 反射型 XSS 的攻击步骤：

1. 攻击者构造出特殊的 URL，其中包含恶意代码。
2. 用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。
3. 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
4. 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。
   反射型 XSS 跟存储型 XSS 的区别是：存储型 XSS 的恶意代码存在数据库里，反射型 XSS 的恶意代码存在 URL 里。
   反射型 XSS 漏洞常见于通过 URL 传递参数的功能，如网站搜索、跳转等。
   由于需要用户主动打开恶意的 URL 才能生效，攻击者往往会结合多种手段诱导用户点击。
   POST 的内容也可以触发反射型 XSS，只不过其触发条件比较苛刻（需要构造表单提交页面，并引导用户点击），所以非常少见。

3）DOM 型 XSS

• DOM 型 XSS 的攻击步骤：

1. 攻击者构造出特殊的 URL，其中包含恶意代码。
2. 用户打开带有恶意代码的 URL。
3. 用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。
   恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

漏洞防护

存储型和反射性预防方案：

1. 输出编码（因为它与跨站点脚本有关）的目的是将不受信任的输入转换为安全的形式，其中输入作为数据显示给用户，而无需在浏览器中作为代码执行。
2. 白名单 黑名单过滤恶意字符
3. 正则限定格式，对已确定数据的基本格式进行限定 比如将输入数据限定在大小写字母、数字、下划线这几种，这在用户名注册，还有密码设置的时候经常会使用到
4. 添加安全响应头(Http Header)
5. 设置HttpOnly和Secure属性

• 1）cookie设置HttpOnly：禁止javascript读取,如果cookie中的一个参数带有httponly，则这个参数将不能被javascript获取
  response.setHeader( “Set-Cookie” , “cookiename=httponlyTest;Path=/;Domain=domainvalue;Max-Age=seconds;HTTPOnly”);

• 2）cookie设置secure（SSL）：当设置为true时，表示创建的 Cookie 会被以安全的形式向服务器传输（ssl），仅https协议中发送
  response.setHeader(“Set-Cookie”, “JSESSIONID=” + sessionid + “;Secure;HttpOnly”)//设置Secure;HttpOnly

dom型预防方案：

• 方案参考：
• 1）https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html
• 2）驱散前端安全梦魇——DOMXSS典型场景分析与修复指南
• 3）DOM操作时，对恶意字符、重定向地址进行验证和过滤（可以借助第三方库）

Content Security Policy

• 禁止加载外域代码，防止复杂的攻击逻辑。
• 禁止外域提交，网站被攻击后，用户的数据不会泄露到外域。
• 禁止内联脚本执行（规则较严格，目前发现 GitHub 使用）。
• 禁止未授权的脚本执行（新特性，Google Map 移动版在使用）。
• 合理使用上报可以及时发现 XSS，利于尽快修复问题。

Q5-SSRF漏洞

漏洞简介

• SSRF（Server-Side Request Forgery）服务端请求伪造漏洞，攻击者可以通过传入特殊构造的URL，伪造服务端对内网发起恶意请求。一般情况下，SSRF攻击的目标是从外网无法访问的内部系统。

漏洞危害

• 内网被恶意扫描，泄露内网敏感信息
• 针对性地对内网应用开展攻击，如利用file协议获取文件、利用gopher协议攻击内网redis植入木马等

漏洞产生场景

1. 服务器从内网服务器获取图片、下载文件、读取文件内容等
2. 在线识图，在线翻译文档或网页，通过 URL 上传文件或图片等
3. 接入内容安全识别、图片/视频质量分析等服务，未指定使用仅外网集群

漏洞防护

1. 提倡默认安全编码方法优先考虑严格的域名/URL白名单，不允许访问内网；
2. 无法使用白名单时，须使用安全组件scurl（Safe curl）校验请求非内网资源；
3. 内部服务未直接提供给外网用户访问，但外网用户通过其他服务间接调用该内部服务时，该内部服务也存在SSRF风险，故使用第三方服务时，需指定使用仅公网集群（只拉取公网资源）

• 后端也要做好异常处理，不能直接抛回异常信息给前端

Q6-跳转漏洞

漏洞简介

• 某些业务场景需要处理url跳转，但是开发者未对跳转目标做严格校验，导致攻击者可以利用跳转功能跳转到其他恶意目标站点。

漏洞产生场景

https://xxx.com?url=hppt://www.qq.com  // 路由携带url跳转参数
String url = request.getParam("url")  // 获取路由中的url值
Response.sendRedirect( url )  // 重定向跳转

漏洞防护

1. 尽量避免这种提供URL跳转、重定向的功能
2. 尽量不要根据用户输入的URL参数拼接，进行跳转、重定向。
3. 根据业务场景，后台配置允许跳转的目录和信任的域名列表，仅允许在白名单里跳转。陷阱！注意使用 in 数组/列表来精确匹配判断，或者使用带^$包围的正则以防止部分匹配致绕过
4. 如果无法限制用户输入，建议提供中间页面明确告知用户将离开本站

Q7-上传漏洞

漏洞简介：

• 文件上传漏洞，是指业务上传接口相关代码在判断上传文件时，没有严格校验上传文件的文件名后缀，导致攻击者可以上传恶意文件到业务系统，在业务系统上执行任意代码，控制服务器。

漏洞修复：

1. 校验上传文件后缀，是否在白名单内，例如后缀是否是jpg、bmp、png等。（读取16进制文件头校验文件类型，而不是单纯通过文件后缀或mimetype来判断文件类型）
2. 存储文件名随机化
3. 禁止外部参数自定义上传文件目标路径
4. 关闭上传目录执行权限

Q8-服务器敏感信息泄露

漏洞描述：

• 通过访问链接：https://xxxx/Dockerfile 可以下载该服务dockerfile文件（敏感文件）

漏洞原因：

• 部署服务的流水线生成的镜像制作文件，Dockerfile随着镜像发布流程发布到了站点服务的根目录上，恰好该服务的静态文件目录恰好是站点的根目录所造成的。

漏洞修复：

• 采取文件后缀白名单过滤以及文件黑名单过滤的双重过滤机制。前者保证了只有白名单后缀的文件才可以发布到服务，后者对于文件过滤差缺补漏，保证白名单无法过滤的情况下进行兜底过滤如：流水线构建镜像所依赖生成的中间敏感文件，这些文件是无法提前做白名单过滤的。

1. 文件后缀白名单：
   通用文件后缀：“.js” “.json” “.css” “.less” “.scss” “.html” “.shtml” “.htm” “.xml” “.htc” “.map” “.txt” “.lnk” “.txt” “.ico” “.jpg” “.png” “.gif” “.svg” “.swf” “.mp4” “.ttf” “.eot” “.woff” “.woff2” “.otf” “.cur”
   java服务文件后缀：“.jsp” “.class” “.java” “.smap” “.tag” “.jar”
   php服务文件后缀：“php” “conf” “ini”
2. 文件黑名单：
   文件：Dockerfile* *php.ini *php-fpm.conf *nginx.conf *.DS_Store *.gitmodules *pom.xml *Gruntfile.js *webpack.config.js *package.json *known_hosts *authorized_keys *config.ini
3. 目录：
   *.git *.svn dependency maven

Q9-用户敏感信息泄露

漏洞描述：

• web页面处理用户信息时泄露用户敏感信息（如：ajax请求）

防护方式：

• 用户敏感信息，如 手机号，身份证号等，要对其进行 加密存储，脱敏展示
  加密存储，脱敏展示！

Q10-sql注入

漏洞简介

• 如果程序根据用户输入的参数动态生成SQL语句并执行，黑客可通过传入恶意参数值注入自己定义的语句，使数据库执行任意自己需要的指令，实现数据窃取或入侵破坏。

漏洞危害

• 导致拖库、敏感信息泄露
• 数据被篡改、删除
• 数据库主机服务器被入侵

漏洞产生场景

const req = ctx.request.body;
let sqlStr = '';
sqlStr = " insert into xxx_table (userid, state, update_time) values (' "
sqlStr += req.userid + " ',' " 
sqlStr += conv.Itoa(1) + " ',' " 
sqlStr += timeStr + " ') " 

• 字段拼接，将uri/post body/cookie/referer/host/自定义header等参数拼接为SQL语句

漏洞防护

1. 使用默认安全组件secmysql或者secorm来执行（还有kenx）
   简单来说：进行SQL操作时，原则上应使用参数化查询的方式或使用可信组件，禁止拼接SQL查询语句（包括自行过滤变量中的特殊字符后再拼接）
2. 使用预编译方式进行安全编码。

• 预编译：将SQL语句和数据部分进行分离，数据部分不会影响原本的SQL语义，所以无法进行SQL注入攻击。（占位符）
• 当变量作为表名/字段名时无法预编译，则应使用白名单方式进行校验

3. 借助参数校验插件完成参数校验

Q11-点击劫持

漏洞原理：

• 攻击者在恶意站点实现了一个和信任站点极其相似的恶意页面，然后在恶意页面的上层覆盖了一个信任站点的合法页面（通常采用iframe的方式），并将合法页面设置成透明态，诱导用户点击页面，这时实际触发的是合法页面上的事件。
  用户的操作被劫持到攻击者事先设计好的恶意按钮或链接上，从而导致用户敏感信息泄露、实施转账、添加权限或者删除记录等敏感操作

漏洞修复：

• 自己页面应当避免被嵌入到其他网页内，或者仅允许嵌入指定网页。

1、检测自己的网页是否为顶层页面,否则跳转

• Window !==top && (top.location.href=window.location.href)

Window !==top && (top.location.href=window.location.href)

2、设置http头部X-Frame-Options选项

1. 设置允许网页嵌套的范围：
2. DENY：浏览器会拒绝当前页面加载任何frame页面；
3. SAMEORIGIN：frame页面的地址只能为同源域名下的页面；
4. ALLOW-FROM origin：允许frame加载的页面地址；

3、添加安全头部（eg：nodejs添加安全头部）

1. var express = require(‘express’);
2. var helmet = require(‘helmet’);
3. var app = express();
4. app.use(helmet());

Q12-命令注入

漏洞简介：

• 命令注入漏洞，是指在代码中调用 system()、exec()、popen() 等系统命令函数时，没有进行有效过滤直接把外部参数带入到函数中，导致攻击者可以在服务器上执行任意系统命令，实现控制服务器的效果。

命令注入漏洞相关函数

PHP

proc_open()
pcntl_exec()
popen()
shell_exec()
exec()
passthru()
system()

Golang

exec.Command()

NodeJS

child_process.spawn()
child_process.exec()
child_process.execFile()

Python

os.system()
os.popen()
subprocess.call()

Java

Runtime.getRuntime().exec()
java.lang.ProcessBuilder().start()
ProcessImpl.start()
javax.script

C#

sysytem()
popen()
exec 函数族

C,C++

sysytem()
popen()
exec函数族

修复方式

1. 避免调用系统命令函数实现业务功能，如 system()、exec()、popen() 等，必须使用系统命令时，应限定或校验命令和参数的内容
2. 过滤或者转义带有特殊含义的字符，如 \n、$、&、;、|、'、"、(、)、（反引号）

Q13-目录穿越

漏洞原理

• 在Linux系统中"…"代表的是向上级目录跳转，如果程序在处理到诸如用…/…/…/…/…/…/…/…/…/…/…/etc/passwd的文件名时没有进行防护，则会跳转出当前工作目录，跳转到到其他目录中；从而返回系统敏感文件给用户。导致泄露源码，泄露敏感文件

漏洞场景

• 攻击者可以通过在 URL 中使用 …/ 或 %2e%2e/ 等字符序列来实现目录穿越攻击。例如，攻击者可以通过访问 http://example.com/…/…/etc/passwd 来获取服务器上的敏感文件 /etc/passwd。

防护场景

1. 下载服务场景：用户输入文件名，可以下载文件。
2. 文件读取场景：用户输入文件名，后台服务读取相应文件内容然后返回显示给用户。
3. 爬取场景：使用curl或者libcurl 时，支持file:// 协议可能下载到系统文件
4. 危险函数场景

• 4.1）PHP 危险函数fread(), readfile(), file_get_content()
• 4.2）python危险函数read(), readline(), readlines()
• 4.3）Node.js危险函数read(), readFile(), readFileSync()
• 4.4）JAVA 危险函数read()，readLine()

防护方案

1. 使用白名单机制限制用户能够访问的目录和文件
2. 在web服务器上配置安全策略，禁止访问敏感目录和文件
3. 使用相对路径而不是绝对路径
4. 在可能有危险的场景调用前，必须要循环过滤参数里的 …

• （陷阱：如果只是过滤一次 …/ 字符，则黑客可以通过 ./…/./ 最终达到./…/的效果）
  过滤需要注意Windows和Linux路径的差异化，如过滤…/情况，但Windows环境下使用…\可实现绕过

Q14-任意文件读取

漏洞简介

• 任意文件读取漏洞是一种文件读取攻击，攻击者通过构造恶意请求，成功读取服务器上未授权的文件内容。
  攻击者可以通过在 URL 中使用 file:// 或 php://input 等协议来实现任意文件读取攻击。攻击者能够访问的文件范围受到服务器文件系统和 Web 应用程序的限制，通常只能访问 Web 应用程序有权限读取的文件。

漏洞危害

• 攻击者可以通过在 URL 中使用 file:// 或 php://input 等协议来实现任意文件读取攻击。例如，攻击者可以通过访问 http://example.com/index.php?page=…/…/…/…/etc/passwd 来获取服务器上的敏感文件 /etc/passwd。

漏洞防护

• 同目录穿越

目录穿越和任意文件读取两者的区别

• 目录穿越：攻击者能够访问的文件范围受到服务器文件系统的限制，通常只能访问与 Web 根目录同级或子目录下的文件。
• 任意文件读取：攻击者能够访问的文件范围受到服务器文件系统和 Web 应用程序的限制，通常只能访问 Web 应用程序有权限读取的文件。
• 目录穿越漏洞和任意文件读取漏洞的本质区别在于攻击者能够访问的文件范围不同。

Q15-XXE漏洞

漏洞原理：

• XXE（XML External Entity）漏洞是一种常见的安全漏洞，它的底层原理是攻击者利用 XML 解析器的功能，通过构造恶意 XML 实体来读取本地文件、执行远程代码等操作。
• XXE 漏洞的攻击方式可以分为两种：内部实体攻击和外部实体攻击。

1. 内部实体攻击是指：攻击者在 XML 实体中引用本地文件，从而读取文件内容。
2. 外部实体攻击是指：攻击者在 XML 实体中引用远程文件，从而执行远程代码。

漏洞场景：

  
]>
&xxe;

• 在上面的 XML 文档中，定义了一个名为 xxe 的实体，它的内容是本地文件 /etc/passwd 的内容。然后，在 XML 文档的 foo 元素中引用了这个实体。当 XML 解析器解析这个 XML 文档时，会读取实体内容并将其替换为实体引用的内容，从而导致读取本地文件 /etc/passwd 的内容。

防护方案：

1. 对用户输入进行严格的过滤和验证，避免用户能够构造恶意 XML 实体。
2. 可以禁用 XML 解析器的实体功能，或者使用安全的 XML 解析器，以避免 XXE 漏洞的攻击。

冷知识：

• 2007 开始，Microsoft 引入了一种新的文件格式，称为 Office Open XML（OOXML），它使用 .xlsx、.docx、.pptx 等扩展名。而OOXML 文件格式是一种基于 XML 的文件格式，它使用一系列 XML 文件和其他文件（如图像和样式表）来描述文档的内容和结构。因此，可以说 Excel、Word、ppt 等文件本质上也是一种 XML 文件，可能引起XXE漏洞攻击。

Q16-短信轰炸

漏洞描述：

• 该漏洞通常是没有对用户手机号码校验准确性，或者对待下发短信的手机号码没有做好限频逻辑导致的。攻击方通过漏洞可以对目标手机大量的，集中的短信轰炸下发。可产生各种危害，比如信息诈骗、骚扰用户等

防护方案：

1. 下发短信时应做好手机号有效性校验（如，某用户只能触发对自己的验证码接收接口，那么调用sendmessage接口是可以通过token携带的用户信息验证，发送的目标手机号是否和他自己的手机号匹配）
2. 发短信接口需要做好限频，如，一个手机号一分钟只能下发X次，一天只能下发XX次。
3. 短信能容不能自定义，需要做模板固定，内容限制。
4. 告知类短信通知可以通过后台关联 userid 发送，而不是直接信赖用户传入的 phone number（如运营后台）