Fixing the most common vulnerabilities in Ruby apps

Introduction

Ruby is a popular programming language that is widely used for developing web applications. While Ruby offers many advantages, such as ease of use and flexibility, it also has its vulnerabilities. Attackers can exploit these vulnerabilities to steal sensitive data, cause system disruptions, and launch various cyberattacks. Therefore, it is crucial for developers to take proactive measures to secure their Ruby applications and protect user data.

In this blog post, we will discuss some of the most common Ruby security vulnerabilities and measures that developers can implement to prevent these vulnerabilities and secure their Ruby applications. 

Top Ruby Security vulnerabilities and How to Mitigate them

1. Secrets

If secrets such as passwords, API keys, and other sensitive information are hardcoded in the application code, they can be easily accessed by anyone who has access to the code, including attackers. Attackers can even leverage if the error message from the application contains secrets. Additionally, using weak protocols and encryption allows attackers to gain access to the secrets. 

How To Handle Secrets

• Do not hardcode secrets: One should never hardcode secrets in the application code. It is better to store secrets in a configuration file that is not included in the version control system or in environment variables.
• Use Encryption: It is important to use strong encryption algorithms and keys to protect secrets. Use encryption to secure data at rest when stored on a system or database, and when data is in transit. 
• Use password managers: Password managers allow you to securely store and manage your passwords and other sensitive information, such as API keys and cryptographic keys. They use strong encryption algorithms to protect your secrets, making them difficult to decrypt even if an attacker gains access to passwords. 

2. Vulnerable Libraries

Ruby has a rich ecosystem of libraries and frameworks that developers can use to build their applications quickly and efficiently. There are thousands of libraries for Ruby and an application might be using several of these. However, if these libraries have vulnerabilities, they can be exploited by attackers to gain unauthorized access to the application or to perform other malicious activities. 

How To Reduce Risks From Vulnerable Libraries

• Remove unused libraries: The more libraries you have in your application, the greater the chance that one of them may have a vulnerability that can be exploited by an attacker. By removing unused libraries, you can reduce the attack surface of your application and make it more secure.
• Keep libraries up to date: Regularly update the third-party libraries you are using to the latest versions to ensure that you have the latest security patches. You can implement a patch management process to ensure that libraries are updated efficiently and as soon as possible. 
• Use trusted sources: Only use libraries from trusted sources, such as the official RubyGems repository, and verify the authenticity of any libraries you use before including them in your application.

3. SQL Injections

SQL injection is a common vulnerability in web applications, including those written in Ruby. A SQL injection attack occurs when an attacker can inject malicious SQL code into an application’s SQL query. This can allow the attacker to perform unauthorized actions, such as bypassing authentication, accessing sensitive data, or modifying data in the database.

SQL injection vulnerabilities exist when an application does not properly validate user input for its format, type, or length, or does not securely process user input when used as part of SQL queries. 

Let’s say you have a simple Ruby application that takes a user’s input for their username and password to log them into the application:

username = params[:username]

password = params[:password]

sql = “SELECT * FROM users WHERE username = ‘#{username}’ AND password = ‘#{password}’”

result = ActiveRecord::Base.connection.execute(sql)

The application uses string interpolation to construct a SQL query. The SQL query is finding an entry in the users database where the username and password in the database match the username and password given as inputs to the application. If there is such an entry, it means that the provided credentials are valid and the user is logged in. 

An attacker can inject SQL code into the query by providing input that includes SQL keywords or special characters. For example, an attacker could provide the following input:

username: ‘ OR 1=1; —

password: anything

This would result in the following SQL query:

SELECT * FROM users WHERE username = ” OR 1=1; –‘ AND password = ‘anything’

In this case, the injected code will cause the SQL query to be a true statement because 1 is equal to 1. The — in the input is a SQL comment that effectively disables the rest of the query. Therefore, the attacker can log in without needing a valid password.

How To Fix SQL Injection Vulnerability

• Use parameterized queries: Use parameterized queries or prepared statements instead of concatenating user input with SQL code to construct a query. Parameterized queries ensure that user input is treated as a parameter rather than as part of the SQL query itself, making it much more difficult for an attacker to inject malicious SQL code.
• Validate user input: Validate all user input, including form fields and query parameters, to ensure that it conforms to the expected format and length.
• Limit database privileges: Use the principle of least privileges when setting up your database. Only grant the minimum set of privileges necessary for your application to function properly.
• Sanitize input and output: Use a sanitization library to sanitize all input and output, such as the Ruby gem called Rack::Attack. This can help prevent malicious input from being processed by your application and can also help prevent malicious output from being returned to the user.

4. Command Injection

Command injection is a security vulnerability that occurs when untrusted user input is insecurely passed to a system shell, which can execute arbitrary commands on the underlying operating system. For example:

