Danger of Content-Location HTTP response header

[Andrew Arnott]

Just a heads up from something I recently became aware of that impacted older versions of dotnetopenid.

The HTTP protocol defines a Content-Location HTTP response header that allows the web server to suggest to the client that another URL would be equivalent to the one that client actually pulled from.  It is not a redirect, but merely a suggestion that two URLs are equivalent.  For the purposes of OpenID claimed identifier discovery, it is imperative that an OpenID RP ignore this header, lest a web server upon which discovery was performed can spoof an arbitrary claimed_id's identity by fooling the RP into thinking it discovered an identifier that in fact it did not.

In particular, .NET's "helpful" HTTP stack automatically reads this header and reports it to the client as if it was in fact that actual URL that was pulled from even though it wasn't.  Since .NET follows redirects automatically by default, a legitimate redirect and this Content-Location header are indiscernable, which is really bad.  This is fixed in the dotnetopenid and dotnetopenauth libraries.

Other RP library/site authors should verify that the HTTP stack they are using ignore this header, or workaround the issue.  

I've set up a test on test-id.org where an RP can very quickly assess whether they are vulnerable.  Please take a moment to find out, and fix it ASAP if you are.

http://test-id.org/RP/IgnoresContentLocationHeader.aspx

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

_______________________________________________
security mailing list
security@...
http://lists.openid.net/mailman/listinfo/openid-security

[Allen Tom-2]

Hi Andrew,

Would an attacker be able to exploit this issue by returning the Content-Location HTTP response header for an URL that he owns, making his URL equivalent to a victim's OpenID? How is this different from having the attacker delegating his URL to the victim's OpenID?

Can you outline a scenario where the Content-Location HTTP header is exploited?

Thanks
Allen



Arnott wrote:

Just a heads up from something I recently became aware of that impacted older versions of dotnetopenid.

The HTTP protocol defines a Content-Location HTTP response header that allows the web server to suggest to the client that another URL would be equivalent to the one that client actually pulled from.  It is not a redirect, but merely a suggestion that two URLs are equivalent.  For the purposes of OpenID claimed identifier discovery, it is imperative that an OpenID RP ignore this header, lest a web server upon which discovery was performed can spoof an arbitrary claimed_id's identity by fooling the RP into thinking it discovered an identifier that in fact it did not.

In particular, .NET's "helpful" HTTP stack automatically reads this header and reports it to the client as if it was in fact that actual URL that was pulled from even though it wasn't.  Since .NET follows redirects automatically by default, a legitimate redirect and this Content-Location header are indiscernable, which is really bad.  This is fixed in the dotnetopenid and dotnetopenauth libraries.

Other RP library/site authors should verify that the HTTP stack they are using ignore this header, or workaround the issue.  

I've set up a test on test-id.org where an RP can very quickly assess whether they are vulnerable.  Please take a moment to find out, and fix it ASAP if you are.

http://test-id.org/RP/IgnoresContentLocationHeader.aspx

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

_______________________________________________
security mailing list
security@...
http://lists.openid.net/mailman/listinfo/openid-security
  

_______________________________________________
security mailing list
security@...
http://lists.openid.net/mailman/listinfo/openid-security

[John Bradley-9]

This is a attack on discovery.

If the RP performs discovery on URL A the owner of URL A can return a XRDS with a content-Location header for URL B.  The RP now believes that whatever OP endpoint is in the XRDS is authoritative for URL B without having retrieved the actual XRDS for it, only the one for URL A claiming to be B.

The problem is that .Net "helps" the application by making it think a redirect has taken place when it hasn't.

There are lots of times when this works just fine however the claimed_id is tied to the product of the second normalization so is vulnerable to this sort of fake redirect.

Andrew can provide more of the details.

John B.

On 2009-11-14, at 2:24 PM, Allen Tom wrote:

Hi Andrew,

Would an attacker be able to exploit this issue by returning the Content-Location HTTP response header for an URL that he owns, making his URL equivalent to a victim's OpenID? How is this different from having the attacker delegating his URL to the victim's OpenID?

Can you outline a scenario where the Content-Location HTTP header is exploited?

Thanks
Allen



Arnott wrote:

Just a heads up from something I recently became aware of that impacted older versions of dotnetopenid.

The HTTP protocol defines a Content-Location HTTP response header that allows the web server to suggest to the client that another URL would be equivalent to the one that client actually pulled from.  It is not a redirect, but merely a suggestion that two URLs are equivalent.  For the purposes of OpenID claimed identifier discovery, it is imperative that an OpenID RP ignore this header, lest a web server upon which discovery was performed can spoof an arbitrary claimed_id's identity by fooling the RP into thinking it discovered an identifier that in fact it did not.

In particular, .NET's "helpful" HTTP stack automatically reads this header and reports it to the client as if it was in fact that actual URL that was pulled from even though it wasn't.  Since .NET follows redirects automatically by default, a legitimate redirect and this Content-Location header are indiscernable, which is really bad.  This is fixed in the dotnetopenid and dotnetopenauth libraries.

Other RP library/site authors should verify that the HTTP stack they are using ignore this header, or workaround the issue.  

I've set up a test on test-id.org where an RP can very quickly assess whether they are vulnerable.  Please take a moment to find out, and fix it ASAP if you are.

http://test-id.org/RP/IgnoresContentLocationHeader.aspx

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

