[nothis]

Hyper-naive take: Couldn't nearly all of these attacks be blocked by a white-list approach, essentially hiding every file or directory from the internet except a very controlled list of paths and escaping all text sent so it can't contain code?

I somehow always imagine these types of hacks to be more clever, like, I dunno, sending harmless-looking stuff that causes the program receiving it to crash and send some instructions into unprotected parts of RAM or whatever. This all looks like "echo ; /bin/cat /etc/passwd" and somehow the server just spitting it out. Is that really the state of web security?

[quesera]

> Couldn't nearly all of these attacks be blocked by a white-list approach, essentially hiding every file or directory from the internet except a very controlled list of paths and escaping all text sent so it can't contain code?

This is basically how things work.

For convenience, instead of itemizing each filename, the webserver root is a subdirectory and anything underneath is fair game. The webserver uses the OS "chroot" facility to enforce this restriction. What you are seeing is ancient exploitation strings from 30 years ago that haven't worked on any serious webserver since that time, but a) keeping the test in the attackers lib is essentially free, and b) there are some unserious webservers, typically in cheap consumer hardware.

Webservers pass plain text to the app server. It is the app server/framework's responsibility to understand the source of the request body and present it to the application in a clear way, possibly escaped. But the app needs to process this and sometimes through poor coding practices, fails to respect the untrusted nature of the data. This again is more typical in historical systems and low-cost consumer products where software is not a marketing advantage.

[InitialBP]

> ancient exploitation strings from 30 years ago that haven't worked on any serious webserver since that time

Unfortunately, there are plenty of serious (business critical) servers that _ARE_ vulnerable to these types of attacks. I've found and remediated things like this all the time. One very common example I've seen of the `.env` issue is Django servers that are exposed to the internet in with debug=True. There's probably thousands if not tens of thousands of servers leaking credentials this way on the internet now.

Beyond that, companies often have internal systems that do not meet the same security standards that external systems require, and sometimes those systems get shifted around, maybe it's moved to a new subnet, maybe a third-party needs access and the CIDR range gets fat fingered in the firewall. Regardless - now that "internal system" is exposed to the internet with all the dangerous configuration.

[Thorrez]

>This all looks like "echo ; /bin/cat /etc/passwd" and somehow the server just spitting it out. Is that really the state of web security?

It's attempting to exploit a vulnerability in bash that was discovered and fixed in 2014:

https://en.wikipedia.org/wiki/Shellshock_(software_bug)

[dartos]

You’re probably right, but consider that not every person is even aware of the security risks of running servers.

Someone might be trying to play with self hosting or a contractor at a company did a bad job and accidentally exposed stuff they shouldn’t.

This attacker is likely just trolling lots of IPs hoping for low hanging fruit that can be exploited with simple/well known attacks.

[InitialBP]

Bit of a rambly reply:

There are different types of web security vulnerabilities and the attacks you see from automated scanners are likely to be far less sophisticated than targeted web attacks. Specifically these scanners are going to spam out widespread and common CVE's that might grant privileged access to the server or dump credentials in some fashion.

The more sophisticated attack you described is essentially an overflow, and most modern web servers are usually written in memory-safe languages making it very unlikely to see that type of attack on the web. More often it's the underlying OS, servers, or communication stacks (bluetooth, TCP, nginx, etc) that have these types of vulnerabilities since they are often written in low level non memory safe languages like C and C++.

Attacks that exploit the HTTP and HTTPS protocol are a little more interesting. Request smuggling lets you trick certain load balancers and webservers by sending an HTTP request "smuggled" inside of another HTTP request.

Here is a blog by James Kettle's about some request smuggling vulnerabilities and the impact they can have. https://portswigger.net/research/http2

There's really a lifetime's worth of knowledge on web security and the type of stuff you see in scans is just trying to hit the low hanging fruit. Portswigger has loads of free challenges and information about different web security topics.

https://portswigger.net/web-security/all-topics

[Zetobal]

Security through obscurity is like a ninja tiptoeing in a room full of laser beams; make one loud move and you'll reveal that your entire protocol hinges on no one sneezing!

[akerl_]

How is strictly controlling exposed server resources to only URIs you’ve confirmed should be an exposed an example of “security through obscurity”.

[scherlock]

Yup, 99.999% are script kiddies running bots that look for unsecured servers or indicators for known exploits.