http - 在服务器代码中处理强制性 SSL

Question

我想在我的应用程序中强制 HTTP 客户端切换到 HTTPS。键入 www.mysite.com 的用户将默认使用 HTTP，但他们需要重定向到 HTTPS。使用旧书签的用户将被重定向到书签页面的 HTTPS 版本。

HSTS (RFC 6797) 重定向后有很大帮助。我的问题实际上是关于 HTTP 方法的。

GET 和 HEAD 肯定应该接受 301/302 重定向，但是 POST/PUT 和 DELETE?

请看下面的例子:

    void context_BeginRequest(object sender, EventArgs e)
    {
        HttpApplication application = (HttpApplication)sender;
        HttpContext context = application.Context;

        if (context.Request.IsSecureConnection) return;

        if (context.Request.HttpMethod == "GET" || context.Request.HttpMethod == "HEAD")
        {
            string redirectUri = context.Request.Url.ToString().Replace("http://", "https://");
            context.Response.RedirectPermanent(redirectUri, true);
        }
        else
        {
            throw new HttpException(403, "SSL Required");
        }
    }

GET 和 HEAD 都是通过重定向处理的。据我所知，目前 POST 接受 301 重定向作为要完成的 GET 请求，即不重新发布到 HTTPS 版本。所以这就是为什么在我的代码片段中我以 403 代码结尾。

题目要从HTTP协议(protocol)的角度来解读

除了检查应用程序中的所有表单是否都指向 HTTPS 之外，聪明的 HTTP 开发人员应该如何在浏览器将其请求定向到普通的旧 HTTP 版本时强制客户端将 POST 请求重定向到页面的 HTTPS 版本？

可能的解决方案

创建一个包含所有表单字段的登录页面，该页面会自动(通过 Javascript 和“如果您没有被重定向，请单击我”按钮)将表单重新发布到目标页面的 HTTPS 版本。

还有其他想法吗？

Answer 1

重定向时 POST 的行为取决于服务器返回的状态码。此外，许多浏览器都实现了 Post/Redirect/Get pattern ，这可能不完全符合 HTTP 规范。

话虽这么说:

• 通常避免依赖重定向。 (请参阅 this answer。)在生产环境中使用重定向不一定是坏事，但这是为那些会直接在地址栏中键入地址的用户准备的。它依赖于无论如何进行重定向时都没有 MITM 的假设。我认为开发阶段的重定向是不好的，因为它们隐藏了潜在的问题。

• 永远不要依赖 POST 上的重定向(甚至是 URL 中包含敏感信息的 GET):初始请求(在重定向到 HTTPS 之前)将以明文方式发送，这违背了尝试的目的使用 HTTPS。

如果您希望使用 HTTPS，请确保您提供的链接和表单的目标 URL 使用 https://。如果可以，还要确保您的用户希望使用 HTTPS。只有用户可以检查。

正如 Eugene 在评论中所说的那样，在登录页面上也可以通过 HTTPS 提供表单也是一种很好的做法。

因为您似乎主要关心使用旧书签访问此页面的用户，POST 和 DELETE 无关紧要:他们无论如何都会使用来自书签的 GET。如果可以，告诉他们更新书签。也可以使用 HSTS 或 301(永久重定向)，浏览器应该记住这些，以便下次使用该地址时它会直接转到 https://，除非它的缓存被清除。