Prevent cross-site access with JSONP

[Sjord]

JSONP is a method to provide cross-site access. If this is misconfigured, it makes it possible for any site on the internet to access information from the target page. It seems the ASVS currently lacks a verification requirement for this attack vector.

E.g. Exploiting JSONP and Bypassing Referer Check

We could make this more general and say that an application shouldn't use sensitive information from within JavaScript. For example, if an application has a file profile.js that has var username = "your_current_username";, any other site can load that script and figure out your username. It seems the ASVS does not currently have a requirement against this.

[jmanico]

JSONP is a major antipattern and should not be used, it allows for CSP bypass.

Can you give us a PR with a new requirement to avoid this and we can work on getting it rolled into main?

Reference: https://blog.fullstacktraining.com/why-jsonp-shouldnt-be-used/

[Sjord]

I would suggest something like this:

Verify that sensitive information is not present in JavaScript or JSONP responses, to prevent cross-origin access to that information.

[jmanico]

 I really really like this a lot, Sjoerd.

…

On 3/18/21 11:11 AM, Sjoerd Langkemper wrote: I would suggest something like this: Verify that sensitive information is not present in JavaScript or JSONP responses, to prevent cross-origin access to that information. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#903 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEBYCKWHWOMF2R2KP4NZ7LTEIJ3LANCNFSM4X2LDXGA>.

[Sjord]

Where should this go? Perhaps somewhere in V8?

[jmanico]

I think V8.2 is reasonable. @elarlang ?

[elarlang]

I need to investigate this topic more before I'm able to give recommendations. V8.2 does not seem the way to go - it's more "do not store sensitive data on the client side" which is not the problem at the moment.

[jmanico]

JSONP is a menace to society and I would support a negative requirement so it's clear we need to avoid it

[elarlang]

Some more ideas on that category-topic - it's not sensitive data leakage from the point of view - this user's browser has permission to access it and can see it anyway (no extra leakage)

The problem is - JavaScript code, which is readable with Cross-Origin requests, contain (sensitive) data.

And there are 2 ways how to fix it:

• remove data from JavaScript code
• restrict access for Cross-Origin requests (similar to defense against CSRF)

The problem exists, when request is made with authenticated/authorised user and response contains information which is only meant for them. It is most likely the case for cookie-based sessions as well.

For non-authenticated users there is requirement like 2.10.4.

I watch this issue as "Cross-Origin Reading (Request)", and CSRF as "Cross-Origin Writing (Request)". So, those should belong together to one category and we don't have suitable one at the moment.

Or

• Cross-Origin Confidentiality - attacker forces victim's browser to read data from targeted site (XSSI)
• Cross-Origin Integrity - attacker forces victim's browser to make data change request in targeted site (CSRF)

Those were thoughts at the moment, still need more investigation from my side.

[cmlh]

Can I recommend that any specific older legacy web technology such as JSONP be put into an ASVS fork as there is no fix/control for JSONP bypassing CSP and developers will argue this works as intended?

I believe we may need another create another issue to discuss sensitive data in cleartext JSON. That said, isn't JSON Web Encryption (JWE) the appropriate control and if so the test case should be the "Invalid Curve Attack"?

[elarlang]

Can I recommend that any specific older legacy web technology such as JSONP be put into an ASVS fork as there is no fix/control for JSONP bypassing CSP and developers will argue this works as intended?

I think we should show the way to go, not discussing was the way so far correct.

I believe we may need another create another issue to discuss sensitive data in cleartext JSON. That said, isn't JSON Web Encryption (JWE) the appropriate control and if so the test case should be the "Invalid Curve Attack"?

Check #934

[cmlh]

I think we should show the way to go, not discussing was the way so far correct.

ASVS is not intended to force a developer to change web technologies when a control exists, otherwise we'll alienate developers who implement JSONP.

[Sjord]

Cross-Origin Confidentiality

Another issue that falls under this category is cross-site search. The attacker performs searches using CSRF requests, and times the responses to determine whether a result is found. This is not always prevented by frameworks with built-in CSRF tokens, since search is considered an idempotent operation, and can use GET (search.php?q=something). CSRF protection is often only enabled on POST requests.

Can I recommend that any specific older legacy web technology such as JSONP be put into an ASVS fork as there is no fix/control for JSONP bypassing CSP and developers will argue this works as intended?
ASVS is not intended to force a developer to change web technologies when a control exists, otherwise we'll alienate developers who implement JSONP.

I don't understand what you are trying to say. Do you agree that we need an ASVS requirement that prohibits JSONP? Or do you want the ASVS to be compatible with existing systems that use JSONP?

[jmanico]

Search should *not* be done over a GET since it contains sensitive data. The advice about not using GET for idempotent operations is wrong. Any GET that is idempotent, nullimpotent OR CONTAINS SENSITIVE REQUEST DATA should use a non-GET verb or at least not put sensitive data in URL's. I strongly oppose any use of GET for search since search always ends up including sensitive data. Adding CSRF defense to GET's is not the right defense, IMO. - Jim

