0

Is it considered a good security practice to prevent users from easily changing the backend URL of a desktop application that connects to a backend server with an SSL protected HTTP API?

One concern is that malicious users could just point the URL to a test server and reverse engineer the protocol. On the other hand, it should be relatively easy to decrypt the communication with the original SSL protected API backend using wireshark or fiddler.

In summary, is it worthwhile, or best practice, to try to prevent users from easily changing the backend URL?

Improve this question
2
  • 1
    From my understanding you are basically asking if obscurity is recommended to protect against "something" - only it is unknown what this "something" actually ist. What would happen on what would happen if the URL gets changed, i.e. what would an attacker gain by doing this and how much does the application rely on the using the original URL? For example does the app only present information behind the URL or would this be some game where the internal state could be changed when controlling the server response by changing the URL.
    – Steffen Ullrich
    Commented Sep 23, 2020 at 19:43
  • 1
    If you use PFS (suites with DHE or ECDHE in TLS 1.2 or lower, always in TLS 1.3) and the app doesn't have a feature to export session secrets (like say most browsers) it can't be decrypted by a passive monitor like Wireshark, and if the app properly checks (and maybe pins) the cert&CA it can't be decrypted by an active interceptor like fiddler. But if the app runs on hardware provided by the user, they can just debug it.
    – dave_thompson_085
    Commented Sep 24, 2020 at 1:50

2 Answers 2

Reset to default
3

No.

In fact, attempting to prevent users to change how your application works is a borderline impossible task. First of all, a user can modify the binary to point to a different host than the one you intended. While this is more complicated than editing a configuration file, this can still be done by dedicated users.

Even if you were to assume that it was somehow impossible for the user to edit an executable file, they can still change their hosts file or DNS resolution to point to their own server. TLS will not protect you here, since the user can simply add their own root CA to their CA store.

As mentioned by yourself and others, sniffing the API calls can allow them to reverse engineer your API. This actually should not be a problem. Kerckhoff famously stated that the security of a system should only depends on it's secret material, not on assuming that the attacker does not know how your system works. In other words, even if you assume an attacker has the source code, your API should still be secure.

In summary, it's not considered best practice. The security gain would be minimal and could still be defeated by semi-dedicated attackers. Your development resources are best spent elsewhere.

Improve this answer
2

I do not think it would be a worthwhile time investment from a security standpoint, as it provides no security. As you said, users can just sniff the underlying protocol, hook or disassemble the application.

However, it may be worthwhile be from a QA standpoint. You don't want your users misusing the application, you want them to stay as close to the happy flow path as possible.

Improve this answer

You must log in to answer this question.

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