Best practice security measures for an enterprise Rails app? - ruby-on-rails

What security measures should a Rails enterprise app have?
Examples of few security measures:
Admin area authenticated and IP restricted
No User added CSS, because of some old browsers can run JavaScript in CSS
Should User information in database be encrypted?

I would suggest looking over the Rails Security Guide which should go over the common pitfalls that you would usually encounter. Also check out the additional resources that they list on the guide:
The security landscape shifts and it is important to keep up to date,
because missing a new vulnerability can be catastrophic. You can find
additional resources about (Rails) security here:
The Ruby on Rails security project posts security news regularly:
http://www.rorsecurity.info
Subscribe to the Rails security mailing list
Keep up to date on the other application layers (they have a weekly
newsletter, too)
A good security blog including the Cross-Site scripting Cheat Sheet

There are a lot of essential security precautions such as a strong authentication system, validating user input to mitigate XSS and SQL injection attacks and escaping HTML at the views.
You can find information about common Ruby on Rails application vulnerabilities and their countermeasures at the Zen Rails Security Checklist.

Related

What are disadvantages of JAAS in comparison to Spring Security/Apache Shiro?

I've been looking at several frameworks that handle authentication and authorization (Apache Shiro, Spring Security, JAAS, Apache Wicket) and am wondering about the disadvantages of JAAS.
I've been reading that it is more complicated and only provides basic security, but I don't quite understand what that means. Also, I've heard to not use it if the application needs to be ported to another system - why is that?
'It provides only basic security' is nonsense. JAAS is a framework within which you can write whatever you need, so it therefore can provide whatever you want it to provide, from simple authentication to any level of role-based authorization, in association with Container Managed Authentication, which IMHO is the only sane way to manage web-app security.
The JAAS programming model I find a little odd, kind of inside-out, but you can do very powerful things with it: for example I built a webapp that would accept a login via either form, session ticket, expiring auto-login token (e.g. for password reset), or client SSL certificate, and in fact it is ideal for scenarios like this.

OWASP top ten attacks and Spring Security

I am evaluating security for my web application. As I am using Spring in my web application I would like to leverage the Spring Security framework. I searched for more info about web security and come across OWASP community and it's top 10 attacks list. So my question is; would it be suffice to configure Spring Security to secure my application? What all security threats out of OWASP top 10 (2013) are handled by Spring Security Framework?
Building secure applications is a challenging task and there is no "silver bullet" product which would make the application automatically secure for you. Therefore the simple usage of Spring Security certainly does not automatically mean that your application is secure! Spring Security is a great tool which helps with many aspects of building of secure applications, but like with any tool you need to know how to use it properly.
Spring Security can help you address at least the following OWASP TOP10 issues:
A2-Broken Authentication and Session Management - by providing mechanisms for efficient and secure authentication and session management
A4-Insecure Direct Object References - by providing mechanisms for authorization within application
A6-Sensitive Data Exposure - Spring Security's crypto module provides necessary cryptography capabilities
A7-Missing Function Level Access Control - by providing means for authorization in UI and server side
A8-Cross-Site Request Forgery (CSRF) - by providing support for generation and validation of tokens mitigating CSRF attacks
I advise to use a layered security architecture. I mean, it’s possible to create a secure application by hand but it’s extremely difficult to implement. Some security features such
as authentication and basic access control (url level or GUI component level) are relatively easy to implement but requirements such as instance level security (specially working with legacy databases), Sql Injection and XSS are harder.
I recommend to use Spring Security and implementing as much as possible custom validations. In addition to that I recommend to use HDIV in order to add an extra security layer that could
help to avoid the exploitation of risks not covered by custom validations. Specifically the features offered by HDIV are:
A1- Injection: regarding HTTP parameters’ values and urls HDIV reduce the risk of this vulnerability to only the data that come from text fields within forms, applying integrity validations (assures the received value is the same as the generated at server side) for the rest of the data that come from client side. For text fields included within forms, HDIV offers generic validations (whitelist and blacklist) in order to avoid injection attacks injection attacks.
A2-Broken Authentication and Session Management: HDIV doesn’t offer functionalities for
this web risk.
A3-XSS: the same as A1 but in that case to avoid XSS risks.
A4-Insecure Direct Object References: HDIV controls all the data
generated at server side ensuring the integrity of the data and
avoiding this vulnerability.
A5-Security misconfiguration: HDIV doesn’t include specific functionalities for that but doesn’t allow the access to resources not sent by the server previously, avoiding the exploitation of unexpected behaviors or access to private resources.
A6-Sensitive Data Exposure: HDIV offers confidentiality feature to
hide the values of HTTP parameters.
A7-Missing Function Level Access Control : thanks to the integrity validations implemented
by HDIV, avoids the exploitation of this vulnerability and limit the user to execute legal actions and maintaining the original contract (GUI or API) offered by the
application.
A8-Cross-Site Request Forgery (CSRF): HDIV adds aleatory tokens to
avoid this vulnerability
A9-Using components with known vulnerabilities: HDIV doesn’t include
specific functionalities for that but thanks to the interaction
limitations applied to the user in many cases is not possible to
exploit the vulnerability.
A10-Unvalidated redirects and forwards: This vulnerability is
mainly related to the manipulation of non editable data or data
generated previously at server side. HDIV controls all the data
sent by the server and doesn't allow the redirection to malicious
web sites.
In addition to these functionalities to protect from OWASP top ten web risks, HDIV generates also logs related to the malicious activity or attacks against your web site including all the information about the attack and the username within authenticated web sites.
Regards,
Roberto Velasco (HDIV team)
You can try HDIV which has support for multiple frameworks.

