Just learning about JOSE and I understand that JWE is for encryption and JWS is for signing. What I don't seem to be able to find examples of is a payload that is both encrypted and signed.
Let's pretend I have a payload hello world. Is the correct thing to do something like this? JWS(JWE('hello world') with the encrypted JWE as the payload of the JWS?
JSON Web Token (JWT) is an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. JWT is a generic name for the following types of token:
JSON Web Signature (JWS): The payload is encoded and signed so the integrity of the claims can be verified.
JSON Web Encryption (JWE): They payload is encrypted so the claims are hidden from other parties.
The image was extracted from this page.
Is the correct thing to do something like this? JWS(JWE('hello world') with the encrypted JWE as the payload of the JWS?
It's a nested JWT and its concept is defined in the RFC 7519:
A JWT in which nested signing and/or encryption are employed. In
Nested JWTs, a JWT is used as the payload or plaintext value of an
enclosing JWS or JWE structure, respectively.
You could add a JWE as a claim of a JWS payload, however the other way around is recommended: First sign the message and then encrypt the result, as mentioned in the same document:
11.2. Signing and Encryption Order
While syntactically the signing and encryption operations for Nested
JWTs may be applied in any order, if both signing and encryption are
necessary, normally producers should sign the message and then
encrypt the result (thus encrypting the signature). This prevents
attacks in which the signature is stripped, leaving just an encrypted
message, as well as providing privacy for the signer. Furthermore,
signatures over encrypted text are not considered valid in many
jurisdictions.
Related
I have a REST API that accepts and returns JSON data.
A sample request response is a follows
Request
{
"repos": [
"some-repo",
"test-repo<script>alert(1)</script>"
]
}
Response
{
"error": "Error Message",
"repos": [
"test-repo<script>alert(1)</script>"
]
}
Is my API vulnerable for XSS?. From what I understand, since the Content-Type is set to application/json, the API as such is safe from XSS. The client needs to ensure that the output is encoded to prevent any XSS attacks.
To add an additional layer of security, I can add some input encoding/validation in the API layer.
Please let me know if my assessment is right and any other gotchas that I need to be aware of
I think it's right that any XSS issue here is a vulnerability of the client. If the client inserts HTML into a document, then it is its responsibility to apply any neccessary encoding.
The client knows what encoding is required not the server. Different encoding, or no encoding may be needed in different places for the same data. For example:
If a client did something like:
$(div).html("<b>" + repos + "</b>");
then it would be vulnerable to XSS, so repos would need to be HTML encoded here.
But if it did something like:
$(div).append($("<b>").text(repos));
then HTML encoding would have resulted in HTML entity codes being wrongly displayed to the user.
Or if the client wanted to do some processing of the data, it may want the plaintext data first to do the processing, and then encode it later to output it.
Input validation can help too, but the rules for what is valid input may not align with what is safe to use without encoding. Things like ampersands, quotes and brackets can appear in valid text data too. But if your data can't contain these characters, you can reject the input as invalid.
Your API will not be vulnerable to XSS unless it also provides a UI that consumes it. It will be the clients of your API which could be vulnerable - they will need to make sure they correctly encode any data from your API before they use it in any UI.
I think your api is vulnerable, though the script may not be execute. Talking to XSS prevention, we always suggest decode/validation dangerous characters when the api deals the input. There is a common requirement "clean the data before it store in the DB".
As for your situation, the api just response a json, but we don't know where the data in json will be used to. usually the frontend accept the data without any decode/validation, if that, there will be a xss.
you talk about that the client use decode the data they get from your api. Yes I agree, but frontend always "trust" the backend so that they won't decode the data. but the api server should not trust any input from frontend due to this can be controlled/changed by (malicious)users.
I need to pass JSON-encoded signed (and sometimes additionally encrypted) objects between multiple instances of my software. The obvious choice here is JWT.
Yet, JWT allows apparently to both sign and encrypt a token (JWS and JWE) or nest JWS into a JWE (nested JWE).
While both approaches seem reasonable for me, is there a "standard" way of doing this? I haven't found any specifics on this.
Short answer
When both signing and encryption are necessary, you should first sign the message and then encrypt the result. That is, nesting a JWS into a JWE is a valid approach.
Long answer
JSON Web Token (JWT) is an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. JWT is a generic name for the following types of token:
JSON Web Signature (JWS): The payload is encoded and signed so the integrity of the claims can be verified.
JSON Web Encryption (JWE): They payload is encrypted so the claims are hidden from other parties.
The image was extracted from this page.
JWT allows apparently to both sign and encrypt a token (JWS and JWE) or nest JWS into a JWE (nested JWE).
While both approaches seem reasonable for me, is there a "standard" way of doing this? I haven't found any specifics on this.
The concept of nested JWT is defined in the RFC 7519:
A JWT in which nested signing and/or encryption are employed. In
Nested JWTs, a JWT is used as the payload or plaintext value of an
enclosing JWS or JWE structure, respectively.
Regarding the order of the operations, it's advisable to first sign the message and then encrypt the result, as mentioned in the same document:
11.2. Signing and Encryption Order
While syntactically the signing and encryption operations for Nested
JWTs may be applied in any order, if both signing and encryption are
necessary, normally producers should sign the message and then
encrypt the result (thus encrypting the signature). This prevents
attacks in which the signature is stripped, leaving just an encrypted
message, as well as providing privacy for the signer. Furthermore,
signatures over encrypted text are not considered valid in many
jurisdictions.
I came across a few resources regarding REST but I'm not able to understand things clearly. It would help me if someone could explain things with respect to my example below.
I have a table named User
User table Content
id name
1 xxx
The URL I will be calling is /test/1
The result will be in JSON format, eg: { 1: "xxx" }
My understanding so far regarding REST:
Resource - User table content
Representation - table/JSON
State transfer - data in the form of table to JSON.
Please do let me know if my understanding is correct.
Else, please answer the below questions:
What is a Resource in my example?
What is a Representation in my example?
What is a state transfer or when does this happen in my example?
REST is about resource state manipulation through their representations on the top of stateless communication between client and server. It's a protocol independent architectural style but, in practice, it's commonly implemented on the top of the HTTP protocol.
When designing REST over HTTP, URLs are used to locate the resources, HTTP methods are used to express the operations over the resources and representations such as JSON and/or XML documents are used to represent the state of the resource. HTTP headers can be used to exchange some metadata about the request and response while HTTP status code are used to inform the client regarding the status of the operation.
What is a resource in my example?
Understand resource as the concept of a user. Don't think about the table in your database, think about an abstraction of a user with their set of attributes.
What is a representation in my example?
A JSON document can be used to represent the state of a particular resource. A resource can have many representations, such as JSON and/or XML documents, and the client can use content negotiation to request different representations of the same resource.
What is a state transfer or when does this happens in my example?
The state of a given resource can be retrieved and manipulated using representations.
A GET request, for example, allows you to retrieve a representation of the state of a resource, sent in the response payload. A PUT request, for example, allows you to replace the state of a resource with the state defined by the representation enclosed in the request payload.
Example
Consider a user resource with attributes such as id and name stored somehow in your server:
ID: 1
Name: John Doe
These details make the state of the resource.
A URL such as /users/1 can be used to locate the resource in your server.
Requests such as GET, PUT and DELETE can be performed against this URL to retrieve/manipulate the state of the resource using representations, such as JSON and/or XML documents (other representations can be supported according to your needs):
{
"id": 1,
"name": "John Doe"
}
<user>
<id>1</id>
<name>John Doe</name>
</user>
The above shown documents are not the resource itself. They are just a way to represent the resource. which is stored somehow in your server.
If you want to understand REST, you should really start from the source: Fielding's thesis.
What is a Resource in my example?
OK, review of the term:
The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author's hypertext reference must fit within the definition of a resource. A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time.
In other words, the "resource" is the concept you are talking about. In this case, the user with name xxx. But it could be anything - the table that holds the data about the user with name xxx is also a "resource".
What is a Representation in my example?
Representations are fundamentally byte arrays
A representation is a sequence of bytes, plus representation metadata to describe those bytes. Other commonly used but less precise names for a representation include: document, file, and HTTP message entity, instance, or variant.
So your json document -- more precisely, the utf-8 encoded byte array, is a representation. A given resource might have many representations at any given time.
What is a state transfer or when does this happens in my example?
When the client and server exchange messages; the client server architectural style is the first of the architectural constraints in the REST architectural style.
If no, where are these CSRF generated tokens stored at: JCR Repository or Objects in the application heap? Also how does it validate the received token at very high level?
If yes, is this not a scalabilty issue?
I tried to follow these links: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-json-web-token-16#section-7 & https://datatracker.ietf.org/doc/html/draft-ietf-jose-json-web-signature-41#appendix-A.4.2 and seems like they use a sort of public-private key, along with user, user-agent and other info to build a key-pair and a signature, and validate it in a similar fashion, where the token is deciphered in a sense, but not exactly matching it to another stored token. But not sure, hence the question.
Short answer: Yes the AEM CSRF Authentication/protection framework is stateless.
Details
The tokens are not persisted and all the information is in the token encrypted using a Symmetric Algorithm. As long as all your instances share the same Crypto Key, any instance can decrypt and decode the CSRF token issued within the cluster. More details on this can be found in the official CSRF documentation.
AFAIK it's not possible to set a header field when a form is submited, it can only be done in ajax requests
This questions also points that it's not possible:
How to set a Header field on POST a form?
Custom HTTP Request headers in HTML
But reading Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet it's mentioned that:
Encrypted Token Pattern
Overview
The Encrypted Token Pattern leverages an encryption, rather than
comparison, method of Token-validation. After successful
authentication, the server generates a unique Token comprised of the
user's ID, a timestamp value and a nonce, using a unique key available
only on the server. This Token is returned to the client and embedded
in a hidden field. Subsequent AJAX requests include this Token in the
request-header, in a similar manner to the Double-Submit pattern.
Non-AJAX form-based requests will implicitly persist the Token in its hidden field, although I recommend persisting this data in a
custom HTTP header in such cases. On receipt of this request, the
server reads and decrypts the Token value with the same key used to
create the Token.
This sentence confuses me:
I recommend persisting this data in a custom HTTP header in such cases
Could anyone shed some light on it?
Yes, the sentence implies that the POST operation is invoked by a custom JavaScript handler in order to inject the AUTH header. I've corrected the OWASP description to reflect this oversight.