I have configured ZAP 2.6 so that it is acting as a proxy for requests from an Android app to a web service over HTTPS. The authentication mechanism is OAuth 2, and so in my login response I get an access token which is then sent in all subsequent request headers as follows
Authorization: Bearer my_long_and_encoded_access_token
Is it possible to get ZAP to recognise this token and use it in tests initiated from the ZAP UI?
I have looked at Automate OAuth access token for Zed Attack Proxy Scans but don't believe this covers my situation.
Thanks.
Yes, you can create a script which extracts this token and then uses it in future requests.
If you need help with such a script then asking on the ZAP User Group might be a better option than asking here ;)
Related
We have a Jenkins instance set up behind an NGinx HTTPS reverse proxy. User authentication is done via PKI user client certificates.
So I want to make RESTful API requests against Jenkins to do things like kick off builds etc. I have got this to work by using application tokens and can kick off builds with and without parameters by using Curl, specifying my client certificate and key. All good so far.
I was interested in using crumbs instead of application tokens as nothing needs to be set up beforehand (i.e. creating the application token). However all the examples I could find use basic auth style authentication in the URI and trying to use the PKI authentication as above results in Error 403 No valid crumb was included in the request. Also remember that being PKI based, users don't have passwords on the system as they are authenticated by their certificate.
Would I be right in assuming that the crumb approach can't be used with PKI authentication?
I have just started using jmeter and want to run performance tests on my application which uses google auth as a login option(oAuth 2.0), What are the steps to implement login using google auth on jmeter?
You need to obtain so called token and add it to your request as Authorization header using HTTP Header Manager like:
With regards to how to obtain the token - it depends on your application configuration, if you're lucky enough and the token is more or less permanent - you can obtain it using Google Developer Console
If the token lifetime is limited and/or your application uses for complex flows - you will have to implement this flow in JMeter, the implementations vary and can be i.e. Web Applications or Installed Applications or Client-Side Aplications, you need to ask around and determine the exact flow.
Check out How to Run Performance Tests on OAuth Secured Apps with JMeter article to learn more about bypassing OAuth login challenge in JMeter tests
With LinkedIn's planned deprecation of their JS SDK, is there any way to complete the OAuth2 flow and obtain an access token from the client-side, without using a server-side proxy to exchange the auth code for the token?
According to this SO post, LinkedIn does not allow for an implicit grant flow. It's from 2015, but appears to still be relevant.
Is there any alternative way I can obtain an access token for a user who authenticated with LinkedIn, without hitting a self-hosted proxy? My application only needs basic profile data for the user.
Edit
To provide more context, the error I receive when making the second request to https://www.linkedin.com/oauth/v2/accessToken is No 'Access-Control-Allow-Origin' header is present on the requested resource. The same request made from postman works fine and returns the access token. I understand this CORS issue comes down to browser policy. Right now I'm testing from localhost over https. Once the front end code is deployed to a proper domain, will the error persist? Is there any alternative way to get around this?
Thank you!
I apologies in advance for incorrect use of oauth terms.
I have 4 "parties" as follows (intentionally not using oauth terms where possible):
End-user in a browser (javascript)
Our website (aspnet)
Our web api (aspnet)
Our auth server (aspnet utilising identityserver 4)
My usage scenario is that we only want the API to be called by a browser that has requested a page from the website first. Whilst the API doesn't release sensitive information, we would like to introduce a layer of complexity with regards to the API being spammed.
Our end user's will not be logged in.
I imagine such a flow being akin:
Browser requests a certain page from the website (one that will likely lead to js making an api call)
Website requests token from auth server
Auth server verifies token request came from website (the server itself)
Auth server returns a token to the website
Website returns page including the access token
Browser is able to make a request to api using token
Although convoluted, I believe this is at least similar to the Client Access Grant flow?
These tokens could then be throttled either by website or auth server.
Yes, I'm aware that this doesn't protect the api from numerous other vectors, but it does eliminate the simplest of cases which is all we're looking to achieve for now. I'll add, I didn't define this requirement, I'm simply trying to find a way to achieve it utilising techs out there instead of making the mistake of rolling anything of my own.
Could someone confirm/deny that there is an oauth flow I could use here? Any sample projects using the given flow and IdentityServer?
IdentityServer3 / non-aspnet[core/5] examples are fine, I can translate.
What you describe is the Client Credentials Grant where your website (client) gets an access token from identityserver (auth server). That access token can then be used to call endpoints on your web API (resource server).
The token is a bearer token and can be used by anyone who has it, so if you are comfortable with your website passing it back to a browser on an HTTP response, then it will work just fine.
I'm not sure what you mean by throttling the tokens - once minted they are valid for their lifetime. I guess you can keep the time-to-live very short to achieve the single usage you want though.
I am using Google+ Sign-in in my application. A user gets an access_token back and I want to pass that token to my server and verify it with google. What is confusing me is conflicting information in google's documentation regarding the security of this:
https://developers.google.com/accounts/docs/OAuth2UserAgent#validatetoken
Says I can make an ajax call with the access_token to check if it is a valid token. This works fine for me, however,
https://developers.google.com/+/web/signin/client-to-server-flow
Says never to send the access_token as a parameter in an http request to my server.
So, is it safe to use https://www.googleapis.com/oauth2/v1/tokeninfo or not?
There's a difference between sending the access token in an HTTP request to your server and sending it to Google's server.
When sending the access token to Google's tokeninfo endpoint for validation it's OK to send it as a query parameter, since it runs over HTTPs and Google is the issuer of the access token in the first place, so you're sending it to a known and controlled environment. Google assumes that Google knows what its doing.
But when sending the access token from client to your server (and you must make sure you use HTTPs anyhow) passing it as a query parameter is less secure since it may end up in logs and traffic analysis data on the server end. Examples of that are situations where there's a proxy in between client and server or you're using web hosting.
On top of that there are sophisticated attacks against OAuth 2.0 enabled systems that exploit the the fact that query parameters with tokens end up in Location and Referer headers. It is better to avoid the possibility of being exposed to any vulnerability like that. For a nice impression of those attacks, see http://www.oauthsecurity.com/ especially the section on open redirects.
I think the docs are saying to not use the access token as a GET parameter to your web app because most web servers will log the URLs accessed in an unprotected location unless it's specifically configured to not do it. So if you did an AJAX request to your backend server, the user's access token would be exposed in the web server logs.
Using the tokeninfo endpoint should be fine because Google does the logging and will handle the security of the logs. HTTPS protects the request URL and the message, so there are no special concerns using the access token as a GET parameter.