Now that our site is mostly done we can check it meets security guidelines, and make it ready for production. We know how to push it to Heroku, but what else should we do to make it work more smoothly in production?
We have not addressed the various other security issues around oursite. We’ll do that now using the guidelines at OWASP. In particular, we can look through the RailsCheatsheet on how the OWASP guidelines can be implemented in Rails. You should also consult the Rails Guide on Security too. We’ll go through the one’s that affect our application. You should also look through this for other aspects that you might need to address with your own applications.
SQL Injection is always a problem. If we go and look through our query statements then we find we have no SQL queries in the models, and only the sessions_helper.rb file has a query, which is generated by the id of the user, which is taken from the user_id in the session. If our sessions were compromised, then this would be a problem.
In the controllers, only three of them have any extra SQL queries beyond those auto generated by Rails itself. In the travelagent_controller.rb file the index method retrieves the cabins for cruises to see which ones are booked. We use the line@cruise_cabins = Cabin.where([“ship_id = ?”,cruise.ship_id]).count(‘id’), which uses the approved escape paramaters and don’t take direct input from the user either.Similarly in the reservations_controller.rb and payments_controller.rb are also using escaped parameters in the SQL statements to further protect our code.
Sessions are being created by us, and destroyed when the person logs out, or closes their browser. We are not using the default. However, we could make this more secure by changing the value of how our sessions are stored. Open app/config/initializers/session_store.rb and change this line in bold (comment out the old line as shown) [If you don’t see this file, then skip down to below the code snippet]:
# Be sure to restart your server when you modify this file.
#Rails.application.config.session_store :cookie_store, key:’_travelagent_session’
Rails.application.config.session_store:active_record_store, key: ‘_travelagent_session’
The file app_name/config/initializers/session_store.rb might not exist in your version of Rails and it cannot be just created by ourselves because all the corresponding code had been outsourced into a gem.
Therefore, to use this feature, we need to include the following gem into our Gemfile:
gem ‘activerecord-session_store’
And then follow the installation guide from https://github.com/rails/activerecord-session_store
Authentication is being sorted by what we did previously, and you’ll see that we too are using the ‘before_filter’ method to ensure all page requests flow through our authentication process. The only exceptions are the ones we set up for the login and registration pages. We could, as noted, require a password to be more complex, and/or longer too. Go read Jeff Attwood’s discussion of passwords, if you’re in doubt or on the fence about passwords. He’s one of the people everyone in computing should be aware of and whose blog posts you should read for general background information.
Insecure Direct Object Reference or Forceful Browsing was taken care of in practical four when we added the ‘redirect_if_not_found’ method to the application_controller.rb file so that people look for items, which aren’t there. While we stop errors, we aren’t doing any checking of who has authorisation to view these records. It’s not so serious to change to a different ship by changing a digit in the URL from http://localhost:3000/ships/65 to http://localhost:3000/ships/66, but it would be quite different if these were bank accounts. A better approach would be to not display the item ID in the URL as we do now. Go look at friendly_id gem for more information on using this approach for applications, and maybe consider using it for your assessment.
Deploying to Production
There are a number of options here, so we’ll only look at the topics, and some of the components, which you might use to deploy your application in production.
Deploy to a Linux server.
Use Puma for the web server.
Use Postgresql for the database.
Beyond the Practical
Go read some of the following for more materials on deploying to production, and making your application secure:
http://www.akitaonrails.com/2016/03/22/is-your-rails-app-ready-for-production
https://medium.com/@manishyadavv/how-to-deploy-ruby-on-rails-apps-on-aws-ec2-7ce55bb955fabut don’t use unicorn
https://aws.amazon.com/developer/language/ruby/
https://guides.rubyonrails.org/security.html
https://guides.rubyonrails.org/configuring.html
Assuming that you might still have some time left, do more work on your assessment site.
