> For the complete documentation index, see [llms.txt](https://cl4nd3st1ne.gitbook.io/write-ups/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cl4nd3st1ne.gitbook.io/write-ups/intigriti-challenges/leakyjar-june-bonus-challenge.md).
# LeakyJar (June Bonus Challenge)
### Solution
The challenge presents a platform with public cookie recipes, along with the option of signing up and creating our own recipes, sharing them with specific users and, most importantly (for us), reporting malicious recipes.
In the Bakers section, we can also confirm that there is a "Master Baker" with username admin. This information will be of use to us later.
On registering, it can be seen that a session cookie is created with HttpOnly flag set. This rules out cookie exfiltration attacks via XSS. But, the SameSite attribute is None and no anti-CSRF tokens are in use anywhere. This implies that there is potential for CSRF here.
Out of habit, I began by performing HTML injection in all input fields starting from registration to adding my own recipe. We could also add reviews to the existing public recipes but seeing the amount of payloads others had tried here, I knew this would definitely not work :laughing:
None of the above injections worked. Time to turn our attention to the Report a recipe feature.
The URL entered here will be looked at by the Master Baker. From the previous investigation of the Bakers section, we know that this is the admin.
To begin my investigation, I entered a webhook URL and saw that the admin bot visited it immediately. The only check being performed seemed to be that it must be an HTTPS URL.
We now know we can deliver URLs to the admin. Because the site lacks same-site protection, any cross-site request performed via those URLs will automatically include the admin's session cookie. With the above knowledge, the most effective strategy is to perform a CSRF attack. [This cheat-sheet](https://www.datocms-assets.com/85623/1765972419-intigriti-csrf-exploitation-cheat-sheet.png) shared by Intigriti in a [blog](https://www.intigriti.com/researchers/blog/hacking-tools/exploiting-insecure-cookie-policies#cross-site-request-forgery-csrf) recently is very useful in visualising why this target is vulnerable to CSRF and exactly how we're going to exploit it.
Next, we need to figure out what action we must perform through this CSRF in order to get the flag.
There is a feature to share our entire recipe box with another user. Below this section, we can also view recipe boxes of users who have shared it with us. Isn't this helpful?
If the admin shares their recipe box with us, we will be able to view all their recipes, and this is likely where we'll find the flag. This is how this particular request looks:
Observe how the request body is sent URL-form-encoded**,** which is a "simple request"**,** and thus**,** it doesn't trigger a pre-flight request. This checks off all the 4 conditions mentioned in the cheat-sheet above. We can now proceed to build the exploit.
One of the conditions required for a valid solution is that the exploit should be single-click. We can do this with the help of auto-submitted forms. The following HTML page can get the job done:
{% code overflow="wrap" %}
```
```
{% endcode %}
This is a typical exploit used to silently perform a POST request to the vulnerable API, keeping the input hidden and providing default values that we want submitted on behalf of the victim.
I used [Loophole](https://loophole.cloud/) to expose this page publicly:
Next, we can go report the path to the HTML file:
Once the report is successful, we can confirm the attack succeeded by returning to our recipe box, where we should see that we now have access to the admin's recipe box!
On viewing it, we will find the flag:
This concludes the challenge!
### Impact
* **Account Integrity Compromise:** An attacker can perform state-changing actions on behalf of any user, leading to unauthorised modifications of account settings.
* **Unauthorised Data Access:** Attackers can gain full access to private data and sensitive information stored in other accounts.
### Remediation
* **Update SameSite Cookie Attribute:** Change the session cookie’s SameSite attribute to Lax or Strict. This prevents the browser from sending the cookie during cross-site POST requests.
* **Implement Anti-CSRF Tokens:** Introduce unique, cryptographically strong, and unpredictable tokens for every request. The server should validate this token before processing the request.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://cl4nd3st1ne.gitbook.io/write-ups/intigriti-challenges/leakyjar-june-bonus-challenge.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.