More that passing out arbitrary files by inum could allow people to get access to files that they shouldn't (e.g. if your documents are served from the same filesystem as your Apache configuration someone could figure out the likely inum for httpd.conf; worse if your document root is on the same filesystem as /etc).
| [reply] |
I want to underscore the following: submitting an inode num to the server is not the only requirement to download a file
There is already a whole method of identifying the user by ip, auth, session time, etc etc- it does happen in ssl. The validity of your 'pageview' is checked with every action etc.. If one were to try to view or download a file they cannot, they are pooped out.
So, first an inode is submitted. Then the inode *must* be in my valid 'files' table which does *not* record about anything but .doc, .pdf, etc like "document" files.
Second, there is a "files to users" (normalisation) table that simply establishes a relationship between a user and a file. To download a file, you must have an entry in the files to users table. If not, the app freaks the hell out, ends your session, sends a notice for the admin to view the logs.
| [reply] |
