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