When we access the WEB API service methods from a web application through Ajax calls, will there be any access restrictions for the following scenarios
“HTTPS” Web application accessing an “HTTP” WEB-API
“HTTP” Web application accessing an “HTTPS” WEB-API
Will there be any impact on request application or context, either it Http or Https the web API will behave same.
Please advice.
When you trying to access the "HTTP" Api or any service from the HTTPS or SSL enabled client, then the security itself is compromised.
SSL certificate is enable to maintain the higher level of security, in any HTTPS enabled client, when you access the Non SSL or HTTP ApI then you have to specify the Transport layer explicitly to allow the process of data [example IOS client - Application Transport]
Even if you have requirement to access the HTTP API, please go through this reference.
Make Https call using HttpClient
Related
I have WebAPP and WEBAPI on same server. I have applied SSL certificate on both the sites under same server (both are separate applications under common IIS default website).
Now my point, Can I access same WEBAPI over http instead of https form 3rd intranet application on same server and which is not a secure application?
My intention to not hamper performance for 3rd site which is not secured and on the same server.
Actually It depends on your configuration.
Generally, when you apply SSL on web server your app can now be accessed over http and https both connections.
But, if you have configured it to redirect http version to https using CSP or server end configuration, then you can access http version as all requests will get automatically redirected to https version.
You should read IIS related materials to learn what is site binding. A web site can of course contain multiple bindings, both HTTP and HTTPS, so that clients (like web browsers) can access using both http:// and https://.
https://blogs.technet.microsoft.com/chrad/2010/01/24/understanding-iis-bindings-websites-virtual-directories-and-lastly-application-pools/
Is it possible in Silverlight to create a proxy client, meaning the Silverlight application knows the host, port, username and password of the proxy server, then establishes a connection to the proxy server?
The Silverlight application would then be able to issues HTTP requests to resources behind that proxy server.
This way, the Silverlight application would reach certain resources without having to install a thirdparty proxy client on the client-machine first, because the proxy client would be part of the Silverlight application itself.
I use the WebClient to issue HTTP requests from Silverlight.
WebClient has a Proxy property, but not in Silverlight.
So I made a webservice, that takes an url and some proxy-server information. The webservice uses the WebClient and the Proxy property to direct the HTTP request to the proxy-server.
Then the Silverlight application calls that webservice, gives it an url and some proxy-server information.
I have several Web PI endpoints currently secured with an access key. I'm not opposed to abandoning this security model.
Now, we're building a web app that will consume the services. The front end will have a login screen to secure portions of the application. I also want to make the Web API services available for use by applications other than our own (think public API).
How should I secure my services and allow access from our own web UI and as a service?
There are many ways to secure Web API 2.0 endpoints.
It seems like you already secured your endpoint with an access key, no idea how your clients know the access key.
For your web app I would ask:
How is the user logging in as you described? What authority are they providing their credentials to? Can you use that authority to attach a token to the requests of your web service?
You mention you also want to provide a public access through a public api. What credentials will they have? What authority will they request access from? You could set this up many ways with different types of credentials e.g. user name and password/client certificate/access key.
Microsoft has some really good resources about this including:
http://channel9.msdn.com/Shows/Web+Camps+TV/Securing-ASPNET-Web-APIs
http://www.asp.net/web-api/overview/security
I can think of:
HTTP Basic Authentication
OAuth/OpenID Connect
Client and Server Certificates
Firstly, I'm relatively new to Web API / CORS and security implementation.
This question is specifically with regards to security. The Web API houses extremely sensitive data and provides clients with the ability to execute transactions online.
The context :
I have a Web API self hosted as a windows service with a fixed port.
The Web API is sitting behind a firewall / DMZ on an internal network.
The Web API (using CORS) only allows traffic from the external server.
The external server hosts our web site using IIS.
The Web API is making use of Token authentication (bound to client IP to avoid hi-jacking).
Both the external website and internal Web API force the use of SSL.
The problem :
The web page makes ajax calls via javascript to the Web API. However, the Web API is not directly exposed to the internet.
What would the security impact be on having the below setup?
What sort of vulnerabilities would I be exposing my network too by doing so.
Is there a better way of implementing such a setup!?
Eg
User enters https://test.mydomain.com into the browser and is served a page.
ajax call gets made to https://test.mydomain.com/api/test/action
external server routes https://test.mydomain.com/api messages to internal server https://myInternalWebAPI/api/test/action which is not exposed to the public.
So this requires a little bit of leg work, but it's implemented into a production environment so I thought I'd share the solution.
I created a WCF service and a WebAPI.
The primary WCF Service resides on the internal network and contains all the business logic, database connectivity.
The proxy WebAPI mimics the WCF service structure and is exposed to the public.
The proxy WebAPI is called from the client (javascript), the proxy WebAPI then calls the internal server hosting the WCF service and voila, victory.
We have a Windows app hosting a WebBrowser control that hits our REST APIs. We like to restrict access to the APIs to be only coming from withing the Windows app itself (for example, the APIs cannot be accessed in a browser, etc).
How can we accomplish that? what is the most secure way without having to expose any kind of credential (for example, if we use HTTP Basic auth, the username and password can be seen by reverse engineering the app itself)?
Thanks a bunch!
EDIT: We plan to distribute the application freely so we have no control over where the connection will be made from.
Restrict the REST interface to only accept connections from 127.0.0.1 (home) and then connect from your rest-consuming application only with http://localhost or http://127.0.0.1 in the URLs (if you use the external IP or DNS name of your machine it'll be treated as a remote connection and denied access).
You can do this with web server settings, or within the code of your REST APIs
I had a similar situation during a project where we distributed an iPhone app that also connected to a REST api that my team developed.
For security we used somewhat of a three-legged scenario. The app was required to authenticate using the user's credentials against a standalone service responsible only for authenticating and generating access tokens. Once the app received a valid access token, subsequent requests to the api required sending this token in the Authorization header.
You could do something similar. If you come up with a credential scheme to authenticate your app as valid API consumers you could use basic auth over HTTPS to obtain tokens, and then only by using those tokens could a consumer gain access to the rest of the API.