This text outlines security vulnerabilities related to plaintext transmission and brute-force attacks. Plaintext transmission occurs when sensitive data is sent to a server without encryption, allowing attackers to intercept it via man-in-the-middle attacks. Defenses include using HTTPS certificates and asymmetric encryption. Brute-force attacks involve systematically guessing credentials using dictionaries, with considerations for password complexity, CAPTCHAs, login attempt limits, and two-factor authentication. These attacks are categorized into client-side (e.g., Hydra) and browser-based types, including form, CAPTCHA, and token-based attacks. CAPTCHA vulnerabilities include client-side bypasses (insecure JavaScript or exposed codes) and server-side issues (codes not destroyed after use or weak logic). Token-based attacks exploit tokens exposed in source code. Prevention measures include mandatory CAPTCHAs with IP policies (avoiding X-Forwarded-For bypass), single-use CAPTCHAs, complex CAPTCHAs with distortions and interference, and unified CAPTCHA interfaces for large sites.
1. Plaintext Transmission
1.1 Introduction
Plaintext transmission of sensitive data refers to submitting such data to a server over a website without any encryption. This allows an attacker to intercept the unencrypted sensitive data through man-in-the-middle attacks such as hijacking or sniffing.
Once attackers obtain this sensitive data, they can use it to log into the system as a legitimate user — potentially even gaining access to the application backend. Once inside the application system, they can acquire even more sensitive data and uncover additional vulnerabilities.
1.2 Exploitation Methods
Capturing unencrypted data through man-in-the-middle attacks (hijacking, sniffing, etc.)
Directly brute-forcing user credentials via the web login page.
1.3 Defense Methods
Use HTTPS certificates issued by a legitimate CA authority
Adopt asymmetric encryption.
2. Brute Force Attack Considerations
Always have an effective wordlist before cracking begins
Insecure leakage of CAPTCHA in frontend source code
Server-side bypass (on_server) common issues:
CAPTCHA not destroyed after use, allowing long-term reuse. (Note: PHP default sessions expire after 24 minutes.)
CAPTCHA validation is substandard, leading to logic flaws.
CAPTCHA design is too simplistic and predictable, making it easy to crack
Weak CAPTCHA recognition attacks
Token-Based Cracking
Because the token value is output in the frontend source code and can be easily obtained, it loses its effectiveness against brute force attacks. Generally, tokens are more useful for preventing CSRF.
4. Brute Force Attack Prevention
Enforce CAPTCHA entry. Otherwise, implement IP-based policies, but be careful not to be bypassed via X-Forwarded-For.
CAPTCHAs must be single-use only, expiring immediately after use and cannot be reused
CAPTCHAs should not be too weak — use distortion, warping, interference lines, noisy backgrounds, font variations, etc.
Large websites should ideally use a unified security CAPTCHA system, with a single CAPTCHA interface shared across all entry points.
1. Plaintext Transmission
1.1 Introduction
Plaintext transmission of sensitive data refers to submitting such data to a server over a website without any encryption. This allows an attacker to intercept the unencrypted sensitive data through man-in-the-middle attacks such as hijacking or sniffing.
Once attackers obtain this sensitive data, they can use it to log into the system as a legitimate user — potentially even gaining access to the application backend. Once inside the application system, they can acquire even more sensitive data and uncover additional vulnerabilities.
1.2 Exploitation Methods
1.3 Defense Methods
2. Brute Force Attack Considerations
3. Brute Force Attack Categories
3.1 C/S Client-Side
Bruter, Hydra, etc.
3.2 B/S Browser-Side
4. Brute Force Attack Prevention