What is Burp suite ~!
Burp suite Is an Application used for Monitoring the Requests From the User to The Website
By Using This You Can Find Bugs Like
Sql Injection ,
Otp Bypassing ,
Exif Data ,
Xml Injection ,
Remote Code Execution
Http Request Smuggling ,
Web cache poisoing
Web Cache Deception
Cookie Injection
Server Side Template Injection
Rate Limiting
IDOR
Why Burp suite is popularly used:
Burp suite is Popularly used By The Penetration Testers and Bug Hunters To Find The Bug In Their Websites and Protect their Website From The Malcious Hackers
What is a Bug ~?
Bug is know as a Flaw in a programming Caused by the Bad Programming and by Some Mistakes that are done by the Programmers While They Design The Website using The Flaw They Hack In their Websites It may Cause Huge Problems To The Website Owners Like Affecting The Users of The Website
Want TO Download the Burp suite Premium Version For Free and Free Licensing Refer This : Click Here
How To Find Bugs In the Website Using the Burp suite ?
You need To know the Networking like How the Websites Works and How the Http Requests are Sending From the Client to the Web Server
While The Requests are sending from the client Side To Server Side You can Modifie IT and may cause Vulneriblities in the Websites
What To Learn Bug Bounty Premium Course For Free Click Here To Download
Download Source : Google Drive
Here Are The Top Ten Vulneriblities in the 2021 as By The BugCrowd:
10 – REMOTE CODE EXECUTION
Remote Code Execution occurs when an attacker is able to execute code on a target system in a way that is unintended. It’s hard to believe how common Remote Code Execution (RCE) vulnerabilities have been so far this year. The tenth most-common, in fact! There are many different ways to achieve RCE, but some ideas are:
Abusing file upload functionality to upload a webshell
Deserialization bugs
Exploiting known CVEs
Command injection
9 – OPEN REDIRECT
Open redirect bugs occur when an attacker is able to redirect an unwitting user to an arbitrary URL. It usually comes in the form of specifying a URL within a parameter, where the application will redirect to. As a basic example, if the “url” parameter on example.com was vulnerable to an open redirect, the following URL might redirect to https://example.com.
https://example.com?url=https://powerfulethic.blogspot.com/
In a real attack scenario, an adversary might use this to host a phishing page to steal sensitive information, but overall this would require extensive user-interaction and social engineering, so without a chain, open redirects tend to be P4 priority.
Why are these so common? Because validating URLs is much harder than it seems.
A great resource for Open Redirect payloads, bypasses and techniques is https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Open%20Redirect.
8 – CROSS-SITE REQUEST FORGERY (CSRF)
CSRF occurs where the user’s browser is tricked into performing unwanted actions on a vulnerable application. This is usually exploited by hosting malicious JavaScript payload on any attacker-controlled website and then convincing the user to navigate to it.
The JavaScript crafts a request to the vulnerable application that performs a sensitive request on the user’s account. The application accepts the request and performs the action, because no CSRF countermeasures were in place.
It’s difficult to understand why CSRF is still so common, there are many protections that can be implemented easily both at an application level and at a server level. Alas, they are still being found every day, and are often quite severe.
7 – AUTHENTICATION BYPASS
Authentication bypasses come in many forms. In recent years, authentication flows have become more complex in nature with the advent of SSO and third-party logins. Many applications now offer multiple forms of authentication, which can sometimes interfere with each other in unexpected ways. The implementation of these login methods require multiple steps and security considerations – each presenting an opportunity for exploitation.
To find these bugs, study up on OAuth, SSO, SAML, and other authentication flows. For the best understanding, try creating your own application using these flows! This will give you an excellent understanding of how these flows are supposed to work, so that you can spot inconsistencies more easily.
6 – SENSITIVE INFORMATION PASSED TO HTTP BY DEFAULT
This is quite a simple one – it occurs when sensitive information such as passwords or session tokens are passed over cleartext HTTP instead of encrypted HTTPS. When this occurs, a well-placed attacker (man-in-the-middle) would be able to view the traffic in cleartext and use the sensitive information to their advantage.
According to our VRT, this type of vulnerability is usually a P4. It’s important to note that this is extremely easy to detect, which means that it will nearly always be a duplicate.
5 – PRIVILEGE ESCALATION
This is quite a generic bug class. It refers to any vulnerability that allows an attacker to gain higher privileges than they should be allowed. Some have argued that this bug class is so general that it covers almost every other bug class, which is true!
Privilege escalation comes in many different forms but most instances I’ve seen are closely related to access control bypasses. For example, a lower privileged user will be able to send a “create user” request and specify that the new user should be an administrator.
4 – BROKEN ACCESS CONTROL (INCLUDING IDOR)
Again, “broken access control” is a generic term that we use to define any bug where a user is able to perform a function that should not be allowed to them. The most common example of this is Insecure Direct Object Reference (IDOR), where sensitive objects or functions can be accessed directly by people who should not have access. As a quick example, let’s say that we have an API endpoint that allows you to view your bank balance:
https://example.com/bankbalance/11111
The “11111” is some kind of identifier for the user (such as an account number). In this case, a user should only be able to access their own bank balance, not the balance of other users. If we were able to access the following URL:
https://example.com/bankbalance/22222
And the bank balance of user 22222 was returned – this would be considered an IDOR vulnerability. Time to report!
3 – SUBDOMAIN TAKEOVER
So you thought subdomain takeovers didn’t exist anymore? I’ve got news for you! They’re everywhere! Every time an organization updates a DNS record, or removes a third party service, or lets a domain expire, there is potential for a subdomain takeover to exist. As you can imagine, this happens very regularly – especially in larger organizations.
For more information on subdomain takeovers, how to find them, and how to exploit them, my favourite resource is Patrik Hudak’s blog, start here (https://0xpatrik.com/subdomain-takeover-basics/). Another valuable resource is EdOverflows’s “Can I Takeover XYZ?” repository, which lists a bunch of services, and whether they are vulnerable to subdomain takeovers: https://github.com/EdOverflow/can-i-take-over-xyz. Finally, checkout codingo’s video on the topic: https://www.youtube.com/watch?v=q_A8aXLO1gA.
2 – CROSS-SITE SCRIPTING
Cross-Site Scripting (XSS) is said to be discovered back in 2005 by Amit Klein. Sixteen years later, they’re still everywhere! This is because as a developer, mitigating against XSS is often a confusing task. Firstly there are three main types of XSS; stored, reflected and DOM based. Then there are many different contexts in which the injection might be reflected (e.g. in the base HTML, within script tags, within HTML attributes, in the <head> vs. <body>, in a file upload) each of these contexts requires different escaping/encoding.
There are many different ways to discover XSS vulnerabilities. Basic XSS bugs can often be discovered using automated scanners such as Burp’s active scan but due to the highly dynamic nature of XSS vulnerabilities, many of them can only be discovered through manual analysis.
1 – SENSITIVE DATA EXPOSURE
Sensitive data exposure refers to a bug where some type of sensitive data (secret keys, PII, passwords, Usernames etc.) are accessible in a way that they shouldn’t be.
There are so many ways that this can happen, but some of the most common scenarios are:
- Unsecured S3 buckets
- Secret keys in client-side JavaScript
- Passwords and secret keys in public Github repositories
- Internal documentation exposed to the internet inadvertently
That just about sums it up! I really hope that this will help to focus your hunting efforts and get more bounties.
Happy hacking!
To Know More Like Join Our Telegram Channel Here: Click Here To Join
0 Comments