From 4ef3e703da06e8fbd3083a0cdc97aa77aa198a81 Mon Sep 17 00:00:00 2001 From: Harshan Liyanage Date: Wed, 14 Dec 2016 11:22:25 +0530 Subject: [PATCH] Added Owasp config for store and publisher apps --- .../core/distribution/src/assembly/bin.xml | 4 + .../Owasp.CsrfGuard.dashboard.properties | 446 ++++++++++++++++++ 2 files changed, 450 insertions(+) create mode 100644 modules/core/distribution/src/repository/conf/security/Owasp.CsrfGuard.dashboard.properties diff --git a/modules/core/distribution/src/assembly/bin.xml b/modules/core/distribution/src/assembly/bin.xml index 0892cc94..a1851be3 100644 --- a/modules/core/distribution/src/assembly/bin.xml +++ b/modules/core/distribution/src/assembly/bin.xml @@ -763,6 +763,10 @@ src/repository/conf/security/Owasp.CsrfGuard.Carbon.properties ${pom.artifactId}-${pom.version}/repository/conf/security + + src/repository/conf/security/Owasp.CsrfGuard.dashboard.properties + ${pom.artifactId}-${pom.version}/repository/conf/security + ../p2-profile-gen/target/wso2carbon-core-${carbon.kernel.version}/repository/conf/event-broker.xml diff --git a/modules/core/distribution/src/repository/conf/security/Owasp.CsrfGuard.dashboard.properties b/modules/core/distribution/src/repository/conf/security/Owasp.CsrfGuard.dashboard.properties new file mode 100644 index 00000000..88257953 --- /dev/null +++ b/modules/core/distribution/src/repository/conf/security/Owasp.CsrfGuard.dashboard.properties @@ -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 + + +########################## \ No newline at end of file