GitBook: [master] 480 pages and one asset modified

SUMMARY.md

@@ -379,6 +379,8 @@
 * [Rate Limit Bypass](pentesting-web/rate-limit-bypass.md)
 * [Regular expression Denial of Service - ReDoS](pentesting-web/regular-expression-denial-of-service-redos.md)
 * [Reset/Forgotten Password Bypass](pentesting-web/reset-password.md)
+* [SAML Attacks](pentesting-web/saml-attacks.md)
+* [Server Side Inclusion/Edge Side Inclusion Injection](pentesting-web/server-side-inclusion-edge-side-inclusion-injection.md)
 * [SQL Injection](pentesting-web/sql-injection/README.md)
   * [MSSQL Injection](pentesting-web/sql-injection/mssql-injection.md)
   * [Oracle injection](pentesting-web/sql-injection/oracle-injection.md)
@@ -392,7 +394,6 @@
     * [Mysql SSRF](pentesting-web/sql-injection/mysql-injection/mysql-ssrf.md)
   * [SQLMap - Cheetsheat](pentesting-web/sql-injection/sqlmap/README.md)
     * [Second Order Injection - SQLMap](pentesting-web/sql-injection/sqlmap/second-order-injection-sqlmap.md)
-* [Server Side Inclusion/Edge Side Inclusion Injection](pentesting-web/server-side-inclusion-edge-side-inclusion-injection.md)
 * [SSRF \(Server Side Request Forgery\)](pentesting-web/ssrf-server-side-request-forgery.md)
 * [SSTI \(Server Side Template Injection\)](pentesting-web/ssti-server-side-template-injection/README.md)
   * [EL - Expression Language](pentesting-web/ssti-server-side-template-injection/el-expression-language.md)

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

@@ -151,6 +151,11 @@ The following parameters are particularly interesting for SSRF attacks:
 
   At the same time, many servers we've seen do not allow arbitrary "request\_uri" values: they only allow whitelisted URLs that were pre-registered during the client registration process. That's why we need to supply "request\_uris": "https://ybd1rc7ylpbqzygoahtjh6v0frlh96.burpcollaborator.net/request.jwt" beforehand.
 
+### CSRF - Attack 'Connect' Request <a id="bda5"></a>
+
+An **attacker** may **start** the **Connect** process from a dummy account with a provider and **stops** the process **before** the **redirect**.  
+Then, he may create a malicious web application that abusing a **CSRF** may **logout** the **victim** from the **Provider**. Then, with another **CSRF**, he **logs in the victim** inside the Provider with the **attackers** **dummy** **account** inside the **Provider**. And finally, being the **victim** **logged** inside the **application** as **his** **user** and **inside** the **provider** **as** the **attacker**, the attacker **sends** a final **HTTP** request with the **redirect** that was stopped at the begging, so the **attackers dummy account** with the provider is **linked** with the **victims** **account** of the **application**. 
+
 ### 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:
@@ -194,6 +199,14 @@ Once the client has the code and state, if it's reflected inside the Referer hea
 
 Go to the browser history and check if the access token is saved in there.
 
+### Everlasting Authorization Code
+
+The authorization code should live just for some time to limit the time window where an attacker can steal  and use it.
+
+### Authorization/Refresh Token not bound to client
+
+If you can get the authorization code and use it with a different client then you can takeover other accounts.
+
 ## Closing <a id="996f"></a>
 
 There’s plenty of other attacks and things that can go wrong in an OAuth implementation, but these are some of the more common ones that you will see. These misconfigurations are surprisingly common, and a very large quantity of bugs come from these. I intended to keep the “Quick Primer” rather short, but quickly realized all of the knowledge was necessary for the rest of the post. Given this, it makes sense that most developers aren’t going to know all the details for implementing securely. More often than not, these issues are high severity as it involves private data leak/manipulation and account takeovers. I’d like to go into more detail in each of these categories at some point, but wanted this to serve as a general introduction and give ideas for things to look out for!

pentesting-web/saml-attacks.md

@@ -0,0 +1,34 @@
+# SAML Attacks
+
+## Basic Information
+
+Security Assertion Markup Language \(SAML\) is an open standard that allows identity providers \(IdP\) to pass authorization credentials to service providers \(SP\). What that jargon means is that you can **use one set of credentials to log into many different websites**. It’s much simpler to manage one login per user than it is to manage separate logins to email, customer relationship management \(CRM\) software, Active Directory, etc.
+
+SAML transactions use Extensible Markup Language \(XML\) for standardized communications between the identity provider and service providers. SAML is the link between the authentication of a user’s identity and the authorization to use a service. \(From [here](https://www.varonis.com/blog/what-is-saml/)\)
+
+### SAML vs. OAuth
+
+OAuth is a slightly newer standard that was co-developed by Google and Twitter to enable streamlined internet logins. OAuth uses a similar methodology as SAML to share login information. **SAML provides more control** to enterprises to keep their SSO logins more secure, whereas **OAuth is better on mobile and uses JSON**.
+
+### Flow
+
+![](../.gitbook/assets/image%20%28534%29.png)
+
+## Attacks
+
+### Tampering with data
+
+The request number 5 from the previous image sends back the information from the identity provider to the service provider. This information is **usually signed** at the end of the message so **no tampering with the information is possible**. It's recommended to check what happens in case the information is sent **stripping the signature** from the message.
+
+### Burp Extension
+
+{% embed url="https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e" %}
+
+#### Tutorial
+
+{% embed url="https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/" %}
+
+{% embed url="https://www.economyofmechanism.com/github-saml" %}
+
+
+