I have a web based application that uses lot of client side requests in various .asmx files.
I am wondering if I can use those web services only from client side and restrict the requests from other sources.
The reason for this is because I want to use those web services only from the current application and to restrict requests from other sources. For security reasons I could use soap authentication but since I requested the services from client side, I don't think the authentication it matters.
I'll appreciate any comments.
Thanks
The webservices are by definition public, publicly visible and available (unless they run on private network or standalone computer). I.e. anybody can access them. So, just deploying a webservice and hoping for the best is not a good approach.
And how do you intend to restrict other access?
Related
We currently have a node web server that does authentication of users including oauth2 to google and facebook. We would like for it to handle the serving of web pages while a stateless .NET web api handles the serving of the actual data (which is all requested asynchronously). My question is how to handle authentication to the web api?
I mean should the client even authenticate to the api (and if so how do we do the pass through authentication so that it is authenticated to both once authenticating against the web server) or should the web server authenticate the user and then just forward all api requests to the api along with a user id? What is the standard scheme used for this?
Thanks in advance.
This answer is late, but I'll post my thoughts for the heck of it. I would place a dummy api in your node app, just a simple pass-through for everything that is in your data api (the .net one). Then I'd lock down the data api so only your node server can talk to it. The short answer is that any api that you expose to the internet has to be locked down. If you do the above, you don't have to expose your data api to the internet. You get the added benefit of not having to deal with CORS - you can have a simple /api folder hanging off of your domain. You can also use this pass-through api to aggregate calls to multiple business apis if your solution ever grows. It's a very scalable architecture.
If you don't want to do the above, then you'll need to either place the data api on the same domain as the other site, or setup CORS so javascript/AJAX from one can call into the other. Once your data api can see cookies written by the other site, you'll need to authenticate them, probably very manually, in your .net api, since .net didn't write the auth cookie - node did.
I know this question can be too generic but for purposes of narrowing the question, here is a brief description:
I'm planning to forget about ASP.net UpdatePanel and move to use ajax via JQuery. I am afraid that because of the plain, client-side nature of JavaScript (and consequently JQuery code), any one looking to my web page's source can realize what is the URL of the web services I'm calling and also what are being passed to those web services.
When using UpdatePanel for these types of operations, I'm sure that calling web services is done on server-side and I have no concern regarding issues of information on calling sensitive web services being exposed publicly but now that I'm planning to use Ajax via JQuery, It worries me alot.
Are my concerns reasonable and if true, what are the best solutions for avoiding the threats of web-service-calling-info being exposed?
Clarification: when saying UpdatePanel, I mean utilizing a chain of techiques including ASP.net AJAX, code-behind and relying on server-side Dlls for performing async server-side operations instead of jquery Ajax which requires web services for intracting with server.
There is no way on the internet to protect your web services all the time by just hiding the URL. I am not sure when you say your updatepanel does the web service call from the server you are not taking the true power of AJAX.
One way to secure your web service is to use the authentication in the web service side. For example you need to send some authentication key every time you access the source, and this is very common, you have so many public web service who protects it self using auth key like OpenId implementation. In case you do not want to change the web service logic I think jquery way of AJAX is not a secure option.
Here's a thought, you can have two levels of web service, one which will open for all that you can use in the jquery. From the current web service, from the server side call the other secure web service. Even now you can configure your incoming request for some specific machine IP.
In this case other than your own server no body else can access to the web service securely kept behind the firewall. It is something similar we do while connecting to database server from application server.
Let me know if this helps.
I'm going to state the problems my answer is hoping to solve:
Assuming you host your services on a machine other than the web server, the problem is you give potential attackers the name/address of those machines.
Attackers can write scripts/bots to scrape your data.
Attackers can focus on your web services and try to hack them/gain access to your network.
Attackers can try to perform a DoS/DDoS on your web services.
The solution I've used in the past is to create a light weight proxy on the web server such that all AJAX calls simply point back to the current domain. Then when a call comes in, it is simply routed to the appropriate web service, which is hosted somewhere internally on the network.
It creates one additional hop on the network, but it also has these benefits:
It hides the actual IP of the machine hosting your services.
You can easily lock down that one web server and monitor unusual activity. If you see a spike in activity, you can potentially shut down the web services. (If you use a different machine, you'd have to monitor two boxes. Not a huge problem, but easier to monitor just one.)
You can easily put a distributed caching layer in the proxy. This protects you from load/denial of service (DoS) attacks and obviously supports normal web service traffic.
You can hide the authentication at the proxy level. The public calls won't betray your authentication scheme. Otherwise an attacker can see what tokens or keys or secrets or whatever that you use. Making a proxy on the web server hides that information. The data will still flow through, but again you can monitor it.
The real benefit in my opinion is that it reduces the surface area of your application which narrows what an attacker can do.
Since you refer to ASP.Net, know its viewstate can easily be decrypted. There's no failproof ways to protect your code (not to say urls called).
If you're web services are called with some parameters that could allow unrestricted and dangerous actions, then you'd better start using some users/roles/rights management.
If you're worried about "man in the middle" attacks, you best option is to use https.
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).
Is there a way I can configure my asp.net web service to work with only some applications? In other words, I am saying "only these applications have access to this web service and can therefore use it. Others can't".
When other applications tries to discover the service, it shouldn't even show up, or at least it should conceal it web methods.
PS: I am wondering if this scenario is even applicable to the whole concept/domain of web services? Plus, I am asp.net 2.0 oriented, but you can give me answers based on higher framework versions, but be specific...Thanx in advance.
I'd look at WCF (after all ASMX web services are now regarded as legacy)- there is a whole load of options regarding security configuration. Patterns and Practises have Security Guidance here. It sounds like you are most interested in authorization, so read about Access Control Mechanisms.
Also to make the service non discoverable in WCF you just don't expose a MEX endpoint. That doesn't stop clients connecting, but makes it hard for people to work out how to call the service. That said you can also secure the MEX endpoints so that is another option.
Can you put some authorization or login method to initialize usage of webservice?
We control usage of services by explicitly logging into the webservice or provide some authorization token.
I am maintaining a public website (no authorization required) that uses web services over https to perform various operations. Most of the calls to the web services are invoked from javascript.
What has recently occurred to me is that a malicious hacker could, if he/she chose to, call the webservices directly in an attempt to play havoc with the system.
In reality, there is not much damage they could do, but in practice these things are difficult to predict.
Bearing in mind that the web service calls will be exposed in javascript code (which is available to the client) what is the best approach I could use to prevent unauthorized and/or malicious access to the web services.
Sadly, I can't just restrict access by IP, as there are windows forms-based client applications out there which also interact with the web services.
Using windows authentication may be difficult, as these client apps can be run from anywhere in the world and the users are not part of any specific AD Group - or even domain for that matter.
I'd appreciate any suggestions, bearing in mind the two different classes of access and the exposure of the javascript code.
Anything called by javascript can be mimicked easily by a malicious user who has the right to use that javascript. I would suggest modifying the page to use a more server-side solution. Leave AJAX to stuff that can't be easily exploited.
Preventing an unauthorized user is MUCH easier than supporting full public access. If you drop a time-expiring guid on the user's cookies, tied to the individual user, that gets sent as one of the arguments to the Web Service, you have an extra, generally difficult-to-break, layer to the application.
Anyone who has access to execute the javascript, though, should have no trouble piecing it together. Someone who has no access to the javascript can probably be kept from accessing the Web Service easily.
It takes a bit of doing, but if your page is also ASP.net you can set up a shared session, turn on the EnableSession attribute on your webservice and use session data to secure the session. An overview can be found here: http://blogs.lessthandot.com/index.php/WebDev/ServerProgramming/ASPNET/sharing-asp-net-session-state-between-we
This would necessitate a different "version" of the service for your windows apps to consume.