understanding HTML
-
I'm trying to trouble shoot an issue.
A client reached out to us that upon visiting our vendor supplied patient portal (presumably from a link on our website), their AV gave this page.
I've reported this to the vendor, and they are just side stepping the whole issue.
This was their response:
Bullet point 1 - can't pull through a non secured website OK this isn't a problem, Our website is setup with a LE cert, and as far as I can tell, it's working fine.
Bullet point 2 - browser can't read site as a secure site - huh? Safari can't read it as a secure site - OK that's possibly I suppose, I don't use safari, except on iphone, so I have no clue.
As for their recommendations -
-
Open in a new browser window - currently it just navigates the current window to the clicked URL - Is this really a problem?
-
the portal uses HTTPS:// - uh duh, and so does the link on our website.
Below is a code snippet created by our WP site for the link to the portal.
Last night's claim is:
REALLY? is that true? is my old page still wrapped around this new site my browser has gone to? I mean, I know it's possible to do an iFrame and hide the rest of my site, but I don't believe that is what is happening.
Have I provided enough of a code snippet to show one way or the other?
-
-
@dashrender I would approach the issue from a different angle and contact AVG to have them review the site for possible false positive.
-
@danp said in understanding HTML:
@dashrender I would approach the issue from a different angle and contact AVG to have them review the site for possible false positive.
Unfortunately, AVG likely can't because you can only get to the URL in question after logging in (or at least while logging in).
-
@dashrender You should simplify it. There is more to it than meets they eye because the site giving the error is the authentication site (oauth.portal.xxxxx).
Send a link in an email that goes directly to the site (7144.portal.xxxxx) and have the user click that. Does the user get the same error?
If they do, you know it's not the link from your page.
-
@pete-s said in understanding HTML:
@dashrender You should simplify it. There is more to it than meets they eye because the site giving the error is the authentication site (oauth.portal.xxxxx).
Send a link in an email that goes directly to the site and have the user click that. Does the user get the same error?
If they do, you know it's not the link from your page.
yeah, the vendor has pretty much stated the same thing...
BUT - this was over two weeks ago..
Frankly - I believe the vendor has an unreported incident on their hands, and they've cleaned up the mess, so testing it at this point will likely be clean.
-
@dashrender said in understanding HTML:
@pete-s said in understanding HTML:
@dashrender You should simplify it. There is more to it than meets they eye because the site giving the error is the authentication site (oauth.portal.xxxxx).
Send a link in an email that goes directly to the site and have the user click that. Does the user get the same error?
If they do, you know it's not the link from your page.
yeah, the vendor has pretty much stated the same thing...
BUT - this was over two weeks ago..
Frankly - I believe the vendor has an unreported incident on their hands, and they've cleaned up the mess, so testing it at this point will likely be clean.
Personally I think it might be the AVG detection that is the culprit. The vendor couldn't possibly know what AVG is looking at to deem it malicious.
-
@pete-s said in understanding HTML:
@dashrender said in understanding HTML:
@pete-s said in understanding HTML:
@dashrender You should simplify it. There is more to it than meets they eye because the site giving the error is the authentication site (oauth.portal.xxxxx).
Send a link in an email that goes directly to the site and have the user click that. Does the user get the same error?
If they do, you know it's not the link from your page.
yeah, the vendor has pretty much stated the same thing...
BUT - this was over two weeks ago..
Frankly - I believe the vendor has an unreported incident on their hands, and they've cleaned up the mess, so testing it at this point will likely be clean.
Personally I think it might be the AVG detection that is the culprit. The vendor couldn't possibly know what AVG is looking at to deem it malicious.
And there are millions of tools that "detects" malicious websites. So it's not like you can test them all.
-
We had several suspicious activities happen at once, along with this activity. I can't go into details.
That said, we contacted our vendor agent and they were super cagey about what was happening.
This is what leads me to believe they had an incident they aren't reporting.
Toss in the fact of these red herring like solutions/problems their helpdesk is providing to the stated problem - instead of saying - oh.. interesting - I wonder if their AV is false positiving us.. no, instead they blaming a website redirect, lack of TLS, etc.
