Hi all!
Sorry about starting such an e-mail storm. My original question was to
automate a process that I have had to do numerous times over the past few
years. That is look at a link in an e-mail and determine if it will take the
person to the location that the link is claiming to take one too. Yes, there
are numerous ways that one will not see that info as pointed out in the message
I’m responding too.
However, believe me the majority of e-mails that I’ve checked the where the
link is taking one too has always been available.
Now the reason I’m checking these is I often have to investigate phishing
e-mail scams. Currently these e-mails are sent to folks and claim to be from a
certain company, and promote that an upgrade to a service is available from sed
company. The visible link will say something like maybe the service name, or
click here to upgrade. Well if one clicks the link one gets a page that
suspiciously looks like it is from sed company for sed service. And it asks
the user to log in. In other words it is a landing page for stealing user
creds.
So I need to establish if the link is really the sed company and its sed
service or is it a landing page. If it’s a landing page then I am off to the
races to establish its IP address, who owns the domain when the domain was
created, and then start the process for a take down.
So yes, its definitely security related.
Yes, I know that links can be generated, but if I get to establishing that some
weird is going on, I have a secured system that can be used to find out more
info.
Anyways, as I stated previously I’m relatively a new scripter in Jaws, so
thanks for everyone who provided suggestions it did help out a lot.
I hadn’t thought about viewing the web site in the virtual viewer that sounds
interesting. So would greatly appreciate if anyone could give me a rough piece
of code to get me started looking at that angle.
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:37 PM
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.
--------------------------------------------------------------
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/';}</scr
ip
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
