通过另一台服务器绕过 SSO 系统时的良好做法和陷阱？答案

【问题标题】：Good practices and pitfalls when bypassing a SSO system through another server?通过另一台服务器绕过 SSO 系统时的良好做法和陷阱？
【发布时间】：2012-09-17 04:29:39
【问题描述】：

我负责通过两个我无法触及的 Apache HTTPD 服务器维护一个具有两个不同访问点的 Web 应用程序（位于 Tomcat 服务器上）。

这两个接入点旨在通过第三方 SSO 系统或提示输入登录名和密码的良好身份验证页面登录用户。

诀窍在于，此 SSO 对可以上传或下载的文件大小进行了限制。由于 SSO 用户需要检索和发送比这更重的内容，因此我需要一个解决方法，很可能只是提供一个链接，通过其他服务器指向正确的资源位置。

这里我担心的是安全性，以防有人输入一个巧妙猜测的地址来获取他不应该得到的文件。负责人不想听到 SessionManager 以确保用户有权检索文档，但建议我可以简单地使用他们的 JSESSSION_ID 来确认他们的身份...

我不确定如何实现这一点，并且有一种严重的直觉认为这会以一种非常可怕的方式适得其反。

任何必须处理类似问题的人能否指出一些陷阱，并可能分享一些关于如何安全绕过此 SSO 的有用提示？

【问题讨论】：

标签： java security tomcat single-sign-on jsessionid

【解决方案1】：

实现此目的的一种可能方法是使用有效期很短的一次性密码来保护非受限站点上的资源。示例：

用户单击链接以打开受 SSO 保护的站点上的文档。该链接不应直接提供文档。
Tomcat 服务器生成一次性密码并使用此密码作为 http 参数将用户重定向（使用 http 代码 303）到不受限制的站点。
3。当浏览器连接到不受限制的站点时，请检查密码是否正确并提供文档。删除密码，使其无法再次使用。密码应该只在 30 秒内有效。您还可以记录用户的 IP 地址并进行验证。

您不应该为此使用 jsession id。在地址栏或 html 页面的参数中公开 jsession id 不是一个好习惯。

但是，您说另一个接入点受用户名和密码保护。如果是这样，用户是否无论如何都必须在这里登录？如果是这样，登录不是保护资源吗？

【讨论】：

感谢您的输入 - 临时密码是个好主意。关于另一个（旧版）入口点，我不确定是否需要登录。安全性似乎是预先管理的，就像访问 Apache 服务器一样。

【解决方案2】：

如果您提供指向正确资源的链接，我们需要考虑安全性。

https://www.owasp.org/index.php/Top_10_2010-A2

最重要的是XSS和CSRF，上面的网站提供了解决方案。

如果我们提供可以直接访问资源的直接链接，会话劫持可能是另一个安全威胁。

【讨论】：