Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing "/etc/hosts" breaks the Substack editor

scalewithlee.substack.com

Post reply on HN
Print view View original

301–310 of 370 posts

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

#301

Post by resonious »

decasia wrote: post #283
derektank wrote: post #134

Earlier quoted context omitted.

IT doesn't always hear the grumbles, hidden away as they frequently are behind a ticketing system; the help desk technicians who do hear the grumbles aren't always informed of the "why" behind certain policies, and don't have the time or inclination to go look them up if they're even documented; and it's a very unsatisfying answer even if one receives a detailed explanation. Information loss is an inherent property o…

> Information loss is an inherent property of large organizations. That's such an interesting axiom, I'm curious if you would want to say more about it? It feels right intuitively - complexity doesn't travel easily across contexts and reaching a common understanding is harder the more people you're talking to.

On a more micro level, I find it very hard to write good documentation. I always forget something that once pointed out seems obvious. Or worse, the reader is missing some important context that many other readers are already privy to. Not to mention, some people don't even seek out docs before acting.

I imagine this gets amplified in a large org. The docs are lacking, people might not read them anyway, and you get an explosion of people who don't understand very much but still have a job to do.

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

#302

Post by vintermann »

That reminds me of issues I once had with Microsoft's boneheaded WAF. We had base64 encoded data in a cookie, and whenever certain particular characters were produced next to each other in the data - I think the most common was "--" - the WAF would tilt and stop the "attempted SQL injection attack". So every so often someone would get an illegal login cookie and just get locked out of the system until they deleted it or it expired. Took a while to find out what went wrong, and even longer to figure out how to remove the more boneheaded rules from the WAF.

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

#303

Post by [deleted] »

paxys wrote: post #61
matt_heimer wrote: post #36

The people configuring WAF rules at CDNs tend to do a poor job understanding sites and services that discuss technical content. It's not just Cloudflare, Akamai has the same problem. If your site discusses databases then turning on the default SQL injection attack prevention rules will break your site. And there is another ruleset for file inclusion where things like /etc/hosts and /etc/passwd get blocked. I disagree…

"You never know..." is the worst form of security, and makes systems less secure overall. Passwords must be changed every month, just to be safe. They must be 20 alphanumeric characters (with 5 symbols of course), just to be safe. We must pass every 3-letter compliance standard with hundreds of pages of checklists for each. The server must have WAF enabled, because one of the checklists says so. Ask the CIO what actu…

[deleted]

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

#304

Post by hnlmorg »

zelphirkalt wrote: post #287
hnlmorg wrote: post #141

Earlier quoted context omitted.

I’m going through exactly this joy with a client right now. “We need SQL injection rules in the WAF” “But we don’t have an SQL database” “But we need to protect against the possibility of partnering with another company that needs to use the same datasets and wants to import them into a SQL database” In fairness, these people are just trying to do their job too. They get told by NIST (et al) and Cloud service provide…

If they want to do their job well, how about adding some thinking into the mix, for good measure? Good would also be,if they actually knew what they are talking about, before trying to tell the engineers what to do.

> If they want to do their job well, how about adding some thinking into the mix, for good measure?

That’s what the conversation I shared is demonstrating ;)

> Good would also be,if they actually knew what they are talking about, before trying to tell the engineers what to do.

Often the people enduring the rules aren’t supposed to be security specialists. Because you’ll have your SMEs (subject matter experts) and your stockholders. The stakeholders will typically be project managers or senior management (for example) who have different skill sets and priorities to the SMEs.

The problem is that when it comes to security, it’s a complicated field where caution is better than lack of caution. So if a particular project does call on following enhanced secret practices, it becomes a ripe field for snake oil salesman.

Or to put it another way: no company would get sued for following security theatre but they are held accountable if there is a breach due to not following security best practices.

So often it doesn’t matter how logical and sensible the counter argument is, it’s automatically a losing argument

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

#305

Post by vintermann »

noisem4ker wrote: post #199
swyx wrote: post #183

Earlier quoted context omitted.

i think GP's point is how would you even sanitize the string "OutOfMemoryException" which presumably comes from a trusted system i guess demanding "Structured logs for everything or bust" is the answer? (i'm not a big o11y guy so pardon me if this is obvious)

