List of known pending security needs
2006-09-26 / lth@opera.com


Needs are broken down by core module, where possible.  Other things
are grouped at the end.


DOC or DOCHAND

Yngve observes:

  There is a check in OpenURL and one in LocalLoadInline (?).  Look
  for URL_FILE.

Lars Thomas observes:

  There needs to be a check on whether eg EMBED/OBJECT can reference
  content from various domains; there are checks in the code now but
  they are inconsistent (bug 174939).

DOM

Lars Thomas observes:

  DOM makes a number of security decisions that go beyond the origin
  checking.  For example, some fields of some objects may be written
  despite the origin check failing.  window.location.href is a typical
  case.

  Checking for whether to allow cross-document messaging is here too.


LOGDOC

Arne Martin writes:

  MHTML-filer (web archives). Om disse skal f laste eksterne
  ressurser, f kjre javascript (eksternt eller inkludert i
  MHTML-filen).


GADGETS

Lars Thomas observes:

  Whether a widget should be allowed to load a plugin or applet should
  be mediated by the security model, since the security spec for the
  widget allows the author to specify this.  See DOC/DOCHAND above.


XMLUTILS, XSLT, FORMS

Jens writes:

  I have security policy decisions in xmlutils and xslt on the line of
  "document A cannot include resource B because it comes from a
  different server."  I believe a similar type of decision is made in
  forms (which with webforms2 can prefill form controls from an
  external resource.)

  Quite the same as the DOM 3 Load/XMLHttpRequest security, that is.


URL

Yngve reveals:

  In URL_Manager::EmailSuppressed there is a check. (maybe in urltools)


WEBFEEDS

Arne Martin writes:

  Webfeeds. Om disse skal f laste eksterne ressurser, f kjre
  javascript (eksternt eller inkludert i feeden).


Unknown modules

Johannes observes:

  There is a security check on whether a page can load content from
  other domains, notably whether pages not from FILE: can load pages
  from FILE:.

Jonny R observes:

  There is (or needs to be) a security check on the kinds of contents
  that can be loaded by HTTPS pages.

Discussion among chrispi, arveb, lth:

  There needs to be logic that decides whether User JS should be
  loaded on a page, since User JS probably should not be loaded in
  widgets.  Probably the same for browser.js.

HTML user interface:

  Discussion with Gorm, Tor Martin, Bjarne, Hvard re Dolphin/Hokkaido UI:

    Probably the UI code needs to run with debugger privileges.  The
    privileged bit is set when UI code is loaded; probably it must be
    loaded from some secure place.

  Exchange between Johan Eriksson and lth:

    > P Core-1 s implementerade vi en DOM utknings som gjorde
    > pause/ resume p layouten (reflow) i FramesDocument som anvnde
    > sig av en skerhetsmodell liknande den fr jsplugins.
    >
    > Finns det mjlighet att lgga in detta i din security module s
    > den delar kod med jsplugins nr nu jsplugins skerhetsmodellen
    > blir flyttad?

    Det ville vre naturlig.

    > P core-1 ligger implementationen p: dumdum_2_final_1_patch_3 i
    > filerna dom/src/dom_manager.h/.cpp (detta borde komma in i
    > skerhetsmodulen)

    OK, skal ihvertfall skrive det p lista over ting jeg kan flytte,
    men om du fr nden over deg m du gjerne flytte koden og sende
    meg en PATCH.

    > Vi vill kunna utka dessa "skra" DOM anrop i framtiden till
    > fler special funktioner.  Browser in Browser UI skulle kanske
    > behva ha samma skerhetsmodell. (TV UI men DOM callbacks
    > specificerade av kunden).

    Det hres bra ut.  Skal du jobbe med BiB?  I s fall foreslr jeg
    at du prver  beskrive sikkerhetsmodellen i prosa frst, det blir
    bedre kode av dette enn nr kode skrives direkte.

