CSRF Guard: How to hide CSRF token from URL - I am using owasp csrfgaurd-3.1.0 version to avoid CSRF attacks. However my CSRF tokens appear in the URL as parameter.
http://localhost:9010/certificates/applicationQAReport.html?OWASP-CSRFTOKEN=EN9U-D4VP-URYM-DQ6T-48KD-HKQC-MGLW-L8EM
I want to avoid it. I tried setting this property to false in owasp properties but it did not help
org.owasp.csrfguard.JavascriptServlet.injectGetForms = false
Related
I´m using spring security rest. Actually to refresh token im using this url: /oauth/access_token?grant_type=refresh_token&refresh_token=token
However i'm using api rest and I want to use /api/oauth to refresh token instead of /oauth.
I tried redirect in urlMappings, but response 404 not found.
"/api/oauth"(redirect: '/oauth')
"/api/oauth"(redirect: '/oauth')
As you found, that mapping won't work but there may not be a good reason to use a redirect anyway. The plugin provides a mapping like this:
"/oauth/access_token"(controller: 'restOauth', action: 'accessToken')
(see https://github.com/alvarosanchez/grails-spring-security-rest/blob/d5940921b4aea466a961957e0599321d01e4c6de/spring-security-rest/grails-app/controllers/grails/plugin/springsecurity/rest/RestOauthUrlMappings.groovy#L24)
You can map whatever url you like to that controller. You could do this...
"/api/oauth"(controller: 'restOauth', action: 'accessToken')
*** Work for me grails spring refresh token
-method : Post
-http://localhost:8085/oauth/access_token?grant_type=refresh_token&refresh_token={your_access_token}
Is it possible to specify a global default timeout for CSRF form elements in Zend 2?
Otherwise I have to specify a timeout option for each CSRF element.
P.S.: What's the value of the current default timeout?
From the source code of Zend\Validator\Csrf, the default timeout of Csrf element in Zend Framework 2 is set to 300:
protected $timeout = 300; //line 70
If you want to set the same time out for all Csrf elements in your forms, you could create a custom csrfValidator with the timeout value you want and override the default CSRF validator of your elements using setCsrfValidator method.
Otherwise just change the default options when you add Csrf element to your forms:
You can change the options of the CSRF validator using the setCsrfValidatorOptions function, or by using the csrf_options key.
Csrf documentation
I have my own Form base class, derived off Zend\Form\From that all my forms inherit from. This way I can have some default behavior for all forms. Specifically, the one thing I have in this base class for now is that all forms are given a CSRF element by default. This way I never forget to add one. And, if you are doing this, then you could easily configure whatever time-out you want in that one place and it would apply to all your forms.
I am currently using Spring Security OAuth2 with Reddit - and trying to pass the duration parameter when redirecting the user to an authorization URL.
This URL is constructed via getRedirectForAuthorization - which is a private method in AuthorizationCodeAccessTokenProvider - so it's not immediately clear how the duration parameter should be added in.
Am I missing anything?
Thanks.
You can add query parameters to the authorization request using a RequestEnhancer. You can inject one into the AccessTokenProvider and the DefaultRequestEnhancer includes a list of parameters to include (empty by default).
We're making requests for bearer tokens using client_credentials OAuth 2 grant flow with Apigee. According to the spec:
4.4.2. Access Token Request
The client makes a request to the token endpoint by adding the
following parameters using the "application/x-www-form-urlencoded"
format per Appendix B with a character encoding of UTF-8 in the HTTP
request entity-body:
grant_type
REQUIRED. Value MUST be set to "client_credentials".
If we make a call however we get an error like this:
{"ErrorCode" : "invalid_request", "Error" :"Required param : grant_type"}
It seems that using Apigee we have to send grant_type as a query parameter.
Why is this? We have clients of Apigee that are unable to use OAuth libraries in their language of choice because of the way that Apigee deals with OAuth 2, and it would be good to know if there is by-design or not.
In addition it doesn't seem like it supports grant_type in the post body and sending id and key using basic auth.
Turns out you do not need to send in grant_type as a query parameter. There is a <GrantType> element in your GenerateAccessToken policy that takes in a variable. For instance, I can use the following:
<OAuthV2 name="GenerateAccessToken">
<DisplayName>GenerateAccessToken</DisplayName>
<FaultRules/>
<Properties/>
<!-- This policy generates an OAuth 2.0 access token using the password grant type -->
<Operation>GenerateAccessToken</Operation>
<!-- This is in millseconds -->
<ExpiresIn>1800000</ExpiresIn>
<Attributes/>
<SupportedGrantTypes>
<GrantType>password</GrantType>
</SupportedGrantTypes>
<GenerateResponse enabled="false">
<Format>FORM_PARAM</Format>
</GenerateResponse>
<GrantType>user.grant_type</GrantType>
<UserName>request.header.username</UserName>
<PassWord>request.header.password</PassWord>
</OAuthV2>
In this example, the grant_type is passed in as user.grant_type. But user.grant_type can be anything-- header, query param, form param, or even a hard-coded value. This way, you (the developer) are provided maximum flexibility on how you want to send in the grant_type.
Can you paste the exact API call that you are making (obviously you should obfuscate the key and secret)?
I'd like to understand what you say when you say "Apigee" -- it could mean API BAAS (https://api.usergrid.com) or a proxy that you defined using API services and attached an OAuth 2 policy to, or something else?
In the OAuth 1.0 spec it is suggested to respond with the following WWW-Authenticate header:
WWW-Authenticate: OAuth realm="http://server.example.com/"
Is it suitable to add any other informative data to this header? In case a request for a protected resource fails, would it be reasonable to include some information as to why? Such as:
WWW-Authenticate: OAuth realm="http://server.example.com/", access token invalid
Or is this contrary to the purpose of the response header?
Note for anyone just stumbling across this: The OAuth 2.0 bearer token spec adds "error", "error_description", and "error_uri" attributes to the "WWW-Authenticate" header for reporting additional error information, and it specifies when they should and shouldn't be used.
E.g.:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
error="invalid_token",
error_description="The access token expired"
Sounds a little dubious to me. The WWW-Authenticate header is specified by an RFC, which would seem to forbid the example you've given. The OAuth spec says that you can include other WWW-Authenticate fields as defined by the RFC, not that you can just tack arbitrary strings onto the end of it. I would avoid it, unless there is a defined field that you could twist to your purposes.
It's against the spec to do that, and if it wasn't it would probably be something like :
realm="http://server.example.com", oauth_error="access token invalid"
I'd recommend using the response body for things like this, or maybe a X-OAuth-Error header.