TNG Security
This is a collection of thoughts on TNG security. TNG has moved administrative functions to the main directory which creates doubt as to its security robustness.
Host and Server Security:
- Use the most restrictive system file permissions that still
allow TNG to function. On many servers this is 644 for files and
755 for directories (owner writeable only).
Typically the web server such as Apache runs as user 'nobody' and needs only read permission.
Typically PHP runs as the site owner so group and global write permission are unnecessary. - Disable any and all Apache and PHP features not used by TNG or other parts of the web site.
TNG Software Security
- All parameter strings should be checked for valid format, appropriateness for the function, and be chopped to a maximum size when the particular parameter format is not strict. And rejected immediately as 400 Bad Request before any other TNG PHP files are loaded. This includes any HTTP headers used by the code. The preg functions and for loops on REQUEST parameters are quite effective and efficient for this purpose.
- Only PHP files that need to be called directly from the web should be
allowed, not include and configuration files etc.
- One way is to have all requests go through a single, web resident PHP file that changes directory to a TNG space outside the web space, and only allows calls to web requested functions, not other TNG files./li>
- Another way is to have front-end PHPs in the web space
call their counterpart in the TNG space outside the web
space. No other PHP files need be in the web space.
- I can think of no reason why CSS, image, and JavaScript files need to be protected. They can be in the web space, or have a soft-link from web space to the TNG space. The CSS and JavaScript files could be sent by the TNG function that creates the web page, but so far I can think of no good reason, except reducing the number of network requests (each separate file requires full connect and disconnect interchanges).
Home