Re: [Tails-dev] Testing image cache and DOM storage isolatio…

Borrar esta mensaxe

Responder a esta mensaxe
Autor: intrigeri
Data:  
Para: Mike Perry, tails-dev
Asunto: Re: [Tails-dev] Testing image cache and DOM storage isolation
Hi,

Mike Perry wrote (17 Apr 2013 18:39:46 GMT) :
> According to my notes in the original bug
> (https://trac.torproject.org/projects/tor/ticket/5742), the patch should
> cause additional domain= entries for each url bar to appear in
> about:cache. Otherwise I think only one entry appears for a given image,
> regardless of url bar domains used to load it... However, the patch was
> first written for Firefox 10. Things may have changed wrt about:cache
> display since then.


I'm not sure I've understood exactly what you mean, but my results
seem to make sense and to concur:

  * without the patch the image appears only once in about:cache (with
    the first source as domain=)
  * with the patch, the image appears twice in about:cache (with
    different domain= prefixes)


> You can manually verify that the Google logo image actually loads over the
> network for all three of these pages:
> https://encrypted.google.com/
> https://anonym-surfen.de/ImageTest.html
> https://anonymous-proxy-servers.net/en/ImageTest.html


OK.

> If the patch is not working/not applied, the Google image will come from
> the cache for the second two, and the web developer console should say
> "304 not modified" in the "Net" logs.


My results are good, but FTR they are displayed slightly differently:

  * google.com has me fetch logo4w.png while the two others have me fetch
    logo3w.png, so I've dropped google.com from the data set
  * If the patch is not applied, then the attempt to load an image
    from a second website is not logged anywhere I can see; if the
    patch is applied, then it's logged with HTTP 200, as expected.


> For DOM storage, you can try hosting this container page on an
> additional domain, and verify that the iframe can't retrieve any values
> set from the original container page from trial.pearlcrescent.com:
> http://trial.pearlcrescent.com/tor/storageContainer.html


Left to be done.

bertagaz or someone else, may you please take care of this before
merging while I'm away?

> What do you use for automated testing of Firefox? I see some pages
> mentioning something called "Cucumber?"


We don't use anything specific for the browser.

We mainly use Sikuli, libvirt and cucumber:
https://tails.boum.org/contribute/release_process/test/automated_tests/

You might be particularly interested in:

http://git.immerda.ch/?p=amnesia.git;a=blob;f=features/torified_browsing.feature;hb=refs/heads/devel
http://git.immerda.ch/?p=amnesia.git;a=blob;f=features/step_definitions/torified_browsing.rb;hb=refs/heads/devel

The unsafe browser tests are a bit more involved and interesting:

http://git.immerda.ch/?p=amnesia.git;a=blob;f=features/unsafe_browser.feature;hb=refs/heads/devel
http://git.immerda.ch/?p=amnesia.git;a=blob;f=features/step_definitions/unsafe_browser.rb;hb=refs/heads/devel

> Are you able to inspect the browser state from that framework?


We don't have access to the browser internal state this way. But we
have access to whatever can be displayed in the browser, to any file
in the system under test's filesystem, and we can run arbitrary
commands in there.

In the specific case of image cache isolation, loading two URLs and
then looking for strings in about:cache, or looking for strings in the
webconsole logs, looks relatively easy.

Our test suite just moved from the PoC to the basic production state,
so who knows what it's gonna become wrt. browser testing. I guess that
at some point, we might want to use a tool more specialized than
Sikuli, such as Selenium.

Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc