Bil, > > If the browser displayed the file > > and the user takes no precautions, the file should > > be in the browser's cache. > > Yngve Pettersen of Opera is working on a proposed > browser specification for "Context Cache" that > would allow cached items to expire/be discarded > immediately upon logging out: > > http://my.opera.com/yngve/blog/2007/02/27/introducing-cache-contexts-or-why-the > http://www.ietf.org/internet-drafts/draft-pettersen-cache-context-03.txt > An interesting proposal. > I know he's looking for feedback on the > idea. And of course, all the new "stealth" modes > being built into browsers would also help (they > do have use beyond surfing adult-content). > > > > To tell you the truth, > > the original motivation was just that it's not a > > good idea to have a valid authentication token > > (the file retrievel session ID) embedded in a URL. > > Sure, it can show up in logs, referer, etc. If > you don't mind JavaScript, it's easy enough to > use JavaScript to submit a POST. > > > > There is also a more exotic scenario: the > > attacker reads the authentication token from the > > user's computer display, as it is shown in the > > address box of the browser. These days, with a > > camera phone, the attacker does not have to be > > James Bond to pull that off. > > You could insert as the first param random junk > that's 100 characters long that will "push" the > real token off-screen. Yes. > > In any case, I do > > think now that the file retrieval session ID must > > remain valid while the login session is valid, in > > case the browser issues multiple requests for the > > same file. > > No, the thing to do here is a one-time, limited > duration key. When the browser first hits the > download page using the key, the user is assigned > an internal session by the file download site, and > the one-time key is voided. No replay attacks. The > internal session is used for all subsequent > requests. And the key is limited in duration > (maybe a minute), so if the user's browser dies or > can't reach the download site, the key expires > after the time limit. Yes, good idea. (I assume that what you mean by "key" is what I called "file retrievel session ID", and the "internal session" is for the purpose of authenticating subsequent request ***for the same file***, and "the user is assigned an internal session by the download site" means that such an internal session record is created on the server side, and a cookie referring to the internal session is set in the user's browser; this cookie would be specific to the file, and it would be used in addition to the cookie that authenticates application pages and the cookie that authenticates standard-URL requests for user files.) > > > Actually, I think there may be another case where > > a browser may issue multiple requests (besides the > > case where a large file download is interrupted), > > namely to implement sniffing. A browser may > > download an initial portion of the file to > > determine its type, and then download the rest. > > It's not clear to me why a second request would be > > needed to download the rest, rather than just > > continuing the download; but I think I remember > > seeing some version of IE issue a second request, > > when downloading MS Office documents. > > Switching from the one-time key to an internal > session ID (as described above) solves these > issues. Yes. (Same assumptions.) Thanks! Francisco