[cmlh]

I don't understand what you are trying to say. Do you agree that we need an ASVS requirement that prohibits JSONP? Or do you want the ASVS to be compatible with existing systems that use JSONP?

I am seeking to make ASVS diverse and inclusive for all web technologies and therefore the most secure implementation of JSONP within legacy web applications i.e. "Or do you want the ASVS to be compatible with existing systems that use JSONP?"

[tghosth]

If we focus on JSONP, is there any problem with @Sjord's suggestion above?

Verify that sensitive information is not present in JavaScript or JSONP responses, to prevent cross-origin access to that information.

To me it seems to handle the specific issue nicely. If we agreed that this needs to go somewhere, we can then decide where.

[elarlang]

In general agree with proposal, category choice depends on #1230. At the moment best category seems to be 13.1 ("V13 API and Web Service" > "V13.1 Generic Web Service Security")

Verify that sensitive information is not present in JavaScript or JSONP responses, to prevent cross-origin access to that information.

Some ideas/questions:

• Should it contain attack name Cross-Site Script Inclusion (XSSI)?
• Is it in general clear, what means "JavaScript response" or "JSONP response"? For me it is, but I'm worried, is it interpretable multiple ways.
• cross-origin vs Cross-Origin
• is "to that information" necessary?

[tghosth]

How about this:

Verify that JSONP functionality is not enabled anywhere across the application and that sensitive information is not present in JavaScript files to avoid Cross-Site Script Inclusion (XSSI) attacks.

[jmanico]

How about this:

Verify that JSONP functionality is not enabled anywhere across the application and that sensitive information is not present in JavaScript files to avoid Cross-Site Script Inclusion (XSSI) attacks.

I like it. Since these are different ideas and fundamental ones, I'd split them into two requirements.

[tghosth]

ok so like:

Verify that JSONP functionality is not enabled anywhere across the application to avoid Cross-Site Script Inclusion (XSSI) attacks.
Verify that sensitive information is not present in JavaScript files to avoid Cross-Site Script Inclusion (XSSI) attacks.

[jmanico]

Love it!

[tghosth]

awaiting outcome of #1230

[elarlang]

Verify that sensitive information is not present in JavaScript files to avoid Cross-Site Script Inclusion (XSSI) attacks.

I prepare for PR and re-analyzing those requirements:

• "sensitive data" is a bit vague - maybe authenticated data?
• "JavaScript" is a bit vague - technically JSON is also JavaScript
• "file" is a bit too strict - usually, when sensitive data is part of JavaScript content, it's a dynamically built response, not a file.

Need some wording and grammar help here, but the direction is maybe something like:
Verify that authenticated data is not present in the HTTP response when it can be included as a JavaScript source to avoid Cross-Site Script Inclusion (XSSI) attacks.

Technical note: it's only problematic when the session token is transferred automatically with the same request, which in practice means if the session token is delivered in the Cookie header and:

• the session cookie has the SameSite attribute set to None
• OR to value Lax when an attack comes from Same-Site scope.

[elarlang]

Requirements are now in the document based on the last proposed wording:

V50.4 Cross-Site Script Inclusion

#	Description	L1	L2	L3	CWE
50.4.1	[ADDED] Verify that JSONP functionality is not enabled anywhere across the application to avoid Cross-Site Script Inclusion (XSSI) attacks.	✓	✓	✓
50.4.2	[ADDED] Verify that sensitive information is not present in JavaScript files to avoid Cross-Site Script Inclusion (XSSI) attacks.	✓	✓	✓

As pointed out in previous comment (#903 (comment)), requirements can be improved.

ping @tghosth , @Sjord

[tghosth]

How about:

#	Description	L1	L2	L3	CWE
50.4.2	[ADDED] Verify that data which should require authorization to access is not returned in executable JavaScript format to avoid Cross-Site Script Inclusion (XSSI) attacks.	✓	✓	✓

[elarlang]

I think "executable JavaScript format" is misleading. Some may think it is only valid for some Electron apps etc. https://medium.com/swlh/javascript-executables-5644ead7016d

maybe direction like "is not returned in response for loading script resource"?

[tghosth]

You mean like this:

#	Description	L1	L2	L3	CWE
50.4.2	[ADDED] Verify that data which should require authorization to access is not returned in script resource responses to avoid Cross-Site Script Inclusion (XSSI) attacks.	✓	✓	✓

[jmanico]

I like this direction a lot. Can we add a little more detail to this to explain what script resource response means?

[tghosth]

@elarlang can we maybe add a clarification like

#	Description	L1	L2	L3	CWE
50.4.2	[ADDED] Verify that data which should require authorization to access is not returned in script resource responses (such as JavaScript files) to avoid Cross-Site Script Inclusion (XSSI) attacks.	✓	✓	✓

[elarlang]

which > that, brackets to commas
46dba30