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

Default: com.soa.console.csrf.CSRFLogger

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

Default: com.soa.console.csrf.ConfigurationProviderFactory

If csrfguard filter is enabled

Default: false

If csrf guard filter should check even if there is no session for the user Note: this changed around 2014/04, 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

Default: 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

Default: 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.

Default: false

Ajax and XMLHttpRequest Support The Ajax property (org.owasp.csrfguard.Ajax) is a boolean value that indicates whether or not OWASP CSRFGuard should support the injection and verification of unique per-session prevention tokens for XMLHttpRequests. To leverage Ajax support, the user must not only set this property to true but must also reference the JavaScript DOM Manipulation code using a script element. This dynamic script will override the send method of the XMLHttpRequest object to ensure the submission of an X-Requested-With header name value pair coupled with the submission of a custom header name value pair for each request. The name of the custom header is the value of the token name property and the value of the header is always the unique per-session token value. This custom header is analogous to the HTTP parameter name value pairs submitted via traditional GET and POST requests. If the X-Requested-With header was sent in the HTTP request, then CSRFGuard will look for the presence and ensure the validity of the unique per-session token in the custom header name value pair. Note that verification of these headers takes precedence over verification of the CSRF token supplied as an HTTP parameter. More specifically, CSRFGuard does not verify the presence of the CSRF token if the Ajax support property is enabled and the corresponding X-Requested-With and custom headers are embedded within the request. The following configuration snippet instructs OWASP CSRFGuard to support Ajax requests by verifying the presence and correctness of the X-Requested-With and custom headers:

Default: true

Unprotected Pages: The unprotected pages property (org.owasp.csrfguard.unprotected.*) defines a series of pages that should not be protected by CSRFGuard. Such configurations are useful when the CsrfGuardFilter is aggressively mapped (ex: /*). The syntax of the property name is org.owasp.csrfguard.unprotected.PageName, where PageName is some arbitrary identifier that can be used to reference a resource. The syntax of defining the uri of unprotected pages is the same as the syntax used by the JavaEE container for uri mapping. Specifically, CSRFGuard will identify the first match (if any) between the requested uri and an unprotected page in order of declaration. Match criteria is as follows: Case 1: exact match between request uri and unprotected page Case 2: longest path prefix match, beginning / and ending /* Case 3: extension match, beginning *. Case 4: if the value starts with ^ and ends with $, it will be evaulated as a regex. Note that before the regex is compiled, any common variables will be substituted (e.g. %servletContext%) Default: requested resource must be validated by CSRFGuard The following code snippet illustrates the four use cases over four examples. The first two examples (Tag and JavaScriptServlet) look for direct URI matches. The third example (Html) looks for all resources ending in a .html extension. The next example (Public) looks for all resources prefixed with the URI path /MySite/Public/*. The last example looks for resources that end in Public.do org.owasp.csrfguard.unprotected.Tag=%servletContext%/tag.jsp org.owasp.csrfguard.unprotected.JavaScriptServlet=%servletContext%/JavaScriptServlet org.owasp.csrfguard.unprotected.Html=*.html org.owasp.csrfguard.unprotected.Public=%servletContext%/Public/* regex example starts with ^ and ends with $, and the %servletContext% is evaluated before the regex org.owasp.csrfguard.unprotected.PublicServlet=^%servletContext%/.*Public.do$

Default: ^%servletContext%/common/sessionexpired.jsp.*$

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

Default: org.owasp.csrfguard.action.Log

org.owasp.csrfguard.action.Invalidate=org.owasp.csrfguard.action.Invalidate

Default: org.owasp.csrfguard.action.Redirect

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:

Default: X-Csrf-Token

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:

Default: 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:

Default: 32

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:

Default: 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:

Default: SUN

If not specifying the print config option in the web.xml, you can specify it here, to print the config on startup

Default: false

leave this blank and blank in web.xml and it will read from META-INF/csrfguard.js from the jarfile Denotes the location of the JavaScript template file that should be consumed and dynamically augmented by the JavaScriptServlet class. The default value is WEB-INF/Owasp.CsrfGuard.js. Use of this property and the existence of the specified template file is required.

Default: META-INF/resources/csrf/csrfguard.js

Boolean value that determines whether or not the dynamic JavaScript code should be strict with regards to what links it should inject the CSRF prevention token. With a value of true, the JavaScript code will only place the token in links that point to the same exact domain from which the HTML originated. With a value of false, the JavaScript code will place the token in links that not only point to the same exact domain from which the HTML originated, but sub-domains as well.

Default: true

Value of true will inject CSRF prevention tokens into all links regardless of domain from which HTML originated.

Default: false

Comma separated list of domain names which will be considered valid regardless of domain of origin useful when dealing with proxy servers.

Allows the developer to specify the value of the Cache-Control header in the HTTP response when serving the dynamic JavaScript file. The default value is private, maxage=28800. Caching of the dynamic JavaScript file is intended to minimize traffic and improve performance. Note that the Cache-Control header is always set to 'no-store' when either the 'Rotate' 'TokenPerPage' options is set to true in Owasp.CsrfGuard.properties.

Default: private

Allows the developer to specify a regular expression describing the required value of the Referer header. Any attempts to access the servlet with a Referer header that does not match the captured expression is discarded. Inclusion of referer header checking is to help minimize the risk of JavaScript Hijacking attacks that attempt to steal tokens from the dynamically generated JavaScript. While the primary defenses against JavaScript Hijacking attacks are implemented within the dynamic JavaScript itself, referer header checking is implemented to achieve defense in depth.

Default: .*

Similar to javascript servlet referer pattern, but this will make sure the referer of the javascript servlet matches the domain of the request. If there is no referer (proxy strips it?) then it will not fail. Generally this is a good idea to be true.

Default: true

Boolean value that determines whether or not the dynamic JavaScript code should inject the CSRF prevention token as a hidden field into HTML forms. The default value is true. Developers are strongly discouraged from disabling this property as most server-side state changing actions are triggered via a POST request.

Default: true

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

Default: true

if the token should be injected in the action in forms note, if injectIntoForms is true, then this might not need to be true

Default: true

Boolean value that determines whether or not the dynamic JavaScript code should inject the CSRF prevention token in the query string of src and href attributes. Injecting the CSRF prevention token in a URL resource increases its general risk of exposure to unauthorized parties. However, most JavaEE web applications respond in the exact same manner to HTTP requests and their associated parameters regardless of the HTTP method. The risk associated with not protecting GET requests in this situation is perceived greater than the risk of exposing the token in protected GET requests. As a result, the default value of this attribute is set to true. Developers that are confident their server-side state changing controllers will only respond to POST requests (i.e. discarding GET requests) are strongly encouraged to disable this property.

Default: false