├── days
    ├── day5.md
    ├── day14.md
    ├── day12.md
    ├── day2.md
    ├── day13.md
    ├── day16.md
    ├── day1.md
    ├── day15.md
    ├── day17.md
    ├── day8.md
    ├── day18.md
    ├── day4.md
    ├── day3.md
    ├── day10.md
    ├── day7.md
    ├── day11.md
    ├── day6.md
    └── day9.md
└── README.md


/days/day5.md:
--------------------------------------------------------------------------------
 1 | #  Client-Side Template Injection (CSTI)
 2 | Index | Section
 3 | --- | ---
 4 | **1** | What is CSTI
 5 | **2** | Method
 6 | 
 7 | ___
 8 | #### What is CSTI
 9 | ```
10 | 1. This occurs at the client-side like other JS attacks such as XSS.
11 | 2. This is mainly seen in the various JS libraries like AngularJS, VueJS etc which utilize the template engines at the client-side.
12 | 3. The presence of "ng-app" in the page source identifies the use of templates. 
13 | 4.  If the application directly accepts the input and process it without any validation, it may be vulnerable to CSTI. 
14 | 5. CSTI leads to perform cross-site scripting attacks by escaping
15 | 6. Testing this issue is similar to Server-Side Template Injection. 
16 | ```
17 | #### Method
18 | ```
19 | a. In the suspected field, provide a payload like {{11*5}}
20 | b. If the response reflected is 55, this tells that there is the use of the template and further you can try performing CSTI to XSS
21 | ```
22 | 


--------------------------------------------------------------------------------
/days/day14.md:
--------------------------------------------------------------------------------
 1 | #  WebSocket Vulns (part - 2)
 2 | 
 3 | Index | Section
 4 | --- | ---
 5 | **1** | Testing for IDOR in WebSockets
 6 | **2** | Denial of Service
 7 | ___
 8 | #### Testing for IDOR in WebSockets
 9 | ```
10 | 1. Intercept WebSocket Communication.
11 | 
12 | 2. Look for any pattern/trace of ID/UUID/user/role and another similar parameter that may uniquely define an object/entity.
13 | 
14 | 3. Assume the WebSocket communication is of a chatting application and consists of a request, where the Attacker is sending a message to the victim. There is a parameter called "sid" which is the attacker's user id.
15 | 
16 | 4. Now, change this "sid" to some victim B's "sid" and if Victim A receives a message from Victim B. That's an issue.
17 | 
18 | Look for all IDORs cases that you look for in normal HTTP workflow
19 | ```
20 | #### Denial of Service
21 | ```
22 | 1. WS allows any number of connections to the target server.
23 | 2. This behavior can be abused by an attacker to exhaust resources and perform a Denial of Service Attack.
24 | 
25 | - Try sending multiple requests to initiate a WS connection in a short time, this may trigger some lagging in the app processing which can be lead to App Level DoS.
26 | ```


--------------------------------------------------------------------------------
/days/day12.md:
--------------------------------------------------------------------------------
 1 | #  Unicode Normalization
 2 | 
 3 | This attack is hard to explain with out proper graphics. \
 4 | Please refer to the references mentioned for a detailed explanation. \
 5 | This is a really good attack vector to try and consider while doing PT/BB.
 6 | 
 7 | ___
 8 | #### Unicode to ASCII Transformation is a two-step process
 9 | ```
10 | 1. Normalization: Where the characters are converted to a standardized form
11 | 
12 | 2. Punycoding: Where the Unicode is turned into ASCII
13 | ```
14 | #### There are two overall types of equivalence between characters
15 | ```
16 | 1. Canonical Equivalence: Characters are assumed to have the same appearance and meaning when printed or displayed. 
17 | 
18 | 2. Compatibility Equivalence: This is a weaker equivalence, in that two values may represent the same abstract character but can be displayed differently.
19 | ```
20 | ####  There are 4 Normalization AlgoDefined by Unicode Standard
21 | ```
22 | 1. Normalization Form D (NFD): Canonical Decomposition
23 | 2. Normalization Form C (NFC): Canonical Decomposition, followed by Canonical Composition
24 | 3. Normalization Form KD (NFKD): Compatibility Decomposition
25 | 4. Normalization Form KC (NFKC): Compatibility Decomposition, followed by Canonical Composition
26 | ```
27 | #### Some Vulnerabilities that can be exploited using this abuse
28 | ```
29 | 1. WAF & Filter Bypass for Attacks like XSS, SQLi, etc.
30 | 2. Account Takeovers 
31 | 3. Text Transformation Attacks
32 | ```