"o11y" stands for "observability". Numeronyms are evil and we should stop using them.

t4s, couldn't agree more.

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

#306

Post by Dylan16807 »

godelski wrote: post #284
Macha wrote: post #278

Earlier quoted context omitted.

Misconfiguring your web server such that example.com/../../etc/passwd returned the actual file was a common vulnerability in the early 00s. Or cgi scripts that worked with real file paths but accepted any path WAFs blocking the string with the filename then is the "to make sure nobody ever accidentally leaves your gate open, we've replaced it with a concrete wall" solution to this problem. You might never have this p…

> directory transversal attack There's some serious miscommunication going on. I'm quite willing to believe it is from my end, but I thought I explained earlier that I'm well aware of directory transversal. The example did not clarify things to me when the author mentioned it I asked why setting permissions was not a sufficient solution. Is someone gaining root? How? I understand there's the user visiting substack an…

There is no exploit... for this specific site.

But the WAF rule is not site-specific.

Almost all of your comment is asking site-specific questions, but that's barking up the wrong tree. The WAF is working under a completely different paradigm.

It especially doesn't know about specific user rules within a specific site! Or file permissions. None of those are in scope for the WAF. The WAF is trying to protect a million sites at once.

> Isn't it defeatable if I chop up the keywords into benign ones, store as variables, and then expand them?

That might work half the time, but not the other half. The filter isn't pointless, it's just being badly and annoyingly applied.

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

#307

Post by immibis »

0xbadcafebee wrote: post #229
immibis wrote: post #180

Earlier quoted context omitted.

They're being downvoted because they're saying the author is incorrect when the author is actually correct.

It's frightening that so many people are convinced the author is correct, when the author never proved they were correct. The author just collected a bunch of correlations and then decided what the cause was. I've been doing this kind of work for many, many years. Just because it looks like it's caused by one thing, doesn't mean it is . Correlation is not causation. That's not just a pithy quip, there's a reason why…

It's more like I saw a big ball fall down and make a hole in the floor and concluded it must be heavy.

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

#308

Post by immibis »

jimmaswell wrote: post #271
connicpu wrote: post #178

Earlier quoted context omitted.

Can confirm when I found out I'd be required to regularly change my password the security of it went down significantly. At my current job when I was a new employee I generated a secure random password and spent a week memorizing it. 6 months later when I found out I was required to change it, I reverted to a variation of the password I used to use for everything years ago with some extra characters at the end that I…

I do the same but write the number at the end of the password on the laptop in sharpie. I work from home so I've been thinking about making a usb stick that simulates a keyboard with a button to enter the password.

Dangerous. You might accidentally press the button in a group chat.

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

#309

Post by immibis »

swyx wrote: post #240
j1elo wrote: post #238

Earlier quoted context omitted.

Thanks. My mind started running the random string generator given those restrictions, like a puzzle game. But had no idea of what it meant until you wrote it. Who invented that stupid idea and thought it would be a good one?

because its easily googlable. counter point - people are going to use them, better to expose newbies early and often and then everyone is better off shorthands will always be in demand. we used to say “horseless carriage”, then “automobile”, then “car”. would you rather use Light amplification by stimulated emission of radiation or just “laser”s? etc in the new york times? sure, spell out observability. but on HN? co…

no we drive to work in our h16e to set up the l47n

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

#310

Post by immibis »

zelphirkalt wrote: post #287
hnlmorg wrote: post #141

Earlier quoted context omitted.

I’m going through exactly this joy with a client right now. “We need SQL injection rules in the WAF” “But we don’t have an SQL database” “But we need to protect against the possibility of partnering with another company that needs to use the same datasets and wants to import them into a SQL database” In fairness, these people are just trying to do their job too. They get told by NIST (et al) and Cloud service provide…

If they want to do their job well, how about adding some thinking into the mix, for good measure? Good would also be,if they actually knew what they are talking about, before trying to tell the engineers what to do.

They don't want to do their job well. They want to look like they're doing their job well, to people who don't know how to do the job and whose metrics are completely divorced from actual merit.
Post reply on HN