Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »



Defects Lifecycle

Review Status of Defects

After an analysis, you will need to spend some time to review the defects found by Kiuwan. You need to fully understand them before to submit its correction to developers.

During the review process, some of them will be reviewed very fast, but others may take a while.

Reasons to review defects can be various, e.g. to confirm if it's a true or false positive.



During the review process, Kiuwan can help you allowing you to set a Review Status for any defect:

  • To review, i.e. someone needs to review the defect in detail 
  • Reviewed, someone has completed the review process of that defect

Also, you can add Notes to the review process.


After reviewed, you can:


How to set the Review Status of a Defect 


First, select the concrete defect, open the menu at the right and select Status option.


Clicking on Status option, the Defect Status window appears.

JSP technology provides the <jsp:include> action (or JSTL <c:import>) for including content in the current page, either from a local (web application) resource or from an URL, respectively.

When the page path or URL is formed using untrusted input, an attacker may provide the input in the HTTP request to force the J2EE application server to include an unintended resource, which opens the way to either sensitive local file disclosure (like a /WEB-INF configuration file), or catastrophic remote file injection (e.g. remote attacker-controlled content with embedded malicious JavaScript code for CSRF attacks, or Java code in scriptlet to execute unexpected server-side operations, including operating system commands).


Kiuwan provides the rule OPT.JSP.SEC_JSP.FileInclusionVulnerability that avoids unintended leakage of sensitive local/remote files, or remote file include attacks, in JSP dynamic include actions.

Use the "compile-time" <%@ include %> directive, if the included page is local and non dynamic.

If included page should be dynamic, never let untrusted input to directly form part of the page path (for <jsp:include>) or page URL (for <c:import>). Better use a request attribute, set in the request processing server-side controller class, where the dynamic page is selected (but untrusted input should not be part of the page path/url anyway).

A "white-list" validation scheme (untrusted input may be used only to select from a known list of allowed pages) could be used as well.

  • No labels