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.
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.
We are running a Saas ASP.NET 3.5 Web application using Forms authentication on a IIS 7.5 public server with protected content for thousands of users. We also have some subapplications running ASP.NET MVC 2.
Usernames and passwords are stored in our database and every user has roles and groups attached, with privileges and access rights defined.
Now we have been asked to also facilitate for simple SSO login via Active Directory so that users do not have to enter username and passwords twice to login. These users will originate from different networks and domains.
No user "sync" should take place from our servers to LDAP serves. We are not sure that any communication with LDAP is needed since all users will be created in our system and maintained there. Forms authentication will be used for most of our users.
From here on we are unsure which is the best path to choose. For our scenario what would be the "best practice" way to proceed?
The simple answer is SAML. It is considered the "best practice" and many large SAAS providers support it.
SAML protocol defines the single sign on flow between multiple systems. It establishes trust between systems using certificates. Your application accepts an assertion containing attributes (user id, name, email address, etc.) from other systems. Your app will map the user into your user store.
In .NET world there are several options. You can find a library that implements SAML (ComponentSpace has one) and hook it into ASP.NET authentication. You can create your own using Windows Identify Framework (WIF). Here's the boatload of WIF videos http://www.cloudidentity.com/blog/2010/06/23/ALL-WILL-BE-REVEALED-7-HOURS-RECORDINGS-FROM-THE-WIF-WORKSHOPS/. You can try IdentityServer http://thinktecture.github.io/
Depending on how secure your app must be, you can opt for a simple option of passing user id from trusted networks using a simplified method. I've seen apps that allow user id to be sent via URL parameter or form field. Of course, this is horribly insecure, and you are taking on more risk, because the trust between two networks is not cryptographically enforced. You can mitigate it somewhat by checking referrer string or IP address (if you can isolate IP range of a corporate network for example). But you are still open to spoofing because any user can impersonate others by simply replacing user id within HTTP request.
It probably doesn't answer your question fully, but hopefully points you in the right direction.
I recommend looking into ADFS 2.0 it is very powerful in terms of claims mapping and works with AD: http://msdn.microsoft.com/en-us/magazine/ee335705.aspx
What you would make is a token consuming portion of your app that would receive and parse the final claims returned to your web server after the authentication loop.
I have Android app that talks to .net 2 webservice (IIS7) using http get and managed to make it run on https using self-signed server certificate (but not requiring client certificate).
I see all http traffic is encrypted and it looks secure.
Now what options would I have on how to authenticate client? For example, I like to block webservice access from internet explorer on PC.
Client-authenticated TLS handshake described here would be a way to go?
Then how can I accomplish that? Some advice or example will be appreciated.
Well, given that each user should authenticate anyhow, you probably want to setup some sort of per-user authentication strategy for a variety of reasons. First, given this might be a widely distributed app, having a single "gold master" authentication certificate or credentials will ultimately fail as someone will hack it -- either grabbing the cert or grabbing the account. And then what do you do? Second, its not particularly hard to handle. You can easily use ASP.NET membership to back it, and then take the credentials a number of ways depending on the nature of the service. Third, it is alot easier to manage than client certificates.
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 have a fairly complex business application written in ASP.NET that is deployed on a hosted server. The site uses Forms Authentication, and there are about a dozen different roles defined. Employees and customers are both users of the application.
Now I have the requirement to develop a Windows Mobile client for the application that allows a very specialized set of tasks to be performed from a device, as opposed to a browser on a laptop. The client wants to increase productivity with this measure. Only employees will use this application.
I feel that it would make sense to re-use the security infrastructure that is already in place. The client does not need offline capability.
My thought is to deploy a set of web services to a folder of the existing site that only the new role "web service" has access to, and to use Forms Authentication (from a Windows Mobile 5/.Net 3.5 client).
I did see this question and I am aware of the limitations that Forms Authentication poses. Since security is not my primary motivator (I use SSL and can restrict access by IP address), but rather using existing user accounts and roles, my decision tree is somewhat different as well.
Can I do this, is it a good idea, and are there any code examples/references that you can point me to?
I ended up with a combination of things. First, forms authentication does not really work in this scenario, because of the redirects that you get when a users is not logged in or the credentials are incorrect.
Because I want to use the user accounts from the web app, I worked around this by just calling Membership.ValidateUser prior to processing each service call on the server.
A user is prompted for an id and password when logging on to the client. I store both values encrypted in the proxy class and pass them transparently with each call using a host header, so that the application does not have to bother with this once the user is logged in, i.e. the credentials were validated once by calling the Login() service method (which only calls Membership.ValidateUser).
I use the CryptoApi on both the server and the client side.
I understand that host headers are somewhat outdated for security applications, but since I use strong encryption AND SSL, it is perfectly adequate.