Lately, the unregistered (available) domain heiiehdsx.com has been showing up in my HTTP referrer logs. It comes from a variety of IP addresses (none very similar). When I Google the domain, the only results are reports of it appearing in other server logs as well.
Anyone have any idea what's going on here?
Looks like a spoofed header.
Most HTTP headers can be very easily spoofed.
FireFox even has an add-in for modifying headers.
Chances these are from a bot/spammer that is looking for vulnerable targets.
This is referer spam. Bad guys trying to provoke you to visit their websites.
Related
To guard against broken links on my servers, I thought it would be great if I could configure Apache to detect them automatically when someone clicks on them and then alert me. Is this possible? What I was imagining is that when a 404 occurs, it checks the referrer and if that is the same server, sends out an alert (for example an email).
I've searched for this subject, but everything I can find is either just about logging and does not address the referrer part, or is unanswered. I guess there are two major components to my question:
Can I configure Apache to check the referrer and take some action when it is the same server?
Can I configure Apache to send out an alert on certain conditions, e.g. by sending an email?
Our website uses cloudflare as it's CDN to handle loads.
One of our apps requests the URL http://www.codenameone.com/files/cn1libs/CN1JSON.cn1lib with a get request. This works fine for every machine/location we tested but we have user complaints that they are getting an HTTP 411: "Length Required" response.
Since this is a GET request content-length doesn't seem like a header we would need to send...
Our server logs don't show any 411 response so my only conclusion is that this is a failure on the cloudflare side. However, since we can't reproduce this and the cloudflare aspect is a black box I don't have much to go on in terms of debugging.
I tried contacting cloudflare support but effectively got the usual "run around" asking me to send traces from a users machine on the other side of the world which is not something I can realistically do.
After a long session with cloudflare support it seems that unless you are an enterprise subscriber log files for access just don't exist. So effectively their support sees cloudflare as a black box just like we do.
Since the problem clearly isn't in our servers my educated guess is that this is a bug in cloudflare related to some odd edge case.
If someone has a better answer than this I'll gladly accept it.
I am trying to access a secure website using this kind of url: https://securenet.someBank.com. Everything is good and I am shown the login page. Now when I just type:
http://securenet.someBank.com (i.e http instead of https) I expect to get back a page with https in the browser. (e.g when you say:http://mail.yahoo.com, you get back https://mail.yahoo.com).
But in this case https:://securenet.someBank.com just says :Page cannot be displayed.
So what did the website developer do wrong in implementing security? I am just curious. I thought this kind of thing (http --> https redirection) was handled automatically by the web server and the website developer does not even need to do anything. But apparently it is not so.
The redirections from HTTP to HTTPS are merely a convenience for the user.
As I was saying in this answer on Webmasters.SE, only the end user can check whether HTTPS is used at all, and whether it's used correctly. A MITM attacker could otherwise prevent that initial redirection from happening at all.
These automatic redirections are only useful based on the assumption that there's no MITM performing such an attack. They're useful to get the user used to seeing HTTPS on pages that should be secure, but whatever happens, it will always be up to the user to check what they're connecting to. Therefore, I wouldn't necessarily call the absence of such a redirection a developer or sysadmin mistake.
As a user, you should always bookmark and use the https:// address for sites where you expect it should be used.
[...] https://securenet.someBank.com. Everything is good and I am shown the login page.
[...]
But in this case https:://securenet.someBank.com just says :Page cannot be displayed.
Here, assuming the double :: is a typo in your question, you seem to contradict yourself. If https://securenet.someBank.com just says "Page cannot be displayed", this would be a mistake indeed.
besides the recommendation by Bruno above I would recommend you to read the following:
https://www.owasp.org/index.php/HTTP_Strict_Transport_Security
There are two things you could do:
1) Force HTTP Strict Transport Security
2) Do a permanent redirect as described in the example on that page.
Any questions, just let me know.
Fabio
#fcerullo
Probably wrong server configuration. For example in apache one must define a redirect option in httpd.conf file in order to automaticaly redirect to the https URL of the page.
Alright, you think that this might be one of the most asked question on the internet, and you're tired reading the exact same answers. So let's focus on one of the most common answer, and forget about the others.
One of the common answer is:
"The https-site and the http-site are two completely different sites;
it’s a little bit like having a www version of the site and a non-www
version. Make sure you have 301 redirects from the http URLs to the
https ones." (source:
http://www.seomoz.org/ugc/seo-for-https-with-s-like-secure)
So here's my question:
Why are people saying that https and http are two different websites? How different is https://www.mydomain.com from http://www.mydomain.com?
The URI is the same and the content is the same. Only the protocol changes.
Why would the protocol have any impact on SEO? Whether or not the content is encrypted from point A to point B, why would that matter SEO wise?
Thanks for your help!
-H
Http and https could technically be two different sites. You could configure your server to server completely different content. They have two different urls (the difference being that s).
That being said, almost all webmasters with both http and https serve nearly identical content whether the site is secure or not. Google recognizes this and allows you to run both at the same time without having to fear duplicate content penalties.
If you are moving from one one to another, you should treat it similarly to other url changes.
Put 301 redirects in place so that each page gets properly redirected to the same content at its new url
Register both versions in Google Webmaster Tools
I have not personally done this switch, but it should be doable without problems. I have made other types of sitewide url changes without problems in the last couple years.
The other alternative would be to run both http and https at the same time and switch users over more gradually. As they log in, for example.
Update to above answer as on August 2014, Google has just confirmed that sites secured by SSL will start getting a ranking boost. Check official statement here: http://googlewebmastercentral.blogspot.in/2014/08/https-as-ranking-signal.html
Don't think about it in terms of protocol. Think about it in terms of potentiality from a search engines point of view.
http://example.com and http://www.example.com can be completely different sites.
http://example.com/ and http://www.example.com/home can be completely different pages.
https://www.example.com and http://www.example.com can, again, be completely different sites.
In addition to this, https pages have a very hard time ranking. google etc.
If your entire site is https and pops an SSL certificate to an HTTP request, G views them as secure and that they're https for a reason. It's sometimes not very clever in this regard. If you have secure product or category pages, for instance, they simply will not rank compared to competitors. I have seen this time and again.
In recent months, it is becoming very clear Google will gently force webmasters to move to HTTPS.
Why are people saying that https and http are two different websites?
How different is www.mydomain.com from
www.mydomain.com?
Answer: Use the site: operator to find duplicate content. Go to a browser and type:
site:http://example-domain.com
and
site:https://example-domain.com
If you see both versions indexed in Google or other search engines they are duplicates. You must redirect the HTTP version to the HTTPS version to avoid diluting your websites authority and a possible penalty from Google's Panda algorithm.
Why would the protocol have any impact on SEO?
Answer:
For ecommerce websites, Google will not rank them well without being
secure. They do not want users to get their bank info etc stolen.
Google will be giving ranking boosts to sites that move to HTTPS in
the future. Although it is not a large ranking signal now, it could
become larger.
The guys at Google Chrome have submitted a proposal to dish out
warnings to users for ALL websites not using HTTPS. Yes, I know it
sounds crazy, but check
this out.
Info taken from this guide on how to move to HTTPS without killing your rank.
Recently, if SSL is inactive in Firefox browser, it shows an error. You must enable SSL and redirect the URL to HTTPS 301
I have a login screen which I'm serving over SSL. The user fills in their login/password, this gets POSTed to the server. At this point I want to jump out of SSL, so I redirect them back to the same page with no SSL.
This causes the browser to show a warning dialog "You are about to be redirected to a connection that is not secure". How can I avoid this? I've been plenty of sites like yahoo mail, and gmail that give you an SSL page for login, then send you to a non-SSL page after this.
Secondary question: what's the purpose of this dialog? It's trying to warn me about some nefarous purpose - but what's so bad about redirecting someone to a non-SSL page? I don't get a warning when I'm on an SSL page and click a non-SSL link. What's different about redirecting someone?
I'm doing this in ASP.NET 2.0 - but I figure this is a generic web-dev question.
UPDATE SUMMARY: It seems the popular answer is "DON'T AVOID IT". I can understand that a user should get a message when security it being removed. But I don't get a dialog when I follow a link and security is removed, so at the very least I'd say this is inconsistent.
The dialog / browser versions. I actually don't see the dialog in IE7/FF3 (maybe I've clicked a checkbox preventing it). More importantly the client DOES see it in IE6 - with no checkbox to remove it (yes, I know IE6 is old and crap).
Firefox2: FF2 http://img521.imageshack.us/img521/8455/sslwarning.jpg
IE6:
The alternative: make the entire site SSL, never redirect the user out of SSL. I could handle that. But I've got a semi-technical client who has some fairly good points:
"SSL is going to cause an increase in traffic / processing power". I don't really buy this, and I don't think his site is every going to require more than one box to serve it.
"Yahoo does it. Yahoo is a big technical company. Are you smarter than Yahoo?"
I'm going to try sway the client over to an entirely SSL site. I'll argue Yahoo's approach made sense in 1996, or for a site that is MUCH more popular. Some official links explaining why this dialog happens would help (i.e Jakob Nielsen level of authenticity).
I've hit this same problem a while back. So I had a look inside fiddler to see how yahoo mail does it. Here's the step I saw (and used on my site):
User fills in SSL encrypted form, and POSTs to the server. Server authenticates, and spits out some script to redirect the client
<script language="JavaScript">
<!--
window.location.replace("~~ non-SSL URL ~~");
// -->
</script>
I figure the client side code is there to avoid this dialog.
"How can I avoid this?"
You shouldn't!
Although you could try that with JavaScript. This might work on some browsers and fail on others.
"What's the purpose of this dialog?"
It warns because switching between SSL and non-SSL on websites is usually unexpected by the user. A warning about the "non-SSL to SSL" is not emitted since it increases security and privacy. However, when security is suddenly decreased, the user should notice that quickly, in order to avoid a false feeling of security. In fact, redirecting to a non-SSL site is sometimes used in XSS/MITM attacks.
"SSL is going to cause an increase in traffic / processing power"
This is nonsense. It might be true for sites full of big, static content. However, for normal dynamic web applications, encryption is very cheap compared to business logic, database access, etc.
There is an urban legend saying that SSL-content is not chached by browsers. See "Will web browsers cache content over https" for more information.
"Yahoo does it. Yahoo is a big technical company. Are you smarter than Yahoo?"
Some rhetoric counter-questions:
Are you a big technical company like Yahoo?
Did being a big technical company prevent Microsoft from producing crappy software?
Do you have to support crappy old (SSL-broken) browsers, as Yahoo has to?
The attack this is preventing against is a man-in-the-middle SSL session strip. The message is there with good cause.
As for the purpose: It's to make you aware that your connection won't be SSL encrypted anymore. You may have seen before that the connection is encrypted and may think that it still is, so this warning says "Just to be clear, whatever data you send from here on will be plaintext".
As for how to suppress it: AFAIK you can't, it's a browser thing, what would be the point of the message otherwise? Even though there are workarounds like client-side redirects, I don't think you should try to work around client "problems" like this. If the browser chooses to be verbose, let it. There's a "Don't show this again" checkbox on the dialog after all If the user wishes to suppress this message he can easily do so, and maybe he actually likes to see it.
Also, IMHO, if the browser was worth its salt it would still pop up this warning, even if you employed client-side redirect tricks.
Use SSL for the whole page in the first place!
There's nothing wrong with SSL. You should provide user privacy everywhere, not only on login. It makes sense an the whole site. So simply redirect all non-SSL pages to SSL pages and keep everything SSL.
Just point your client to the latest attacks against mixed mode content (lookup CookieMonster on fscked.org) and proxy attacks (against sites available both in http and https, lookup Pretty-Bad-Proxy). He might reconsider.
It is much easier to get security right if you only deal with one protocol without mixing the two. SSL adds a bit of overhead, but it is nothing compared to the cost of a breach.
Gmail, yahoo, etc. use SSL for an encrypted iframe, which authenticates, but there's none of the in-page redirection you're talking about. The whole page isn't encrypted for these login systems.
read:
http://support.microsoft.com/kb/883740
which says that this is fixed in a hotfix or with a changed registry setting. However, not all the IE6 cpu's we use have this problem, nor do their registry settings correspond to what this article says they should. Also some that give the msg are XPsp3 and IE6 sp3.
We have an https log in screen that uses code to log into 15 other (http) domains and some of our IE6 users have to click 'Yes' 15 times. This is inacceptable to them.
No, we cannot control what browser all our users use. Some are not compatible with upgrade to IE7.
We are looking for some config attribute for each user to adjust that will suppress this msg. We've identically configed a 'bad' browser with settings that match one that does not give the msg. Internet and Intranet Security and Advanced settings and Proxies (none).Also Network connections. No joy so far.
Any ideas?