I am working on web application that has angular 4 on frontend and WEB API on backend. This application is hosted on MS Azure and until now we didn't have any issues.
Currently we need to integrate with one payment provider. During payment user is redirected to his payment page, and if everything goes well user is redirected back to our web site. Beside the browser redirect (which may fail) payment provider supports server to server call (HTTP GET). In this way they make sure we get information about the transaction. The problem here is that instead of one call to our Web API backend we get always two calls. After checking the request origin IP addresses I concluded that there is two origins (one is payment provider address and another is IP located in USA, which I assume belongs to MS). This looks to me like a routing problem, but I am not very experienced at this.
Did anybody have similar problem on Azure while hosting web application ?
According to your decription, it seems that fails for cross domain request. Azure website is supposed to manage CORS for you.
I think you missed a handy Azure website blade: Specify the origins that should be allowed to make cross-origin calls (for example: http://example.com:12345). To allow all, use "*" and remove all other origins from the list. Slashes are not allowed as part of domain or after TLD.
Cross-Origin Resource Sharing (CORS) allows JavaScript code running in a browser on an external host to interact with your backend. Specify the origins that should be allowed to make cross-origin calls (for example: http://example.com:12345). To allow all, use "*" and remove all other origins from the list. Slashes are not allowed as part of domain or after TLD.
Related
I've developed simple REST API using a expressJs. I'm using React as my client side application. So the problem is anyone can see my API endpoints because of react app is in client side. So they will also able to make request and fetch data from my REST API. (May be they will build their own client side apps using my API.) I've seen some question about this and couldn't find any comprehensive answer. How these kind of a security problem should be handled? Is it possible to give the access for API to only my client app? If not how huge brands that using REST API prevent that? (Also I don't have a user authenticating scenario in my product as well. People can just visit and use the website. They don't need to register).
Authentication can be a way but it can be bypassed. Another way is you can create a proxy server which strictly blocks cross origin requests, hence it blocks requests from other domains to make request to your API, and you can make your API call from that proxy server. In this way your API server endpoint will also be not compromised.
If, as you state in your comment, this is about users on your own website being allowed to use your site's API, while disallowing off-site use (e.g. other websites, wget/curl, etc) then you need to make sure to set up proper CORS rules (to disallowed cross-origin use of your API) as well as CSP rules (to prevent user-injected scripts from proxying your API), and you also make sure to only allow API calls from connections that have an active session (so even if you don't want user authentication: use a session managemer so you can tell if someone landed on your site and got a session cookie set before they started calling API endpoints).
Session management and CORS come with express itself (see https://expressjs.com/en/resources/middleware/session.html and https://expressjs.com/en/resources/middleware/cors.html), for CSP, and lots of other security layers like HSTS, XSS filtering, etc, you typically use helmet.
I have set up an Azure Frontdoor Load Balancer with 2 backends, hosting an Angular app. When looking at the network traffic in the browser's developer tools, I see that only the first few requests for *.html and *.js files go to the loadbalancer. Beginning with the GET options request, all subsequent requests seem to go directly to the backend #2 (in red in the picture below):
This means, if the backend #2 goes down, the client gets 404 errors, and won't be automatically redirected to backend #1, unless the user reloads the browser window with F5.
I'm not sure how the Angular app gets the actual backend host's URL. I cannot see any header or cookie which would provide this information. The headers of the first request for login.html look like this - no sign of the backend URL anywhere:
My questions are
how does the client get the backend host's URL?
is there a way to define that ALL requests go through the loadbalancer?
Would that even be a good idea? Or is this the "intended behaviour", meaning that the user WILL see 404 errors and have to reload the page manually?
It the application that is doing it, not the azure front door. The app must be constructing the url based on where it is hosted and them making a request. The front door will set the host header same as the app service's hostname. In that case, the application would see it's request to come as if the user typed that in the browser. You would typically want to use custom hostname e.g. neonapp-dev.yourcompanyname.com. When you do that both app services and the front door would have the custom host configured. While configuring the front door, you would use this as a host header rather than the default which is app services host name. Then everything would work fine as the app would never see the app services name as host header.
More details https://learn.microsoft.com/en-us/azure/frontdoor/front-door-backend-pool#backend-host-header
I want to only allow users from my own IP and two domains which would cover the client's intranet and external secure website. Should I be doing it in web.config? Azure itself?
Thanks for the help :-)
The mechanism to control which referral domains are allowed to access resources in your Azure Web App, or any other HTTP endpoint for that matter, is called Cross-Origin Resource Sharing (CORS).
CORS is an IETF standard (RFC6454) and is supported and configurable for any Web App / App Service. However, it will not help you in what you are trying to achieve.
Web browsers nowadays operate what's referred to as same-origin policy. This is where a browser will only fetch resources from the same domain present in the address bar. Why? It's really a security mechanism designed to protect the user against cross-site scripting (CSS) attacks, where a malicious actor may craft scripts to make calls to websites a victim is currently logged in to, where their cookie will automatically be sent to the server to sign in, thus being able to carry out activities as the victim. CORS allows developers to permit cross-origin requests safely by white-listing particular domains which are allowed to access resources.
CORS should not be used a mechanism to restrict access to a site. Neither should the referrer HTTP header be used when locking down access to a website, since this can easily be spoofed. Further, CORS operates on an honorary basis meaning that, should origin be indeterminable, the request will be allowed, as it is assumed that the request is same-origin, or initial.
What you are looking for is IP restrictions. Azure Web Apps support IP restrictions. In the portal, navigate to your Web App -> Networking -> IP Restrictions. This area will allow you to configure IP addresses or ranges that are allowed to access the application. You will need to create a rule allowing your IP address and addresses relating to the "referral domains" in question, which demands that the users are coming from known addresses.
So, to answer your question, it should be done in the portal, and you should use IP restrictions.
I'm new to Web API, HTTP and security in general, but I just want to know if this is possible: for a controller to relax security requirements when the HTTP request originated from within the local area network.
My particular application has very low security requirements for clients inside the firewall. For instance, I want internal client apps to be able to make requests of controller actions marked with [AllowAnonymous] so that they don't need to deal with OAuth, etc (which just seems like complete overkill for my internal use scenario).
However, if the same controller actions are available to the public Internet, of course strict security requirements should apply.
Can security be handled differently based on origin? Or is the standard practice to expose both a public-facing and an Internal API?
When you use the [AllowAnonymous] attribute on your controller or action, you tell ASP.NET that it should not check the user's identity at all. That is not what you want for users coming from the internet.
You could remove the [Authorize] attribute from your controller and manually check inside the action if the user is authenticated using:
if (User.Identity.IsAuthenticated || IsLocalUser())
{
// action implementation
}
You can implement this check in a custom authorization attribute.
This still leaves you with the task to determine whether the user is local or coming from the internet. You could check the client IP-address to determine this of course.
Another option would be to enable both Windows authentication and bearer scheme authentication if your local users are part of an Active Directory domain.
Users from your intranet could use Windows authentication to talk to the service, while internet users need to bring a JWT token. This would only work if the client application for users coming from the internet is different than for local users.
DISCLAIMER: I've never tried this last option.
Identifying a request as one from "inside the firewall" isn't always as simple as just investigating the IP address. Although, this may work for you now, it may make it difficult to move environments or modify the environment without affecting application logic.
I would recommend developing a simple middle layer application that simply has the job of calling your main application with enough authorization data to handle security in the same context as your regular app, but this middle layer would in itself not be authorized. You will then just have to make sure that this app is not accessible to users outside of the firewall.
I am currently developing an API that will be launched into production in a matter of weeks. I am relatively new to REST, started reading about CORS - and realized that it could impact me.
What conditions will a REST service not be accessible to a client? I have been using sample html/js on the same server, and through Postman - a google chrome addon - to access my API. I have had no issues so far.
When the API goes live, it will be hosted at 'api.myserver.com'. Requests, at the beginning, will come from 'app.myOTHERserver.com'. Will these requests be denied if I do not use a CORS-friendly approach like JSONP or special 'access-control' headers that permit my domain?
What about accessing rest APIs from other non-browser clients? Such as a C# application? Are these requests permitted by default?
Assuming I do need to add 'access-control' headers server-side, to permit the scenario described above when my API goes live, is it better (performance-wise) to let your web server (NGINX in my case) handle the headers, or should I add them through PHP or NodeJS?
This is more about the same-origin policy applied by web browsers than it is about RESTful APIs in general.
If your API is intended to be used by web applications deployed on a different origin host/port than the API, then you have these options:
Respond with appropriate headers that allow for techniques like CORS to work.
Have the web server which serves up your web content (in your example, app.myOTHERserver.com) handle your REST API requests too by proxifying your API requests from the web server through to the API server. For example, you could have your API exposed on your web server under the URL /api, and then it's just a matter of setting up a web proxy configuration that forwards requests under that URL to your API server.
Use JSONP or other techniques.
If your API is going to be used by non-web applications, you have nothing to worry about. This is only a restriction applied by browsers when running JavaScript code to make sure that the user hasn't inadvertently clicked on a phishing link with some hackery in it that tries to send their PayPal password to Pyongyang.
When the API goes live, it will be hosted at 'api.myserver.com'.
Requests, at the beginning, will come from 'app.myOTHERserver.com'.
Will these requests be denied if I do not use a CORS-friendly approach
like JSONP or special 'access-control' headers that permit my domain?
You can specify what clients can access your web service to an extend. Assuming you're using Express: How to allow CORS?