> -----Original Message----- > From: Yoav Nir [mailto:[email protected]] > Sent: Monday, December 12, 2011 11:25 AM > To: Murray S. Kucherawy > Cc: [email protected] > Subject: Re: [websec] Same Origins and email > > > What about something like Outlook or alpine, where we're not talking > > about a web-based MUA but one that pulls from a local store? > > file://localhost ? > > Although I think HTML you get through the mail should not be scripted > by files on your computer, so maybe each mail item should have its own > origin.
I was thinking maybe "mailto:"; followed by whatever address is parsed from the From: field. The problem, of course, is that it's trivially forged. Given that I come from the messaging side and not from the browser side, I'm trying to ensure I've got the idea here: Is the idea of web origins to inform the target server of URIs in the HTML document about where the request came from, a little more generally than what Referer does, and allowing chaining, thus permitting the server servicing that URI the choice to refuse or substitute the content where it determines the referral was likely fraudulent? Or does it allow the user agent to make more informed choices about which URIs it is willing to dereference? Or both? Is it possible for a server to use web origins to list other web origins allowed to reference it? Say, could a bank's reply to an <img src> tag include a list of authorized origins? (That might be hard to secure, but I'm talking generally here.) Basically, if there's a way to use this stuff to help reduce the attack surface in HTML email, I'd love to put it to use, and that's what I'm (pardon the pun) fishing around for here. Thanks, -MSK _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
