←back to thread

Writing "/etc/hosts" breaks the Substack editor

(scalewithlee.substack.com)
600 points scalewithlee | 2 comments | 25 Apr 25 13:48 UTC | HN request time: 0.599s | source
Show context
Y_Y ◴[25 Apr 25 14:13 UTC] No.43793778[source]▶
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.
replies(6): >>43793862 #>>43793868 #>>43793954 #>>43794072 #>>43794473 #>>43802345 #
mystifyingpoi ◴[25 Apr 25 14:20 UTC] No.43793862[source]▶
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.
replies(7): >>43793876 #>>43793969 #>>43794144 #>>43794428 #>>43795337 #>>43796158 #>>43796295 #
1. wavemode ◴[25 Apr 25 17:25 UTC] No.43796295[source]▶
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.

replies(1): >>43797432 #
2. serial_dev ◴[25 Apr 25 19:06 UTC] No.43797432[source]▶
Net zero for security might be generous.

The way I assume it works in practice on a real team is that after some time, most of your team will have no idea how the WAF works and what it protects against, where and how it is configured… but they know it exists, so they will no longer pay attention to security because “we have a tool for that”, especially when they should have finished that feature a week ago…