0

In my new team, we use the API of our internal clients, whose request calls and responses contain names of our accounts with the client - for example: dingobiscuits.vodafone.com/data/fetch-something And some error messages read detailed configurations, like, "configuration allow.eu-zone.access is not set".

For our internal development, this works and aids in debugging issues.

We also have an external API that we offer to our customers, who are technical users. Basically, this external API exposes all internal information in response objects, that is:

  • implementation names, and details, like class names, method names, etc
  • internal urls, and resource names
  • exact error codes and messages from calling these internal urls

I have two questions:

  1. Is there a standard/principle/prescribed practice in Information Security about exposing internal information? Some of the account names could be confidential to be released publicly.
  2. Is it a security risk when a url, and additional information about internal configurations is exposed? No API keys are exposed, but it is easy to put the <url, account name, and client> and settings information together, to deduce critical information.
julie
  • 3
  • 2
  • 1
    This might end up being too opinion-based to answer here. We're missing context. Typically, you want to limit program internals and internal URLs, but you're battling against pentesters and the technical manager who have assessed the risk, with the full context, and have rated the risk *and accepted it*. So, we can't state whether the risk is high or low. – schroeder Aug 21 '23 at 10:41
  • Thank you @schroeder. Please let me rephrase my question - the internal urls contain names of our accounts with the client - for example: italic dingobiscuits.vodafone.com/data/fetch-something italic And some error messages read, italic "configuration allow.eu-zone.access is not set" italic. Is that an acceptable state from an information security perspective? – julie Aug 21 '23 at 10:59
  • can you edit the question to include these details clearly and why you think this info poses a risk? – schroeder Aug 21 '23 at 11:10

1 Answers1

0

A lot of context is missing (e.g. API design details, security policies, risk assessments etc) so answering is difficult. But, here are some thoughts:

our technical manager disagrees this improvement is needed. In his words, "pentesters have reported this as minor. I mean, we are not even exposing stacktrace here, it is fine"

so, the people whose job is to make risk assessments have already decided on the issue. Unless it's also your job to challenge that, I'm not sure what you can do to change it

I have serious concerns about it

Understandable. Based on your description, I would have concerns too. But, that's not the point; the point is that the risk has already been accepted by the people responsible to make such decisions

Is my understanding incorrect that this 'excessive exposed data' is a medium to high security risk?

Unfortunately, this cannot be answered easily. Risk is based on facts that you don't provide in your question. More details are required on how the API works, what data does it expose and the risk assessment done by the security people, before an opinion can be expressed

Also, in general:

  • the API should have some sort of authentication and authorization mechanism to protect it. As such, even if this info is available, maybe there are proper security controls in place (along with logging and monitoring) that mitigate the said risk

  • on the exposure of configuration items, it also depends on which configuration items are exposed, whether the API allows to modify them and/or which items to modify. Maybe the configuration items exposed are non-critical (security-wise) and read-only. Of course, that's still a source of understanding the system's internals which can lead to vulnerabilities identification, but - again - this falls under the risk assessment that the security people have done

  • whether the URLs returned are a security issue, also depends on whether the customer details are exposed to other customers or only to the customer that the URLs refer to. But (again) this must have been considered during the risk assessment done by the security people

As you can understand, everything revolves around risk assessment and the outcome of it. If the people that are responsible for it have assessed that the issues you mention are not a problem, then you should play along.

Having said that, in the past I did not approve similar API behaviour, but it was part of my job to have an opinion.

  • Thank you @Spyros. I have edited my question, but you've already answered it. It is easy to put together information about our accounts with the clients, and using the configuration items, more such sensitive information can be deduced. – julie Aug 21 '23 at 14:50
  • I am not sure if information security was considered as part of the pentests, but I am worried how the technical manager writes off vulnerabilities as 'it is fine'. To me, adjusting the code to obfuscate/remove these internal details is better/easier, than falling prey because someone thought, 'it is fine'. – julie Aug 21 '23 at 14:55
  • @julie half of cybersecurity is technical knowlege and half of it is politics. Everyone can have an opinion about anything, but you need to be a specialist in a domain in order that people follow your suggestions about that domain. Besides, even if you convinced everyone that your concerns need to be addressed, then you'd put the manager and pentesters into a very difficult position and force all developers to re-implement the solution. Not a good position for you to be in. The way I see it, you did your job and raised a flag; not your problem anymore –  Aug 21 '23 at 15:16
  • Yep, point duly noted, thanks @Spyros I'll watch and learn. – julie Aug 21 '23 at 15:27