More

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., `<img>`) 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.

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!