51–60 of 60 posts
The sixth link from the Google result, https://jpl-vmdb03.inetuhosted.net/sjsuvc.drivingcreative.co... , Is that the JPL I thought it was?
The IP block is managed by INetU Inc, which was apparently a cloud hosting company now owned by Canadian telecommunications company Shaw Communications.
https://whois.arin.net/rest/poc/II25-ARIN
https://www.crunchbase.com/organization/inetu-managed-hostin...
One of the more amusing patterns I spotted in the URLs is where an alarming amount of the filesystem appears to be exposed, e.g.: www.dulceswilly.com/mysql/BHP_sym/root/usr/local/etc/apache22/server.key If I was on a non-company IP, I'd be tempted to poke around and see what else is visible...
that yields just 7 pages (10 items each) so it's probably pretty irrelevant. but of course you are welcome to share your run of the mill anecdotes about some intern once accidentally publishing passwords - etc. :)
For me the top of the first page said about 1160 results. Still a surprisingly small number of hits.
Earlier quoted context omitted.
For me the top of the first page said about 1160 results. Still a surprisingly small number of hits.
That's because Google always inflates result numbers, until you get to the last page... for me, that last page is 5 and there is 46 results.
For instance, there have been times I've searched for something, and it gives back a lot of results, plus it has a pager with seemingly over 50 pages in it.
But - if I say "jump to the last page", suddenly the pager only shows four pages and I'm at the end of page 4...
What the heck is up with that? Sometimes, some really great information is buried under all the SEO'd to hell-and-back crap at the top. That's the info I want, and I don't care if the website owner cares about SEO or whatnot - because they are likely a small-time user (or they just have a very old page or something that hasn't been updated in 20 years)...
It took me about 15 seconds to understand. WTF! Why are people uploading their private keys to github?!
The better question are those actual non-github sites that have them exposed (though others here have noted that those sites may already be hacked).
Slightly related question about API keys that rely on referer (say Google Vision) - what stops me using curl to spoof referer and rake in thousands in someone’s bill (15 cents per 1k recognitions)? I assume there’s some IP based quota, but I haven’t seen a knob for that on GCP at least.
This should be enforced on your server and you shouldn’t have clients directly connecting to a service like Google Vision. I have a system that uses AWS lambda so that I don’t have to distribute my 3rd party API keys but I still have to add rate limiting.
Earlier quoted context omitted.
That's because Google always inflates result numbers, until you get to the last page... for me, that last page is 5 and there is 46 results.
I've often wondered why they do this; what's the point in offering misleading results? For instance, there have been times I've searched for something, and it gives back a lot of results, plus it has a pager with seemingly over 50 pages in it. But - if I say "jump to the last page", suddenly the pager only shows four pages and I'm at the end of page 4... What the heck is up with that? Sometimes, some really great inf…
Hmmm my idea would be "Hello from github, We detected that you uploaded credentials to NAME_OF_REPO. We strongly advise against this as it allows attackers to easily gain unauthorized access to your software and infrastructure. Have a look at this blog where we discuss alternatives" EDIT: Just to be clear, I'm not suggesting a ban at all, just a friendly email in response to commits that introduce credentials to publ…
Earlier quoted context omitted.
I know you mean well but no charge should be introduced to mitigate against this stupidity. You are (probably correctly) assuming that the data in question is genuine. Nonetheless it is none of our business. rm -rf /* does not contain a warning message and that is the way it should be.
Misleading? Because "rm -rf /" does give a warning. From info rm: `--preserve-root' Fail upon any attempt to remove the root directory, `/', when used with the `--recursive' option. This is the default behavior.