Re: Session Fixation Vulnerability in Web Based Apps
> To avoid it, one has to roll one's own state management, for > example by providing one's own cryptographically strong login > label in the Urls in the web page one generates in response to > a login, the label acting as primary key to a table of > currently active logins. When I've done login and state management, it's all maintained on the server side. It's completely independant of SSL sessions -- that's transport, has no place in application -- just like it's completely independant of HTTP/1.1 session management. A logout page isn't the same as "Connection: close" :) The only thing in the cookie is an opaque identifer. It's purely random bytes (for which OPenSSL's RANDbytes() is useful), that is a key into a server-side table that has all the state. Depending on the size, that table will be in-core or in a databse. /r$ Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Session Fixation Vulnerability in Web Based Apps
-- On 14 Jun 2003 at 21:42, Ben Laurie wrote: > The obvious answer is you always switch to a new session > after login. Nothing cleverer is required, surely? I had dreamed up some rathe complicated solutions. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG ocf99Mr7YN0oLlYWkZsE57yUHWMocE0Z+gK2yQOU 4RiX1d4bEHzLkunxq2FfwXmWFdySguhagGnZR4U7X - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Session Fixation Vulnerability in Web Based Apps
Ben dude wrote: > The obvious answer is you always switch to a new session after login. > Nothing cleverer is required, surely? Well particularly the issue is your login URL should not accept an existing session identifier supplied by the browser (what the author of the session fixing paper calls "session adoption"). I would presume that most people would naturally stomp an existing session identifier. Another related issue I'd think would be some login URLs manualy written or using programing environments may just skip do a redirect to some application page without prompting the user to login there is already a still valid session. In this case the user is logged in as the attacker, so the attacker doesn't learn the users account info. Of course it may be that if the user then starts to use the attackers session, the user may enter something that is private and the attacker would get that. Adam - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Session Fixation Vulnerability in Web Based Apps
James A. Donald wrote: > -- > James A. Donald wrote: > >>>This flaw is massive, and the biggest villain is the server >>>side code created for Apache. > > > Ben Laurie > >>This isn't the case. I analysed several sites I work on for >>attacks of the type described when this paper first came out. >>None of them were vulnerable. > > > In the development environments that I am familiar with, the > code environment assumes one is using a session cookie. If you > are using a session cookie automatically generated by the > environment for state management, if you are using the state > management supplied by the development environment, this flaw > will bite you. > > To avoid it, one has to roll one's own state management, for > example by providing one's own cryptographically strong login > label in the Urls in the web page one generates in response to > a login, the label acting as primary key to a table of > currently active logins. > > How did you do your state management, and why did you do it the > way that you did? > > For the environments that I am familiar with, if one did a > server side coding for a login in the way the environment was > designed to be used, that login code would be flawed. > > I do not see how this flaw can be avoided unless one > consciously takes special measures that the development > environment is not designed or intended to support. The obvious answer is you always switch to a new session after login. Nothing cleverer is required, surely? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Session Fixation Vulnerability in Web Based Apps
-- Rich Salz: > > The following environment variables are exported into SSI > > files and CGI scripts: > > SSL_SESSION_ID The hex-encoded SSL session id On 14 Jun 2003 at 18:24, Daniel Carosone wrote: > The problem is that this is not especially useful in > practice, if your client is IE. Essentially, you can't rely > on IE to keep ssl sessions open from one request to the next, > and thus it's not practical to treat this as a significant > authentication token. As I said earlier, there is no strong enforceable relationship between an https session and a login session. "This fortress wall not merely meets specifications, but is invincible" "But in only covers the north side of the fortress, and there is a gate in the middle that a child could kick down" "The specification was for the north wall, and the gate is the responsibility of the supplies and transport division" --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG HbAVQDehUS8SgfQqOI28BdF348siCWO9xi9Ep226 4yrN59HvscIQo8lQ44oxphi77XJ3ssx4FJUG6y2yd - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Session Fixation Vulnerability in Web Based Apps
-- James A. Donald wrote: > > This flaw is massive, and the biggest villain is the server > > side code created for Apache. Ben Laurie > This isn't the case. I analysed several sites I work on for > attacks of the type described when this paper first came out. > None of them were vulnerable. In the development environments that I am familiar with, the code environment assumes one is using a session cookie. If you are using a session cookie automatically generated by the environment for state management, if you are using the state management supplied by the development environment, this flaw will bite you. To avoid it, one has to roll one's own state management, for example by providing one's own cryptographically strong login label in the Urls in the web page one generates in response to a login, the label acting as primary key to a table of currently active logins. How did you do your state management, and why did you do it the way that you did? For the environments that I am familiar with, if one did a server side coding for a login in the way the environment was designed to be used, that login code would be flawed. I do not see how this flaw can be avoided unless one consciously takes special measures that the development environment is not designed or intended to support. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG kTr+tGmv2Tc7wtpF2vCQqPhk5dxOUN1yhHOu2VtM 4uKcnZA607mHi4kFhb+yzpP4NHwUS/DukGoP89sdV - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Session Fixation Vulnerability in Web Based Apps
James A. Donald wrote: > -- > On 12 Jun 2003 at 16:25, Steve Schear wrote: > http://www.acros.si/papers/session_fixation.pdf > > Wow. > > This flaw is massive, and the biggest villain is the server > side code created for Apache. > > When you login to your bank, your e-gold account, your > stockbroker, or your domain registrar, someone else can share > your login. > > It is a security design error in the development environments > for active server pages (all of them) . Every such development > environment will have to be changed, and every login script > written for existing environments needs to have some kind of > workaround cobbled into it. > > The ideal solution is to change the development environment so > that your session identifier is linked to the shared symmetric > key used in any https conversation during that session, which > requires tight coupling of https and development environments > for active server pages. > > In the long term, https must be amended to have a concept of > login and session, and make that sessionID available to the > server side coding environments. This isn't the case. I analysed several sites I work on for attacks of the type described when this paper first came out. None of them were vulnerable. I suggest you read and think more carefully. I will agree that an incautious implementor could get bitten by these attacks, though. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Session Fixation Vulnerability in Web Based Apps
On Fri, Jun 13, 2003 at 09:58:32PM -0400, Rich Salz wrote: > The following environment variables are exported into SSI files > and CGI scripts: > SSL_SESSION_ID The hex-encoded SSL session id The problem is that this is not especially useful in practice, if your client is IE. Essentially, you can't rely on IE to keep ssl sessions open from one request to the next, and thus it's not practical to treat this as a significant authentication token. -- Dan. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
At 02:24 PM 06/11/2003 -0700, David Honig wrote: At 12:42 PM 6/11/03 -0600, Anne & Lynn Wheeler wrote: >actually, if you had a properly secured DNS then you could trust DNS >to distribute public keys bound to a domain name in the same way they >distribute ip-addresses bound to a domain name. ... Adding PKeys to Yellow Pages merely lets you get scammed *confidentially*. Unfortunately, that doesn't help you against wetware attacks - the "paypa1.com" and "e-g0ld.com" web sites can have valid certs, and your browser is unlikely to notice that they're different from the certs at the sites "paypal.com" and "e-gold.com" because they've got different domain names. So it won't notice that the certs have changed, because they haven't, they're just the new certs for the new websites. And client-side certs won't help, because the bogus sites can happily accept them or ignore them. An e-gold-specific or paypal-specific client can tell, because it can remember that it's trying to see the real thing, but the browser can't tell, except by bugging you about "Hi, this is a new site that's giving us a new cert" placebo box. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
