81–90 of 140 posts
Earlier quoted context omitted.
Aah, he took down Chesterton's fence and found the reason of its existance! ( https://en.wiktionary.org/wiki/Chesterton%27s_fence )
More than once I have taken down a Chesterton's fence that I myself had originally put up
Earlier quoted context omitted.
You got a reference on the CFAA? On the contrary, I found that it was probably not a problem to change a URL parameter "We also note that in order to be guilty of accessing “without authorization, or in excess of authorization” under New Jersey law, the Government needed to prove that Auernheimer or Spitler circumvented a code-or password-based barrier to access. See State v. Riley, 988 A.2d 1252, 1267 (N.J. Super. C…
There is a massive difference between scraping unintentionally published information on a public website and cloaking your account to subvert your employer revoking access to its systems and continuing to access them when you know you're not allowed to be.
This seems like a bit of strech for “cloaking”. (Like wearing vaguely similar colored t-shirt as employees do)
> continuing to access them when you know you're not allowed to
This part is rock solid.
Earlier quoted context omitted.
Sure it is, this problem has been solved for a long time: SCIM. Any modern idp should support SCIM and if the app doesn’t I’d question using it at all.
SCIM adoption isn't near where it needs to be. I guess yeah, this is the correct answer. We live in a world where SSO is considered an enterprise feature, I hope one day that it's considered default.
Slack, to their credit, offers this at the business+ tier: https://api.slack.com/admins/scim
Earlier quoted context omitted.
Shameless plug for my startup (hope that's ok!) If you're building an app and need to add SCIM, check out WorkOS. My email is in my profile to chat. More info -> https://workos.com/directory-sync
$125 per connection / month and then you wonder why companies don't offer SSO/SCIM by default in their free/cheap plans.
Charging for scim is a convenient way to segment customers, the same way SLAs are. For companies that care deeply about controlling user access (or are forced to by law or regulator), that isn't much money.
Features like this subsidize the free/cheap version, which you can then offer to let folks learn about and love your software, and use. After all, you can replace scim with careful manual processes until you get to a certain size.
It's similar to the sso tax: https://sso.tax/
I'm not aware of a scim.tax site, but maybe there should be one? :)
I even made a vim plugin that highlights these "dangerous" characters: https://github.com/vim-utils/vim-troll-stopper
I've never been pranked with unicode characters, but I've had a situation at work where a consultant from Japan unintentionally used some "japanese space" characters in a translation file, and that broke our app. Since I have my vim plugin running all the time it didn't take me a lot to see what's going on.
I worked for $company where customer dashboards were set up on a wildcard - https://*.$company.com, e.g. https://foo.$company.com. Guess what happens when someone picks a dashboard slug that conflicts with an actual record, like `www` or `blog`? Their dashboard becomes completely inaccessible. Of course, the setting to change the prefix is also on https://$dashboard.$company.com, so the customer is unable to fix it themselves and requires support. Of course, support's tools don't expose the ability to change the $dashboard prefix directly...
Figuring out how to build the denylist isn't really trivial. Of course, there's pre-existing DNS entries. Then there's pre-existing $dashboard prefixes that already exist. Then there's dirty language, Unicode symbols, Punycode (i.e. xn-- prefixes)... then there's setting up redirects from the old prefix and reserving it so that nobody can claim it in the future...
I'm not surprised Slack has holes here, it's a fundamentally hard problem.
Earlier quoted context omitted.
At my previous job, we had an entire system aptly named Pandora whose entire role was keeping track of which ssh keys were permitted to be found on servers. It had a bot that would crawl through every server, and if it found a key not in it's database, it nuked it. Every new person or automation key had to first be registered fomarlly, with an end date. A bit of a hassle but definitely necessary for the space the com…
Why not use ssh certificates at that point?
Where “but not to C” is the reason for existence.
How certificates simplify that part?
(Never used them, but my understanding they are usefull when you want x1,x2,… ssh’ing into y1,y2,…; two uniform sets; if set sizes approach 1, then cert usefullness aproach zero)
I don't run IT these days, but when I did...we used to mark them as inactive in Azure Active Directory. They could no longer log in to any Office 365 service, Outlook Teams or whatever, and none of the third party services we had using MS SSO. Wouldn't you join Slack to it too?
I can still log into the google workspace, slack, check out confidential documents on drive (not because of transparency, but because they dont know how to share properly). I can check out what is happening in nearly any of their projects by peeking at the channel and if I want to know more, I just take a look at the documents, including their pitches. If I poked for a bit, I could probably also find API keys and DB credentials.
These people work for banks, insurances, national televisions, hotels, airlines and more.
If I was a bad actor, it would be incredibly easy to cause damage to both them and the clients or do insider trading based on the upcoming project data.
But it seems like half of these places just don't care about security - even when contacted, admins/responsible people just flat out ignored it.
And then we wonder how breaches happen.
A lot of people advise ways of locking down name changes, but this doesn't really solve the problem. I'm sure there's someone out there whose first name is actually Jira. I worked for $company where customer dashboards were set up on a wildcard - https://*.$company.com , e.g. https://foo.$company.com . Guess what happens when someone picks a dashboard slug that conflicts with an actual record, like `www` or `blog`? T…
If you want to allow some symbols you can either whitelist or check if usernames are an appropriate levenshtein distance away from core names (like say slackbot) and either ban such things or flag to a human "hey this could be an issue".
It's fundamentally hard to stop everything, but it's not hard to stop the biggest issues.