CWE for overly permissive crossdomain.xml?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

CWE for overly permissive crossdomain.xml?

Seth Art

Would this fall under CSRF (352), something else, or should it have its own cwe?

Exploitation is very similar to csrf, but you can receive the data from the vitim's client request, so in some ways it can be more impactful.

Regards,

Seth Art

JA
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CWE for overly permissive crossdomain.xml?

JA
I think that the related CVEs are under 264
With that said, one more detailed could be created (covering various technologies like Flash, Silverlight), as CSP is used more frequently.

Regards

On Monday, February 24, 2014, Seth Art <[hidden email]> wrote:

Would this fall under CSRF (352), something else, or should it have its own cwe?

Exploitation is very similar to csrf, but you can receive the data from the vitim's client request, so in some ways it can be more impactful.

Regards,

Seth Art

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CWE for overly permissive crossdomain.xml?

Seth Art
Jerome,

Thanks for the info.  The only CVE that I could find that specifically speaks to an overly permissive crossdomain policy is: Improper permissions in Silverlight cross-domain policy (CVE-2012-2292).

And sure enough, the NVD does use CWE-264 for that CVE-2012-2292.

That being said, I do think a more specific CWE would be helpful. I am willing to help create one, but I'd need some direction as to where to start, where to submit, etc. 

Thanks again,

Seth


On Mon, Feb 24, 2014 at 10:46 AM, Jerome Athias <[hidden email]> wrote:
I think that the related CVEs are under 264
With that said, one more detailed could be created (covering various technologies like Flash, Silverlight), as CSP is used more frequently.

Regards


On Monday, February 24, 2014, Seth Art <[hidden email]> wrote:

Would this fall under CSRF (352), something else, or should it have its own cwe?

Exploitation is very similar to csrf, but you can receive the data from the vitim's client request, so in some ways it can be more impactful.

Regards,

Seth Art


JA
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CWE for overly permissive crossdomain.xml?

JA
CVE-2010-3636,

CVE-2008-4822,

CVE-2007-6243

are other examples.


stolen descriptions, xss.cx

Flash cross-domain policy

Issue background

The Flash cross-domain policy controls whether Flash client components
running on other domains can perform two-way interaction with the
domain which publishes the policy. If another domain is allowed by the
policy, then that domain can potentially attack users of the
application. If a user is logged in to the application, and visits a
domain allowed by the policy, then any malicious content running on
that domain can potentially gain full access to the application within
the security context of the logged in user.

Even if an allowed domain is not overtly malicious in itself, security
vulnerabilities within that domain could potentially be leveraged by a
third-party attacker to exploit the trust relationship and attack the
application which allows access.

Issue remediation

You should review the domains which are allowed by the Flash
cross-domain policy and determine whether it is appropriate for the
application to fully trust both the intentions and security posture of
those domains.

Issue detail

The application publishes a Flash cross-domain policy which uses a
wildcard to specify allowed domains, and allows access from specific
other domains.

Using a wildcard to specify allowed domains means that any domain
matching the wildcard expression can perform two-way interaction with
this application. You should only use this policy if you fully trust
every possible web site that may reside on a domain which matches the
wildcard expression.

Allowing access from specific domains means that web sites on those
domains can perform two-way interaction with this application. You
should only use this policy if you fully trust the specific domains
allowed by the policy.




Silverlight cross-domain policy

Issue background

The Silverlight cross-domain policy controls whether Silverlight
client components running on other domains can perform two-way
interaction with the domain which publishes the policy. If another
domain is allowed by the policy, then that domain can potentially
attack users of the application. If a user is logged in to the
application, and visits a domain allowed by the policy, then any
malicious content running on that domain can potentially gain full
access to the application within the security context of the logged in
user.

Even if an allowed domain is not overtly malicious in itself, security
vulnerabilities within that domain could potentially be leveraged by a
third-party attacker to exploit the trust relationship and attack the
application which allows access.

Issue remediation

You should review the domains which are allowed by the Silverlight
cross-domain policy and determine whether it is appropriate for the
application to fully trust both the intentions and security posture of
those domains.

Issue detail

The application publishes a Silverlight cross-domain policy which uses
a wildcard to specify allowed domains, and allows access from specific
other domains.

Using a wildcard to specify allowed domains means that any domain
matching the wildcard expression can perform two-way interaction with
this application. You should only use this policy if you fully trust
every possible web site that may reside on a domain which matches the
wildcard expression.

Allowing access from specific domains means that web sites on those
domains can perform two-way interaction with this application. You
should only use this policy if you fully trust the specific domains
allowed by the policy.

