当不使用TLS / SSL时，如何在Django中删除HttpRequest连接？ [英] How can you drop an HttpRequest connection in Django when TLS/SSL is not being used?

问题描述

我正在编写一个需要使用TLS / SSL的Django 1.3视图方法。如果接收到HttpRequest而不使用TLS / SSL，并且不返回任何类型的响应，我想完全删除连接。这是为了安全起见。

I'm writing a Django 1.3 view method which requires TLS/SSL to be used. I want to entirely drop the connection if an HttpRequest is received without using TLS/SSL and NOT return any kind of response. This is for security reasons.

目前我正在回复这样的回复：

Currently I am returning a response like so:

def some_view(request):
    if not request.is_secure():
        return HttpResponse(status=426)
    ...

但是，返回 426 - 需要升级提出了几个问题：

However, returning 426 - Upgrade Required poses a couple of problems:

1. 它是2000年5月提出的标准的一部分（ RFC 2817 ），并不是一个官方的HTTP标准。


2. HttpResponse对一个中间人（MITM）开放，攻击。作为在这里的评论中提到的，如果服务器返回任何类型的响应到客户端没有TLS / SSL连接首先是成立后，MITM可以劫持响应，改变它以重新指向其他地方，并向客户端发送恶意的直接响应。

1. It's part of a proposed standard from May 2000 (RFC 2817), and is not an official HTTP standard.
2. The HttpResponse is open to a man-in-the-middle (MITM) attack. As mentioned in the comments here, if the server returns any type of response to the client without a TLS/SSL connection first being established, a MITM could hijack the response, alter it to re-direct elsewhere, and deliver the malicious re-direct response to the client.

将服务器从HTTP URI重定向到HTTPS URI，如上所述可以使用相同的MITM攻击。

Having the server re-direct from a HTTP URI to a HTTPS URI is open to the same MITM attack as noted above.

那么，你怎么能完全删除连接Django 1.3视图方法，而不返回任何类型的HttpResponse？

So, how can you entirely drop a connection inside a Django 1.3 view method without returning any type of HttpResponse?

推荐答案

正如我在这个答案，我通常反对使用 http：// 的自动重定向 https：// 由于您提到的原因。我肯定不会建议仅使用大量的 mod_rewrite - 重定向来保护网站。

As I was saying in this answer, I'm generally against the use of automatic redirections from http:// to https:// for the reasons you're mentioning. I would certainly not recommend resorting only to bulk mod_rewrite-style redirections for securing a site.

然而，在你的情况下，当请求到达服务器时，已经太晚了。如果有麻省理工学院，他已经完成了攻击（或其中一部分）。

However, in your case, by the time the request reaches the server, it's too late. If there is a MITM, he has done his attack (or part of it) before you got the request.

那么你最好能做的就是回复没有任何有用的内容。在这种情况下，重定向（使用301或302和位置头）可能是适当的。但是，如果用户（甚至您作为开发人员）忽略了警告（在这种情况下，浏览器将遵循重定向并几乎透明地重试该请求），则可能会隐藏问题。

The best you can do by then is to reply without any useful content. In this case, a redirection (using 301 or 302 and the Location header) could be appropriate. However, it may hide problems if the user (or even you as a developer) ignores the warnings (in this case, the browser will follow the redirection and retry the request almost transparently).

因此，我建议返回一个404状态：

Therefore, I would simply suggest returning a 404 status:

• http：// yoursite / / code>和 https：// yoursite / 实际上是两个不同的网站。没有理由期望从一个URI到另一个URI空间的所有资源的1：1映射（就像您可以为完全不同的层次结构> ftp：// yoursite / ）。


• 更重要的是，这是一个应该在上游处理的问题：使用 http ：// 应该被视为破损。不要让它自动工作。拥有不应该在那里的资源的404状态是罚款。另外，当出现错误时返回错误消息是好的：它将强制（或至少提醒您）作为开发人员，您需要修复导致此问题的页面/表单/链接。

• http://yoursite/ and https://yoursite/ are effectively two distinct sites. There is no reason to expect a 1:1 mapping of all resources from the URI spaces from one to the other (just in the same way as you could have a completely different hierarchy for ftp://yoursite/).
• More importantly, this is a problem that should be treated upstream: the link that led your user to this resource using http:// should be considered as broken. Don't make it work automatically. Having a 404 status for a resource that shouldn't be there is fine. In addition, returning an error message when there is an error is good: it will force you (or at least remind you) as a developer that you need to fix the page/form/link that led to this problem.

删除连接只是一个奖励，如果你可以用这个框架来做到这一点：只有当它可以被异步地发送时，它将非常有用服务器（在客户端完成发送请求之前），如果浏览器可以异步读取（在这种情况下，当出现错误时应立即停止发送），并且如果MITM攻击者是被动的（活动的MITM可能会停止响应返回通过客户端，并确保客户端通过自己的代理消费它发送所有请求，无论服务器是否已经删除连接）。这些情况可能会发生，但将问题解决来源仍然更好。

Dropping the connection is just a bonus, if you can do this with this framework: it will only be really useful if it can be sent asynchronously by the server (before the client has finished sending the request), if the browser can read it asynchronously (in which case it should stop sending immediately when there is an error) and if the MITM attacker is passive (an active MITM could stop the response to go back through the client and make sure the client sends all the request by consuming it with its own "proxy", whether or not the server has dropped the connection). These conditions can happen, but fixing the problem at the source is still better anyway.

这篇关于当不使用TLS / SSL时，如何在Django中删除HttpRequest连接？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！