Almost every public website on the open Internet receives thousands of HTTP requests similar to the ones mentioned in this text file. This is one of the several reasons why web application firewalls gained popularity years ago, especially as vulnerability scanners became widespread.
Years ago, when I was employed at a young security startup, my colleague and I dedicated countless hours analyzing this particular kind of web traffic. Our objective was to develop basic filters for what eventually evolved into an extensive database of malicious signatures. This marked the inception of what is now recognized as one of the most widely used firewalls in the market today.
We use one of them for ISO certification. Twice a year, we turn on their "vulnerability scanner", which says its test over x-thousand vulnerabilities, we get a report, and everybody is happy. Only on the first run did it discover a small error in the nginx config. Unfortunately, it is theater.
Do these injection attacks come from a single source perhaps, which everyone imitated?
When you run a search engine you will see queries that try to look through every page of results for the search query 'input type="text"' typically this will either come from an API query or to a search page that is fronting another index.
Mostly they came from Israeli Chinese and Russian IP addresses.
Relatedly if you work in a field where your products become known as a useful benchmark you will find prototypes start showing up long before any public disclosure. We used to use this to be able to anticipate new screen resolutions and evaluate new GPUs and SoCs before being told about them.
The internet is a jungle with dragons. Nowadays I try to keep everything on my vpn as an extra security layer.
The filter system is open source https://github.com/kristopolous/BOOTSTRA.386/blob/master/hom...
Showing it's not impossible to have a classic anonymous guestbook, you just have to be a bit clever.
Yes, that's a zipbomb to a particular offender at the beginning. It worked. A script dumb enough to brainlessly slam the site easily broke against a zipbomb.
Seems to be what makes the vast majority of the spam bots faceplant, at least the ones that spam random irrelevant sites like this one.
As a bonus, your apparently vulnerable service would be incredibly slow, so any iterative testing would be incredibly slow.
You come to a fork in the road. There are three statues, you need to ask them all one question and figure out which way is the right way to go.
One statue always lies, one always tells the truth and one kills people who ask convoluted questions.
https://github.com/andresriancho/w3af/blob/fb345a5/w3af/core...
This one sends the payload reversed as a test to see if the delay is due to the SQLi attempt
For heavier use cases (e.g. image processing), the user should be willing to spend some CPU power. It doesn't make sense to send an image to a server, put it in a queue, wait for an image processing worker to run it, and send back the result. It's simpler and more sensible to run that process client-side, if feasible. E.g. LLMs are too big for that, but many other tasks can.
(Granted, it's probably still too much overhead, just a thought.)
Even the mobile oriented samey SAAS sites that have you scroll through 20 screens to read 5 lines sound better...
Edit: Btw, 100-500 ms on what? The latest Intel 500 W space heater? And tested only in Chrome because it's too expensive to notice that it's not very fast or responsive on other browsers?
Edit 2: Not to be misunderstood. If you're doing the computation for me, go ahead. If you're doing the computation because your framework has 100000% overhead, no thanks.
All browsers are approximately equally fast nowadays. I use Firefox, so no worries there.