h1

Featured on Security Now!

September 21, 2007

Vista busy cursor Following on from my email exchange with Steve Gibson, I listened to yesterday’s Security Now! Episode #110 to find out if I had a mention.

True to his word Steve included my comments about “beating him to that session state management system” as one of the listeners’ items.

Apparently everybody else had beaten him to it too and something like it was built into ASP by Microsoft years ago. I think I actually knew that.

What got me was that Leo and Steve were just finishing off the previous item about jpegs getting resized but still harbouring malicious code and it seemed nearly done, Leo said “Dennis Wright in the UK …” but then went back to the previous item because they didn’t want to appear to be being rude about the previous guy’s question and they prattled on about people not having an intuitive grasp of probability for ages. I was listening in my car on the way to work, was nearly there and they still hadn’t got to my item. It was killing me. Finally Leo again picked up with “Dennis Wright in the UK …” and this time went on to read out my piece on session management.

I had asked for trouble by inviting Steve to tell me what was wrong with relying on SSL for security rather than having to encrypt the data being passed back and forth between server and client. To my relief he didn’t crush my reliance on SSL as wholly inadequate. Whew! He does have his reasons for going that extra mile with encryption but for my application that would have been completely unnecessary overkill.

The discussion went on for a while and I ended up sat in the underground carpark at the office, carrying on listening. Colleagues would arrive and park up and presumably wonder why I was just sitting in the car. Well, I’d arrived quite early and I wasn’t going to wait all day to listen through to the end.

Here is an extract from the transcript as downloadable from the grc website:

Thanks Steve and Leo. You are the best.

Security Now!


