RE: A11y for Web App Sec Anti clickjacking spec

Thanks Brad.

 

PF discussed the proposed text today. It captures the situation well, but we
had a couple of questions and suggested amendments.

 

“Certain classes of accessibility technologies such as screen readers will
provide strong defenses against many classes of UI Redressing attacks by
presenting the content to the user in a manner not subject to interference.”

 

Until we can be sure this is the case, it should be a “may provide strong
defenses”, instead of “will provide strong defenses”.

 

When there are test cases available, we can take a more detailed look at AT
behaviour and that sould put us in a better position to be more certain.

 

The detection of transformative settings and/or ATs is still the biggest
challenge. As previously mentioned, techniques for doing this are limited,
so we’re still left with a potential vulnerability in people who need to
turn off the security measures in order to prevent false positives.

 

One question was raised on the PF call. What happens when someone has chosen
a personalised colour scheme within their browser (or no other reason than
asthetic choice)? Would this have the potential to trigger a false positive
too?

 

Léonie.

 

 

 

From: Hill, Brad [mailto:bhill@paypal-inc.com] 
Sent: 21 November 2012 18:58
To: tink@tink.co.uk
Cc: public-webappsec@w3.org; w3c-wai-pf@w3.org
Subject: RE: A11y for Web App Sec Anti clickjacking spec

 

Thanks for this, Léonie.  It was nice to meet you as well, and we really
appreciate your and the WAI’s taking the time to review our spec.

 

The canvas used to render the “control image” for obstruction testing will
never be accessible to the user, so those concerns are moot.

 

Below is the text I’ve added based on this feedback.  I think the UA
implementers should have an easier time telling if A11Y technologies are
enabled in the browser, because they are coding “from the inside”, even if
no external APIs are exposed.  As a final fallback, we suggest that UAs
should provide a way to disable the obstruction check manually if it
interferes with users’ chosen A11Y technology.

 

-Brad

9.1 Accessibility Technologies

Certain classes of accessibility technologies such as screen readers will
provide strong defenses against many classes of UI Redressing attacks by
presenting the content to the user in a manner not subject to interference.
Such user agents should set the unsafe attribute of the UIEvent interface as
this may be interrogated by client applications doing feature detection, and
should ignore X-Frame-Options headers when presented in combination with UI
Safety directives in a Content Security Policy.

Use of accessibility technologies must not cause the input-protection
heuristic to be triggered. Accessibility technologies that modify the
appearance of a resource, such as screen magnifiers or color and contrast
modifications to the display have the potential to interfere with the
obstruction checkif not applied in a consistent manner to both the user
image and control image. To prevent this inteference, user agents should
apply accessibility transformations to the control image. If a user agent is
able to detect that accessibility technologies are in use that cannot be
applied uniformly as part of the obstruction check, the check must be
disabled.

User agents should provide a means for the user to manually disable
enforcement of the Input Protection Heuristic if it interferes with their
chosen accessibility technologies.

 

 

 

 

 

From: Léonie Watson [mailto:tink@tink.co.uk] 
Sent: Sunday, November 18, 2012 7:01 AM
To: Hill, Brad
Cc: public-webappsec@w3.org; w3c-wai-pf@w3.org
Subject: A11y for Web App Sec Anti clickjacking spec

 

Brad,

 

It was good to meet you and the Web App Sec WG at TPAC. Thanks for inviting
PF to work with you on the accessibility of this specification:

http://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safe
ty.html

 

Our assumption is that screen readers afford a measure of protection against
some clickjacking techniques, because of their reliance on HTML (rather than
what’s visible on screen). This should be tested when any example use cases
become available though.

 

One instance when this behaviour is likely to influence the spec is when
HTML5 canvas is used as part of an obstruction check. The method used to
hide the canvas content off screen should render it invisible to screen
readers as well. Either visibility:hidden; or display:none; should do the
trick.

 

Assuming there is no intention for the canvas to be available to the user,
its accessibility is a moot point. If that’s not the case though, the
following notes might prove helpful.

 

You can include HTML elements inside the canvas element. This fall back
content is keyboard navigable, and you can create relationships  between the
rendered canvas and elements within the HTML.

 

You can define a path around an object in the canvas and bind it to an
element in the fall back content. This creates a location that can be used
to pass mouse events through to the fall back content (hit testing).

 

If you don’t define paths, the hit testing is handled by the canvas.
Anything without a path is routed to the canvas element, and the mouse event
is routed to the handlers associated with it.

 

When you associate a path with a fall back element, it can be used to form a
rectangle that can be exposed to the browser’s accessibility API. For
example, a screen magnifier would be able to zoom in on a targeted area of
the canvas.

 

In terms of the visual appearance of content to be compared in an
obstruction check, canvas isn’t subject to CSS styling or adaptations such
as high contrast mode. The challenge will be preventing a false positive
from being triggered when legitimate accessibility adaptations have been
made to the on screen content.

 

Microsoft has introduced a proprietary CSS3 media query for detecting high
contrast mode in Windows8/IE10:

http://msdn.microsoft.com/en-us/library/windows/apps/hh465764.aspx

 

Otherwise, I haven’t been able to find other methods for detecting high
contrast or increased text size adaptations at the UA or OS level. It may be
that the browser vendors can offer some suggestions for detecting
adaptations made within the browser, but detecting the presence of assistive
technologies like screen magnifiers isn’t viable.

 

This may mean catch 22. If it isn’t possible to detect accessibility
adaptations there is no way to disable the policy (and that has security
implications as an action anyway of course), but if the policy isn’t
disabled the likely outcome is a false positive trigger.

 

Léonie.

 

 

-- 

Léonie Watson

 

E. tink@tink.co.uk

T. @LeonieWatson

S. Leonie.Watson

W. tink.co.uk