From c370df6f4a865512f90a17e560caa2f29baf588e Mon Sep 17 00:00:00 2001 From: Connor Nelson Date: Tue, 17 Dec 2024 19:48:31 -0700 Subject: [PATCH] More --- web-security/csrf-get/DESCRIPTION.md | 1 - web-security/csrf-xss-post/DESCRIPTION.md | 4 ++-- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/web-security/csrf-get/DESCRIPTION.md b/web-security/csrf-get/DESCRIPTION.md index 449cf09..abf83dc 100644 --- a/web-security/csrf-get/DESCRIPTION.md +++ b/web-security/csrf-get/DESCRIPTION.md @@ -5,7 +5,6 @@ This style of attack, known as **Cross-Site Request Forgery (CSRF)**, takes adva Modern web security practices include defenses against CSRF, such as: - [**Same-Origin Policy (SOP)**](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy): Controls interactions between different origins (e.g., `http://example.com` and `http://evil.com`); typically "writes" (e.g., form submissions) and "embedding" (e.g., ``) is allowed, but "reads" are not. This means that you can send [simple requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests) to another site, but you cannot read the responses by default - [**SameSite Cookie Attribute**](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#controlling_third-party_cookies_with_samesite): Allows servers to specify when cookies should be sent with cross-site requests. -- [**HttpOnly Cookie Attribute**](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#security): Allows servers to specify that cookies should not be able to be accessed by JavaScript (e.g. `document.cookie`). - [**CSRF Tokens**](https://developer.mozilla.org/en-US/docs/Web/Security/Practical_implementation_guides/CSRF_prevention#anti-csrf_tokens): Unique tokens included in requests that attackers cannot forge, because SOP prevents them from reading the token. Despite these defenses, they are not always implemented correctly. In this challenge, pwnpost has resolved its XSS issues for the admin user. Your task is to exploit CSRF to publish the flag post! The victim user will log into pwnpost (`http://challenge.localhost/`) and visit your malicious site (`http://hacker.localhost:1337`). You can easily serve your malicious site using a Python HTTP Server (e.g. `http.server`), or even using `nc` if you prefer. Since these sites have different Origins, be mindful of SOP limitations. diff --git a/web-security/csrf-xss-post/DESCRIPTION.md b/web-security/csrf-xss-post/DESCRIPTION.md index 4522e97..f075d82 100644 --- a/web-security/csrf-xss-post/DESCRIPTION.md +++ b/web-security/csrf-xss-post/DESCRIPTION.md @@ -1,7 +1,7 @@ This level closes the loophole that allowed you to steal cookies from JavaScript. -Cookies have a special setting called `httponly`, and when this is set, the cookie is _only_ accessible in HTTP headers, and not through JavaScript. +Cookies have an optional attribute called (`HttpOnly`)[(https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#security)], and when this is set, the cookie is not able to be accessed by JavaScript (e.g. `document.cookie`) This is a security measure, aimed to prevent exactly the type of cookie pilfering that you have been doing. -Luckily, Flask's default `session` cookie is set to be `httponly`, so you cannot steal it from JavaScript. +Luckily, Flask's default `session` cookie is set to be `HttpOnly`, so you cannot steal it from JavaScript. So, now how would you get the flag with your CSRF-to-XSS shenanigans? Luckily, you don't _need_ the cookie!