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.
Related
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 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?
Wondering about how to do the following efficiently, securely, and in a fashion that won't have us tearing our hair out because of overcomplication: we have an ASP.Net site that uses forms authentication and would like to implement some WCF restful web services that can be called from the first site, provided the user calling them has been authenticated.
We'd like to host the WCF RESTful service in a different web site from the ASP.Net site. Both sites will be in the same domain (my-domain.com for instance).
I've been reading up on the various bindings in WCF and am not sure if webHttpBindings are the way to go here (they being the most REST-friendly, but can they accommodate forms-authenticated users?)
I'm looking for suggestions and references as much as code, but I'd love to know where to start and what to look for, what's possible and what isn't.
Every time I read about WCF authentication it seems to inevitably sluice into discussions about WS-security and X509 certificates, and I don't know that I need all that for what I'm doing? What I'm really looking to build is a series of WCF restful services that only respond to forms-authenticated users. If that's not possible without diving deep into WS-Security and X509 then so be it, but I'd like to keep it as simple as possible.
Note: I asked a somewhat similar question about a month ago, but have decided to go with forms authentication.
If you are not calling your WCF services from the browser, then you don't even need to secure them. Just call them from your ASPX code to a non-public site that hosts WCF. Or use X509 certs in a server-to-server mode.
If you do plan to call them from the browser, then things get more complicated. In this case, you may want to ditch WCF and look at with Web API included in the MVC 4 beta release to build your REST services.
http://www.asp.net/web-api
Have your javascript generated from the code behind. If Page.User.IsAuthenticated, render the ajax script. If not, render javascript that alerts the user that they need to be logged in. If you don't want the user cutting the javascript out of the browser source and running it later, when they are not authenticated, you will need to generate a token based on the session ID, that can be passed between the site and the service.
Something I can't wrap my head around is how secure web services are.
For example we're writing a desktop application that will interact with data on one of our websites as well as local data. This data is sensitive though and the last thing we want is anybody calling the web services.
I've not yet found anything that says web services has some kind of authentication methods and the only security I've seen people talk about is using certificates to encrypt the message.
I'm no guru on this and would appreciate anyone's input and perhaps a link to somewhere that will explain this in simple terms.
Thanks
Jacques
If you are using ASP.NET to create a response / request Service you have only 3 options
ASMX
WCF
Normal .NET pages (or handlers) to process requests
as you specify Services, you can choose between ASMX and WCF then (you can read the difference between ASMX and WCF in my answer here)
keep in mind this
ASMX is considered deprecated technology and replaced by WCF. So if you are going to start new development which requires exposing reusable services, WCF is the way to go.
This days, there is a common pattern when we need to secure Services, and that's using a session key.
The Service normally has a Method for Login where it gets a User and some kind of Password (normally hashed, salted, etc) and that returns a "ticket" that has a limit of time (slided or not - means per each call to a method the period get's reseted or not), and all calls need to have that ticket included in the message body.
Services API like Magento and others uses this.
Or having a pre generated key that is given to the user / application to be used with every call
Services API like Campaign Monitor and MailChimp and others uses this.
The other normal way is to have the user and other credential in the message header all the time.
Services API like SuperOffice CRM and others uses this.
None of this services uses SSL, as I would only use if I really needed to protected the data in the "wire" keeping in mind that SSL expands the response time on every call made.
I hope this helps
Authentication:
Consider securing your web services with SSL. Distribute client certificates to those who need to consume those web services. Configure IIS to "Require Client Certificates".
Authorization: Consider developing a scheme where the user is sending a username and password of some kind in the querystring. When you can determine that those credentials are permitted to perform the operation that they're requesting, you can allow them to proceed. Indeed, this is custom logic that the application developer needs to write. There are no built-in conventions in ASP.NET web service for this.
The SSL encryption occurs at a lower level from the application. It's the applications job to then determine who is allowed to perform what operations.
Our webservices are encrypted through SSL (the certificates part) which is https://www.yousite.com instead of http://www.yoursite.com. This just provides basic encryption for the data stream. See SSL.
They are also authenticated by the authentication method that is chosen for our website. If it's is windows auth, or forms auth. See the msdn page on ASP .NET authentication.
For XML Web-Services you should take into account the following best practices:
Secure the transport Layer: the infromation or data in XML cannot be interrupted and read in transit.
Mask internal resources: Use Network Addres Translation (NAT).
Implement XML filtering: With the heklp of XMLand SOAP, affective filtering policies can be set to a content level that requieres a fully parsed or processed XML document.
Validate, Transform, Sign and Timestamp al messages: Use XML Schemma Validation, use XSLT for transforming XML, sing all messages, use Network Time Protocool (NTP) for synchronizing all XML nodes to a single authoritative reference time source.
Encrypt message fields.
Implement secure auditing.
Use existing security methods such as HTTPS.
Perform XSL transformations on the server.
Source: EC-Council Secure Programmer.
To expound on previous answers: Web Services are as secure as you make them. In general, there are two types of security. Securing the Transmission, and securing the access. Use of SSL can make your transmission secure (). Using Authentication (demand a username and password) allows you to secure access.
Web Services accessed via public internet (that is: not a VPN or only internal resources) are, indeed, less secure than Windows applications, since anyone can have access to them and, potentially, attempt to break your security. By using both transmission and access security, you can mitigate that to acceptable levels (acceptable to the point that banks use them for financial transactions, and you don't know paranoid until you've talked to a banker who has to face an FDIC inspection).
All web applications are exposed to the attacker and are a great surface area for attack. The biggest problem with web services, such as SOAP(WCF) is that often times the programmer doesn't realize that its trivial for an attacker to gain full access to the service. Often times programmers expose nasty functionally like execute_sql_query().
You should read the entire OWASP top 10.
Here's a primer on Securing XML Web Services Created using ASP.NET.
I am building a web based application written in ASP.NET and Flex. One of my biggest challenges is implementing security for the application in a flexible and maintainable way. This challenge is compounded when different technologies are involved. I'll try to describe what I have below.
The website is laid out as follows:
/mydomain.com/
Login.aspx
Default.aspx (hosts flex [.swf] application)
/Administration/
AddUsers.aspx
AddRoles.aspx
AddPermissions.aspx
etc...
/Services/
SecurityService.asmx
MapService.asmx
PhotoService.asmx
etc...
I am currently using forms authentication to secure the resources on the website. All pages/resources not in the /Services/ folder require an authenticated user and will be redirected to Login.aspx if they are not yet authenticated. The .asmx pages allow unauthenticated users. To secure these resources I throw an exception in the SOAP method. This avoids redirecting pages for SOAP web services which is not supported by any SOAP web service clients I am aware of. Finally, SecurityService.asmx contains a Login method to allow the Flex application to Login without redirecting to the Login.aspx page should the cookie expire for any reason. Because the cookie established is sent with any request to the server, including requests coming from the Flex application, this seems to work pretty well.
However, this still feels like a bad approach securing web services. I feel like I am using Forms Authentication for something it was not intended for. Specifically, I am concerned about:
This model will not work when the services are separated from the core website. This is a newly discovered requirement and I believe that Forms Authentication is not going to work well (if at all) without a lot more modification and trickery.
Clients other the Flex may require access to the services. Some of these clients may not even be able use cookies. If so, this model immediately falls apart. This is not an immediate requirement but it is known that this is one of the long term goals.
We will eventually (hopefully sooner rather than later) move to a REST based architecture (vs. SOAP) so any solution needs to work for SOAP and REST.
So, my question is.
What are the best authentication and authorization mechanisms for securing an application built on ASP.NET, Flex, and SOAP or REST web services?
Note: I am actively looking into OAuth; however, I am having a difficult time finding complete examples from which to learn. Additionally, I need to be able to filter the data returned for a given user based on the permissions that user has, OAuth seems to remove the identity of the user from the token. As such, I am not sure how OAuth applies in a fine grained security model.
Others may disagree, but I actually don't see a huge problem with handling it the way you are now; that's probably how I'd handle myself, at least initially. One way or another, even down the road, you'll probably want to keep the Flex app aware of the authentication state of the session, so if that means checking the ASP.NET session token directly, or some other cookie you set when you set that one, it seems like a fine and reliable way to go.
I do see what you mean about the services redirecting, but even so, with forms auth, it's not so much the service specifically that's handling the redirecting so much as the ASP.NET app itself. Later, should you need to use a different authentication scheme, you can consider that scheme's specific implementation considerations. Unless you've got concerns about using forms auth in general, there's probably no need complicate your approach simply because of the Flex client and Web services.
I admit I don't work with web services much, but what about requiring an access key as a soap header parameter? Any client app which can communicate with a soap web service is likely to have a low level API to modify the soap request, and use of the access key allows you to (in theory) limit the use of the service. Google, Amazon, and several other providers use this type of authentication for their web services and it seems to work very well.
This article seems like it might be a good place to start...
The WCF Security Guide published on CodePlex may help you there, if you are using, or can use WCF.
There's also Microsoft's Web Services Enhancements (WSE) 3.0 which I believe implements some of the WS-* security specifications.
Hope that helps.
If you move your services to another place, then the standard ASP.net authentication cookie can be re-used if both web apps have the same machineKey in the web.config.
As far as I know, FLEX will honour the asp.net authentication cookies because it will make http requests through the browser, which will pass the http cookies (including the asp.net authentication ticket) like a normal http request.
Have you tried securing your website and services using normal asp.net authentication yet?
I think it's best to have independent authentication systems - even if there are relations between the user and the auth tokens on the back end. They are different beasts that have differing capabilities and demands.
Use the normal forms based auth for the flex portion. That is good.
For web services, you could create a login method that returns some auth token which is used by subsequent tasks to execute. Or add a few fields to your web services (posted in the header or as params) to use a userid/password combo for authentication each and every time.
A side note: I wouldn't rely on a soap exception to handle authentication problems. But you wouldn't need to worry about the redirection if you send an auth token or user/pass with the WS requests.
EDIT:
RE: Comment-
Ideally there is. There are products out there (Tivoli access manager) that service those needs, but they are expensive.
I gave this recommendation because it eases the pain of allowing access to alternative clients and as long as you designed the services correctly it's stateless. It also gives you finer grained control over data level access on the service side of things.
See Web Services authentication - best practices?
Dave Dunkin wrote:
The easiest way to handle it across a
variety of platforms is to use HTTP
basic authentication and HTTPS for the
transport layer. WS-Security would be
good if your needs go beyond simple
username/password but the support is
going to vary quite a bit between
platforms. HTTP authentication is
supported by every decent SOAP
implementation.
and my Custom HTTP Basic Authentication for ASP.NET Web Services on .NET 3.5/VS 2008.