Preventing bombing

[bit-n...@hotmail.com]

If I have a site where people will log in and make posts, what's to stop someone logging in manually, ie. with the password they've signed up to the site with, and THEN running the bombing script to fill up the database with junk?
I suppose Apache can be configged to prevent too many posts from 1 IP in too little time (is this done by default?), but this is not really a solution.

I would really hate to put Capchas in my site for *each time people wanna post something* - this is really a horrible thing to do to my users. Is there a solution?


Thanks.

[Ben Bacarisse]

I would implement a cryptographically protected timer and serial number
(a UUID works as well). You can use the serial number to reject
repeated submissions of the same form, and the time to reject forms that
are requested and submitted either too fast (because a bot has filled
them in) or too slowly (a bot has cached the form a queued the
submission).

If you are only interested preventing scripts that just send the form
data again and again, you need only the serial number. Of course you
need to store it, but if your users' posts are being stored in a
database, it's very simple to check if a post with the number has been
seen so before.

To defeat the very simplest scripts, you don't even need the
cryptographic check, but it's simple to implement so I'd do it anyway.
Whatever check data you send out with the form, append some random data
to it and hash it with a key know only to the server. That way you can
reject any submission where the script has guessed that the serial
number must be changed or the time code is important.

The timer part can be made minimally intrusive to the user. If they
submit the form really quickly, or they take too long, just re-send it
along with a time code that will be accepted right away and tell them to
click again.

--
Ben.

[Gordon Burditt]

> If I have a site where people will log in and make posts, what's
> to stop someone logging in manually, ie. with the password they've
> signed up to the site with, and THEN running the bombing script to
> fill up the database with junk?

> I suppose Apache can be configged to prevent too many posts from
> 1 IP in too little time (is this done by default?), but this is not
> really a solution.

Such a feature could be very annoying to a user trying to *READ* a
hundred messages a minute looking for something specific. It isn't
so easy for Apache to *automatically* tell the difference betweeen
"Post a message" and "Display next page of this message", especially
if the messages are kept in a database, not as static links. Your
custom code can do this easily.

And you really need to enforce at least some of the limits on a
per-user, not per-IP, basis. It should be pretty easy for you to
use a database query to count previous messages from user X within
time period Y. You probably want to hold in reserve the ability
to ban particular IPs from accessing your site *AT ALL* - there are
some bad guys who bring a site to its knees just repeatedly requesting
pages at a thousand times a second from many hosts (and they don't
necessarily even try to log in or post).

> I would really hate to put Capchas in my site for *each time
> people wanna post something* - this is really a horrible thing to
> do to my users. Is there a solution?

Capchas are a good idea to create new accounts. Each user has to
do it only once (and you can "grandfather" existing users with
accounts so they don't have to do it at all) unless they are
constantly creating throwaway accounts.

If someone misbehaves, manually ban the account. You have to resort
to this as not everyone uses bombing scripts - sometimes they just
use bad words, insult other users, and post a small amount of
advertising, solicit sexual favors, or insisting on campaigning for
Hillary Clinton in a group dedicated to Major League Baseball games.
Have handy a "delete all posts from this user" function an administrator
can use to clean up the mess.

If people log in on accounts they have created, you can limit the
number of posts made in a certain time *by user name*, and turn off
the account if it's excessive. I think 20 posts in 20 minutes is
approaching excessive. Also, repeatedly posting messages with
nearly-identical content is at least suspicious.

Capchas are also something you can activate in the case where a
user is doing something suspicious but you can't say it's abusive
yet. For example, if they post more than 20 posts in 20 minutes,
require capchas for the next hour.

Require some personal information to create an account (such as an
email address or a phone number). Verify these, say by sending a
link to the email address and requiring the user to click on it to
activate the account to allow posting, or texting a security code
to the phone number, which they need to enter to activate the
account. Do not permit more than one account (banned or not) on
the same email address or on the same phone number. That means
they keep having to come up with more throwaway email addresses or
phone numbers, and will at least slow them down a little.

(Warning: this approach may create some problems if there are any
husband/wife or parent/child pairs still left who share the same
phone number and/or email address. You may have to tell them that
if they share the phone, they have to share the account also.)

*NEW* users can have stricter posting limits than more established
ones. You might require manual approval (by you) of each post for
users whose accounts are less than 48 hours old, or manual approval
of the first 3 posts regardless of account age. You might also
only turn on automatic approval after they have posted a few times
with *information useful to the other users*, such as answering
other user's questions or contributing news on a topic, not just
asking questions. (This is a much stricter rule than "non-offensive").
Some sites have "reputation points" or "karma" which get users
additional privileges as they do more positive things on the site.

Let your users help you. Allow them to flag posts as offensive or
pointless. You probably have to review these manually, and some
of them will flag any post critical of them, but if users abuse the
"flag post" button, you can turn it off for that user or ban the
user.

Yes, a lot of this requires actual work from an administrator,
and not just in writing code.

[J.O. Aho]

On 09/06/2016 08:28 AM, bit-n...@hotmail.com wrote:
> If I have a site where people will log in and make posts, what's to stop someone logging in manually, ie. with the password they've signed up to the site with, and THEN running the bombing script to fill up the database with junk?
> I suppose Apache can be configged to prevent too many posts from 1 IP in too little time (is this done by default?), but this is not really a solution.

Apache do not have a magic ball, so it will not be able to limit
anything regarding post, it can throttle the connection speed, but that
ain't the same thing as limiting number of posts requests.

> I would really hate to put Capchas in my site for *each time people wanna post something* - this is really a horrible thing to do to my users. Is there a solution?

You can try to limit the miss use by using a guid which is generated
when the page is loaded, and when the page is posted, compare the guid
with what you have stored on the server side, it they match, process the
page, if they do not match, then ignore the post.

Keep in mind that you can still make automation which can load the post
page, take the guid and use it in the post.


--

//Aho

[bit-n...@hotmail.com]

OK, I'll read all you guys' posts a bit later, but... I was just wondering - *which* are the Linux tools which actually DO this type of bombing? I only have a vague idea about em, is it WGET or CURL, or does even netcat do this type of thing? i.e. which is the one which can be programmed to *send the "logged in" cookie* from the client side? Or is a little BASH script or something required to read the cookie from the HD (and how? - Firefox stores em in a SQLite database, how do you read em?), and THEN send it over HTTP? i.e. the script would have to implement a bit of the HTTP protocol - netcat is just a TCP/IP tool, isn't it?

[R.Wieser]

bit-naughty,

> I only have a vague idea about em, is it WGET or CURL, or does
> even netcat do this type of thing? i.e. which is the one which can be
> programmed to *send the "logged in" cookie* from the client side?

*Any* program which can do text-mode HTTP(S) requests and receive the (also
text-mode) responses can be used for it. In other words, all of the above
and than some. :-) :-(

> Or is a little BASH script or something required to read the
> cookie from the HD

Not needed at all. A cookie is present in the HTTP headers (that you
normally do not see, but are very visible when you are in text-mode) of the
page you requested, and you can simply copy that entry into the headers of
the next HTTP request.

> i.e. the script would have to implement a bit of the HTTP protocol

Yes, it would need to. But as the HTTP protocol (for what you are looking
at) is rather simple (and human-readable!) thats not all that difficult.

In other words, almost anyone can throw scripted requests at your website.

Also, PHP (which is written to handle *and send* HTTP requests).

Regards,
Rudy Wieser


-- Origional message:
<bit-n...@hotmail.com> schreef in berichtnieuws
fc41cf97-c80e-46d1...@googlegroups.com...