Web Application Hacking · Topic 3 of 8
Footprinting Web Apps, Client-Side Controls and Authentication Attacks
Footprint web infrastructure, analyze an app, see why client-side controls fail, and recognize attacks on login, recovery and authentication.
- 4 min
- Never trust the client. Hidden fields, disabled controls and JavaScript checks can all be bypassed.
- Entry points include parameters, headers, cookies, forms and uploads.
- Username enumeration comes from different error messages or timings.
What it is
The first stages of the web hacking methodology are about learning the target, finding what the browser controls, and then attacking the login.
Footprinting and analysis build a map of servers, technologies and entry points. Client side controls are checks done in the browser, which a user can always change. Authentication attacks target how an application confirms who you are.
How it works
Footprint web infrastructure
| Activity | What it finds |
|---|---|
| Server discovery | Hosts and virtual hosts serving the app, using Whois, DNS and search engines such as Shodan |
| Service discovery | Open ports and services, using Nmap |
| Server identification | Software and version from banners and response headers |
| Hidden content discovery | Unlinked files, admin paths and backups, using spidering and forced browsing tools |
| Web spidering | Following links to build a site map. Burp Suite and ZAP spiders do this |
| Web server vulnerability scanning | Known flaws, using Nikto or Nessus |
| Technology detection | Frameworks and CMS, using tools such as Wappalyzer and WhatWeb |
Forced browsing (directory brute forcing) requests many likely paths to find content not linked from the site. The robots.txt file is useful because paths listed there are ones the owner does not want crawled, which can point to interesting areas.
Analyze web applications
The tester identifies entry points: URL parameters, form fields, cookies, HTTP headers and file uploads. Then the tester identifies server side technologies from file extensions, error messages, session token names and headers, and maps functionality such as login, search, upload and payment. A proxy records all of this as the tester uses the app normally.
Bypass client side controls
Anything the browser enforces can be changed by the user, so it cannot be a security control.
| Control | How it is bypassed |
|---|---|
| Hidden form fields | Changed in the proxy or the page source before sending |
| Disabled form elements | Re-enabled or the value sent directly |
| Client side validation (JavaScript length or format checks) | Skipped by sending the request straight to the server |
| Cookies and URL parameters holding state or price | Edited in transit |
| Browser extensions, Java applets and similar components | Decompiled or intercepted |
The lesson is that every check must be repeated on the server. Client side checks are for convenience only.
Attack authentication mechanism
| Weakness | Description |
|---|---|
| Username enumeration | Different error messages or timing reveal whether a username exists |
| Weak or default passwords | Easy to guess |
| Brute force and dictionary attacks | Many guesses against one account, with tools like Hydra and Burp Intruder |
| Password spraying | One common password tried across many accounts to avoid lockout |
| Credential stuffing | Reusing credentials from other breaches |
| Insecure password recovery | Guessable security questions or reset tokens |
| Insecure "remember me" and cookies | Predictable or unprotected tokens |
| Insecure logout and session handling | Tokens that remain valid |
| Missing multi factor authentication | A single factor protects the account |
| Verbose errors | "Invalid password" versus "no such user" |
Countermeasures include generic error messages, rate limiting and lockout with care, strong password policy, breached password checks, multi factor authentication, secure reset flows with random single use tokens, and monitoring for failed login patterns.
A worked example
A login page says "unknown user" for a wrong name and "wrong password" for a right name. An attacker can list valid usernames. The fix is one message for all failures, such as "invalid credentials", and the same response time for both cases.
How the exam asks about this
- "A price is stored in a hidden form field and the user changes it before submitting. Which control failed?" -> Reliance on a client side control (parameter tampering).
- "One common password is tried against many accounts to avoid lockout. What is it called?" -> Password spraying.
- "Which file can reveal paths the site owner does not want indexed?" -> robots.txt.
What to remember for the exam
- Never trust the client. Hidden fields, disabled controls and JavaScript checks can all be bypassed.
- Entry points include parameters, headers, cookies, forms and uploads.
- Username enumeration comes from different error messages or timings.
- Spraying differs from brute force: many accounts, few passwords.
- Fix: server side validation, generic errors, MFA and rate limiting.
Lockout alone does not stop password spraying, because each account sees very few attempts.
Common mistakes
Trusting JavaScript validation. It runs on the attacker's machine.
Treating robots.txt as protection. It is a request to crawlers and a hint to attackers.
Confusing spraying and credential stuffing. Spraying guesses common passwords. Stuffing reuses leaked pairs.
Check yourself
Why can hidden fields be changed?
They are sent from the browser, which the user controls, and can be edited with a proxy.
Which error design prevents username enumeration?
One generic message and equal response time for every login failure.
What is forced browsing?
Requesting likely paths to find content that is not linked from the site.
Topic 3 of 8 in Web Application Hacking
Test yourself on Web Application Hacking
The full EC-Council 312-50 question bank has 1,000 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by EC-Council. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.