Live data from Hacker News

Writing "/etc/hosts" breaks the Substack editor

scalewithlee.substack.com

201–210 of 370 posts

Re: Writing "/etc/hosts" breaks the Substack editor

#201

Everything old is new again :) We used to call this the Scunthorpe problem. https://en.m.wikipedia.org/wiki/Scunthorpe_problem

I remember back in the old days on the Eve Online forums when the word cockpit would always turn up as "c***pit". I was quite amused by that.

Re: Writing "/etc/hosts" breaks the Substack editor

#202
post #173
post #148

Earlier quoted context omitted.

I found an example! https://retail.direct.zurich.ch/resources/definition/product... Questionnaire Zurich Cyber Insurance Question 4.2: "Do you have a technically enforced password policy that ensures use of strong passwords and that passwords are changed at least quarterly?" Since this is an insurance questionnaire, presumably your answers to that question affect the rates you get charged? (Found that with the help o…

Directly following is question 4.3: "Are users always prevented from installing programs on end-user devices?" Totally bonkers stuff.

This is standard practice for years in big corporations.

You install software via ticket requests to IT, and devs might have admin rights, but not root, and only temporary.

This is nothing new though, back in the timesharing days, where we would connect to the development server, we only got as much rights as required for the ongoing development workflows.

Hence why PCs felt so liberating.

Re: Writing "/etc/hosts" breaks the Substack editor

#203
post #188
post #173

Earlier quoted context omitted.

Directly following is question 4.3: "Are users always prevented from installing programs on end-user devices?" Totally bonkers stuff.

A trend for corporate workstations is moving closer to a phone with a locked-down app store, with all programs from a company software repo. Eliminating everything but a business's industry specific apps, MS Office, and some well-known productivity tools slashes support calls (no customization!) and frustrates cyberattacks to some degree when you can't deploy custom executables.

I don’t think locking down slashes support calls because you will now receive support requests anytime someone wants to install something and actually have a good business reason to do so.

Re: Writing "/etc/hosts" breaks the Substack editor

#204

Earlier quoted context omitted.

I don't get why you'd have SQL injection filtering of input fields at the CDN level. Or any validation of input fields aside from length or maybe some simple type validation (number, date, etc). Your backend should be able to handle arbitrary byte content in input fields. Your backend shouldn't be vulnerable to SQL injection if not for a CDN layer that's doing pre-filtering.

Because someone said "we need security" and someone else said "what is security" and someone else said "SQL injection is security" and someone looked up SQL injections and saw the word "select" and "insert". WAFs are always a bad idea (possible exception: in allow-but-audit mode). If you knew the vulnerabilities you'd protect against them in your application. If you don't know the vulnerabilities all you get is a fuz…

WAFs can be a useful site of intervention during incidents or when high-severity vulns are first made public. It's not a replacement for fixing the vuln, that still has to happen, but it gives you a place to mitigate it that may be faster or simpler than deploying code changes.

Re: Writing "/etc/hosts" breaks the Substack editor

#205

Earlier quoted context omitted.

While the password recommendation stuff is changing (the US government updating it guidelines last year), it’s generally best practice to not share passwords which itself implies using a password manager anyway which makes the whole “long passphrase” vs “complex” password moot - just generate 32 lowercase random characters to make it easier to type or use the autogenerated password your password manager recommends. T…

There's also login passwords, and depending on how many systems you have to log into, these can be quite numerous. There are some attempts to address this with smartcards and FIDO tokens and so on, but it's not nearly universal yet. At least SSH keys are common for remote login nowadays, but you still need to log into some computer directly first.

I find it rare to have a huge number of machines to log into that aren't hooked up to a centralized login server. Still, nothing prevents you from having passwords for each individual machine that needs it. It's cumbersome to type it in but it works, which is why I recommended all lowercase (faster to type on a mobile device).

Re: Writing "/etc/hosts" breaks the Substack editor

#206

Earlier quoted context omitted.

entropy is stronger than complexity. https://xkcd.com/936/

I wonder how many people have used Correct Horse Battery Staple as a password thanks to this comic

Ah, just mix them up randomly: Staple Battery Correct Horse!

Re: Writing "/etc/hosts" breaks the Substack editor

#207
post #7

Does it block `/etc//hosts` or `/etc/./hosts`? This is a ridiculous kind of whack-a-mole that's doomed to failure. The people who wrote these should realize that hackers are smarter and more determined than they are and you should only rely on proven security, like not executing untrusted input.

How would that be hard? Getting the absolute path of a string is in almost all languages stdlibs[1]. You can just grep for any string containing slashes and try resolve them and voilá Resolving wildcards is trickier but definitely possible if you have a list of forbidden files [1]: https://nodejs.org/api/path.html#pathresolvepaths Edit: changed link because C's realpath has a slightly different behavior

It’s not hard, but I think that’s more computation than a CDN should be doing on the edge. If your CDN layer is doing path resolution on all strings with slashes, that’s already some heavy lifting for a proxy layer.

Re: Writing "/etc/hosts" breaks the Substack editor

#208

> This case highlights an interesting tension in web security: the balance between protection and usability. But it doesn't. This case highlights a bug, a stupid bug. This case highlights that people who should know better, don't! The tension between security and usability is real but this is not it. Tension between security and usability is usually a tradeoff. When you implement good security that inconveniences the…

I would say it’s a useful security practice in general to apply WAF as a blanket rule to all endpoints and then remove it selectively when issues like this occur. It’s much, much, harder to evaluate every single public facing endpoint especially when hosting third party software like Wordpress with plugins.

Re: Writing "/etc/hosts" breaks the Substack editor

#209
post #158

Earlier quoted context omitted.

It's a relatively recent change, too. Transition from "the executives and managers mostly came up through 10-25 years of doing 'lower' jobs in the company, and very much know how the business actually works" to "we hire MBAs to those roles directly" was throughout the '70s-'90s. Finance and business grads have really taken over the economy, not just through technocratic "here's how to do stuff" advice but by personal…

They're taking over veterinary clinics too! The biggest owner of veterinary clinics is Mars inc. the candy company!

I wonder if Matt Levine has a bit about this

Re: Writing "/etc/hosts" breaks the Substack editor

#210
post #126

Earlier quoted context omitted.

I wish IT teams would say "sorry about the password requirement, it's required by our insurance policy". I'd feel a lot less angry about stupid password expiration rules if they told me that.

Sometime in the past few years I saw a new wrinkle: password must be changed every 90 days unless it is above a minimum length (12 or so as best I recall) in which case you only need to change it yearly. Since the industry has realized length trumps dumb "complexity" checks, it's a welcome change to see that encoded into policy.

> Sometime in the past few years I saw a new wrinkle: password must be changed every 90 days unless it is above a minimum length (12 or so as best I recall) in which case you only need to change it yearly. Since the industry has realized length trumps dumb "complexity" checks, it's a welcome change to see that encoded into policy.

This is such a bizarre hybrid policy, especially since forced password rotations at fixed intervals are already not recommended for end-user passwords as a security practice.

Post reply on HN