SSO request hijack
Hi Subin,
There are a few potential issues I see.
First, depending on how you perform the encryption, attacks might be
possible. If, for instance, you use ECB, you might be subject to block
shuffling or bit-flipping attacks. If you're using a timestamp in the
XML blob to indicate the validity period for the session request, a
bit-flipping attack might be sufficient to replay a stale session
token outside the normal validity period.
If you're using CBC, you might be subject to padding oracle attacks
which would allow for an attacker to tamper with the encrypted data.
If you reuse keys and are subject to an encryption oracle anywhere in
your application (see
http://www.slideshare.net/BaronZor/daniel-crowley-speaking-with-cryptographic-oracles)
you might allow anyone to create their own session using this
mechanism.
Encryption is difficult to do correctly. Do not rely on it as the only
thing standing between your application and an attacker.
Second, placing data in the URL is considered unwise, as that data is
logged in various places like proxies, browser history and web logs.
Should an attacker gain access to any one of those items, they could
replay the session within the three minute validity period.
Third, if a user controls any part of the XML data, you might be
subject to XML injection attacks which might allow for things like
privilege escalation.
Is there any reason the user needs to log into the old version of the
application at all? Why not just force them to log into the new
version?
Cheers,
Dan Crowley
"All the forces in the world are not so powerful as an idea whose time
has come." - Victor Hugo
There are a few potential issues I see.
First, depending on how you perform the encryption, attacks might be
possible. If, for instance, you use ECB, you might be subject to block
shuffling or bit-flipping attacks. If you're using a timestamp in the
XML blob to indicate the validity period for the session request, a
bit-flipping attack might be sufficient to replay a stale session
token outside the normal validity period.
If you're using CBC, you might be subject to padding oracle attacks
which would allow for an attacker to tamper with the encrypted data.
If you reuse keys and are subject to an encryption oracle anywhere in
your application (see
http://www.slideshare.net/BaronZor/daniel-crowley-speaking-with-cryptographic-oracles)
you might allow anyone to create their own session using this
mechanism.
Encryption is difficult to do correctly. Do not rely on it as the only
thing standing between your application and an attacker.
Agreed.
You could additionally sign the encrypted XML blob and ensure it was properly signed prior
to use. This would prevent an attacker from generating/modifying the encrypted XML blob and
prevents the attacks mentioned by Dan above. You still run into the issue of token replay
for as long as the token is valid for, so it is best to set this to a short (albeit
reasonable) period of time.
To Dan's other point you should avoid putting the token in a URL and
should consider passing it via a POST request to prevent it from showing
up in web server logs, browser history, proxy logs, etc...
Third, if a user controls any part of the XML data, you might be
subject to XML injection attacks which might allow for things like
privilege escalation.
If you properly sign/verify the payload this would be prevented.
Regards,
- Robert A
Moderator of the Web Security Mailing List/WASC Co-Founder
http://www.webappsec.org/
http://www.cgisecurity.com/
http://www.qasec.com
On Wed, Mar 14, 2012 at 1:37 PM, Robert A. robert@webappsec.org wrote:
There are a few potential issues I see.
First, depending on how you perform the encryption, attacks might be
possible. If, for instance, you use ECB, you might be subject to block
shuffling or bit-flipping attacks. If you're using a timestamp in the
XML blob to indicate the validity period for the session request, a
bit-flipping attack might be sufficient to replay a stale session
token outside the normal validity period.
If you're using CBC, you might be subject to padding oracle attacks
which would allow for an attacker to tamper with the encrypted data.
If you reuse keys and are subject to an encryption oracle anywhere in
your application (see
http://www.slideshare.net/BaronZor/daniel-crowley-speaking-with-cryptographic-oracles)
you might allow anyone to create their own session using this
mechanism.
Encryption is difficult to do correctly. Do not rely on it as the only
thing standing between your application and an attacker.
Agreed.
You could additionally sign the encrypted XML blob and ensure it was
properly signed prior
to use. This would prevent an attacker from generating/modifying the
encrypted XML blob and
prevents the attacks mentioned by Dan above. You still run into the issue of
token replay
for as long as the token is valid for, so it is best to set this to a short
(albeit
reasonable) period of time.
To Dan's other point you should avoid putting the token in a URL and should
consider passing it via a POST request to prevent it from showing up in web
server logs, browser history, proxy logs, etc...
Third, if a user controls any part of the XML data, you might be
subject to XML injection attacks which might allow for things like
privilege escalation.
If you properly sign/verify the payload this would be prevented.
Not necessarily. We can assume that the old application takes data
about the user's session, formats it as an XML blob, then
encrypts/signs it before handing it to the user in a URL so that the
user can move to a session on the new application.
If a user controls some part of the session data, it then follows that
they control part of the XML blob, opening up the possibility of XML
injection attacks. There's no need to tamper with the encrypted
version of the blob at all.
Regards,
- Robert A
Moderator of the Web Security Mailing List/WASC Co-Founder
http://www.webappsec.org/
http://www.cgisecurity.com/
http://www.qasec.com
--
Dan Crowley
"All the forces in the world are not so powerful as an idea whose time
has come." - Victor Hugo
I don't have the background on this thread, but figured I'd chime in to say:
-
If you're using the default mode (ECB) you can be cryptanalyzed a byte-at-a-time
-
CBC mode is susceptible to bit flipping attack, the default mode isn't (don't ever use the default mode).
-
If you reuse or generate predictable CBC IVs you can be cryptanalyzed a byte-at-a-time
-
If you don't encrypt-then-MAC, verify-then-decrypt, your plaintext can be rewritten through the ciphertext (a simplification, but a useful one).
-
If you pick the wrong MAC, &c.
-
If you implement MAC verify with data-dependent timings, &c
-
The other modes have similar or worse problems, as do the stream ciphers
Basically just don't do your own encryption.
If you're writing Java code, you can use BouncyCastle's PGP support to get an all-singing all-dancing cryptosystem that resists these attacks.
On Mar 14, 2012, at 1:12 PM, Daniel unicornFurnace Crowley wrote:
Hi Subin,
There are a few potential issues I see.
First, depending on how you perform the encryption, attacks might be
possible. If, for instance, you use ECB, you might be subject to block
shuffling or bit-flipping attacks. If you're using a timestamp in the
XML blob to indicate the validity period for the session request, a
bit-flipping attack might be sufficient to replay a stale session
token outside the normal validity period.
If you're using CBC, you might be subject to padding oracle attacks
which would allow for an attacker to tamper with the encrypted data.
If you reuse keys and are subject to an encryption oracle anywhere in
your application (see
http://www.slideshare.net/BaronZor/daniel-crowley-speaking-with-cryptographic-oracles)
you might allow anyone to create their own session using this
mechanism.
Encryption is difficult to do correctly. Do not rely on it as the only
thing standing between your application and an attacker.
Second, placing data in the URL is considered unwise, as that data is
logged in various places like proxies, browser history and web logs.
Should an attacker gain access to any one of those items, they could
replay the session within the three minute validity period.
Third, if a user controls any part of the XML data, you might be
subject to XML injection attacks which might allow for things like
privilege escalation.
Is there any reason the user needs to log into the old version of the
application at all? Why not just force them to log into the new
version?
Cheers,
Dan Crowley
"All the forces in the world are not so powerful as an idea whose time
has come." - Victor Hugo
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
Thomas Ptacek // thomas@matasano.com
Principal, Matasano Security --- 888-677-0666x7805
Agreed.
You could additionally sign the encrypted XML blob and ensure it was
properly signed prior
to use. This would prevent an attacker from generating/modifying the
encrypted XML blob and
prevents the attacks mentioned by Dan above. You still run into the issue of
token replay
for as long as the token is valid for, so it is best to set this to a short
(albeit
reasonable) period of time.
To Dan's other point you should avoid putting the token in a URL and should
consider passing it via a POST request to prevent it from showing up in web
server logs, browser history, proxy logs, etc...
Third, if a user controls any part of the XML data, you might be
subject to XML injection attacks which might allow for things like
privilege escalation.
If you properly sign/verify the payload this would be prevented.
Not necessarily. We can assume that the old application takes data
about the user's session, formats it as an XML blob, then
encrypts/signs it before handing it to the user in a URL so that the
user can move to a session on the new application.
The original email indicated he was encrypting the blob, but he gave no
indication that he was signing it.
If a user controls some part of the session data, it then follows that
they control part of the XML blob, opening up the possibility of XML
injection attacks. There's no need to tamper with the encrypted
version of the blob at all.
Yes, if the user can influence any of the data within the XML blob
this is a possibility. We'd need the details of the data within the blob
to verify this (which was not discussed in the original email).
Regards,
- Robert A
Moderator of the Web Security Mailing List/WASC Co-Founder
http://www.webappsec.org/
http://www.cgisecurity.com/
http://www.qasec.com
Regards,
- Robert A
Moderator of the Web Security Mailing List/WASC Co-Founder
http://www.webappsec.org/
http://www.cgisecurity.com/
http://www.qasec.com
--
Dan Crowley
"All the forces in the world are not so powerful as an idea whose time
has come." - Victor Hugo
Thanks Dan ,
It's a major change/migration from the old version to new and the business requires a slow transition , a set of user ids are configured to have a new link to the new version and this is the only way one can reach the new version of app.
This is critical financial app , requires high availability and security , This is a temporary solution proposed for the new version would be beta tested for few months before everyone gets the new version
I thought of ip validation to make sure request can be replayed only on the same client machine initiating SSO but that may not always work especially behind proxy servers
Thanks
Subin
Sent from my iPhone
On Mar 14, 2012, at 2:12 PM, "Daniel "unicornFurnace" Crowley" dan.crowley@gmail.com wrote:
Hi Subin,
There are a few potential issues I see.
First, depending on how you perform the encryption, attacks might be
possible. If, for instance, you use ECB, you might be subject to block
shuffling or bit-flipping attacks. If you're using a timestamp in the
XML blob to indicate the validity period for the session request, a
bit-flipping attack might be sufficient to replay a stale session
token outside the normal validity period.
If you're using CBC, you might be subject to padding oracle attacks
which would allow for an attacker to tamper with the encrypted data.
If you reuse keys and are subject to an encryption oracle anywhere in
your application (see
http://www.slideshare.net/BaronZor/daniel-crowley-speaking-with-cryptographic-oracles)
you might allow anyone to create their own session using this
mechanism.
Encryption is difficult to do correctly. Do not rely on it as the only
thing standing between your application and an attacker.
Second, placing data in the URL is considered unwise, as that data is
logged in various places like proxies, browser history and web logs.
Should an attacker gain access to any one of those items, they could
replay the session within the three minute validity period.
Third, if a user controls any part of the XML data, you might be
subject to XML injection attacks which might allow for things like
privilege escalation.
Is there any reason the user needs to log into the old version of the
application at all? Why not just force them to log into the new
version?
Cheers,
Dan Crowley
"All the forces in the world are not so powerful as an idea whose time
has come." - Victor Hugo
Thanks ,
I would reduce the token validity to reasonable time,and have the encrypted blob submitted over a post request
We are not signing the XML , client Id or user Id and the client ip are the only external factors , the token id , user id and ip in request can be generated only after a successful 2 factor authentication on the legacy application so the user id and ip are pretty much valid.
Thanks
Subin
Sent from my iPhone
On Mar 14, 2012, at 2:54 PM, "Robert A." robert@webappsec.org wrote:
Agreed.
You could additionally sign the encrypted XML blob and ensure it was
properly signed prior
to use. This would prevent an attacker from generating/modifying the
encrypted XML blob and
prevents the attacks mentioned by Dan above. You still run into the issue of
token replay
for as long as the token is valid for, so it is best to set this to a short
(albeit
reasonable) period of time.
To Dan's other point you should avoid putting the token in a URL and should
consider passing it via a POST request to prevent it from showing up in web
server logs, browser history, proxy logs, etc...
Third, if a user controls any part of the XML data, you might be
subject to XML injection attacks which might allow for things like
privilege escalation.
If you properly sign/verify the payload this would be prevented.
Not necessarily. We can assume that the old application takes data
about the user's session, formats it as an XML blob, then
encrypts/signs it before handing it to the user in a URL so that the
user can move to a session on the new application.
The original email indicated he was encrypting the blob, but he gave no indication that he was signing it.
If a user controls some part of the session data, it then follows that
they control part of the XML blob, opening up the possibility of XML
injection attacks. There's no need to tamper with the encrypted
version of the blob at all.
Yes, if the user can influence any of the data within the XML blob this is a possibility. We'd need the details of the data within the blob to verify this (which was not discussed in the original email).
Regards,
- Robert A
Moderator of the Web Security Mailing List/WASC Co-Founder
http://www.webappsec.org/
http://www.cgisecurity.com/
http://www.qasec.com
Regards,
- Robert A
Moderator of the Web Security Mailing List/WASC Co-Founder
http://www.webappsec.org/
http://www.cgisecurity.com/
http://www.qasec.com
--
Dan Crowley
"All the forces in the world are not so powerful as an idea whose time
has come." - Victor Hugo
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
Thanks very much for all the info !
Sent from my iPhone
On Mar 14, 2012, at 2:49 PM, Thomas Ptacek thomas@matasano.com wrote:
I don't have the background on this thread, but figured I'd chime in to say:
-
If you're using the default mode (ECB) you can be cryptanalyzed a byte-at-a-time
-
CBC mode is susceptible to bit flipping attack, the default mode isn't (don't ever use the default mode).
-
If you reuse or generate predictable CBC IVs you can be cryptanalyzed a byte-at-a-time
-
If you don't encrypt-then-MAC, verify-then-decrypt, your plaintext can be rewritten through the ciphertext (a simplification, but a useful one).
-
If you pick the wrong MAC, &c.
-
If you implement MAC verify with data-dependent timings, &c
-
The other modes have similar or worse problems, as do the stream ciphers
Basically just don't do your own encryption.
If you're writing Java code, you can use BouncyCastle's PGP support to get an all-singing all-dancing cryptosystem that resists these attacks.
On Mar 14, 2012, at 1:12 PM, Daniel unicornFurnace Crowley wrote:
Hi Subin,
There are a few potential issues I see.
First, depending on how you perform the encryption, attacks might be
possible. If, for instance, you use ECB, you might be subject to block
shuffling or bit-flipping attacks. If you're using a timestamp in the
XML blob to indicate the validity period for the session request, a
bit-flipping attack might be sufficient to replay a stale session
token outside the normal validity period.
If you're using CBC, you might be subject to padding oracle attacks
which would allow for an attacker to tamper with the encrypted data.
If you reuse keys and are subject to an encryption oracle anywhere in
your application (see
http://www.slideshare.net/BaronZor/daniel-crowley-speaking-with-cryptographic-oracles)
you might allow anyone to create their own session using this
mechanism.
Encryption is difficult to do correctly. Do not rely on it as the only
thing standing between your application and an attacker.
Second, placing data in the URL is considered unwise, as that data is
logged in various places like proxies, browser history and web logs.
Should an attacker gain access to any one of those items, they could
replay the session within the three minute validity period.
Third, if a user controls any part of the XML data, you might be
subject to XML injection attacks which might allow for things like
privilege escalation.
Is there any reason the user needs to log into the old version of the
application at all? Why not just force them to log into the new
version?
Cheers,
Dan Crowley
"All the forces in the world are not so powerful as an idea whose time
has come." - Victor Hugo
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
Thomas Ptacek // thomas@matasano.com
Principal, Matasano Security --- 888-677-0666x7805
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
Why not send the session info from the old application to the new one out
of band, negotiate a token representing the session, then hand the token to
the client to pass to the new application? No need to put all that data in
the hands of the client, even encrypted.
On Mar 14, 2012 3:35 PM, "Subin" subin.net@gmail.com wrote:
Thanks very much for all the info !
Sent from my iPhone
On Mar 14, 2012, at 2:49 PM, Thomas Ptacek thomas@matasano.com wrote:
I don't have the background on this thread, but figured I'd chime in to
say:
- If you're using the default mode (ECB) you can be cryptanalyzed a
byte-at-a-time
- CBC mode is susceptible to bit flipping attack, the default mode isn't
(don't ever use the default mode).
- If you reuse or generate predictable CBC IVs you can be cryptanalyzed
a byte-at-a-time
- If you don't encrypt-then-MAC, verify-then-decrypt, your plaintext can
be rewritten through the ciphertext (a simplification, but a useful one).
-
If you pick the wrong MAC, &c.
-
If you implement MAC verify with data-dependent timings, &c
-
The other modes have similar or worse problems, as do the stream
ciphers
Basically just don't do your own encryption.
If you're writing Java code, you can use BouncyCastle's PGP support to
get an all-singing all-dancing cryptosystem that resists these attacks.
On Mar 14, 2012, at 1:12 PM, Daniel unicornFurnace Crowley wrote:
Hi Subin,
There are a few potential issues I see.
First, depending on how you perform the encryption, attacks might be
possible. If, for instance, you use ECB, you might be subject to block
shuffling or bit-flipping attacks. If you're using a timestamp in the
XML blob to indicate the validity period for the session request, a
bit-flipping attack might be sufficient to replay a stale session
token outside the normal validity period.
If you're using CBC, you might be subject to padding oracle attacks
which would allow for an attacker to tamper with the encrypted data.
If you reuse keys and are subject to an encryption oracle anywhere in
your application (see
you might allow anyone to create their own session using this
mechanism.
Encryption is difficult to do correctly. Do not rely on it as the only
thing standing between your application and an attacker.
Second, placing data in the URL is considered unwise, as that data is
logged in various places like proxies, browser history and web logs.
Should an attacker gain access to any one of those items, they could
replay the session within the three minute validity period.
Third, if a user controls any part of the XML data, you might be
subject to XML injection attacks which might allow for things like
privilege escalation.
Is there any reason the user needs to log into the old version of the
application at all? Why not just force them to log into the new
version?
Cheers,
Dan Crowley
"All the forces in the world are not so powerful as an idea whose time
has come." - Victor Hugo
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
Thomas Ptacek // thomas@matasano.com
Principal, Matasano Security --- 888-677-0666x7805
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates