1

In one of the existing batch process codebase, I can see a practice of JDBC Connection String is getting logged and also persisted. Logging or Persisting a JDBC Connection String alone may not be a security issue. Though, it's a little discomforting to make this information available to naked eyes. But is it a best practice to do so? If not, is there any other reason? OR Is there any usefulness to this practice?

Divs
  • 187
  • 7
  • By connection string I guess you mean the `jdbc:vendor://host:port/database` right? Just to make clear we are not speaking about prepared statements. – Laiv Apr 04 '19 at 13:22
  • You are correct, it's the Connection String not the Statement... – Divs Apr 04 '19 at 13:24
  • What kind of details are logs providing you with? It would not surprise me if these logs were keeping traceability between applications - sessions - databases. – Laiv Apr 04 '19 at 13:28
  • The entity ids of Source and Sink are logged, which is typically same, along with Job Id. The job is responsible to migrate data from One System to Another.. – Divs Apr 04 '19 at 13:33
  • 1
    Looks like monitoring and traceability. – Laiv Apr 04 '19 at 13:49
  • Are you saying JDBC Connection String is needed for monitoring and traceability? Sorry got confused.. – Divs Apr 05 '19 at 02:38
  • I'm saying that It looks like. Whether it's necessary or not, I don't know. – Laiv Apr 05 '19 at 04:29

2 Answers2

1

Knowing which database an application is connecting to can be very useful when there are multiple possibilities. But you don't need the entire connection string for that.

I agree with you that doing this is in general a bad practice. An application should know what it's logging and the connection string is generally just that. A string passed in from configuration that could contain anything.

Ewan
  • 70,664
  • 5
  • 76
  • 161
1

As long as the credentials are not being passed in the connection string (I think you can do this at least with some drivers) I don't think this is a significant security concern. Aside from those details, what would be considered secret about this information? Typically the port is standard and well-known.

At best, trying to hide this information would be considered security by obscurity. With security considerations, it's helpful to consider who you are defending against. For most organizations, insiders are the most likely attackers. Would removing this information significantly impede someone within the organization? I kind of doubt that. For an external attacker, if they have the chops to get into your database, they can surely find it.

Alternately, not logging this potentially creates risks. What if an attacker is able to modify the configuration to point to something they control? If you don't log this information, it could make it a lot easier for them to cover their tracks.

If you are concerned about the information in logs (which is perfectly reasonable) you should probably focus on securing the logs. Trying to prevent any sensitive information from being logged is a endless game of whack-a-mole and success is unlikely over the long-run.

JimmyJames
  • 24,682
  • 2
  • 50
  • 92
  • 1
    Would downvoter care to say why? Security is measured and implemented upon feasible attack vectors and feasible treats. You might or might not agree with `At best, trying to hide this information would be considered security by obscurity.` but it doesn't invalidate the rest. – Laiv Apr 04 '19 at 13:54
  • @Laiv If there's disagreement about whether this is more than security through obscurity, then I think discussion about how that is would be great. – JimmyJames Apr 04 '19 at 14:27
  • DB Queries are handled to prevent injection attacks in the app; So, I'd think, changing the source alone can't make a big difference? Also, to reflect a new source we would require a restart of the apps and hence can't affect the app dynamically through in-memory changes. Logs and DB has both source and sink ids for traceability, On the other hand, persisting the info in sink DB, also reveals information about the source, which is `not-a-best-practice` to my understanding? And for Suppt activities, we don't need to persist this info, they have access to SCM anyway. What am I missing, please? – Divs Apr 05 '19 at 03:27
  • @Divs "So, I'd think, changing the source alone can't make a big difference?" You are saying that someone pointing your app to a fake database that steals data or worse is no big deal? I'm not sure I follow that. – JimmyJames Apr 05 '19 at 13:29
  • @JimmyJames The source info configured and is injected during initialization Only. To change the source the has to be restarted, which will re-read from the config again, hence I believe it is not possible to do so in our arch/design. – Divs Apr 05 '19 at 13:49
  • @Divs "hence I believe it is not possible to do so in our arch/design." That's the kind of hubris that leads to security failures. Setting that aside, what is the concern with have this information in logs? What about all the other places this info is stored such as the injection configuration? What's the plan for that? – JimmyJames Apr 05 '19 at 15:06
  • @Divs You should be aware that a common approach to exploiting systems is to use a vulnerability to modify the configuration/binaries of the system. When the system is (inevitably) restarted they attacker gains more access and/or control. But if you are sure your system is bulletproof, then it's really hard to understand why exposing this information in logs is a concern. – JimmyJames Apr 05 '19 at 15:13