我正在编写一个需要使用 TLS/SSL 的 Django 1.3 View 方法。如果在不使用 TLS/SSL 的情况下收到 HttpRequest 并且不返回任何类型的响应,我想完全断开连接。这是出于安全原因。
目前我正在返回这样的响应:
def some_view(request):
if not request.is_secure():
return HttpResponse(status=426)
...
但是,返回 426 - Upgrade Required
会带来一些问题:
- 它是 2000 年 5 月提出的标准 (RFC 2817) 的一部分,不是官方 HTTP 标准。
- HttpResponse 容易受到中间人 (MITM) 攻击。作为mentioned in the comments here ,如果服务器在没有首先建立 TLS/SSL 连接的情况下向客户端返回任何类型的响应,则 MITM 可以劫持响应,将其更改为重定向到其他地方,并将恶意重定向响应传递给客户端。
将服务器从 HTTP URI 重定向到 HTTPS URI 会受到与上述相同的 MITM 攻击。
那么,如何在不返回任何类型的 HttpResponse 的情况下完全删除 Django 1.3 View 方法中的连接?
最佳答案
正如我在 this answer 中所说的那样,出于您提到的原因,我通常反对使用从 http://
到 https://
的自动重定向。我当然不建议仅使用批量 mod_rewrite
样式的重定向来保护站点。
但是,在您的情况下,当请求到达服务器时,为时已晚。如果存在 MITM,则他在您收到请求之前已经完成了攻击(或部分攻击)。
到那时你能做的最好的事情就是在没有任何有用内容的情况下回复。在这种情况下,重定向(使用 301 或 302 和 Location
header )可能是合适的。但是,如果用户(甚至您作为开发人员)忽略警告(在这种情况下,浏览器将遵循重定向并几乎透明地重试请求),它可能会隐藏问题。
因此,我只建议返回 404 状态:
http://yoursite/
和https://yoursite/
实际上是两个不同的站点。没有理由期望所有资源从一个 URI 空间到另一个的 1:1 映射(就像您可以为ftp://yoursite/
使用完全不同的层次结构一样) >).- 更重要的是,这是一个应该在上游处理的问题:使用
http://
引导您的用户访问此资源的链接应该被视为已损坏。不要让它自动工作。对于不应该存在的资源具有 404 状态很好。此外,在出现错误时返回一条错误消息是好的:它会迫使您(或至少提醒您)作为开发人员需要修复导致此问题的页面/表单/链接。
断开连接只是一个好处,如果你可以用这个框架做到这一点:只有当它可以被服务器异步发送(在客户端完成发送请求之前)时,它才会真正有用,如果浏览器可以异步读取它(在这种情况下,它应该在出现错误时立即停止发送)并且如果 MITM 攻击者是被动的(主动 MITM 可以停止响应以通过客户端返回并确保客户端通过消费发送所有请求它有自己的“代理”,无论服务器是否已断开连接)。这些情况可能会发生,但无论如何还是从源头上解决问题更好。
关于django - 当不使用 TLS/SSL 时,如何在 Django 中删除 HttpRequest 连接?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8963692/