Scribd
Upload
121 views

Web Application Concurrency Vulnerabilities

Web applications need to be aware of threading issues as multiple threads could interact with shared objects simultaneously. This can lead to race conditions where the order of thread execution impacts the outcome. Common concurrency issues include deadlocks when multiple threads attempt to update shared data, and cross-user vulnerabilities when data is accessed through shared objects instead of being isolated to each user. Proper application design is needed to ensure objects are only shared where intended and user data is associated with the correct session. Thorough testing with many simultaneous users is also important to uncover any race conditions.

Uploaded by

chidseymatt
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
121 views

Web Application Concurrency Vulnerabilities

Web applications need to be aware of threading issues as multiple threads could interact with shared objects simultaneously. This can lead to race conditions where the order of thread execution impacts the outcome. Common concurrency issues include deadlocks when multiple threads attempt to update shared data, and cross-user vulnerabilities when data is accessed through shared objects instead of being isolated to each user. Proper application design is needed to ensure objects are only shared where intended and user data is associated with the correct session. Thorough testing with many simultaneous users is also important to uncover any race conditions.

Uploaded by

chidseymatt
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 43

CONCURRENCY VULNERABILITIES

OWASP BOOKS

OWASP Testing Guide


: ~NZ$18 + pp
OWASP Code Review
: ~NZ$15 + pp
OWASP Developers Guide
: ~NZ$15 + pp

WEB APPLICATION SECURITY

WHAT ABOUT SQL INJECTION?

WEB APPLICATION SECURITY

WEB APPLICATION SECURITY

CONCURRENCY VULNERABILITIES

Web servers are multithreaded applications


: Thread pools
: Locking
: IO requests
Web applications need to be thread aware
: Danger of multiple threads interacting with an object
at the same time
What happens when threads act simultaneously?
: Depends on the language and framework
: Depends on the situation
: Depends on the server load

MULTI ACCESS ISSUES

Race conditions
: TOCTOU
: Object reuse out of context
: Object modification during workflow
Deadlocks
: Common condition when data updated by two
sources
: Record locking, database transactions

CONCURRENCY VULNERABILITIES

Thread safety
: Multithreaded applications
Cross user data vulnerabilities
: Access through shared objects
Single user data vulnerabilities
: Access through unshared objects
Asynchronous requests
: Synchronisation issues

THREAD SAFETY

Thread safe objects


: Automatically handle locking
: Ensure access by one thread at a time
: Not cause a deadlock
Threading errors
: Not all objects are thread safe
: Serious and subtle problems
: Difficult to identify
: Difficult to reproduce

THREAD SAFETY
THE APPLICATION

The app starts with 10


users

NUMUSERS

RACE
NUMUSERS
++
NEW USER
SIGNUP

NUMUSERSUSER QUIT

Depending on who wins the race and


when the threads intercept, numusers
could end up as 10 or 11 (should be 10)

THREAD SAFETY

ASP.Net
: Requests for a given session are serialized, so
session variables are thread-safe by default
Java Servlets
: HttpSession, including associated variables are not
thread-safe

THREAD SAFETY

Struts 1.x
: Actions are singletons and thus prone to issues
Struts 2.x
: New instances of Actions are spawned for each
request and are thread safe

THREAD SAFETY

How does this affect security?


: Consider an online banking system

THREAD SAFETY

CONCURRENCY ISSUES

More interesting are;


: Issues affecting users

The ones that make it into the


headlines!

UNCONFIRMED ISSUES

UNCONFIRMED ISSUES

WHAT HAPPENED?

Variables shared between threads


: Shared between sessions
: Class globals
: Static declarations
Shared data
: Any data not instantiated for the session
: Data reused in following sessions
How can this affect user accounts?
: Session token identifier returned to two threads
: Different browser sessions have the same identifier

CROSS USER THREAD SAFETY


THE APPLICATION
SHARED
OBJECT

USER 1

USER 2

Depending on where the object is used, it


can cause a security issue

JAVA

Servlets
: Unless it implements the SingleThreadModel
interface, the Servlet is a singleton by default
: There is only one instance of the Servlet
Member fields
: Storing user data in Servlet member fields introduces
a data access race condition between threads

JAVA

public class GuestBook extends HttpServlet {


String name;
protected void doPost (HttpServletRequest req,
HttpServletResponse res) {
name = req.getParameter("name");
...
out.println(name + ", thanks for visiting!");
}
}
Thread 1:
Thread 2:
Thread 1:
visiting!
Thread 2:
visiting!"

assign "Dick" to name


assign "Jane" to name
print "Jane, thanks for
print "Jane, thanks for

JAVA

Java beans
: When a bean is a singleton (which is by default), it
simply means that every time you access the bean,
you will get a reference to the same object
<bean id="myBean" class="MyClass" />
Object bean1 = context.getBean("myBean");
Object bean2 = context.getBean("myBean");
Object bean3 = context.getBean("myBean");

bean1, bean2, and bean3 are all the same


instance of MyClass.

JAVA

