服务端常见漏洞 | 青训营

1eek
104 阅读6分钟

服务端漏洞

这是我在字节跳动青训营学习的第32天，也是我参加《第六届青训营笔记伴读》的第六篇笔记

1. 第三方组件漏洞

平时使用第三方组件的时候，第三方组件可能存在某些漏洞， 对于java可以使用dependency-check-maven检查项目以来的组件是否存在安全漏洞

2. SQL注入

SQL语句静态模板和动态数据部分没有严格区分，如果在数据项中加入了某些SQL语句关键字（比如说select，drop等），这些SQL语句就很可以在数据库写入或读取数据时得到执行

例如，假设一个应用程序接收用户输入的用户名和密码，然后通过以下 SQL 查询语句验证用户是否存在：

SELECT * FROM users WHERE username = '$username' AND password = '$password'

如果应用程序没有对用户输入进行过滤和验证，那么攻击者可以通过构造恶意输入，将SQL代码注入到查询语句中，例如：

username = 'admin' OR 1=1 --'

查询语句会变为：

SELECT * FROM users WHERE username = 'admin' OR 1=1 --' AND password = '$password'

这个查询语句中的 OR 1=1 将始终返回 True，因此该查询将返回所有用户的信息，而不仅仅是管理员账户信息。攻击者可以利用这种方式来绕过身份验证、获取敏感信息或者进行其他恶意操作。

防护方式

  1. 尽量不要基于DB的Raw方法拼接构造SQL语句，而应该使用预编译、ORM框架
  2. 使用ORM框架时，应该注意框架中的特性，可能存在不安全的写法导致的SQL注入问题
  3. 如果在复杂场景一定要使用拼接SQL，需要对外部输入进行转义

3. 命令执行

代码中遇到需要某个命令才能完成的功能时候，会涉及到命令拼接，如果命令拼接没有做好安全过滤，那么将会导致命令注入风险，服务器权限将会被控制

防护方式

  1. 对动态的值尽可能设置白名单进行验证
  2. 如果某些位置无法白名单，需要尝试对数据类型进行校验
  3. 特殊字符黑名单的过滤，或者转义。

3. 越权漏洞

  • 认证：你是谁
  • 授权：你能做什么
  • 越权：资源访问或操作时候主题权限没有进行校验就会造成越权问题，细分为：未授权、水平越权和垂直越权

水平越权

假设一个在线论坛应用程序，每个用户都有一个唯一的用户ID，并且用户可以通过URL访问他们自己的帖子。应用程序的某个页面的URL结构如下：

https://example.com/forum/posts?userId=<用户ID>

应用程序使用userId参数来标识要显示的用户的帖子。假设Alice的用户ID为1，Bob的用户ID为2。

Alice可以通过以下URL访问她自己的帖子：

https://example.com/forum/posts?userId=1

现在，如果Bob意识到URL参数是可变的，他可能尝试修改URL参数来访问Alice的帖子。他将尝试将URL参数修改为Alice的用户ID（1）：

https://example.com/forum/posts?userId=1

如果应用程序没有正确实施访问控制机制，没有验证用户的身份和权限，那么Bob将成功地通过URL参数访问到Alice的帖子。

防护方式

涉及资源id尽量不要使用短id（遍历难度小），同时最重要的一定要最好资源

垂直越权

假设一个电子商务网站，有两种用户角色：普通用户和管理员。普通用户有限的权限，只能查看和购买商品，而管理员则拥有更高的权限，可以添加、编辑和删除商品。

在正常情况下，只有管理员可以访问和执行与商品管理相关的操作。然而，如果应用程序没有正确实施访问控制和权限验证，那么普通用户可能尝试利用垂直越权漏洞提升为管理员角色，并执行未经授权的操作。

例如，普通用户Alice可能意识到应用程序的URL结构如下：

https://example.com/admin/manage-products

她可能尝试手动修改URL，将自己的用户角色从普通用户更改为管理员，如下所示：

https://example.com/admin/manage-products?role=admin

如果应用程序没有进行足够的验证和授权检查，就会错误地将Alice的角色更改为管理员，从而使她能够访问和执行与商品管理相关的操作。

防护方式

  • 如果是简单的场景，可以将接口在路由级别进行分组，对不同的api分组引入middleware进行权限拦截，middleware获取当前用户角色以确定是否可以访问此接口
  • 最小权限原则：在分配用户权限时，采用最小权限原则，即给予用户所需的最低权限级别，以限制潜在的越权行为。用户只应具备完成其任务所需的最小权限。
  • 验证用户输入：应该对所有用户输入进行严格的验证和过滤，以防止攻击者通过构造恶意输入来利用越权漏洞。特别是对于涉及访问控制的操作，必须仔细验证用户请求的合法性。

4. SSRF

SSRF又称服务端请求伪造攻击，指攻击者利用后端服务器为跳板，让后端服务向非预期网络地址（主要指内网地址）发出恶意请求，获取敏感信息或执行恶意操作

修复方案

  • 限制请求的端口只能为Web端口，只允许访问HTTP和HTTPS的请求
  • 限制不能访问内网的IP，以防止对内网进行攻击
  • 屏蔽返回的详细信息

5. 文件上传漏洞

攻击者可以上传一个与网站脚本语言相对应的恶意代码动态脚本到服务器上,然后访问这些恶意脚本中包含的恶意代码,从而获得了执行服务器端命令的能力,进一步影响服务器安全。

防护方案

  • 对用户传入的文件名在使用的时候尽量进行白名单过滤，可以的话尽量不要使用用户传入文件名，杜绝从文件名上导致的安全漏洞。

  • 对文件内容本身做好格式验证，黑名单或者白名单的方式都可以，不过白名单的方式安全性会更高一点。文件格式不能简单的判断文件后缀或者是表单上传时带有的 Content-Type 字段，因为这两个是用户上传内容，都是可被构造的。最好是通过文件头的魔术数字来读取，配合白名单列表就能避免这方面的问题。比较著名的使用魔术数字来判断文件类型的模块是 github.com/sindresorhu…，推荐直接使用。

  • 如果允许用户上传 .svg 格式图片的话，需要针对 SVG 内容进行 HTML 解析，过滤掉 <script>, <foreignObject> 等相关标签。当然，使用白名单的话是最好不过的了。这里提供一个比较全的 SVG 合法标签白名单列表。

参考

avatar
文章
阅读
粉丝