I have administrated a community site for quite a while and over the time a handful people have told me that their browsers got infected with a "malware addon" that randomly inserts ad banners in websites they visit.
While they say some websites don't seem to "allow" such foreign insertions, my forum did "allow" the adding of the browser ads. (For example a malware thing called "OnlineBrowserAdvertising")
Is there a way (through HTML, Javascript...) to prohibit browsers to add something to my site? I am 100% sure that my site or my webspace are not infected. It's the visitors' browser add-ons messing with my page.
You cannot prevent browsers from injecting their own code on your end - the data is retrieved from your server and stored locally (at least temporarily) by the user's device. From the moment the data leaves your server, it is essentially out of your control.
This is purely a client-side issue that can be rectified by following standard security practices. Tell your users to keep their software up-to-date, use an antivirus/firewall solution, and not to visit or download from suspicious websites.
Related
I developed a web app in VueJS, but it seems to be having some issues with CloudFlare.
When a user is prompted with the Captcha verification screen, upon completing the verification the page loads, but it is blocking resources like my JS files.
However, if I say whitelist a certain country and access it, the page works as intended.
I've also had some issue when changing certain elements and the page not updating correctly, even when purging. I feel this issue is related to the one above.
(I'm also using SSL if that makes any difference.)
Out of curiosity, I've recently seen a lot of pages using a “newer” 5 second protection style page rather than a captcha. I was wondering if cloudflare offered anything like this as I feel the captcha gets very annoying for my users.
Thanks and any help is appreciated.
I'm building a website for a company, I build this website offline so google won't index it, with the reason that google don't see the codes yet and thinks at the official launch that we copied the text/codes from an other website.
Sadly I encounterd a problem. I need to implant the facebook social plugin, sadly does this plugin only work when the site is online. But as I said putting it online can be dangerous for future Google SEO.
Is there an other option where I can see the facebook plugin but it is not online yet or is it okay for me to just place it online already on (for example) www.example.com and later put the released product on (for example) www.released.com.
Any toughts on this problem?
Why don't you place the website online in a folder that is blocked for Googlebot via robots.txt?
That way you can test all the online elements work and not have to worry about users and search engines finding it and listing it.
An alternative could be to use the .htaccess file to limit access only to your IP address - that way, you'd be the only one to see the site live.
This issue began last week. Prior to that, I was not having any problems, and I am not aware of any changes to my site or platform.
Now, when I want to share a new blog or article to Google+, it fails. Typically I would use the embedded +1 buttons on a specific post and use the expanded box to create my post. The box comes up, but instead of a nice title and image, it now uses the URL only for the page, and sometimes adds extra characters to the end of the URL. If I take the URL from the address bar and try to compose a new update directly on Google+, I get the same issue. If I enter the URL into the Link field on a status update, it usually comes back "could not load website."
Here's a sample
You'll find Google+ sharing buttons above and below the article. Sharing to every other network works as expected.
My site is a Drupal site that has been operating for 10 months. I am a Drupal developer, but have never encountered an issue like this.
It appears that requests from the Googler crawler are being rejected by your server. I tried testing the microdata with the structured data testing tool and it runs into problems connecting to your site. Other sites work fine.
If you have access to your site's Apache access logs, I would check those for problems coming to that URL. You can narrow your search down by looking for the user agent of the crawler: Google (+https://developers.google.com/+/web/snippet/)
My guess is that something changed in your server's configuration that is the cause. Start with the logs and see what's there.
I am currently assessing what are the best options to integrate multiple sites to a single sign-on system. The ambition is to have a unified header with shared assets across the sites. Currently it operates as a separate login page where the user is redirected back to the page they were on before, similar to Google accounts.
There has been a proposal for an iframe or a popup iframe.
The benefits for this appear to be entirely for the user, so the user does not have to leave the page they are on. My concerns with this approach are
if we make changes to the login page itself we will need to make changes to the iframe which could require a redeployment of all the sites at the same time
the suggestion for a regular iframe is intricate to the design and will create problems across browsers
pop up iframes are problematic on mobile devices
if a user has scripting disabled they will be unable to login
a user may have a pop up blocker in place
Does anyone have any other arguments for or against using iframes for an SSO system? Any critique on the points I have already raised are also greatly appreciated.
Thanks!
We have a mobile web based app at my company. Due to the nature of the application we do not want the browser on the users phone to prompt the user to save the passwords on the form a.k.a the autocomplete feature.
We managed to do that for IE and Firefox by setting the autocomplete tag to "off" but that doesnt seem to work for Opera mini (and i am guessing opera in general). I know user's can set it to off in their settings but for security reason we rather have it disabled?
Is there a workaround for this through code? the app is Java app using faces components based on an Jboss/Apache architecture.
In general, Opera lets the user configure whether it should respect autocomplete=off. On principle, users should be able to configure the password storage feature, and web sites should not be able to affect the configuration at a whim.
However, I can certainly see that for specific scenarios, like "send one-time passwords by SMS to the device Opera remembered the regular password on", this sucks. If you have stored password for a high-value site + use SMS one-time passwords as an "out of band" authentication, a lost phone becomes a major risk. The root of this problem is the assumption that an SMS constitutes "three-factor" authentication - if the stored login and the SMS is on the same device it's no longer "three-factor"..
It is tricky to try to leave users in control, while yielding to the web site when it's a really good idea to do so. Sadly, I think this is an unsolved question for now.
If you have a good use case for disabling password storage and are working on an important site, perhaps Opera Mini server admins could be persuaded to disable password manager on a site-specific basis? I don't know, but if you report it as a bug to Opera it would at least give the internal discussions some more momentum. Feel free to contact me with a reference to the bug report because I'm in a position where I could keep an eye on it ;-)