Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I tried installing refbase on my shared hosting space and after many hours of trying to debug the application, I emailed my host's technical support (host is Hostdime.com) and they replied noting that one of their default PHP security modules prevents using the main show.php function (seems like due to the way variables are passed in the URL). The correspondence with my host is below. In case I missed something or a new version addresses this, any information would be much appreciated.
Posted On: 30 May 2007 11:12 PM
The reason you are getting this error is because of the query string that is being run when you attempt to add ?records=all to the end of show.php. The server security module has picked up "select.+from" which is blocked by mod_security. You will have to find a workaround for this otherwise the server will keep blocking it. Please let us know if you have any further questions.
Posted On: 30 May 2007 10:33 PM
I am forwarding your ticket to a level 2 tech.
Posted On: 30 May 2007 09:46 PM
I'm getting a forbidden error for the following address:
The error is as follows:
You don't have permission to access /refbase/search.php on this server....
I'm just curious if some part of the server configuration could be at the root of this as I did a chmod 755 on the files, I can't discern anything pertinent/causal from the php.ini or .htaccess files, and I have been over configuration files and fora for this app multiple times without note of this type of error.
Any assistance would be appreciated,
'show.php' (and some other functionality in refbase) constructs a SQL query & redirects the browser to 'search.php' with this query. Some mod_security users have "very crude filters to prevent SQL injection attacks," and it is one of these filters that is preventing you from using some of refbase's functionality. (Note that refbase does escape user input and that when search.php receives a SQL query, the query is validated to make sure that it doesn't have potentially dangerous input & this check is less "crude" (as they say) than what mod_security is doing.) The particular mod_security check causes problems for many other webapps too. There is an "easy security" vs power/usability trade-off here. (Some argue that no webapp should permit any SQL-like string, but other argue that you lose a great deal of power and/or take on greater code maintenance costs in this.)
Good hosts will let their users write their own mod_security rules in an '.htaccess' file. Try adding a line to your .htaccess file in the refbase directory (creating it if it doesn't exist) that says:
And then test. Note that this turns ALL filtering off. You use it at your own risk. The reason I recommend TRYING this is merely to see if you're able to customize the filter with an .htaccess file. If it works, you might be able to run with the filter On, but with rules that you supply fed to it (and your rules wouldn't prohibit the relatively safe SELECT queries).
Outside of this, we can only provide work-arounds. Other webapps encode the SQL query (even doing relatively simple things like ROT13ing it) & then decode it in search.php.
Thanks for the response! So I can override the SecFilterEngine in my refbase directory, but am now wary of the risks associated with this that you mentioned. Perchance can you recommend any resources or specific approaches pertaining to adding rules to re-enable some of the security without compromising the functionality of Refbase?