I know this is not a programming question and it could be open ended. However, I feel like I can get this most help here.
Is the image below cross-site scripting or a result of net-neutrality? If so, what can do to get them out of my browser?
So far I have noticed this on my computer, my wife's computer which has better security on it, and it is happening to other people I know.
It happens randomly in my google chrome browser. I have not seen it in FF or Edge but I don't use those much. It will also occur on different websites. The copyright is 2016 but it is happening now (2019). I would think this was an annoying ad but it has my name in it, and it occurs when I have to pay the bill. Also just another observation, it seems to happen on HTTP sites, not HTTPS but I could be wrong.
Any information to get Charter out would be helpful. Please don't say use TOR
It's probably DNS hijacking.
To mitigate, you could try:
Not using your ISP's DNS servers. Try OpenDNS or similar.
DNS over HTTPS
The HTTPS Everywhere browser extension, which might help reduce it
a VPN
Related
My Magento 1.9 webshop is marked as unsafe (phishing which is not true) in Microsoft Edge, if switch to IE and run Smart Screen security check it says all safe.
And strangely only on one of my computers and therefore didn't bother much but also a customer complained about it today.
Anyone experienced this before and have a solution? Is there a way to check why a site is marked as unsafe by smartscreen?
Based on my searching results, Below information may helpful to you.
Q. If I am a website owner, how do I correct a warning on my legitimate site?
A. You can immediately submit a request for a correction. Windows Defender SmartScreen has a built-in, web-based feedback system in place to help customers and website owners report any potential false warnings as quickly as possible. In Windows Internet Explorer, from a red warning, click More information then Report that this site contains no threats. This will take you to a feedback page where you can indicate you are a site owner or representative. Follow the instructions and provide the information on this site to submit a site for review...
Reference:
Resolving “This website has been reported as unsafe” (Windows Defender SmartScreen)
Q.
If I am a website owner, what can I do to help minimize the chance of my website being flagged by Windows Defender SmartScreen?
A.
There are several things you can do that can help minimize the chance of your site being flagged as suspicious. Think of these as best practices or optimal website design ethics.
If you ask users for personal information, use HTTPS with a valid, unexpired server certificate issued by a trusted certification authority.
Make sure that your webpage doesn't expose any cross-site scripting (XSS) vulnerabilities. Protect your site by using anti-cross-site scripting functions such as those provided by the Microsoft Anti-Cross Site Scripting library.
Use the fully-qualified domain name rather than an IP-literal address. (This means a URL should look like "microsoft.com" and not "207.46.19.30.")
Don't encode or tunnel your URLs unnecessarily. If you don't know what this means, you probably aren't doing it.
If you post external or third-party hosted content, make sure that the content is secure and from a known and trusted source.
Reference:
Windows Defender SmartScreen Frequently Asked Questions
In MS Edge browser there's an option to "report file as safe". After clicking it - select the "I'm a website owner" option and fill the false-positive form.
I have Adblock and Adblock Plus extensions in Chrome browser. I spend a lot of time doing intentional shopping and get blocked from things I don't want to be blocked from. For example if I search google for a "hotspot", I want to research various devices available. But when I click on one (sponsored link at the top of the search results), I get an error page that says
This site can’t provide a secure connection
ad.doubleclick.net sent an invalid response.
Try running Windows Network Diagnostics.
ERR_SSL_PROTOCOL_ERROR
I don't mind these "ads". They are useful. Is there a way to configure AdBlocker to allow them?
My IT department admitted this is a filtering policy. Quite unfortunate since looking at ads for new technology IS A HUGE PART OF MY JOB
But Its a lie
I am facing this issue with my installer:
Installer exe when downloaded from the websites in Chrome are flagged as being malicious software.
To overcome this problem so far we have tried changing domain names,but its not a permanent solution.
Even after signing my exe with Thawte certificate the flag is still there.
I have scanned my exe with all popular AVs and there is nothing malicious in it.
How can I get rid of this chrome flag?
The webmaster site doesn't do anything to help with the false positive on installers. All it does is tell you the file is potentially malware without giving you any way of appealing or asking for a review of their findings.
With FireFox and Chrome and others using this data, you would think Google would provide a way to appeal. It is ironic the company starting the false positive initiative with Microsoft is the worst offender in creating false positives.
You may be able to get around the issue by supplying your site's URL to "Google Webmaster Tools". You don't even have to supply a URL for every single "malicious" file; an overall, top-level URL for your site (or, for your little corner of Blogger.com) seems to be adequate.
If you've got a Google account, just log in and go to this URL. There's a prominent textbox with an "Add Site" button next to it that does the trick. This worked for me, in a matter of minutes (and I don't have a "certificate", other than the one I got for winning a raft race in Pre-K).
Oh, and I too have experience working in heuristics, as part of my degree. "Heuristics" are really just what ordinary, unpretentious people call "rules of thumb"!
It may be that Chrome is using heuristic analysis, to determine that this file is "malicious". That is to say, it is basically saying "Because this file possesses these qualities, we therefore believe this file to be malicious".
Given that a few years ago, someone got hold of a root certificate authority, and proceeded to make genuine security certificates (so that people wouldn't be suspicious, and because they were actually genuine, browsers did not notify the user), for their sites which asked for personal data (bank username and password, etc), and stole it, until that authority was annulled a few days later.
Therefore, simply having an .exe with a certificate (a genuine one, which of course, you have), won't suffice, in Chrome's mind, for the above two reasons.
I'm sorry I can't tell you how to get rid (or at least alleviate somewhat) this issue, but I thought it'd be helpful for you to have some possible reasons as to why this is occurring.
**EDIT: Sources to back up my claims: http://news.techworld.com/security/3266817/online-fraudsters-issue-fake-security-certificates-for-google-yahoo/
http://www.bbc.co.uk/news/technology-14819257**
I also have experience working in heuristics, as part of my programming degree.
I'm having some issues with Chrome canceling some HTTP requests and I'm suspecting cached authentication data to be the cause. Let me first write down some important factors about the application I'm writing.
I was using Basic Authentication scheme for some time to guard several services and resources in my web app.
In the meantime I was using/testing the app heavily using Chrome with my main Google Account fully synced. Most frequently I was using my name - "lukasz" - as the username in Basic Auth.
Recently I have switched my application to use Digest Authentication.
Now, some of the HTTP requests I'm making are failing with status=failed with no apparent reason. It only happens when I'm using user "lukasz", if I enter some other unique username - there is no problem.
I looked everywhere in the backend and frontend and I couldn't locate the issue to be in our code. I can easily reproduce this with user "lukasz" each time. So I reverted my code to Basic Auth (while not touching the rest of app) and the problem was gone.
That led me to think that there is something wrong with cached passwords. So I cleared the cache in Chrome, but that didn't help. After several hours of analyzing the issue I decided to make sure that I'm running fresh instance of Chrome, so I reinstalled it (deleting the disk data along the way). TADAAA! The problem was gone and I couldn't reproduce this anymore.
Then I synchronized my Google Account with this newly installed Chrome and after a short while the requests to my app started failing again!! So I took a deeper look at this (cleaning profile data from disk and redoing all the steps) and indeed it looks like the problem starts as soon as my account is synced with cloud!
Yes, I know it sounds dodgy. It sounds ridiculous. It sounds stupid. But I am almost sure that those two problems are somehow related (failing requests and account sync).
My idea is this: Chrome somehow remembered that I was using "lukasz/my-pass" with Basic Auth for certain services. After I switched to Digest Auth the same combination of credentials (lukasz/my-pass) is now acting funny. Perhaps under the hood Chrome still thinks that this is Basic Auth and cancels requests when it learns otherwise?
UPDATE:
I've did some low level debugging with chrome://net-internals/ and it appears that the problem is while reading cache entry. This seems to prove my initial assumption.
I did some investigation and found this article. Apparently always adding "Last-Modified" header to my http response has solved the issue in Chrome (I'm still having some problems in FF, but that's off topic).
However, it still doesn't solve my issue entirely. Why the requests were failing in the first place?
You could try using incognito mode and see what happens. It may give you some hints without having to clear the cache or re-installing Chrome.
Also take a look at How to clear basic authentication details in chrome
I have a page that is just a non interactive display for a shop window.
Obviously, I don't link to it, and I'd also like to avoid people stumbling across it (by Google etc).
It will always be powered by Chrome.
I have thought of...
Checking User Agent for Chrome
Ensuring resolution is 1920 x 1080 (not that useful as it is a client side check)
Banning under robots.txt to keep Google out of it
Do you have any more suggestions?
Should I not really worry about it?
Not that I would EVER recommend what I'm about to suggest - how about filtering by IP address. Since you provider IP is rarely going to change you can use Javascript to kick out or deny requests from IP addresses other than yours. Maybe a clean redirect to http://www.google.com or something silly like that. Although I would still suggest locking it down with a login and password and just have it write a never expiring cookie. That's still not a great idea but a shy bit better than the road your trucking down right now.
You could always limit the connections by IP address (If you know it ahead of time/it's reliable):
Apache's access control
If it is just for a shop window, do you even need access to a web page?
You can host the file locally.
Personally, I wouldn't worry about it, if no-one is linking to it externally it is unlikely to ever be found by search engines.