Jump to content

Saving data in text files - what security issues are there?


MrCat

Recommended Posts

In a nutshell: is it possible for the public to browse my site folders?

 

If I either set htaccess to not allow browsing, or I place a blank (or redirect) index into every folder, is there any other way someone could browse my folders and files?

 

If I save data in text files instead of a database, what specific security issues are there?

People say seemingly by instinct "That's a bad idea security wise" but can anybody give me specifics?

 

Can a text file in a web folder called "password.txt" be read if browsing is off?

Sure, if they know the file path is mysite.com/password.txt then they could - but what if I name it password.php and store the data in a php comment? Even if they know the file exists they couldn't read it right? What about mysite.com/fUnnyFilenameXYX.php - how could they find out that even existed?

 

Link to comment
Share on other sites

If you did it in plaintext, e.g. a .txt file and placed it in a web-accessible directory, anybody could read it. From there they could figure out what hash you used and use a rainbow table to find the actual passwords. Granted, things like salts, different hashing, etc would help... but still... it'll be accessible to the world.

 

If you placed .htaccess disallowing to that directory, sure you might not be able to access it. However, personally I just don't trust it and would rather place a file like that below http docs, or better yet (for performance and more safety) in a database.

 

If you had the passwords in a PHP array then nobody could see it unless you output it or the server was misconfigured and did not parse the PHP file.

Link to comment
Share on other sites

Thanks for that.

 

When you say "it'll be accessible to the world", are you saying there are still teqhniques for browsing files and folders when htaccess disallows that directory and an index file is present?

 

Link to comment
Share on other sites

Thanks for that.

 

When you say "it'll be accessible to the world", are you saying there are still teqhniques for browsing files and folders when htaccess disallows that directory and an index file is present?

 

 

What he means is that if the file is in webspace it will be accessible if someone knows or guesses the url to the file.  Neither disabling a default directory listing or adding an index.xxx file will stop that from happening, just as having an index.php does not stop you from making a file called foo.php and accessing it via http://yoursite.com/somedir/foo.php. 

 

With PHP there is no reason that you need to have files in web space.  They can exist outside of webspace and then you don't need to worry about an exploit that inadvertantly discloses their contents.

Link to comment
Share on other sites

Thanks guys.

 

I hadn't actually tried to access files above the webroot folder before. I'm on a commercial shared server and I didn't realise I could use relative addressing to go backwards past the site root folder.

It seems to work fine.

 

Apart from someone guessing the url, I'm still not clear on how it could be discovered if it has a crazy file name (or maybe a crazy folder name in the path).

 

I know a PHP programming error might do it.

 

What about a server error where just PHP goes down? If PHP went down but Apache was still running, what happens? Are the PHP files revealed as plain text?

 

Link to comment
Share on other sites

 

I hadn't actually tried to access files above the webroot folder before. I'm on a commercial shared server and I didn't realise I could use relative addressing to go backwards past the site root folder.

It seems to work fine.

 

Apart from someone guessing the url, I'm still not clear on how it could be discovered if it has a crazy file name (or maybe a crazy folder name in the path).

 

I know a PHP programming error might do it.

 

What about a server error where just PHP goes down? If PHP went down but Apache was still running, what happens? Are the PHP files revealed as plain text?

 

 

No, the php file routines all work with file system paths.  Webspace is a function of the web server application.  When PHP deals with files it deals with the operating system filesystem, and has no interest or understanding of webspace.  So let's say on your host, your webroot is:

 

/users/username/htdocs/

 

You can specify that /users/username/datafiles is the place where you will read/write these .txt files and using php's file handling routines like fopen etc, you can access them and return their contents in whatever way you want, while at the same time leaving no possibility for the user to access the files via a url.

 

As for crazy names... yes it might be highly unlikely for someone to guess the filenames.  The basic term for that is "security through obscurity".  You can use that phrase to explore the idea further if you'd like.  I would not recommend on counting that when you have a completely viable option to put the files outside the webroot.

 

PHP is not a seperate process from apache.  If apache is down there is no webspace.  If php explodes, apache will generate errors and you'll typically get exceptions and blank pages.  When people inadvertantly leak information, it's usually because of some logic error, and not having the server properly configured not to display errors and log them instead to an error log on the server.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.