headers
Andrew Manore | 1 Jun 2009 21:07
Picon

S/MIME in Thunderbird

I'm not able to see what encryption algorithms Thunderbird 2.0.x is 
using. From what I've been able to tell (through downloading the 
encrypted message into Microsoft Outlook), Thunderbird is using 3DES 
encryption with SHA-1 hashes.

I'm wondering if there's any way to change the encryption to AES (any 
supported key length) and the hash to SHA-2. I'm also wondering if 
there's a way to verify the form of encryption used. There doesn't seem 
to be any option in the menus, nor any option in the advanced 
configuration editor.

Thanks!

-- Andrew Manore
Permalink | Reply | 0 comments |
headers
Brandon Sterne | 23 Jun 2009 01:15

Content Security Policy - Relaxed Restrictions Mode(s)

Some sites have shared the desire to use some features of CSP, but not
all of them at once.  For example, a site may want to utilize the
content loading features of CSP to help prevent data exfiltration, but
they may not want to be subject to the JavaScript restrictions which are
enabled by default (no inline script, no eval, etc.).

We have made two additions to the spec that we think will address these
needs:

1. Sites can opt-out of "no inline scripts" by adding the "inline"
keyword to their script-src directive.
2. Sites can opt-out of "no code from strings" by adding the "eval"
keyword to their script-src directive.

These additions may enable some sites, who would otherwise be deterred
by the JS restrictions, to adopt CSP in a limited fashion early, and
later do a full implementation as resources permit.

Cheers,
Brandon
Permalink | Reply | 0 comments |
headers
Serge van den Boom | 23 Jun 2009 15:13
Picon
Favicon

XSRF via CSP policy-uri

Hi,

If I'm not mistaken, there is a hypothetical situation where CSP can be
used to the benefit of an attacker. Consider the scenario where:
* the website contains a stored header injection vulnerability,
* the website contains a XSRF vulnerability, and
* the web client supports CSP.

To exploit a XSRF vulnerability, an attacker needs some way to direct
the web client to the vulnerable URL. This usually requires a social
engineering attack or a XSS vulnerability. A (stored) header injection
vulnerability is generally not enough.

However, by injecting an X-Content-Security-Policy header with the
policy-uri set to the vulnerable URL, the web client can be tricked into
visiting the vulnerable URL.

In practice, this scenario will not often occur, as stored header
injections are rare. And when it does occur, often also easier to
execute attacks are conceivable. Still, there is a small risk.

A solution to this problem would be to require the policy document to
have a fixed location on the website, instead of allowing it to be
specified through a URI.

Regards,

Serge
Permalink | Reply | 2 comments |
headers
Bil Corry | 23 Jun 2009 22:25

Re: XSRF via CSP policy-uri

Serge van den Boom wrote on 6/23/2009 8:13 AM: 
> However, by injecting an X-Content-Security-Policy header with the
> policy-uri set to the vulnerable URL, the web client can be tricked into
> visiting the vulnerable URL.

It would only work for those pages where a X-Content-Security-Policy header has not already been set --
additional X-Content-Security-Policy headers are ignored.  But beyond that, the proposed "Link"
header would provide the same attack surface, and can not be restricted to a known URI:

	http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-05.txt

Given that, I suggest keeping the CSP specification as-is.

- Bil
Permalink | Reply | 0 comments |
headers
Serge van den Boom | 23 Jun 2009 22:48
Picon
Favicon

Re: XSRF via CSP policy-uri

On 2009-06-23, Bil Corry <bil <at> corry.biz> wrote:
> Serge van den Boom wrote on 6/23/2009 8:13 AM: 
>> However, by injecting an X-Content-Security-Policy header with the
>> policy-uri set to the vulnerable URL, the web client can be tricked into
>> visiting the vulnerable URL.
>
> It would only work for those pages where a X-Content-Security-Policy
> header has not already been set -- additional
> X-Content-Security-Policy headers are ignored.

The injected header could be the first one though, with the genuine
header being ignored.

> But beyond that, the proposed "Link" header would provide the same
> attack surface, and can not be restricted to a known URI:

I was not familiar with that proposal, but skimming through it, it
appears that these links are not resolved automatically, making this
header less interesting for attackers. The same goes for the standard
"Content-Location" header.

Serge
Permalink | Reply | 1 comment |
headers
Bil Corry | 23 Jun 2009 23:41

Re: XSRF via CSP policy-uri

Serge van den Boom wrote on 6/23/2009 3:48 PM: 
> On 2009-06-23, Bil Corry <bil <at> corry.biz> wrote:
>> Serge van den Boom wrote on 6/23/2009 8:13 AM: 
>>> However, by injecting an X-Content-Security-Policy header with the
>>> policy-uri set to the vulnerable URL, the web client can be tricked into
>>> visiting the vulnerable URL.
>> It would only work for those pages where a X-Content-Security-Policy
>> header has not already been set -- additional
>> X-Content-Security-Policy headers are ignored.
> 
> The injected header could be the first one though, with the genuine
> header being ignored.

True, but the attacker could simply split the header and issue a redirect to any page they desire and skip
trying to exploit CSP entirely.

