Django Rest框架应用程序安全准备生产(8月和管理小组)

Question

简介

我构建了一个具有多个服务的web应用程序：

(react)

• backend (API和面板)( Rest框架+简单jwt auth)
  • Redis、DB、Nginx和
  • Kubernetes集群

这个应用程序不像60k+代码行那么小。这是一家初创公司。我提到这是为了让你知道，我可能不会受到黑客或流量的太多关注。因此，我有一个逐步改进的空间。

auth是用DRF简单的jwt库完成的。到期访问+刷新令牌。

问题陈述

我做了一次安全审计，并从安全体系结构的角度发现了不足之处。我不知道这些问题是如何至关重要的，我应该如何解决它们，或者什么问题可以稍后解决。所以我在寻求解决方案和建议。我更喜欢速度和质量之间的最佳比例，而不仅仅是质量(如果我错过了这一点，请告诉我)。因此，如果有什么东西是“好的”，而不是“重要的”，我会把它放到下一个版本的积压中。

实际问题清单

如果你想的话，让我们用它的编号来表示。

#1身份验证方法

我目前的设置：

REST_FRAMEWORK = {
    'DEFAULT_PERMISSION_CLASSES': (
        'rest_framework.permissions.IsAuthenticated',
    ),
    'DEFAULT_AUTHENTICATION_CLASSES': (
        'rest_framework.authentication.SessionAuthentication',
        'rest_framework.authentication.BasicAuthentication',
        'rest_framework_simplejwt.authentication.JWTAuthentication',
    ),
    .....

}

如你所见，我有三种方法。JWT是可以的，但是BasicAuthentication和SessionAuthentication似乎不太好。我想要实现的是拥有真正的JWT，并将其作为API视图的惟一方式(我确实相信我已经拥有了它，直到我发现相反的情况)。

正如我所理解的(可能是错误的)，在生产设置中我不需要SessionAuthentication和BasicAuthentication，但是我需要开发，因为它允许我使用登录表单登录到DRF，这对于测试来说很酷。我说得对吗？

#2会议

当我来到Chrome工具并检查饼干时，我感到很沮丧。此时，我反对SessionAuthentication和BasicAuthentication进行测试。

​

​

据我所知，由于SessionMiddleware，我有会话id cookie。拥有它是可以的，因为它只用于管理面板身份验证，而被DRF视图忽略，所以惟一的方法是JWT，但它是吗？也许它可以有更多的影响力和功绩。因此，我是否应该完全放弃SessionMiddleware，特别是为了实现将JWT作为惟一auth类型的目标？

*我知道这将放弃使用管理小组功能的能力，我将在稍后讨论这一点。

#3我在本地存储器中存储Access和Refresh令牌

对，看来我错了。我承认。一开始就是缺乏经验。前端应用程序和测试(我使用Cypress)在很大程度上依赖于本地存储中的令牌，但是迁移是可行的。另一方面，我只是害怕随后可能出现的新bug。此外，我怀疑移民可能会有点痛苦。问题是，这一点有多重要，因此，我应该现在将令牌存储迁移到cookie，还是以后再做呢？

#4.1管理小组与API分离

Django管理面板是令人敬畏的，我们都知道，但它是紧密耦合到应用程序。但。问题2使我想到了将API和Admin分开的想法。因此，由于我使用Kubernetes，所以我们的想法是运行这两个服务。一个是API，我认为它是相同的代码库，但设置是不同的(禁用SessionMiddlware和管理面板)。和另一个服务，其中的管理面板功能是完全启用。说得通吗？

*我觉得这闻起来有点过火了。所以，如果我错了，请停止。

**似乎在很大程度上依赖于#2，因为如果没有SessionMiddleware的问题和利用，那么就没有充分的理由这样做。

#4.2管理面板生产装置

我只是想知道在prod中设置Admin的最佳安全实践是什么。我绝对是赤裸裸的。没有卡普查。没有VPN。全香草的。问题是，什么是最可行但最有效的访问设置？我觉得它应该以某种方式得到保护。至少/admin不是公共端点(VPN?)但我不知道如何做到这一点。我在谷歌云平台上，所以也许我可以使用它的解决方案之一？

欧特罗

在作为工程师进入生产之前，您还会做什么安全检查？我是说，最好的办法就是雇佣保安队，但我不能这么做。

我所做的：

architecture)

• did
• 确保没有数据泄漏的可能性(测试和propper后端和前端应用程序
• 得到广泛接受，在auth
• 上的e2e测试通过序列化程序运行，并确保没有漏洞(至少是可见的)(当然，有很多单元和e2e测试)

。

谢谢你，阿特姆

Answer 1

#1是的，移除其他两个auth方法，只保留jwt，这只适用于REST框架，因此不应该成为/admin的问题。

第二条第一点已经解决了这个问题。但是请记住，您也可以从django更改cookie路径。因此，您可以设置django应用程序中的/admin使用其他cookie。这将允许您完成/admin与应用程序的其他urls分离。你会发现这很有趣：

SESSION_COOKIE_PATH = '/admin'
CSRF_COOKIE_PATH = '/admin'
LANGUAGE_COOKIE_PATH = '/admin'
SESSION_COOKIE_NAME = 'backend-sessionid'
CSRF_COOKIE_NAME = 'backend-csrftoken'

据我所知..。这是我们可以在前端应用程序上保存令牌的唯一方法。因此，那里的安全部分是通过拥有令牌的“过期时间”来完成的，如果有人从客户端获得令牌，他将只能访问很短的时间。这在很大程度上取决于业务的逻辑以及您希望如何管理这段时间。

#4.1我不建议在两种情况下运行您的应用程序，您应该能够正确地设置应用程序并避免使用这种解决方案。

#4.2正如您所提到的，/admin应该有一个受限的访问权限。我是通过白名单IP(可以在nginx上完成)来做到这一点的，但是您必须事先知道IP。您也可以通过nginx的http auth来实现这一点，这样您就可以在连接到django应用程序之前就有一个用户和密码(您可以共享这个用户和密码而不必知道IP)。

建议：

• 对你的应用程序进行扫描，比如：https://observatory.mozilla.org/ --这会让你知道你在应用程序中需要的很多其他安全信息。有了这个，你应该准备好安全了。而且，有时您无法避免某些测试失败，只需尝试更好地缓解这些问题。