This piece of shit site is a snitch site to enable fascists to harass drag queens, any children attending these events GNC people in general, and any parents who would dare attend an event which encourage their child to read.
It needs spam. And it needs it now.
It depends on whether or not they log IPs with the form submissions. If they're competent they would, but the Epik leak seemed to show that generally, right wingers are not. If they do log IPs they will easily discard everything you sent when they notice thousands of fake submissions from one IP, but if not you could move on to automating a process for sending several of each of multiple fake events.
Ah, but even if they log the ip where are they getting that information from? IIRC theres a header that has the sender's ip address which you can just fill with guff, good luck on getting a response back but methinks that might not be nessecary. I'm just spitballing tbh
HTTP is built on top of the TCP protocol. Delivery of every packet is acknowledged with an ACK response, and if this doesn't happen the connection is dropped. It not like a letter where you could write a fake return address. You could use a proxy, but the server needs to send a response somewhere. This all needs to happen before a connection is even "opened," before any data can be transmitted through it.
Can you do the slow loris thing on this site? Or is that all patched out now?
I'm assuming not, since cloudfare has a nice fancy writeup about it.
Goodpoint, I'm UDP brained clearly. Can you get away with changing the ip header part way through the connection? I imagine not cause it would trip balls
Not really. Once the socket is open, it going to be associated with an IP address somewhere in the OS's network stack. None of this happens at the application layer (and 'applications' like Apache/Nginx are among the most hardened things out there, for what its worth). I think this is the wrong approach.
If there is any hope, it is looking for some mistake in the server configuration. Maybe they have a shitty firewall set up and you can connect to a database or the PHP-FPM module from outside. Maybe they have extra, unneeded services running on the server which expose additional attack surface. Maybe they used a dictionary word as their SSH password. All of this would require not only gross negligence, but self-defeating intervention on their behalf though (default settings tend to be secure. You have to go out of your way, read a bunch of tutorials, and do the opposite of what they say to open up holes like this).
Things might get easier if they are running some large, convoluted web application like Drupal or Wordpress. I can't tell you how many bots would show up in my HTTP access log checking to see if Wordpress was installed. This also takes time though. Usually the weaknesses develop from them setting everything up once, then never updating it.
This is all hypothetical though. Don't get arrested.
In my experience PHP is rarely safe lmao but like you say this is hypothetical
I doubt most webservers would do anything but drop a packet with that removed by default unless explicitly set to allow it.
Yeah but you just put a random ip address in there, no point in having a bot net when you don't need distributed computing right?