This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sanitizing an object to satisfy Cross-site Scripting Content sniffing

I have Fortify ssc scanning my java spring boot project. I have a simple controller that returns an object from the database. 

  public Item getMyItems(@RequestBody int itemids, HttpServletRequest request)
    return itemService.getMyItems(itemids, request);
and Item is a class with 3 strings and an int as attributes. All 3 strings are being sanitized (html encoded) by an apache library. I've tried other libraries as well and fortify still 
considers this a vulnerability. Is this normal, or am I doing something wrong? 
Further information: 
The example above appears as a Medium criticality vulnerability. I had the same vulnerability appear on the Critical category except they were simple Strings being returned to the 
user. Once I sanitized those strings with the apache library, fortify would mark those vulnerabilities as resolved. So clearly this is the solution to XSS content sniffing, but for some reason
fortify does not recognize when an object is sanitized. Am I correct to assume this?  
  • Suggested Answer

    If it were me I would use "Diagram" in the Auditworkbench.

    Follow the taint flow (if any) leading to the sink. The thing is IF the return if from a DB then Fortify will likely give is DATABASE and possible XSS if the return value flows into another sink. So if you are sure your DB access can never return some XSS type string (and realistically you cannot be?) then you could add a new custom rule where return value of getMyItems is considered VALIDATED_XSS and whatever other validity you need. Again, use AuditWorkbench to create the rule.

    Better to make a brief repro - test your sanitizer, then apply to the wider project. That way you also have either something you can ask here, or provide to MicroFocus for their support teams to look at.