.svg "2024_Full_Logo_Full_Color_SVG (1)"){kind=logo}
This post may seem timely in light of the recent Snapchat compromise. Although Snapchat’s breach appears to be due to some poor assumptions around an “internal” Snapchat API, it is not the type of traditional web service that I was thinking about when I was planning this post. This said, Snapchat’s API is still technically a type of web service that is a common design in today’s rich web applications so some of what you read below absolutely would be applicable to web APIs used by rich web applications like Snapchat.
This is my second post on “scary web services”. The first one was focused on how web services can be daunting to testers. My intent with this post is to offer a view from the defensive, on why those who host web services in their company should find them “scary”, by outlining a few of the more common vulnerabilities with them.
Let’s start with just talking about the functions and information found in web services. Web services have grown to be very common for core business functions, especially those that might be used across several different applications. A prime example is that of retrieving and updating customer data. This type of functionality is something that often makes sense to put into a web service so that all the different applications that might need to can access it in a standard, centralized fashion.
Assuming a particular web service has the capability to access some of your most sensitive data, and that the web service must go through proper authentication and authorization controls to access said data. Why is it, then, that the web service itself may be any less protected? Poor or non-existent authentication controls are probably the number one problem with web services. One excuse I have heard on a number of occasions: “well that’s only available internally and you would have to know how to find it.” The level of protection should be relative to the type of data on the other end, not how well hidden you think it is.
Another issue that seems quite common with web services is a lack of monitoring. I don’t understand the logic behind not monitoring a web service – especially one with access to critical data or functions. Since account lockouts tend to be impractical for such web services, detective controls may be the only reasonable defense against dictionary or brute force attacks.
A final common issue with web services is a lack of encryption. Although you may not be too concerned about a man-in-the middle attack on your internal network, you may be required to encrypt the data in transit if it falls under any regulatory requirements such as those related to PCI or HIPAA. This has sometimes fallen into a gray area in the past but that probably won’t be the case in the future.
So there you have it – some reasons you should be scared of your own web services. They may access some of your core data or functions without proper authentication and they may not be monitored to detect an ongoing attack.
And if you are in an industry that’s under regulatory scrutiny, your web services may be required to use encryption. If you are running web service then make sure you do not fall trap to these three common problems.
And if you are in an industry that’s under regulatory scrutiny, your web services may be required to use encryption. If you are running web service then make sure you do not fall trap to these three common problems.
Jason Gillam is a Senior Security Consultant with Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at jgillam@secureideas.com or visit the Secure Ideas – Professionally Evil site for services provided.