如果我在http://example.com:123通过HTTP提供了HTML页面，而在https://example.com:456/some_app通过HTTPS提供了另一个HTML页面，那么HTTPS应用程序是否存在任何风险？请注意，假设以下缓解措施已到位：
secure 我看到的主要风险是攻击者可以拦截HTTP请求并发回带有恶意Javascript的页面。虽然这是不可取的，但我无法看到攻击可能升级的任何方式。尽管对cookie的访问控制过于宽松，但攻击者不应该窃取HTTPS页面的cookie，因为它们被标记为安全。就交叉原始请求而言，HTTP页面发出的请求被认为来自不同的来源，因此CSRF保护在那里工作。
是否有我失踪的攻击场所？或者HTTPS应用程序是否相当安全？
答案 0 :(得分：1)
Cookie的“安全”属性可防止使用http请求发送 Cookie，因此只能使用https发送这些Cookie。但是，没有什么可以阻止http页面上的javascript 读取，例如，如果它在传输过程中被篡改以包含额外的javascript或者容易受到XSS漏洞的攻击。</ p>
这可以通过设置HttpOnly标志和安全标志来解决，但如果需要JavaScript来读取cookie，这可能对双保护CSRF实现不起作用。
编辑：下面的评论指出Chrome（至少）在设置安全标志时会阻止此操作，但我无法在RFC中看到此明确调用，实际上8.5节指出Cookie并不总是遵循相同的通过document.cookie访问时对方案和路径的限制。它还给出了使用document.cookie在本地访问时忽略路径限制的示例 - 尽管无法明确提及是否可以从非https页面上的javascript读取安全cookie。我会谨慎行事，所以假设除非设置了HttpOnly标志，否则它们不会在http页面上使用javascript。
另一个问题是，没有什么可以阻止Http页面设置 cookie，并覆盖现有的cookie。同样，这可以通过拦截http页面响应并添加Set-Cookie标头，或者在易受XSS攻击的页面上使用javascript来实现。虽然您可能认为覆盖cookie不会导致太多问题，但它可能会将您作为其他人登录，例如，如果没有人意识到他们可能会在此错误登录下输入其他私人数据。
当然，您的https页面也可能容易受到XSS的攻击，但提到的拦截攻击只是一个问题，在不安全的http上（我在该btw中包含配置不当的https）。另外，http页面通常由用户和开发人员小心处理，并且还加载不安全的第三方内容而没有错误。因此可能更容易受到XSS或其他问题的影响。
这并不是说，只有一个端口号差异，您的http网站可能会被拦截并使其看起来像您的https网站作为网络钓鱼网站，希望您的访问者对服务器名称感到满意并且不要注意到错误的端口。
这些只是我能想到的几个问题。
我强烈建议不要在同一服务器名称上允许http和https，建议在任何地方使用https，甚至建议使用HSTS以确保这一点。