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

["James Landis" <jcl24@xxxxxxxxxxx>]

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

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.
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.

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.

Another option: host PDF files on a domain with no other sensitive data,
eliminating the usefulness of the attack.

Again I would raise the question of whether remediation of this issue is the
Web developer's responsibility. Clearly the problem is with the installed
client software and just because it is possible to create a solution on the
server side which defeats the attacks, that shouldn't mean it is necessary.
Developers have enough work to do just to secure their own code, let alone
cleaning up after others' mistakes. Does anyone have good metrics about the
vulnerable userbase? My gut is this is much less pervasive than older
vulnerable Flash installations.

-j

On 1/4/07, Amit Klein <aksecurity@gmail.com> wrote:
>
> RSnake wrote:
> >
> > So I think your idea was partly good, the 301 redirection will knock off
> > the URL fragment, but it has nothing to do with GET vs POST, and you'll
> > need to redirect it to a unique token to prevent infinite loops or
> > someone just forwarding to a guessable token.
> BTW, "unique" isn't good enough. You'll note in my algorithm, it's tied
> to the IP of the client (and encrypted, so it cannot be predicted).
> Otherwise an attacker website can obtain a valid token by communicating
> directly with the target website, and then present the victim with a
> link + valid token + nasty fragment.
>
> -Amit
>

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

More notes on Amit&#39;s remediation algorithm:<br><br>Putting all of the identifying information into the token weakens the defense because the attacker can mount known plaintext attacks against it. 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.
<br><br>Amit&#39;s solution is a tradeoff with maintaining state for the &quot;unique tokens&quot; described by RSnake. Unique tokes or nonces are a more secure solution but using them incurs the additional overhead of tracking the nonces. Amit&#39;s algorithm has no tracking overhead.
<br><br>Another option: host PDF files on a domain with no other sensitive data, eliminating the usefulness of the attack.<br><br>Again I would raise the question of whether remediation of this issue is the Web developer&#39;s responsibility. Clearly the problem is with the installed client software and just because it is possible to create a solution on the server side which defeats the attacks, that shouldn&#39;t mean it is necessary. Developers have enough work to do just to secure their own code, let alone cleaning up after others&#39; mistakes. Does anyone have good metrics about the vulnerable userbase? My gut is this is much less pervasive than older vulnerable Flash installations.
<br><br>-j<br><br><div><span class="gmail_quote">On 1/4/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;">
RSnake wrote:<br>&gt;<br>&gt; So I think your idea was partly good, the 301 redirection will knock off<br>&gt; the URL fragment, but it has nothing to do with GET vs POST, and you&#39;ll<br>&gt; need to redirect it to a unique token to prevent infinite loops or
<br>&gt; someone just forwarding to a guessable token.<br>BTW, &quot;unique&quot; isn&#39;t good enough. You&#39;ll note in my algorithm, it&#39;s tied<br>to the IP of the client (and encrypted, so it cannot be predicted).
<br>Otherwise an attacker website can obtain a valid token by communicating<br>directly with the target website, and then present the victim with a<br>link + valid token + nasty fragment.<br><br>-Amit<br></blockquote></div>
<br>

------=_Part_13048_3695171.1167951916678--