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.
(4/n) 2. Missing Captcha Field Integrity Checks
- There are multiple scenarios around this one, this happens when the application validates whether the captcha parameters are present but not the "value".
- Send an empty captcha parameter and see if the request works successfully.
(5/n)
- Change some specific characters of the captcha parameter and see if it is possible to bypass the restriction. This usually happens when only string length is validated at the server-side.
(6/n) 3. HTTP Verb Manipulation
- If a request with the POST method is using the Captcha, try changing the verb(method) from POST to GET and remove the captcha parameter.
- Often this bypasses the restrictions if the validation on the server-side are not in place.
(7/n) 4. Content Type Conversion
- Change the content type say from JSON to Plain Text and remove the captcha parameters to see if the request works successfully.
5. Reusuable Captcha
- Just repeat the request using the same Captcha key multiple times and see if that works.
(8/n)
- One of my weird findings was, Capture the Request in Burp Proxy and send it to Intruder. Hold the request in Proxy Tool don't let it go.
- Run the Intruder and observed that the same captcha can be reused any no. time until you drop off the original request from proxy.
(9/n) 6. Using HTTP Request Headers
- Using Headers such as X-Forwarded-For, X-Original-IP, etc. you can try to bypass the Captcha in some cases.
7. Some Other Techniques
- Automated Captcha Solving Techniques such as OCR Enabled Bots and Human-Based Captcha Solving Services.
#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.
I'll try to cover some of the interesting business logic flaws that I usually test and have encountered so far today & in the next couple of days. Feel free to add more if you know any. #bugbountytips#appsec#websecurity
(1/n)
(2/n)
1. Review Functionality
- Some applications have an option where verified reviews are marked with some tick or it's mentioned. Try to see if you can post a review as a Verified Reviewer without purchasing that product.
(3/n)
- Some app provides you with an option to provide a rating on a scale of 1 to 5, try to go beyond/below the scale-like provide 0 or 6 or -ve.
- Try to see if the same user can post multiple ratings for a product. This is an interesting endpoint to check for Race Conditions.
1. Weak Cryptography in Password Reset Tokens
- Always check randomness in password reset tokens. It is also a good idea to check password reset tokens against known schemes.
Ref: medium.com/bugbountywrite… #bugbountytips
(1/n)
(2/n) 2. Reusable Password Reset Tokens
- Use the token once and try to re-use it again.
- Request a new token and try if the old one is still active.
- Check how long a token stays alive. If it's >1 day and is reusable, you may report it.
(3/n) 3. IDOR (ATO)
- In the password reset link, assume there is something like this: harshbothra.tech/reset?token=so…
- try changing the value of the user parameter to the victim and see If the attack token can be used for resetting the victim's password. harshbothra.tech/reset?token=so…
Pentesting GraphQL may look hard if you are not familiar but there is still a lot to explore and exploit once you understand how it works. Today, It's all about continue reading and some good resources.
#learn365 Day-21: GraphQL Vulnerabilities (Part-2) 1. Information Disclosure via Error Messages
- Similar to the normal information disclosure via error triggering.
- Provide malformed or unexpected input within GraphQL queries.
(2/n)
- Sometimes you may observe verbose error messages revealing sensitive information.
2. GraphQL Denial of Service
- Due to an improper limit on the maximum query depth, it might be possible to perform a denial of service in graphql implementation.
(3/n)
- Nest a query to unlimited depth and send this query on a GraphQL endpoint to observe anything suspicious.
- A good example: owasp-skf.gitbook.io/asvs-write-ups…