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

21. Web Application Testing Tools

21.3 Burp Intruder: Automating Requests

By Last updated:

Intruder repeats a request while changing marked positions – useful for testing many inputs (for example, trying an ID from 1 to 50 to find IDOR). Community Edition throttles the speed, which is fine for the lab.

Workflow:

  1. Send a request to Intruder (right-click, "Send to Intruder").
  2. Positions: mark the value to change with § § (for example the id=§1§ in a URL).
  3. Payloads: choose a list – numbers 1–50, or a wordlist of usernames.
  4. Start attack: read the results table; a different status or length often means you found something.

Intruder is powerful – lab only

Running Intruder against a real site is an automated attack and can lock accounts or overload a server. Keep it on DVWA/Juice Shop and your own apps.

Ravindra Bagale's Tip

In the results table everything is "200 OK", so students say "nothing found". Look at the Length column – where the length is different, the answer is different. When hunting for IDOR, this column is the most important.

Lab

In DVWA (or Juice Shop), find a page that takes an id in the URL. Use Intruder with numbers 1–20 in that position and compare the response lengths. Note any id that returns another user's data – that is IDOR, which you will fix in Chapter 27.

Intruder as a teaching tool, not a weapon

Intruder shows how attackers try many values quickly. Your defensive lesson is rate limiting, lockouts and predictable-ID protection.

  1. Rate-limit login and OTP endpoints (nginx limit_req, API gateway rules, or app middleware).
  2. Use unpredictable IDs (UUIDs) instead of 1, 2, 3 for private objects.
  3. Lock accounts after repeated failures and alert on spikes.
  4. Log and monitor for password-spraying patterns.

Real examples

Indian company (sample): a UPI app saw a spike of password guesses at 3 a.m. Rate limits and CAPTCHA cut it within minutes. Global: credential stuffing against large sites is routine. Have I Been Pwned and similar services help users change reused passwords.

Common mistakes

  • Running Intruder against live sites. That can lock real users out and is often illegal.
  • Testing OTPs against production SMS gateways (cost and abuse).

Recap

  • Lab only.
  • The fix is rate limits, strong IDs and monitoring.

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.