[theora] <video/> and cross site scripting policy.

[Conrad Parker]

Hi,

thanks Gregory for the heads-up, and to Robert for the explanation.

One issue that I'm not clear on is: at what point does served content
contain such information that it introduces vulnerabilities? Is it
when it contains personalized content/markup, or javascript? Or is a
static video file somehow susceptible to attack?

I understand that the client must deny cross-origin loads in order to
protect the user. So my question concerns what the default file
serving behavior should be.

If we specify to allow all access by default then stuff "just works"
for the simple case of someone setting up a personal video server
which just serves static files, and embedding the content from their
existing blog (hosted elsewhere).
I guess that what's important about that scenario is that the video
files are static, which we can take to mean that:
  * the content and markup of the video are not personalized for the viewer
  * no application side-effects occur as a result of retrieving the video

My understanding of the problem is that as the sophistication of video
formats progresses, these assumptions will break which may allow
sensitive information to leak. For example, a video may contain
personalized markup, may itself be the response to part of a
transaction, or may contain embedded scripting; and the markup content
of a video may be queried by the containing web page.

So ... is my understanding of the problem correct? The existing uses
of web video are much like <img>, but in future we'd like to see more
complex applications where the <video> is a customized part of the
interaction.

Well, that was a lot of abstract words. I'll finish this email with an
example of a vulnerable script for a Web 3.0 video application, and a
patch that makes it so!

<script language="English">
Shop assistant: Hey there BOB, great to see you! You look FINE! How
about a new hat? CLICK NOW to buy a new hat! All your friends like
ALICE and MARY think you need a new hat!
Shop assistant: Hey there BOB, great to see you! NICE HAT! Do you like
ice cream? Wanna see a funny video of a DOG? CLICK NOW to see a funny
video about a DOG!
Shop assistant: Hey there BOB! This is a DOG! Would you like to know more?
</script>

Anyway, back to the static file scenario ... For the sake of
experimentation, the attached patch to oggz-chop adds a response
header allowing all access. If anyone wants to test this out, it would
be trivial to modify the patch to specify a particular site. Of course
we would want to make this configurable instead.

cheers,

Conrad.
 -> needs a new hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-add-Access-Control-Allow-Origin-header-to-oggz.patch
Type: text/x-patch
Size: 1901 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/theora/attachments/20081110/90f8b9fa/attachment.bin