How can I disable a form, server side, to prevent DoS attacks?

General PHP Help
#1

Hi :slight_smile:

I’ve seen this solution which can be done through JavaScript to disable an entire form:

<form>
    <fieldset disabled>
        <input/>
        <input/>
        <input/>
    </fieldset>
</form>

But does this work against a bot, or DoS attacks? i.e. if I throttle login attempts when a user goes beyond the threshold (e.g. 5 invalid passwords attempts in 5 minutes = disable the form from JavaScript for 25 seconds).

I don’t understand how exactly DoS attacks work, but it seems that it can bypass JavaScript so disabling a form won’t do anything beneficial if the DoS script can just carry on what it’s doing.

In that case, how can I disable the form server side? Or, is my approach not the right thing to do?

#2

Two different types of things, not related. What you do with a form is immaterial in a DoS or DDoS attack, they aren’t going through a form.

For a bot, there are a couple ways to deal with them: honey pots, false fields, and javascript submission all have the possibility of thwarting them.

#3

Wait, they aren’t going through a form?

Oh I see… I was under the impression that user attempts coming from the ‘form’ should be throttled…Where does it come from?

I mean… How would a user/script kiddie/whoever does DoS attacks/bots attempt to login (with a correct username, but possibly incorrect password) without going through your login form?

The reason I was put in this direction was cause of these discussions on StackOverflow:

‘Bruteforcing’ and ‘DoS attacks’ - I thought these were done through the login form. Now i’m super confused.

Sorry, if this is too broad of a subject, please send me to a link or book or somewhere I can learn about it (the lack of terminology puts me in a position where I can’t find relevant content on this info…maybe it’s taught in hacking books?)

I’m really not understanding the whole DoS attack things, here I am using PHP/MySql and the Html forms to create a ‘client’, so to say, blockage. But if the attacks don’t come from the login form, that’s a whole new issue…whew!

#4

The first step in dealing with a DOS Attack is to first understand what it is.

https://en.wikipedia.org/wiki/Denial-of-service_attack

#5

:ok_hand: I’ll do that.

#6

I just asked my web-host service about DoS attack protection…and they say that it’s already implemented (part of the web hosting package I bought), to quote their exact words “This is to confirm that your Linux Hosting package comes with DDoS protection by default.”.

Does that mean I don’t have to do anything if my web-host has got it implemented?

#7

Anyone or anything (bot) can make a http(s) request to any of your pages. No one needs your form (other than to see what form fields it has) to make a request to your form processing code. You can and should use a run-once token. This will at least require someone/bot to make a request to your form page each time before making a request to your form processing code.

External data can be anything, can come from anywhere, and cannot be trusted. You must validate all external data before using it. This will filter out requests that don’t have expected data and ones that have unexpected/honey-pot data.

On the subject of brute force attempts being made to the login form processing code, you must detect repeated invalid attempts per account/username per period of time (just record the username, ip, and date/time or timestamp of each failed attempt) and prevent further login attempts if the threshold has been exceeded. What you are doing is limiting the login attempts, not actually locking out the account (some forum software, SMF if I remember, locked out the real already logged in users after a number of invalid login attempts.)

1 Like
Sponsor our Newsletter | Privacy Policy | Terms of Service