How do I test a Web service that sends and receives a response? I need to test “authenticate” and “decrypt” functions.
My answer starts with a warning: a basic tenet of security is to leave security to the professionals. Authentication and encryption are two engineering processes which exist in a number of proven application components. If your company is developing its own authentication utilities, think twice. There’s no sense in risking getting it wrong when there are so many open source and commercial solutions available. And encryption? Don’t even try it … believe me, there are bright folks working day and night to break standard, highly-secure encryption solutions. Don’t think it’ll take them more than a few hours to break something you build in-house. Unless you have experts with long experience in both domains, leverage something that exists.
Assuming you’ve implemented existing solutions and your task at hand is testing that they’re implemented correctly, here are some ideas. First, start with the basics. Ensure authentication with a series of cases that probe valid logins, invalid logins, disabled accounts, etc. The next step is to move to corner cases like valid accounts which do not have access to the Web service apps in question, accounts which were valid but are now disabled, and so forth. Probe for a variety of cases because if you can think of it, chances are it will happen in production.
Validating encryption can be another challenge. Unless you’re an MIT-caliber mathematician, I doubt you’re going to be able to validate RSA’s public/private key exchanges. But I think what you’re really asking is how to make sure data to and from your service is being encrypted. You could proxy your client’s requests, but most of the tools built for proxying Web requests run above the encryption layer (in the OSI model, this is the Transport layer where SSL protocol is decrypted), so it’s difficult to detect if network traffic has actually been encrypted. When you’re sniffing traffic, look for traffic over port 443, and make sure that traffic is going over TLS 1.0 on a secure socket layer. The traffic frame will look something like this, if you’re using Wireshark:
Notice the fifth layer in the capture is “Secure Socket Layer” or SSL. If communications between your client and your server don’t appear in SSL, you have a configuration issue somewhere.
Kudos to your team that you’re validating these topics. Many teams press ahead blindly, simply assuming authentication, authorization and encryption are working and are configured correctly. By spending a little time now, you’ll know your service has been built and deployed correctly.
Dig Deeper on Topics Archive
Related Q&A from John Overbaugh
Learn strategies for best security test strategies for SaaS cloud. Continue Reading
Security and security tools have become more necessary to the application lifecycle, according to recent research. In this response, expert John ... Continue Reading
Expert John Overbaugh defines security as confidentiality, integrity and availability of information across systems and applications. Read this ... Continue Reading