2

我是 WebApp 编程的新手,我试图了解不验证通过调用javax.servlet.http.HttpSession.getAttribute()接口方法获得的数据的安全隐患。我正在使用已标记此潜在漏洞的安全代码扫描程序。

我知道作为一般规则,我应该始终验证从不受信任的来源获得的数据,但我想我不明白为什么会话的内容会不受信任。这是基于我的(可能是没有根据的)假设,即可以将数据添加到会话的唯一方法是通过调用HttpSession.setAttribute(),并且只有同一应用程序范围内的受信任代码才能做到这一点。

我想我真正要问的是攻击者如何利用无法验证从 HttpSession 获取的数据的应用程序。是因为实现是未知的,并且不能保证会话的内容不是从 HTTP 请求中的数据(除了会话 ID)以某种方式构造的,因此会受到篡改吗?还是因为信任会话的内容意味着隐含地信任会话 ID,这可能会受到损害并指向错误的会话?(尽管要发生这种情况,攻击者似乎必须有某种方法来创建包含受损数据的备用会话)。

假设会话的内容不是根据请求中的数据构建的,那么是否存在可以利用此漏洞的唯一方法是如果存在另一个允许攻击者创建错误会话的漏洞?例如上传可执行代码并让服务器执行它并返回一个被捕获和重放的会话ID?

谢谢

4

3 回答 3

0

只要您不将任何您不信任的内容放入 HttpSession 中,您就不需要验证 HttpSession 中的数据。HttpSession 是为您的 web 应用程序创建的,当您要求它时,它应该只包含您在您的 servlet 或 JSP 之一中添加到它的东西 - 尽管如果您使用一些额外的框架可能是间接的。

我个人会确保我永远不会在 HttpSession 中放入任何稍后我将其取出时必须再次验证的内容。在一个简单的 servlet 容器环境中,它只会是您自己的代码来更新会话(除非容器自动删除它,如果它超时)。

除非您使用的框架会自动将内容添加到 HttpSession 中,并且这些内容可能直接来自用户而没有经过清理,否则您应该没问题。如果您自己的代码当前正在将您不信任的内容放入 HttpSession 中,我会将其更改为不这样做。

请注意,JSP 在这方面没有任何区别;JSP在编译后就是servlet。如果您信任您的 servlet 放入 HttpSession 中的内容,那么您应该也能够信任您的 JSP 对它所做的事情。(毕竟,它们是您的JSP。)

重新“是因为实现是未知的,并且不能保证会话的内容不是从 HTTP 请求中的数据(除了会话 ID)以某种方式构造的,因此会被篡改吗?”。servlet 规范中没有任何内容可以强制或允许这种情况发生。所以不,这不是原因。

重新“或者是因为信任会话的内容意味着隐式信任会话 ID,这可能会受到损害并指向错误的会话?” 我不确定“错误的会话”。但是,一旦某人(除了预期用户)拥有会话 ID(JSESSIONID),他们本质就是预期用户,并且可以做任何用户可以做的事情(在相关 webapp 的能力范围内)。无论被破坏的数据是来自会话、数据库还是其他什么,都是如此。

一个常见的 servlet/MVC/JSP 方法是让用户登录(通过任何方式),然后为用户创建一个包含该用户的最小表示的 HttpSession(例如,一个包含用户 ID、名称等的 UserLogin POJO, ETC)。从那时起,webapp 相信此信息是有效的并使用它来识别用户 - 例如,带有 JSESSIONID 的 HTTP 请求到达,它映射到 HttpSession,后者映射到会话中的某些数据(UserLogin POJO),然后识别请求用户在从 webapp 内部调用底层系统时(例如进行数据库调用)。没有 HttpSession 和 UserLogin 会话数据则表明用户没有登录。这在 webapps 中很常见,并且取决于能够信任 JSESSIONID 和它映射到的 HttpSession。

顺便说一句(因为上面有人提到了 JSP)我不会编写一个 JSP 接触会话的 web 应用程序——我会限制 JSP 呈现由基于 MVC 的 servlet 提供给它们的数据。

(如果可以选择的话,我也根本不会使用 JSP:JSP 相当笨重,语法难看,还有许多其他限制 - 尝试使用 JSP 来模板电子邮件,而不是 HTML 页面,例如, 没有跳过一堆箍。考虑使用 Velocity 或类似的。)

于 2013-07-31T12:54:29.473 回答
0

数据也可以从表单添加到会话中。请求可能来自另一个 servlet/应用程序,不一定来自表单。某人很容易在表单/servlet 中为 SQL 注入设置 SQL 语句并将其转发给 servlet。这只是我能想到的一种可能性。话虽如此,我不记得验证会话属性......永远!

于 2012-11-16T19:07:23.807 回答
0

我认为它的全部意思是用户可能输入数据,您无法确定用户输入的内容或是否有任何类型的客户端验证。如果您根据在请求中收到的内容盲目地调用函数,那么您可能会遇到安全问题。例如,在检索用户输入的客户 ID 的客户信息之前,请确保 ID 有效并确保用户有权查看数据。

于 2012-11-16T19:00:37.460 回答