This project is on nuxtjs.
I don't think is important but maybe it can be some clue.
I need to get order detail information for using axios and below url.
/users/orders/d/20210806000349
but, very weird because axios doesn't request without cookies that url
of course i do set withCredentials: true already
when i change that url to /20210806000349 everyting is okay
someone help me about this?
I need more detail about domains but maybe api domain and nuxt domain are different. in this case you should care about CORS.
what is CORS
Cross-Origin Resource Sharing (CORS) is an HTTP-header based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading of resources. CORS also relies on a mechanism by which browsers make a "preflight" request to the server hosting the cross-origin resource, in order to check that the server will permit the actual request. In that preflight, the browser sends headers that indicate the HTTP method and headers that will be used in the actual request.
MDN
what happen if you request to foreign domain?
user agent send an option request to foreign host
foreign host send response whit some header
user agent looks to Access-Control-Allow-Origin header and if its value is not equal to your domain block request
if request's withCredentials be true look at Access-Control-Allow-Credentials header and if its value be true send request with cookie. otherwise send request without cookie.
figure out myself
get request also preflight options request if domain is different
but in this case chrome doesn't show up options request
i check this on firefox
Related
I have rest api which is publicly available with REST API key authentication, but I want to allow private network to access api without authentication. Is it safe to add global CORS
Access-Control-Allow-Origin: *
Note that I am doing authentication in haproxy:
acl private_ip src -m reg -i (^127\\.0\\.0\\.1)|(^10.*)|(^172\\.1[6-9].*)|(^172\\.2[0-9].*)|(^172\\.3[0-1].*)|(^192\\.168.*)|(^::1$)|(^[fF][cCdD])|(0:0:0:0:0:0:0:1)
I read that setting CORS "*" could cause some security issues in case when there is IP authentication, but as I am not sure how "src" IP address in haproxy is obtained I can't be sure if this security risk is present in my case?
It is strongly recommended against to use IP authentication and a permissive CORS policy together.
CORS allows for script on a page served from one host to process a response from a call to a resource on another host when normally a well-behaved browser would stop script on the page from reading the response. For example where a page on webserver.com includes an AJAX call to a resource on api-server.com.
CORS is enforced by the browser, so if your attacker can make a call to your API then they are able to ignore your CORS header, and this is transitive to anything they can get another user to do by serving them a malicious page.
API authentication (whether by token or by IP) is a server-side protection that allows you to filter your response to the request. Consider the case where your attacker has access to your network. They can make a request to your API and your IP authentication lets them get the data. CORS is not the solution to that, but you of course secure your network well and only your users have access to it.
However, if the attacker controls a website (say, compromised.example.com) then they can send a user on your network a link to their page. When your user goes to the page, they are served a script that makes a call to your API. Because you permit the request based on IP, you provide the response.
This is where CORS comes in. If you have a header allowing '*' on your API responses, then the browser on your network will happily provide the requesting page (served from the attacker who is not on your network) with the response.
So the attacker has unauthenticated access to your API if they can get one of your network's users to browse to their malicious page and exfiltrate any responses that a user on your network can get.
When a response to a certain request is redirection, with status code 3XX and location header, it seems that the browser automatically redirects to the other page (by URLs included in location header).
But when I send the same request via cURL or postman, the response comes with the 3XX but no redirect occurs.
So I concluded that the redirection from the first case is not a basic response but an additional function that browsers.
If so where I can find the settings about this? If not, what is the main cause of this redirection?
The browser is trying to give the user a good experience. If the web site returns a redirect, then the best user experience is for it to go ahead and do the redirect. cURL and wget will also follow the redirects if you enable the option, but since those tools are mostly for diagnostics, the default is to have one request, one response. It's up to the consumer to decide what to do with that response.
I'm not sure what you mean by "basic response". The RFC does not require a redirect. The request receives a response, and it's up to the recipient to decide what to do next.
I am building an oauth login flow and I am not sure if I have done it wrong because I will need to send the bearer token back via redirect URL, like /oauth2/redirect?token=[TOKEN]. But isn't it not recommended to have token passed along through URL? As it is pointed out in this thread:
Don't pass bearer tokens in page URLs: Bearer tokens SHOULD NOT be passed in page URLs (for example, as query string parameters).Instead, bearer tokens SHOULD be passed in HTTP message headers or message bodies for which confidentiality measures are taken. Browsers, web servers, and other software may not adequately secure URLs in the browser history, web server logs, and other data structures. If bearer tokens are passed in page URLs, attackers might be able to steal them from the history data, logs, or other unsecured locations.
I must have missed something in the whole flow and would like to understand more about this matter. Any input is appreciated!
UPDATE
Might not be correct but this is my understanding after some digging. The three means to pass token:
URL (not preferable)
Auth header
Request body
But under the oauth redirect use case, option 2 and 3 not feasible. So option 1 is the only option available. If really needed, token can be encrypted to ensure security.
I think this only means, that you should not use a GET request when the server requires the token, instead you should use POST or whatever is appropriate. In a GET request the parameters are included in the URL and those can end up in logs or other histories, other request types will send the paramters separat from the request URL.
P.S. BTW if you are not implementing the OAuth server yourself, you won't have to send a redirect url containing the token.
The basic auth header which provides a little extra security as it's required to be through TLS:
In the case of a "Basic" authentication like shown in the figure, the exchange must happen over an HTTPS (TLS) connection to be secure.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication
Also, the headers aren't logged in easy places like browser history.
From the spec,
it SHOULD NOT be used
unless it is impossible to transport the access token in the
"Authorization" request header field or the HTTP request entity-body.
https://www.rfc-editor.org/rfc/rfc6750#section-2.3
I have a REST service that is already secured with basic authentication using the Authorization header. This is used to access the service in general and is required for any request. i.e. "User1", "password1".
I have a "file" resource which can have an additional password associated with it (i.e a password protected Word document, PDF, etc), "docpassword". What is the best way to send sensitive information like this? I'm especially interested in how to send the password for a GET request, but I'd like to have a universal solution that will also work for POST requests.
Maybe a custom header?
The HTTP protocol defines the standard Authorization header for sending authentication data (credentials) to the server. This header is defined in the RFC 7235 (which makes the old RFC 2616 obsolete and updates the RFC 2617):
4.2. Authorization
The Authorization header field allows a user agent to authenticate
itself with an origin server -- usually, but not necessarily, after
receiving a 401 (Unauthorized) response. Its value consists of
credentials containing the authentication information of the user
agent for the realm of the resource being requested.
Authorization = credentials
[...]
Please note that the name of this HTTP header is unfortunate because it carries authentication data instead of authorization. Anyways, this is the standard headers for sending credentials in the HTTP protocol.
Once you are already using the HTTP Basic Authentication Scheme to authenticate the users in your application, I believe you are already using the standard Authorization header.
I usually do not recommend custom headers, especially when the standard headers can be used instead, but your scenario seems not so common: You need to perform two authentications on the same request.
So, maybe a custom header such as X-Auth-Document or Document-Authentication with the document's password will be fine for GET requests. If you decide not using GET and decide using POST to access this resource, you can consider sending the document's password in the request paylod.
Anyways, don't forget using HTTPS: is highly advisable once you are sending sensitive data, such as credentials, over the wire. And HTTPS will protect you against the man-in-the-middle attack.
HTTP already has an authentication method, see for example this RFC: https://www.rfc-editor.org/rfc/rfc2617
Edit after clarification of question: There is nothing preventing the server to make additional challenges, even based on single resource basis. I must admit I did not implement such a thing yet, but each authorization can have its own realm. You could specify different realms, even down to document level if you really want to. The server then can potentially make multiple challenges in each realm (first login, then document). Remember, you can cache successful authentications, either on the client (for a realm, like a browser does), or giving out cookies with a cached token.
This would have the advantage of avoiding a custom header, and be completely HTTP/REST conform. There may be some performance disadvantage, but it could be mitigated with some targeted caching.
Of course you can go with custom header if you want to, but normally REST would imply that the client goes in with no prior knowledge other than mime-types and the HTTP protocol. A custom header implies out-of-band prior knowledge.
I need to integrate CSRF Prevention in our existing REST Service.
We have created many rest resources and published its detail for other developers to consume. Anyone in the organization can use it. I have no control how he uses it, the form he uses or the httpclient. I have no idea who has used it till date and I cannot change all the clients. Hence, I cannot add a hidden text fields/tokens to the form, since I do not have access to the clients. Also, I cannot use the double authentication or captcha, because it wont work with the httpclient implementations. Is there any other way that I can prevent the misuse of the REST service against CSRF.
You could do this by checking the X-Requested-With header.
If any web clients are already using JQuery, then this header will be passed automatically and ensures that the request is not a cross-domain request either by AJAX or by HTML forms. This header will not be sent at all for HTML forms, so this will work if no web clients use HTML forms.
If your web clients use plain JavaScript then you could check that the Origin header is set to a valid domain. Please note that some versions of some browsers do not set this when the request is not cross domain.
The only drawback is that non-web clients would have to set one of these headers, or that you have some way of identifying these non-web clients from your REST service so that you could bypass the checks in these cases.
If you non-web clients already send any headers other than the following:-
Accept
Accept-Language
Content-Language
Last-Event-ID
Content-Type
then you could verify the value is passed (instead of X-Requested-With or Origin) to ensure that this is not a CSRF attack as custom headers cannot be sent in a CSRF attack. Even the User-Agent could be used - this can be spoofed only by a HTTP client but not by an attacker inside a browser which is the only relevant place that a CSRF attack can happen.