64

If I create a servlet that would return the server time publicly (no need for authentication), would this be a security issue? I couldn't think of any issue with this, but somehow something tells me I could be wrong.

To explain more, this end-point will be used by mobile apps to enhance their security (to avoid cheating by adjusting the device date).

Improve this question
3
  • What you should have asked was "How much of a security risk is publicly exposing my server's time?" Exposing anything about your system is a potential risk, although time (assuming it's accurate) is at the lowest end of the threat spectrum.
    – Ian Kemp
    Commented Jun 8, 2018 at 20:48
  • 1
    By the way, the "server time" should be UTC and set via NTP, which means that it's public information anyway. (Oh, and if you're writing servlets directly instead of using a framework like Spring or Dropwizard, that hand-implementation is much more likely to cause security vulnerabilities than exposing the time.)
    – chrylis -cautiouslyoptimistic-
    Commented Jun 9, 2018 at 3:30
  • You should assume they can change anything. If they're willing to change the date on their phone, who's to say they won't intercept the response from the server at their firewall and change the date there too? The only thing you can rely on a client to tell you is what the client would like to do. Any other validation, no matter how trivial, must be assumed to be compromised and checked somewhere you can trust it.
    – corsiKa
    Commented Jun 10, 2018 at 16:20

7 Answers 7

Reset to default
89

The server time is of little use to an attacker, generally, as long as it is accurate. In fact, what is being revealed is not the current time (after all, barring relativistic physics, time is consistent everywhere) so much as the time skew. Note that, even if you do not explicitly reveal the time, there are often numerous ways to get the local server time anyway. For example, TLS up to and including version 1.2 embeds the current time in the handshake, web pages may show the last modified dates of dynamic pages, HTTP responses themselves may include the current time and date in response headers, etc.

Knowing the exact clock skew of a server is only a problem in very specific threat models:

  • Clock skew can be used in attacks to deanonymize Tor hidden services.

  • Poorly-written applications may use server time to generate secret values.

  • Environmental conditions of the RTC may be revealed in contrived situations.

Improve this answer
11
11

"Servlet" sounds like you're already running a complex server there.

There's a lot of ways that protocols leak server time. For example, HTTP has a popular header field for creation/modification time, and dynamically generated data would always have the current system time, if used properly.

For TLS authentication reasons, you can even binary search to find an endpoint's date and time using expiring client certificates.

This is a necessary evil – if you're doing TLS, your server needs to have a notion of time to know what's a valid key / cert and what not. If that's the case, this will very likely be an NTP-coordinated time. So, you really can't tell anything about the server that an attacker wouldn't already know – there's really only one "correct" time.

If you're not doing TLS: leaking system time is probably not the first thing you should fix.

Regarding security: Not quite sure you should expose yet another servlet just for devices to figure out world time.

To explain more, this end-point will be used by mobile apps to enhance their security (to avoid cheating by adjusting the device date).

Red flag. You're depending on your client's unmodifiedness for security. Never do that. You simply can't trust anything happening on your user's devices. These are not your devices. They can simply hook up a debugger and modify notions of time in-memory of your process, no matter whether kept by the phone's OS or by your application.

Improve this answer
4
  • 1
    I think you misunderstood the "To explain more.." part. In contrary, I'm already assuming mobile app users are more likely to change the device time to cheat, that's why I need the server time for counter-checking. If there's a more correct way of doing this, I'm all ears. But thank you for your input as well.
    – Manny
    Commented Jun 8, 2018 at 10:51
  • 8
    @Manny: send every command to the server. Have the server verify every action. You can assume in the client code that the server will approve and carry out consequences. If it turns out the server rejects an action (one second later e.g.,), revert on the client. This way, your server is the authority. Your server is (should be) 100% under your control and there you can trust things like system time.
    – marstato
    Commented Jun 8, 2018 at 13:58
  • "Leaking" system time should never be fixed. It is required to be revealed for proper operation of TLS and HTTP.
    – OrangeDog
    Commented Jun 8, 2018 at 18:00
  • @OrangeDog exactly what I said in my answer.
    – Marcus Müller
    Commented Jun 8, 2018 at 18:07
2

The only thing that could really expose a security risk is the high-precision timers and performance counters. These could be used to precisely time how long some cryptographic process takes on the server, and from there infer secret data.

Timing data to the milisecond or normal "tick" rate is unlikely to expose this.

Improve this answer
2

Server time is not a secret. On the contrary, you are strongly encouraged to sync your time to an outside objective time source (such as an atomic clock exposed through a time server).

Not being a secret has two consequences:

  1. you don't need to protect or hide it. You can safely assume that the attacker is capable of figuring out what the current time is.
  2. it should not have a function on anything that you do wish to protect or hide. For example, you should not derive any keys or secrets from the time. Any random functions you are using should be seeded not with the current time (still a lazy default in many), but with a better seed source.
Improve this answer
1

Knowing the server time is of little use for an attacker. So here you should find about possible side effects.

  • is the protection for that servlet weaker (in any way) that the one of other servlets? What are the possible implications of the no need for authentication in term of DOS/DDOS attacks. It could matters if authentication was processed in other more secured servers. Is there any difference for reverse proxying?
  • what are the risks for security flaws in that servlet? Has it followed the same quality insurance controls than the other servlets? What about its maintenance cycle?
  • what about its servlet container?
Improve this answer
1

I would like to answer that by pointing out, what would follow from the assumption, that exposing the server time would in fact be a risk. It would mean that system administrators would have to set random times on their systems, because any server set to the correct time would be vulnerable, since a correct or near correct server time is just to easy to guess. It would also mean extreme development effort to translate a false setting to a correct time for use in every time related application. Every single file on the system would have a wrong time stamp.

In my experience you invite much more trouble by setting wrong server times, than you can expect with the correct setting. Some examples are mentioned in other answers, but you also have to consider distributed applications or clusters, where correct time settings are usually essential. Basically any time related information you store would be flawed.

So if exposing your system time would be your biggest risk, you were in luck. But most likely there are many other concerns that you haven't paid enough attention to. See https://www.owasp.org/index.php/Main_Page for security related issues and best practices.

Improve this answer
1

The only thing that I can think of is if you exposed the "uptime" time of the server - this could give an indication of the last installed patches; however I believe this isn't usually exposed publicly- but haven't checked so it might be worth confirming this if you are interested.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .