Interview Bank
  • Interview Bank
  • Web
    • Persistent Connection and Non Persistent
    • CDN
    • Code Review
    • JWT
      • JWT vs Session Based Authentication
      • JWT Challenge
      • JWE
      • JWS
    • Content Security Policy (CSP)
    • Same-origin Policy (SOP)
    • Cross-Origin Resource Sharing (CORS)
      • Exploiting CORS
    • HTTP Strict Transport Security (HSTS)
    • SQL Injection (SQLi)
    • Password Encryption in Login APIs
    • API Security
      • API Principles
    • Simple bypass PHP
    • Server-side Template Injection (SSTI)
    • Javascript Object and Inheritance
    • HTTP/2
    • Cookie vs Local vs session Storage
    • XML External Entity (XXE)
    • What happened when enter domain name in browser
    • Prototype Pollution - Part 1
    • Prototype Pollution - Part 2
    • Nginx vs Apache
  • OT Security
    • Securing Operational Technology: Understanding OT Security
  • Quantum Computing
    • Quantum Computing: Unveiling the Cryptographic Paradigm Shift
    • Quantum Obfuscation: Shielding Code in the Quantum Era
  • DevSecOps
    • Continuous Integration/Continuous Deployment Pipeline Security
    • Chaos Engineering Overview
      • Security Chaos Engineering
    • Mysql VS redis
    • Kubernetes (k8s)
    • How MySQL executes query
    • REDIS
    • Difference between cache and buffer
  • Windows
    • Pentesting Active Directory - Active Directory 101
    • Pentesting Active Directory - Kerberos (Part 1)
    • Pentesting Active Directory - Kerberos (Part 2)
    • AD vs Kerberos vs LDAP
    • Active Directory Certificate Services Part 1
    • Unconstrained Delegation
    • AS-REP Roasting
    • NTLM Relay via SMB
    • LLMRN
    • Windows lateral movement
    • Constrained Delegation
    • Resource-Based Constrained Delegation
    • IFEO (lmage File Execution Options) Hijacking
  • UNIX
    • Setuid
  • Large Language Models (LLMs)
    • Tokens
    • LangChain
    • Integration and Security
  • Android
    • Keystore
  • Red team development
    • Secure C2 Infrastructure
    • P Invoke in c#
    • D Invoke
    • ExitProcess vs ExitThread
  • Blue Team
    • Indicators of Compromise
    • Methods to prevent Email domain spoofing
    • Windows Prefetching
  • CVE
    • XZ Outbreak CVE-2024-3094
    • Log4J Vulnerability (CVE-2021-44228)
    • SolarWinds Hack (CVE-2020-10148)
    • PHP CGI RCE (CVE-2024-4577)
    • Windows Recall
  • Software Architecture
    • Microservices
    • KVM
  • Docker
    • Overview
    • Daemon Socket
    • Tips to reduce docker size
  • Blockchain
    • Overview
    • Smart Contract
  • Business Acumen
    • Market Research Reports and Perception
    • Understanding Acquisitions
    • Cybersecurity as a Business Strategy
  • Cyber Teams
    • Introduction to Purple Teaming
  • Malware
    • Dynamic Sandbox Limitations
Powered by GitBook
On this page
  • What is JWS?
  • How are JWS used?
  • Who can create JWS?
  • Want to get a practical challenge on JWS?
  • Questions
  • Source:
  1. Web
  2. JWT

JWS

PreviousJWENextContent Security Policy (CSP)

Last updated 9 months ago

What is JWS?

Of course we know it is called JSON Web Signature but what is it really?

It is an implementation of JWT, representing content that is secured using digital signatures or Message Authentication Codes (Sounds familiar?) all using JSON-based data structure.

The most common algorithms used by JWS out there are the following:

  • HMAC using SHA-256 or SHA-512 hash algorithms (HS256, HS512)

  • RSA using SHA-256 or SHA-512 hash algorithms (RS256, RS512)

If you have decoded a JWT or JWS in https://jwt.io/ before, you would note these do look rather familiar and in the other pages of this JWT gitbook, we have touched on what they mean.

How are JWS used?

They are often used in claims. Claims are small pieces of information that are asserted regarding a subject in question.

For example, this is a JWS

Decoding the Token reveals the payload section (the second section of the JWS)

{
      "sub": "696969",
      "name": "Jak Jak",
      "admin": false
}

The claim refers to the sub, the name and admin in this.

So what happens is that these claims get signed with a signature (often a private key), depending on which algorithm is used. The claims can then be verified by being decrypted using a secret signing key (public key). This ensure Integrity of the claims.

In essence, when you sign a JWT, you are using JWS to create it. A JWT is often a JWS that adheres to the JWT standard.

But note why are they slightly different is due to the fact that there are Unsecured JWTs where the 3rd section of the JWT is an empty space like such:

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.

Who can create JWS?

A common misconception is that JWS can only be created by the server for authentication only, however it is actually valid both ways.

  1. Server-Created JWS (JWT Example):

    • Client sends login credentials to the server.

    • Server validates credentials and generates a JWT containing user information and permissions.

    • Server signs the JWT with its private key.

    • Server sends the signed JWT (JWS) back to the client.

    • Client includes the JWT in the Authorization header of subsequent requests.

    • Server verifies the JWT signature to authenticate the client and authorize access to resources.

  2. Client-Created JWS (API Request Example):

    • Client creates a JWS containing the API request details.

    • Client signs the JWS with its private key.

    • Client sends the signed JWS to the server.

    • Server verifies the signature using the client's public key.

    • Server processes the request if the signature is valid.

The Server created is mostly straight forward, server does the creation of token and is client just need to use this token for their authentication access.

But for client created wise... it is just little more complex if you want it secured.

Best would be for client to be authenticated firstly by any secure means, so the server knows that the request is valid, then the client needs to generate a private key and save it, using the private key to sign the JWS and sending it to the Server. The complicated portion lies in the storing of private keys, and the additional steps of authenticating first before this can happen.

Want to get a practical challenge on JWS?

Questions

  • What is the purpose of JWS?

  • What makes JWS secure?

  • Can you or should you put confidential information in JWS?

  • Who can create JWS? Client or Server?

Source:

  • https://codecurated.com/blog/introduction-to-jwt-jws-jwe-jwa-jwk/

  • https://datatracker.ietf.org/doc/html/rfc7515?ref=codecurated.com

  • https://www.loginradius.com/blog/engineering/guest-post/what-are-jwt-jws-jwe-jwk-jwa/

  • https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-token-claimsobsidian://open?vault=OSCP&file=Pasted%20image%2020240524011018.png

Go try out the

Author: 🐱‍👤

JWT Challenge
Ninjarku
An image of the JWT Family tree Source: [https://codecurated.com/blog/introduction-to-jwt-jws-jwe-jwa-jwk/]
JWS example highlighting the Payload portion