CODEWITHSUNDEEP
phpserver
Matt
Matt

Reputation: 1432

Does making server file names ambiguous help security?

I'm working on a system that has ambiguous file names for server calls (for a mobile app). For example, if I have a user registration call, the file could be called from r.php or df.php (random). The logic (when the system was initially built), is that this would help prevent people from guessing file names and abusing the server calls.

Does this really do anything? All people need to do is start a packet trace or use a decompiler to find out what HTTP requests are being called. (and realistically, anyone who wants to abuse HTTP requests would know how to do one or both of these "tricks")

On top of that, with the growing file names, keeping all the filenames in order is becoming a pain.

Is it bad practice to have our registration file simply be registration.php or newUser.php?

Upvotes: 1

Views: 36

Answers (1)

Sherif
Sherif

Reputation: 11943

The short is no. Security through obscurity is not security [1].

First, a file name has very little to do with uncovering the request URI, which is always visible to the client UA in plain-text. So no packet trace or "decompiler" is necessary here to uncover request/response data over HTTP.

Secondly, when you think about the actual kinds of abuse you would want to prevent in a login system (i.e. brute-force attacks, automated registration, etc...), none of them can be prevented by randomizing the end-point URI, since it ultimately always has to be visible to the client at the end of the day. Whether you try to obscure it from them directly or not does you no good. Mostly because the people you would succeed in hiding from are not the people you fear attacking you (i.e. not the people that can actually do your system any bit of harm anyway). So you haven't accomplished anything by doing this.

Instead, what you want are measurable secrets (and secrets are a huge distinction from obscurities in the practice of security engineering) that can either impede or prevent tampering of the system regardless of the knowledge of its implementation [2].

To give you an example, a rate-limited login system. By throttling the number of login attempts into a particular user's account or from a particular IP/range, you can effectively impede the efforts of a brute-force attack enough to deter the attacker from even trying. The fact that they know this rate limit exists doesn't necessarily equip them any farther in trying to bypass your security, because the rate-limit is still under complete control of your system. Whereas, with hiding an end-point URI, all they need to do is inspect the HTTP request/response headers to find that URI and you are still left defenseless.

[1] https://en.wikipedia.org/wiki/Security_through_obscurity

[2] https://security.stackexchange.com/questions/44094/isnt-all-security-through-obscurity

Upvotes: 1

Related Questions