Leo: Dennis Wright in the U.K. has been programming web forms, too, something like what you’ve been doing for your eCommerce. He says: I was listening to the fascinating episode on your eCommerce system. I think I may have beaten you to the session management scheme.
Steve: Dennis and the rest of the world, apparently.
Leo: I don’t think – I’ll have to listen to it again, but I don’t think…
Steve: No.
Leo: …you claimed that you invented this.
Steve: No, I just came up with a solution that worked for me.
Leo: Yeah. Almost all websites use some form of session preservation using cookies. I mean, that’s just kind of common. Anyway, he says: As you were talking, I could see where you were heading because I’d been there myself. I’m an actuary – interesting. Now, here’s a guy who understands statistics. But he’s interested in IT. Some years ago he created an interactive online retirement modeling system for the place where he worked. I had the same issues. You can’t assume cookies or JavaScript are available, and you didn’t want an overcooked database solution. So he had the data items, which were few and not needed to be recorded permanently, shuttling back and forth between client and server using the query string and hidden form fields. Oh, that’s a good way to do it. I skipped the encryption because the whole thing was running under SSL. No doubt you’ll tell me that was a mistake. No, that sounds sensible.
Steve: Well, I wanted to put this in here because there were so many people who mentioned the idea that I talked about last week not being unique to me. Apparently there are books on CGI programming that talk about maintaining state this way, too. And so…
Leo: Most programs have to solve this problem. State is important in a program.
Steve: Well, yes.
Leo: And in a client-server environment you have to figure out a way to do this.
Steve: Exactly. So there’s storing cookies, formal standard HTTP web cookies on the browser. There’s various ways you could use variables in JavaScript. Or you could go with standard straight HTML, which is what I did, and just return the contents in a hidden field in the form in order to pass the state back to the browser, which it then passes back to the server when the user adds some more information to that form and then resubmits it. And I did want to talk about his comment about not using encryption because it was running under SSL. And he says no doubt you’ll tell me that was a mistake. Well, what SSL of course did was, for Dennis in this case, was it prevented anyone from sniffing the transaction as it was passing back and forth on the line. My concern, and the reason I encrypted this blob of data and then signed it and made sure, was that the signing, of course, verified that it had not been altered because essentially I’m taking all of the state of my eCommerce transaction and hanging it, transporting it out of the server off to a client somewhere. Now, I’m assuming he’s on my side, that is, you know, this is his eCommerce transaction, after all. And he wants it to work out well. I’m not giving it to some bad person. On the other hand, I don’t know that I can trust this person not to screw around with my server. So when I hand them back the blob, I don’t want them to be able to, A, modify it in any way, not do any sort of like delayed replay. Replaying the data in the future is something that I also prevent by putting in a transaction count as part of the encrypted data to prevent any kind of a replay attack. Nor do I want them to be able to decrypt it, see what’s going on, and figure out anything they might be able to do with it to mess with GRC or eCommerce or whatever. So because browsers might be caching those pages, even though I explicitly expire the pages and have “no caching” tags all over the place, it’s theoretically possible. So, and the fact is there’s no vulnerable data, other than the users’ own data that they have submitted in the form, ever coming back to me because all I’m doing is carrying that through a couple pages. But, you know, I thought, what the heck, I might as well make sure this thing is locked down. So aware of the dangers, even though we also have an SSL connection which is enforced through all this, I thought, I just don’t want anyone to screw with this. This is my blob, not their blob.
Leo: Not your blob. Hands off my blob.
Steve: So I’m going to encrypt my blob, and I’m going to digitally sign it, and I’m going to put serial numbers in it, and I’m going to do everything I can think of so that the blob I give you is your data, but I’ve made it mine. And all your browser knows to do is send it back just the way it is. And then I’m going to take a look at it and make sure that everything about it makes sense before I trust it. And that’s what I do when the data comes back. I deblobbify it and then look at it, make sure it all makes sense, and then proceed to process that next submission from the user. And it works.
Leo: Yeah. That makes perfect sense. I mean, I think probably any book you look in is going to talk about some way to do this. And cookies are obviously the way everybody uses, just because it’s there.
Steve: Although apparently Microsoft does have this thing that they call State View, which is built into their ASP.NET system, that makes it very easy for programmers to carry state from page to page in a fashion very much like this.
Leo: But I’m thinking it’s cookies; right? I mean, if you’re storing something…
Steve: We have to be careful about that word, though, because cookies are sort of a reserved word. Cookies means a blob stored on the server that’s associated with the site.
Leo: No, on the client, on the client.
Steve: I’m sorry, yeah, of course. Erase that. Stored on the client that’s associated with the site. So a cookie is a specific thing. This is not a cookie. This is an opaque token which is sent back and is part of the page itself.
Leo: Yeah, okay. So it’s not stored.
Steve: Exactly.
Leo: On the client side.
Steve: It is not stored on the client side. It’s on the page.
Leo: Right. If it’s stored client-side it’s, you know, cookies were created by Netscape, and originally they were called PCSSIs, which is not very catchy. Client side, what does it stand for, Persistent Client Side State Information. And so anything stored on the client has state information. That’s a cookie.
Steve: Right.
Leo: But I guess since you’re – yours are not persistent. That’s the difference. It doesn’t persist through the session.
Steve: Well, and but there are also non-persistent cookies.
Leo: Right.
Steve: I think what the real difference is that I’m storing it in the page. So the page that comes back to the user, it’s actually in the HTML is this blob which is a field in the form that I’m next asking them to fill out. And so it just, you know, I’m not having to keep any memory of this on the server at all. When I’m done with it, I send it all back to the user. If they want to continue or proceed with the transaction, they click on the button or fill out the form or do whatever, and then all of that state information comes back to me as part of the next stage in the transaction. So…
Leo: Right. It’s a session – it’s effectively what a session cookie does, which is it’s not saved. It’s just for the session.
Steve: Well, except that a session cookie is normally a token that does refer to state information saved on the server. So this session cookie comes back to the server. Then the server looks up what the – like the bulky session state that that cookie refers to. Instead, all of that data is what I’m sending back out to the browser, and it all comes back to me. So I have nothing – so it’s not a pointer to data on the server. It’s all the data.
Leo: Well, I mean, I’ve used session cookies in programming, and most programming languages support this kind of [indiscernible] you can [indiscernible] me. Essentially a lot of times it’s just, okay – I just pressed a button or something, lost my audio. Lot of them it’s just you’re setting a date or a time, and it’s programmatic, I mean, it’s a hash of something.
Steve: Right.
Leo: That the program did. It’s not like the server’s doing a lot of work.
Steve: Right.

AddThis Social Bookmark Button

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: