It's Hard to Build a Web Site Secure Against Untrusted User Input

Recently it was reported that a group of hackers broke into Citibank. One security expert was quoted saying, "It would have been hard to prepare for this type of vulnerability." Maybe so, but the problems are hardly new if this part is true:

They simply logged on to the part of the group's site reserved for credit card customers - and substituted their account numbers which appeared in the browser's address bar with other numbers.

I'm sure someone else has stumbled onto this problem several times (it would be hard not to because there are so many websites with sequential numbers and unauthenticated data in user input fields), but I know of at least two research projects that looked into the technical issues behind such vulnerabilities.

Prof. Nickolai Zeldovich at MIT innovated the RESIN research project to help web application developers more clearly specify assertions that pertain to security. For example, a common web application error is forgetting to include an authentication check. Pretty simple error, but pervasive and cumbersome to prevent without a way to express such assertions. The RESIN language helps programmers control information flow.

A second project is my own, so I am more familiar with it. Back in 2001 (when we said "web site" rather than "website"), our small team analyzed the authentication mechanisms in several websites. It was hard not to find problems where websites were susceptible to impersonation of the user. Relevant to the Citibank incident, there were cases where websites assumed the user would not change certain elements of the query string or HTTP POST request. Embedded in these requests were sequential identifiers. Here's one example from a talk several years ago:




After prodding from people working on web application toolkits, I took a new look at web authentication in 2004. Alas, even the web toolkits had authentication flaws. In one product used by large chain retailers, it was possible for a would-be thief to impersonate others to download retail receipts by changing hidden HTML code. I wonder if this problem is similar to the flaw at Citibank. This work was never published, but did appear in the WSJ.

For more information, I encourage the interested reader to consume these documents:

• Dos and Don'ts of Client Authentication on the Web from USENIX Security 2001 [PDF and slides from a series of talks]


• Inside risks, web cookies: Not just a privacy risk 2001


• Book: Exploiting Software 2004 (see the section on "the user input problem")


• Biggest Web Problem Isn't About Privacy, It's Sloppy Security 2004


• More Scary Tales Involving Big Holes In Web-Site Security 2004


• Nemesis: Preventing Authentication & Access Control Vulnerabilities in Web Applications from USENIX Security 2009 [PDF]


• RESIN from SOSP 2009

There are probably other historical technical documents of relevance from OWASP or the RISKS Digest. Happy searching!

Exit Strategy

Something seems a bit wrong with this exit sign in the hallway at IBM.

USENIX Health Security & Privacy Videos Made Public

Earlier today USENIX made several of the HealthSec Workshop webcast videos publicly available. In particular, anyone may now watch the:

• Opening Remarks on USENIX HealthSec


• Policy for Health Records (Position papers from both universities and industrial research.)


• Invited Panel on Medical Device Security & Privacy
  

  Panelists: John F. Murray Jr., Software Compliance Expert, United States Food and Drug Administration, CDRH/Office of Compliance; Nathanael Paul, Research Scientist, Oak Ridge National Laboratory; Karen Sandler, General Counsel of the Software Freedom Law Center

  
  

  All the panelists work in the medical device software space, and all personally use computer-controlled medical devices (mostly implanted).

  
  

Software update risks in avionics: pre-flight briefings

Browsing the ASRS database can be educational. Search for ACN #875270 and you'll see these snippets of an anonymous comment about the risks of software updates and avionics for providing pilots with pre-flight briefings.

"I am a Flight Service specialist. I am reporting an ongoing and routinely occurring safety concern. About 2-3 times/month, the company takes down its primary briefing system, for various reasons - software updates/patches, security patches, information updates, etc. The entire system is taken down all at once, nationwide."
...
"Coupling this lack of knowledge with unreliable/incomplete data is a recipe that guarantees, in time, a tragedy for an unknowing pilot and passengers who placed their trust in our company."

Aviation Safety Reporting System
Pre-flight briefing

Software risks and medical ventilators

Did a software glitch cause an oxygen delivery system to fail, leading to a patient's death?

Earlier this year, a person tragically died during ambulance transport. The article explains that it's believed a software glitch caused an oxygen system to fail, leading to the patient's death. A TV news team made a video of the the medical system and interviewed a paramedic (who was not the paramedic involved with the event). There is very little technical information publicly available about the event, except that there are multiple manufacturers involved. Road Rescue reportedly built the ambulance. And Spartan Chassis is reportedly involved with the components in the ambulance itself.

No one has reported technical information on the alleged software glitch itself. However, this rather brief adverse event report at FDA cites a date coincidentally close to April 22 (the date of the incident). Is the underlying technology an Evita 4 Ventilator? What role did software play in the incident? What other factors contributed?