Concurrency Attacks in Web Applications


This is Scott Stender and Alex Vidergar from iSEC Partners, and our topic for BlueHat is Concurrency Attacks in Web Applications.  Database administrators, computer architects, and operating system designers have spent decades solving the problems that arise from concurrency as they apply to their respective technologies, so this should be old, boring stuff, right? 


If you are a web application developer, let’s start with a quick question:  Is accessing session variables in your web application framework thread-safe?  If you don’t know the answer off the top of your head, don’t worry – you are not alone!


Web application developers are caught in the middle of two powerful forces:  productivity and abstraction. 


Developer productivity reduces costs and can be credited with removing drudgery from programming tasks.  In the web application world, the pursuit of productivity has yielded a parade of easy-to-use web application frameworks.  No longer do the web developers of the world manage connections and thread pools, they can focus on the creative aspects of their profession.  Modern frameworks require the programmer to implement a single function using a handful of APIs, and presto, a fully interactive web page is born. 


In order to achieve this, however, we need abstraction.  All of the “plumbing” that goes into making a web page work has to be hidden in the web application framework and web server, which means that the average web developer does not have to worry about it, or know it is even there.  Furthermore, most of those frameworks are written in an object-oriented manner, meaning that abstraction is more than just a luxury, it is a key tenet of the programming environment. 


There’s the problem:  When abstraction of such resources is a requirement of the programming environment, we should expect trouble.  Because of abstraction, developers can be unaware of resources shared across threads, processes, or servers and will fail to protect them. 


As you may have guessed, we have found more than a few instances where well-meaning developers can easily introduce concurrency flaws into their web applications. The problems themselves are difficult to identify, reproduce and can carry a hefty security impact.  Our goal is to provide guidance for developers and testers to identify and address this class of flaw.  And, with a roomful of people responsible for creating the very technologies we are discussing, we anticipate a healthy discussion on how this problem can be best addressed by security analysts and developers alike.


-Scott Stender and Alex Vidergar, iSEC Partners.