CSC/ECE 517 Fall 2014/ch1a 23 ss: Difference between revisions
Line 63: | Line 63: | ||
All non GET request should use a security token. | All non GET request should use a security token. | ||
== User | == Application Logic == | ||
There are certain common functionality that most applications need to implement. If these are not implemented correctly, then they can cause a security vulnerability. Rails provide plug ins that make the job easier to implement. Some common cases are discussed below. | |||
===User Authentication=== | |||
Most web applications have to deal with user authorization and authentication. Hence it is up to the programmer to implement it correctly. Rails provide built in "''has_secure_password'' feature that stores the password in encrypted manner. | Most web applications have to deal with user authorization and authentication. Hence it is up to the programmer to implement it correctly. Rails provide built in "''has_secure_password'' feature that stores the password in encrypted manner. | ||
*Brute Force Attack | *Brute Force Attack | ||
Line 70: | Line 73: | ||
*Logging:Rails should be configured to not put passwords into log files by using "''config.filter_parameters'' in application configuration. | *Logging:Rails should be configured to not put passwords into log files by using "''config.filter_parameters'' in application configuration. | ||
*Anchor Regular Expressions:Ruby has extensive options that can be used to anchor it at the line beginning and line end. | *Anchor Regular Expressions:Ruby has extensive options that can be used to anchor it at the line beginning and line end. | ||
===File Upload=== | |||
Many applications allow user to upload files. Use Rail plugin to handle unsafe file names and file upload. | |||
===SQL Injection=== | |||
It is possible that the attacker can manipulate web application parameters by influencing database queries. | |||
Rails can prevent such attacks by providing filters for special SQL characters which escapes ',' NULL character and line breaks. | |||
===Command Line=== | |||
Ruby provides api like "''system(command, parameters)'' which passes command line parameters safely. | |||
= Security Enhancements = | = Security Enhancements = |
Revision as of 18:42, 18 September 2014
Security Features in Rails 4.x
Web applications can be challenging for a developer to properly secure against threats. There are many attack vectors against web applications that must be carefully considered and mitigated. The developer must be responsible to understand these threats and take the necessary steps to secure the application and data. A web application may be vulnerable due to misconfiguration, poorly written code, or through un-patched vulnerabilities.
Ruby on Rails, or just Rails, is a web application framework written in Ruby. It is a full-stack framework which attempts to make the development process easier and more accessible. This wiki aims to highlight all the security features in a Rails 4.x.
Threats Against Web Applications
Cookie Management
Cookies are used to maintain stateful sessions in HTTP. The cookies typically contain the user's session id which is used to identify the user. By stealing it, the attacker can use the application in the victim's name. More over since the data is stored on the client machine, programmers should not store sensitive data in cookies.
The cookie is sent in the clear and so the easiest way for the attacker is to sniff the packets. This attack is shown below in Figure 1.
Figure1: Packet Sniffing Attack
To manage the cookies Rails provide several options to the programmer.
Use SSL
SSL prevents the attacker from sniffing the cookie from the network.
config.force_ssl = true
New Session Identifier
Configure Rails to issue a new session identifier and declare the old one invalid after a successful login.
Fast Timeout
Set the expiry time stamp of the cookie to a small value so that chances of attacker using a stale cookie is minimized.
Injection
An attacker can inject client site executable code. When the victim renders it, it can steal the cookie, hijack the session and redirect the victim to a different page.
Cross Site Scripting (XSS)
XSS is an attack where an adversary places client-side code in the web application, often through a valid method such as posting to a message board. This code is then viewed by other application users and executed by their client machines.
This attack is mitigated by properly sanitizing any input to the application. <ref>https://www.netsparker.com/blog/web-security/ruby-on-rails-security-basics/</ref> The sanitize method may be used to strip improper code from user input.
Input to be sanitized:
<%= sanitize '<img src=x onerror=prompt(1)>' %>
Sanitized output:
<img src=“x”>
SQL Injection
SQL injection is a very common and serious vulnerability for many applications. The generalized concept is to pass carefully crafted input that will eventually get passed as parameters in a SQL statement. In July of 2014, Rails developers released version 4.1.3 in order to patch a serious vulnurability affecting applications using a PostgreSQL database system. <ref>http://www.computerworld.com/article/2489654/malware-vulnerabilities/ruby-on-rails-patches-tackle-sql-injection-vulnerabilities.html</ref> This vulnerability allowed attackers to inject arbitrary SQL code into the affected Rails applications.
Mitigation here.
Ajax Injection
Header Injection
Cross Site Request Forgery (CSRF)
This attack method works by including malicious code or a link in a page that accesses a web application that the user is believed to have authenticated. If the session for that web application has not timed out, an attacker may execute unauthorized commands.
Security Token
All non GET request should use a security token.
Application Logic
There are certain common functionality that most applications need to implement. If these are not implemented correctly, then they can cause a security vulnerability. Rails provide plug ins that make the job easier to implement. Some common cases are discussed below.
User Authentication
Most web applications have to deal with user authorization and authentication. Hence it is up to the programmer to implement it correctly. Rails provide built in "has_secure_password feature that stores the password in encrypted manner.
- Brute Force Attack
- Good Password: Ensure that the user password are "random" enough. Rails make it easy to define requirements for the password field in the model.
- Implement CAPTCHAs:This is a challenge response test that determines that the response is not generated by a computer. Rails provide extensive API for implementing it.
- Logging:Rails should be configured to not put passwords into log files by using "config.filter_parameters in application configuration.
- Anchor Regular Expressions:Ruby has extensive options that can be used to anchor it at the line beginning and line end.
File Upload
Many applications allow user to upload files. Use Rail plugin to handle unsafe file names and file upload.
SQL Injection
It is possible that the attacker can manipulate web application parameters by influencing database queries. Rails can prevent such attacks by providing filters for special SQL characters which escapes ',' NULL character and line breaks.
Command Line
Ruby provides api like "system(command, parameters) which passes command line parameters safely.
Security Enhancements
CSRF via Leaky #match Routes
Regular Expression Anchors in Format Validations
Clickjacking
User-Readable Sessions
Automated Security Scanners
http://brakemanscanner.org/docs/introduction/
Unresolved Issues
Verbose Servers Headers
Binding to 0.0.0.0
Versioned Secret Tokens
Logging Values in SQL statements
Offsite Redirects
Reference
http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/
http://guides.rubyonrails.org/security.html
<references />