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
Can you help me understand the exploit here? I'd really like to understand.
(What's below is written not as "this is how it should be done" but instead "what I understand should be done". To provide context to what I do and do not understand so that my misunderstandings can be more directly addressed)
I understand being over zealous, an abundance of caution. But what I'm confused about is why normal text could lead to an exploit in the first place. I can only understand this being a problem if arbitrary text is being executed. Which that would appear to be a HUGE security hole ripe for exploitation. But path access is handled by privileges. So even if arbitrary text is being executed, how can that lead to exploitation without already having a major security hole?
Maybe I'm not understanding substack? I've only been a reader. But why is the writer not in a container or chroot? If you want you be overly zealous why not use two vms? Put them in a vm to write, once they've edited then run tests and then use that as the image for the userspace in the ephemeral vm that is viewed by readers. Would this still be exploitable? I don't mean image for the whole vm, I really do mean a subimage so you can lock that up.
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 problem, and might need to actually use the gate but the vendor/security team has successfully solved their problem of checking off a blocked attack, and the consequences are now your problem
> directory transversal attack
I asked why setting permissions was not a sufficient solution. Is someone gaining root? How?
I understand there's the user visiting substack and the person editing on substack. Certainly this is about the person editing. This is why I asked about the containerization side. That's an extra layer in permissions. Not only should that editor not have permissions to edit `/etc/passwd` (or some other file), but they wouldn't be able to do so even if gaining root. They'd need to gain root, break out of the container, and gain root again (hopefully that container is being run as a user and not root!).
But even there, I'm still confused about the exploits. How is a transversal even happening? Why is text even being executed? I understand we're sending POST requests but why is that POST request able to do anything other than input string literals into a text body? Isn't this a prepared statement? Why does that POST request have permission to access those files in the first place? Like even if a malicious editor circumvented defenses and was able to write injections, accessing those files shouldn't be possible from permissions, right?
My understanding is that for this solution to be effective then several other critical security flaws have to also have happened. And how far does this thing need to go? Isn't it defeatable if I chop up the keywords into benign ones, store as variables, and then expand them? I guess it stops very low hanging fruit attackers but again, isn't that also only in the situations where there are also low hanging fruit attacks available which can cause far more damage? That's where my confusion is coming from.
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.
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.
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