Skip to main content

Use of an insecure channel - HTTP

Need​

Secure transmission of client information

Context​

  • Usage of Ruby for building web applications and scripting
  • Usage of Rails for building web applications

Description​

Non compliant code​

# config/environments/production.rb
Rails.application.configure do
  config.force_ssl = false
end

In the above code, the application is configured not to force SSL in the production environment. This means that the application allows HTTP connections, which are insecure.

When config.force_ssl is set to false, Rails does not automatically redirect HTTP requests to HTTPS. This means that any data transmitted between the client and server - including potentially sensitive information like usernames, passwords, and credit card numbers - is sent in plain text and can be intercepted by attackers.

This vulnerability is particularly dangerous because it can lead to data breaches and other serious security incidents. To protect against this type of attack, you should always force SSL in production environments.

Steps​

  • Enable SSL/TLS encryption for the application
  • Set the 'config.force_ssl' option to true in the production environment configuration file
  • Ensure that the application is deployed on a server that supports HTTPS
  • Obtain and install a valid SSL/TLS certificate for the application domain
  • Redirect all HTTP requests to HTTPS to enforce secure communication

Compliant code​

# config/environments/production.rb
Rails.application.configure do
  config.force_ssl = true
end

The above code snippet is a fix for the insecure channel vulnerability in a Ruby on Rails application. The config.force_ssl option is set to true in the production environment configuration file. This forces the application to use SSL/TLS encryption, ensuring that all data transmitted between the client and the server is encrypted.

This change will make the application use HTTPS instead of HTTP, which is a secure protocol. HTTPS uses SSL/TLS to encrypt the data during transmission, making it difficult for attackers to intercept and read the data.

However, simply changing this configuration is not enough. The application must be deployed on a server that supports HTTPS. This usually means that the server must have a valid SSL/TLS certificate installed. The certificate can be obtained from a Certificate Authority (CA). There are many CAs that offer free certificates, such as Let's Encrypt.

Once the certificate is installed on the server, all HTTP requests to the application will be automatically redirected to HTTPS. This ensures that even if a user tries to access the application over HTTP, they will be redirected to the secure HTTPS version of the application.

This fix significantly reduces the risk of data being intercepted during transmission, protecting sensitive user data and enhancing the overall security of the application.

References​

Last updated on