1616
authentication and access control model will help prevent such attacks from occurring in the
first place, and it will help the administrator to identify who is committing the abuse. The login
application should be protected against DoS attacks as much as possible. Limiting the database
access, perhaps by caching result sets, can help minimize the resources expended. To further
limit the potential for a DoS attack, consider tracking the rate of requests received from users and
blocking requests that exceed a defined rate threshold.
Phase: Implementation
Strategy = Input Validation
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use
a list of acceptable inputs that strictly conform to specifications. Reject any input that does not
strictly conform to specifications, or transform it into something that does. When performing
input validation, consider all potentially relevant properties, including length, type of input, the
full range of acceptable values, missing or extra inputs, syntax, consistency across related
fields, and conformance to business rules. As an example of business rule logic, "boat" may be
syntactically valid because it only contains alphanumeric characters, but it is not valid if the input
is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for
malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if
the code's environment changes. This can give attackers enough room to bypass the intended
validation. However, denylists can be useful for detecting potential attacks or determining which
inputs are so malformed that they should be rejected outright.
Phase: Architecture and Design
For any security checks that are performed on the client side, ensure that these checks are
duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side
checks by modifying values after the checks have been performed, or by changing the client to
remove the client-side checks entirely. Then, these modified values would be submitted to the
server.
Phase: Architecture and Design
Mitigation of resource exhaustion attacks requires that the target system either: recognizes
the attack and denies that user further access for a given amount of time, typically by using
increasing time delays uniformly throttles all requests in order to make it more difficult to
consume resources more quickly than they can again be freed. The first of these solutions is an
issue in itself though, since it may allow attackers to prevent the use of the system by a particular
valid user. If the attacker impersonates the valid user, they may be able to prevent the user from
accessing the server in question. The second solution can be difficult to effectively institute -- and
even when properly done, it does not provide a full solution. It simply requires more resources on
the part of the attacker.
Phase: Architecture and Design
Ensure that protocols have specific limits of scale placed on them.
Phase: Architecture and Design
Phase: Implementation
If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to
simply let the program fail poorly in cases such as low memory conditions, but an attacker may
be able to assert control before the software has fully exited. Alternately, an uncontrolled failure
could cause cascading problems with other downstream components; for example, the program
could send a signal to a downstream process so the process immediately knows that a problem
has occurred and has a better chance of recovery. Ensure that all failures in resource allocation
place the system into a safe posture.
Phase: Operation
Phase: Architecture and Design
CWE Version 4.14
CWE-770: Allocation of Resources Without Limits or Throttling
CWE-770: Allocation of Resources Without Limits or Throttling