i want to fix a vulnerability in the jsp page for session.getparameter to avoid Cross-Site-Scripting attack.can anyone please suggest how to perform . i have tried like
Boolean flag=EsapiValidator.checkIfEmailIsValid(request.getParameter("name_id"), 251, true);
if(flag)
{
session.setAttribute("gsaPartnerContactEmail",request.getParameter("name_id"));
}
but still sonar qube is failing .
I think Sonar Qube is expecting you do output encoding on this rather than just validation. Ultimately, most of the ESAPI validators are just regular expression based and are not foolproof in preventing XSS. (E.g., at least conceptually, you could have 2 different types of user inputs that you each separately validate using an ESAPI validator that individually would not present any XSS dangers, but if an attacker could somehow combine them to be used together, an XSS attack might still be possible.) However, using the proper output encoding output, especially in combination of setting charset on your HTTP response, is rock solid. Output encoding is the preferred defense against XSS just line using parameterized SQL statements (i.e., in Java, PreparedStatements) is the preferred AppSec defense against SQLi.
The problem is that you need to do output encoding in the context of how it ultimately is being used. For example, if it were output in an HTML context, you would use ESAPI's Encoder.encodeForHTML() (or its equivalent 'encodeForHTML' tag from the ESAPI tag library). If you were using it in a JavaScript context, you would use Encoder.encodeForJavaScript(), or its equivalent 'encodeForJavaScript' JSP tag. But this usually means that you do NOT want to apply output encoding at the time you are simply stashing it into an HttpSession attribute. Why not? Well, let's suppose that you assume it will be used in an HTML context so you save it something like:
session.setAttribute("gsaPartnerContactEmail", ESAPI.encoder.encodeForHTML(request.getParameter("name_id")));
That's great, as long as when you retrieve and use the attribute, it is ONLY used in an HTML context (okay, I lied a bit; it would work for non-event handler HTML attributes as well, as long as you properly quote the attribute values when inserting them). But what if someone decided to retrieve your 'gsaPartnerContactEmail' attribute and then use it in a JavaScript context? If that were to happen, the HTML entity encoding would not be sufficient to prevent XSS since in a JavaScript context, JavaScript output encoding is needed. Of course, you could also output encode it for JavaScript, but then it would not be rendered correctly because it would be double-encoded. Or perhaps more likely, someone might wish to use your 'gsaPartnerContactEmail' attribute in a 'mailto:' URL, in which case Encoder.encodeForURL() should be used. But my point is, except in very rare cases, you generally don't know how and where a particular input value will be rendered on output and that is especially true the more developers who have their hands in your application.
When you are applying output encoding to prevent XSS vulnerabilities, the general rule-of-thumb is to apply the output encoding just prior to where / when the tainted value is ultimately going to be rendered. The reason for that is, if you do it earlier, it could get used in a different context and then you still have left yourself open to an XSS vulnerability.
BTW, lastly, it still is a good idea to do early validation on user input using ESAPI's Validator similar to what you are doing. (Validation and output encoding are not exclusive, but rather complementary.) Rather than silently proceeding if there is an error in the input value (i.e., the input is deemed "invalid"), is is better instead direct an error message back to the users letting them know as early as possible that they need to re-enter their value because it was not legal input. That is good practice, because most cases of where ESAPI's Validator identifies bad input will generally be typos rather than something with malicious intent and there is no point in upsetting all those friendly users who vastly outnumber the malicious ones.
Hope this helps. --kevin
