I often see in my webservers logs the “x-middleton” flag from amazon IP's ranges and looks like normal traffic (there is a variety of user agents but they all share that x-middleton at the end )
Anyone has any ideas what it might be ?
I came across this link http://support.ezoic.com/hc/en-us/articles/206245065-Origin-Errors-and-other-error-messages- but its not that it makes much sense either.
Ezoic adds it to user agents when it proxies traffic.
Related
Over the last couple days I've been getting millions of requests from rotating IPs. They're attempting to run post requests and seem to be using an incorrect HTTP_ORIGIN. By incorrect, I mean that it's not the same as what my server sends:
My server sends: "https://www.example.com"
The spam request sends: www.example.com
I placed some logging for each scenario:
User logged in and has incorrect HTTP_ORIGIN
User NOT logged in and has incorrect HTTP_ORIGIN
What I've noticed is that there are users that are logged in, but have the wrong HTTP_ORIGIN (origin is missing "https://". I have checked those user accounts and while they appear to be real, and not created by the original spam requests, they may be currently run through scripts.
It seems like it would prevent those users from accessing the POST requests of the site, but on the other hand, if they were real users, it would cause a problem.
Now if I were to put filtering in place to block requests that didn't match the origin, my questions are:
What would be the side effect of that?
Are there downsides or negative aspects?
Would I see drops in traffic?
If that so, It's like you said some are using your website from scripts, considering if your website is normal (I mean not like a website to upload data or sth like that), then it would be good to consider adding captcha to your website in place of filtering requests (cause I think it would be simple for those who send incorrect HTTP_ORIGIN to make a similar one to the original if they use a sslstream especially if it is for malicious goals).
And for the consequences if you use a filtering to the http request, I think the requests will drop remarkably (since you will refuse incorrect ones), and some real users who use scripts will switch to browser (it's a rare case especially if they scrape data from website in an automatic way) or they will stop using your website.
You need to wait for further research and make sure that those false requests are not malicious ones (perhaps they are using simple tcp client). Either way it is best for the time being to inspect data sent in the POST requests (incorrect ones) and see if there is some suspicious data (In that case you should use some safety method in your website)
I have seen some sites use hostnames as data such as usernames (for example username.example.com) and was wondering how you would be able to achieve this.
Is it good practice to use hostnames like this or are there reasons against it?
Thanks in advance.
It is generally bad practice to treat hostnames this way. Lookups become a bit more complicated and it is always safest to use usernames in the path or query.
Hostnames are designed to be thought of in a global sense. For instance user.example.com/username/profile
It also helps protect the user (a little) because paths can be encoded into the http request where a subdomain request essentially requests user.example.com and that request can be redirected multiple times before returning to the client and dns monitoring is the number one way that people do tracking.
DNS tracking is easy because its already fast, open, and the contents aren't designed to be hidden like https or more recent ipsec techniques.
I've accomplished this by setting up a DNS wildcard with your DNS host (*.example.com) then using PHP to parse out the username in the URL and act accordingly.
I am starting to see a few of these requests in my Apache logs. They seem to come in pairs; first a request for /notified-Notify_AUP followed by a request for /verify-Notify_AUP.
The requests come with a google search referrer pointing to my site. The requests seem to come from legit companies -- of course anything can be hacked.
I have never heard of these files, unlike so many of the other fishing expeditions aimed at all of our sites. Is this something new or are these legit and I am supposed to be providing some sort of reply?
Thanks,
Boggle
I finally found out that this is an attack on ProxySG. Since I do not have a ProxySG box, I can safely ignore this problem.
To deal with recent growth our application has been split across two sets of separate infrastructure. Approximately half of our customers are on set 1 and the other half are on set 2.
Both sets have different urls (api1.ourdomain.com and api2.ourdomain.com).
Problem is clients accidentally putt the wrong url and then wonder why they get error messages.
Other then user education any other strategies for dealing with this mess?
Is it possible to redirect requests to the correct endpoint?
Thanks.
I don't think your question is detailed enough to provide meaningful feedback. There are obviously several factors that could easily contribute to a recommendation.
Does your application make use of user profiles (or a similar construct)? If so you might consider associating a primary URI for each user in their profile and include logic in your application to interrogate the profile for each request and redirect if a user goes to the wrong URI.
Is this an authorization issue? If so you might consider including some basic authorization routing that provides a custom 403 page with the proper URL.
If you could provide additional detail I think we could be more helpful.
I'm making something that requires me to pass information from one domain to a subdomain. The subdomain would be in an iframe on the domain. I know I can use cookies, sessions, or a database. But I'm trying to save processing time so I thought about using the referrer. I know that some people turn the referrer off for some reason, but exactly just how many. If they do, this won't work for them.
Oh and I can't use the URL to pass information.
I'd say < 0.001 % of all Internet users have ever heard about referrers. Even a smaller portion of them will be willing to switch them off. Even a smaller number of them will be able to.