I often produce mathematical software in Delphi 2009, and publish it on my web site. However, the last year or so, Google Chrome has started to consider a small (but increasing!) number of my EXEs 'harmful', and Google Chrome refuses do download them.
For example, today I wrote a program that visualises the Lorenz attractor. You can find it at https://specials.rejbrand.se/chaos/lorenz/; it's lorenz.exe.
When I use Google Chrome to download this EXE, the following prompt appears:
(Yeah, I actually did try it three times...)
This is Swedish, and the text says "%s is harmful and has been blocked by Chrome". The button says "Remove permanently", and the drop-down menu doesn't offer any other actions (like "I know the file is safe, please let me have it").
Obviously, this is kind of a problem. As far as I know, the EXEs are perfectly safe. At least the code I have written is not harmful in any way, but I suspect there is a theoretical possibility that the Delphi compiler has started to add harmful code behind my back.
Questions
Is there something harmful about my EXEs?
Is there some way to make Google Chrome not block my EXEs?
I could reproduce this behavior with Chrome with your original EXE.
Is there some way to make Google Chrome not block my EXEs?
I can confirm that after I digitally signed it (with my company's signing code certificate) Google Chrome downloads this file without any issues. This is the most efficient (maybe the only) way to avoid this kind of problems.
Another quick solution is to pack the EXE with RAR. Chrome downloaded it with no problem.
Surely this is a False positive "detection" with Google Chrome. My Antivirus (NOD32) did not
found any problem, and other browsers did not have any issues with your EXE.
NOTE also that Your domain might have issues (flagged) as #Sertac Mentioned. If I download your original EXE from my website the error message is %s is not comonly downloaded and could be dangerous. Same goes for any other EXE I uploaded to MY site. (You still have an option to "Keep" the file)
See also here: Google Chrome Browser Will Block Dangerous Downloads
Specially this:
As welcome as the new features are, Chrome is in the unusual position
of playing catch up to Internet Explorer 9, which features an arguably
superior method of blocking potentially malicious downloads.
Microsoft's SmartScreen Application Reputation rates downloads in
three ways: whether they're digitally signed, the reputation of the
author, and--arguably most importantly--how many times the file has
been downloaded by others.
"Is there something harmful about my EXEs?"
No.
Here's a link to the results of Jotti's malware scan (which results with: 22 out of 22 scanners "found nothing"):
http://virusscan.jotti.org/en/scanresult/df25dbecfccc5d10862f52236d664d48d0c72058
The link to virustotal scan (detection ratio = 0/53):
https://www.virustotal.com/en/file/51d9d637a17f5876c371e5eec164e1dc48a35c56900a3235a9c656d10687814a/analysis/1408587813/
"Is there some way to make Google Chrome not block my EXEs?"
One option is to make it block nothing, evidently it's crap anyway. The option is in the "privacy" section in "advanced settings", here are the instructions:
https://support.google.com/chrome/answer/4412392?p=ib_download_blocked&rd=1
Otherwise, you can check what google thinks about safety of your site:
http://www.google.com/safebrowsing/diagnostic?site=rejbrand.se
The report seems to be somewhat indeterminate. Here's a quote (for rejbrand.se):
Has this site hosted malware?
Yes, this site has hosted malicious
software over the past 90 days. It infected 0 domain(s), including .
Presumably you can also request a site review in the security issues of google webmaster tools. But apparently it's not always fruitful. That last link also suggests there's a way to send samples to google hoping that they would analyze better (AFAICT it's not part of webmaster tools), but this might not turn out to be practical depending on the number of executables/versions you produce.
This is a fairly common problem, actually. Because Delphi makes software development easy and has no external runtime dependencies, it tends to get used for writing malware, unfortunately. And so some virus scanner heuristics that are supposed to detect malware instead end up detecting parts of the Delphi RTL.
The best thing to do is to do a bit of research and find out how Chrome is making this determination, and then send the people behind the virus scanner giving the false positives a copy of your EXE(s) with an explanation that this is a false positive and needs to be fixed.
I have equally been frustrated by this warning, and without going into a rant about how ridiculous the whole thing is, I will share the solution that worked for me.
I have found that double zipping got rid of the warning right away- zip your files, then zip the resulting zip file, the warning will disappear upon downloading.
The user will have to unzip 2 files to get to your files, but that is a much lesser inconvenience than the dangerous warning.
Related
I have switched to using Content-Security-Policy for my website. I'm starting to see reports about the following not being allowed: https://www.pagespeed-mod.com/v1/taas
Does anyone know why the website is trying to load this file? I'm using Google Analytics and Tag Manager, but I don't think that I have any page speed mod installed. Maybe this is an extension in the user's browser? Or when they open developer tools? Another source I could think of is automatic optimization through Cloudflare which I'm also running on.
Extra info: The source of loading this script is https://3001.scriptcdn.net/code/static/1 which doesn't reveal much about who made that.
Had the exactly the same issue and preventing me from using Element Inspector/ debugger. It appears to be some Chrome extension you have installed gone rogue, see if you have extension called "Auto Refresh Plus" installed like i did before.
I also see reports on https://www.pagespeed-mod.com/v1/taas being blocked with the same source of loading. It seems to happen in short periods on the various resources I have reports from. This indicates that it is related to the user/browser and not related to the site itself.
The same can be seen with translators, extensions, security proxies etc. I have given up trying to attribute the source of anything that is likely not caused by legitimate site content.
I will rephase for a more precisely question. If I click on a malicious/virus link, then I do not click on anything further or download anything from that website, can my PC get hacked?
I am asking this question on the perspective of a web developer through all the tools and programming languages.
If browsers work as intended, there shouldn't be, but there's always the risk that someone has exploited a vulnerability in a web browser that has gone undetected or unreported. Such vulnerabilities do occur, though most get fixed quickly.
It's highly unlikely that you'd just stumble upon such an exploit, but it's always best to be safe. If you don't know or trust the link, it's best to just not click it.
There is nothing standard that would allow a developer to hack or infect a client computer through a browser simply by the client loading the page.
I have read several articles on feature detection and that it is more reliable than browser detection because browsers lie.
I couldn't find any information on why they lie. Does anyone know the reason why they would do that?
As far as I understand it, Webmasters do browser sniffing to find the capabilities of a browser and limit what they send to the browser. If a browser lies about it's capabilities they will receive more from the webmaster, you can read more:
http://farukat.es/journal/2011/02/499-lest-we-forget-or-how-i-learned-whats-so-bad-about-browser-sniffing
http://webaim.org/blog/user-agent-string-history/
The reason is simple:
Because web sites look at the user agent string and make assumptions about the browser, which are then invalid when the browser is updated to a new version.
This has been going on almost since the begining of the web. Browser vendors don't want their new versions to break the web, so they tweak the UA string to fool the code on existing sites.
Ultimately, if everyone used the UA string responsibly and updated their sites whenever new browser versions come out, then browsers wouldn't need to lie. But you have to admit, that's asking quite a lot.
Feature detection works better because when a new browser version comes out with that feature, the detection will pick it up automatically without the either browser needing to do anything special nor the site owner.
Of course, there are times when feature detection doesn't work perfectly -- eg maybe if a feature exists but has bugs in a particular browser. In that case, yes, you may want to do browser detection as a fall-back. But in most cases, feature detection is a much better option.
Another more modern reason is to just avoid demands to install mobile apps (where product owners contol what I can and can't do with content. No thanks!).
Today Reddit started to block viewing subreddits in case they detect a mobile browser in UserAgent so I had to change it just to be able to view content.
I want to let users (i.e. anyone who signs up for an account) upload and download video and text documents. I have been researching the security issues regarding letting users upload files, but everything I can find on the subject assumes that users will only upload images.
Are there any security issues specific to letting users upload videos and text documents? Is security a lot more difficult when users can upload files at video size? Are there any particular file extensions I should look out for?
The problem is this: If you let users upload videos, images and text files, some of them will try to upload viruses, server-side scripts and other malicious code. Such code will then expose your site's users to what ever 'bad things' those users uploaded, within the context of your own site.
If you allow such uploads, you must be very careful that you are only saving files of the actual types you planned on - and not by looking at the file extension, either. You also must make sure those files are placed in locations where execute/script permissions are disabled.
Virus checking is a must - but it is not at all enough. A PHP script may not set off virus warnings at all, but that same script could reveal vital information for your site, or cause other bad things to happen if executed.
You must examine the content of the files - never rely on the extension or MIME type reported by the client. Those can easily be faked.
Serve your downloads from a location for which you have disabled the execution of server side code. This is all you need to do to protect yourself from server side exploits. Relying on file extensions or other such things are all hacks.
If you want to fully protect your users (and indirectly your website) as well, you'll need to run the files through a suitable virus scanner. It is possible, and there are real-life examples of doing so, to exploit video decoders and such software to run arbitrary code. But if you start walking down that line, you could also argue that certain text strings might set off weird behavior in certain software, and that starts getting silly. Luckily, the people who write virus scanners will have done most of the work for you. So:
Never execute that what is uploaded
If you feel it's needed, virus scan them as well.
You can virus check each file that is uploaded. If you look at most web based email clients you will see when you upload a file they are checked by McWhoever. In generally you shouldn't let them upload exe files but checking the extension is a very basic (unreliable) method.
It's quite hard to make an upload REALLY secure.
There are quite a lot of things to check - the file extension is just one part of it. Here are few things which have to be at least checked:
file extension (as you've already mentioned)
mimetype
filesize
depending on the users: maybe check the uploads with ClamAV ...
To answer your question here is a meta attack:
bad guy uploads a binary to your
server, perhaps tricking your
filters by compressing file and
changing extension to .avi
exploit bug in a CGI script to
decompress avi from #1
exploit bug in another CGI to
execute file from #2 -> backdoor
installed
backdoor accessed and rootkit
installed to hide all evidence of steps
1,2,3
Some variation on the above is what typically happens when servers are compromised.
I know this might be a no-brainer, but please read on.
I also know it's generally not considered a good idea, maybe the worst, to let a browser run and interact with local apps, even in an intranet context.
We use Citrix for home-office, and people really like it. Now, they would like the same kind of environment at work, a nice page where every important application/document/folder is nicely arranged and classified in an orderly fashion. These folks are not particularly tech savvy; I don't even consider thinking that they could understand the difference between remote delivered applications and local ones.
So, I've been asked if it's possible. Of course, it is, with IE's good ol' ActiveX controls. And I even made a working prototype (that's where it hurts).
But now, I doubt. Isn't it madness to allow such 'dangerous' ActiveX controls, even in the 'local intranet' zone? People will use the same browser to surf the web, can I fully trust IE? Isn't there a risk that Microsoft would just disable those controls in future updates/versions? What if a website, or any kind of malware, just put another site on the trust list? With that extent of control, you could as well uninstall every protection and just run amok 'till you got hanged by the IT dept.
I'm about to confront my superiors with the fact that, even if they saw it is doable, it would be a very bad thing. So I'm desperately in need of good and strong arguments, because "let's don't" won't do it.
Of course, if there is nothing to be scared of, that'll be nice too. But I strongly doubt that.
We use Citrix for home-office, and people really like it. Now, they would like the same kind of environment at work, a nice page where every important application/document/folder is nicely arranged and classified in an orderly fashion
I haven't used Citrix very many times, but what's it got to do with executing local applications? I don't see how "People like Citrix" and "browser executing local applications" relate at all?
If the people are accessing your Citrix server from home, and want the same experience in the office, then buy a cheap PC, and run the exact same Citrix software they run on their home computers. Put this computer in the corner and tell them to go use it. They'll be overjoyed.
Isn't it madness to allow such 'dangerous' ActiveX controls, even in the 'local intranet' zone ? People will use the same browser to surf the web, can I fully trust IE ?
Put it this way. IE has built-in support for AX controls. It uses it's security mechanisms to prevent them from running unless in a trusted site. By default, no sites are trusted at all.
If you use IE at all then you're putting yourself at the mercy of these security mechanisms. Whether or not you tell it to trust the local intranet is beside the point, and isn't going to affect the operation of any other zones.
The good old security holes that require you to reboot your computer every few weeks when MS issues a patch will continue to exist and cause problems, regardless of whether you allow ActiveX in your local intranet.
Isn't there a risk that Microsoft would just disable those controls in future updates / versions ?
Since XP-SP2, Microsoft has been making it increasingly difficult to use ActiveX controls. I don't know how many scary looking warning messages and "This might destroy your computer" dialogs you have to click through these days to get them to run, but it's quite a few. This will only get worse over time.
Microsoft is walking a fine line. On one hand, they regularly send ActiveX killbits with Windows Update to remove/disable applications that have been misbehaving. On the other hand, the latest version of Sharepoint 2007 (can't speak for earlier versions) allows for Office documents to be opened by clicking a link in the browser, and edited in the local application. When the edit is finished, the changes are transmitted back to the server and the webpage (generally) is refreshed. This is only an IE thing, as Firefox will throw up an error message.
I can see the logic behind it, though. Until Microsoft gets all of their apps 'in the cloud', there are cases that need to bridge the gap between the old client-side apps and a more web-centric business environment. While there is likely a non-web workaround, more and more information workers have come to expect that a large portion of their work will be done in a browser. Anything that makes the integration with the desktop easier is not going to be opposed by anyone except the sysadmins.
The standard citrix homepage (or how we use it) is a simple web page with program icons. Click on it, and the application get's delivered to you. People want the same thing, at work, with their applications/folders/documents. And because I'm a web developer, and they asked me, I do it with a web page... Perhaps I should pass the whole thing over to the VB guy..
Ahh... I know of 2 ways to accomplish this:
You can embed internet explorer into an application, and hook into it and intercept certain kinds of URL's and so on
I saw this done a few years ago - a telephony application embedded internet explorer in itself, and loaded some specially formatted webpages.
In the webpage there was this:
Call John Smith
Normally this would be a broken URL, but when the user clicked on this link, the application containing the embedded IE got notified, and proceeded to execute it's own custom code to dial the number from the URL.
You could get your VB guy to write an application which basically just wraps IE, and has handlers for executing applications. You could then code normal webpages with links to just open applications, and the VB app would launch them. This allows you to write your own security stuff (like, only launch applications in a preset list, or so on) into the VB app, and because VB is launching them, not IE, none of the IE security issues will be involved.
The second way is with browser plug-ins.
For example, skype comes with a Firefox plug-in, which looks for phone-numbers in web-pages, and attaches special links to them. When you click on these links it invokes skype - you could conceivably do something similar for launching your citrix apps.
You'd then be tied to firefox though. Writing plugins for IE is much harder than for FF, I wouldn't go down that path unless forced to.