_______________________________________________
security mailing list
security@...
http://lists.openid.net/mailman/listinfo/openid-security
  

_______________________________________________
security mailing list
security@...
http://lists.openid.net/mailman/listinfo/openid-security

_______________________________________________
security mailing list
security@...
http://lists.openid.net/mailman/listinfo/openid-security

[Andrew Arnott]

That's right, John.

For a vulnerable RP, an attacker could set up any URL to impersonate any other user at the RP simply by logging into the RP with his own URL, after configuring it to send back the Content-Location header with the victim's claimed_id as its value.  

I've confirmed that the extremeswankopenid library is vulnerable to this attack, and have contacted the author already.

Regarding your question about how this is different than delegating your identifier to a victim's OpenID... I'm not familiar with such an approach, or how that would be exploited.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

On Sat, Nov 14, 2009 at 10:50 AM, John Bradley <ve7jtb@...> wrote:

This is a attack on discovery.

If the RP performs discovery on URL A the owner of URL A can return a XRDS with a content-Location header for URL B.  The RP now believes that whatever OP endpoint is in the XRDS is authoritative for URL B without having retrieved the actual XRDS for it, only the one for URL A claiming to be B.

The problem is that .Net "helps" the application by making it think a redirect has taken place when it hasn't.

There are lots of times when this works just fine however the claimed_id is tied to the product of the second normalization so is vulnerable to this sort of fake redirect.

Andrew can provide more of the details.

John B.

On 2009-11-14, at 2:24 PM, Allen Tom wrote:

Hi Andrew,

Would an attacker be able to exploit this issue by returning the Content-Location HTTP response header for an URL that he owns, making his URL equivalent to a victim's OpenID? How is this different from having the attacker delegating his URL to the victim's OpenID?

Can you outline a scenario where the Content-Location HTTP header is exploited?

Thanks
Allen



Arnott wrote:

Just a heads up from something I recently became aware of that impacted older versions of dotnetopenid.

The HTTP protocol defines a Content-Location HTTP response header that allows the web server to suggest to the client that another URL would be equivalent to the one that client actually pulled from.  It is not a redirect, but merely a suggestion that two URLs are equivalent.  For the purposes of OpenID claimed identifier discovery, it is imperative that an OpenID RP ignore this header, lest a web server upon which discovery was performed can spoof an arbitrary claimed_id's identity by fooling the RP into thinking it discovered an identifier that in fact it did not.

In particular, .NET's "helpful" HTTP stack automatically reads this header and reports it to the client as if it was in fact that actual URL that was pulled from even though it wasn't.  Since .NET follows redirects automatically by default, a legitimate redirect and this Content-Location header are indiscernable, which is really bad.  This is fixed in the dotnetopenid and dotnetopenauth libraries.

Other RP library/site authors should verify that the HTTP stack they are using ignore this header, or workaround the issue.  

I've set up a test on test-id.org where an RP can very quickly assess whether they are vulnerable.  Please take a moment to find out, and fix it ASAP if you are.

http://test-id.org/RP/IgnoresContentLocationHeader.aspx

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

_______________________________________________
security mailing list
security@...
http://lists.openid.net/mailman/listinfo/openid-security
  

_______________________________________________
security mailing list
security@...
http://lists.openid.net/mailman/listinfo/openid-security

_______________________________________________
security mailing list
security@...
http://lists.openid.net/mailman/listinfo/openid-security

[Breno de Medeiros]

Andrew,

This is a sufficiently significant risk that should be documented in
the security wiki. I encourage you to do so.

On Sat, Nov 14, 2009 at 7:21 PM, Andrew Arnott <andrewarnott@...> wrote:

