I have a Web Service (ASMX) with a few Web methods on our production Web server. On a separate internal Web server (which isn't publicly exposed) I have another Web site that will use the ASMX's public web methods. What are some of the best ways to secure the Web service such that only the internal Web server can access the Web Services running on the publicly exposed Web server?
One of the easiest ways is to pass credentials in the soap header of the message. So each call passes along the info needed to determine if the user is authorized. WSE makes some of that easier but one of the most succinct descriptions of this process can be found in Rocky Lhotka's book on Business Objects. I get a lot of books to review by publishers and this one had the best explanation
Assuming you don't have the option of using WCF, I'd advocate using WSE 3 (Web Service Enhancements). You can get the toolkit / SDK thingummy at MS's site
To limit the access to only internal machines (as I think your question asked), I'd set up a separate web site in IIS and set it to only respond to the internal IP address of your server.
I would set a firewall rule to restrict access to a whitelist of IP addresses.
Use IIS's directory security IP address restrictions, and limit access to just that internal web server IP address.
If you can't do that then, and you can't setup a username/password on the directory, then use WSE and add a username/password into the service, or look at certificates if you want some fun grin
Maybe I did not understand correctly, but why expose the web methods publicly at all if they're only going to be consumed by the internal server?
A simple HTTP module will work. Just hardcode (or from config) the allowed IP/host and reject all others.
If it is only the internal server that will be accessing the asmx files? You could set them up in IIS under a separate web site or virtual directory, then place some IP restrictions on the site. In properties, go under Directory Security, then "IP Address and Domain Name Restrictions."
Also, for passwords, WSE 3 is the new go-to, but I did find a simple method in a book from Apress called "Pro ASP.NET 2.0 in C# 2005" Chapter 34. (Note, the newer version of this book omits this chapter.) The section is custom Ticket-based authentication.
In this moment what comes to my mind is IP filtering on IIS. Fast to apply, should work in your scenario.
TLS with client certs. See Wikipedia entry to get started.
Be aware that there are ways around whitelisting IPs. Don't get me wrong, it's a great idea, and you should definetly do it, but if your budget/resources allow it, you can expand your threat model.
Related
I'm very new to web services (please note, not WCF but the old fashioned .asmx files).
Now I may be liking this too much to ports, but if I expose a port on my web facing server then it is exposed to attacks as well as my own use; There are tools which can scan to see what ports are open.
Is this true of a web service? Now, don't get me wrong, I know each service should be coded well enough that nothing malicious can happen or that the calling class doesn't know the 'contract' to implement them, but that's not the question (and I guess port flooding could still occur?); If I put up a few web services on a server, is there a tool/program which can detect them (by name)?
Yes, a web service is basically a web page that takes arguments and response with a formatted result that can be read more easily by a program (technically both are a result of a http request and response - there are other mechanisms as well, but the typical one is over the http protocol).
If you type the link to your web service in a browser you will see you are presented with an interface that allows you to "execute" its services.
Therefor you need the same security as with a web page, meaning login or check of credentials, tokens, signing, encryption and so forth (preferably on a ssl-connection).
I have a public desktop site, a public mobile site, and a private intranet site on the same server. They are all written in C# (ASP.Net 4.0).
Each has their own code to process credit card payments. I would like to write a single application that handles credit card payments for all 3 sites. I want this application to only be accessible from these 3 local applications.
The only way I know how to do this is to create a web service and restrict traffic to the localhost.
Is there a better ("right") way to do this? Should I create a windows service instead?
The general approach is sound. However, I would not only rely on access being restricted to localhost. A single misconfiguration at some later point in time would expose your payment web service. Also, if the server is compromised, any process running on that local host would have unchecked access.
Always use authentication to secure your payment web service.
If you must deploy the authentication service on the same physical box as the front end websites, take particular care securing the payment service (e.g. if you are storing credit card numbers or PII related to the credit accounts e.g. name, address, ... ensure the database is correctly secured). If at all possible, place payment services in an additional layer separate from the public-facing (or co-worker facing) websites, protected by appropriate firewall rules.
I don't think windows service would be good option if you have calling applications. As far as I know about WCF, we have option for NetTcpBinding and NetNamedPipeBinding which you might consider.
NetTcpBinding - A secure and optimized binding suitable for cross-machine communication between WCF applications.
NetNamedPipeBinding - A secure, reliable, optimized binding that is suitable for on-machine communication between WCF applications.
I have an Asp.net application 3.5. I want to be able to allow multiple/ different clients to access the same application but using different URL's. I have already managed to configure the database to allow this.
So here's the main part.
I want to host my application in a domain say...
wwww.myapplication.com
then allow different client to access the same application using
1) www.clientOne.myapplication.com
2) www.clientTwo.myapplication.com
Also the client subdomains i.e(clientone.myapplication.com and clienttwo.myapplication.com)
should be autocreated by the client upon registration.
How can I achieve this..Your help will be greatly appreciated
A good example of how I want my application to work is
www.quickschools.com
I finally found out the solution that I wanted, so I thought I would share with you my finding. It turns out I needed to create a web application from another running Asp.net web application (From C# Code)
This tutorial by Robbe Morris was really helpful if you need to get started on this.
Another article you might want to check out is this one.
To have different url's using the same application, i would use "301 redirect" subdomains. I'm not really sure how to have a webapp create these subdomains.
I think the way to do this is to make the website the default website on the server i.e. configure so all requests to the servers IP hit this website (unless the header matches another website that explicitly looks for it). You do this just by not specifying a header on the IIS settings (only an IP address and a port number) - you can only do this for one site per IP address/port combination on the server.
Then look at the request url in the website to determine which domain was requested.
This way there is no need to 'create' subdomains... but you do need to reject all request to a domain that you don't want to recognize.
If you can't do this then you would need to adjust the IIS metabase from the application - not impossible - but a very risky and probably a bad idea.
The common case is that you'll have to configure a new virtual site for each of your new tenants during account provisioning. See Creating a New Virtual Server on how to achieve this programatically. Some though argue (with convincing arguments...) that spinning up an appdomain for each tenant is a waste of resources and one should use routing in the application that inspect the HOST header, see Multi-tenant ASP.NET MVC – Introduction.
Configuring IIS/ASP to respond to your tenant sub-dmains is the easy part. The real problem will be to configure DNS for your tenants, and that depends on your DNS solution.
I have a .NET web service which is publically accessible since it needs to be accessible via Flex. It currently only has read operations.
http://www.example.com/webservices/weather.asmx?wsdl
I want to add some admin only web methods to the same webservice such as UpdateWeather and StartRainstorm. Obviously I don't want my end user being able to do change weather patterns.
So I just want to hide the wsdl so that it cannot be accessed via the standard ?wsdl parameter. Ultimately I'll add on better security etc. but I need a quick fix for now. I figure if they don't know the method name they won't be able to access it.
I want to be able to disable the WSDL generation - which I can do by adding <add name="Documentation" /> to my web.config. BUT I want to be able to access the WSDL in some other 'secret' way that only I know so I dont have to keep going to the server. How could I achieve this. I'm fine if its a secret URL or a secret parameter or whatever.
I'm fine with this security through obfuscation approach for now.
One thing you could do is expose another endpoint for the admin contract. Then turn off the WSDL publisher on that admin endpoint. Eventually you could configure security just on the administrative endpoint if you wanted.
This is assuming you are using WCF.
Update: Check out this WCF getting started tutorial. You'll like WCF more than ASP.NET/ASMX services once you learn a bit about it.
why won't you just create another web service? Seems simpler
For update references, you could use your development server.
The production server cannot expose wsdl docs unless you provide public access.
Or, if you have access to the wcf assembly, you can use svcutil against the wcf assembly. This will generate language code to be used in your application.
If you really, really want to expose wsdl to limited users, you can use the iis url rewriting to block access from unauthorized ip addresses.
Scenario
I have an HTML/javascript website that uses javascriptSOAPClient communicate with an ASP.NET 1.1 web service in order to read/write to a SQL database. (http://www.codeproject.com/KB/ajax/JavaScriptSOAPClient.aspx). The database contains anonymous demographic information--no names, no credit cards, no addresses. Essentially the data collected is for data mining purposes.
The site is live, but we want to introduce a more secure communication between the javascript/ajax client and the wbe service for both this and future projects. Working as contractors in the financial industry, at some point we're going to get nailed with the question: is this website hackable? If we don't have a solution we could be out on our ears.
I am already following best practices such as communicating with the database via command parameters and stored procedures). However, currently anyone could browse to our web service description and figure out how to consume our exposed services.
Questions
With my hybrid solution (i.e. not end-to-end Microsoft) how should I go about authenticating client requests on the web service?
If I start passing a username/password or some other identifiable element into the web service as authentication, should I be concerned about how that key is generated/stored on the client side?
A few suggestions to consider:
List the threats, and compare each to your current setup.
Use SSL / HTTPS. This alleviates a whole class of vulnerabilities.
Use username/password, generated on the server side and sent out of band (in the post or by phone) to the user. (Hope this answers question 2).
Use 2-factor authentication. To do this, you can look at security tokens such as RSA's keyfob-type gizmos or look at Steve Gibson's Perfect Paper Passwords
The easiest solution from a programming standpoint is to use two way HTTPS. That is, the server presents a certificate to the client, and the client presents a certificate to the server. Then only clients with proper certs (issued by you) can connect.
That helps reassure clients that your site is not generally accessible, yet the security is transparent to the application and, once they've signed up and received a cert, to them. The downside is that you have admin overhead in issuing and tracking the user certs -- but that's probably less than you'd have dealing with username/password combos.
There are a few simple options:
SSL + Cookie
If the web app is also ASP.NET and hosted along with your web service, then you should have access to the User/Membership/Session of the web app inside your web service (essentially #1, but you get it without doing any work).
If the web app and web service are not on the same domain, then cookies are out due to cross-domain issues - so you can have the web app embed a GUID into a hidden form field, and use that GUID as a sort of cookie (and it will need to be passed as a parameter on all web service requests).
Can you incorporate a certificate authentication mechanism? So that only clients that have keys you can verify can communicate? That's how the product I work with has its managed devices communicate back to the core.