I AM a Senior Security Consultant

JSON web tokens (JWTs) are a standardized format for sending cryptographically signed JSON data between systems

JWT Tokens includes 3 parts, and they are seperated by dot Header + Paylod + Signature:

• Header and Paylod part are just Base 64 - url encoded JSON objects
• The header contains metadata about the token itself, while the payload contains the actual data/ information.
• The server that issues the token typically generates the signature by hashing the header and payload.
• This mechanism provides a way for servers to verify that none of the data within the token has been tampered with since it was issued:
• As the signature is directly derived from the rest of the token, changing a single byte of the header or payload results in a mismatched signature.
• Without knowing the server's secret signing key, it shouldn't be possible to generate the correct signature for a given header or payload.

JWT vs JWS vs JWE

• The JWT spec is extended by both the JSON Web Signature (JWS) and JSON Web Encryption (JWE)
• When people use the term "JWT", they almost always mean a JWS token.
• JWEs actual contents of the token are encrypted rather than just encoded.

Exploiting flawed JWT signature verification

• Accepting arbitrary signatures
• JWT libraries typically provide one method for verifying tokens and another that just decodes them. For example, the Node.js library jsonwebtoken has verify() and decode()
• Occasionally, developers confuse these two methods and only pass incoming tokens to the decode() method.
• This effectively means that the application doesn't verify the signature at all.
• Accepting tokens with no signature
• the JWT header contains an alg parameter. This tells the server which algorithm was used to sign the token and, therefore, which algorithm it needs to use when verifying the signature.
• This is inherently flawed because the server has no option but to implicitly trust user-controllable input. In other words, an attacker can directly influence how the server checks whether the token is trustworthy.
• JWTs can be signed using a range of different algorithms, but can also be left unsigned. In this case, the alg parameter is set to none, which indicates a so-called "unsecured JWT".
• Brute-forcing secret keys using hashcat
• You just need a valid, signed JWT from the target server and a wordlist of well-known secrets. You can then run the hashcat command, passing in the JWT and wordlist as arguments
• Hashcat signs the header and payload from the JWT using each secret in the wordlist, then compares the resulting signature with the original one from the server. If any of the signatures match, hashcat outputs the identified secret, along with various other details:
• Injecting self-signed JWTs via the jwk (JSON Web Key) ,jku (JSON Web Key Set URL), kid (Key ID) parameters
• jwk (JSON Web Key) - Provides an embedded JSON object representing the key.
• jku (JSON Web Key Set URL) - Provides a URL from which servers can fetch a set of keys containing the correct key.
• kid (Key ID) - Provides an ID that servers can use to identify the correct key in cases where there are multiple keys to choose from. Depending on the format of the key, this may have a matching kid parameter.

These user-controllable parameters each tell the recipient server which key to use when verifying the signature.

Reference link: https://portswigger.net/web-security/jwt

1. A01 Broken Access Control:
• Privilege escalations
• CORS misconfiguration allaowing APi access from untrusted origins
• Accessing restricted methods like PUT, DELETE
• Force browsing authenticated pages without valid credentials
• Preventive steps:
  • Deny by Default
  • Rate limit APIs,
  • Session identifier should be invalidated
2. A02 Cryptographic Failures - Sensitive Data Exposure(2017) : Focus on Cryptographic failures which often leads to sensitive data exposures
   • Plain text data Transmission
   • Deprecated Hash fuinctions in use line MD5, SHA1
   • Security headers missing in reuqest and response
   • Server certicated properly and trust chain properly validated?>
   • Preventive measures:
     • Encrypt data at rest
     • Use authenticated encryption
3. A03 Injection
4. A04 Insecure Design
5. A05 Security Misconfiguration
6. A06 Vulnerable and Outdated Components
7. A07 Identification and Authentication Failures
8. A08 Software and Data Integrity Failures
9. A09 Security Logging and Monitoring Failure
10. A10 Server Side Request Forgery (SSRF)

Issue with OpenSSL - The openssl developers made one critical error when implementing heartbeat messages. They fully trusted the length sent in the request

What information can you get with a Heartbleed attack?

POODLE stands for “Padding Oracle On Downgraded Legacy Encryption”

• Downgrade TLS connection to SSLv3: This can be done by repeatedly dropping the session and eventually client will try with lower SSL version.
• If cipher suite users RC4 or BLock Cipher, attacker can get encryted text and convert them to plain text later

TLS V1.3 usere only one round trip, instead of two as in TLS v1.2.

TLS V2 supports some old cryptographic algorithms, which is dropped in TLS V3

references: https://www.cloudflare.com/learning/ssl/why-use-tls-1.3/