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

251–260 of 370 posts

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

#251

Post by gopher_space »

immibis wrote: post #166
krferriter wrote: post #76

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…

If your clients will let you pass the buck on security like this it would be very tempting to work towards the least onerous insurance metric and no further.

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

#252

Post by michaelt »

9x39 wrote: post #188
kiitos wrote: 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.

Then the users start using cloud webapps to do everything. I can't install a PDF-to-excel converter, so I'll use this online service to do it.

At first glance that might seem a poor move for corporate information security. But crucially, the security of cloud webapps is not the windows sysadmins' problem - buck successfully passed.

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

#254

Post by bigfatkitten »

9x39 wrote: post #188
kiitos wrote: 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.

That's why this it's been a requirement for Australian government agencies for about 15 years.

In around 2011, the Defence Signals Directorate (now the Australian Signals Directorate) went through and did an analysis of all of the intrusions they had assisted with over the previous few years. It turned out that app whitelisting, patching OS vulns, patching client applications (Office, Adobe Reader, browsers), and some basis permission management would have prevented something like 90% of them.

The "Top 4" was later expanded to the Essential Eight which includes additional elements such as backups, MFA, disabling Office macros and using hardened application configs.

https://www.cyber.gov.au/resources-business-and-government/e...

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

#255

Post by bigfatkitten »

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.

You would probably have no idea what the requirement actually said or where it ultimately came from.

It would've gone from the insurer to the legal team, to the GRC team, to the enterprise security team, to the IT engineering team, to the IT support team, and then to the user.

Steps #1 to #4 can (and do) introduce their own requirements, or interpret other requirements in novel ways, and you'd be #5 in the chain.

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

#256

Post by bigbuppo »

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.

The fun part is that they don't demand anything, they just send you a worksheet that you fill out and presumably it impacts your rates. You just assume that whatever they ask about is what they want. Some of what they suggest is reasonable, like having backups that aren't stored on storage directly coupled to your main environment.

The worst part about cyber insurance, though, is that as soon as you declare an incident, your computers and cloud accounts now belong to the insurance company until they have their chosen people rummage through everything. Your restoration process is now going to run on their schedule. In other words, the reason the recovery from a crypto-locker attack takes three weeks is because of cyber insurance. And to be fair, they should only have to pay out once for a single incident, so their designated experts get to be careful and meticulous.

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

#257

Post by butshouldyou »

manwe150 wrote: post #143
cratermoon wrote: post #135

Earlier quoted context omitted.

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.

I think I like this idea that the rotation interval could be made proportional to length, for example doubling the interval with each additional character. Security standards already now acknowledge that forced yearly rotation is a net decrease in security, so this would incentivize users to pick the longest password for which they would tolerate the rotation interval. Is yearly rotation too annoying for you? For mer…

Unfortunately, lots of end users refuse to read the password policy and won't understand why their password reset interval is "random" or shorter than their colleague's.

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

#259

Post by II2II »

mjr00 wrote: post #65
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…

> 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…

> 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 the face that it's bad practice, NIST changed its policy to recommend not regularly rotating passwords over a decade ago, etc., and be totally correct... but they're still going to jack up premiums if you don't do it.

I would argue that password policies are very context dependent. As much as I detest changing my password every 90 days, I've worked in places where the culture encouraged password sharing. That sharing creates a whole slew of problems. On top of that, removing the requirement to change passwords every 90 days would encourage very few people to select secure passwords, mostly because they prefer convenience and do not understand the risks.

If you are dealing with an externally facing service where people are willing to choose secure passwords and unwilling to share them, I would agree that regularly changing passwords creates more problems than it solves.

Post reply on HN