Scary Web Services: Part 2

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
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.

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 or visit the 
Ideas – Professionally Evil
 site for services provided.
Scroll to Top