2014-02-25 5:55 GMT+03:00 Seth Art <[hidden email]>:

> Jerome,
>
> Thanks for the info.  The only CVE that I could find that specifically
> speaks to an overly permissive crossdomain policy is: Improper permissions
> in Silverlight cross-domain policy (CVE-2012-2292).
>
> And sure enough, the NVD does use CWE-264 for that CVE-2012-2292.
>
> That being said, I do think a more specific CWE would be helpful. I am
> willing to help create one, but I'd need some direction as to where to
> start, where to submit, etc.
>
> Thanks again,
>
> Seth
>
>
> On Mon, Feb 24, 2014 at 10:46 AM, Jerome Athias <[hidden email]>
> wrote:
>>
>> I think that the related CVEs are under 264
>> With that said, one more detailed could be created (covering various
>> technologies like Flash, Silverlight), as CSP is used more frequently.
>>
>> Regards
>>
>>
>> On Monday, February 24, 2014, Seth Art <[hidden email]> wrote:
>>>
>>> Would this fall under CSRF (352), something else, or should it have its
>>> own cwe?
>>>
>>> Exploitation is very similar to csrf, but you can receive the data from
>>> the vitim's client request, so in some ways it can be more impactful.
>>>
>>> Regards,
>>>
>>> Seth Art
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CWE for overly permissive crossdomain.xml?

Seth Art
Those descriptions are great.   What is the next step in creating a CWE for this?  I am not at all familiar with the process.




On Tue, Feb 25, 2014 at 12:49 AM, Jerome Athias <[hidden email]> wrote:
CVE-2010-3636,

CVE-2008-4822,

CVE-2007-6243

are other examples.


stolen descriptions, xss.cx

Flash cross-domain policy

Issue background

The Flash cross-domain policy controls whether Flash client components
running on other domains can perform two-way interaction with the
domain which publishes the policy. If another domain is allowed by the
policy, then that domain can potentially attack users of the
application. If a user is logged in to the application, and visits a
domain allowed by the policy, then any malicious content running on
that domain can potentially gain full access to the application within
the security context of the logged in user.

Even if an allowed domain is not overtly malicious in itself, security
vulnerabilities within that domain could potentially be leveraged by a
third-party attacker to exploit the trust relationship and attack the
application which allows access.

Issue remediation

You should review the domains which are allowed by the Flash
cross-domain policy and determine whether it is appropriate for the
application to fully trust both the intentions and security posture of
those domains.

Issue detail

The application publishes a Flash cross-domain policy which uses a
wildcard to specify allowed domains, and allows access from specific
other domains.

Using a wildcard to specify allowed domains means that any domain
matching the wildcard expression can perform two-way interaction with
this application. You should only use this policy if you fully trust
every possible web site that may reside on a domain which matches the
wildcard expression.

Allowing access from specific domains means that web sites on those
domains can perform two-way interaction with this application. You
should only use this policy if you fully trust the specific domains
allowed by the policy.




Silverlight cross-domain policy

Issue background

The Silverlight cross-domain policy controls whether Silverlight
client components running on other domains can perform two-way
interaction with the domain which publishes the policy. If another
domain is allowed by the policy, then that domain can potentially
attack users of the application. If a user is logged in to the
application, and visits a domain allowed by the policy, then any
malicious content running on that domain can potentially gain full
access to the application within the security context of the logged in
user.

Even if an allowed domain is not overtly malicious in itself, security
vulnerabilities within that domain could potentially be leveraged by a
third-party attacker to exploit the trust relationship and attack the
application which allows access.

Issue remediation

You should review the domains which are allowed by the Silverlight
cross-domain policy and determine whether it is appropriate for the
application to fully trust both the intentions and security posture of
those domains.

Issue detail

The application publishes a Silverlight cross-domain policy which uses
a wildcard to specify allowed domains, and allows access from specific
other domains.

Using a wildcard to specify allowed domains means that any domain
matching the wildcard expression can perform two-way interaction with
this application. You should only use this policy if you fully trust
every possible web site that may reside on a domain which matches the
wildcard expression.

Allowing access from specific domains means that web sites on those
domains can perform two-way interaction with this application. You
should only use this policy if you fully trust the specific domains
allowed by the policy.