>> But beyond that, the proposed "Link" header would provide the same
>> attack surface, and can not be restricted to a known URI:
> 
> I was not familiar with that proposal, but skimming through it, it
> appears that these links are not resolved automatically, making this
> header less interesting for attackers. The same goes for the standard
> "Content-Location" header.

Section 5 indicates it's "semantically equivalent to the <LINK> element in HTML" -- so presumably that
means the browser will retrieve a stylesheet specified by the header before rendering the page.

- Bil
Permalink | Reply | 0 comments |
headers
Serge van den Boom | 24 Jun 2009 11:08
Picon
Favicon

Re: XSRF via CSP policy-uri

On 2009-06-23, Bil Corry <bil <at> corry.biz> wrote:
> Serge van den Boom wrote on 6/23/2009 3:48 PM: 
>> On 2009-06-23, Bil Corry <bil <at> corry.biz> wrote:
>>> Serge van den Boom wrote on 6/23/2009 8:13 AM: 
>>>> However, by injecting an X-Content-Security-Policy header with the
>>>> policy-uri set to the vulnerable URL, the web client can be tricked
>>>> into visiting the vulnerable URL.
>>> It would only work for those pages where a X-Content-Security-Policy
>>> header has not already been set -- additional
>>> X-Content-Security-Policy headers are ignored.
>> 
>> The injected header could be the first one though, with the genuine
>> header being ignored.
>
> True, but the attacker could simply split the header and issue a
> redirect to any page they desire and skip trying to exploit CSP
> entirely.

If you are thinking of adding a Location header: that shouldn't have any
effect unless you have a 3xx status code, which you can't influence with
a header injection.
However, the attacker could end the header in their injection, and add a
body of their own -- this was in fact what I was thinking of when I
wrote "when it does occur, often also easier to execute attacks are
conceivable." in my original posting. But it is conceivable that the
header injection vulnerability only allows for the insertion of a small
number of characters. In this case, CSP does actually make an exploit
possible which wasn't otherwise realizable.

Though I agree that the likelihood of these circumstances occurring in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brandon Sterne | 24 Jun 2009 19:31

Re: XSRF via CSP policy-uri

Serge van den Boom wrote:
> Hi,
> 
> If I'm not mistaken, there is a hypothetical situation where CSP can be
> used to the benefit of an attacker. Consider the scenario where:
> * the website contains a stored header injection vulnerability,
> * the website contains a XSRF vulnerability, and
> * the web client supports CSP.

So the premise is that the site already has a CSRF vuln and a header
injection vuln, and Content Security Policy provides a new way for an
attacker to forge a request from the victim to the target site.

> To exploit a XSRF vulnerability, an attacker needs some way to direct
> the web client to the vulnerable URL. This usually requires a social
> engineering attack or a XSS vulnerability. A (stored) header injection
> vulnerability is generally not enough.
> 
> However, by injecting an X-Content-Security-Policy header with the
> policy-uri set to the vulnerable URL, the web client can be tricked into
> visiting the vulnerable URL.

How did the attacker get the victim to visit the URL with the header
injection vuln in the first place?  If the attacker could get this far,
they could skip the CSP step altogether and have the victim go straight
to the CSRF URL.

Given the numerous ways to initiate a GET to a particular URL, I don't
believe CSP adds any significant new attack surface with the policy-uri
directive.  The attack scenario above also requires massive existing
(Continue reading)

Permalink | Reply | 0 comments |
headers
Serge van den Boom | 24 Jun 2009 21:49
Picon
Favicon

Re: XSRF via CSP policy-uri

On 2009-06-24, Brandon Sterne <bsterne <at> mozilla.com> wrote:
> So the premise is that the site already has a CSRF vuln and a header
> injection vuln, and Content Security Policy provides a new way for an
> attacker to forge a request from the victim to the target site.

Right.

> How did the attacker get the victim to visit the URL with the header
> injection vuln in the first place?  If the attacker could get this far,
> they could skip the CSP step altogether and have the victim go straight
> to the CSRF URL.

The victim doesn't have to visit the URL with the header injection
vulnerability, as I'm talking about a *stored* header injection
vulnerability.

An example:
A web application allows users to submit their own content. With new content,
the user may specify its language from a drop-down box.
When another user views the content, the language is sent along in the
Content-Language header.

Now the developers of the web appliction forgot to add code to check
server-side whether the specified language is valid.
The attacker manipulates the language field of the submission form,
and tries to use it to inject some dangerous URL. But as the
Content-Type header is already set to something harmless, there is no
point in manipulating the body.

But policy-uri to the rescue! The attacker sets the language to "en\n
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sid Stamm | 26 Jun 2009 18:44

Content Security Policy discussion (link)

Hi All,

Some discussion about CSP has recently popped up on the mozilla wiki:
https://wiki.mozilla.org/Talk:Security/CSP/Spec

I'm posting the link here in case anyone interested hasn't seen it yet. 
  Comments are welcomed (both here and there).

Cheers,
Sid
Permalink | Reply | 4 comments |

Gmane