I'd say that the security is not improved by showing the real destination to
blind people.
And this is why I think so:
1. In most cases the links use href attributes that contain valid URLs, and
a label that doesn't contain an URL, but simple text like "Click here".
And in 99.99% of cases the user doesn't know to what URL that link should
point.
And even if the user will see that the url points to
http://dracula.bin-laden.all-devils.com, he doesn't know if that page is a
good one or an evil one.
2. In much fewer cases, but this depends what sites are mostly used, there
are many enough cases where the links contain href="#" and the destination
URL is generated by a Javascript code.
It is not helpful at all to see that the destination URL is "#" because we
can't find to what page it points.
3. Probably in even much more cases, there are links that use Javascript
code, but that JS code doesn't provide an URL, but do a POST request. This
is the case of many pages generated by aspx.net.
In those cases, the links don't do a GET request, so the address in address
bar will remain the same, but they do an AJAX request and just replace a
part of the current page.
4. There are more and more pages where the active elements are not standard
active HTML elements like <input> or <button> or <a>, but simple <div>
improved with onClick events and nothing more. So they are nicely designed
to look like links or buttons, but the screen reader doesn't know that, but
we can see them as common plain text. However if we press Enter on them we
can access another page or we can execute AJAX requests. If those <div>
elements are not also improved with ARIA to help the screen readers see them
as links or buttons and if they don't contain tabstops to be able to jump to
them with Tab, it is harder for us to use them than for the sighted. We
might even skip them.
They are a disadvantage for the sighted. And in any case, we can't find
their destination URL.
5. If the current site was compromised and if it contain bad URLs, the
attacker won't use URLs like the one above, so it won't appear so clear that
it might be bad, but it would generate the href attribute using Javascript
code, or it would use another way of defining the onClick event for that
link, or it would generate the whole link entirely with Javascript code, so
there won't be any <a> element on page, or it will use a destination url
like erftrytyt.com, with some garbage letters that don't mean anything, or
it would use the IP address directly, or it would use the IP address
transformed in decimal format that would look like a long number, or it
would use a relative URL but earlier in page it would define a base URL for
that page, or it would define the link as a form button with ARIA, or it
would use other HTML elements like <insert>, <div> improved with onClick
event and a tabstop and an ARIA attribute that should make it look like a
link, and who knows how many other ways.
I don't think it is normal to expect an attacker to just post simple links
with the href pointing to another page, with no care for all the other
cases, but thinking that this improves the security.
I think that improving the browser with Javascript code that shows the
content of the href attribute is as useless for the blind as it is for the
sighted, but sometimes even if it is useless, it is very good for the blind
to be able to show to the sighted that we are equal and that we can do what
they can, because otherwise we can be pointless disadvantaged.
However, there are other things that decrease our accessibility when
compared with the accessibility for the sighted, like those modern active
elements which are not well defined and marked with ARIA, or Captcha.
--Octavian
----- Original Message -----
From: "Doug Lee" <doug.lee@xxxxxxxxxxxxxxx>
To: <jawsscripts@xxxxxxxxxxxxx>
Sent: Monday, January 06, 2020 7:58 PM
Subject: [jawsscripts] Re: A scripting browser problem!!!
This is why my scripts for OpenTween, a Windows Twitter client, allow me
to see a site's contents without running any local web code. It's not
perfect and not even as effective currently as an actual text browser; but
when it
works, it's super fast (as long as the website itself delivers quickly of
course) and way safer in my opinion than visiting random sites with a
full-blown Windows browser. Shameless plug I suppose, though my point when
I
started writing this was not to write an advertisement.
https://www.dlee.org/tween/
What made me start writing is this:
I wonder if many sites out there have a legal href= attribute but
completely ignore it in favor of a script-generated URL. That would make
browsers lie even to sighted people about where a link will go. A JAWS
script might be
able to detect an onclick event, but there's no guarantee that a JAWS
script could figure out, from that, where the link would go. Of course, a
text browser would go to the href= address if there is one. Interesting
concept
this is...
So back to this thread's topic: If we can't trust the href= value, do we
help or hinder security by showing it to blind people? I still assume it
helps in the majority of cases, but I raise the question because I'm not
sure
how common such web code tricks are out there.
On Mon, Jan 06, 2020 at 05:58:53PM +0200, Octavian Rasnita wrote:
This is why I gave you that code example. To see that if you right-click
the
link and copy the shortcut to clipboard, the copied URL is not always the
real target URL that will be opened if the user will click or hit enter or
Shift+Enter on that link.
The sighted users are not able to see that URL either. They will see just
the content of the href attribute which is useless for more reasons.
A JAWS script might be helpful to find the content of the href attribute
faster, but not for security reasons, and not for the reason of finding
the
real destination of the links.
It is good if the JAWS script helps you, but you need to know what it can
do
and what it can't.
"what I was after was a short cut to determining where the link would take
one too. E.g. what is displayed on the web site isn't where the link will
really take you too."
Remember that this is not possible.
The real destination URL might not exist at all in the source code of the
web page, but it might be generated right after clicking on the link,
so....
if it doesn't exist, you can't find it. :)
--Octavian
----- Original Message -----
From: "Shan Noyes" <shan.noyes@xxxxxxxxxxx>
To: <jawsscripts@xxxxxxxxxxxxx>
Sent: Monday, January 06, 2020 3:59 PM
Subject: [jawsscripts] Re: A scripting browser problem!!!
Hi:
Yes, the links generated at OnClick or run time should still be an issue.
I'll have to test that out as well. However, what I was after was a
short
cut to determining where the link would take one too. E.g. what is
displayed on the web site isn't where the link will really take you too.
The sighted folks can see where a link is going to take them to by
hovering the mouse over the link and I've been told the place that the
link would take them to is displayed on the screen.
I can get the same info but it caused a lot of extra steps.
e.g.
1. put the focus on the html link on the display.
2. hit the applications key, or shift + f10
3. select copy link this copies the link to the clipboard.
4. switch over to say notepad and paste it in.
Well I monkeyed around with the key sequences etc, and then thanks to
some
suggestions on this list specifically the snowman and its really cool now
how it works for me.
I hit a key sequence when my focus is on a link and the place that the
link will take me to shows up in a jaws dialog box.
Yes, the important thing is to keep one's software upto date to protect
yourself on the internet. In security I deal with this all the time.
But one of the things I see quite often Are attacks that say this is
such
and such a site. The user has an account on that site and the e-mail is
trying to get them to click on the site for the upgrade. But The page
they go to looks exactly like what they would expect, however, it's a
landing page to steal the user's credentials.
Anyways, I just wanted to be able to check links as fast as my sighted
colleagues, which now I can.
Have a good day everyone.
-----Original Message-----
From: jawsscripts-bounce@xxxxxxxxxxxxx <jawsscripts-bounce@xxxxxxxxxxxxx>
On Behalf Of Octavian Rasnita
Sent: Monday, January 6, 2020 2:23 AM
To: jawsscripts@xxxxxxxxxxxxx
Subject: [jawsscripts] Re: A scripting browser problem!!!
-------------------------------------------------------------
WARNING, this email originated from outside of SaskTel.
Do not click links or open attachments unless you trust the sender and
believe the contents are safe.
--------------------------------------------------------------
The destination URLs can't be known beforehand if they are generated
runtime.
They are generated after a Javascript function is executed, and the JS
code is executed only after a certain event appears, for example an
onClick or something else.
I think that it is not a security problem to just visit an evil web site
if a good and secure browser is used.
If a browser is not secure, then this is the security issue, not the fact
that the user visits a bad site. So I don't think a JAWS script can
improve the security this way.
These are my thoughts when speaking about just clicking on links and
opening web pages as usually.
In other cases, where more complex attacks are involved, allowing for
example the attackers to insert on a good site evil Javascript code that
makes unwanted POST requests with the permissions of the currently
authenticated user, it is something else. The problem in that case is
that
site that has vulnerabilities, but a JAWS script can't improve the
security in that case either.
--Octavian
----- Original Message -----
From: "Jonathan Cohn" <jon.c.cohn@xxxxxxxxx>
To: <jawsscripts@xxxxxxxxxxxxx>
Sent: Sunday, January 05, 2020 5:08 PM
Subject: [jawsscripts] Re: A scripting browser problem!!!
Doesn't the WAVE accessibility tool provide a way to list links and
the destinations in them?
Also, often newer pages use a addEventListener() function and not a
onClick attribute. If a event handler is defined using this function I
expect there would be no way for an external application to examine
this.
Though the developer tools for Chrome, Safari and Firefox do appear to
have ways of auditing, are there any Security services similar to the
accessibility audits often used by accessibility firms?
Best wishes,
Jonathan Cohn
On Jan 3, 2020, at 4:05 PM, Octavian Rasnita <orasnita@xxxxxxxxx>
wrote:
Will that JAWS script also work if the HTML code would be:
<script>function
goToFreedomScientific(){location.href='http://www.evil.com/';}</scrip
t> <a href=http://www.freedomscientific.com/
onclick="javascript:goToFreedomScientific();return
false;">freedomscientific.com</a>
...because if a site is evil, probably its creators will be able to
do even worse things than this.
--Octavian
----- Original Message -----
From: "Shan Noyes" <shan.noyes@xxxxxxxxxxx>
To: <jawsscripts@xxxxxxxxxxxxx>
Sent: Friday, January 03, 2020 10:13 PM
Subject: [jawsscripts] A scripting browser problem!!!
Hi folks:
First I should say that I'm a relatively new Jaws scripter. I done
some pretty simple scripts like writing key commands that will
look at a web page and read certain areas etc.
Anyways, I work in computer security and one of the things we check
is where are links going to take one too. E.g. an evil person can
make the link so it looks like when you click on it you would be
going to say Freedom scientific's site, but in the html code it
actually takes you to an evil site.
e.g.
the html code for the link would read.
<a href=http://evilsite.com>Freedom Scientific</a>
The place that one goes to is specified by the href statement, but
jaws reads to the user the info after the evilsite>
A sighted person can get this info of where the link will take you
by merely hovering the mouse over the link and it displays the
location on the screen.
Anyways, to get this info as a jaws user one puts the virtual
cursor on the link text, then issues the windows application key
and selects the option for copy link. Then one can go to say
notepad and paste the clipboard and voila you see that the link that
says freedom scientific is actually going to take you to the
evilsite
Way to many steps.
I've have written the following little script and it actually works.
Well
most of the time.
Here's the script. And then I'll ask my questions.
Script CopyRealLink ()
SayString("Please wait")
{shift+f10} ; is the windows application key sequence pause () { e}
; is the option for copy link
EndScript
This works and one can see where the freedom scientific site will go
to the evilsite.com instead of switching and pasting the link
results into a notepad as stated above I tried the virtual clipboard
with the jawskey + spacebar then the letter c. and the evilsite
link shows up.
Its really cool.
My questions:
1. Rather then having to do the jawskey + spacebar then the letter
c to get the clipboard viewer up I would like to add this into my
script. So should I try and do this via keyboard input or hat
script or fuction should I be calling? I've started reading through
various default jaws .jss files but haven't found what I think is the
answer.
2. Anyone familiar with how to flush or clean out the virtual
viewer after one has read it?
Thanks for any and all of your assistance.
Have a good day.
Shan Noyes Technical Analyst - Systems Security GIAC
W: 306 777-4830
C: 306 533-1440
NOTICE: This confidential e-mail message is only for the intended
recipients. If you are not the intended recipient, be advised that
disclosing, copying, distributing, or any other use of this message,
is strictly prohibited. In such case, please destroy this message
and notify the sender.
__________ďş˝
View the list's information and change your settings at
//www.freelists.org/list/jawsscripts
__________ďş˝
View the list's information and change your settings at
//www.freelists.org/list/jawsscripts
__________ďż˝
View the list's information and change your settings at
//www.freelists.org/list/jawsscripts
__________ďż˝
View the list's information and change your settings at
//www.freelists.org/list/jawsscripts
NOTICE: This confidential e-mail message is only for the intended
recipients. If you are not the intended recipient, be advised that
disclosing, copying, distributing, or any other use of this message, is
strictly prohibited. In such case, please destroy this message and notify
the sender.
__________ďż˝
View the list's information and change your settings at
//www.freelists.org/list/jawsscripts
__________ďż˝
View the list's information and change your settings at
//www.freelists.org/list/jawsscripts
--
Doug Lee, Lead Accessibility Architect
Level Access - over 1,000 organizations trust us to help them achieve and
maintain digital accessibility compliance!
mailto:Doug.Lee@xxxxxxxxxxxxxxx http://www.LevelAccess.com
"While they were saying among themselves it cannot be done, it was
done." --Helen Keller
__________�
View the list's information and change your settings at
//www.freelists.org/list/jawsscripts
