[Home]HTTP

ec2-52-91-67-23.compute-1.amazonaws.com | ToothyWiki | RecentChanges | Login | Webcomic

HyperText Transfer Protocol



TODO: RFC link




Places to keep state between requests:

Cookies
But a lot of people have them turned off, and/or actively complain when a site tries to set them.

URL
Looks ugly. Implementation needs attention if the user is to be able to bookmark stuff.

Hidden form fields
Needs Javascript, or limits state-preserving links to being form submission buttons.




How do I know the person talking to me is the same person it was two requests ago?

This is not the same problem as above. In general, we don't care; we just want the state. In, e.g. online commerce, we do care. Cookies, URLs and hidden form fields can all be stolen - using, for instance, the MSIE? cross-site-scripting vulnerability of the day. Also, having some form of timeout seems a basic requirement.

It doesn't have to be - and, in fact, can't be? - 100% secure. It just needs to obey the HomeSecurity principle.

HTTPS? sessions
The client's certificate can be stolen offline. IIRC, however, an HTTPS? session involves per-session data that is available to the server but not to scripts running on the browser, raising the difficulty bar somewhat. TODO: look up details.
This is, officially, the 'right way' to do things.  Unfortunately, as you say, it makes scripting a pain - and getting a certificate that the client will accept is a royal pain.  --Vitenka
Making scripting a pain is the idea - the state of MSIE?'s security generally means you can't guarantee your scripts are the only scripts with access to browser data, so you'd have to rely on something that isn't accessible by browser-side scripts at all. Getting a certificate is the main barrier, I'd say (yes, you can generate them yourself, but most people just go somewhere else when confronted with instructions on how to get their browser to accept your certificate). - MoonShadow

.
.
.

Side data
Referrer fields, IP address.. not reliable, easy to forge; but examining it raises the amount of stuff an attacker needs to take into account, and certain patterns could be used to flag transactions as "supicious; someone human please check me" (e.g. referrer field has been valid for the last n requests and is suddenly not).
This one would really annoy me (though if all it is is a human checking it would be fine) - I often have to switch browser in mid session because the site suddenly tells me my browser isn't supported.  --Vitenka
Uh - I can see it causes inconvenience, but surely security-wise it's a good thing if you can't carry secure sessions across browsers easily? 'cos if you can do it, so can an attacker.. - MoonShadow
That's fine, if it's something secure.  But too many sites have page after page of "fill in details" and "click this to bypass the stupid agreement you won't read and isn't legally binding anyway" - at the very least let me carry that across.  I agree that you don't want to carry across state that includes authorisation or anything like that; but a lot of sites now require you to renavigate all the way through their junk ridden mess to get to the signup page again.  I think we really need to move to some physical token based system - now that USB? flash sticks are so cheap.  It would really help the "I logged on at home and now cannot access it from work" problems.  --Vitenka
Agreed.. - MoonShadow




Vitenka would have to say that the URL is the right place to put it (session data) - preferably encrypted but without any kind of timeout on validity.  That makes it accessible for bookmarking etc.  However, that is horribly horribly insecure.  Probably the best compromise is a cookie (over ssl) that is safe to throw away - if the user throws it away then fine, they have to log in next time.  If they don't, then great.  --Vitenka



CategoryComputing CategoryAbbreviation; see also HTTPS?

ec2-52-91-67-23.compute-1.amazonaws.com | ToothyWiki | RecentChanges | Login | Webcomic
Edit this page | View other revisions | Recently used referrers
Last edited July 29, 2003 12:59 pm (viewing revision 10, which is the newest) (diff)
Search: