# The OWASP CSRFGuard Project, BSD License
# Eric Sheridan (eric@infraredsecurity.com), Copyright (c) 2011
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
#
# 1. Redistributions of source code must retain the above copyright notice,
# this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the distribution.
# 3. Neither the name of OWASP nor the names of its contributors may be used
# to endorse or promote products derived from this software without specific
# prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
# (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
# LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
# ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
# SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

# From: https://github.com/esheri3/OWASP-CSRFGuard/blob/master/csrfguard-test/src/main/webapp/WEB-INF/csrfguard.properties
 
# Common substitutions
# %servletContext%  is the servlet context (e.g. the configured app prefix or war file name, or blank.
# e.g. if you deploy a default warfile as someApp.war, then %servletContext% will be /someApp
# if there isnt a context it will be the empty string.  So to use this in the configuration, use e.g. %servletContext%/something.html
# which will translate to e.g. /someApp/something.html

# Logger
#
# 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
org.owasp.csrfguard.configuration.provider.factory = org.owasp.csrfguard.config.overlay.ConfigurationAutodetectProviderFactory


# If csrfguard filter is enabled
org.owasp.csrfguard.Enabled = true

# 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
org.owasp.csrfguard.ValidateWhenNoSessionExists = true

# New Token Landing Page
#
# The new token landing page property (org.owasp.csrfguard.NewTokenLandingPage) defines where
# to send a user if the token is being generated for the first time, and the use new token landing
# page boolean property (org.owasp.csrfguard.UseNewTokenLandingPage) determines if any redirect happens.
# UseNewTokenLandingPage defaults to false if NewTokenLandingPage is not specified, and to true
# if it is specified.. If UseNewTokenLandingPage is set true then this request is generated
# using auto-posting forms and will only contain the CSRF prevention token parameter, if
# applicable. All query-string or form parameters sent with the original request will be
# discarded. If this property is not defined, CSRFGuard will instead auto-post the user to the
# original context and servlet path. The following configuration snippet instructs OWASP CSRFGuard to
# redirect the user to %servletContext%/index.html when the user visits a protected resource
# without having a corresponding CSRF token present in the HttpSession object:
#
# org.owasp.csrfguard.NewTokenLandingPage=%servletContext%/index.html

 
# Protected Methods
#
# The protected methods property (org.owasp.csrfguard.ProtectedMethods) defines a comma
# separated list of HTTP request methods that should be protected by CSRFGuard. The default
# list is an empty list which will cause all HTTP methods to be protected, thus preserving
# legacy behavior. This setting allows the user to inform CSRFGuard that only requests of the
# given types should be considered for protection. All HTTP methods not in the list will be
# considered safe (i.e. view only / unable to modify data). This should be used only when the
# user has concrete knowledge that all requests made via methods not in the list
# are safe (i.e. do not apply an action to any data) since it can actually introduce new
# security vulnerabilities. For example: the user thinks that all actionable requests are
# only available by POST requests when in fact some are available via GET requests. If the
# user has excluded GET requests from the list then they have introduced a vulnerability.
# The following configuration snippet instructs OWASP CSRFGuard to protect only the POST,
# PUT, and DELETE HTTP methods.
#
# org.owasp.csrfguard.ProtectedMethods=POST,PUT,DELETE

# or you can configure all to be protected, and specify which is unprotected.  This is the preferred approach

# org.owasp.csrfguard.UnprotectedMethods=GET

# Unique Per-Page Tokens
#
# 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
org.owasp.csrfguard.TokenPerPage=true
org.owasp.csrfguard.TokenPerPagePrecreate=false
 
# Token Rotation
#
# The rotate token property (org.owasp.csrfguard.Rotate) is a boolean value that determines if
# CSRFGuard should generate and utilize a new token after verifying the previous token. Rotation
# helps minimize the window of opportunity an attacker has to leverage the victim's stolen token
# in a targeted CSRF attack. However, this functionality generally causes navigation problems in
# most applications. Specifically, the 'Back' button in the browser will often cease to function
# properly. When a user hits the 'Back' button and interacts with the HTML, the browser may submit
# an old token causing CSRFGuard to incorrectly believe this request is a CSRF attack in progress
# (i.e. a 'false positive'). Users can prevent this scenario by preventing the caching of HTML pages
# containing FORM submissions using the cache-control header. However, this may also introduce
# performance problems as the browser will have to request HTML on a more frequent basis. The following
# configuration snippet enables token rotation:
#
# org.owasp.csrfguard.Rotate=true
 
# 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:
#
# org.owasp.csrfguard.Ajax=true
org.owasp.csrfguard.Ajax=true
 