2014-02-25 5:55 GMT+03:00 Seth Art <[hidden email]>:
> Jerome,
>
> Thanks for the info.  The only CVE that I could find that specifically
> speaks to an overly permissive crossdomain policy is: Improper permissions
> in Silverlight cross-domain policy (CVE-2012-2292).
>
> And sure enough, the NVD does use CWE-264 for that CVE-2012-2292.
>
> That being said, I do think a more specific CWE would be helpful. I am
> willing to help create one, but I'd need some direction as to where to
> start, where to submit, etc.
>
> Thanks again,
>
> Seth
>
>
> On Mon, Feb 24, 2014 at 10:46 AM, Jerome Athias <[hidden email]>
> wrote:
>>
>> I think that the related CVEs are under 264
>> With that said, one more detailed could be created (covering various
>> technologies like Flash, Silverlight), as CSP is used more frequently.
>>
>> Regards
>>
>>
>> On Monday, February 24, 2014, Seth Art <[hidden email]> wrote:
>>>
>>> Would this fall under CSRF (352), something else, or should it have its
>>> own cwe?
>>>
>>> Exploitation is very similar to csrf, but you can receive the data from
>>> the vitim's client request, so in some ways it can be more impactful.
>>>
>>> Regards,
>>>
>>> Seth Art
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

FW: CWE for overly permissive crossdomain.xml?

Christey, Steven M.


-----Original Message-----
From: Seth Art [mailto:[hidden email]]
Sent: Tuesday, August 26, 2014 1:57 PM
To: Jerome Athias
Cc: cwe-research-list CWE Research Discussion
Subject: Re: CWE for overly permissive crossdomain.xml?

This   message   was  originally   submitted   by   [hidden email]  to   the
CWE-RESEARCH-LIST list at LISTS.MITRE.ORG. If you simply forward it back to the
list, using a mail command that generates "Resent-" fields (ask your local user
support or consult the documentation of your mail program if in doubt), it will
be  distributed and  the  explanations  you are  now  reading  will be  removed
automatically. If on the other hand you edit the contributions you receive into
a digest, you will have to  remove this paragraph manually. Finally, you should
be able  to contact  the author  of this  message by  using the  normal "reply"
function of your mail program.

---------------- Message requiring your approval (214 lines) ------------------
I just noticed that "CWE-942: Overly Permissive Cross-domain
Whitelist" has been created.  That is great!

For the first line in the extended description, I'd like to suggest a
small change:

Current: A cross-domain policy file ("crossdomain.xml" in Flash and
"clientaccesspolicy.xml" in Silverlight) defines a whitelist of
domains from which a server is allowed to make cross-domain requests.

Proposed: A cross-domain policy file ("crossdomain.xml" in Flash and
"clientaccesspolicy.xml" in Silverlight) defines a whitelist of
domains from which a client side Rich Internet Application
(Flash,Silverlight) loaded from an external domain is allowed to make
cross-domain requests to the managed domain.

I think a lot of the confusion around this vulnerability exists
because most language talks about the attack as if it is launched from
the server, where really it is loaded from the server, but launched
from the browser, just like CSRF.   Just my $.02

For the references, I suggest considering:


http://shiflett.org/blog/2006/sep/the-dangers-of-cross-domain-ajax-with-flash
http://jeremiahgrossman.blogspot.com/2006/10/crossdomainxml-statistics.html
http://gursevkalra.blogspot.com/2013/08/bypassing-same-origin-policy-with-flash.html
http://sethsec.blogspot.com/2014/03/exploiting-misconfigured-crossdomainxml.html

Also, may I suggest using CVE-2014-2227
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2227) as an
Observed Example.

Thanks for adding this CWE!

Actually, I just read through the rest of the description, and I have
one more modification:

Current: The attacker could transfer private information, such as
cookies that may include session information, from the victim's
machine to the attacker.

As far as I know, the attacker can not access the user's cookies using
a malicious flash object.  This is a restriction built into the flash
player.  The attacker can execute a CSRF attack which use the victim's
cookies, but they will never actually see the cookies.

If someone knows otherwise, I'd be really interested in knowing how
you can do it -- but as far as I can tell, it is not possible to
read/view/steal/access cookies via action script.

The rest of the CWE looks great!


Regards,

Seth Art

On Fri, Feb 28, 2014 at 2:22 PM, Seth Art <[hidden email]> wrote:

