Web Apllication Testing(Race Condition,Server Misconfiguration)

Technology House, 1234, Juja, 1234

As per the OWASP testing guide, “A race condition is a flaw that produces an unexpected result when the timing of actions impact other actions. An example may be seen on a multithreaded application where actions are being performed on the same data. Race conditions, by their very nature, are difficult to test for.”

Jan 27, 2022, 3:00 – 6:00 PM

3
RSVP'd

RSVP Now

Key Themes

Web

About this event

One instance of a race condition found by a security researcher (Egor Homakov) resulted in essentially unlimited money on Starbucks gift cards. How did it happen?

The exploit took advantage of the way funds were transferred between gift cards. The server-side logic for transferring funds between accounts went something like this:

1. Check balance on card 1.

2. If sufficient funds, increment funds in card 2.

3. Decrement funds in card 1.

The above steps were programmed to happen synchronously (one step at a time), however these actions were actually performed in a multi-threaded asynchronous environment.

To be clear, most modern computing environments are multi-threaded and asynchronous (even when using PHP — more on that later). So how does one exploit this race condition?

Simple: send a ton of requests for this function at the same time, thus creating a high probability that events would occur simultaneously. For example, it may result in the following execution logic:

1. 5 threads check the balance on card 1 (let’s say it’s $5).

2. 5 threads find that the balance is sufficient, and so they increment card 2 by $5, resulting in a total balance of $25.

3. 5 threads each try to decrement the funds in card 1 by $5, however the card can’t go below $0, thus 4 of the threads fail.

Wallet 2 has now gained $25 and wallet 1 has lost only $5.

When

When

Thursday, January 27, 2022
3:00 PM – 6:00 PM UTC

Speaker

  • Lawrence Ochieng

    Jomo kenyatta university of Agriculture and Technology

    Cybersecurity

Facilitator

  • John kiguru

    mr Kiguru

Organizers

  • Gabriel Okemwa

    GDSC Lead

  • Sebastian Muchui

    IoT Track Lead

  • Andrew Nzioki

    Web Development Track Lead

  • Arnold Keter

    Data Science track - Karen Campus

  • Peter Chege

    Mobile development Lead

  • Clinton Njogu

    Blockchain/Web3 Track lead

  • Chris Macharia

    Cyber-Security Track Lead

  • HILLARY OMONDI

    GDSC JKUAT

    GDSC CO-LEAD

  • Erick Otuoma

    StackUp

    Data Science Track Lead

  • Valarie Chebet

    GDSC CO-LEAD Karen Campus

  • Ruth Gitau

    Social Media and Outreach

  • Alfred Warui

    Web Dev Lead - Karen Campus

Contact Us