how to identify the user on subsequent requests to asp.net mvc web app

I am building an ASP.net MVC web application and I am starting to look into security.
What would be the best way to identify the user on subsequent requests (after they have logged in). I'm thinking of some form of authentication token or maybe using a cookie?
Ive read about Forms-Based Authentication but I'm not sure what would be a good approach?
This is a very broad question and there are many ways to answer it. I would recommend that you learn the basics of identity and access in ASP.NET by reading each topic in the ASP.NET Identity section and understanding what options you have. At a basic level, you need a mechanism to register users in a repository/database of some sort, validate their credentials when they log in, and a way to persist their user session in a browser (such as via a cookie). All of this is discussed in that section with examples.
The good news is that there are many valid authentication options that are pretty easy to implement and don't require you to be an expert on security. You can create/maintain your own member database, use Windows authentication, outsource authentication entirely to external identity providers such as Facebook/Google/Azure Active Directory/etc, and so on. The new tooling in Visual Studio 2013 also makes this much easier for you to manage. I would highly recommend you familiarize yourself with all of these options before jumping in and writing any code.

Ruby on Rails API Security

For a recent project a friend of mine and I have been working on, we want to build a RESTful web API for client application usage. I believe that I have a fairly good grasp of the top-down picture after reading this, but am fairly clueless when it comes to security issues.
I know of OAuth and plan on implementing it, but are there any other concerns we should address first thing? I would hate to spend a large amount of time developing these features to find out later that we've left the site open for malicious attack.
Thanks.
If you are looking for general information on Web security, check out OWASP Ruby on Rails Security Guide V.2. (There's also a first edition which I read back in the day.) Check out OWASP's web site for more security related information.
A few more resources for you:
Great walkthrough of common web attacks and how to deal with them in rails
https://www.honeybadger.io/blog/guides/2013/03/09/ruby-security-tutorial-and-rails-security-guide
Rails insecure defaults
http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults
All about sql injection, goes beyond the simple examples
http://rails-sqli.org
New security issues are listed at

User authentication support for Rails, NOT authorization

Which authentication plugin for Rails would you choose? I'm not interested in the permissions, roles and other authorization stuff.
I'm interested in the:
user model/controllers generation
predefined components to support various ways of authentication (HTML form, OpenID) with various back-end (database, LDAP, textfile).
I'm looking for something similar to the Java Spring Security (formerly Acegi) but for Rails platform.
Kind regards.
Check out Authlogic. It's incredibly flexible and simple to get started.
Other options:
Clearance
Devise (Rack-based)
Ruby Toolbox provides a nice list of Rails Authentication plugins.
I used restful_authentication in the past but I switched to authlogic 1 year ago.
Authlogic is an excellent and high customizable plugin, there are also additional third party plugins to support OpenID and Facebook logins.
I heard good words about Clearance but I never used it.

Resources