> That's right, John.
> For a vulnerable RP, an attacker could set up any URL to impersonate any
> other user at the RP simply by logging into the RP with his own URL, after
> configuring it to send back the Content-Location header with the victim's
> claimed_id as its value.
> I've confirmed that the extremeswankopenid library is vulnerable to this
> attack, and have contacted the author already.
> Regarding your question about how this is different than delegating your
> identifier to a victim's OpenID... I'm not familiar with such an approach,
> or how that would be exploited.
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>
>
> On Sat, Nov 14, 2009 at 10:50 AM, John Bradley <ve7jtb@...> wrote:
>>
>> This is a attack on discovery.
>> If the RP performs discovery on URL A the owner of URL A can return a XRDS
>> with a content-Location header for URL B.  The RP now believes that whatever
>> OP endpoint is in the XRDS is authoritative for URL B without having
>> retrieved the actual XRDS for it, only the one for URL A claiming to be B.
>> The problem is that .Net "helps" the application by making it think a
>> redirect has taken place when it hasn't.
>> There are lots of times when this works just fine however the claimed_id
>> is tied to the product of the second normalization so is vulnerable to this
>> sort of fake redirect.
>> Andrew can provide more of the details.
>> John B.
>> On 2009-11-14, at 2:24 PM, Allen Tom wrote:
>>
>> Hi Andrew,
>>
>> Would an attacker be able to exploit this issue by returning the
>> Content-Location HTTP response header for an URL that he owns, making his
>> URL equivalent to a victim's OpenID? How is this different from having the
>> attacker delegating his URL to the victim's OpenID?
>>
>> Can you outline a scenario where the Content-Location HTTP header is
>> exploited?
>>
>> Thanks
>> Allen
>>
>>
>>
>> Arnott wrote:
>>
>> Just a heads up from something I recently became aware of that impacted
>> older versions of dotnetopenid.
>> The HTTP protocol defines a Content-Location HTTP response header that
>> allows the web server to suggest to the client that another URL would be
>> equivalent to the one that client actually pulled from.  It is not a
>> redirect, but merely a suggestion that two URLs are equivalent.  For the
>> purposes of OpenID claimed identifier discovery, it is imperative that an
>> OpenID RP ignore this header, lest a web server upon which discovery was
>> performed can spoof an arbitrary claimed_id's identity by fooling the RP
>> into thinking it discovered an identifier that in fact it did not.
>> In particular, .NET's "helpful" HTTP stack automatically reads this header
>> and reports it to the client as if it was in fact that actual URL that was
>> pulled from even though it wasn't.  Since .NET follows redirects
>> automatically by default, a legitimate redirect and this Content-Location
>> header are indiscernable, which is really bad.  This is fixed in the
>> dotnetopenid and dotnetopenauth libraries.
>> Other RP library/site authors should verify that the HTTP stack they are
>> using ignore this header, or workaround the issue.
>> I've set up a test on test-id.org where an RP can very quickly assess
>> whether they are vulnerable.  Please take a moment to find out, and fix it
>> ASAP if you are.
>> http://test-id.org/RP/IgnoresContentLocationHeader.aspx
>> --
>> Andrew Arnott
>> "I [may] not agree with what you have to say, but I'll defend to the death
>> your right to say it." - S. G. Tallentyre
>>
>> ________________________________
>> _______________________________________________
>> security mailing list
>> security@...
>> http://lists.openid.net/mailman/listinfo/openid-security
>>
>>
>> _______________________________________________
>> security mailing list
>> security@...
>> http://lists.openid.net/mailman/listinfo/openid-security
>>
>
>
> _______________________________________________
> security mailing list
> security@...
> http://lists.openid.net/mailman/listinfo/openid-security
>
>

--
--Breno