> Those descriptions are great.   What is the next step in creating a CWE for
> this?  I am not at all familiar with the process.
>
>
>
>
> On Tue, Feb 25, 2014 at 12:49 AM, Jerome Athias <[hidden email]>
> wrote:
>>
>> CVE-2010-3636,
>>
>> CVE-2008-4822,
>>
>> CVE-2007-6243
>>
>> are other examples.
>>
>>
>> stolen descriptions, xss.cx
>>
>> Flash cross-domain policy
>>
>> Issue background
>>
>> The Flash cross-domain policy controls whether Flash client components
>> running on other domains can perform two-way interaction with the
>> domain which publishes the policy. If another domain is allowed by the
>> policy, then that domain can potentially attack users of the
>> application. If a user is logged in to the application, and visits a
>> domain allowed by the policy, then any malicious content running on
>> that domain can potentially gain full access to the application within
>> the security context of the logged in user.
>>
>> Even if an allowed domain is not overtly malicious in itself, security
>> vulnerabilities within that domain could potentially be leveraged by a
>> third-party attacker to exploit the trust relationship and attack the
>> application which allows access.
>>
>> Issue remediation
>>
>> You should review the domains which are allowed by the Flash
>> cross-domain policy and determine whether it is appropriate for the
>> application to fully trust both the intentions and security posture of
>> those domains.
>>
>> Issue detail
>>
>> The application publishes a Flash cross-domain policy which uses a
>> wildcard to specify allowed domains, and allows access from specific
>> other domains.
>>
>> Using a wildcard to specify allowed domains means that any domain
>> matching the wildcard expression can perform two-way interaction with
>> this application. You should only use this policy if you fully trust
>> every possible web site that may reside on a domain which matches the
>> wildcard expression.
>>
>> Allowing access from specific domains means that web sites on those
>> domains can perform two-way interaction with this application. You
>> should only use this policy if you fully trust the specific domains
>> allowed by the policy.
>>
>>
>>
>>
>> Silverlight cross-domain policy
>>
>> Issue background
>>
>> The Silverlight cross-domain policy controls whether Silverlight
>> client components running on other domains can perform two-way
>> interaction with the domain which publishes the policy. If another
>> domain is allowed by the policy, then that domain can potentially
>> attack users of the application. If a user is logged in to the
>> application, and visits a domain allowed by the policy, then any
>> malicious content running on that domain can potentially gain full
>> access to the application within the security context of the logged in
>> user.
>>
>> Even if an allowed domain is not overtly malicious in itself, security
>> vulnerabilities within that domain could potentially be leveraged by a
>> third-party attacker to exploit the trust relationship and attack the
>> application which allows access.
>>
>> Issue remediation
>>
>> You should review the domains which are allowed by the Silverlight
>> cross-domain policy and determine whether it is appropriate for the
>> application to fully trust both the intentions and security posture of
>> those domains.
>>
>> Issue detail
>>
>> The application publishes a Silverlight cross-domain policy which uses
>> a wildcard to specify allowed domains, and allows access from specific
>> other domains.
>>
>> Using a wildcard to specify allowed domains means that any domain
>> matching the wildcard expression can perform two-way interaction with
>> this application. You should only use this policy if you fully trust
>> every possible web site that may reside on a domain which matches the
>> wildcard expression.
>>
>> Allowing access from specific domains means that web sites on those
>> domains can perform two-way interaction with this application. You
>> should only use this policy if you fully trust the specific domains
>> allowed by the policy.
>>
>> 2014-02-25 5:55 GMT+03:00 Seth Art <[hidden email]>:
>> > Jerome,
>> >
>> > Thanks for the info.  The only CVE that I could find that specifically
>> > speaks to an overly permissive crossdomain policy is: Improper
>> > permissions
>> > in Silverlight cross-domain policy (CVE-2012-2292).
>> >
>> > And sure enough, the NVD does use CWE-264 for that CVE-2012-2292.
>> >
>> > That being said, I do think a more specific CWE would be helpful. I am
>> > willing to help create one, but I'd need some direction as to where to
>> > start, where to submit, etc.
>> >
>> > Thanks again,
>> >
>> > Seth
>> >
>> >
>> > On Mon, Feb 24, 2014 at 10:46 AM, Jerome Athias <[hidden email]>
>> > wrote:
>> >>
>> >> I think that the related CVEs are under 264
>> >> With that said, one more detailed could be created (covering various
>> >> technologies like Flash, Silverlight), as CSP is used more frequently.
>> >>
>> >> Regards
>> >>
>> >>
>> >> On Monday, February 24, 2014, Seth Art <[hidden email]> wrote:
>> >>>
>> >>> Would this fall under CSRF (352), something else, or should it have
>> >>> its
>> >>> own cwe?
>> >>>
>> >>> Exploitation is very similar to csrf, but you can receive the data
>> >>> from
>> >>> the vitim's client request, so in some ways it can be more impactful.
>> >>>
>> >>> Regards,
>> >>>
>> >>> Seth Art
>> >
>> >
>
>

Loading...