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

151–160 of 370 posts

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

#151

Post by SonOfLilit »

0xbadcafebee wrote: post #23

Worth noting that people here are assuming that the author's assumption is correct, that his writing /etc/hosts is causing the 403, and that this is either a consequence of security filtering, or that this combination of characters at all that's causing the failure. The only evidence he has, is he gets back a 403 forbidden to an API request when he writes certain content. There's a thousand different things that coul…

You're being downvoted because WAFs work exactly like this, and it's intentional and their vendors think this is a good thing. A WAF vendor would say that a WAF parsing JSON makes it weaker.

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

#153

Post by foobarchu »

Wowfunhappy wrote: post #72
mjr00 wrote: post #65

Earlier quoted context omitted.

> I disagree with other posts here, it is partially a balance between security and usability. And economics. Many people here are blaming incompetent security teams and app developers, but a lot of seemingly dumb security policies are due to insurers. If an insurer says "we're going to jack up premiums by 20% unless you force employees to change their password once every 90 days", you can argue till you're blue in th…

Maybe it wouldn't make a difference, but if I was the IT person telling users they have to change their passwords every 90 days, I would 100% include a line in the email blaming the insurance company.

I'm not in an IT dept (developer instead), but I'd bet money that would get you a thorough dressing down by an executive involved with the insurance. That sort of blaming goes over well with those at the bottom of the hierarchy, and poorly with those at the top.

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

#154

Post by Macha »

mystifyingpoi wrote: post #12
Y_Y wrote: 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.

No one expects any WAF to be a 100% solution that catches all exfiltration attempts ever, and it should not be treated this way. But having it is generally better than not having it.

> But having it is generally better than not having it.

The problem is that generally you're breaking actual valid use cases as the tradeoff to being another layer of defense against hypothetical vulnerabilities.

Yes, discussing the hosts file is a valid use case.

Yes putting angle brackets in the title of your message is valid use case your users are going to want.

Yes putting "mismatched" single quotes inside double quotes is a thing users will do.

Yes your users are going to use backslashes and omit spaces in a way that looks like attempts at escaping characters.

(All real problems I've seen caused by overzealous security products)

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

#155

Post by Macha »

wat10000 wrote: post #137
p_ing wrote: post #99

Earlier quoted context omitted.

Locks are a speedbump for a lockpick. Doors are a speedbump for a car. Well yeah, sure, doesn't mean I'm going to have an open doorframe or a door without a lock.

The difference is that a door tends to be the only thing between you and an attacker. A speedbump is better than nothing. This isn't like having a lock on your door, this is like having a cheap, easily pickable padlock on your bank vault. If the vault has a proper lock then the padlock serves no purpose, and if it doesn't then you're screwed regardless.

And to extend the metaphor to cover the false positives these systems produce, sometimes the padlock seizes shut if the air temperature is in a certain range, and the team that put it there refuses to take responsibility for the fact they've locked your customers from accessing their assets with the valid key.

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

#156

Post by tmpz22 »

betaby wrote: post #100
mjr00 wrote: post #65

Earlier quoted context omitted.

> I disagree with other posts here, it is partially a balance between security and usability. And economics. Many people here are blaming incompetent security teams and app developers, but a lot of seemingly dumb security policies are due to insurers. If an insurer says "we're going to jack up premiums by 20% unless you force employees to change their password once every 90 days", you can argue till you're blue in th…

> but a lot of seemingly dumb security policies are due to insurers. I keep hearing that often on HN, however I've personally never seen seen such demands from insurers. I would greatly appreciate if one share such insurance policy. Insurance policies are not trade secrets and OK to be public. I can google plenty of commercial cars insurance policies for example.

This is such an important comment.

Fear of a prospective expectation, compliance, requirement, etc., even when that requirement does not actually exist is so prevalent in the personality types of software developers.

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

#157

Post by owebmaster »

ycombinatrix wrote: post #150
PhilipRoman wrote: post #124

Earlier quoted context omitted.

Careless analysis of free-form text logs is an underrated way to exploit systems. It's scary how much software blindly logs data without out of band escaping or sanitizing.

Why would someone "sanitize" OutOfMemoryException out of their logs? That is a silly point to make.

An OutOfMemoryException log should not be the same as a search log

  Error: OutOfMemoryException
And

  Search: OutOfMemoryException
Should not be related in any way

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

#158

Post by tmpz22 »

alabastervlog wrote: post #122
reaperducer wrote: post #77

Earlier quoted context omitted.

the CIO is securing his job. Every CIO I have worked for (where n=3) has gotten where they are because they're a good manager, even though they have near-zero current technical knowledge. The fetishizing of "business," in part through MBAs, has been detrimental to actually getting things done. A century ago, if someone asked you what you do and you replied, "I'm a businessman. I have a degree in business," you'd get…

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!

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

#159

Post by wavemode »

mystifyingpoi wrote: post #12
Y_Y wrote: 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.

No one expects any WAF to be a 100% solution that catches all exfiltration attempts ever, and it should not be treated this way. But having it is generally better than not having it.

No, that logic doesn't follow. If your application is so hopelessly vulnerable as to benefit from such naive filtering of the text "/etc/hosts, then your application is still going to be vulnerable in precisely the same ways, with just slightly modified inputs.

It is net zero for security and net negative for user experience, so having it is worse than not having it.

Post reply on HN