←back to thread

Writing "/etc/hosts" breaks the Substack editor

(scalewithlee.substack.com)
601 points scalewithlee | 1 comments | 25 Apr 25 13:48 UTC | HN request time: 0.212s | source
Show context
godelski ◴[25 Apr 25 17:32 UTC] No.43796384[source]▶
I don't get it. Why aren't those files just protected so they have no read or write permissions? Isn't this like the standard way to do things? Put the blog in a private user space with minimal permissions.

Why would random text be parsed? I read the article but this doesn't make sense to me. They suggested directory transversal but your text shouldn't have anything to do with that and transversal is solved by permission settings

replies(1): >>43797072 #
tryauuum ◴[25 Apr 25 18:33 UTC] No.43797072[source]▶
this is the usual approach with web application firewalls, block all the 100500 known attacks. Doesn't matter if they are not applicable to your website. Some of them are obviously OS-depended (having .exe in the URLs) but it doesn't matter, it's blocked just in case

I do understand this appoach. From the defence point of view it makes sense, if you have to create a solution to protect millions of websites it doesn't make sense to tailor it to specifics of a single one

replies(2): >>43797768 #>>43798473 #
1. julik ◴[25 Apr 25 21:01 UTC] No.43798473[source]▶
I haven't been in the business of writing WAFs, but if I got an assignment of "block every string in the request body that contains /etc/passwd or /etc/hosts, including filenames in multipart forms" – I would strongly debate that with the PMs requesting that. And - probably - debate for some kind of "This website is served by an application developed by people who know what they are doing" checkbox, which would instantly neuter rules like that.