When you look at the biggest trends in software development in the last few years, Web and Mobile apps stands out as by far the most dominant. And it's not hard to understand why.
Web and cloud-based apps are designed to be interconnected and accessible, making it possible to reach people regardless of geographic boundaries. Tiny startups can take advantage of massive cloud infrastructure they wouldn't have the bandwidth to build themselves. Major organisations are using web applications to make their services more integrated than ever before. Rapid development and deployment through cloud services haven't just become possible, they're necessary.
The shift towards web services sparked the widespread use of REST (Representational State Transfer) and SOAP (Simple Object Access Protocol - the older standard). These web services have led to creation of API and allowed for a higher level of interactivity between applications, leading to a massive convergence of mobile, web, and connected technologies (like IoT and so on).
But as with any new technology, the push towards creating seamless web services and enabling apps brought with it a new set of security issues. In the case of web applications, this security flaw relates to vulnerabilities in Authorisation.
Authorisation is the practice of assigning permissions and privileges of objects and components to subjects (e.g. users). It's one of the cornerstones of a strong access control system. For instance, a user must be able to access his/her own account on an e-commerce system, but must be unable to gain access to another user’s account.
Permissions and Privileges to objects must be based on the principle of “Least Privilege” (the privileges required to perform one’s functions as per one’s role and requirement). In Web 1.0 ( and the beginning of 2.0) this was relatively well established. The browser was the sole medium of access to services. Authorisation could be enforced at the view layer (presentation) or at the controller layer (business logic and data access).
Authorisation was much more “visible” and developers used the tools at their disposal, at multiple layers to enforce permissions and privileges across the system. Now however, we find that 7 in 10 applications (with a web services footprint) have serious flaws in authorisation. Let me explain why that is, and what we can do about it.
In the days of traditional web apps and enterprise apps, everything was visual. Applications were generally monolithic structures that focused on delivering content to the browser. There was a traditional view (what the user sees) and a controller and data access layer (for business logic and accessing the Database).
Now, however, even the smallest applications have middleware layers (web services) that deliver content to completely varied clients (browsers, mobile apps, other apps, etc), which has made them, for lack of a better word, “invisible”. Developers create web services that can be called by a client, directly interacting with the data and manipulating it.
For instance, while performing the penetration test of a major hotel booking service provider, a particular bug caught our attention: When using a browser, the user can only access bookings that he/she has performed. However, while sending calls over REST based web services, we were able to retrieve bookings of all the users in the booking system, using an incremental key value, effectively giving us access to all bookings on the system. Scary!
Read more: Preventing XSS with Base64 encoding
Apparently, the developers had failed to lock down the permissions models for the web services because they figured that no one could manipulate requests over web services and that they would be “invisible” for the most part. Web services are just another medium to access data, the same rules for authorisation apply to web services as they do to traditional web apps.
Web Services, especially REST and JSON are like a panacea for an XML and “pure-web” view of things. I agree, these technologies have made web services truly seamless and scalable, delivering amazing results. However, I still find that developers are not aware of possible security considerations of these technologies.
I find that most applications are rife with Insecure Direct Object Reference bugs (ability to reference objects and access them, even being an unauthorised user) or direct URL access (ability to access privileged URLs without authentication or authorisation).
Web Services are vulnerable to a rash of other issues that can be directly solved with higher levels of awareness (distinct from typical “Web Application Security”) and lists like the OWASP Top 10 - Possibly micro-focused on an OWASP Web Services Top 10 or equivalent.
NoSQL Databases, Key Value DBs, Search Databases and JSON/BSON based Databases like ElasticSearch, Solr, Mongo, Redis, Cassandra, etc are being used today more than ever to simplify searches, do realtime analytics and so on. In some cases, these DBs are used primarily for data storage.
However, these databases have proven to be notoriously lax on security (the way they are configured and deployed). Application critical data is stored and managed by these data stores, with little attention paid towards securing these services. As they become more pervasive in the world of apps, developers and organisations must figure out granular measures towards data protection.
Read more: Understanding Django for Web Services
Recently, we performed five penetration tests on mobile apps (against everything from mobile retail, banking, healthcare and social networks) using one or more of these databases for their web services and found that we were able to perform not only authorisation attacks, but enumerate sensitive information from these databases using configuration flaws. In some cases, like ElasticSearch, we are consistently able to exploit poorly configured DB instances to gain root access to the backend server (using a Remote Code Execution bug).
Web services are great. However, authorisation on web services is still a serious issue because of everything I've just talked about. Developers, architects and business stakeholders need to seriously look at authorisation models and implementations during the entire lifecycle of the application.
While technologies like oAuth2.0 have definitely helped, they cannot be considered a “silver bullet”. Authorisation attacks are rife and can be potentially devastating. The following are some additional steps that I would take to secure web services against authorisation attacks:
