I want to secure my application using access token while communicating to the server.I am using nginx server which logs all the headers which are present in the request. It is a security threat if we are logging the header. If somebody can access the logs file. They can easily manipulate the data. Then why people use token in header?
In this case can we consider payload as the right choice?
What is the best place(or standard way) to put access token : Header or in payload?
What are the pros and cons of both?
IMHO, it is mainly a matter of taste, and of tools you use for testing ...
If you use elaborated tools, that allows you to set custom headers, header is nice, because it does not clutter the payload. But if you want to be able to test with a simple browser, if is easier to add a request parameter than a header ...
You can even accept both, first looking in the header, and then in payload if you could not find the token in header.
Related
I am asked to maintain security for web-API(will be clarified in a minute), but the problem is I am not allowed to make any structural changes, that is using any kind of token-based or user-based authentication is not possible. I offered to use CORS, but both mobile and web application use the same service, so this is not an option as well. The bottom line is I want to make the service secure with minimal changes.
you could use a secret apiKey, and then for every api call you take the entire body of the request, add "- apiKey" at the end, and run it trough a sha1 encryption (or simmilar one way enryption) then you put the result as "checksum" in the header
on the serverend you do the same thing, take the body of the request, add "- apiKey" and run it trough the same oneway encryption, and hten compare the result to the checksum in the header of the resuest. if the strings matches you allow it, otherwise block the call.
this is not too much to implement, and it doesnt really change anything about the structure, but if this is too much "changes" so you are not allowed, then the only other option is using firewall to only allow certain ip addresses.
The token approach is advisable as there isn't much structural change. You need to add a middleware, where all the API calls hit, and there you perform a token validation. Orrr you could use cookies to secure your endpoints
The x-requested-with header is kind of confusing to me. I know it can be used to defend against CSRF attacks, and that it is used to identify Ajax calls...but what is it really?
It just tells you what the request was...requested with?
Could there ever be a reasonable situation in which the header is present but set to some value other than "XMLHttpRequest"? I would imagine so, but I've never seen it set to anything else.
Just like the User-Agent header, it is provided by the client and can contain literally anything.
It is not at all reliable for any server-side security check.
Android sets X-Requested-With to the package ID of the app, for third-party apps that use the WebView component to embed a browser into their UI.
Presumably this could be used for debugging and/or statistics, but the values cannot be trusted because it would be possible for an attacker to write a custom client that sets it to anything just to try to break your server.
I am using form authentication and role based access.
I want to make all the subsequent request as an authentication request using the access token.
I refer Loopback-example-access-control example, but not get a clear idea.
In this example, they pass access token using query string. My question is I want to make all the request as authenticated using access-token without pass query string or header.
Any other alternative way is available?
I need demo application that includes authentication and authorization, except loopback-example-access-control example.
Please help me, I am new to strong loop.
There are only three ways to send data to a server: path/query string, headers, and the request body. Since you don't want to use the query string (which is good, you really shouldn't) and you don't want to use a header (which is the most common and currently the industry standard) then you are left with only the request body. That's not a great choice either, and not supported by default in LoopBack, you would have to code that up yourself.
The right solution here is to use the Authorization header and send the access token in there with each request.
And just to be clear, this really has nothing to do with LoopBack, this is just token-based authentication basics. You must pass the token with each request, that's how the system works, there is no alternative.
I'm a bit naive about how to send cookie data between servers. I am aware that in the HTTP request you use Set-Cookie.
Right now, I am sending a header between the servers, for authorization purposes, so that one server is authorized with the other. But I am wondering if there is some advantage to using cookies, if cookies act differently than headers in this case. From what I have read, cookies and headers are one and the same for most purposes?
Using two Node.js servers, one being the web server, the other being the API server, is there any reason why sending a cookie vs a regular non-cookie header is better?
The "cookie" represents shared state between the client and the server. As was mentioned, the way to set cookie values, is to use the Set-Cookie header. And the way to communicate values that have already been set is to use the Cookie header.
Cookies are typically associated with web browsers, as tool to track and identify existing users. I've never seen cookies used for server to server communication.
The Authorization header is good for passing encoded or encrypted strings.
So for example you might see:
Authorization: "Basic dXNlcm5hbWU6cGFzc3dvcmQ="
The value in this case is the base64 encoded string of "username:password"
I wouldn't worry too much about what header you use. You can make up your own x-my-awesome-auth-header: Its conventional to prefix a custom header with an "x".
An important thing to consider, is what the header value contains. If you are communicating over plain http make sure you encrypt.
Also consider using open source standards for passing encrypted data such as JWT
Edit: To answer your question, is there any reason why sending a cookie is better? When it comes to server to server communication, its actually much worse to use Cookies, because those servers have to maintain state with other servers. eg. When A talks to B, A has to remember what B said when they talk again. You typically what server to server communication to be stateless, meaning you can throw away data pertaining to authorization and permission after each transaction. Each transaction has to go through the full authorization and permission resolution process. Its much easier to code, and there is no penalty in terms of security as long as your are protected via encryption
Yes, "cookies" is just jargon for the Cookie: HTTP header and corresponding Set-Cookie: header. So they are ultimately the same basic thing. Many APIs use the slightly more semantic Authorization: header, so that would be a good place to start.
I’m designing a REST service that needs to be well secured against unauthorized access. I’m thinking about requiring a security digest that’s generated by hashing all request parameters plus a secret key with sha-256 and making the service only available over https. Can anyone tell me if this is sufficient security?
First of all, make sure you are using en HMAC, not a plain SHA-256 to generate the "security digest".
Next, what are you going to put into the input of this digest? You'll want to have at least the method, the URI, the payload, and very possibly most of the headers of the request (there are many headers that affect the meaning of an HTTP request that are important in a REST context). That might be difficult depending on what HTTP client you are using because the client might set or change headers in a way that you do not directly control.
Finally, where are you going to put this digest? A custom header (e.g. X-Request-Authenticator) seems sensible, or maybe a cookie if the client is running in a web browser.
I would recommend using existing tools if you can, instead of creating something yourself. Using SSL already gives you message integrity protection so start with that. Then, if you just need simple access control, HTTP basic auth will work just fine with a REST request. Or you could have the client present a certificate and verify it.