[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous



OK, so my understanding is that we assume IP-binding, and then compare a PRNG approach (one-time token) to an encryption approach. I think we're making progress on our mutual understanding ;-)

As you noted yourself, the session/one-time-token approach typically makes use of PRNG, which may have cryptographic weakness much like encryption. I agree though that there's less likelihood of making mistakes when using the session mechanism, compared to encryption (e.g. key management issues). But please read on.

James Landis wrote:
Comments inline.

Before we go down this road, I know that any random number generator we can use in practice is going to be deterministic as well. However, from a provability perspective all we need to show is that this generator is sufficiently random. Using the encryption scheme, we not only have to show randomness but we have to do it for a much more complex system, which itself will probably include it's OWN random number generator. Complexity is the enemy of security.
Yes, but I'm not sure that what the encryption approach is THAT complex. Two implementations for the encryption approach were provided already (J2EE - http://www.owasp.org/index.php/PDF_Attack_Filter_for_Java_EE and .NET - http://www.techplay.net/), none seem to contain complex code by my standards. And the "payment" at the server side for one time token - i.e. maintaining a list of generated tokens and ticking its entries when valid tokens are received is pretty severe payment. Think load-balanced systems, fail over, RAM considerations, ...



    > In practice, for both methods it is probably easier to attack the
    > client by forcing them to use a valid generated token via one of
    the
    > attack schemes already discussed.
    >
    What attack methods do you refer to, which are applicable to my
    algorithm?


What? Let me rephrase. There are two ways to attack the defenses that have been proposed on this thread (regardless of the token generator): attack the token itself or attack the token handling in transit or on the client side. What I'm saying is that if the encrypted token is generated securely (non-trivial), then no matter which method is chosen then it is probably easier to attack the token handling than to try to pre-generate a valid token.


In essence, in current practical terms it doesn't really matter if you use a computed token or a random nonce if the token generation process is secure enough; that's not the weak link. However, the devil is in the details. State management isn't without its pitfalls, either (resource starvation, overhead, etc.), but the theory of state management is a lot easier for the typical developer to grasp than strong encryption.

I suppose that observation is individual ;-)  I for one disagree ;-)

-Amit


----------------------------------------------------------------------------
The Web Security Mailing List: http://www.webappsec.org/lists/websecurity/


The Web Security Mailing List Archives: http://www.webappsec.org/lists/websecurity/archive/
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]




Brought to you by http://www.webappsec.org
Search this site