This was a typical XY problem:
http://xyproblem.info/
"The XY problem is asking about your attempted solution rather than your
actual problem. This leads to enormous amounts of wasted time and energy,
both on the part of people asking for help, and on the part of those
providing help."
In the original question was not mentioned at all that this check for bad
links is done in email messages. And this is important, because most email
providers don't allow <script> elements in messages, so yes, you're right,
usually they
are not a problem there.
It is good that you made it clear now.
And now that you also told that you want to automate this, I'd say that a
better solution would be to have a program, a mail client, that connects to
the POP3 mail server, gets the email messages, extracts the links from them,
then for each link compares the host found in the href attribute with the
one found in the link's label, and possibly other checks you need to do
manually, then for each message that contains strange links, store that
email message somewhere, and make a note somewhere, eventually delete that
email message from server automaticly etc.
This solution would be much much faster, more secure, because it won't skip
by accident a bad link, and it can be permanently improved to check other
things and do other actions after that.
Of course, this is just an idea for improvement in future, not a solution
for the current problem.
--Octavian
----- Original Message -----
From: "Shan Noyes" <shan.noyes@xxxxxxxxxxx>
To: <jawsscripts@xxxxxxxxxxxxx>
Sent: Monday, January 06, 2020 11:13 PM
Subject: [jawsscripts] Re: A scripting browser problem!!!
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
__________
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
