Ravindra BagaleCourses & study guides मराठी Track your progress

21. Web Application Testing Tools

Chala mitrano, aaj internet cha saglyat motha hallya-cha area – web applications. Tumhi Chapter 9 te 16 madhe swatah PHP website, LAMP/LEMP aani reels app banavla. Aata tya hi najrene baghuya jashi ek attacker baghto: form madhe kay taklyavar kay hote, URL badalla tar kay hote, hidden pages kuthe aahet. Ha chapter tools cha aahe – Burp Suite, ZAP, Gobuster, sqlmap, WPScan. Pratyek tool fakt DVWA, Juice Shop kiwa tumchya swatahchya reels app var. Baherchya konatyahi site var nahi – to gunha aahe. Samjla ka? Chala!

What you will learn in this chapter

  • How web traffic works and why a proxy is the tester's main tool
  • Burp Suite: proxy, intercept, repeater and intruder (community edition)
  • OWASP ZAP: a free alternative with automated scanning
  • Gobuster and Dirb: finding hidden directories and files
  • sqlmap: testing for and confirming SQL injection safely
  • WPScan: checking WordPress sites
  • Turning every attack into a defence for the apps you built earlier

Lab scope for this whole chapter

Run every tool here only against DVWA, OWASP Juice Shop, or your own reels app from Chapter 16, all on your host-only lab. Automated web attacks against a site you do not own are illegal under the IT Act, even as a "test".

Concepts in this chapter

  1. 21.1How Web Testing Works: The Intercepting Proxy
  2. 21.2Burp Suite: Proxy and Intercept
  3. 21.3Burp Intruder: Automating Requests
  4. 21.4OWASP ZAP: A Free Full Scanner
  5. 21.5Gobuster and Dirb: Finding Hidden Content
  6. 21.6sqlmap: Testing for SQL Injection
  7. 21.7WPScan: Scanning WordPress
  8. 21.8Red vs Blue, Project and Real Incidents

The chapter recap is at the end of the last concept page.

Chapter 21: Web application testing tools — practice tasks

Open chapter lessons · Full guided lab: juice shop local headers cookies errors fixes (not repeated here)

21.1 Intercept a login in Burp or ZAP

MediumRetail

Why: Seeing raw requests is the base of web testing.

What: Proxy a login on local Juice Shop.

How:

  1. docker run -d --rm -p 127.0.0.1:3000:3000 bkimminich/juice-shop
  2. Set the browser proxy to ZAP/Burp on 127.0.0.1:8080.
  3. Log in with a fake account; view POST /rest/user/login.

Expected output: JSON body with email and password.

Hint

Use the proxy's built-in browser.

Answer / how to check
  1. You can see and replay the request.

21.2 Find hidden paths with ffuf

MediumIT

Why: Forgotten pages are common entry points.

What: Brute-force paths on localhost:3000 only.

How:

  1. ffuf -u http://127.0.0.1:3000/FUZZ -w /usr/share/wordlists/dirb/common.txt -mc 200

Expected output: Paths like /ftp or /api.

Hint

Only on your local target.

Answer / how to check
  1. Open /ftp in the browser → file list.

21.3 Read security headers

EasyBanking

Why: Headers block many browser attacks.

What: List headers from Juice Shop.

How:

  1. curl -sI http://127.0.0.1:3000 | grep -iE 'x-frame|csp|x-content|strict-transport'

Expected output: Some headers present; others missing.

Hint

See the linked Juice Shop headers lab.

Answer / how to check
  1. You wrote which headers are still missing.

Web tools with a defender's goal

You built PHP, LAMP/LEMP and even a reels-style app earlier. Now you look at the same kind of app the way a tester does, only on DVWA, Juice Shop or your own app. Every finding should become a fix you already know: prepared statements, authentication checks, security headers, least privilege.

After this lesson you will be able to

  1. Intercept and read an HTTP request in Burp or ZAP.
  2. Run a directory discovery scan on a lab app.
  3. Explain what sqlmap proved, then show the prepared-statement fix.
  4. Scan a lab WordPress and list plugin updates to apply.

Real-world picture

OWASP's Top 10 lists the most common web risks. Indian CERT-In advisories often map to the same classes: injection, broken access control, outdated software. Tools in this chapter find them. Your earlier chapters fix them.

Recap

  • Own apps and lab VMs only.
  • Finding without fixing is only half the lesson.

Defender's worksheet (do this today)

  1. Write the lesson title and date in your notebook.
  2. List three systems you own (VMs, personal projects, or lab apps) where this lesson applies.
  3. Run one safe command or checklist item from the lesson on a lab system only.
  4. Paste the command and its output under an Evidence heading.
  5. Write one fix you would give a teammate in two sentences.
  6. Write one mistake students make with this topic and how to avoid it.

More real-world pictures

Indian workplace (sample data)

Suppose we are a junior analyst at Tech Mahindra supporting a client SOC. After reading this lesson you add one detection or one hardening item to the team weekly checklist, with the owner name and a due date. That is how learning becomes operations.

Global practice

Public bodies such as CERT-In (India), CISA (US) and NCSC (UK) publish advisories that map to the same ideas: patch, least privilege, logging and user awareness. Bookmark one advisory feed and read it every Monday.

Home and family

Explain this lesson to a family member in four sentences without jargon. If they can repeat the main warning back to you, you understand it well enough to teach.

Connect to earlier chapters

Parts 1 to 9 built Linux, web servers, databases and cloud pieces. This lesson only makes sense when you can point to a concrete config file, package name or architecture box from those parts. If you cannot, revisit the matching earlier chapter before you practise any tool command.

Common mistakes

  • Skipping written permission just for a quick scan.
  • Practising on hostel or office Wi-Fi targets without authorisation.
  • Collecting tool output without writing the fix.
  • Copying exploit commands onto production to verify. Verification for defenders means checking versions and patches, not firing modules.

Recap

  • Evidence, fix, owner, date.
  • Own lab only.
  • Teach one other person the warning from this lesson.