Using Postman, I can create an API call which creates a TWEx2 cookie and auth. The cookie will look something similar to this:
83df910f-86a0-4ce8-a334-696d8g0f07db
Obviously, in my production code I cannot use Postman, so I have been trying to find a way to generate these cookies on my own. But when I try to search for "TWEx2 Cookie", or any kind of generator, I find tons of recipes for Twix Cookies. Clearly that's less than helpful.
Below you will see the TWEx2 cookie, and the auth. I have found that the auth is not needed, but the cookie is. I have tried several methods without the cookie, and the API request results in NULL.
Can anyone point me in the right direction on some instructions on how to create these hashed strings, or explain it to me?
The problem was my headers - I thought that I had accepted all returned values from the API but I had left out 'CURLOPT_HEADER' from my cURL.
Without receiving a cookie from the API, I had assumed (incorrectly) that I needed to create my own cookie. As soon as I added that in the header, I was able to see the cookie which was generated and returned by the API and use that.
So, if you run into this problem, make sure your headers are correct.
As a side note, "TWEx2" appears to be something specific to this API. It does not appear to be a normal thing.
Related
So, I am developing a very basic blog using spring boot, and as I am getting to the controllers layer, I want to test with Postman. GET requests are working perfectly fine, but POST requests are getting 403 forbidden.
I have been doing a lot of research and it seems it is all about the default spring security's CSRF cookie. I have tried a bunch of different things (like this one https://dev.to/shane/using-postman-with-java-spring-and-csrf-tokens-di0), but the thing is, when I do it, the csrf variable in Postman never gets filled. It is always undefined.
On the other hand, I know there are ways to disable csrf, but I don't want that. It does not solve anything, it is just bypassing the problem without really understanding how to tackle it.
How can I get past this? How can I get Postman to get the csrf cookie, put it in a variable that I can then reuse in a POST request?
I am building a frontend client for Jira and am running into some conflicting authentication methods I think.
I have setup the OAuth2 authentication method for logging in and hitting the Jira API. I have a button on a login page that redirects to Jira, you log in, hit "allow" and are redirected to my app. This step completes fine, I have a token and a secret and can make api calls just fine.
Next, I make an api call to get the user data, which returns fine. One of the pieces of data is a set of avatar urls. I put one of the urls into my site's markup. Here is where the problem begins.
If my browser session that I used to login is still active, I get an avatar. BUT if not, I get an "anonymous" avatar from Jira.
All the while, my OAuth token/api calls all seem to return fine.
This makes sense as Jira is using cookie based auth and I am not. So if that cookie dies in my browser, the call to the image will fail.
My ultimate question is how to handle this? Is this my responsibility to put an expiration on the token? What happens if they select "Stay logged in"? I don't think I get that knowledge on the OAuth side.
I kind of feel like I am missing something but I cannot figure out what. This seems like a problem that has been fixed or isn't even really a problem.
One solution would be just to switch to a cookie based authentication but OAuth seems more secure.
I've also tried directly hitting it from my server but that also yields an anon avatar. As does a curl with the access token. Maybe I didn't provide it in the correct way?
Any thoughts or ideas on this would be greatly appreciated. Thanks in advance.
I have created a Rest service. In this service I want to know which client is calling the service. Is there any method to check the properties or information of the client.
I don't know what you exactly mean by "which client". I see two things:
The terminal kind. This can be known using the User-Agent header if set.
The authenticated user using the Authorization header. The content in this header allows to get the corresponding user. This allows to authenticate requests. In this case, this link could help you: https://templth.wordpress.com/2015/01/05/implementing-authentication-with-tokens-for-restful-applications/.
Hope it helps you,
Thierry
I have a RESTful API which has annotations like #Consumes(MediaType.JSON) - in that case, would the CSRF attack still be possible on such a service? I've been tinkering with securing my services with CSRFGuard on server side or having a double submit from client side. However when I tried to POST requests using FORM with enctype="text/plain", it didn't work. The technique is explained here This works if I have MediaType.APPLICATION_FORM_URLENCODED in my consumes annotation. The content negotiation is useful when I'm using POST/PUT/DELETE verbs but GET is still accessible which might need looking into.
Any suggestions or inputs would be great, also please let me know if you need more info.
Cheers
JAX-RS is designed to create REST API which is supposed to be stateless.
The Cross Site Request Forgery is NOT a problem with stateless applications.
The way Cross Site Request Forgery works is someone may trick you to click on a link or open a link in your browser which will direct you to a site in which you are logged in, for example some online forum. Since you are already logged in on that forum the attacker can construct a url, say something like this: someforum.com/deletethread?id=23454
That forum program, being badly designed will recognize you based on the session cookie and will confirm that you have the capability to delete the thread and will in fact delete that thread.
All because the program authenticated you based on the session cookie (on even based on "remember me" cookie)
With RESTful API there is no cookie, no state is maintaned between requests, so there is no need to protect against session hijacking.
The way you usually authenticate with RESTFul api is be sending some additional headers. If someone tricks you into clicking on a url that points to restful API the browser is not going to send that extra headers, so there is no risk.
In short - if REST API is designed the way it supposed to be - stateless, then there is no risk of cross site forgery and no need to CSRF protection.
Adding another answer as Dmitri’s answer mixes serverside state and cookies.
An application is not stateless if your server stores user information in the memory over multiple requests. This decreases horizontal scalability as you need to find the "correct" server for every request.
Cookies are just a special kind of HTTP header. They are often used to identify a users session but not every cookie means server side state. The server could also use the information from the cookie without starting a session. On the other hand using other HTTP headers does not necessarily mean that your application is automatically stateless. If you store user data in your server’s memory it’s not.
The difference between cookies and other headers is the way they are handled by the browser. Most important for us is that the browser will resend them on every subsequent request. This is problematic if someone tricks a user to make a request he doesn’t want to make.
Is this a problem for an API which consumes JSON? Yes, in two cases:
The attacker makes the user submit a form with enctype=text/plain: Url encoded content is not a problem because the result can’t be valid JSON. text/plain is a problem if your server interprets the content not as plain text but as JSON. If your resource is annotated with #Consumes(MediaType.JSON) you should not have a problem because it won’t accept text/plain and should return a status 415. (Note that JSON may become a valid enctype one day and this won’t be valid any more).
The attacker makes the user submit an AJAX request: The Same Origin Policy prevents AJAX requests to other domains so you are safe as long as you don’t disable this protection by using CORS-headers like e.g. Access-Control-Allow-Origin: *.
Will OpenAM work if cookies are disabled?
I have a Flex application and on some browsers (Chrome, Firefox), when a file upload is attempted, the flash player will not pass the OpenAM cookie. I need to find another way to do this. Is there any way to use OpenAM when cookies are disabled?
Not by default, but you may be able to modify the OpenAM source code to do so.
From the OpenAM mailing list:
if you check out the source code of
SSOProviderImpl#createSSOToken(HttpServletRequest) it looks like there
are methods trying to get the session id from the request
parametermap, so IMHO you should be able to post the
cookiename=cookievalue along with your file, or put the session ID on
the querystring (but that will be logged in the container access
logs...)