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

["James Landis" <jcl24@xxxxxxxxxxx>]

------=_Part_23240_26991567.1168019860644
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I never said your solution was WEAK, just that is is WEAKER. Yes, it is
still theoretically very difficult to construct valid tokens by breaking the
encryption algorithm, but it is certainly weaker to expose reconstructable
values to the client than to expose only a random value from the same
keyspace. Also note the class of insider attacks which involve gaining the
key and algorithm without reversing it. In addition, if the server is using
a published algorithm, the attacker can also mount chosen-key attacks as
well.

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.

If you apply the same restrictions (IP address + timestamp) to the session
method, it will be more secure than any algorithm which does not maintain
state simply due to the fact that you're placing some trust in the client.
However, it does have additional overhead. TANSTAAFL.

-j

On 1/5/07, Amit Klein <aksecurity@gmail.com> wrote:
>
> 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
>
>

------=_Part_23240_26991567.1168019860644
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I never said your solution was WEAK, just that is is WEAKER. Yes, it is still theoretically very difficult to construct valid tokens by breaking the encryption algorithm, but it is certainly weaker to expose reconstructable values to the client than to expose only a random value from the same keyspace. Also note the class of insider attacks which involve gaining the key and algorithm without reversing it. In addition, if the server is using a published algorithm, the attacker can also mount chosen-key attacks as well.
<br><br>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.<br><br>If you apply the same restrictions (IP address + timestamp) to the session method, it will be more secure than any algorithm which does not maintain state simply due to the fact that you&#39;re placing some trust in the client. However, it does have additional overhead. TANSTAAFL.
<br><br>-j<br><br><div><span class="gmail_quote">On 1/5/07, <b class="gmail_sendername">Amit Klein</b> &lt;<a href="mailto:aksecurity@gmail.com";>aksecurity@gmail.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
James Landis wrote:<br>&gt; More notes on Amit&#39;s remediation algorithm:<br>&gt;<br>&gt; Putting all of the identifying information into the token weakens the<br>&gt; defense because the attacker can mount known plaintext attacks against
<br>&gt; it.<br>Not precisely. First, the classic definition of &quot;known plaintext<br>attacks&quot; is that an attacker can observe both the plaintext and the<br>ciphertext, In our case, the attacker does see ciphertext, but he/she
<br>does not exactly see the plaintext. Obviously the IP is known, and the<br>server time is known up to some granularity, but if (say) you use the<br>microsecond clock, then an attacker will have a hard time guessing the
<br>*exact* plaintext.<br><br>I don&#39;t think known-plaintext attack should worry you if you use an<br>industrial strength encryption, but if you feel like hardening the<br>algorithm against this attack, you can always throw in a random number,
<br>or a secret string as part of the plaintext, and discard it upon decryption.<br>&gt; Putting things in perspective, even if the attacker breaks the<br>&gt; encryption algorithm, they still have to know the IP address of the
<br>&gt; target. However, a sufficiently clever attacker will simply create a<br>&gt; phishing scam which harvests IPs and creates custom URLs for each<br>&gt; victim. The algorithm will also be weakened against individually
<br>&gt; targeted attacks because like you said, it does not protect users<br>&gt; which appear to come from the same IP to the Web server.<br>&gt;<br>Even if the attacker knows the exact IP address of the victim, I don&#39;t
<br>see how this helps much. A good encryption algorithm will withstand a<br>known plaintext attack. And since the attacker cannot fake TCP traffic<br>coming from the victim&#39;s IP (unless the attacker and victim go out to
<br>the Internet from the same IP, or unless the attacker uses IP spoofing<br>techniques not suitable for our kind of attacks), I don&#39;t see how the<br>attacker can acquire a valid token for the attack.<br>&gt; Amit&#39;s solution is a tradeoff with maintaining state for the &quot;unique
<br>&gt; tokens&quot; described by RSnake. Unique tokes or nonces are a more secure<br>&gt; solution but using them incurs the additional overhead of tracking the<br>&gt; nonces. Amit&#39;s algorithm has no tracking overhead.
<br>Why are they secure? Please consider the attack scheme I described in<br><a href="http://www.webappsec.org/lists/websecurity/archive/2007-01/msg00065.html";>http://www.webappsec.org/lists/websecurity/archive/2007-01/msg00065.html
</a><br><br>-Amit<br><br></blockquote></div><br>

------=_Part_23240_26991567.1168019860644--