I have a self-hosted WCF service, which is available from all computers of the company. This has a standard landing page ("You have created a service. To test this service..."). I want to make sure that this landing page and the WSDL links on it are only accessible from the local server, as the information contained there could potentially be a security risk.
What is the easiest way to make sure that any URL that is not tied to a service is only accessible from localhost?
Please note that I do not want to change the contents of the landing page, as the WSDL links are useful for developers.
I am interested in solutions that involve modifying the app.config or limiting access via code.
As far as I know you can't selectively grant access to WSDL/Test WCF pages only by config or code. You can disabled it or not.
You could implement some sort of rules at IIS level to prevent access from non local addresses, but would make the question more suitable for Super Admin, probably.
If WSDL and/or service description pages public are secutiry issue, though, maybe you need to rethink your services security. Methods should be secured by authentication/authorization of some sort (usually via tokens). If anyone can post to your method and run code without proper authorization, having the interface description public is the last of your problems.
PS: if needed for devs, you can generate static versions of WSDLs to be served from user/password protected path.
Related
I have an application for managing user data. All the business logic is encapsulated within a separate web api service, which the user management web application (among others) calls into. At the moment all web api calls are exposed (they are anonymous). However the web api sits on a separate domain and is only accessible to the applications that call into it.
Is there any benefit to adding bearer tokens and enforce authentication for each API call?
If the web api service is on a separate domain and adequately protected from the internet, then you dont need to authenticate at the service level for external security (over and above any application logins you have).
However, that is not to say that your application is not internally exposed and could be intentionally or accidentally called by malicious intent or an incorrectly configured application, for example, someone accidentally points a load test at production. For this reason I would secure it, at least with a HMAC if you dont want to implement full blown authentication.
EDITED: To add that with any public facing web real estate you should classify your data and decide the appropriate level of security to apply. In some circumstances you may not want to secure GETs of low sensitivity data. On the flip side, exposing GETs allows someone access to try denial of service attacks (by calling your API in a loop from multiple servers / a botnet). When it comes to POSTs, the risk is higher, since consumers will be inserting in to your datastore.
It's also always good to keep the OWASP Top 10 in mind when dealing with security.
In our WCF Web service, we recently solved a customer's problem by adding <serviceHostingEnvironment multipleSiteBindingsEnabled=”true”> to the application's configuration file. This allowed the service to operate correctly, when IIS was configured with multiple bindings for the site containing the Web service, meaning that the Web service had multiple base addresses.
The question now is whether this setting is a good idea for all installations of our product. Does it have any downsides? If not, why is it not the default in WCF?
I have done some Web-searching and found multiple people explaining reasons why one should include this setting, but the only downside that I found was to do with "relayed endpoints", which are a concept with which I am unfamiliar and therefore something that I don't believe we are using.
I dont know what problem you solved enabling multipleSiteBindingsEnabled however if you are using multiple base url e.g. one for external users and one for internal users and you want to keep one of urls secrete then enabling multipleSiteBindingsEnabled will defy that purpose as all base address will be listed in WSDL/MEX information generated by the service. This could be one flip side of enabling multiple site bindings.
This seems like a duplicate question - but after hours of search, it seems there is no clear question-answer which summarize the issues i'm raising here.
We have a web application (built using asp.net MVC4) which stores customers sensitive customer information.
We've decided to migrate our entire application to https.
My question is, except for the IIS and certificates technical issues, which we've already know how to deal with, what should be changed on code level?
What will happen for instance for:
Included external scripts containing http, such as: http://code.jquery.com/jquery-1.7.1.min.js - will it work automatically without any problem and popup messages or blocking on the client browsers?
Internal links, which we've forgotten to change, which redirect to our site using http?
Images/Sources which have http in their URL.
Should we change all references from http to relative, or just specifying // without the http/https protocol ? (as seen on other posts on this subject)
Should we do nothing, will it happen automatically?
Is there a way to do something in IIS or Global.asax etc, in order to automatically take care of all http leftovers?
What else should we take in account when migrating to https?
Thanks in advance.
For all internal static resources hopefully you have used #Url.Content helper and for all internal dynamic resources you have used #Html.ActionLink, #Html.BeginForm, ... helpers to generate the links. This way you don't need to worry about anything.
For all external resources you could use // syntax in the link which will respect the protocol.
Since you are switching to HTTPS you might consider marking all your cookies (if any) with the secure flag to ensure that they are transmitted only over a secure channel.
I have a challenge and I believe there is a developer smarter than me that can provide some insight.
I have a web service. This web service is written with ASP.NET MVC in C#. I want to allow developers to call this web service. When developers are writing code, I recognize that web apps typically run from localhost. When they call this service, I want to be able to identify if the request is coming from localhost. However, if I look at the IP address, its the IP address of their machine.
Is there a way for me to even do this? Clearly Request.IsLocal won't work as my web service is running on an entirely different machine.
When you call a web service, the browser usually passes the page in the Referer header. So you can check if that value starts with "http://localhost". Virtually anything in an http request can be forged (including this), so be careful what kind of decisions you make based on this data.
Without passing some additional data along with the request from the app, there's not going to be any way for you to know.
You'll only be able to get the IP address or Host name that was used to make the request to your Web Service and it sounds like you want to be able to find the Host Name (localhost) that was used to make the request to the app (which then triggers the call to the Web Service).
How will you then define local (from the perspective of your service)? You'd be better off setting up a development service on a different API end point instead of attempting to guess this.
All production level API calls can go to something like api.yourservice.com with all development level requests coming in via dev.yourservice.com.
You can then have two separate services or have your service read the URL being requested and differentiate based on this.
I'm building a complex, public web service in WCF that send email to a specific address, similar to a contact form but with some features.
With jQuery I get the data from the textbox and with Ajax and json I send to the web service the strings to proceed at the send.
Now, is there a good way to make it secure?
I mean.. the service is public so someone can have access to it and starting to spam on this address. Can I restrict the users to use the web service only from the correct web site?
Thanks.
IF the WCF service is hosted in the IIS you can allow calls only from a specific IP address, look at the directory security settings under IIS.
By far the simplest way is to have your web service require some type of access key in order to run the operation.
Something simple like a base64 encoded GUID would work. It doesn't even have to change. Just add a parameter called "AccessKey" or something similar. Have your app pass that and let the service validate that it is good.
Another idea is to have the web service check the http headers to see if it came from the page you authorized to use it.
Neither of those are perfect. The first one means that your "key" will be inside the html you send to the client. The second one can be spoofed.
Personally, I'd probably not bother at this level and just log what the service is doing. If the traffic counts to the service start to exceed what you think it ought to be, then I'd investigate ways to mitigate it. Most likely, given that it's a service you won't see any issues.