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…
(4/n) 4. Lack of Random Generation in Password Reset Token
- Request multiple passwords reset tokens.
- If all the requested tokens are identical, it is confirmed that some Identifier is crypted to generate a password reset token.
- Try guessing the crypto else still an issue.
(5/n) 5. Weak/Small Password Reset Token is used
- If a password reset token used by the application is weak/small/guessable, it can be brute-forced.
(6/n) 6. Password Reset Token not Validated
- Navigate to the password reset link and remove the token parameter or send only empty values.
- Only keep the user identifier and change that to the victim user's identifier
- See if it is possible to change the password.
(7/n) 7. Excessive Information in JWT Based Password Reset Token
- If the password reset token is JWT Based, check for the following:
a. If there is any excessive info, it may contain an old password (never seen but you never know)
b. Make sure that asymmetric algo is used.
(n/n)
Some of the Broken Cryptography & Account Takeover Related methods are discussed in some of my talks, you can find them here:
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…
#learn365 Day-20: GraphQL Series Part - 1
- GraphQL is a query language for the underlying API.
- A single endpoint can be used as a query API to perform all the actions including Create, Read, Update & Delete.
(2/n)
- GraphQL has its own type of system that’s used to define the schema of an API. The syntax for writing schemas is called Schema Definition Language (SDL).
# A GraphQL operation can be of type: 1. query (a read-only fetch) 2. mutation (a write followed by fetch)
(3/n) 3. subscription (a long‐lived request that fetches data in response to source events.)
- A GraphQL document can contain one or more of these operations (i.e multiple queries/mutations/subscriptions).
- Mutations queries modify data in the data store and returns a value.
WebSocket is a network protocol that enables 2-way communication b/w client & server. In the HTTP standard, where the one-party has to wait for the req./res from another party before performing the next action.
(2/n)
The major goal of WebSocket is to enable real-time communication and can widely be seen in IM applications.
I will be diving the WebSocket learning into 3 parts and I will post more about various attacks in the next two days.
(3/n)
# Web socket Protocol Scheme
1. Websockets use wss:// and ws:// as the protocol scheme. 2. This is similar to HTTPS and HTTP. Here, the WSS:// is a secure channel where WS:// is an insecure channel.
#learn365 Day-12: Unicode Normalization
This attack is hard to explain w/o proper graphics. Please refer to the references mentioned for a detailed explanation. This is a really good attack vector to try and consider while doing PT/BB.
(1/n) #bugbountytips#AppSec#infosec
(2/n)
Unicode to ASCII Transformation is a two-step process.
1. Normalization: Where the characters are converted to a standardized form 2. Punycoding: Where the Unicode is turned into ASCII
There are two overall types of equivalence between characters:......
(3/n) 1. Canonical Equivalence: Characters are assumed to have the same appearance and meaning when printed or displayed.
2. Compatibility Equivalence: This is a weaker equivalence, in that two values may represent the same abstract character but can be displayed differently.
#Learn365 Day-11: Cache Poisoned Denial of Service (CPDos)
AIO Resource: cpdos.org
- One of a kind of Web Cache Poisoning attack that affects the resources used by an application to create a denial of service situation.
The working of this attack is theoretically very simple to understand:
1. The attacker sends a request to the server containing a malicious header with a malicious value. This can be any random header.
ex: x-mal-example: tohackthehacker
(3/n) 2. This request is first processed by the intermediate cache server to check if the copy exists. 3. The cache server forwards the attacker's request with malicious headers to the origin server as it doesn't store a fresh copy of the requested resource.