Right on! Great article. Concurrency is a huge issue and nowhere more important than web applications. Many many developers are writing web apps and not realizing that they are heavily multithreaded. They develop and test on their desktop in a single-user environment, so they don't see the problems. Even many load testing frameworks will not exercise a concurrency problem, as they don't tend to send a wide variety of requests.

We've found these problems in web applications of every flavor. And they *are* being experienced by customers. Imagine that once in a great while, a user just gets another user's account page. Then after a refresh it's gone and everything is working fine. Very difficult to find or reproduce for maintenance programmers. One of our customers had exactly this problem in their application and it was uncovered by a user who happened to report it.

If you're interested, there's a lesson in WebGoat at OWASP that teaches developers about these flaws and how to avoid them.

--Jeff

----- Original Message ----- From: "Gunnar Peterson" <[EMAIL PROTECTED]>
To: "Secure Coding Mailing List" <SC-L@securecoding.org>
Sent: Tuesday, February 01, 2005 2:10 PM
Subject: [SC-L] free lunch almost over



If you do the math on what comes next after the processor manufacturers' free lunch is over, the implications to concurrency, security, and privacy are huge:

http://www.gotw.ca/publications/concurrency-ddj.htm

How do traditional security mechanisms function in a massively concurrent world? How relevant are they? What new security designs are needed? Is it too late to bail and head for academia?

-gp




Reply via email to