CSRF Guard Configuration (com.soa.console.csrf)
CSRF Guard configuration From: https://github.com/esheri3/OWASP-CSRFGuard/blob/master/csrfguard-test/src/main/webapp/WEB-INF/csrfguard.properties
The logger property (org.owasp.csrfguard.Logger) defines the qualified class name of the object responsible for processing all log messages produced by CSRFGuard. The default CSRFGuard logger is org.owasp.csrfguard.log.ConsoleLogger. This class logs all messages to System.out which JavaEE application servers redirect to a vendor specific log file. Developers can customize the logging behavior of CSRFGuard by implementing the org.owasp.csrfguard.log.ILogger interface and setting the logger property to the new logger's qualified class name. The following configuration snippet instructs OWASP CSRFGuard to capture all log messages to the console: org.owasp.csrfguard.Logger=org.owasp.csrfguard.log.ConsoleLogger org.owasp.csrfguard.Logger=org.owasp.csrfguard.log.JavaLogger
Which configuration provider factory you want to use. The default is org.owasp.csrfguard.config.PropertiesConfigurationProviderFactory Another configuration provider has more features including config overlays: org.owasp.csrfguard.config.overlay.ConfigurationOverlayProviderFactory The default configuration provider is: org.owasp.csrfguard.config.overlay.ConfigurationAutodetectProviderFactory which will look for an overlay file, it is there, and the factory inside that file is set it will use it, otherwise will be PropertiesConfigurationProviderFactory it needs to implement org.owasp.csrfguard.config.ConfigurationProviderFactory
If csrfguard filter is enabled
If csrf guard filter should check even if there is no session for the user Note: this changed around 2014/4, the default behavior used to be to not check if there is no session. If you want the legacy behavior (if your app is not susceptible to CSRF if the user has no session), set this to false
The unique token per-page property (org.owasp.csrfguard.TokenPerPage) is a boolean value that determines if CSRFGuard should make use of unique per-page (i.e. URI) prevention tokens as opposed to unique per-session prevention tokens. When a user requests a protected resource, CSRFGuard will determine if a page specific token has been previously generated. If a page specific token has not yet been previously generated, CSRFGuard will verify the request was submitted with the per-session token intact. After verifying the presence of the per-session token, CSRFGuard will create a page specific token that is required for all subsequent requests to the associated resource. The per-session CSRF token can only be used when requesting a resource for the first time. All subsequent requests must have the per-page token intact or the request will be treated as a CSRF attack. This behavior can be changed with the org.owasp.csrfguard.TokenPerPagePrecreate property. Enabling this property will make CSRFGuard calculate the per page token prior to a first visit. This option only works with JSTL token injection and is useful for preserving the validity of links if the user pushes the back button. There may be a performance impact when enabling this option if the .jsp has a large number of proctected links that need tokens to be calculated. Use of the unique token per page property is currently experimental but provides a significant amount of improved security. Consider the exposure of a CSRF token using the legacy unique per-session model. Exposure of this token facilitates the attacker's ability to carry out a CSRF attack against the victim's active session for any resource exposed by the web application. Now consider the exposure of a CSRF token using the experimental unique token per-page model. Exposure of this token would only allow the attacker to carry out a CSRF attack against the victim's active session for a small subset of resources exposed by the web application. Use of the unique token per-page property is a strong defense in depth strategy significantly reducing the impact of exposed CSRF prevention tokens. The following configuration snippet instructs OWASP CSRFGuard to utilize the unique token per-page model: org.owasp.csrfguard.TokenPerPage=true org.owasp.csrfguard.TokenPerPagePrecreate=false
Enabling this property will make CSRFGuard calculate the per page token prior to a first visit. This option only works with JSTL token injection and is useful for preserving the validity of links if the user pushes the back button. There may be a performance impact when enabling this option if the .jsp has a large number of proctected links that need tokens to be calculated.
Actions: Responding to Attacks The actions directive (org.owasp.csrfguard.action.) gives the user the ability to specify one or more actions that should be invoked when a CSRF attack is detected. Every action must implement the org.owasp.csrfguard.action.IAction interface either directly or indirectly through the org.owasp.csrfguard.action.AbstractAction helper class. Many actions accept parameters that can be specified along with the action class declaration. These parameters are consumed at runtime and impact the behavior of the associated action. The syntax for defining and configuring CSRFGuard actions is relatively straight forward. Let us assume we wish to redirect the user to a default page when a CSRF attack is detected. A redirect action already exists within the CSRFGuard bundle and is available via the class name org.owasp.csrfguard.actions.Redirect. In order to enable this action, we capture the following declaration in the Owasp.CsrfGuard.properties file: syntax: org.owasp.csrfguard.action.actionName=className example: org.owasp.csrfguard.action.class.Redirect=org.owasp.csrfguard.actions.Redirect The aforementioned directive declares an action called 'Redirect' (i.e. actionName) referencing the Java class 'org.owasp.csrfguard.actions.Redirect' (i.e. className). Anytime a CSRF attack is detected, the Redirect action will be executed. You may be asking yourself, 'but how do I specify where the user is redirected?' this is where action parameters come into play. In order to specify the redirect location, we capture the following declaration in the Owasp.CsrfGuard.properties file: syntax: org.owasp.csrfguard.action.actionName.parameterName=parameterValue example: org.owasp.csrfguard.action.Redirect.ErrorPage=%servletContext%/csrf/error.html The aforementioned directive declares an action parameter called 'ErrorPage' (i.e. parameterName) with the value of '%servletContext%/error.html' (i.e. parameterValue) for the action 'Redirect' (i.e. actionName). The Redirect action expects the 'ErrorPage' parameter to be defined and will redirect the user to this location when an attack is detected. org.owasp.csrfguard.action.Empty=org.owasp.csrfguard.action.Empty
Token Name The token name property (org.owasp.csrfguard.TokenName) defines the name of the HTTP parameter to contain the value of the OWASP CSRFGuard token for each request. The following configuration snippet sets the CSRFGuard token parameter name to the value OWASP_CSRFTOKEN:
The session key property (org.owasp.csrfguard.SessionKey) defines the string literal used to save and lookup the CSRFGuard token from the session. This value is used by the filter and the tag libraries to retrieve and set the token value in the session. Developers can use this key to programmatically lookup the token within their own code. The following configuration snippet sets the session key to the value OWASP_CSRFTOKEN:
The token length property (org.owasp.csrfguard.TokenLength) defines the number of characters that should be found within the CSRFGuard token. Note that characters are delimited by dashes (-) in groups of four. For cosmetic reasons, users are encourage to ensure the token length is divisible by four. The following configuration snippet sets the token length property to 32 characters:
The pseudo-random number generator property (org.owasp.csrfguard.PRNG) defines what PRNG should be used to generate the OWASP CSRFGuard token. Always ensure this value references a cryptographically strong pseudo-random number generator algorithm. The following configuration snippet sets the pseudo-random number generator to SHA1PRNG:
The pseudo-random number generator provider property (org.owasp.csrfguard.PRNG.Provider) defines which provider's implementation of org.owasp.csrfguard.PRNG we should utilize. The following configuration snippet instructs the JVM to leverage SUN's implementation of the algorithm denoted by the org.owasp.csrfguard.PRNG property:
If not specifying the print config option in the web.xml, you can specify it here, to print the config on startup
Value of true will inject CSRF prevention tokens into all links regardless of domain from which HTML originated.
Comma separated list of domain names which will be considered valid regardless of domain of origin useful when dealing with proxy servers.
Default: private, maxage=28800
if the token should be injected in GET forms (which will be on the URL) if the HTTP method GET is unprotected, then this should likely be false
if the token should be injected in the action in forms note, if injectIntoForms is true, then this might not need to be true