My site flagged as unsafe by Smartscreen only in Microsoft Edge - magento-1.9

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.

Related

Signing an extension

How can I sign my extension so users make sure my extension is safe and it won't steal their information? My extensions needs to access page contents, some users have no good sense of permitting an extension to do so.
Can I sign my extension using a verified sign provider, for example VeriSign?
When you publish an extension to the Chrome Web Store, the only "proof" that users can have of your extension is given by the rating system and the comments of other users. An hypothetical user that wants to install your extension, looks at the ratings and the comments, so make sure that your extensions has a good feedback from its users.
By the way, Google doesn't always look at the internal code of your extension manually, most of the times it only performs some heuristic checks on the code. So the problem is that developers could easily include some malicious code that may not be recognized and that could harm user's privacy in their extension without any problem.
Therefore, due to the Chrome Web Store policy, "validating" your extension is not possible at all. Plus, using SSL servicies (like the one you mentioned) will not make any sense since that your extension's scripts are stored locally.
What you can do is:
Encourage users in rating your extension and leave good feedbacks if they like it.
Redirect users to help links in case of trouble (links like "having trouble?" in your popup and so on).
Write a good worded description, and obviously add some images (or videos, better) to clearly show why an user may find your extension useful.
Always be nice (implied, ahah).
Your extension cannot be signed by an external provider, but it is signed by Chrome Web Store itself.
Every extension has an associated private key used for signing. It ensures consistent extension ID and updates. You can generate one yourself by packaging the extension as CRX (that produces a .pem file) and provide it when publishing on the CWS, or CWS generates it internally when you publish it (and then there's no way to extract it).
From on then, only code signed by this key (by the Web Store engine) will be recognized by Chrome as an update. Furthermore, at least on Windows only CWS-signed packages can be installed.
This security is as strong as the developer's Google account: if it is compromised, CWS will accept an update to your extension, which will be signed with the same key.
Although, as Marco correctly pointed out in his answer, the act of signing something would be just snake oil with respect to security. This signature verifies the identity of the publisher, but nothing more.
There's one more aspect - verified sites. If your extension interacts with a site you control, you can certify this by associating your extension with the site. It will be visible in the Web Store.
CWS-signed packages have an additional warranty of saying "so far, we did not catch this extension breaking any rules". Google can pull the extension off Web Store, and in severe cases blacklist and remove it from all Chrome installs. So that's an additional assurance for the user.
Google runs automated heuristic checks every time you submit your extension, which can trigger manual review. But that's invisible to the user.
That said, make sure to only ask absolute minimum permissions you need. For instance, look into the activeTab permission. It gives full host permissions for a tab when the extension is invoked by the user, but does not result in any permission warning. This was specifically added to address concerns about blanket extension permissions.

Google Chrome: File is malicious

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.

Phishing Detected! warning in Chrome

I have encountered the "Phishing Detected" warning in Chrome browser on my dev site. Interestingly I don't encounter the same warning in Firefox or Safari even though, as far I can tell, they are using the same phishing database (although in Safari preferences it says "google safe browsing service is unavailable"). I also don't encounter the warning on the same page of the production sites.
It first popped up on a new account verification page I created which amongst other things asked users to confirm their PayPal account with the GetVerifiedStatus API. This requires only name and email.
I have also encountered the warning on a configuration page which asks for the PayPal email address which the user wishes to receive payments to.
Neither page requests a password or any other data that would be considered a secret.
As you might gather I have zeroed in on a potential false positive on the PayPal portion of the content as if perhaps I am phishing for PayPal information beyond the payers email address. There has been no malicious code injection or any such thing. Even when i've removed all content from the page the warning is still present.
I reported the first incorrect detection to Google, and intend to do the same for the second incident, however what I really want to clear up is:
What content can lead to this warning?
How can I avoid it in the future?
How can I get some info from the "authorities" on which urls are blocked? (Webmaster Tools is not showing warnings for the dev site)
How can I flush my local cache of "bad sites" in case I want to re-test?
Clearly having a massive red alert presented to a user on a production site would be disastrous, and there is a (perhaps deliberate) lack of information about how this safe browsing service actually works.
I have been developing a website for a banking software developer and ran into the Phishing warning as well. Unlike you I had no PayPal associations in any of my code and well not even any data collection besides a simple contact form. Here are some things I managed to figure out to resolve my false positive warnings.
1) The warnings in Chrome (red gradient background) is a detection method built into the Chrome browser itself and it does not require to check any blacklists to give the warning. In fact Google themselves claim that this is one of the methods that they discover new potentially harmful sites. When your site is actually on the blacklists you get another red warning screen with diagonal lines in the background. This explains why you only see the warning in Chrome.
2) What actually triggers this warning is obviously kept kind of hidden. I could not find anything to help me debug the content of my site. You have pretty much done this, so for anybody else in need of help, I had to isolate the parts of my site to see what was triggering the warnings. Due to the nature of the site I was working on it turned out to be the combination of words and phrases in the content itself. (e.g Banking Solutions, Online Banking, Mobile Banking). Alone they did not trigger anything but when loaded together chrome would do its thing. So I'm not sure what your triggers are or even what the list of possible triggers are. Sorry...
3) I found that simply quitting Chrome completely and restarting it resets the "cache" for whether it has perviously detected a page. I closed Chrome hundreds of times while getting to the bottom of my warnings.
Thats all I have and hope it helps.
Update: My staging area was accessed via an IP address. Once I moved the site to use a domain instead all the warnings stopped in chrome.
I experienced the same today while creating an SSL test report for my web server customers. What I had there was simply something like this:
"Compare the SSL results of our server to the results of a well-known bank and its Internet banking service". I just wanted to show that the banking site had grading B whereas ours had grading A-.
I had two images from SSL-Labs (one the results for my server and the other the results of the bank). No input fields, no links to any other site and definitely no wording about then name of the bank.
One h1, two h2 titles and two paragraphs plus two images.
I moved the HTML to the page and opened it in my Chrome browser. The web server log told me that a Google service had loaded the page after 20 seconds from my first preview. Nobody else had seen it so far. The phishing site warning came to me (webmaster) in less than an hour.
So it seems to me that the damn browser is making the decision and reporting to Google which then automatically checks and blocks the site. So the site is being reported to Google by Google tools, the trial is run by Google and the sentence is given by Google. Very, very nice indeed.

