What you need to know about Burp Suite before the first web CTF
Burp Suite is an intercept proxy and a set of tools for analyzing web traffic, sharpened to search for vulnerabilities of web applications. For a CTF player on a web category, this is the main working tool. Without it, half of the tassks are simply unsolved from the browser.
From the whole arsenal, a beginner on the CTF needs four modules. The others will wait.
Proxy is an HTTP proxy server that stands between the browser and the target server. Intercepts every query and response, allows them to read, change on the fly and forward further. This is what the browser hides: hidden form parameters, cookies with coded data, authorization headers, non-standard HTTP methods.
Repeater – manually sending modified requests. Intercepted the request in Proxy, threw in Repeater, changed the parameter, pressed Send, compared the answer. This is the main cycle when solving web-tasks. You can open several tabs and compare the server reaction to different modifications - convenient.
Intruder is the automation of overkill. You need to check 100 values of the parameter (User ID, PIN, password dictionary) - Intruder does this in seconds. In the Community version, the speed is cut by trottling, but for CTF tasks usually enough.
Decoder – data coding and decoding. Base64, URL-encoding, hex — what is constantly found in the CTF. Copied a suspicious cookie, inserted into Decoder, decoded from Base64 — saw JSON with {"role":"user"}. Changed to admin, encoded back, pasted into the request. Half of the Easy-tashka is solved this way.
Scanner is available only in the paid Professional version (for the current price, see portswigger.net/burp/pro), but for CTFs, manual analysis through Repeater is more effective than automatic scanning – tasks are specifically constructed so that the scanners do not cope. Click the community version from the official website - it is free, and all four modules above work (Intruder - with trottling).
Configure Burp Suite proxy and browser preparation
Before intercepting the first query, you need to configure a bundle of two components: Burp as an HTTP proxy server and a browser that will walk through it. A typical beginner’s mistake is to set up one thing and be surprised that nothing works.
Download Burp Suite Community with portswigger.net/burp/communitydownload. The installer includes Java, you do not need to set separately. Minimum: 4 GB RAM (better than 8), Windows 10+ / macOS 10.14+ / Linux. When you first start, choose Temporary project and Use Burp defaults – for CTFs this is for your eyes. Persistent-project is necessary for a multi-day pentest, not at competitions.
Once launched, Burp automatically raises the proxy on 127.0.0.1:8080. Check in the Proxy → Proxy settings tab: Proxy Listeners should have an entry in the list 127.0.0.1:8080 with a tick Running. If the port 8080 is busy, change to 8081 or any free.
Now you need to send a browser through this proxy. I recommend Firefox - it has its own certificate storage, regardless of the system, which simplifies life.
FoxyProxy Burp Suite — setup switching in one click
You can manually change the proxy settings in Firefox every time, but on CTF time is flags. FoxyProxy allows you to switch between direct connection and Burp with a single click.
Step-by-step setting of FoxyProxy for Burp Suite:
Open Firefox, go to Add-ons (about:addons), find FoxyProxy Standard and install
Click on the FoxyProxy icon in the toolbar → Options
Click Add to create a new proxy profile
Fill in the fields: Title — Burp, Proxy Type — HTTP, Proxy IP — 127.0.0.1, Port — 8080
Save profile
For activation: click on FoxyProxy icon → select profile Burp
For Disconnection: Select Turn Off (direct connection)
Critical point: If FoxyProxy is active and Burp Suite is not running, the browser will not download a single page. This is the first question that newcomers come with: “I have the Internet broken.” Didn't break - Burp is not running. The order is always this: first launched Burp → then included FoxyProxy → only then go to the tack.
How to Configure a Burp Suite browser without extensions: Firefox – Settings → General → Network Settings → Manual proxy configuration → HTTP Proxy: 127.0.0.1, Port: 8080, mark “Also use this proxy for HTTPS”. In exceptions add localhost, 127.0.0.1. Works, but switch manually each time – the loss of two minutes, which on the CTF may not be enough.
SSL Burp certificate – without it HTTPS does not work
Without installing the Burp CA certificate, the browser will show a security error on each HTTPS site. Burp generates its own certificate for decrypting HTTPS traffic – essentially a legitimate man-in-the-middle applied to its own traffic. Technically, it's similar to the Adversary-in-the-Middle (T1557 on MITRE ATT&CK, credential-access/collection tactics), but the T1557 describes the interception of third-party traffic by an attacker. We decrypt our own TLS traffic through a trusted CA is a diagnosis, not an attack.
Installing the SSL Burp Certificate in Firefox:
Make sure Burp is launched and FoxyProxy is aimed at Burp
In the address bar, go to http://burp ( HTTP, not HTTPS)
Click CA Certificate – file is downloaded cacert.der
In Firefox: Settings → Privacy & Security → Certificates → View Certificates
Tab → Authors Import→ Select Downloaded File
Mark Trust this CA to identify websites → OK
Check: open any HTTPS site — the page should boot up without warning, and in Burp in the Proxy → HTTP history tab, decrypted traffic will appear
If after installing the certificate, the browser still swears, restart Firefox completely. Didn’t help — remove the old PortSwigger certificate from the repository (input Authorities, find PortSwigger) and import again. It takes 30 seconds, but without a working certificate, HTTPS traffic interception is impossible.
HTTP Burp Suite Interception – First Actions
Proxy setup is complete. Let's move on to intercept. Open the Proxy → Intercept tab and make sure the button shows Intercept is on.
Now every request from the browser stops at Burp. The Intercept window shows a raw HTTP request: method (GET/POST), URL, headers (Host, User-Agent, Cookie) and body. The same thing that the DevTools show in a “beautiful” form, but here – without filters and with the ability to edit right before sending.
Three intercept control buttons:- Forward — send a request further to the server, get a response to the browser- Drop — delete the request: it will not reach the server, the action is canceled- Intercept is on/off — global intercept switch
A typical working cycle of web traffic analysis on CTF: enabled Intercept → performed an action in the browser (pressed a button, sent the form) → saw a request in Burp → studied parameters → sent Forward or flipped into Repeater via Ctrl+R.
Now the nuance on which everyone stumbles: do not keep Intercept on constantly. When it is active, every query — CSS, JS, pictures, favicon, analytics — stops at Burp. Instead of analyzing an interesting POST query, you’ll endlessly press Forward on the trash GETs to the CDN. Only enable Intercept before the specific action you want to intercept. Pressed the button - intercepted - switched off.
The entire query history is saved in the Proxy → HTTP history tab, even when the Intercept is off. Burp writes traffic in the background. You can safely view the tack with the Intercept switched off, and then find the right request in the story and send it to Repeater. Search for history — Ctrl+F in the bottom panel or filter by URL in the Filter line.
Scope – filter noise and focus on the target
On the CTF, you have one goal – the address of the task, for example http://challenge.ctf.local:5000. Everything else is noise. Target Scope restricts the interception and recording of only the target domain.
Setup Scope for Web CTFs:
Go to Target → Scope settings
Click Add and enter the task URL: http://challenge.ctf.local:5000
Return to Proxy → Proxy settings, in the Request Passion rules section, enable the URL rule Is in target scope
In HTTP history, click Filter and mark the Show only in-scope items
Without the Scope setting for half an hour, hundreds of requests to Google Fonts, CDN jQuery, and advertising trackers accumulate in HTTP history. The right POST to /api/login lost on the fifth page. Scope is saving tens of minutes for the competition. Set up first thing.
Burp Repeater: how to use for manual testing
Repeater is the main tool in solving web-tasks. The logic is simple: take a request, change the parameter, send, see the answer. Without automation, without scanning, is a clean manual job that solves most of the tasks on the CTF.
Send a request to Repeater: find it in HTTP history or intercept it through Intercept, right-click → Send to Repeater (hot key Ctrl+R). In the Repeater tab on the left, the editable query, the server response on the right. Change what you need, press Send, watch Response. You can open several tabs and compare answers to different modifications of a single query - this is more convenient than it seems.
A typical example is the check for IDOR (Insecure Direct Object Reference). According to OWASP Top 10, this category A01:2021 Broken Access Control is the most common vulnerability: 94% of the tested applications contain any form of access control violation. On CTF, the task may look like this: the profile page loads the data through GET /api/profile?id=42. Change id=1 – the server returns the data of another user without verifying the rights. Classic IDOR.
GET /api/profile?id=42 HTTP/1.1
Host: challenge.ctf.local:5000
Cookie: session=eyJhbGciOiJIUzI1NiJ9...
The flag is obtained by one modified parameter. In a real pentest, such a vulnerability allows an attacker to pull the data of any user of the system. In MITRE ATT&CK, the operation of public web applications is described as Exploit Public-Facing Application (T1190, Initial Access), although T1190 implies obtaining initial access to infrastructure. IDOR inside an already authenticated session is more of an access control (OWASP A01) rather than an access in terms of ATT&CK.
Another frequent CTF scenario is the SQL injection (A03:2021 Injection by OWASP). If the parameter hits the SQL request without filtering, you can send a classic test through Repeater:
GET /search?q=test' OR '1'='1 HTTP/1.1
Host: challenge.ctf.local:5000
If the answer has changed, all the records have returned instead of one, the injection is confirmed. Further: UNION SELECT to determine the number of columns, extract table names, receive the flag. The whole cycle is in Repeater, request by request.
Burp Intruder is a tutorial on overkill automation
When one request is small, Intruder is connected. On CTF it is a selection of user ID ID (mass IDOR), brutfors PIN-codes, phased hidden endpoints.
Sending a request: right click → Send to Intruder (or Ctrl+I).
In the Intruder → Positions tab, select a selection option. Burp wraps it with markers §. Click Clear § (remove all automatic markers), then highlight only the desired value and click Add §. In GET /api/profile?id=§42§ Markers stand around the value 42 - it's the one that's going to move.
Setting up an ID reassembly from 0 to 100:
In Positions, leave the markers only around the parameter value id
In the Payloads tab, select Numbers type : Range 0 to 100, Step 1
Attack type: Sniper (one parameter is one pailload list)
Click Start attack
In the results table, look at the Status (UTX response code) and Length (the size of the response in bytes). If 98 queries are returned Status 403 and Length 240, and two requests – Status 200 and Length 580 – here they are, interesting ID. Click on the request with a non-standard answer, see Response – with a high probability there is a flag or data for the next step.
In the Community version, Intruder works with trottling – the delay between requests slows down the too much. For CTF, this is rarely critical: 100-200 values are chased away in a couple of minutes. For large dictionaries (rockyou.txt for 14 million records), the Community version is already inconvenient, but such tasks on the CTF are infrequent.
Search for vulnerabilities of web applications: step-by-step analysis of web-taska
Let's get the whole arsenal into one algorithm. Let’s say the CTF gave a URL: http://challenge.local:8080 – application with login form and dashboard.
Step 1: exploration through Proxy. Include FoxyProxy on your Burp profile. Intercept is off. Go through all the pages of the application, fill out the forms with test data, click all the buttons. In HTTP history, a set of queries will accumulate - this is an endpoint card: /login, /dashboard, /api/user, /static/app.js. Already here look for suspicious parameters and unusual headlines.
Step 2: analysis of requests and cookies. In HTTP history find POST on /login. See the body: username=guest&password=guest. Now the answer is the title Set-Cookie. Often the value of cookies is base64-line. Copy it, open Decoder, paste, choose Decode as Base64. Seen {"user":"guest","role":"user"}? Here is a potential hole: if the server trusts data from cookies without server validation, the role can be replaced.
Step 3: Modification via Repeater. Send a request to /dashboard (the one in HTTP history, with cookies) in Repeater via Ctrl+R. Take JSON {"user":"admin","role":"admin"}, encode in Base64 via Decoder. Insert the result into the Cookie title instead of the original value. Send. If the server returned the admin page with the flag, the task is solved. Typical vulnerability: trust client data without server verification, category A01 by OWASP.
Step 4: If the cookie manipulation did not work, we dig deeper. Try SQL injection in login field: send admin' -- in the parameter username through Repeater. Check the HTML response to the hidden fields – <input type="hidden" name="isAdmin" value="false">. Intercept POST via Intercept, change isAdmin=true, press Forward. Look for developer comments in Response: <!-- TODO: remove debug endpoint /api/debug --> This is more common than it seems.
Step 5: Massive overkill through Intruder. If there's an endpoint on the dashboard /api/user?id=YOUR_ID – send a request to Intruder, go over the ID from 0 to 50 in Sniper mode. Look for a response with a non-standard Length or Status code – there will be the data of the privileged user or the flag itself.
Proxy algorithm → analysis → Repeater → Intruder covers the vast majority of Easy and Medium-level web-tasks on CTF. The tool itself is simple – value in a systematic approach and attentiveness to the details of requests.
Newcomer's Cheklist: The Mistakes That Flags Are Worth
In two years of training of the university CTF-team, I have collected a list of mistakes that all beginners make. Every one is lost minutes or whole loads.
Forgot to enable Intercept before action. Pressed Submit on the page, nothing in Burp appeared. Checked - Intercept is off. The request was gone, the action was done, there was nothing to intercept. Before each critical action, visually check the inscription on the Intercept button.
Didn't set up Scope. HTTP history is queryed with queries to fonts.googleapis.com, cdn.jsdelivr.net and google-analytics. The right POST to /api/flag lost on the fifth page. The first action after opening a task is to add its URL to the Target Scope and enable the filter in HTTP history.
No SSL certificate Burp was installed. HTTPS-task shows the SSL error in the browser. The student disables Burp and tries to solve the problem without interception - manually, through DevTools. Bottom line: 20 minutes on a task that is solved in three. Installing a certificate is part of the preparation for the CTF, not “I’ll figure it out later.”
Ignore cookies and headlines. Only look at the parameters in the URL and the POST body. And the flag is sewn into a base64-cookie that needs to be decoded through Decoder. Or the server checks the title X-Forwarded-For and gives the admin only for 127.0.0.1. On each dug, check Set-Cookie in responses and all non-standard headlines.
Do not use Repeater. Change the parameters directly in the Intercept and click Forward - if it did not work, you need to re-perform the action in the browser. In Repeater you can send the same request with dozens of modifications in a row. Ctrl+R must become a reflex.
Do not read Response in its entirety. Only watch the render of the page in the browser. And in raw Response, commented HTML with a hint, hidden JSON-endpoint or debug information with paths to files on the server. In Repeater or HTTP history, always check the Response → Raw tab through Ctrl+F.
Mini-cheklist before CTF (we have hanging on the wall):
Burp Suite launched, Proxy Listener is active on 127.0.0.1:8080
FoxyProxy is set up and Burp profile included
Burp SSL certificate is installed in Firefox
The URL of each task is added to Target Scope
Intercept is off by default (only before target action)
Decoder is open on a separate tab for quick base64/URL decoding
Hot keys worth remembering: Ctrl+R – send to Repeater, Ctrl+I – send to Intruder, Ctrl+F – search in the query or response.
Burp Suite is an intercept proxy and a set of tools for analyzing web traffic, sharpened to search for vulnerabilities of web applications. For a CTF player on a web category, this is the main working tool. Without it, half of the tassks are simply unsolved from the browser.
From the whole arsenal, a beginner on the CTF needs four modules. The others will wait.
Proxy is an HTTP proxy server that stands between the browser and the target server. Intercepts every query and response, allows them to read, change on the fly and forward further. This is what the browser hides: hidden form parameters, cookies with coded data, authorization headers, non-standard HTTP methods.
Repeater – manually sending modified requests. Intercepted the request in Proxy, threw in Repeater, changed the parameter, pressed Send, compared the answer. This is the main cycle when solving web-tasks. You can open several tabs and compare the server reaction to different modifications - convenient.
Intruder is the automation of overkill. You need to check 100 values of the parameter (User ID, PIN, password dictionary) - Intruder does this in seconds. In the Community version, the speed is cut by trottling, but for CTF tasks usually enough.
Decoder – data coding and decoding. Base64, URL-encoding, hex — what is constantly found in the CTF. Copied a suspicious cookie, inserted into Decoder, decoded from Base64 — saw JSON with {"role":"user"}. Changed to admin, encoded back, pasted into the request. Half of the Easy-tashka is solved this way.
Scanner is available only in the paid Professional version (for the current price, see portswigger.net/burp/pro), but for CTFs, manual analysis through Repeater is more effective than automatic scanning – tasks are specifically constructed so that the scanners do not cope. Click the community version from the official website - it is free, and all four modules above work (Intruder - with trottling).
Configure Burp Suite proxy and browser preparation
Before intercepting the first query, you need to configure a bundle of two components: Burp as an HTTP proxy server and a browser that will walk through it. A typical beginner’s mistake is to set up one thing and be surprised that nothing works.
Download Burp Suite Community with portswigger.net/burp/communitydownload. The installer includes Java, you do not need to set separately. Minimum: 4 GB RAM (better than 8), Windows 10+ / macOS 10.14+ / Linux. When you first start, choose Temporary project and Use Burp defaults – for CTFs this is for your eyes. Persistent-project is necessary for a multi-day pentest, not at competitions.
Once launched, Burp automatically raises the proxy on 127.0.0.1:8080. Check in the Proxy → Proxy settings tab: Proxy Listeners should have an entry in the list 127.0.0.1:8080 with a tick Running. If the port 8080 is busy, change to 8081 or any free.
Now you need to send a browser through this proxy. I recommend Firefox - it has its own certificate storage, regardless of the system, which simplifies life.
FoxyProxy Burp Suite — setup switching in one click
You can manually change the proxy settings in Firefox every time, but on CTF time is flags. FoxyProxy allows you to switch between direct connection and Burp with a single click.
Step-by-step setting of FoxyProxy for Burp Suite:
Open Firefox, go to Add-ons (about:addons), find FoxyProxy Standard and install
Click on the FoxyProxy icon in the toolbar → Options
Click Add to create a new proxy profile
Fill in the fields: Title — Burp, Proxy Type — HTTP, Proxy IP — 127.0.0.1, Port — 8080
Save profile
For activation: click on FoxyProxy icon → select profile Burp
For Disconnection: Select Turn Off (direct connection)
Critical point: If FoxyProxy is active and Burp Suite is not running, the browser will not download a single page. This is the first question that newcomers come with: “I have the Internet broken.” Didn't break - Burp is not running. The order is always this: first launched Burp → then included FoxyProxy → only then go to the tack.
How to Configure a Burp Suite browser without extensions: Firefox – Settings → General → Network Settings → Manual proxy configuration → HTTP Proxy: 127.0.0.1, Port: 8080, mark “Also use this proxy for HTTPS”. In exceptions add localhost, 127.0.0.1. Works, but switch manually each time – the loss of two minutes, which on the CTF may not be enough.
SSL Burp certificate – without it HTTPS does not work
Without installing the Burp CA certificate, the browser will show a security error on each HTTPS site. Burp generates its own certificate for decrypting HTTPS traffic – essentially a legitimate man-in-the-middle applied to its own traffic. Technically, it's similar to the Adversary-in-the-Middle (T1557 on MITRE ATT&CK, credential-access/collection tactics), but the T1557 describes the interception of third-party traffic by an attacker. We decrypt our own TLS traffic through a trusted CA is a diagnosis, not an attack.
Installing the SSL Burp Certificate in Firefox:
Make sure Burp is launched and FoxyProxy is aimed at Burp
In the address bar, go to http://burp ( HTTP, not HTTPS)
Click CA Certificate – file is downloaded cacert.der
In Firefox: Settings → Privacy & Security → Certificates → View Certificates
Tab → Authors Import→ Select Downloaded File
Mark Trust this CA to identify websites → OK
Check: open any HTTPS site — the page should boot up without warning, and in Burp in the Proxy → HTTP history tab, decrypted traffic will appear
If after installing the certificate, the browser still swears, restart Firefox completely. Didn’t help — remove the old PortSwigger certificate from the repository (input Authorities, find PortSwigger) and import again. It takes 30 seconds, but without a working certificate, HTTPS traffic interception is impossible.
HTTP Burp Suite Interception – First Actions
Proxy setup is complete. Let's move on to intercept. Open the Proxy → Intercept tab and make sure the button shows Intercept is on.
Now every request from the browser stops at Burp. The Intercept window shows a raw HTTP request: method (GET/POST), URL, headers (Host, User-Agent, Cookie) and body. The same thing that the DevTools show in a “beautiful” form, but here – without filters and with the ability to edit right before sending.
Three intercept control buttons:- Forward — send a request further to the server, get a response to the browser- Drop — delete the request: it will not reach the server, the action is canceled- Intercept is on/off — global intercept switch
A typical working cycle of web traffic analysis on CTF: enabled Intercept → performed an action in the browser (pressed a button, sent the form) → saw a request in Burp → studied parameters → sent Forward or flipped into Repeater via Ctrl+R.
Now the nuance on which everyone stumbles: do not keep Intercept on constantly. When it is active, every query — CSS, JS, pictures, favicon, analytics — stops at Burp. Instead of analyzing an interesting POST query, you’ll endlessly press Forward on the trash GETs to the CDN. Only enable Intercept before the specific action you want to intercept. Pressed the button - intercepted - switched off.
The entire query history is saved in the Proxy → HTTP history tab, even when the Intercept is off. Burp writes traffic in the background. You can safely view the tack with the Intercept switched off, and then find the right request in the story and send it to Repeater. Search for history — Ctrl+F in the bottom panel or filter by URL in the Filter line.
Scope – filter noise and focus on the target
On the CTF, you have one goal – the address of the task, for example http://challenge.ctf.local:5000. Everything else is noise. Target Scope restricts the interception and recording of only the target domain.
Setup Scope for Web CTFs:
Go to Target → Scope settings
Click Add and enter the task URL: http://challenge.ctf.local:5000
Return to Proxy → Proxy settings, in the Request Passion rules section, enable the URL rule Is in target scope
In HTTP history, click Filter and mark the Show only in-scope items
Without the Scope setting for half an hour, hundreds of requests to Google Fonts, CDN jQuery, and advertising trackers accumulate in HTTP history. The right POST to /api/login lost on the fifth page. Scope is saving tens of minutes for the competition. Set up first thing.
Burp Repeater: how to use for manual testing
Repeater is the main tool in solving web-tasks. The logic is simple: take a request, change the parameter, send, see the answer. Without automation, without scanning, is a clean manual job that solves most of the tasks on the CTF.
Send a request to Repeater: find it in HTTP history or intercept it through Intercept, right-click → Send to Repeater (hot key Ctrl+R). In the Repeater tab on the left, the editable query, the server response on the right. Change what you need, press Send, watch Response. You can open several tabs and compare answers to different modifications of a single query - this is more convenient than it seems.
A typical example is the check for IDOR (Insecure Direct Object Reference). According to OWASP Top 10, this category A01:2021 Broken Access Control is the most common vulnerability: 94% of the tested applications contain any form of access control violation. On CTF, the task may look like this: the profile page loads the data through GET /api/profile?id=42. Change id=1 – the server returns the data of another user without verifying the rights. Classic IDOR.
GET /api/profile?id=42 HTTP/1.1
Host: challenge.ctf.local:5000
Cookie: session=eyJhbGciOiJIUzI1NiJ9...
The flag is obtained by one modified parameter. In a real pentest, such a vulnerability allows an attacker to pull the data of any user of the system. In MITRE ATT&CK, the operation of public web applications is described as Exploit Public-Facing Application (T1190, Initial Access), although T1190 implies obtaining initial access to infrastructure. IDOR inside an already authenticated session is more of an access control (OWASP A01) rather than an access in terms of ATT&CK.
Another frequent CTF scenario is the SQL injection (A03:2021 Injection by OWASP). If the parameter hits the SQL request without filtering, you can send a classic test through Repeater:
GET /search?q=test' OR '1'='1 HTTP/1.1
Host: challenge.ctf.local:5000
If the answer has changed, all the records have returned instead of one, the injection is confirmed. Further: UNION SELECT to determine the number of columns, extract table names, receive the flag. The whole cycle is in Repeater, request by request.
Burp Intruder is a tutorial on overkill automation
When one request is small, Intruder is connected. On CTF it is a selection of user ID ID (mass IDOR), brutfors PIN-codes, phased hidden endpoints.
Sending a request: right click → Send to Intruder (or Ctrl+I).
In the Intruder → Positions tab, select a selection option. Burp wraps it with markers §. Click Clear § (remove all automatic markers), then highlight only the desired value and click Add §. In GET /api/profile?id=§42§ Markers stand around the value 42 - it's the one that's going to move.
Setting up an ID reassembly from 0 to 100:
In Positions, leave the markers only around the parameter value id
In the Payloads tab, select Numbers type : Range 0 to 100, Step 1
Attack type: Sniper (one parameter is one pailload list)
Click Start attack
In the results table, look at the Status (UTX response code) and Length (the size of the response in bytes). If 98 queries are returned Status 403 and Length 240, and two requests – Status 200 and Length 580 – here they are, interesting ID. Click on the request with a non-standard answer, see Response – with a high probability there is a flag or data for the next step.
In the Community version, Intruder works with trottling – the delay between requests slows down the too much. For CTF, this is rarely critical: 100-200 values are chased away in a couple of minutes. For large dictionaries (rockyou.txt for 14 million records), the Community version is already inconvenient, but such tasks on the CTF are infrequent.
Search for vulnerabilities of web applications: step-by-step analysis of web-taska
Let's get the whole arsenal into one algorithm. Let’s say the CTF gave a URL: http://challenge.local:8080 – application with login form and dashboard.
Step 1: exploration through Proxy. Include FoxyProxy on your Burp profile. Intercept is off. Go through all the pages of the application, fill out the forms with test data, click all the buttons. In HTTP history, a set of queries will accumulate - this is an endpoint card: /login, /dashboard, /api/user, /static/app.js. Already here look for suspicious parameters and unusual headlines.
Step 2: analysis of requests and cookies. In HTTP history find POST on /login. See the body: username=guest&password=guest. Now the answer is the title Set-Cookie. Often the value of cookies is base64-line. Copy it, open Decoder, paste, choose Decode as Base64. Seen {"user":"guest","role":"user"}? Here is a potential hole: if the server trusts data from cookies without server validation, the role can be replaced.
Step 3: Modification via Repeater. Send a request to /dashboard (the one in HTTP history, with cookies) in Repeater via Ctrl+R. Take JSON {"user":"admin","role":"admin"}, encode in Base64 via Decoder. Insert the result into the Cookie title instead of the original value. Send. If the server returned the admin page with the flag, the task is solved. Typical vulnerability: trust client data without server verification, category A01 by OWASP.
Step 4: If the cookie manipulation did not work, we dig deeper. Try SQL injection in login field: send admin' -- in the parameter username through Repeater. Check the HTML response to the hidden fields – <input type="hidden" name="isAdmin" value="false">. Intercept POST via Intercept, change isAdmin=true, press Forward. Look for developer comments in Response: <!-- TODO: remove debug endpoint /api/debug --> This is more common than it seems.
Step 5: Massive overkill through Intruder. If there's an endpoint on the dashboard /api/user?id=YOUR_ID – send a request to Intruder, go over the ID from 0 to 50 in Sniper mode. Look for a response with a non-standard Length or Status code – there will be the data of the privileged user or the flag itself.
Proxy algorithm → analysis → Repeater → Intruder covers the vast majority of Easy and Medium-level web-tasks on CTF. The tool itself is simple – value in a systematic approach and attentiveness to the details of requests.
Newcomer's Cheklist: The Mistakes That Flags Are Worth
In two years of training of the university CTF-team, I have collected a list of mistakes that all beginners make. Every one is lost minutes or whole loads.
Forgot to enable Intercept before action. Pressed Submit on the page, nothing in Burp appeared. Checked - Intercept is off. The request was gone, the action was done, there was nothing to intercept. Before each critical action, visually check the inscription on the Intercept button.
Didn't set up Scope. HTTP history is queryed with queries to fonts.googleapis.com, cdn.jsdelivr.net and google-analytics. The right POST to /api/flag lost on the fifth page. The first action after opening a task is to add its URL to the Target Scope and enable the filter in HTTP history.
No SSL certificate Burp was installed. HTTPS-task shows the SSL error in the browser. The student disables Burp and tries to solve the problem without interception - manually, through DevTools. Bottom line: 20 minutes on a task that is solved in three. Installing a certificate is part of the preparation for the CTF, not “I’ll figure it out later.”
Ignore cookies and headlines. Only look at the parameters in the URL and the POST body. And the flag is sewn into a base64-cookie that needs to be decoded through Decoder. Or the server checks the title X-Forwarded-For and gives the admin only for 127.0.0.1. On each dug, check Set-Cookie in responses and all non-standard headlines.
Do not use Repeater. Change the parameters directly in the Intercept and click Forward - if it did not work, you need to re-perform the action in the browser. In Repeater you can send the same request with dozens of modifications in a row. Ctrl+R must become a reflex.
Do not read Response in its entirety. Only watch the render of the page in the browser. And in raw Response, commented HTML with a hint, hidden JSON-endpoint or debug information with paths to files on the server. In Repeater or HTTP history, always check the Response → Raw tab through Ctrl+F.
Mini-cheklist before CTF (we have hanging on the wall):
Burp Suite launched, Proxy Listener is active on 127.0.0.1:8080
FoxyProxy is set up and Burp profile included
Burp SSL certificate is installed in Firefox
The URL of each task is added to Target Scope
Intercept is off by default (only before target action)
Decoder is open on a separate tab for quick base64/URL decoding
Hot keys worth remembering: Ctrl+R – send to Repeater, Ctrl+I – send to Intruder, Ctrl+F – search in the query or response.
