Page 208 - Hands-On Bug Hunting for Penetration Testers

Other (Out of Scope) Vulnerabilities Chapter 12

Brute Forcing Authentication Systems

If an authentication system (a GUI form, an API request, or any other implementation or
layer) doesn't lock a user out after a certain number of failed login attempts, it leaves itself
open to being brute forced, with an attacker trying every possible combination of
credentials until he/she is successful. Locking a user out after X failed attempts is a common
security best practice, but missing that feature doesn't immediately make an application
insecure. The amount of resources involved in brute forcing and the high level of noise it
would make to any observing system engineer, means that, by itself, brute-force-ability isn't
a compelling enough foundation for a severe attack scenario. Additionally, testing the
efficacy of a brute force attack means making a brute force attack, which can deal serious
damage to the target company's infrastructure and computing resources.

CSRF Logout

Traditionally considered to be a security non-issue (and still not rewarded by many bounty
programs), the ability for a cross-site request to forcefully log a user out is being
reevaluated as a possible security threat by organizations like Detectify Labs, who have
published a couple of different attack scenarios outlining when logout functionality being
susceptible to CSRF is a problem (check the Further reading section for the link). Despite the
constant reevaluation of the bug, it still often requires several extra steps to become a true
vulnerability with a credible attack scenario, and is therefore not a priority for bug bounty
programs.

Anonymous Form CSRF

Another common CSRF-related vulnerability that doesn't often receive a payout is an
anonymous form (for example, Contact Us) that is susceptible to CSRF. If an anonymous
form is susceptible to CSRF, it means that an attacker could trick the victim into submitting
it with different or modified fields.
Taking the contact form as our example, this bug doesn't merit a payout because there's no
relevant attack scenario that we can derive from it. Even if we submit the form with a
different email address or message, it's not clear what damage that would do. For more
mission-critical forms (filling out payment information, changing account settings, or
authentication methods), we can come up with some bone-chilling scenarios, but if a form
is anonymous, that usually means it's expected to receive a bunch of spam, and is isolated
from important functions accordingly.

[ 193 ]