system(“ls #{params[:dir]}”)

If an attacker can control the value of params[:dir], they could inject additional shell commands that will be executed alongside the intended ls command. For example, if params[:dir] is set to “; rm -rf /“, the shell command that will be executed is:

ls ; rm -rf /

First, the system will execute the ls command and then the rm command. This command will attempt to delete all files on the system.

How To Fix Command Injection Vulnerability

• Sanitize input: To prevent command injection, you need to sanitize any user input that is being passed to a system call. This involves removing any special characters that could be used to inject additional commands. You can use Ruby’s built-in Shellwords.escape function to sanitize user input before passing it to a system call.
• Avoid using system calls: If possible, avoid using system calls altogether. 
• Run system commands with least privileges: If you do need to use a system call, make sure to limit the scope of the call and run it with the least privileges. This will prevent the malicious code from execution if it required higher privileges and can help to minimize the potential impact of any successful attacks.

5. Cross-Site Scripting

Cross-site scripting (XSS) occurs when untrusted user input is rendered on a web page without proper sanitization. It allows an attacker to inject malicious code that will be executed by the victim’s browser. 

Suppose you have a Ruby on Rails application that allows users to post comments on a blog. The comments are stored in a database and displayed on the blog page. The comment form would look something like this:

<%= form_for @comment do |f| %>

  <%= f.text_area :body %>

  <%= f.submit “Post Comment” %>

<% end %>

In this example, the user’s comment is stored in the body attribute of the Comment model. When the comment is displayed on the blog page, it is rendered as HTML:

<%= comment.body %>

If a user posts a comment with malicious code like this:

<script>

alert(‘Hello, World!’);

</script>

The comment will be stored in the database as-is. When the comment is displayed on the blog page, the <script> tag will be interpreted as HTML and the JavaScript code inside it will be executed in the victim’s browser, displaying an alert message that says “Hello, World!”. Attackers can use far more dangerous codes. 

How To Fix Cross-Site Scripting Vulnerability

• Use a templating engine for escaping: Ruby on Rails has built-in protection against XSS attacks by automatically escaping any user input that is rendered in a view.
• Sanitize user input: Sanitize any user input that will be rendered in a view. You can use a library like the htmlentities gem to escape special characters and prevent XSS attacks.
• Use content security policies (CSPs): CSPs can help to prevent XSS attacks by limiting the types of content that a browser will execute. You can use the secure_headers gem to easily implement a CSP in your Ruby application.
• Use HTTP-only cookies: By setting the HTTP-only flag on your cookies, you can prevent attackers from stealing them using XSS attacks. This doesn’t technically fix the vulnerability but limits its impact. 

6. Cross-Site Request Forgery

Cross-Site Request Forgery (CSRF) occurs when an attacker can trick a user into unknowingly sending a request to a web application. The request may include sensitive information or actions, such as making a payment or deleting data, and if successful, can compromise the security of the application and its users.

Suppose there is a Ruby web application that allows users to transfer funds between accounts. The application uses a simple form to accept input from the user, including the account number to transfer funds to, and the amount to transfer. 

Now, imagine that an attacker creates a fake web page with a hidden form that contains the same input fields as the legitimate application. When a user visits this fake page, the form is automatically submitted in the background, without the user’s knowledge or consent. If the user has an active session on the legitimate application, the fake form will be submitted with the user’s session token, allowing the attacker to make a fraudulent transfer on behalf of the user. This is an example of a CSRF attack. 

How To Fix Cross-Site Request Forgery

• Use CSRF tokens: CSRF tokens are unique, cryptographically-generated tokens that are added to each form or request submitted by the user. The server validates the token to make sure that the request was made by a legitimate user and not a malicious attacker. In Ruby, you can use the built-in form_authenticity_token method to generate and validate CSRF tokens.
• Use Resourceful Routing: Resourceful routing can help you manage your application’s routes more efficiently, and can also help prevent CSRF attacks. With resourceful routing, you can map a set of CRUD (Create, Read, Update, Delete) operations to a single controller, which can help prevent attackers from exploiting vulnerabilities in your routing structure.
• Set the SameSite Attribute: Set the SameSite attribute to ‘strict’ for cookies. When set to ‘strict’, cookies will only be sent with requests originating from the same domain. 

This brings us to the end of major Ruby on Rails vulnerabilities. 

Conclusion

As Ruby continues to grow in popularity as a web application development language, developers must take proactive steps to secure their applications and protect their users from potential cyber threats. We went through the 6 major Ruby on Rails vulnerabilities commonly found in Ruby applications and how to fix them. But the top 6 vulnerabilities are just the beginning. It’s important for developers to prioritize security throughout the development cycle and regularly identify and address potential vulnerabilities in their applications. If you’re looking to make this process easy, check out GuardRails. GuardRails makes it easy to find, prioritize and fix Ruby security vulnerabilities along with other languages, as early as they are created, saving everyone in the organization time and unnecessary stress. This improves the overall process of enhancing the security of your PHP applications and makes the lives of the developers and security teams easy.

The post Fixing the most common vulnerabilities in Ruby apps appeared first on GuardRails.

*** This is a Security Bloggers Network syndicated blog from GuardRails authored by GuardRails. Read the original post at: https://blog.guardrails.io/fixing-the-most-common-vulnerabilities-in-ruby-apps/