How to capture image with html5 webcam without security prompt

I need to capture image from web page without security warning.
Page where i need webcam functionality can not be switched to https protocol.
I've installed root certificates and made them trusted.
I tried to insert iframe (which pointed to secure protocol https://mysecurepage.com) inside page (http://mypage.com), but not worked.
#bjelli is correct - this is a major security flaw for any internet content. Just imagine if you could go to a website which would start taking photos/recording everything going on without any permissions or notifications!
However, I am working on an intranet project where disabling the prompt would be quite safe.
If you are in this sort of position - there is one thing you can do;
Google Chrome Policies
If you are deploying the browser, you can override the security prompt for sites you specify. I don't know if you are working in such an environment, but this is the only way you can avoid the prompt all together. Similar things probably would apply for other browsers too.
As defined in http://www.w3.org/TR/mediacapture-streams/
When the getUserMedia() method is called, the user agent MUST run the following
steps:
[9 steps omitted]
Prompt the user in a user agent specific manner for permission to provide the
entry script's origin with a MediaStream object representing a media stream.
[...]
If the user grants permission to use local recording devices, user agents are
encouraged to include a prominent indicator that the devices are "hot" (i.e. an
"on-air" or "recording" indicator).
If the user denies permission, jump to the step labeled failure below. If the
user never responds, this algorithm stalls on this step.
If a browser does not behave as described here it is a serious security problem. If you find a way of making a browser skip the "permission" you have found a security problem.
What do you do if you find a security problem?
Report it IMMEDIATELY! Wikipedia: Vulnerability Disclosure
Firefox: http://www.mozilla.org/security/#For_Developers
Internet Explorer: http://technet.microsoft.com/en-us/security/ff852094.aspx
Safari: https://ssl.apple.com/support/security/
Chrome: http://www.google.com/about/appsecurity/
Opera: http://www.opera.com/security/policy
This is not just a question of technical possibilities, it's also a question of
professional ethics: what kind of job would I not take on? should I be
loyal to my customer or should I think of the welfare of the public? when do I
just follow orders, when do I stop bad stuff from happening, when do I blow the whistle?
Here are some starting points for computing professionals to think about the ethics of their work:
http://www.acm.org/about/se-code
http://www.acm.org/about/code-of-ethics
http://www.ieee.org/about/corporate/governance/p7-8.html
http://www.gi.de/?id=120

Techniques for securing a pure HTML site

I have been tasked with securing a pure HTML website for someone, and I'm not entirely sure how to approach the problem. Here are the constraints:
All logins must link in with our current Active Directory domain.
(Optional, but desired) The solution must whitelist requests coming from inside our intranet - that is, if someone attempts to access the site from on campus, they are immediately allowed in.
(Optional, but desired) The solution must whitelist requests made from our hub website, regardless of whether or not they are on campus. Said hub site is secured with logins that reference our Active Directory domain, so this is essentially a request for a passthrough.
The vast majority of our user base is very non-technical, so as small a footprint with few requests for logins is nessecery.
Normally, I'd have no problem with this, but this is a pure HTML website so my options are a little limited. My current ideas:
Use IIS6's Directory Security to simply force Active Directory authentication. I cannot use the IP permit/deny because that check comes before anything else in the life cycle and quickly denies anything on the deny list. I cannot change this behavior.
Code an aspx file that resides on our hub website that pre-loads the integrated Windows security credentials for the user, automatically authenticating them to the HTML website. As far as IIS is concerned, however, these are two different websites and this sounds like bad practice at best and an imitation of a cross-site intrution attempt at worst.
I have to admit I'm stuck. Has anyone ever handled a problem like this before?
Assuming you are using Windows2003/IIS6 and your web server is part of your domain you can do the following:
Configure your website to use Integrated and/or Basic authentication to authenticate against Active Directory. Also disable anonymous access. You'll find these settings by clicking "Edit" in the "Directory Security" tab of your website in IIS Manager. You'll only need to enable Basic if your users will use a browser other than Internet Explorer. If you use Basic your should also use SSL to protect your usernames and passwords. The level of access is determined by the permissions set on the files/directories on your website's root/child directories. Any files within these directories will only be served to authenticated users.
To allow users on your domain to logon without a prompt you will need to configure Internet Explorer to automatically logon to sites within your intranet. You'll also need to enable Integrated authentication for your website in IIS.
I'm not sure if the requirements in item #3 will be met. If your hub website uses impersonation it might pass your Windows credentials to another server within your domain but I suspect not.
References:
"How to configure IIS Web site authentication in Windows Server 2003"
http://support.microsoft.com/kb/324274/
"Internet Explorer May Prompt You for a Password"
http://support.microsoft.com/kb/258063
"How to use security zones in Internet Explorer"
http://support.microsoft.com/kb/174360/EN-US/
If the pure-html site is running on IIS, converting it to a .Net web app just to wrap its resources in your custom conditional forms login using the richer ASP.Net security wrappers seems like a natural enough fit. You can serve the pure HTML files out of that now-application.
This has no downside for the content maintainers that I can see.