I am relatively new to OAuth, and I wonder why the access-token is passed around in query string parameters in OAuth2.0, given that this may get saved in browser history as plain text.
I understand that the query string parameters are transported over SSL and cannot be possibly intercepted. But, once they are in browser cache/history, aren't they plain text, and accessible to other programs?
If so, why is OAuth2.0 defined this insecure way?
Related
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.
Is it safe to put a jwt (json web token) into the url as a query parameter of a GET request?
It can be safe under the following circumstances:
the JWT is one-time time usage only
the jti and exp claims are present in the token
the receiver properly implements replay protection using jti and exp
but in case it is used as a token that can repeatedly be used e.g. against an API then supplying it as a query parameter is less preferred since it may end up in logs and system process information, available to others that have access to the server or client system. In that case would be better to present it as part of a header or a POST parameter.
Besides that, by using it in the query parameters you may run in to URL size limitations on browsers or servers; using it in a header provides some more space, using it as a POST parameter would work best.
Is it safe to put a jwt (json web token) into the url as a query parameter of a GET request?
Yes, insofar that a JSON Web Token (JWT) is encoded in a way that it is transparent with the encoding of a query parameter in an URL:
A JWT is URL-encoding-safe. There will be no data-loss when used in-place; no additional encoding is required; it is even URL encoding safe inherently, applying url-encoding (percentage-encoding) on the JWT multiple times will not destroy it.
This safety is limited:
There can be a data-leak when used in-place if the URL itself is part of such a data-leak. By how URLs are commonly in use, you should treat any JWT in an URL query parameter as-if the data-leak already happened and therefore prepared the JWT for it already (e.g. prevent replay attacks).
And it will be at best as safe as the transport of the URL information is, and never more safe.
And if the transport of the URL information is not safe, everything in the URL can never be more safe either, which includes the JWT when used as a GET parameter.
Apart from using it in an URL (which looks to me as a mechanism of transport), you may want to consider additional data-retention, protocol and even your own systems properties, including those of the JWT in question itself.
For all these it depends.
For some of those considerations, please see the other answer and JSON Web Token (JWT) - RFC-7519 incl. the referenced updates there.
I'm using basic auth over SSL for CouchDB, and I was wondering, if there are symbols in my password, how do I get it working, and not colliding with the url in general?
For example: https://username:p#$$word#couchdb.domain.com/db
Any help would rock!
Basic auth uses the Authorization header in the HTTP request to pass your user name and password, not the URL. The URL you have posted is a shortcut supported by some browsers (in which the browser converts the username/password in the URL into the appropriate headers). The URL format is not actually part of the basic auth spec (see the RFC for more complete details: https://www.ietf.org/rfc/rfc2617.txt).
With that out of the way, yes, basic auth supports symbols and you should not need to worry about whether or not those symbols have special meaning in a URL. However, the basic auth spec is ambiguous when it comes to charsets and contains no way to specify which charset is being used to encode the user name and password. As a result, any character outside the 7 bit ASCII range may cause issues dependent upon the server side implementation.
According to the Basic Authentication RFC:
To receive authorization, the client sends the userid and password, separated by a single colon (":") character, within a base64 encoded string in the credentials.
I don't understand why you feel you must send your credentials in clear-text as part of the URL, when the official Couch DB documentation clearly suggests a more standard way of authentication.
I am a web application newbie. I know that XSRF protection questions have been asked in SO but the questions have been specific to a particular language (RoR/Python for example) or a library (jQuery). I would like to know how I can implement XSRF protection in my web application.
My understanding is that XSRF protection relies to using a unique random token that must be authenticated when a HTTP request is made. I have the following questions:
When should the authentication token be initialized? Should it be set on page load (i.e. GET request)?
Where should the token be initialized? Should they be set in input fields, cookies or request headers? How is this random value generated? How do I persist this value in order to be used for comparison?
When should the authentication token be verified? How does I compare authentication tokens? How do I compare these tokens with the token that I have persisted?
Is there a difference in the set up for a synchronous form request versus an AJAX request?
When should the authentication token be initialized?
The first time, during a session, that the user arrives at a page containing any form that you wish to protect from CSRF attacks.
Should it be set on page load (i.e. GET request)?
It should be embedded in the form when the HTML for it is generated.
Should they be set in input fields, cookies or request headers?
Hidden inputs.
Using a cookie would miss the point (which is that it comes from the page and does not persist in the browser). Extra headers can only work when using XHR, use a general approach.
How is this random value generated?
With a random number generator
How do I persist this value in order to be used for comparison?
Sessions
When should the authentication token be verified?
As part of the authorization step.
How does I compare authentication tokens? How do I compare these tokens with the token that I have persisted?
if ( $request->paramaters->{csrf} eq $session->data->{csrf} )
Is there a difference in the set up for a synchronous form request versus an AJAX request?
No. You still have a session and you still have a piece of the POST data being the token.
I'm not going to talk about a specific solution that you must follow as there are many, I'll talk about the main idea instead and you could implement it however you want.
The key idea to prevent XSRF is to store a random token in a place where code from other domains cannot access (such as a cookie). You could generate this token on server side and instruct the browser to store it locally for the entire session. (don't need to persist anything on server side)
Whenever you perform a request, send:
the token in your storage (if you use cookie, the browser will send it automatically).
the same token as the stored one in your request (whether as a header or in body using hidden field depending on how server code gets it)
On server side, the server will check for a match.
A sample code in jquery (with jquery cookie plugin):
$.ajax({
url:"someurl",
data:{token:$.cookie('token')}
});
The ability to read the cookie proves that this is from your domain, not external domains
There are various ways to implement this mechanism (don't need to stick to a specific solution) as long as they stick the the main idea:
Storing a secret token on browser in a place code from other domains cannot read it.
Send the secret token and the same token from browser to your server. The ability to send that same token proves that this is not a XSRF request.
How do I persist this value in order to be used for comparison?
We could store it as a cookie or as a session variable. Personally, I prefer cookie because:
Reduce memory consumption on server side.
We don't need to include that token in every generated HTML file in order for the browser to send it back.
Is there a difference in the set up for a synchronous form request
versus an AJAX request?
No, as long as you could prove this is not a XSRF request by sending the same token in the request. It does not matter where token is (a hidden field, a custom header,..). In case of Form, people usually send it as a hidden field.
I don't know if the title is clear enough, anyway what I need to do is quite simple: I have some content you can access by an API call on my server; this content is user-related so when you request access to it, you must first wait for the owner to authorize you. Since this content will be probably embedded into blog articles or form posts I want it to be accessible only from the URL the user authorized to.
The only way that came to my mind is to check in some secure way where the request is coming from: the problem with this approach is that anybody could create a fake request, using a valid URL but coming from a non-authorized URL actually.
I'm looking for a way to solve this problem, even if this doesn't involve checking the actual URL but using some other approach or whatever. Feel free to ask any questions if this is not clear enough.
With Sessions:
If you generate a secure token, most languages have libraries to do such a thing, you will have to persist it probably in a session on your server. When you render the page which will access the other content you can add that token to the link/form post/ajax request on the page you wish to be able to access it from.
You would then match that token against the value in the user session if the token doesn't match you return an error of some sort. This solution relies on the security of your session.
Without Sessions:
If you don't have sessions to get around server persistance, you can use a trick that amazon s3 uses for security. You would create something like a json string which gives authorization for the next 30 seconds, 5 minutes, whatever is appropriate. It would need to include a timestamp so that the value changes. You would use a secret key on your sever that you combine with the JSON string to create a hash value.
Your request would have to include the JSON string as one request parameter. You would need to base64 encode it or some other means so that you don't run into special characters not allowed over http. The second parameter would be the output of your hash operation.
When you get the request you would decode the JSON string so it was exactly the same as before and hash it with your secret key. If that value matches the one sent with the request it means those are the two values you sent to the page that ultimately requested the content.
Warnings:
You need to make sure you're using up to date algorithms and properly audited security libraries to do this stuff, do not try to write your own. There may be other ways around this depending on what context this ultimately ends up in but I think it should be relatively secure. Also I'm not a security expert I would consult one if you're dealing with very sensitive information.