3

I have some code like this in index.php:

if(isset($_GET['something'])){
    //do something
}

Can hackers find this and request index.php?something, or is this sufficient for security?

Polynomial
  • 133,763
  • 43
  • 302
  • 380
user20081
  • 31
  • 2
  • 1
    yea this isnt good for security, though its a good layer to have if specific details are needed for a script not to crash / fail – TheHidden Jan 28 '16 at 09:53

6 Answers6

6

You're relying on a principle called security through obscurity, which is generally frowned upon. There is a widely-accepted principle called Kerckhoffs's Principle which states:

A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

An alternate, and more general, form of the principle is called Shannon's maxim:

The enemy knows the system.

Essentially, this means that you should never rely on an obscurity mechanism to protect your system. You should assume that attackers know the code, and can discover any vulnerabilities like this.

As such, your access mechanism should involve proper authentication - e.g. entering a set of credentials that can be checked on the server side, using proper password hashing. This means that even if an attacker knows your code, he cannot exploit it.

Community
  • 1
Polynomial
  • 133,763
  • 43
  • 302
  • 380
  • 1
    If the token is unguessable(entropy of about 40 bits would be enough here), then it's not violating Kerckhoff's Principle, because the token functions as a key like secret. I wouldn't recommend this approach here, but it's not necessarily security through obscurity. – CodesInChaos Jan 27 '13 at 17:16
  • Yes, that is a caveat, though hard-coding a token like that isn't best practice as you mentioned. – Polynomial Jan 27 '13 at 17:53
4

As mentioned elsewhere on this site (see this and this, your "secret" can be discovered in web server logs and many other means.

Using this as a means of access control is known as "security through obscurity", and can be easily discovered.

However some less secure sites will use a variation of this theme and use it to protect a session after a user logs on. The idea here is to use a HTTP GET value instead of a session cookie. I wouldn't recommend implementing it yourself, but it is included in many software packages (Microsoft Windows Identity Foundation) for example, when client side cookies are disabled.

Community
  • 1
makerofthings7
  • 50,488
  • 54
  • 253
  • 542
3

If this is a privileged function that should not be executed by just anyone, then you need to protect your function by also checking the identity of the user (e.g. session id).

Furthermore you should make sure that you have a CSRF token, if someone were to send a link to one of your users with that GET request and the user opens it, he might end up executing a function he didn't want to execute.

Now depending on what your function does and what the GET parameter is, "hackers" might find out what it does.

It might be that your function only shows information (immutable) than this can be ok. I would like to refer to this question: How unlikely is it that a Google Doc link is guessed?

Community
  • 1
Lucas Kauffman
  • 54,229
  • 17
  • 113
  • 196
3

Besides the other answers posted, there's the general problem that web browsers and their users generally do not consider URL's to be sensitive information. They are stored in history files, bookmarks, etc. without encryption by the browsers, and users will happily share them via e-mail, instant message, or cloud bookmark/url sharing services, not expecting a URL alone to give away their access. They may also be captured in web proxy logs, firewall logs, and other intermediaries, who again consider that sensitive information would not be found in the URL.

If any of those get seen by a web spider, or a user just copies the URL from their browser to their blog or a wiki, then they'll be indexed and easy for hackers to find in the search engines.

alanc
  • 140
  • 4
2

Hiding and not protecting functionality is not a good security practice.

There are indirect ways this functionality can leak, such as:

  • Vulnerabilities in other parts of your web application can lead to arbitrary file access making your index.php file readable.
  • HTML text and JavaScript code can leak the name of the hidden variable or it can hint the type of that hidden functionality.
  • Error messages that contain snippets of the something code.
  • Guessing for common variable names or brute-forcing them.
  • Backing up or using multiple versions of that index.php with different extensions (index.bak, index.php.1, etc.) can make the contents readable.
Cristian Dobre
  • 9,837
  • 1
  • 31
  • 51
  • +1 For the correct view point. All rules are valid in a general approach, but just wanted to point out that in the third case I doubt that the php can rendering format the own error code. The error detection nonrecursive mechanism in php prevents you retrieve the code before and after error. Favoring only information about its exception descript and the location of the exception. – RTOSkit Jan 27 '13 at 16:56
0

First and foremost, make sure that the secret token is long enough and changes with every access. Always using the same token is very risky, for reasons the other answers pointed out.

When using different tokens, there are still several threats here, which can be (partially) mitigated:

  • HTTP sniffing: If the connection is unencrypted, a person with a wifi sniffer or a man in the middle somewhere in the network can see the token and use it immediately. Make sure that the connection is always over HTTPS.
  • User data loss: If the user bookmarks the URL or sends it via mail and the users computer gets hacked/stolen, the secret is out. This threat can be mitigated by making the token valid for a short time span only. If the token can be linked to a user feature like IP Address or User Agent, the security increases a bit (but usability might suffer).
  • Server-Side data loss: The easiest to mitigate against is loss of HTTP logs - short lifespan of token and linking to user fature help here too.

Another good strategy is to restrict the access level of users only identified by a token - allow only very specific, potentially non-dangerous actions.

chiborg
  • 653
  • 1
  • 6
  • 12