Premium Features are not widely tested by the crowd due to the involvement of a purchase factor. However, the person who often invests in the premium account is less likely to go disappointed.
(1/n)🧵
Below is my methodology to test for the Premium features:
[Without Purchase] 1. Fuzzing the API endpoints to find out the endpoints that are accessible to premium users.
(2/n)
2. Comparing the difference in the freemium vs premium accounts and creating a threat map of functionalities available in the premium account to make sure if it's really worth an investment.
(3/n)
3. Next, Checking the profile update functionality and if there is any "Response Parameters" such as "isSubscribed", trying to use mass assignment attack to gain premium features for free using the "Freemium Account".
(4/n)
4. Checking for the trial membership & trying to abuse the business logic to always re-issue the trial membership once finished (typically a 7 day membership is offered). 5. Performing recon to find some API docs that may involve the API calls accessible to premium user.
(5/n)
(6/n)
6. Some applications use true-false request/response values to validate if a user is having access to premium features or not. Try using Burp's Match & Replace to see if you can replace these values whenever you browse the app & access the premium features.
(7/n)
[After Purchase] 1. Pay for a premium feature & cancel subscription. If you get a refund but the feature is still usable, its an issue. 2. Always check cookies or local storage to see if any variable is checking if the user should have access to premium features or not.
(8/n) 3. Generating a site-map with the premium user and comparing it with the freemium user to find new endpoints. 4. Checking for privilege escalation attacks between these two users manually as well as using extensions such as Autorize.
(9/n) 5. Checking for payment gateway flows and payment tampering.
Feel free to add more techniques if you know some!
Many applications in iOS platform provides a functionality to enable touch/face ID to act as an added layer of protection to the application. However, it is possible to bypass this layer.
(1/n)
(2/n)
If the attack has "physical access" to the device, there are multiple options to bypass the checks, however, one of the simplest methods is to use "Objection".
Before, performing the attack ensure that the Frida is running. Also, the Objection must be installed.
(3/n)
# How to perform the attack:
1. Run the following command: objection --gadget <package_name_here> 2. In the objection run following command: ios ui biometrics_bypass
#SecurityExplained S-5: Bypassing Privileges & Other Restrictions with Mass Assignment Attacks.
As per OWASP's definition: Software frameworks sometimes allow developers to automatically bind HTTP request parameters into program code variables or ...
(1/n)
objects to make using that framework easier on developers. Attackers can sometimes use this methodology to create new parameters that the developer never intended which in turn creates or overwrites new variable or objects in program code that was not intended.
(2/n)
(3/n)
There are multiple attacks that can be executed by exploiting this vulnerability such as escalating privileges, bypassing business logic, manipulating payloads and bypassing client-side checks.
The below thread contains an overview of my pentesting methodology on the web application targets:
1. Initially, before starting with the engagement, I start with "Scoping" .........
(1/n)
(2/n)
where I go through the details shared by the client to understand the scope and see if the testing is feasible as per the given timeline. During this phase, I also check if the application is accessible and credentials (if required) are working properly.
(3/n)
If any of the things from "Step-1" are blocking, I reach out to the concerned person and request to unblock the blocking items. 2. Next, I start browsing the application while letting the traffic flow through Burp Suite to populate the "Target" menu.
Captcha is widely adapted by the applications to avoid automated attempts on specific functionality, commonly on the Authentication forms to avoid brute-force attacks.
(2/n)
However, it is possible to bypass Captcha, and sometimes if the function is critical, it can be paid well in terms of bounties.
1. Missing Server-Sides Validation
- Some apps send Captcha Parameters on the client-side but they do not validate this on the server side.
(3/n)
- Simply, Remove the "Captcha" parameters and see if the request is processed successfully.
- If yes, you can now use this request to perform your brute-force or rate-limiting attempts.
#learn365 Day-30: Common Business Logic Issues (Wrap)
(Cont'd...) 9. Parameter Tampering
- Tamper Payment or Critical Fields to manipulate their values
- Add multiple fields or unexpected fields by abusing HTTP Parameter Pollution & Mass Assignment #bugbountytips#appsec
(1/n)
(2/n)
- Response Manipulation to bypass certain restrictions such as 2FA Bypass
10. App Implementation Logic Abuse
- If an app accepts JSON data, try changing content type to XML and see if the XML data is being processed, it can be left vulnerable to XXE or XML-based attacks.
(3/n)
- If an application is using the DELETE method to delete a resource but there is no CSRF protection, try converting the method to GET/POST and add an additional parameter like ?method=delete
(2/n)
- Pay for a premium feature and cancel your subscription. If you get a refund but the feature is still usable, it's a monetary impact issue.
- Some applications use true-false request/response values to validate if a user is having access to premium features or not.
(3/n)
- Try using Burp's Match & Replace to see if you can replace these values whenever you browse the app & access the premium features.
- Always check cookies or local storage to see if any variable is checking if the user should have access to premium features or not.