#learn365 Day-31: Captcha Bypass Techniques

Captcha is widely adapted by the applications to avoid automated attempts on specific functionality, commonly on the Authentication forms to avoid brute-force attacks.

#bugbountytips #appsec #infosec #Pentesting

(1/n)
(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.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Harsh Bothra

Harsh Bothra Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @harshbothra_

30 Jan
#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
Read 7 tweets
29 Jan
#learn365 Day-29: Common Business Logic Issues (Part - 2)

(cont'd...)
5. Premium Feature Abuse
- Try forcefully browsing the areas or some particular endpoints which come under premium accounts.

#bugbountytips #AppSec #infosec #pentest

(1/n)
(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.
Read 8 tweets
28 Jan
#learn365 Common Business Logic Issues: Part-1

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.
Read 9 tweets
23 Jan
#learn365 Day-22: Password Reset Token Issues

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…
Read 8 tweets
21 Jan
#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.

#BugBountyTips #appsec #infosecurity

(1/n)
(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…

3. Insecure Direct Object Reference
- Similar to normal API like IDORs
- A good example: owasp-skf.gitbook.io/asvs-write-ups…
Read 4 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!