Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-14 17:07:34 +00:00
Code Issues Projects Releases Packages Wiki Activity

GitBook: [#2928] No subject

Browse source
This commit is contained in:
CPol 2021-12-30 10:14:05 +00:00 committed by gitbook-bot
parent e10010e9f4
commit f9fec3fd5b
No known key found for this signature in database
GPG key ID: 07D2180C7B12D0FF
2 changed files with 12 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
pentesting-web/cross-site-websocket-hijacking-cswsh.md
View file

@ -73,6 +73,10 @@ Once the client is trying to connect to you you can use:
websocat -E --insecure --text ws-listen:0.0.0.0:8000 wss://10.10.10.10:8000 -v
```
## Websockets Enumeration
You can use the **tool** [**https://github.com/PalindromeLabs/STEWS**](https://github.com/PalindromeLabs/STEWS) **to discover, fingerprint and search for known** **vulnerabilities** in websockets automatically.
## Cross-site WebSocket hijacking (CSWSH)
Also known as _cross-origin WebSocket hijacking_.\

8
pentesting-web/oauth-to-account-takeover.md
View file

@ -89,6 +89,14 @@ All these parameters are **optional according to the OAuth and OpenID** specific
If you target an OpenID server, the discovery endpoint at **`.well-known/openid-configuration`**sometimes contains parameters such as "_registration\_endpoint_", "_request\_uri\_parameter\_supported_", and "_require\_request\_uri\_registration_". These can help you to find the registration endpoint and other server configuration values.
### XSS in redirect implementation <a href="#bda5" id="bda5"></a>
As mentioned in this bug bounty report [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html) it might be possible that the redirect **URL is being reflected in the response** of the server after the user authenticates, being **vulnerable to XSS**. Possible payload to test:
```
https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>
```
### CSRF - Improper handling of state parameter <a href="#bda5" id="bda5"></a>
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 authorising. You will then come across a request such as: