Follow-up of your comments:
- Dan Kubb has some interesting comments about the OS security, and uses MySQL in a strict mode by using the sql-mode directive in my.cnf:
sql-mode = ansi,traditional,no_engine_substitution,
no_auto_value_on_zero,no_dir_in_create,
no_unsigned_subtraction - And, yes, the MySQL user I’m creating is only for “normal” Rails access, not for db migration or testing. I agree, Rails/Rake should provide means to use a different user for migration works.
Next up I’m preparing the web server section, after that the Rails specific security. Here are some links which address Rails’ security and more:
Security checklist
Security concerns in the Rails wiki
Some basic countermeasures in a Rails book
And my favorite Hacme Casino with lots of security holes
The OWASP Top 10 security flaws
Bookmark to
3 responses so far ↓
1 NeoMike // Mar 5, 2007 at 11:25
How about this?
From an example database.yml
development:
adapter: mysql
database: development
username: devUser
password: devPassword
host: localhost
development-migration:
adapter: mysql
database: development
username: migrateDevUser
password: migrateDevPassword
host: localhost
Then you can simply:
rake db:migrate RAILS_ENV="development-migration"
Although the password is still in a file accessible by the code, it does help with a few problems, such as accidentally running “rake db:migrate” or the application having the ability to change the schema.
2 Dee Zsombor // Mar 5, 2007 at 12:59
It’s quite simple to tweak a rails project to have a second database user just for running migrations. I’ve documented the steps at: http://deezsombor.blogspot.com/2007/03/rails-tip-use-separate-user-just-for.html
3 Admins Log // Mar 6, 2007 at 10:58
Ruby on Rails security…
Neu auf dem Markt und klasse Idee, da hier eindeutig eine “Marktlücke” herrschte: Ruby on Rails Security.
……
Leave a Comment