In a new paper, Bernd Roellgen of Munich-based encryption outfit PMC Ciphers, explains how it is possible to compare an encrypted backup image file made with almost any commercial encryption program or algorithm to an original that has subsequently changed so that small but telling quantities of data 'leaks'.

Here's the paper. Turns out that if you use a block cipher in Electronic Codebook Mode, identical plaintexts encrypt to identical ciphertexts.

Yeah, we already knew that.

And -1 point for a security company requiring the use of Javascript, and not failing gracefully for a browser that doesn't have it enabled.

And -- ahem -- what is it with that photograph in the paper? Couldn't the researchers have found something a little less adolescent?

For the record, I doghoused PMC Ciphers back in 2003:

PMC Ciphers. The theory description is so filled with pseudo-cryptography that it's funny to read. Hypotheses are presented as conclusions. Current research is misstated or ignored. The first link is a technical paper with four references, three of them written before 1975. Who needs thirty years of cryptographic research when you have polymorphic cipher theory?

EDITED TO ADD (10/9): I didn't realize it, but last year PMC Ciphers responded to my doghousing them. Funny stuff.

CSRF vulnerabilities occur when a website allows an authenticated user to perform a sensitive action but does not verify that the user herself is invoking that action. The key to understanding CSRF attacks is to recognize that websites typically don't verify that a request came from an authorized user. Instead they verify only that the request came from the browser of an authorized user. Because browsers run code sent by multiple sites, there is a danger that one site will (unbeknownst to the user) send a request to a second site, and the second site will mistakenly think that the user authorized the request.

If a user visits an attacker's website, the attacker can force the user's browser to send a request to a page that performs a sensitive action on behalf of the user. The target website sees a request coming from an authenticated user and happily performs some action, whether it was invoked by the user or not. CSRF attacks have been confused with Cross-Site Scripting (XSS) attacks, but they are very different. A site completely protected from XSS is still vulnerable to CSRF attacks if no protections are taken.

Paper here.

Proxy caches, combined with poorly written session management code, can easily leads to serious security flaws similar to what we highlighted in A New Security Breach in Google Docs Revealed.

Web developers have no control over proxy caches in the Internet. However, developers do have control of the code they write and their admin teams have configuration control of their web servers. Developers must assume the worst case Internet scenario with aggressive Internet cache management policies that serve cached data for economic and performance reasons.

As a consequence, this fact-of-life on the Internet sometimes results in multiple web clients being sent the same Set-Cookie HTTP headers, for example.  Caching proxy servers should obtain a fresh cookie for the each new client request. Ideally, proxy caches should not cache session management cookies and distribute cached cookies to multiple clients. However, application developers cannot assume that proxy caches are well behaved, especially for applications where security and privacy are required.

Web developers cannot know whether their content is consumed directly or via a proxy cache. Developers also cannot assume that the HTTP responses will be delivered to the intended browser. Moreover, developers cannot be sure that the intended browser even receives the intended content.  For example, a session ID issued to a client gets used while it is valid or until abandoned and expired. If it is served and delivered in response to an unencrypted HTTP GET request, there’s no guarantee it will be consumed by the intended web browser.

Ideally, SSL should be used on all web transactions that require confidentiality and privacy, including our recent Google Docs breach.  On the other hand, even SSL is not foolproof. For example, many web developers do not correctly set the “Encrypted Sessions Only” cookie property. These incorrectly configured “secure” servers will send HTTPS cookies in the open, unencrypted.

There be dragons …

Proxy Caches and Web Application Security

Abstract:  Proxy caches, combined with poorly written session management code, can easily lead to serious Internet security breaches. Web application developers cannot know whether their content is consumed directly or via a proxy cache. Developers cannot assume that the HTTP responses will be delivered to the intended browser. Moreover, developers cannot be sure that the intended browser even receives the intented content. Consequently, proxy caches are a serious theat to web application security.  In the presentation, we will discuss the recent security breach Tim found in Google Docs and review web application security and session management topics related to proxy caching.