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



James Landis wrote:
More notes on Amit's remediation algorithm:

Putting all of the identifying information into the token weakens the defense because the attacker can mount known plaintext attacks against it.
Not precisely. First, the classic definition of "known plaintext attacks" is that an attacker can observe both the plaintext and the ciphertext, In our case, the attacker does see ciphertext, but he/she does not exactly see the plaintext. Obviously the IP is known, and the server time is known up to some granularity, but if (say) you use the microsecond clock, then an attacker will have a hard time guessing the *exact* plaintext.

I don't think known-plaintext attack should worry you if you use an industrial strength encryption, but if you feel like hardening the algorithm against this attack, you can always throw in a random number, or a secret string as part of the plaintext, and discard it upon decryption.
Putting things in perspective, even if the attacker breaks the encryption algorithm, they still have to know the IP address of the target. However, a sufficiently clever attacker will simply create a phishing scam which harvests IPs and creates custom URLs for each victim. The algorithm will also be weakened against individually targeted attacks because like you said, it does not protect users which appear to come from the same IP to the Web server.

Even if the attacker knows the exact IP address of the victim, I don't see how this helps much. A good encryption algorithm will withstand a known plaintext attack. And since the attacker cannot fake TCP traffic coming from the victim's IP (unless the attacker and victim go out to the Internet from the same IP, or unless the attacker uses IP spoofing techniques not suitable for our kind of attacks), I don't see how the attacker can acquire a valid token for the attack.
Amit's solution is a tradeoff with maintaining state for the "unique tokens" described by RSnake. Unique tokes or nonces are a more secure solution but using them incurs the additional overhead of tracking the nonces. Amit's algorithm has no tracking overhead.
Why are they secure? Please consider the attack scheme I described in http://www.webappsec.org/lists/websecurity/archive/2007-01/msg00065.html

-Amit



Relevant Pages

  • Re: [PROPOSAL/PATCH] Fortuna PRNG in /dev/random
    ... > plaintext that's not one of the two. ... > which plaintext of the two goes with which ciphertext, ... > attacker has to mount their attack is limited. ... > and propose a comment patch. ...
    (Linux-Kernel)
  • Re: New mode for AES: "Packet Mode"
    ... carry significant data in the first block, the ECB-like first block, ... For protocols that carry no information in the first ... the attacker can try to guess any previous plaintext block Px. ...
    (sci.crypt)
  • Re: Tightly stuffed crypto framing
    ... There are statements that using RSA directly to encrypt data is ... Signing only the plaintext thus would allow ... the attacker to decrypt the packages, ... retransmit them without breaking the signature. ...
    (sci.crypt)
  • Re: New mode for AES: "Packet Mode"
    ... since Encrypt is refering to AES Encrypt which requires a password! ... The attacker never has to guess the cipher text; he can read it from the ... As for guessing a plausible plaintext, ... character at a time; in that case, each plaintext might consist of one ...
    (sci.crypt)
  • Re: Bijective - an explanation please?
    ... :>of plaintext to just one. ... the attacker is faced with multiple plausible-looking messages. ... I advocate using AES, but AES shares ... advocates of pre-compression seem to be advocating it precisely because we ...
    (sci.crypt)