# The default behavior of CSRFGuard is to protect all pages. Pages marked as unprotected will not be protected.
# If the Protect property is enabled, this behavior is reversed. Pages must be marked as protected to be protected.
# All other pages will not be protected. This is useful when the CsrfGuardFilter is aggressively mapped (ex: /*),
# but you only want to protect a few pages.
#
# org.owasp.csrfguard.Protect=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$
org.owasp.csrfguard.unprotected.Default=%servletContext%/
org.owasp.csrfguard.unprotected.Upload=%servletContext%/upload.html
org.owasp.csrfguard.unprotected.JavaScriptServlet=%servletContext%/JavaScriptServlet
org.owasp.csrfguard.unprotected.Ajax=%servletContext%/ajax.html
org.owasp.csrfguard.unprotected.Error=%servletContext%/error.html
org.owasp.csrfguard.unprotected.Index=%servletContext%/index.html
org.owasp.csrfguard.unprotected.JavaScript=%servletContext%/javascript.html
org.owasp.csrfguard.unprotected.Tag=%servletContext%/tag.jsp
org.owasp.csrfguard.unprotected.Redirect=%servletContext%/redirect.jsp
org.owasp.csrfguard.unprotected.Forward=%servletContext%/forward.jsp
org.owasp.csrfguard.unprotected.Session=%servletContext%/session.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%/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
org.owasp.csrfguard.action.Log=org.owasp.csrfguard.action.Log
org.owasp.csrfguard.action.Log.Message=potential cross-site request forgery (CSRF) attack thwarted (user:%user%, ip:%remote_ip%, method:%request_method%, uri:%request_uri%, error:%exception_message%)
#org.owasp.csrfguard.action.Invalidate=org.owasp.csrfguard.action.Invalidate
org.owasp.csrfguard.action.Redirect=org.owasp.csrfguard.action.Redirect
org.owasp.csrfguard.action.Redirect.Page=%servletContext%/error.html
#org.owasp.csrfguard.action.RequestAttribute=org.owasp.csrfguard.action.RequestAttribute
#org.owasp.csrfguard.action.RequestAttribute.AttributeName=Owasp_CsrfGuard_Exception_Key
org.owasp.csrfguard.action.Rotate=org.owasp.csrfguard.action.Rotate
#org.owasp.csrfguard.action.SessionAttribute=org.owasp.csrfguard.action.SessionAttribute
#org.owasp.csrfguard.action.SessionAttribute.AttributeName=Owasp_CsrfGuard_Exception_Key
#org.owasp.csrfguard.action.Error=org.owasp.csrfguard.action.Error
#org.owasp.csrfguard.action.Error.Code=403
#org.owasp.csrfguard.action.Error.Message=Security violation.

# 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:
#
# org.owasp.csrfguard.TokenName=OWASP_CSRFTOKEN
org.owasp.csrfguard.TokenName=OWASP_CSRFTOKEN
 
# Session Key
#
# 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:
#
# org.owasp.csrfguard.SessionKey=OWASP_CSRFTOKEN
org.owasp.csrfguard.SessionKey=OWASP_CSRFTOKEN
 
# Token Length
#
# 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:
#
# org.owasp.csrfguard.TokenLength=32
org.owasp.csrfguard.TokenLength=32
 
# Pseudo-random Number Generator
#
# 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:
#
# org.owasp.csrfguard.PRNG=SHA1PRNG
org.owasp.csrfguard.PRNG=SHA1PRNG
 
# Pseudo-random Number Generator Provider

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

# org.owasp.csrfguard.PRNG.Provider=SUN
org.owasp.csrfguard.PRNG.Provider=SUN

# If not specifying the print config option in the web.xml, you can specify it here, to print the config
# on startup
org.owasp.csrfguard.Config.Print = true

###########################
## Javascript servlet settings if not set in web.xml
## https://www.owasp.org/index.php/CSRFGuard_3_Token_Injection
###########################

# 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.
org.owasp.csrfguard.JavascriptServlet.sourceFile = 

# 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.
org.owasp.csrfguard.JavascriptServlet.domainStrict = true

# 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.
org.owasp.csrfguard.JavascriptServlet.cacheControl = private, maxage=28800

# 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.
org.owasp.csrfguard.JavascriptServlet.refererPattern = .*

# 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.
org.owasp.csrfguard.JavascriptServlet.refererMatchDomain = 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.
org.owasp.csrfguard.JavascriptServlet.injectIntoForms = 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.
org.owasp.csrfguard.JavascriptServlet.injectIntoAttributes = true 


org.owasp.csrfguard.JavascriptServlet.xRequestedWith = OWASP CSRFGuard Project

###########################
## Config overlay settings if you have the provider above set to ConfigurationOverlayProvider
## This CSRF config provider uses Internet2 Configuration Overlays (documented on Internet2 wiki)
## By default the configuration is read from the Owasp.CsrfGuard.properties
## (which should not be edited), and the Owasp.CsrfGuard.overlay.properties overlays
## the base settings.  See the Owasp.CsrfGuard.properties for the possible
## settings that can be applied to the Owasp.CsrfGuard.overlay.properties
###########################

# comma separated config files that override each other (files on the right override the left)
# each should start with file: or classpath:
# e.g. classpath:Owasp.CsrfGuard.properties, file:c:/temp/myFile.properties
org.owasp.csrfguard.configOverlay.hierarchy = classpath:Owasp.CsrfGuard.properties, classpath:Owasp.CsrfGuard.overlay.properties

# seconds between checking to see if the config files are updated
org.owasp.csrfguard.configOverlay.secondsBetweenUpdateChecks = 60


###########################