[phone] desk
[phone] (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
_______________________________________________
security mailing list
security@...
http://lists.openid.net/mailman/listinfo/openid-security

[Andrew Arnott]

I'll do that.  Thanks.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

On Mon, Nov 16, 2009 at 10:06 AM, Breno de Medeiros <breno@...> wrote:

Andrew,

This is a sufficiently significant risk that should be documented in
the security wiki. I encourage you to do so.

On Sat, Nov 14, 2009 at 7:21 PM, Andrew Arnott <andrewarnott@...> wrote:
> That's right, John.
> For a vulnerable RP, an attacker could set up any URL to impersonate any
> other user at the RP simply by logging into the RP with his own URL, after
> configuring it to send back the Content-Location header with the victim's
> claimed_id as its value.
> I've confirmed that the extremeswankopenid library is vulnerable to this
> attack, and have contacted the author already.
> Regarding your question about how this is different than delegating your
> identifier to a victim's OpenID... I'm not familiar with such an approach,
> or how that would be exploited.
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>
>
> On Sat, Nov 14, 2009 at 10:50 AM, John Bradley <ve7jtb@...> wrote:
>>
>> This is a attack on discovery.
>> If the RP performs discovery on URL A the owner of URL A can return a XRDS
>> with a content-Location header for URL B.  The RP now believes that whatever
>> OP endpoint is in the XRDS is authoritative for URL B without having
>> retrieved the actual XRDS for it, only the one for URL A claiming to be B.
>> The problem is that .Net "helps" the application by making it think a
>> redirect has taken place when it hasn't.
>> There are lots of times when this works just fine however the claimed_id
>> is tied to the product of the second normalization so is vulnerable to this
>> sort of fake redirect.
>> Andrew can provide more of the details.
>> John B.
>> On 2009-11-14, at 2:24 PM, Allen Tom wrote:
>>
>> Hi Andrew,
>>
>> Would an attacker be able to exploit this issue by returning the
>> Content-Location HTTP response header for an URL that he owns, making his
>> URL equivalent to a victim's OpenID? How is this different from having the
>> attacker delegating his URL to the victim's OpenID?
>>
>> Can you outline a scenario where the Content-Location HTTP header is
>> exploited?
>>
>> Thanks
>> Allen
>>
>>
>>
>> Arnott wrote:
>>
>> Just a heads up from something I recently became aware of that impacted
>> older versions of dotnetopenid.
>> The HTTP protocol defines a Content-Location HTTP response header that
>> allows the web server to suggest to the client that another URL would be
>> equivalent to the one that client actually pulled from.  It is not a
>> redirect, but merely a suggestion that two URLs are equivalent.  For the
>> purposes of OpenID claimed identifier discovery, it is imperative that an
>> OpenID RP ignore this header, lest a web server upon which discovery was
>> performed can spoof an arbitrary claimed_id's identity by fooling the RP
>> into thinking it discovered an identifier that in fact it did not.
>> In particular, .NET's "helpful" HTTP stack automatically reads this header
>> and reports it to the client as if it was in fact that actual URL that was
>> pulled from even though it wasn't.  Since .NET follows redirects
>> automatically by default, a legitimate redirect and this Content-Location
>> header are indiscernable, which is really bad.  This is fixed in the
>> dotnetopenid and dotnetopenauth libraries.
>> Other RP library/site authors should verify that the HTTP stack they are
>> using ignore this header, or workaround the issue.
>> I've set up a test on test-id.org where an RP can very quickly assess
>> whether they are vulnerable.  Please take a moment to find out, and fix it
>> ASAP if you are.
>> http://test-id.org/RP/IgnoresContentLocationHeader.aspx
>> --
>> Andrew Arnott
>> "I [may] not agree with what you have to say, but I'll defend to the death
>> your right to say it." - S. G. Tallentyre
>>
>> ________________________________
>> _______________________________________________
>> security mailing list
>> security@...
>> http://lists.openid.net/mailman/listinfo/openid-security
>>
>>
>> _______________________________________________
>> security mailing list
>> security@...
>> http://lists.openid.net/mailman/listinfo/openid-security
>>
>
>
> _______________________________________________
> security mailing list
> security@...
> http://lists.openid.net/mailman/listinfo/openid-security
>
>

--
--Breno

[phone] desk
[phone] (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

_______________________________________________
security mailing list
security@...
http://lists.openid.net/mailman/listinfo/openid-security

[Andrew Arnott]

I've added it to http://wiki.openid.net/Reported_Security_Issues, 

Although between these URLs, and their content, it was difficult to figure out exactly where was most appropriate.  So let me know if I guessed wrong.

http://wiki.openid.net/Security

http://wiki.openid.net/SecurityIssues

http://wiki.openid.net/Reported_Security_Issues

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

On Mon, Nov 16, 2009 at 10:42 AM, Andrew Arnott <andrewarnott@...> wrote:

I'll do that.  Thanks.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

On Mon, Nov 16, 2009 at 10:06 AM, Breno de Medeiros <breno@...> wrote:

Andrew,

This is a sufficiently significant risk that should be documented in
the security wiki. I encourage you to do so.

On Sat, Nov 14, 2009 at 7:21 PM, Andrew Arnott <andrewarnott@...> wrote:
> That's right, John.
> For a vulnerable RP, an attacker could set up any URL to impersonate any
> other user at the RP simply by logging into the RP with his own URL, after
> configuring it to send back the Content-Location header with the victim's
> claimed_id as its value.
> I've confirmed that the extremeswankopenid library is vulnerable to this
> attack, and have contacted the author already.
> Regarding your question about how this is different than delegating your
> identifier to a victim's OpenID... I'm not familiar with such an approach,
> or how that would be exploited.
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>
>
> On Sat, Nov 14, 2009 at 10:50 AM, John Bradley <ve7jtb@...> wrote:
>>
>> This is a attack on discovery.
>> If the RP performs discovery on URL A the owner of URL A can return a XRDS
>> with a content-Location header for URL B.  The RP now believes that whatever
>> OP endpoint is in the XRDS is authoritative for URL B without having
>> retrieved the actual XRDS for it, only the one for URL A claiming to be B.
>> The problem is that .Net "helps" the application by making it think a
>> redirect has taken place when it hasn't.
>> There are lots of times when this works just fine however the claimed_id
>> is tied to the product of the second normalization so is vulnerable to this
>> sort of fake redirect.
>> Andrew can provide more of the details.
>> John B.
>> On 2009-11-14, at 2:24 PM, Allen Tom wrote:
>>
>> Hi Andrew,
>>
>> Would an attacker be able to exploit this issue by returning the
>> Content-Location HTTP response header for an URL that he owns, making his
>> URL equivalent to a victim's OpenID? How is this different from having the
>> attacker delegating his URL to the victim's OpenID?
>>
>> Can you outline a scenario where the Content-Location HTTP header is
>> exploited?
>>
>> Thanks
>> Allen
>>
>>
>>
>> Arnott wrote:
>>
>> Just a heads up from something I recently became aware of that impacted
>> older versions of dotnetopenid.
>> The HTTP protocol defines a Content-Location HTTP response header that
>> allows the web server to suggest to the client that another URL would be
>> equivalent to the one that client actually pulled from.  It is not a
>> redirect, but merely a suggestion that two URLs are equivalent.  For the
>> purposes of OpenID claimed identifier discovery, it is imperative that an
>> OpenID RP ignore this header, lest a web server upon which discovery was
>> performed can spoof an arbitrary claimed_id's identity by fooling the RP
>> into thinking it discovered an identifier that in fact it did not.
>> In particular, .NET's "helpful" HTTP stack automatically reads this header
>> and reports it to the client as if it was in fact that actual URL that was
>> pulled from even though it wasn't.  Since .NET follows redirects
>> automatically by default, a legitimate redirect and this Content-Location
>> header are indiscernable, which is really bad.  This is fixed in the
>> dotnetopenid and dotnetopenauth libraries.
>> Other RP library/site authors should verify that the HTTP stack they are
>> using ignore this header, or workaround the issue.
>> I've set up a test on test-id.org where an RP can very quickly assess
>> whether they are vulnerable.  Please take a moment to find out, and fix it
>> ASAP if you are.
>> http://test-id.org/RP/IgnoresContentLocationHeader.aspx
>> --
>> Andrew Arnott
>> "I [may] not agree with what you have to say, but I'll defend to the death
>> your right to say it." - S. G. Tallentyre
>>
>> ________________________________
>> _______________________________________________
>> security mailing list
>> security@...
>> http://lists.openid.net/mailman/listinfo/openid-security
>>
>>
>> _______________________________________________
>> security mailing list
>> security@...
>> http://lists.openid.net/mailman/listinfo/openid-security
>>
>
>
> _______________________________________________
> security mailing list
> security@...
> http://lists.openid.net/mailman/listinfo/openid-security
>
>

--
--Breno

[phone] desk
[phone] (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

_______________________________________________
security mailing list
security@...
http://lists.openid.net/mailman/listinfo/openid-security

[Breno de Medeiros]

Hmmm... we need to consolidate these locations ... Suggestions?

On Mon, Nov 16, 2009 at 11:00 AM, Andrew Arnott <andrewarnott@...> wrote:

> I've added it to http://wiki.openid.net/Reported_Security_Issues,
> Although between these URLs, and their content, it was difficult to figure
> out exactly where was most appropriate.  So let me know if I guessed wrong.
> http://wiki.openid.net/Security
> http://wiki.openid.net/SecurityIssues
> http://wiki.openid.net/Reported_Security_Issues
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>
>
> On Mon, Nov 16, 2009 at 10:42 AM, Andrew Arnott <andrewarnott@...>
> wrote:
>>
>> I'll do that.  Thanks.
>> --
>> Andrew Arnott
>> "I [may] not agree with what you have to say, but I'll defend to the death
>> your right to say it." - S. G. Tallentyre
>>
>>
>> On Mon, Nov 16, 2009 at 10:06 AM, Breno de Medeiros <breno@...>
>> wrote:
>>>
>>> Andrew,
>>>
>>> This is a sufficiently significant risk that should be documented in
>>> the security wiki. I encourage you to do so.
>>>
>>> On Sat, Nov 14, 2009 at 7:21 PM, Andrew Arnott <andrewarnott@...>
>>> wrote:
>>> > That's right, John.
>>> > For a vulnerable RP, an attacker could set up any URL to impersonate
>>> > any
>>> > other user at the RP simply by logging into the RP with his own URL,
>>> > after
>>> > configuring it to send back the Content-Location header with the
>>> > victim's
>>> > claimed_id as its value.
>>> > I've confirmed that the extremeswankopenid library is vulnerable to
>>> > this
>>> > attack, and have contacted the author already.
>>> > Regarding your question about how this is different than delegating
>>> > your
>>> > identifier to a victim's OpenID... I'm not familiar with such an
>>> > approach,
>>> > or how that would be exploited.
>>> > --
>>> > Andrew Arnott
>>> > "I [may] not agree with what you have to say, but I'll defend to the
>>> > death
>>> > your right to say it." - S. G. Tallentyre
>>> >
>>> >
>>> > On Sat, Nov 14, 2009 at 10:50 AM, John Bradley <ve7jtb@...>
>>> > wrote:
>>> >>
>>> >> This is a attack on discovery.
>>> >> If the RP performs discovery on URL A the owner of URL A can return a
>>> >> XRDS
>>> >> with a content-Location header for URL B.  The RP now believes that
>>> >> whatever
>>> >> OP endpoint is in the XRDS is authoritative for URL B without having
>>> >> retrieved the actual XRDS for it, only the one for URL A claiming to
>>> >> be B.
>>> >> The problem is that .Net "helps" the application by making it think a
>>> >> redirect has taken place when it hasn't.
>>> >> There are lots of times when this works just fine however the
>>> >> claimed_id
>>> >> is tied to the product of the second normalization so is vulnerable to
>>> >> this
>>> >> sort of fake redirect.
>>> >> Andrew can provide more of the details.
>>> >> John B.
>>> >> On 2009-11-14, at 2:24 PM, Allen Tom wrote:
>>> >>
>>> >> Hi Andrew,
>>> >>
>>> >> Would an attacker be able to exploit this issue by returning the
>>> >> Content-Location HTTP response header for an URL that he owns, making
>>> >> his
>>> >> URL equivalent to a victim's OpenID? How is this different from having
>>> >> the
>>> >> attacker delegating his URL to the victim's OpenID?
>>> >>
>>> >> Can you outline a scenario where the Content-Location HTTP header is
>>> >> exploited?
>>> >>
>>> >> Thanks
>>> >> Allen
>>> >>
>>> >>
>>> >>
>>> >> Arnott wrote:
>>> >>
>>> >> Just a heads up from something I recently became aware of that
>>> >> impacted
>>> >> older versions of dotnetopenid.
>>> >> The HTTP protocol defines a Content-Location HTTP response header that
>>> >> allows the web server to suggest to the client that another URL would
>>> >> be
>>> >> equivalent to the one that client actually pulled from.  It is not a
>>> >> redirect, but merely a suggestion that two URLs are equivalent.  For
>>> >> the
>>> >> purposes of OpenID claimed identifier discovery, it is imperative that
>>> >> an
>>> >> OpenID RP ignore this header, lest a web server upon which discovery
>>> >> was
>>> >> performed can spoof an arbitrary claimed_id's identity by fooling the
>>> >> RP
>>> >> into thinking it discovered an identifier that in fact it did not.
>>> >> In particular, .NET's "helpful" HTTP stack automatically reads this
>>> >> header
>>> >> and reports it to the client as if it was in fact that actual URL that
>>> >> was
>>> >> pulled from even though it wasn't.  Since .NET follows redirects
>>> >> automatically by default, a legitimate redirect and this
>>> >> Content-Location
>>> >> header are indiscernable, which is really bad.  This is fixed in the
>>> >> dotnetopenid and dotnetopenauth libraries.
>>> >> Other RP library/site authors should verify that the HTTP stack they
>>> >> are
>>> >> using ignore this header, or workaround the issue.
>>> >> I've set up a test on test-id.org where an RP can very quickly assess
>>> >> whether they are vulnerable.  Please take a moment to find out, and
>>> >> fix it
>>> >> ASAP if you are.
>>> >> http://test-id.org/RP/IgnoresContentLocationHeader.aspx
>>> >> --
>>> >> Andrew Arnott
>>> >> "I [may] not agree with what you have to say, but I'll defend to the
>>> >> death
>>> >> your right to say it." - S. G. Tallentyre
>>> >>
>>> >> ________________________________
>>> >> _______________________________________________
>>> >> security mailing list
>>> >> security@...
>>> >> http://lists.openid.net/mailman/listinfo/openid-security
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> security mailing list
>>> >> security@...
>>> >> http://lists.openid.net/mailman/listinfo/openid-security
>>> >>
>>> >
>>> >
>>> > _______________________________________________
>>> > security mailing list
>>> > security@...
>>> > http://lists.openid.net/mailman/listinfo/openid-security
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> --Breno
>>>
>>> [phone] desk
>>> [phone] (Grand Central)
>>> MTV-41-3 : 383-A
>>> PST (GMT-8) / PDT(GMT-7)
>>
>
>

--
--Breno

[phone] desk
[phone] (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
_______________________________________________
security mailing list
security@...
http://lists.openid.net/mailman/listinfo/openid-security

[Andrew Arnott]

I suggest we refactor it so that /Security is a general discussion of how security is evaluated and triaged for OpenID, and that /SecurityIssues be where all issues are listed, and that sub-pages to /SecurityIssues actually explain individual issues.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

On Mon, Nov 16, 2009 at 11:03 AM, Breno de Medeiros <breno@...> wrote:

Hmmm... we need to consolidate these locations ... Suggestions?

On Mon, Nov 16, 2009 at 11:00 AM, Andrew Arnott <andrewarnott@...> wrote:
> I've added it to http://wiki.openid.net/Reported_Security_Issues,
> Although between these URLs, and their content, it was difficult to figure
> out exactly where was most appropriate.  So let me know if I guessed wrong.
> http://wiki.openid.net/Security
> http://wiki.openid.net/SecurityIssues
> http://wiki.openid.net/Reported_Security_Issues
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>
>
> On Mon, Nov 16, 2009 at 10:42 AM, Andrew Arnott <andrewarnott@...>
> wrote:
>>
>> I'll do that.  Thanks.
>> --
>> Andrew Arnott
>> "I [may] not agree with what you have to say, but I'll defend to the death
>> your right to say it." - S. G. Tallentyre
>>
>>
>> On Mon, Nov 16, 2009 at 10:06 AM, Breno de Medeiros <breno@...>
>> wrote:
>>>
>>> Andrew,
>>>
>>> This is a sufficiently significant risk that should be documented in
>>> the security wiki. I encourage you to do so.
>>>
>>> On Sat, Nov 14, 2009 at 7:21 PM, Andrew Arnott <andrewarnott@...>
>>> wrote:
>>> > That's right, John.
>>> > For a vulnerable RP, an attacker could set up any URL to impersonate
>>> > any
>>> > other user at the RP simply by logging into the RP with his own URL,
>>> > after
>>> > configuring it to send back the Content-Location header with the
>>> > victim's
>>> > claimed_id as its value.
>>> > I've confirmed that the extremeswankopenid library is vulnerable to
>>> > this
>>> > attack, and have contacted the author already.
>>> > Regarding your question about how this is different than delegating
>>> > your
>>> > identifier to a victim's OpenID... I'm not familiar with such an
>>> > approach,
>>> > or how that would be exploited.
>>> > --
>>> > Andrew Arnott
>>> > "I [may] not agree with what you have to say, but I'll defend to the
>>> > death
>>> > your right to say it." - S. G. Tallentyre
>>> >
>>> >
>>> > On Sat, Nov 14, 2009 at 10:50 AM, John Bradley <ve7jtb@...>
>>> > wrote:
>>> >>
>>> >> This is a attack on discovery.
>>> >> If the RP performs discovery on URL A the owner of URL A can return a
>>> >> XRDS
>>> >> with a content-Location header for URL B.  The RP now believes that
>>> >> whatever
>>> >> OP endpoint is in the XRDS is authoritative for URL B without having
>>> >> retrieved the actual XRDS for it, only the one for URL A claiming to
>>> >> be B.
>>> >> The problem is that .Net "helps" the application by making it think a
>>> >> redirect has taken place when it hasn't.
>>> >> There are lots of times when this works just fine however the
>>> >> claimed_id
>>> >> is tied to the product of the second normalization so is vulnerable to
>>> >> this
>>> >> sort of fake redirect.
>>> >> Andrew can provide more of the details.
>>> >> John B.
>>> >> On 2009-11-14, at 2:24 PM, Allen Tom wrote:
>>> >>
>>> >> Hi Andrew,
>>> >>
>>> >> Would an attacker be able to exploit this issue by returning the
>>> >> Content-Location HTTP response header for an URL that he owns, making
>>> >> his
>>> >> URL equivalent to a victim's OpenID? How is this different from having
>>> >> the
>>> >> attacker delegating his URL to the victim's OpenID?
>>> >>
>>> >> Can you outline a scenario where the Content-Location HTTP header is
>>> >> exploited?
>>> >>
>>> >> Thanks
>>> >> Allen
>>> >>
>>> >>
>>> >>
>>> >> Arnott wrote:
>>> >>
>>> >> Just a heads up from something I recently became aware of that
>>> >> impacted
>>> >> older versions of dotnetopenid.
>>> >> The HTTP protocol defines a Content-Location HTTP response header that
>>> >> allows the web server to suggest to the client that another URL would
>>> >> be
>>> >> equivalent to the one that client actually pulled from.  It is not a
>>> >> redirect, but merely a suggestion that two URLs are equivalent.  For
>>> >> the
>>> >> purposes of OpenID claimed identifier discovery, it is imperative that
>>> >> an
>>> >> OpenID RP ignore this header, lest a web server upon which discovery
>>> >> was
>>> >> performed can spoof an arbitrary claimed_id's identity by fooling the
>>> >> RP
>>> >> into thinking it discovered an identifier that in fact it did not.
>>> >> In particular, .NET's "helpful" HTTP stack automatically reads this
>>> >> header
>>> >> and reports it to the client as if it was in fact that actual URL that
>>> >> was
>>> >> pulled from even though it wasn't.  Since .NET follows redirects
>>> >> automatically by default, a legitimate redirect and this
>>> >> Content-Location
>>> >> header are indiscernable, which is really bad.  This is fixed in the
>>> >> dotnetopenid and dotnetopenauth libraries.
>>> >> Other RP library/site authors should verify that the HTTP stack they
>>> >> are
>>> >> using ignore this header, or workaround the issue.
>>> >> I've set up a test on test-id.org where an RP can very quickly assess
>>> >> whether they are vulnerable.  Please take a moment to find out, and
>>> >> fix it
>>> >> ASAP if you are.
>>> >> http://test-id.org/RP/IgnoresContentLocationHeader.aspx
>>> >> --
>>> >> Andrew Arnott
>>> >> "I [may] not agree with what you have to say, but I'll defend to the
>>> >> death
>>> >> your right to say it." - S. G. Tallentyre
>>> >>
>>> >> ________________________________
>>> >> _______________________________________________
>>> >> security mailing list
>>> >> security@...
>>> >> http://lists.openid.net/mailman/listinfo/openid-security
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> security mailing list
>>> >> security@...
>>> >> http://lists.openid.net/mailman/listinfo/openid-security
>>> >>
>>> >
>>> >
>>> > _______________________________________________
>>> > security mailing list
>>> > security@...
>>> > http://lists.openid.net/mailman/listinfo/openid-security
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> --Breno
>>>
>>> [phone] desk
>>> [phone] (Grand Central)
>>> MTV-41-3 : 383-A
>>> PST (GMT-8) / PDT(GMT-7)
>>
>
>

--

--Breno

[phone] desk
[phone] (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

_______________________________________________
security mailing list
security@...
http://lists.openid.net/mailman/listinfo/openid-security

[Chris Messina]

That sounds pretty good.

/Security should be the landing page.

/Security-Issues (I tend to prefer naming with spaces or hyphens for SEO/readability) should be for the list of known and fixed security issues.

/Security-Report-[descriptive-shortname] could be used for the details of an individual report.

Are there good templates for such reports on the web? I can import one to the wiki so that it'd be available in the dropdown list of templates.

Chris

On Mon, Nov 16, 2009 at 11:11 AM, Andrew Arnott <andrewarnott@...> wrote:

I suggest we refactor it so that /Security is a general discussion of how security is evaluated and triaged for OpenID, and that /SecurityIssues be where all issues are listed, and that sub-pages to /SecurityIssues actually explain individual issues.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

On Mon, Nov 16, 2009 at 11:03 AM, Breno de Medeiros <breno@...> wrote:

Hmmm... we need to consolidate these locations ... Suggestions?

On Mon, Nov 16, 2009 at 11:00 AM, Andrew Arnott <andrewarnott@...> wrote:
> I've added it to http://wiki.openid.net/Reported_Security_Issues,
> Although between these URLs, and their content, it was difficult to figure
> out exactly where was most appropriate.  So let me know if I guessed wrong.
> http://wiki.openid.net/Security
> http://wiki.openid.net/SecurityIssues
> http://wiki.openid.net/Reported_Security_Issues
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>
>
> On Mon, Nov 16, 2009 at 10:42 AM, Andrew Arnott <andrewarnott@...>
> wrote:
>>
>> I'll do that.  Thanks.
>> --
>> Andrew Arnott
>> "I [may] not agree with what you have to say, but I'll defend to the death
>> your right to say it." - S. G. Tallentyre
>>
>>
>> On Mon, Nov 16, 2009 at 10:06 AM, Breno de Medeiros <breno@...>
>> wrote:
>>>
>>> Andrew,
>>>
>>> This is a sufficiently significant risk that should be documented in
>>> the security wiki. I encourage you to do so.
>>>
>>> On Sat, Nov 14, 2009 at 7:21 PM, Andrew Arnott <andrewarnott@...>
>>> wrote:
>>> > That's right, John.
>>> > For a vulnerable RP, an attacker could set up any URL to impersonate
>>> > any
>>> > other user at the RP simply by logging into the RP with his own URL,
>>> > after
>>> > configuring it to send back the Content-Location header with the
>>> > victim's
>>> > claimed_id as its value.
>>> > I've confirmed that the extremeswankopenid library is vulnerable to
>>> > this
>>> > attack, and have contacted the author already.
>>> > Regarding your question about how this is different than delegating
>>> > your
>>> > identifier to a victim's OpenID... I'm not familiar with such an
>>> > approach,
>>> > or how that would be exploited.
>>> > --
>>> > Andrew Arnott
>>> > "I [may] not agree with what you have to say, but I'll defend to the
>>> > death
>>> > your right to say it." - S. G. Tallentyre
>>> >
>>> >
>>> > On Sat, Nov 14, 2009 at 10:50 AM, John Bradley <ve7jtb@...>
>>> > wrote:
>>> >>
>>> >> This is a attack on discovery.
>>> >> If the RP performs discovery on URL A the owner of URL A can return a
>>> >> XRDS
>>> >> with a content-Location header for URL B.  The RP now believes that
>>> >> whatever
>>> >> OP endpoint is in the XRDS is authoritative for URL B without having
>>> >> retrieved the actual XRDS for it, only the one for URL A claiming to
>>> >> be B.
>>> >> The problem is that .Net "helps" the application by making it think a
>>> >> redirect has taken place when it hasn't.
>>> >> There are lots of times when this works just fine however the
>>> >> claimed_id
>>> >> is tied to the product of the second normalization so is vulnerable to
>>> >> this
>>> >> sort of fake redirect.
>>> >> Andrew can provide more of the details.
>>> >> John B.
>>> >> On 2009-11-14, at 2:24 PM, Allen Tom wrote:
>>> >>
>>> >> Hi Andrew,
>>> >>
>>> >> Would an attacker be able to exploit this issue by returning the
>>> >> Content-Location HTTP response header for an URL that he owns, making
>>> >> his
>>> >> URL equivalent to a victim's OpenID? How is this different from having
>>> >> the
>>> >> attacker delegating his URL to the victim's OpenID?
>>> >>
>>> >> Can you outline a scenario where the Content-Location HTTP header is
>>> >> exploited?
>>> >>
>>> >> Thanks
>>> >> Allen
>>> >>
>>> >>
>>> >>
>>> >> Arnott wrote:
>>> >>
>>> >> Just a heads up from something I recently became aware of that
>>> >> impacted
>>> >> older versions of dotnetopenid.
>>> >> The HTTP protocol defines a Content-Location HTTP response header that
>>> >> allows the web server to suggest to the client that another URL would
>>> >> be
>>> >> equivalent to the one that client actually pulled from.  It is not a
>>> >> redirect, but merely a suggestion that two URLs are equivalent.  For
>>> >> the
>>> >> purposes of OpenID claimed identifier discovery, it is imperative that
>>> >> an
>>> >> OpenID RP ignore this header, lest a web server upon which discovery
>>> >> was
>>> >> performed can spoof an arbitrary claimed_id's identity by fooling the
>>> >> RP
>>> >> into thinking it discovered an identifier that in fact it did not.
>>> >> In particular, .NET's "helpful" HTTP stack automatically reads this
>>> >> header
>>> >> and reports it to the client as if it was in fact that actual URL that
>>> >> was
>>> >> pulled from even though it wasn't.  Since .NET follows redirects
>>> >> automatically by default, a legitimate redirect and this
>>> >> Content-Location
>>> >> header are indiscernable, which is really bad.  This is fixed in the
>>> >> dotnetopenid and dotnetopenauth libraries.
>>> >> Other RP library/site authors should verify that the HTTP stack they
>>> >> are
>>> >> using ignore this header, or workaround the issue.
>>> >> I've set up a test on test-id.org where an RP can very quickly assess
>>> >> whether they are vulnerable.  Please take a moment to find out, and
>>> >> fix it
>>> >> ASAP if you are.
>>> >> http://test-id.org/RP/IgnoresContentLocationHeader.aspx
>>> >> --
>>> >> Andrew Arnott
>>> >> "I [may] not agree with what you have to say, but I'll defend to the
>>> >> death
>>> >> your right to say it." - S. G. Tallentyre
>>> >>
>>> >> ________________________________
>>> >> _______________________________________________
>>> >> security mailing list
>>> >> security@...
>>> >> http://lists.openid.net/mailman/listinfo/openid-security
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> security mailing list
>>> >> security@...
>>> >> http://lists.openid.net/mailman/listinfo/openid-security
>>> >>
>>> >
>>> >
>>> > _______________________________________________
>>> > security mailing list
>>> > security@...
>>> > http://lists.openid.net/mailman/listinfo/openid-security
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> --Breno
>>>
>>> [phone] desk
>>> [phone] (Grand Central)
>>> MTV-41-3 : 383-A
>>> PST (GMT-8) / PDT(GMT-7)
>>
>
>

--

--Breno

[phone] desk
[phone] (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

_______________________________________________
security mailing list
security@...
http://lists.openid.net/mailman/listinfo/openid-security

--
Chris Messina
Open Web Advocate

Personal: http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagency.com
Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net

This email is:   [ ] shareable    [X] ask first   [ ] private

_______________________________________________
security mailing list
security@...
http://lists.openid.net/mailman/listinfo/openid-security