--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
 1 | # learn365
 2 | 
 3 | This repository contains all the information shared during my Learn 365 Challenge. Learn 365 is a challenge to keep the learning spirit going on and challenge myself to learn something daily for the whole year, it can be anything from infosec to general life. Follow me on Twitter for Regular Updates: [Harsh Bothra](https://twitter.com/harshbothra_). Huge thanks to [Mehedi Hasan Remon](https://twitter.com/remonsec), who originally created and maintained this repository. 
 4 | ___
 5 | 
 6 | 
 7 | Day | Topic
 8 | --- | ---
 9 | **1** |  [2FA Bypass Techniques](/days/day1.md)
10 | **2** | [Regular Expression Denial Of Service](/days/day2.md)
11 | **3** | [SAML Vulnerabilities](/days/day3.md)
12 | **4** | [Unauthenticated & Exploitable JIRA Vulnerabilities ](/days/day4.md)
13 | **5** | [Client-Side Template Injection(CSTI)](/days/day5.md)
14 | **6** | [Cross-Site Leaks (XS-Leaks)](/days/day6.md)
15 | **7** | [Cross-Site Script Includes (XSSI)](/days/day7.md)
16 | **8** | [JSON Padding Attacks](/days/day8.md)
17 | **9** | [JSON Attacks](/days/day9.md)
18 | **10** | [Abusing Hop-by-Hop Headers](/days/day10.md)
19 | **11** | [Cache Poisoned Denial of Service (CPDos)](/days/day11.md)
20 | **12** | [Unicode Normalization](/days/day12.md)
21 | **13** | [WebSocket Vulns (Part-1)](/days/day13.md)
22 | **14** | [WebSocket Vulns (Part-2)](/days/day14.md)
23 | **15** | [WebSocket Vulns (Part-3)](/days/day15.md)
24 | **16** | [Web Cache Deception Attack](/days/day16.md)
25 | **17** | [Session Puzzling Attack](/days/day17.md)
26 | **18** | [Mass Assignment Attack](/days/day18.md)
27 | 


--------------------------------------------------------------------------------
/days/day2.md:
--------------------------------------------------------------------------------
 1 | #  Regular Expression Denial of Service
 2 | 
 3 | Index | Section
 4 | --- | ---
 5 | **1** | What is ReDos
 6 | **2** | Method
 7 | **3** | Evaluation
 8 | **4** | Resources
 9 | **5** | Prevention
10 | **6** | References
11 | 
12 | ___
13 | #### What is ReDos
14 | ```
15 | Due to weakly implemented RegEx Sometimes it is possible to perform a DoS attack by making this expression to evaluate an expression which will make the application work relatively slow.
16 | 
17 | Usually this attack is explored and exploited when the source code is available and you can figure out what regular expressions are used in the code at what fields. 
18 | 
19 | For example, at the mobile no input field, what is the regex that validates the mobile no input field.
20 | However, you can also try to find this in Black/Gray Box engagements. 
21 | ```
22 | 
23 | #### Method
24 | 
25 | ```
26 | Open the JavaScript files and search for the "RegExp(" function and try to figure out what function utilize that particular Regex.
27 | ```
28 | #### Evaluation
29 | ```
30 | https://github.com/2bdenny/ReScue 
31 | 
32 | This is a good tool to evaluate and identify if the given regex is vulnerable or not. 
33 | This tool will also provide a string that will make the vulnerable RegEx go into potential ReDoS Attacks.
34 | 
35 | It is important to understand how RegEx works and not only with ReDoS attack but it is useful overall.
36 | ```
37 | #### Resources
38 | ```
39 | Some of the good websites to learn about Regex are
40 | 
41 | https://rexegg.com
42 | https://regexone.com
43 | https://speakerdeck.com/harshbothra/having-fun-with-regex
44 | ```
45 | #### Prevention
46 | ```
47 | https://regular-expressions.info/redos.html 
48 | ```
49 | #### References
50 | ```
51 | https://hackerone.com/reports/511381
52 | https://hackerone.com/reports/661722
53 | ```
54 | 


--------------------------------------------------------------------------------
/days/day13.md:
--------------------------------------------------------------------------------
 1 | #  WebSocket Vulns
 2 | 
 3 | WebSocket is a network protocol that enables 2-way communication b/w client & server. \
 4 | In the HTTP standard, where the one-party has to wait for the req./res from another party before performing the next action. 
 5 | 
 6 | The major goal of WebSocket is to enable real-time communication and can widely be seen in IM applications. 
 7 | 
 8 | I will be diving the WebSocket learning into 3 parts and I will post more about various attacks in the next two days.
 9 | 
10 | 
11 | Index | Section
12 | --- | ---
13 | **1** | Web socket Protocol Scheme
14 | **2** | WebSocket Connection Process
15 | **3** | How to work with Websocket Messages
16 | **4** | General Security Implications
17 | **5** | References
18 | ___
19 | #### Web socket Protocol Scheme
20 | ```
21 | 1. Websockets use wss:// and ws:// as the protocol scheme. 
22 | 2. This is similar to HTTPS and HTTP. Here, the WSS:// is a secure channel where WS:// is an insecure channel.
23 | ```
24 | #### WebSocket Connection Process
25 | ```
26 | 1. The application will send an HTTP request with two additional Headers: Upgrade: WebSocket & Connection: Upgrade to the server. 
27 | 2. This request basically initiates the Web Socket connection process.
28 | 3. In return the server will return 101 Switching Protocols status code.
29 | 4. After this, WebSocket communication will start to take place. 
30 | ```
31 | #### How to work with Websocket Messages
32 | ```
33 | 1. Burp Suite allows an option to capture the WebSocket Traffic, modify it, and replay it.
34 | 2. Additionally, you can use the Simple Web Socket browser extension to check for some test cases and communicating with the Web Socket. 
35 | ```
36 | #### General Security Implications
37 | ```
38 | 1. Denial of Service 
39 | 2. Insecure Communication
40 | 3. Missing Access Controls & Authorization Checks
41 | 4. Missing Input Validation in User-Controlled Data 
42 | 5. Lack of/Improper Authentication 
43 | 6. Tunneling 
44 | 7. Cross-Site Web Socket Hijacking 
45 | 8. Server-Side Issues & OOB (out of band) Issues
46 | ```
47 | #### References
48 | ```
49 | WebSocket Top 7 Vuln: https://www.neuralegion.com/blog/websocket-security-top-vulnerabilities/
50 | ```


--------------------------------------------------------------------------------
/days/day16.md:
--------------------------------------------------------------------------------
 1 | # Web Cache Deception Attack
 2 | 
 3 | This attack mainly happens when the Cache-Control directives are misconfigured and can be leveraged by an attacker to get hold of sensitive information.
 4 | 
 5 | Index | Section
 6 | --- | ---
 7 | **1** | [About the attack](#About-the-attack)
 8 | **2** | [Path confusion attacks](#Path-confusion-attacks)
 9 | **3** | [Cause](#cause)
10 | **4** | [Scenario](#Scenario)
11 | **5** | [How to test](#How-to-test)
12 | ___
13 | 
14 | ### About the attack
15 | ```
16 | - This attack requires User Interaction. 
17 | - One of the important vectors is "Path Confusion Attack."
18 | - Path Confusion Attack/Flexible URL Rewriting plays an important role in this Attack
19 | ```
20 | 
21 | ### Path confusion attacks
22 | ```
23 | - Many Web Applications have URL Rewriting Rules.
24 | - In such scenarios depending upon the configuration of the webserver, both of these URLs will be considered as (http://harshbothra.tech/myprofile).
25 | - http://harshbothra.tech/myprofile
26 | - http://harshbothra.tech/myprofile/test.css
27 | ```
28 | 
29 | ### Cause
30 | ```
31 | - The following example code uses a regex that will consider both of the above examples as the same treaty: 
32 | 
33 | from django.conf.urls import url
34 | 
35 | patterns = [url(r'^myprofile/', ...)]
36 | ```
37 | 
38 | ### Scenario
39 | ```
40 | - Now, when the user requests for a static resource such as CSS, JPG, JS, etc., the web cache will consider to cache it considering it as static content (Expected Behavior) and this is where the web cache deception attack will come into the picture.
41 | ```
42 | 
43 | ### How to Test
44 | ```
45 | 1. Navigate to an application and look for a page that may contain sensitive information such as http://harshbothra.tech/myprofile
46 | 2. Now add any static file after /myprofile such as test.css, test.jpg, etc. For Ex: http://harshbothra.tech/myprofile/test.jpg
47 | 3. Now, if the app displays the same /myprofile page, it might be cached. 
48 | 4. Now, From another session (where this user is not logged in), navigate to the same URL: http://harshbothra.tech/myprofile/test.jpg
49 | 5. If you can see the information about the victim user. The attack is successful.
50 | ```
51 | 


--------------------------------------------------------------------------------
/days/day1.md:
--------------------------------------------------------------------------------
 1 | # 2FA Bypass Techniques
 2 | 
 3 | ### [Mindmap](https://mm.tt/1736437018?t=SEeZOmvt01)
 4 | 
 5 | Index | Technique
 6 | --- | ---
 7 | **1** | Response Manipulation
 8 | **2** | Status Code Manipulation
 9 | **3** | 2FA Code Leakage in Response
10 | **4** | JS File Analysis
11 | **5** | 2FA Code Reusability
12 | **6** | Lack of Brute-Force Protection
13 | **7** | Missing 2FA Code Integrity Validation
14 | **8** | CSRF on 2FA Disabling
15 | **9** | Password Reset Disable 2FA
16 | **10** | Backup Code Abuse
17 | **11** | Clickjacking on 2FA Disabling Page
18 | **12** | Enabling 2FA doesn't expire Previously active Sessions
19 | **13** | Bypass 2FA with null or 000000
20 | ___
21 | #### Response Manipulation
22 | ```
23 | In response if "success":false
24 | Change it to "success":true
25 | ```
26 | 
27 | #### Status Code Manipulation
28 | 
29 | ```
30 | If Status Code is 4xx
31 | Try to change it to 200 OK and see if it bypass restrictions
32 | ```
33 | #### 2FA Code Leakage in Response
34 | ```
35 | Check the response of the 2FA Code Triggering Request to see if the code is leaked.
36 | ```
37 | #### JS File Analysis
38 | ```
39 | Rare but some JS Files may contain info about the 2FA Code, worth giving a shot
40 | ```
41 | #### 2FA Code Reusability
42 | ```
43 | Same code can be reused
44 | ```
45 | ### Lack of Brute-Force Protection
46 | ```
47 | Possible to brute-force any length 2FA Code
48 | ```
49 | #### Missing 2FA Code Integrity Validation
50 | ```
51 | Code for any user acc can be used to bypass the 2FA
52 | ```
53 | #### CSRF on 2FA Disabling
54 | ```
55 | No CSRF Protection on disabling 2FA, also there is no auth confirmation
56 | ```
57 | #### Password Reset Disable 2FA
58 | ```
59 | 2FA gets disabled on password change/email change
60 | ```
61 | #### Backup Code Abuse
62 | ```
63 | Bypassing 2FA by abusing the Backup code feature
64 | Use the above mentioned techniques to bypass Backup Code to remove/reset 2FA restrictions
65 | ```
66 | #### Clickjacking on 2FA Disabling Page
67 | ```
68 | Iframing the 2FA Disabling page and social engineering victim to disable the 2FA
69 | ```
70 | #### Enabling 2FA doesn't expire Previously active Sessions
71 | ```
72 | If the session is already hijacked and there is a session timeout vuln
73 | ```
74 | #### Bypass 2FA with null or 000000
75 | ```
76 | Enter the code 000000 or null to bypass 2FA protection.
77 | ```
78 | 


--------------------------------------------------------------------------------
/days/day15.md:
--------------------------------------------------------------------------------
 1 | #  WebSocket Vulns (part - 3)
 2 | 
 3 | Index | Section
 4 | --- | ---
 5 | **1** | Insecure WS Connection
 6 | **2** | Cross-Site Scripting
 7 | **3** | Sensitive Information in WS
 8 | **4** | Server-Side Injections
 9 | **5** | Other Server-Side issues
10 | **6** | Learn & Practice
11 | **7** | References
12 | ___
13 | #### Insecure WS Connection
14 | ```
15 | - If the WS is using WS:// instead of WSS://, this is like using HTTP:// instead of HTTPS://. 
16 | - The WSS:// sends the traffic over SSL/TLS & prevents MiTM attacks.
17 | - If any sensitive action is happening through WebSocket over WS://, try traffic intercepts, and create a proof of concept to show the impact.
18 | - If the WebSocket is using WSS://, try degrading it to WS:// and see if the WS:// is supported.
19 | ```
20 | #### Cross-Site Scripting
21 | ```
22 | - Check if the WebSocket is sending data that is displayed back on the application interface or somewhere in another panel (if you have access to it)
23 | - Also, if the data is reflecting somewhere else say admin panel, always try to perform Blind XSS
24 | - Send XSS payloads in interesting parameters & if the app fails to perform Input Validation in WS, it can allow an attacker to trigger XSS.
25 | ```
26 | #### Sensitive Information in WS
27 | ```
28 | - Read the Message sent through WS & keep an eye for any sensitive information that can be utilized
29 | - Just like reading response or JavaScript files in the usual web workflow. 
30 | ```
31 | #### Server-Side Injections
32 | ```
33 | - Check all the WebSocket Parameters for potential Server Side Injection like SQLi 
34 | - Fuzz the Parameters based on how various payloads and inputs are handled.
35 | ```
36 | #### Other Server-Side issues
37 | ```
38 | It is always a good idea to test the interesting parameters for all potential security vulnerabilities that are usually tested in normal HTTP Workflow.
39 | ```
40 | #### Learn & Practice
41 | ```
42 | PortSwigger: https://portswigger.net/web-security/websockets
43 | ```
44 | #### References
45 | ```
46 | - https://hackerone.com/reports/178990
47 | - https://hackerone.com/reports/409850
48 | - https://hackerone.com/reports/395729
49 | - https://hackerone.com/reports/163464
50 | - https://github.com/github/securitylab/issues/65
51 | - https://hackerone.com/reports/512065
52 | - https://hackerone.com/reports/1023669
53 | - https://hackerone.com/reports/86283
54 | ```


--------------------------------------------------------------------------------
/days/day17.md:
--------------------------------------------------------------------------------
 1 | # Session Puzzling Attack
 2 | 
 3 | Also known as Session Variable Overloading Attack. <br>
 4 | An app-level issue that may allow an attacker to bypass authentication, elevate privileges, skip MFA, or exploit any related issues.
 5 | 
 6 | Index | Section
 7 | --- | ---
 8 | **1** | [About the attack](#About-the-attack)
 9 | **2** | [Scenario](#Scenario)
10 | **3** | [How to test](#How-to-test)
11 | **4** | [Practice](#Practice)
12 | **5** | [How to test](#How-to-test)
13 | ___
14 | 
15 | ### About the attack
16 | ```
17 | - When an application utilizes the same session variable for multiple purposes, this can be abused by an attacker to trick the application and perform the action as an authenticated or privileged user.
18 | - In Simple Words, For example, if the application generates a session identifier at an unauthenticated page and later that can be used to access the authenticated page, it is a session puzzling vulnerability.
19 | 
20 | ```
21 | 
22 | 
23 | ### Scenario
24 | ```
25 | - An attacker navigates to the /forget_pass page of the application.
26 | - He provides the username of the victim user and initiate a password reset request and observes the application assigns a session identifier by looking at the cookies.
27 | - Now, the attacker utilizes the same session identifier in cookies to access an authenticated page /my_profile and the page is accessed successfully with the victim user's information.
28 | - This is Session Puzzling/Session Variable Overloading Attack.
29 | ```
30 | 
31 | ### How to Test
32 | ```
33 | - Always check for the session identifier generation at various unauthenticated or lower privileged pages and see if they can be used to access authenticated or higher privileged pages.
34 | ```
35 | 
36 | ### Remediation 
37 | ```
38 | - Session variables should only be used for a single consistent purpose.
39 | ```
40 | 
41 | ### Practice
42 | 
43 | - https://owasp-skf.gitbook.io/asvs-write-ups/kbid-250-session-puzzling
44 | 
45 | ### References
46 | - https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/08-Testing_for_Session_Puzzling
47 | - https://dzone.com/articles/using-session-puzzling-to-bypass-two-factor-authen
48 | - https://medium.com/bugbountywriteup/hunting-session-overloading-d2ec860c49c0
49 | - https://code.google.com/archive/p/puzzlemall/downloads
50 | - https://medium.com/@maheshlsingh8412/session-puzzling-attack-bypassing-authentication-29f4ff2fd4f5
51 | - https://deepsec.net/docs/Slides/2013/DeepSec_2013_Shay_Chen_-_The_Boomerang_Effect_-_Using_Session_Puzzling_To_Attack_Apps_From_The_Backend.pdf
52 | 


--------------------------------------------------------------------------------
/days/day8.md:
--------------------------------------------------------------------------------
 1 | #  Json Padding (JSONP) Attack
 2 | Index | Section
 3 | --- | ---
 4 | **1** | What is JSONP & JSONP Attack
 5 | **2** | Callback Parameter
 6 | **3** | Security Risks with JSONP
 7 | **4** | Tools
 8 | **5** | References
 9 | ___
10 | #### What is JSONP & JSONP Attack
11 | ```
12 | 1. JSONP stands for  JavaScript Object Notation with Padding  which allows sending JSON data across domains without worrying about Cross-Domain Issues.
13 | 
14 | 2. It utilizes <script> tag to perform the action instead of using XMLHttpRequest. However, the function requires to be existing in the global scope
15 | 
16 | 3. JSONP is an insecure communication technique and it should only be used when no personal or sensitive data is involved and sanitizing the callback function.
17 | 
18 | 4. There are multiple attacks affecting the JSONP implementation as it doesn't have a pre-implemented security feature. 
19 | 
20 | 
21 | ```
22 | 
23 | #### Callback Parameter
24 | ```
25 | 1. The “padding” or function to call with the JSON data, is often specified as a parameter. Often this parameter is called callback and is reflected as-is in the response.
26 | 
27 | ```
28 | 
29 | #### Security Risk with JSONP
30 | ```
31 | 
32 | 1. It is possible to access data cross-domains which makes it possible to steal sensitive information of an authenticated user which other domains should not have access to. JSONP attack makes it possible to retrieve the data in a CSRF-style attack.
33 | 
34 | 2. Usually the JSONP endpoint will be visible by looking at the various GET/POST calls. Alternatively you can search your HTTP History to search for endpoints like ?callback=somedata, etc. 
35 | 
36 | 3. JSONP might be supported at the API level and might not be visible directly or acts as a hidden parameter. You can try following: 
37 |     A. Adding  a callback parameter to a JSON URL, by appending ?callback=something to the URL.
38 |     B. When a format type is provided, change it to JSONP. Change ?format=json to ?format=jsonp.
39 | 
40 | ```
41 | 
42 | 
43 | #### Tools 
44 | 
45 | ```
46 | 1. https://github.com/kapytein/jsonp
47 | 2. https://github.com/zigoo0/JSONBee
48 | 
49 | ```
50 | 
51 | 
52 | #### References
53 | 
54 | ```
55 | a. https://www.sjoerdlangkemper.nl/2019/01/02/jsonp/ 
56 | b. https://gracefulsecurity.com/jsonp-vulnerabilities/
57 | c. https://owasp.org/www-pdf-archive//2017-04-20-JSONPXSS.pdf	
58 | d. https://gist.github.com/karanth/8467944
59 | e. https://securitycafe.ro/2017/01/18/practical-jsonp-injection/
60 | f. https://medium.com/bugbountywriteup/exploiting-jsonp-and-bypassing-referer-check-2d6e40dfa24
61 | g. Sample JSONP Page to Practice the Retrieval of data using Script through Other Domain: https://demo.sjoerdlangkemper.nl/jsonp.php
62 | h. https://hackerone.com/reports/10373
63 | ```
64 | 


--------------------------------------------------------------------------------
/days/day18.md:
--------------------------------------------------------------------------------
 1 | # Mass Assignment Attack
 2 | 
 3 | Index | Section
 4 | --- | ---
 5 | **1** | [About the attack](#About-the-attack)
 6 | **2** | [Scenario](#Scenario)
 7 | **3** | [How to test](#How-to-test)
 8 | **3.1** | [Steps](#Steps)
 9 | **4** | [What can be achieved](#What-can-be-achieved)
10 | **5** | [How to test](#How-to-test)
11 | **6** | [Practice](#Practice)
12 | **7** | [References](#References)
13 | ___
14 | 
15 | ### About the attack
16 | ```
17 | Occurs when an app allows a user to manually add parameters in an HTTP Request & the app process value of these parameters when processing the HTTP Request & it affects the response that is returned to the user. 
18 | ```
19 | 
20 | 
21 | ### Scenario
22 | #### Original Request
23 | ```
24 | POST /userinfo
25 | <redacted>
26 | 
27 | username=harsh
28 | ```
29 | #### Response
30 | ```
31 | 200 OK 
32 | <redacted>
33 | 
34 | username=harsh&isadmin=false&email=harsh@harshbothra.tech
35 | ```
36 | 
37 | #### Modified Request 
38 | ```
39 | POST /userinfo
40 | <redacted>
41 | 
42 | username=harsh&isadmin=true
43 | ```
44 | 
45 | #### Response of Modified Request
46 | ```
47 | 200 OK 
48 | <redacted>
49 | 
50 | username=harsh&isadmin=true&email=harsh@harshbothra.tech
51 | ```
52 | 
53 | ***Now consider the above example where an attacker observes normal request/response flow and notice there is a parameter called isadmin which is set to false.***
54 | 
55 | ***The attacker tries to send "isadmin" with the value true in the HTTP request and as a result, in response, the "isadmin" parameter is now true and the normal user is now an admin user.***
56 | - This is a simple example of Mass Assignment Vulnerability.
57 | 
58 | ### How to Test
59 | ```
60 | Depending on the language/framework this issue has different names: 
61 | - Mass Assignment: Ruby on Rails, NodeJS.
62 | - Auto binding: Spring MVC, ASP NET MVC.
63 | - Object injection: PHP.
64 | ```
65 | #### Steps
66 | - Capture the Request and Observe its response.
67 | - Include the parameters present in Response to the HTTP Request with the modified values.
68 | - Observe if the values in response are changed as Modified values.
69 | - Navigate to the application and observe if the changes are also reflected on the UI level.
70 | 
71 | 
72 | ### What can be achieved
73 | - Authentication Bypass (2FA) - Adding "Success":true parameter in the request with the wrong OTP.
74 | - Privilege Escalation - Changing the Role/Access Level.
75 | - Modifying/Overwriting Sensitive Information.
76 | - Client-Side/Server-Side validation might be missing in the parameters that are not editable by the user from the UI level and if can be abused through mass assignment, it can lead to exposure to some serious issues.
77 | - Premium Feature Abuse/Bypass Payment Restrictions.
78 | 
79 | 
80 | ### Practice
81 | 
82 | - https://owasp-skf.gitbook.io/asvs-write-ups/kbid-147-parameter-binding
83 | 
84 | ### References
85 | - https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html
86 | - https://virtuesecurity.com/kb/api-mass-assignment/
87 | - https://itzone.com.vn/en/article/mass-assignment-vulnerability-and-prevention/
88 | - https://hackerone.com/reports/99424
89 | 


--------------------------------------------------------------------------------
/days/day4.md:
--------------------------------------------------------------------------------
 1 | # Unauthenticated & Exploitable JIRA Vulnerabilities 
 2 | 
 3 | ### [Mindmap](https://www.xmind.net/m/Jrn7f8/)
 4 | 
 5 | Index | Technique
 6 | --- | ---
 7 | **1** | CVE-2020-14179 (Information Disclosure)
 8 | **2** | CVE-2020-14181 (User Enumeration)
 9 | **3** | CVE-2020-14178 (Project Key Enumeration)
10 | **4** | CVE-2019-3402 (XSS)
11 | **5** | CVE-2019-11581 (SSTI)
12 | **6** | CVE-2019-3396 (Path Traversal)
13 | **7** | CVE-2019-8451 (SSRF)
14 | **8** | CVE-2019-8449 (User Information Disclosure)
15 | **9** | CVE-2019-3403 (User Enumeration)
16 | **10** | CVE-2019-8442 (Sensitive Information Disclosure)
17 | **11** | Tools
18 | **12**| Reports
19 | 
20 | ___
21 | #### CVE-2019-8442 (Sensitive Information Disclosure)
22 | ```
23 | a. Navigate to <JIRA_URL>/secure/QueryComponent!Default.jspa
24 | b. It leaks information about custom fields, custom SLA, etc.
25 | 
26 | ```
27 | 
28 | #### CVE-2020-14181 (User Enumeration)
29 | 
30 | ```
31 | a. Navigate to <JIRA_URL>/secure/ViewUserHover.jspa?username=<uname>
32 | 
33 | ```
34 | 
35 | #### CVE-2020-14178 (Project Key Enumeration)
36 | 
37 | ```
38 | a. Navigate to <JIRA_URL>/browse.<project_key>
39 | b. Observe the error message on valid vs. invalid project key. Apart from the Enumeration, you can often get unauthenticated access to the project if the protections are not in place.
40 | 
41 | ```
42 | 
43 | #### CVE-2019-3402 (XSS)
44 | ```
45 | a. Navigate to <JIRA_URL>/secure/ConfigurePortalPages!default.jspa?view=search&searchOwnerUserName=%3Cscript%3Ealert(1)%3C/script%3E&Search=Search
46 | 
47 | ```
48 | 
49 | #### CVE-2019-11581 (SSTI)
50 | 
51 | ```
52 | a. Navigate to <JIRA_URL>/secure/ContactAdministrators!default.jspa
53 | ```
54 | #### CVE-2019-3396 (Path Traversal)
55 | 
56 | #### CVE-2019-8451 (SSRF)
57 | 
58 | ```
59 | a.  Navigate to <JIRA_URL>/plugins/servlet/gadgets/makeRequest?url=https://<host_name>:1337@example.com
60 | ```
61 | 
62 | #### CVE-2019-8449 (User Information Disclosure)
63 | ```
64 | a. Navigate to <JIRA_URL>/rest/api/latest/groupuserpicker?query=1&maxResults=50000&showAvatar=true
65 | b. Observe that the user related information will be available.
66 | ```
67 | 
68 | #### CVE-2019-3403 (User Enumeration)
69 | ```
70 | a.  Navigate to <Jira_URL>/rest/api/2/user/picker?query=<user_name_here> 
71 | b.  Observe the difference in response when valid vs. invalid user is queried.
72 | ```
73 | #### CVE-2019-8442 (Sensitive Information Disclosure)
74 | ```
75 | a.  Navigate to <JIRA_URL>/s/thiscanbeanythingyouwant/_/META-INF/maven/com.atlassian.jira/atlassian-jira-webapp/pom.xml
76 | b. Observe that the pom.xml file is accessible.
77 | ```
78 | #### Tools
79 | 
80 | [Nuclei Template](https://github.com/projectdiscovery/nuclei-templates/blob/master/workflows/jira-workflow.yaml) can be used to automate most of these CVEs Detection.
81 | 
82 | #### Reports
83 | * [https://hackerone.com/reports/632808](https://hackerone.com/reports/632808)
84 | * [https://hackerone.com/reports/1003980](https://hackerone.com/reports/1003980)
85 | #### Blog
86 | [How i converted SSRF TO XSS in jira.](https://medium.com/@D0rkerDevil/how-i-convert-ssrf-to-xss-in-a-ssrf-vulnerable-jira-e9f37ad5b158)
87 | 
88 | 
89 | 


--------------------------------------------------------------------------------
/days/day3.md:
--------------------------------------------------------------------------------
 1 | # SAML Vulnerabilities
 2 | Security Assertion Markup Language) is widely used for authentication. \
 3 | It uses XML schema and is prone to multiple security vulnerabilities. \
 4 | Some of the common security issues are
 5 | 
 6 | Index | Technique
 7 | --- | ---
 8 | **1** | Signature Wrapping (XSW) Attacks
 9 | **2** | XML Attacks
10 | **3** | SAML Message Integrity Abuse
11 | **4** | Missing / Invalid Signature
12 | **5** | SAML Message Replay
13 | **6** | CSRF
14 | **7** | XML Comment Handling
15 | **8** | XSLT
16 | **9** | Token Recipient Confusion
17 | **10** | Labs & Resources
18 | **11** | Report
19 | ___
20 | #### Signature Wrapping (XSW) Attacks
21 | ```
22 | XSW Attacks happen when the XML Digital Signature (XML DSig) is not validated which is used to establish a trust b/w IDPs & Service Providers.
23 | 
24 | This attack can lead to situations like Privilege Escalation, Authentication Abuse & Denial of Service as well.
25 | 
26 | Resource:
27 | https://research.aurainfosec.io/bypassing-saml20-SSO/
28 | 
29 | Burp Extention:
30 | SAML Raider
31 | 
32 | 
33 | There are multiple variants of XSW attacks from XSW1 to XSW8 (Way of exploitation varies a bit). You can read more about them here in little details
34 | 
35 | https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/SAML%20Injection/README.md
36 | ```
37 | 
38 | #### XML Attacks
39 | 
40 | ```
41 | Due to the improper input validation and DTD processing
42 | The SAML implementation might be Vulnerable to XXE and XML DoS Attacks like Billian Laugh Attack.
43 | ```
44 | #### SAML Message Integrity Abuse
45 | ```
46 | Using the SAML Message from other users or forged SAML message to bypass the restriction or may lead to bypass the authentication
47 | ```
48 | #### Missing / Invalid Signature
49 | ```
50 | Missing or Invalid Signature may allow an attacker to forge a signature and abuse the implementation
51 | ```
52 | #### SAML Message Replay
53 | ```
54 | Assertion ID should be unique and one ID should be accepted only once.
55 | ```
56 | ### CSRF
57 | ```
58 | Due to improper validation it is possible to carry out CSRF in SAML Implementation
59 | ```
60 | #### XML Comment Handling
61 | ```
62 | A threat actor who already has authenticated access into an SSO system can authenticate as another user without that individual’s SSO password
63 | ```
64 | #### XSLT
65 | ```
66 | XSLT (eXtensible Stylesheet Transformation Language) Attack can also be leverage against SAML Implementation
67 | ```
68 | #### Token Recipient Confusion
69 | ```
70 | Attacker Token is used to login to Victim Account.
71 | ```
72 | #### Labs & Resources
73 | 
74 | * https://research.aurainfosec.io/bypassing-saml20-SSO/
75 | * https://github.com/yogisec/VulnerableSAMLApp
76 | * https://github.com/dogangcr/vulnerable-sso
77 | * http://sso-attacks.org/Category:Attack_Categorisation_By_Attack_on_SAML
78 | * https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/
79 | * https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/
80 | * https://epi052.gitlab.io/notes-to-self/blog/2019-03-16-how-to-test-saml-a-methodology-part-three/
81 | * https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/SAML_Security_Cheat_Sheet.md
82 | 
83 | #### Report
84 | 
85 | * https://hackerone.com/reports/888930
86 | * https://hackerone.com/reports/812064
87 | 


--------------------------------------------------------------------------------
/days/day10.md:
--------------------------------------------------------------------------------
 1 | # Abusing Hop-by-Hop Headers
 2 | 
 3 | Hop-by-hop headers, which are meaningful only for a single transport-level connection, and are not stored by caches or forwarded by proxies. 
 4 | 
 5 | Index | Section
 6 | --- | ---
 7 | **1** | What is Hop-by-Hop Headers
 8 | **2** | Attack Description
 9 | **3** | Working of the Attack
10 | **4** | Attacks by Abusing Hop-by-Hop Header
11 | **5** | Practice & Tools
12 | ___
13 | #### What is Hop-by-Hop Headers
14 | ```
15 | Hop-by-hop headers are meaningful only for a single transport-level connection, and are not stored by caches or forwarded by proxies.
16 | Only H-b-H headers may be set using the Connection header.
17 | 
18 | The following HTTP/1.1 headers are H-b-H headers:
19 |       - Connection
20 |       - Keep-Alive
21 |       - Proxy-Authenticate
22 |       - Proxy-Authorization
23 |       - TE
24 |       - Trailers
25 |       - Transfer-Encoding
26 |       - Upgrade
27 | 
28 | All other headers defined by HTTP/1.1 are end-to-end headers.
29 | A request may also define a custom set of headers to be treated as hop-by-hop by adding them to the Connection header
30 | 
31 | like so:
32 | "Connection: close, X-Foo, X-Bar"
33 | ```
34 | #### Attack Description
35 | ```
36 | 1. Removing header from HTTP Req isn't an issue itself but being able to remove headers that weren't in the original req but were added by either the frontend or another proxy in the chain could create unexpected results.
37 | 
38 | 2. The Connection header itself is the default hop-by-hop header. This implies that a compatible proxy server should not forward a list of custom hop-by-hop headers to the next server in the chain in its Connection header when it forwards the request.
39 | 
40 | 3. In practice this does not always occur, some systems either forward the entire Connection header/copy the H-b-H list & add it to their own Connection header. Ex most likely HAProxy passes the Connection header untouched, the same behavior with Nginx in reverse proxy mode
41 | ```
42 | #### Working of the Attack
43 | ```
44 | 1. Suppose an application requires Cookie Headers in order to process a request and allow the user to access the target host.
45 | 
46 | 2. Now, to test the H-b-H Header abuse, assume the Attacker includes a modified connection header in the HTTP Req.
47 | 
48 | 3. The goal here to add the "Cookie" header name in the connection header is to ask the proxy to forward the request with Cookie Headers and then somewhere in intermediate proxy to drop this cookie header and forward the request without cookie header.
49 | 
50 | 4. When the request reaches the final source, it will not contain the cookie headers and if the app is vulnerable to H-b-H Header abuse attack, the attacker will be able to access the endpoint w/o the need to have a valid user's cookie or may give some unexpected results.
51 | ```
52 | #### Attacks by Abusing Hop-by-Hop Header
53 | ```
54 | 1. Fingerprinting Services
55 | 2. Accessing Authenticated Endpoint or Protected Information 
56 | 3. Masking the Source IP 
57 | 4. Cache Poisoned Denial of Service (CPDoS)
58 | 5. SSRF
59 | 6. WAF Bypass
60 | ```
61 | #### Practice & Tools
62 | ```
63 | https://github.com/mrtc0/abusing-hop-by-hop-header
64 | 
65 | https://gist.github.com/ndavison/298d11b3a77b97c908d63a345d3c624d
66 | 
67 | - One liner to test: 
68 | for HEADER in $(cat headers.txt); do python http://poison-test.py -u "https://target" -x "$HEADER"; sleep 1; done
69 |  
70 | - List of Headers:
71 | https://github.com/danielmiessler/SecLists/blob/master/Discovery/Web-Content/BurpSuite-ParamMiner/lowercase-headers
72 | 
73 | https://0xn3va.gitbook.io/cheat-sheets/web-application/abusing-http-hop-by-hop-request-headers
74 | 
75 | https://nathandavison.com/blog/abusing-http-hop-by-hop-request-headers
76 | ```


--------------------------------------------------------------------------------
/days/day7.md:
--------------------------------------------------------------------------------
 1 | #  Cross-Site Script Inclusion (XSSI)
 2 | Index | Section
 3 | --- | ---
 4 | **1** | Cross-Site Script Inclusion (XSSI)
 5 | **2** | Types of XSSI
 6 | **3** | Exploiting Authenticated Static JS & Dynamic JS
 7 | **4** | Some Interesting Attacks Descibed in OWASP Testing Guide using XSSI
 8 | **5** | Labs 
 9 | **6** | Tools
10 | **7** | References
11 | ___
12 | 
13 | #### What is Cross-Site Leaks
14 | 
15 | ```
16 | 1. XSSI is a different attack vector than XSS. In XSS, the payload is included on the victim to perform an action. However, In case of XSSI the victim's code (JS) is embedded in the attacker controlled page. 
17 | 
18 | 2. In XSSI, the goals is to usually steal the data bypassing the restrictions such as Same Origin Policy (SOP)
19 | 
20 | 3. XSSI is less utilized and I personally never paid much attention to this attack vector. However, this seems to be an interesting and realistic, easy to exploit attack vector. 
21 | 
22 | 4. This attack is to mainly target the sensitive information that might get dynamically stored in the javascript files when a user perform some activity. If there are not proper restrictions set, an attacker can easily read and get hold of sensitive information. However, this can also be utilized to steal other information such as authentication tokens.
23 | 
24 | ```
25 | 
26 | #### Types of XSSI
27 | 
28 | ```
29 | There are mainly Four Situations when it comes to XSSI attack: 
30 | 
31 | 1. Regular XSSI - Static Javascript
32 | - This is similar to looking for the hardcoded data in a javascript file.
33 | - Since the javascript file is static, an attacker can try to embed it a page in order to extract information. 
34 | 2. Authenticated Access to Static Javascript
35 | 3. Dynamic Javascript
36 | 4. Non-Script Attack
37 | ```
38 | 
39 | #### Exploiting Authenticated Static JS & Dynamic JS
40 | 
41 | ```
42 | 1. In case of Dynamic JS, the sensitive information is added to the Javascript file when the user performs an action. 
43 | 2. In Order to test this:
44 | 	A. Perform an action with authenticated user.
45 | 	B. Perform the same action with unauthenticated user.
46 | 	C. Compare the content of JS files included in the response in both cases. If there is difference it may give an idea of dynamic JS being used. 
47 | 3. To Automatically detect this attck: 
48 | 	A. Use Detect DynamicJS Burp Plugin
49 | 		a. This works on the same principle. Passively scanning all JS files and than scanning those files without authentication identifier like cookies. 
50 | 		b. If issue is found, it will be seen under Target Tab as Informational severity finding. 
51 | ```
52 | 
53 | 
54 | #### Some Interesting Attacks Descibed in OWASP Testing Guide using XSSI
55 | 
56 | ```
57 | 1. Sensitive Data Leakage via Global Variables
58 | 2. Sensitive Data Leakage via Global Function Parameters
59 | 3. Sensitive Data Leakage via CSV with Quotations Theft
60 | 4. Sensitive Data Leakage via JavaScript Runtime Errors
61 | 5. Sensitive Data Leakage via Prototype Chaining Using 'this'
62 | 
63 | ```
64 | 
65 | #### Labs 
66 | 
67 | ```
68 | 1. https://google-gruyere.appspot.com/part3
69 | ```
70 | 
71 | #### Tools 
72 | 
73 | ```
74 | 1. https://github.com/luh2/DetectDynamicJS
75 | ```
76 | 
77 | #### References
78 | 
79 | ```
80 | a.https://www.scip.ch/en/?labs.20160414
81 | b. http://sebastian-lekies.de/leak/
82 | c. https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/11-Client_Side_Testing/13-Testing_for_Cross_Site_Script_Inclusion.html
83 | d. https://www.mbsd.jp/Whitepaper/xssi.pdf
84 | e. https://medium.com/bugbountywriteup/effortlessly-finding-cross-site-script-inclusion-xssi-jsonp-for-bug-bounty-38ae0b9e5c8a
85 | f. https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-lekies.pdf
86 | 
87 | ```
88 | 


--------------------------------------------------------------------------------
/days/day11.md:
--------------------------------------------------------------------------------
 1 | #  Cache Poisoned Denial of Service (CPDos)
 2 | 
 3 | 
 4 | Index | Section
 5 | --- | ---
 6 | **1** | What is CPDos
 7 | **2** | Working
 8 | **3** | Types of CPDoS Attacks
 9 | **4** | HTTP Header Oversize
10 | **5** | HTTP Meta Characters (HMC)
11 | **6** | HTTP Method Override Attack
12 | **7** | References & Reports
13 | ___
14 | #### What is CPDos
15 | ```
16 | One of a kind of Web Cache Poisoning attack that affects the resources used by an application to create a denial of service situation.
17 | 
18 | AIO Resource: https://cpdos.org 
19 | ```
20 | #### Working
21 | ```
22 | The working of this attack is theoretically very simple to understand:
23 | 
24 | 1. The attacker sends a request to the server containing a malicious header with a malicious value. This can be any random header. 
25 | ex: x-mal-example: tohackthehacker
26 | 
27 | 2. This request is first processed by the intermediate cache server to check if the copy exists. 
28 | 
29 | 3. The cache server forwards the attacker's request with malicious headers to the origin server as it doesn't store a fresh copy of the requested resource.
30 | 
31 | 4. At the origin server, when this request comes, due to a malformed req bcz of a malicious header, the origin server returns an error page back to the intermediate cache server. 
32 | 
33 | 5. The cache server stores this error page considering it as a fresh copy of the req resource
34 | 
35 | 6. Whenever someone visits this page next after the cache is poisoned they are presented with the error page/message instead of original content.
36 | This issue doesn't affect the integrity of the origin server but the cache server is fooled to store an invalid page that is served to the legitimate user making the original content unavailable.
37 | ```
38 | #### Types of CPDoS Attacks
39 | ```
40 | 1. HTTP Header Oversize (HHO)
41 | 2. HTTP Meta Character (HMC)
42 | 3. HTTP Method Override (HMO)
43 | 
44 | - It is possible to perform a CPDoS attack by abusing Hop-by-Hop Headers.
45 | ```
46 | #### HTTP Header Oversize
47 | ```
48 | The HTTP Standard hasn't defined any size limit for the HTTP Request Headers. This thing can be utilized by an attacker to perform a multitude of attacks. This is the base for HHO based CPDoS Attack.
49 | 
50 | - HHO CPDoS attacks work in scenarios where a web app uses a cache that accepts a larger header size limit than the origin server.
51 | 
52 | - A malicious client sends an HTTP GET request including a header larger than the size supported by the origin server but smaller than the size supported by the cache.
53 | 
54 | - Working is similar to the above-described method, however, the header is sent like this: 
55 | X-Oversized-Header-x: Big_Value 
56 | 
57 | - Upon receiving this the origin server will not be able to handle this and will return with Header Size Exceeded message which will be cache and displayed to the end-user.
58 | ```
59 | #### HTTP Meta Characters (HMC)
60 | ```
61 | This is again a similar technique the only difference is that in a malicious header, you send some harmful meta characters such as \n \r \a, etc.
62 | 
63 | - The origin server will not process these characters and may throw an error like character not allowed which will be presented to the victim user.
64 | 
65 | - The malicious header can be like this: 
66 | X-Meta-Malicious-Header: \r\n
67 | ```
68 | #### HTTP Method Override Attack
69 | ```
70 | There are several headers present in HTTP Standard that allow modifying overriding the original HTTP header as the request goes forward through proxies before reaching the origin server. Some of these headers are:
71 | 
72 | 1. X-HTTP-Method-Override
73 | 2. X-HTTP-Method
74 | 3. X-Method-Override
75 | 
76 | When these headers are supplied and supported, the header instructs the application to override the HTTP method in request to the header mentioned in these headers upon reaching the Origin Server.
77 | 
78 | This can be abused to perform a Cache Poisoned Denial of Service Attack. The steps to perform the attack are the same, only the used HTTP headers change. 
79 | 
80 | - The malicious header will look like this: 
81 | 
82 | X-HTTP-Method-Override: DELETE
83 | 
84 | - Now if the origin server doesn't support the DELETE method, it will return with Method Not Supported error which will be stored at intermediate cache & will be displayed to the legitimate users.
85 | ```
86 | #### References & Reports
87 | ```
88 | 1. https://hackerone.com/reports/409370
89 | 2. https://hackerone.com/reports/728664
90 | 3. https://hackerone.com/reports/921704
91 | 4. https://hackerone.com/reports/326639
92 | 5. https://hackerone.com/reports/591302
93 | ```


--------------------------------------------------------------------------------
/days/day6.md:
--------------------------------------------------------------------------------
  1 | #  Cross-Site Leaks (XS-Leaks)
  2 | Index | Section
  3 | --- | ---
  4 | **1** | What is Cross-Site Leaks
  5 | **2** | Cross-Site Oracle
  6 | **3** | A Simple Example
  7 | **4** | Attacks using XS-Leaks
  8 | **5** | XS-Search Exploitation Workflow
  9 | **6** | References
 10 | ___
 11 | #### What is Cross-Site Leaks
 12 | ```
 13 | 1. Cross-Site Leaks/XS-Leaks is a less explored security issue that usually comes from Side-Channel Attacks. 
 14 | 
 15 | 2. This basically utilizes the web's core principle of composability in order to determine & extract useful information. 
 16 | 
 17 | 3. XS-Leaks take advantage of small pieces of information which are exposed during interactions between websites.
 18 | 
 19 | ```
 20 | 
 21 | #### Cross-Site Oracle
 22 | ```
 23 | 1. This can be considered as a querying mechanism. The information used for this attack is of binary form and called Oracles. They usually have an answer of "Yes" or "No". You can say True or False. 
 24 | 
 25 | 2. For Example: Does User Harsh Exists in the Application. Yes, means that the user is there in the application. 
 26 | 
 27 | 3. An attacker requires to smartly form queries in order to successfully execute this attack and gain hold of sensitive information.
 28 | 
 29 | ```
 30 | 
 31 | #### A Simple Example 
 32 | ```
 33 | 
 34 | 1. Suppose that bank.com has an API endpoint that returns data about a user’s receipt for a given type of transaction.
 35 | 
 36 | 2. evil.com can attempt to load the URL bank.com/my_receipt?q=groceries as a script. By default, the browser attaches cookies when loading resources, so the request to bank.com will carry the user’s credentials.
 37 | 
 38 | 3. If the user has recently bought groceries, the script loads successfully with an HTTP 200 status code. If the user hasn’t bought groceries, the request fails to load with an HTTP 404 status code, which triggers an Error Event.
 39 | 
 40 | 4. By listening to the error event and repeating this approach with different queries, the attacker can infer a significant amount of information about the user’s transaction history.
 41 | 
 42 | ```
 43 | 
 44 | #### Attacks using XS-Leaks
 45 | 
 46 | ```
 47 | 1. XS-Search: An attacker try to abuse the query mechanism such as search functionality to leak and get hold of user's inforamtion.
 48 | 
 49 | 2. Error Events: Based on the Error Message returned by the application, it may be possible to enumerate sensitive information. This is similar to user enumeration techniques.
 50 | 
 51 | 3. Frame Counting: window.length which provides the number of frames in the window. This attribute can provide valuable information about a page to an attacker.
 52 | 
 53 | 4. Navigation Attacks: To detect if any kind of navigation occurred in order to know specific information about the victim. 
 54 | 
 55 | 5.  Cache Probing: Workes based on detecting whether the web page was cached or not.
 56 | 
 57 | 6. ID Attribute
 58 | 
 59 | 7. Post Message Broadcasts
 60 | 
 61 | 8. Abusing Browser Features Abusing Browser Features 
 62 |     - CORB (Cross-Origin Read Blocking)
 63 |     - CORP (Cross-Origin Resource Policy)
 64 | 
 65 | 9. Timing Attacks
 66 |     - Clock Based 
 67 |     - Network Timing
 68 |     - Execution Timing
 69 |     - Hybrid Timing 
 70 |     - Connection Pool
 71 | ```
 72 | 
 73 | 
 74 | #### XS-Search Exploitation Workflow
 75 | ```
 76 | 1.Define a timeline when there is a Hit (Success) vs There is a Failure (Miss)
 77 | 2. Start attacking the Querying Endpoint. 
 78 | 3. For Example: ?search=h (Throws a Hit)
 79 | search for the next word appended to `h` i.e. ?search=ha otherwise change the word i.e. ?search=b
 80 | 4. By this you can try to extract the complete info it that exist.
 81 | 
 82 | ```
 83 | 
 84 | #### References
 85 | 
 86 | ```
 87 | a. https://xsleaks.com/
 88 | b. https://arxiv.org/pdf/1908.02204.pdf
 89 | c. https://github.com/xsleaks/xsleaks/wiki/Browser-Side-Channels
 90 | d. http://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html
 91 | e. https://polict.net/blog/web-tracking-via-http-cache-xs-leaks/
 92 | f. https://hackerone.com/reports/723175
 93 | g. https://xsleaks.dev/category/attack/
 94 | h. https://owasp.org/www-community/attacks/Cross_Site_History_Manipulation_(XSHM)
 95 | i. https://portswigger.net/research/xs-leak-leaking-ids-using-focus
 96 | j. https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html
 97 | k. https://medium.com/@terjanq/massive-xs-search-over-multiple-google-products-416e50dd2ec6
 98 | l. https://owasp.org/www-pdf-archive/AppSecIL2015_Cross-Site-Search-Attacks_HemiLeibowitz.pdf
 99 | m. Reference: https://hackerone.com/reports/505424
100 | n. https://www.imperva.com/blog/facebook-privacy-bug/
101 | o. https://hackerone.com/reports/491473
102 | 
103 | ```
104 | 


--------------------------------------------------------------------------------
/days/day9.md:
--------------------------------------------------------------------------------
  1 | #  JSON Attacks
  2 | Index | Section
  3 | --- | ---
  4 | **1** | What is JSON and its Attack Surface
  5 | **2** | Interesting JSON Attacks
  6 | **3** | References
  7 | ___
  8 | #### What is JSON and its Attack Surface
  9 | ```
 10 | 1. JSON is widely used in modern web applications and often most of the API requests are observed using JSON as data type. Some applications use it for communicate data where some applications use it to store data. 
 11 | 
 12 | 2. Use of JSON is mostly observed in REST APIs and AJAX applications.
 13 | 
 14 | 3. JSON is however considered to be secure than traditional data exchange formats like text/plain but it also comes with multiple security issues if not implemented properly. 
 15 | 
 16 | 4. Most of the Server Side JSON attack happens when an attacker is able to supply untrusted data and the server without performing sanitization, writes it directly to JSON Stream. 
 17 | 
 18 | 5. On the other hand, In case of Client-Side JSON attacks are a result of user supplied data getting parsed using JavaScript eval() function without any sanitization. 
 19 | 
 20 | ```
 21 | 
 22 | #### Interesting JSON Attacks
 23 | ```
 24 | 1. JSON Deserialization Attack 
 25 | 
 26 | - It is possible to perform and exploit deserialization attack in JSON implementation. The following Research Paper is the goldmine to learn about it: https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf
 27 | 
 28 | 
 29 | 2. JSONP (JSON Padding) Attack
 30 | 
 31 | - I described this attack on Day-8 of Learn365, can be found in Day-8.MD 
 32 | 
 33 | 3. Brute-Forcing Attacks
 34 | 
 35 | - It is possible to perform attacks that fall under brute-force category such as testing for No Rate Limiting, Lockout Policy, etc. in JSON. The steps are similar to traditional web app approaches. 
 36 | 
 37 | 4. XXE 
 38 | 
 39 | - By changing the content-type to XML, it might be possible to perform XXE if the application doesn't sanitize and validate user supplied Input. 
 40 | 
 41 | # Steps: 
 42 | 
 43 |     1. Capture a Request with JSON Body
 44 |     2. Change content type to application/xml and insert a XML payload 
 45 |     3. Also, you can use Burp's Content Type Convertor plugin.
 46 |     4. Observe how application responds and perform attack based on response. 
 47 | 
 48 | 5. XSS
 49 | 
 50 | - The JSON implementation might be vulnerable to traditional XSS attacks if there is no input validation/sanitization in place. It's always a good idea to fuzz the application and try checking manually how application reacts on supplying different Payloads 
 51 | 
 52 | 6. Injection Attacks 
 53 | 
 54 | - Again, if there is a lack of input validation and application doesn't perform proper checks, it is possible to perform any sort of inject attacks such as SQL Injection, Command Injection, etc. based on how application works. 
 55 | 
 56 | - It's always a good idea to check how the application reacts upon supplying different payloads. 
 57 | 
 58 | 7. File Inclusion/File Read 
 59 | 
 60 | - If the application utilize a weakly implemented function that let a user read files, it can be abused to perform Local File Read. 
 61 | 
 62 | - For Ex: Original Request Body
 63 | 
 64 |     {"user":"admin", "path"="/admin.html"}
 65 | 
 66 | - If the path parameter is not getting validaed, it can be abused to perform local file read like: 
 67 | 
 68 |     {"user":"admin", "path"="../../../../../../../../../../../etc/passwd"}
 69 | 
 70 | 
 71 | 8. Broken Access Controls & Logical Issues 
 72 | 
 73 | - Similar to the other implementation, JSON implementation can also be vulnerable to BAC and other Logical Issues as this is more of the responsibility of developer to ensure how various logics and centralized checks are handled. 
 74 | 
 75 | 9. CSRF 
 76 | 
 77 | - It is possible to perform CSRF in JSON based implementation but it maybe tricky sometimes. 
 78 | 
 79 | # Example (Refered from websecgeeks.com)
 80 | 
 81 |     POST /site/getuserinfo HTTP/1.1
 82 |     Host: websecgeeks.com
 83 |     Content-Type: application/json;
 84 |     Cookie: test=test;
 85 | 
 86 |     {"id":"1","email":"attacker@attacker.com"}
 87 | 
 88 | 
 89 | - We can perform the CSRF for this request as mention below.
 90 |     <html>
 91 |     <form action="" method=post enctype="application/json" method="POST">
 92 |     <input name='{"id":"1","email":"attacker@attacker.com"}' type='hidden'>
 93 |     <input type=submit>
 94 |     </form>
 95 |     </html>
 96 | 
 97 | 10. JSON Hijacking Attack
 98 | 
 99 | - This looks similar to JSONP attacks but it different a way that application does not provide a convenient callback function. Instead, the attack relies on modifying native JS objects. However, this is not possible anymore in current browsers.
100 | 
101 | 11. Other Common Vulnerabilities that may affect JSON implementation:
102 | 
103 |     a. Mass Assignment
104 |     b. Open Redirection
105 |     c. Parameter Tampering 
106 |     d. Response Manipulation
107 |     e. Session Related Issues 
108 | 
109 | 12. Some Other Interesting JSON Attacks 
110 | (As described in the following paper: http://www.infosecwriters.com/Papers/ASood_ExploitingJSON.pdf) 
111 | 
112 |     a. String Defracturing Attack 
113 |     b. Malicious Hashing & Listing 
114 |     c. Fused Proxy Attack: Domain Crossing
115 |     d. JSON-XML Banner Grabbing
116 | 
117 | ```
118 | 
119 | 
120 | #### References
121 | 
122 | ```
123 | a. https://owasp.org/www-pdf-archive/Marshaller_Deserialization_Attacks.pdf.pdf
124 | b. https://www.websecgeeks.com/2015/10/attacking-json-application-pentesting.html
125 | c. https://medium.com/@koumudi.garikipati/json-based-xss-84089141c136
126 | 
127 | ```
128 | 


--------------------------------------------------------------------------------