Welcome to 60cycle.net, David van Geest's home on the web. Feel free to look around!
Missing foreign key constraints in Rails test database
Tuesday, April 6, 2010 - 6:18 pm
Wondering why your foreign key constraints are never created in your Rails test database? Chances are you, like me, are creating your referential integrity constraints using execute calls in a migration. These database-implementation-specific statements cannot be included in the DB-independent schema.rb file, so when you run rake test:db:prepare (or it is called implicitly by rake test:functionals), your FK constraints are not included in the test database.
The workaround to this is simple. In your environment.rb file, add (or uncomment) a line as follows:
config.active_record.schema_format = :sql
Now Rails will load the test DB structure from db/development_structure.rb, which should be automatically created when you run your tests. You can also create it manually using rake db:structure:dump.
60cycleCMS 2.5.1 released
Saturday, March 27, 2010 - 3:19 pm
I know, two posts about 60cycleCMS in one day :-). Supporting the webmaster over at aegamestudios while he was installing 60cycleCMS motivated me to put together another release.
60cycleCMS 2.5.1, ironically, considering my previous post, does address a potential security vulnerability. While previously I was using a somewhat lame white-list filter to filter input from the URL "post" parameter, I've switched to using PHP's real_escape_string() from mysqli. While I'm not sure of the exact method, I suspect my previous white-list filter could have been bypassed, and an attacker could have done some damage with SQL injection. Using real_escape_string() should completely mitigate this potential vulnerability.
This release also includes a custom negative CAPTCHA (in addition to ReCAPTCHA) to protect against spammers with a bunch of human CAPTCHA breakers from some disadvantaged country. Lastly it includes CSS stylesheet listing all the custom classes used by 60cycleCMS, for easier customization (thanks to Madison at aegamestudios.com for that suggestion).
As always, you can download the latest zip from the project page, or checkout the latest code from svn.
0 commentsSupposed security vulnerabilities in 60cycleCMS
Saturday, March 27, 2010 - 2:49 pm
Googling 60cycleCMS these days brings up a few "security vulnerabilities" that, at first glance, are somewhat alarming. The first alleged vulnerability is generally described as an HTML injection or a persistent XSS (cross-site scripting) vulnerability. Here's a link to a report (the reports tend to multiply across the web, so there are other sites describing the same exploit).
I'm all for transparency and openness in coding, and I'm glad people take time to expose vulnerabilities in others' code. However, this XSS "vulnerability" really needs to be put in context.
The XSS exploit states that an attacker can insert malicious HTML or Javascript into an existing post using the "Edit" feature of 60cycleCMS because the user input is unvalidated. While the unvalidated input part of this exploit is true, it is intentional and, when the CMS is installed as intended, does not expose the website to attack. Let me elaborate somewhat. The user input is unvalidated to allow a website author to post any HTML content they want. When I write this post I don't want to fight my own HTML filters. Secondly, the page in question (private/select.php?act=edit) is a private page, if the exploit author had bothered to read the readme or install the CMS, he would have noticed that install process password protects that area of the site using an .htaccess file. Therefore, only the website author (presumably trusted....) may post unfiltered HTML and/or Javascript on the site. If you were to un-protect the private admin section of the site, then this exploit would be possible, but then of course an attacker could do anything they wanted to, whether it be deleting your posts or changing your database configuration. Presumably my users are not stupid enough to leave themselves open this way.
The second supposed vulnerability is a remote file inclusion vulnerability. Here's a link. Originally posted over at exploit-db.com, this exploit claimed that you could include a remote file in the PHP powering the CMS, thus allowing you to execute arbitrary code on the webserver. The "exploit" centered around overwriting the $_SERVER variable so that the CMS would load the config.php file from another location besides the usual (one level above website root). This vulnerability is just plain false. PHP does not allow a remote user to override the $_SERVER variable, for obvious reasons. There's an email thread discussing this in more detail here. The exploit has been removed from ExploitDB (I can only assume because it is incorrect), but a few sites around the web still have it up.
The point is, don't believe everything you read on the web. It would seem there's people out there trying to make us think they're l33t hackers by exposing security vulnerabilities when, in reality, they don't do their homework and are sometimes just plain wrong. If you do have any concerns about the security of 60cycleCMS, please contact me or leave a comment, and I will be happy to discuss your concerns.
1 comments
