Discussion: Too much and/or sensitive information in (mostly API) responses

[elarlang]

Had it in my todo-list but as WSTG has this topic under discussion I make link/placeholder here as well: https://github.com/OWASP/wstg/issues/727 by @pinkLagoon

Problem: in response from an application there is too much information which may be also sensitive. Happens, when developers are JSON-encoding entire dataset or object and give it for HTTP response.

Risks:

• sensitive information leakage
  • access control issue (V4)
• unneeded data in traffic (which is not used in frontend)
  • too many fields in entries, example: only titles are used but entire dataset is provided by API
  • too many rows, example: only 10 rows "per page" are displayed, but entire list is provided by API

Lists in the beginning are small, but if someone "is testing" with every field with max-length value (text fields getting problematic quite fast) - like few hundred MB to download by API most likely is causing some problems for serving the content or handling the content on the client side - availability loss.

Proposal:

• new requirement(s)
  • todo/discuss - category
  • todo/discuss - requirement text
• Levels: 1, 2, 3
• CWE - probably CWE-200

[elarlang]

Category and requirement text - probably direction should be current requirement 8.1.3:

V8.1.3 Verify the application minimizes the number of parameters in a request, such as hidden fields, Ajax variables, cookies and header values.

[jmanico]

I do not think it's enough to say "just minimize parameters, etc". What you're really asking is that we only include data in JSON (1) that the user has access to and (2) that the application actually needs.

And I'm confused, the original post is about responses, but the last comment was about requests?

[elarlang]

8.1.3 was taken as an example, where (to what category) to place it in ASVS. Requirement itself is for response.

[jmanico]

I personally see this as a pure access control requirement. And it's a core principle. I suggest 4.1 or 4.3

[elarlang]

Yes, part of that is authorization problem and initially I was thinking about this problem more like V4.* problem.

I have seen examples where frontend needs list of titles, but entire entity datasets are provided ended up responses with size of many MB.

[jmanico]

I am with you 100% and think this is a great idea for a new requirement! Even if the user has access to the data, it should not be sent to the client unless the user has access AND the app actually needs that data! :)

[csfreak92]

+1 on this requirement, I actually saw a badly designed/implemented app where the whole API is sending everything to the front-end to make the application's response "faster" but it ended up including a bunch of sensitive information that should never be there in the first place.

[cmlh]

Should "sensitive" be inserted into ASVS Level 1 to mirror the use of the term "sensitive" within the description of ASVS Level 2?

[elarlang]

todo, check requirement 13.1.3 as potential duplicate or place to merge, if we can find some solution here:

V13.1.3 Verify API URLs do not expose sensitive information, such as the API key, session tokens etc.

[jmanico]

This is not a problem with API’s it's a problem with any Url due to referrer headers, logs, browser history and similar.

[elarlang]

This is not a problem with API’s it's a problem with any Url due to referrer headers, logs, browser history and similar.

this is what you described, is covered by 8.3.1

V8.3.1 Verify that sensitive data is sent to the server in the HTTP message body or headers, and that query string parameters from any HTTP verb do not contain sensitive data.

the problem is not the method how sensitive data is sent to client, the problem is the fact that sensitive data is exposed to the client.

[elarlang]

Access control part maybe can be merged to current 1.4.5 (this one need to be moved to V4): Verify that attribute or feature-based access control is used whereby the code checks the user's authorization for a feature/data item rather than just their role. Permissions should still be allocated using roles.

[tghosth]

Which of the following problem options are we suggesting that this is:

1. An Authorization problem where the user is receiving data in the API that they should not have permissions to access?
2. An efficiency issue where data is being returned that the user has permissions to but is more data than they need for the current functionality?

[jmanico]

The issue I see is:

1. Client side validation can we easily bypassed

2. Strong API level access control is super important for this reason

3. Also, when client side validation is bypasses and server side access control violations happen, such events are often really good intrusion detection.

Regards,

• Jim

[tghosth]

V4 Access Control at the JSON attribute level, i.e. you can get the user's firstname and last name but not their password hash, even if it is in the same conceptual object/entity.

Business Logic - Verify that data pagination is enforced at the server side so that the amount of data that can be accessed at once is limited, matching the limit enforced at the front-end.

Too many fields (which the user is permitted to access) seems a little too specific and niche and probably not a serious issue.

@set-reminder 5 weeks @tghosth to look at this.

[octo-reminder[bot]]

⏰ Reminder Monday, January 16, 2023 12:00 AM (GMT+01:00)

@tghosth to look at this.

[octo-reminder[bot]]

🔔 @tghosth

@tghosth to look at this.

[tghosth]

@elarlang should we work on this now or wait for the full access control reorg?

[elarlang]

@elarlang should we work on this now or wait for the full access control reorg?

We can work on this now but I prefer we take one topic and cover it all at once. Otherwise at the moment I should put my time (again) to investigate all the background and history for give answer and then it waits again few months... and we need to start again from the start.