Which file included or required me?

thewitt

Is it possible to tell which file has included or required "me" if I am an included file?

I'd like to restrict access to an included file from a list of allowed files on a particular domain.

Thanks,

-t

amcgrath

Just off the top of my head, why are files included other files that you don't want to include? Just remove the include... or further explain what you mean....

thewitt

Allen McGrath wrote:

Just off the top of my head, why are files included other files that you don't want to include? Just remove the include... or further explain what you mean....

Sorry, not what I meant.

Let's say I have a file on my server named secret_stuff.ini. I don't want this file to be included from a PHP script, unless that script is known to secret_stuff.ini already.

If another script attempts to include this script, it would be rejected.

Make sense?

-t

Anon

I believe you could try using the $PHP_SELF variable to identify the script that the user has loaded. I'm not sure if it will work 100% (includes with includes in them for example), but it may be good enough.

-Josh

thewitt

Bingo.

I'm not sure why it didn't click with me the first time, but $PHP_SELF works great - even on nested includes it identifies the top level script file.

Thanks,

-t

[deleted]

Just a small note to state the obvious; $PHP_SELF can be overwritten inside a script, making it possible for a script to set it's PHP_SELF to whetever it wants, including 'authorized' scripts.

Anon

so now that you can identify the calling script, how are you stopping it from including secret_stuff.ini? or are you allowing the script to include it, but secret_stuff.ini contains an if-else so that it basically does nothing unless the script is in the approved list? or what? (this is a very interesting thread.)

thewitt

secret_stuff.ini would have simply done nothing if the calling script was not authorized to include it.

As Vincent noted however, this method is still vulnerable to an including script masquerading as a valid script by simply overriding $PHP_SELF before making the call to include secret_stuff.ini.

Less authoritative than I would like.

-t

amcgrath

Maybe I'm missing something, but in what scenario would a calling script that was not authorized to call secret.ini be calling secret.ini in first place? Let me know...

Anon

and if an unathorized script knows enough to call secret_stuff.ini and fake it's name, what is to stop it from simply reading secret_stuff into a variable and somehow executing it that way? looking more and more like the server software has to provide this level of security.

thewitt

Therein lies the problem, 99% of the shared server installations out there don't provide safety from scripts running elsewhere on the server.

I'm trying to protect a customer's database username and password from prying eyes on his shared hosting account server. It's turning out to be virtually impossible the way a typical CPANEL shared server is configured.

The ease of which you can - from any account on a shared server - load up and read config files in other accounts is quite frightening.

I'm considering an article to shake up the hosting world, by writing a paper with examples of how to exploit these configurations and get access to mySQL databases all over the Internet - with nothing more than a simple account that lets me run a PHP script. Maybe this will get people's attention enough to realize that they are not safe in these environments.

What's unfortunate is that most of these people are like my client. They think they got a great deal on hosting at $30 a month, yet they are totally exposed to even the simpliest of exploits. Add to that the tendancy of applications to store plain text information, usernames and passwords into their application database, and the Internet becomes a dangerous place indeed.

-t

[deleted]

Think about hackers. Secret.ini might belong hold the username/password data to a database.