Then SCA said: "I have to report both possible entry points, the getParameter in the Filter and the getParameter directly in the request". Each one of these points is a possible fix point but the filter finally is optional in the WebApp implementation. The use of "http(Servlet)Request.getParamenter" will call this method in chain, first in the Request Object and then on the filter. The filter implements for example the "GetParameter" function, through which JRE will retrieve data from he User. An Http filter acts a Extra Layer between HttpRequests/servletRequests (User controlled Inputs) and application it self. Other reason to have "duplicate issues" is the use of HttpFilters, for example in Java Applications. It is because you can fix in source or sink with the same result. In this case it will be reported as only one Issue with different paths. There is a variation form this picture, when data source and sink are the same, but data may follow a few different paths between those points. If you fix near the source (entry point) the solution will apply only to one path, leaving the other issues alive. etc.) each one have to be reported, no matter if there is only a single explotation point (sink), because you have the choise to fix the issue in the source or at the sink. httpRequest, ConfigFile, Database, different user entry points. One of it, is the reason raised by, there are in the app some function that is called from more than one location using data from different sources (eg. I've using Fortify SCA some years ago, and so far, I have knowledge of two reasons to SCA report issues that seems to be duplicated.
0 kommentar(er)
