[1.5.3] Error 500 when using words "select" and "from" in description / comment

[MadPole]

applies to: task description, comment, title and possibly any other text field

Entering following or similar text in task description, comment or title:

[...] user selects another page from already loaded website [...]

causes Error 500: Internal Server error

Changing text to following or similar:

[...] user selects another page ffffrrrrroooommmm already loaded website [...]

resolves the problem

I suspect some bit of software is recognizing this as SQL and trying to execute it?

Browsers: Firefox 3.5.3, Safari 4.0.3
Linux Kernel version     2.6.9-67.0.22.ELsmp
Apache version     2.2.11
PHP version    5.2.9
MySQL version     5.0.85-community
define('DEBUG', true);
no messages in error_log or cache/log.php

Cheerio!

[paulscallanjr]

You may want to try what I did to fix my Error 500.  http://forums.opengoo.org/index.php?topic=3035.0

[MadPole]

Hmmm.... hmmm... hmmm... many thanks for your help Paul, which inspired me to revisit and try to generate some error messages - but the problem mysteriously went away!  I've just gone through all the items where the problem occurred and changed misspelled "from" to correct spelling... without any issues! 

I haven't updated the installation so damn me if I know what's going on but phew nevertheless!
 

Cheers!

[brian_enotion]

I am also experiencing this issue with any comments that match the pattern:

 /select(*+)from/

Whenever I attempt to post a comment that matches this pattern, such as "...select the commits from...", I receive a 500 error.

I'm running:
- OpenGoo 1.5.3 (auto updated)
- PHP 5.2.6
- Apache 2.2.11

[brian_enotion]

Ok, after a bit more digging, I determined that OpenGoo is not the source of this issue.   Apache ModSecurity is to the guilty culprit.  In checking my httpd error logs I see the following line:

[Fri Nov 06 14:17:11 2009] [error] [client 111.222.333.444] ModSecurity: Access denied with code 500 (phase 2). Pattern match "(insert[[:space:]]+into.+values|select.*from.+[a-z|A-Z|0-9]|select.+from|bulk[[:space:]]+insert|union.+select|convert.+\\(.*from)" at ARGS:comment[text]. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "355"] [id "300016"] [rev "2"] [msg "Generic SQL injection protection"] [severity "CRITICAL"] [hostname "foo"] [uri "/opengoo/index.php"] [unique_id "SvR2N0PhhX4AABRsAWUAAAAP"]

Apparently ModSecurity is just running overly broad regexes against all incoming data, and throwing 500 errors for anything that matches.  Is this a form of security?  Technically I guess it is, but only in the way your car becomes "safer" once you remove the ignition and weld the doors shut.

To get around this issue you must selectively remove rules from ModSecurity, as explained here (thereby rendering ModSecurity pretty much useless):

http://www.linuxquestions.org/questions/linux-server-73/apache-modsecurity-fixing-false-positives-613609/

Why is this kind of dumb handling necessary, or even advisable, with all the modern protections against SQL injections (active records, bind variables, etc.)?  Who knows.

[brian_enotion]

For anyone interested, here's how you selectively turn off just the SQL injection rules in ModSecurity 2 for a particular URI path (in this case, the path to OpenGoo):

1) Edit /path/to/apache/conf/modsec2/whitelist.conf

2) Add the following line:
SecRule REQUEST_URI "/opengoo" phase:1,nolog,allow,ctl:ruleEngine=Off

3) Change "opengoo" to the correct path for your OpenGoo installation.

4) Restart Apache.

Note that this fix is only for ModSecurity 2 on Apache 2.

[ignacio]

Thanks for you tip!