forked from community/product-iots
Merge branch 'master' of https://github.com/wso2/product-iots
Menaka Jayawardena
8 years ago
commit
75c6eba589
@ -0,0 +1,446 @@
|
||||
# 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 = false
|
||||
|
||||
# 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
|
||||
|
||||
# WSO2 : Since state-changing operations are not performed via HTTP GET,
|
||||
# disabling CSRF validation for GET method.
|
||||
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
|
||||
|
||||
# WSO2 : Considering overhead, necessity, as well as current unintended behaviour
|
||||
# of library after blocking a CSRF attack, disabling per-page tokens.
|
||||
org.owasp.csrfguard.TokenPerPage=false
|
||||
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
|
||||
|
||||
# WSO2 : Disable redirecting user to an error page after blocking a CSRF attack
|
||||
#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
|
||||
|
||||
# WSO2 : Disabling token rotation after blocking a CSRF attack, since this behaviour
|
||||
# will break back navigation after blocking an attack.
|
||||
#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
|
||||
|
||||
# WSO2 : Enable sending a 403 error after blocking a CSRF attack. Product teams
|
||||
# can add error page that handles 403 or “org.owasp.csrfguard.action.Error” to
|
||||
# display custom error pages.
|
||||
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
|
||||
|
||||
# WSO2 : Since, CSRFGuard will send relevant token name as HTTP header
|
||||
# “X-” prefix was added to express that this is a non-standard header.
|
||||
org.owasp.csrfguard.TokenName=X-CSRF-Token
|
||||
|
||||
# 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
|
||||
# WSO2 - Pseudo-random number generator provider should be configured based on
|
||||
# environment (SUN/IBMJCE)
|
||||
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
|
||||
|
||||
# WSO2 : Disable printing configuration during start-up
|
||||
org.owasp.csrfguard.Config.Print = false
|
||||
|
||||
###########################
|
||||
## 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
|
||||
|
||||
# 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
|
||||
|
||||
# WSO2 : Disable JavaScript from injecting token value to HTTP GET based forms.
|
||||
# This prevents token leakage that could occur when sending token in URL.
|
||||
# State-changing actions should not be performed over HTTP GET
|
||||
org.owasp.csrfguard.JavascriptServlet.injectGetForms = 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
|
||||
|
||||
# WSO2 : Disable JavaScript from injecting token value to form action.
|
||||
# This prevents token leakage that could occur when sending token in URL.
|
||||
org.owasp.csrfguard.JavascriptServlet.injectFormAttributes = false
|
||||
|
||||
|
||||
# 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.
|
||||
|
||||
# WSO2 : Disable JavaScript from injecting token value to “src” and “href”.
|
||||
# This prevents token leakage that could occur when sending token in URL.
|
||||
org.owasp.csrfguard.JavascriptServlet.injectIntoAttributes = false
|
||||
|
||||
|
||||
# WSO2 : Changing X-Request-With header text to avoid unnecessary information disclosure.
|
||||
org.owasp.csrfguard.JavascriptServlet.xRequestedWith = WSO2 CSRF Protection
|
||||
|
||||
###########################
|
||||
## 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
|
||||
|
||||
|
||||
##########################
|
||||
Loading…
Reference in new issue