JSP pages
: JSP pages by default are not thread safe
: Local variables are ok
: Instance variables modified within the service
section of a JSP will be shared by all requests
Can mark it as unsafe
: <%@ page isThreadSafe="false" %>
: Will cause [N] instances of the servlet to be loaded
and initialized

ASP .NET

Thread safe
: Most, but not all, classes and types are safe
Shared data
: Static variables in class
: A static reference to a helper class that contains
member variables
: A helper class that contains a static variable
The application collection
: Global application-specific information that is visible
to the entire application.

ASP .NET

Static declaration
: Static classes, methods and variables are shared by
every request
: Developer must be careful not to have unsafe code
public static class Global
{
/// Global variable storing important stuff.
static string _importantData;
/// Get or set the static important data.
public static string ImportantData
{
get
{
return _importantData;
}
set
{
_importantData = value;
}
}

WHY ARE THEY HARD TO DETECT

Pools
: Application pools
: Thread pools
: Object pools
: Jobs
: Etc....

WHY ARE THEY HARD TO DETECT

Server load
: Did you test with 10 simultaneous connections?
: Did you test with 100 simultaneous connections?

Did you even test with just 2 simultaneous connections?

SERVER LOAD
THE APPLICATION
USER 1
WRITES

SHARED
OBJECT

USER 1
READS

1 User thread accessing the shared


object over its workflow life

SERVER LOAD
THE APPLICATION
USER 1
WRITES

USER 1
READS

SHARED
OBJECT

USER 2
WRITES

USER 2
READS

2 User threads accessing the shared


object over its workflow life. User2 has
overwritten user1 data

SESSION VARIABLES

Session
: Store and retrieve values for a user
: Assigned to their session token
Single User
: Can only be accessed by the associated user
: Usually thread safe for read/write
Safe?
: Not always
: Can be changed by different thread

SESSION VARIABLES
THE APPLICATION
APPLICATIO
N
WRITES

SESSION
OBJECT

APPLICATIO
N
READS

1 User thread accessing the session


object over its workflow life

SESSION VARIABLES
THE APPLICATION
APPLICATIO
N
WRITES

APPLICATIO
N
READS

SESSION
OBJECT

APPLICATIO
N
WRITES

APPLICATIO
N
READS

2 User threads accessing the session


object over its workflow life

SESSION VARIABLES

Real world example


Login()
{
..
Session["Username"] = Username.Text;
Session["Password"] = Password.Text;
If CheckLogin()
Session["Authed"]=TRUE;
Else {
Session["Username"] = "";
Session["Password"] = "";
}
..
}

SESSION VARIABLES

Real world example


LoadUserData()
{
..
If !(Session["Authed"]=TRUE)
return FALSE;
..
GetUserDataFromDB(Session["Username"])
;
//Display user data
..
Return TRUE;
}

SESSION VARIABLES

Real world example


Login()
{
..
Session["Username"] = Username.Text;
Session["Password"] = Password.Text;
If CheckLogin()
Session["Authed"]=TRUE;
Else {
Session["Username"] = "";
Session["Password"] = "";
}
..
}

LoadUserData()
{
..
If !(Session["Authed"]=TRUE)
return FALSE;
..
GetUserDataFromDB(Session["Username"]);
//Display user data
..
Return TRUE;
}

Login with valid creds, sets Session[Authed] = TRUE


Hit Login() function against with different username, sets
Session[Username]
Race with LoadUserData()
Win the race and view other users data

RACE CONDITIONS

TOCTOU
: Time of check, time of use
Change in state
: Between the time in which a given resource is
checked, and the time that resource is used, a
change occurs in the resource to invalidate the
results of the check
Threading issues
: All of the previously discussed issues

RACE CONDITIONS

Usual shopping process

Raced shopping process

Add To Cart Contents


After Payment
Processed

ASYNCHRONOUS REQUESTS

Can be affected by race conditions


THE APPLICATION
UPDATECART
()

Change quantity

PURCHASE()

Debit account

Update cost

Send Order

Race condition exists between the


backend functions, to which order they are
executed

Change quantity
Debit account
Update cost
Send Order

BROWSER CONCURRENCY ISSUES

Most major browsers have had issues


: Complicated window, DOM, object sharing
: Faulty synchronization between objects

SHARED OBJECT
Race!

SOLUTIONS

Application design
: Be aware of which objects are shared
: Do not use static/globals for user specific data
Code level
: Safe locking
: Syncronisation, Mutexes
: Be aware of thread safe/unsafe types
: Use intelligent queries
UPDATE Account ... where ID=## and
Balance=[LASTKNOWNBALANCE]

SOLUTIONS

Code reviews
: Investigate static/global classes
: Identify all singleton java objects
: Check session[] use pre authentication
Load testing
: Identify how to detect issues
: Use stress testing tools to mimic simultaneous use
Cross user suggestions
: Session should be hooked to dbase ID
: User data should be associated with session
: Do not allow concurrent session use

www.insomniasec.com

WE ARE ACTIVELY HIRING NEW PEOPLE


NOW
*
*
*
*
*

Code review
Penetration testing
Infrastructure testing
Vulnerability research
Technical report writers

You might also like