跨站点脚本攻击

时间:2020-02-28 11:41:36

标签: jsp xss esapi

我想在jsp页面中修复session.getparameter的漏洞,以避免交叉站点脚本攻击。任何人都可以提出建议执行。我尝试过

Boolean flag=EsapiValidator.checkIfEmailIsValid(request.getParameter("name_id"), 251, true);
if(flag)
{
session.setAttribute("gsaPartnerContactEmail",request.getParameter("name_id"));
}

但声纳qube仍然失败。

1 个答案:

答案 0 :(得分:0)

我认为Sonar Qube希望您对此进行输出编码,而不仅仅是验证。最终,大多数ESAPI验证器仅基于正则表达式,并且在防止XSS方面并非万无一失。 (例如,至少在概念上,您可以使用2种不同类型的用户输入,分别使用 不会出现任何XSS危险的ESAPI验证器分别进行验证,但是如果攻击者可以某种方式将它们组合在一起,但是,使用 proper 输出编码输出,尤其是结合在HTTP响应上设置字符集的输出,实在是坚如磐石。对于使用参数化SQL语句(即Java中的PreparedStatements)的XSS justline而言,输出编码是首选的防御方式。对于SQLi,AppSec的首选防御方法是

问题是您需要在最终使用方式的上下文中进行输出编码。例如,如果它是在HTML上下文中输出的,则可以使用ESAPI的Encoder.encodeForHTML()(或ESAPI标记库中的等效“ encodeForHTML”标记)。如果在JavaScript上下文中使用它,则应使用Encoder.encodeForJavaScript()或其等效的'encodeForJavaScript'JSP标记。但这通常意味着您只是在将输出存储到HttpSession属性中时不希望应用输出编码。为什么不?好,让我们假设您将在HTML上下文中使用它,因此将其保存为:

session.setAttribute("gsaPartnerContactEmail", ESAPI.encoder.encodeForHTML(request.getParameter("name_id")));

那太好了,只要您检索并使用该属性,就可以在HTML上下文中仅使用(好吧,我撒了点谎;它可以用于非事件处理程序HTML属性)同样,只要在插入属性时正确引用属性 values 即可。但是,如果有人决定检索您的'gsaPartnerContactEmail'属性,然后在 JavaScript 上下文中使用它,该怎么办?如果发生这种情况,HTML实体编码将不足以阻止XSS,因为在JavaScript上下文中,需要JavaScript输出编码。当然,您也可以 输出针对JavaScript的编码,但是由于它会被双重编码,因此无法正确呈现。或更可能的是,有人可能希望在“ mailto:” URL中使用您的“ gsaPartnerContactEmail”属性,在这种情况下,应使用Encoder.encodeForURL()。但我的意思是,除非在极少数情况下,否则您通常不知道特定的输入值将在输出中呈现的方式和位置,尤其是当更多的开发人员在您的应用程序中动手时。

当您应用输出编码来防止XSS漏洞时,通常的经验法则是将输出编码 previous before 应用于最终将呈现污染值的位置。这样做的原因是,如果您较早地进行操作,它可能会在不同的上下文中使用,那么您仍然会面临XSS漏洞的威胁。

最后,最后,使用ESAPI的Validator对用户输入进行早期验证仍然是一个好主意,类似于您正在做的事情。 (验证和输出编码不是排他性的,而是互补的。)与其在输入值有错误(即输入被视为“无效”)的情况下进行静默处理,不如直接将错误消息传回给用户尽早告知他们他们需要重新输入自己的价值,因为这不是合法的输入。这是一个好习惯,因为大多数情况下,ESAPI的Validator识别错误输入的情况通常是错别字,而不是带有恶意意图的东西,并且毫无意义地激怒所有远远超过恶意用户的友好用户。

希望这会有所帮助。 -凯文