Initial commit (history cleared)
CI / test (3.4.1) (push) Has been cancelled

This commit is contained in:
2026-04-29 11:21:39 +01:00
commit 298610b5f6
277 changed files with 30877 additions and 0 deletions
+123
View File
@@ -0,0 +1,123 @@
# Bonus: Encrypted Secrets in Rails 5.1+
This bonus section explains how modern Rails applications manage sensitive
information such as secret keys, API tokens, and credentials.
RailsGoat intentionally does NOT follow these practices by default, because it
is designed to demonstrate insecure patterns for educational purposes.
However, real-world applications should always protect secrets properly.
---
## What Are Application Secrets?
Application secrets include:
- `secret_key_base`
- API keys
- OAuth client secrets
- Encryption keys
- Database credentials
If these values are exposed, attackers may be able to:
- Hijack user sessions
- Forge cookies
- Access third-party services
- Decrypt sensitive data
---
## The Problem with Hardcoded Secrets
Hardcoding secrets directly in source code is dangerous because:
- Source code is often shared publicly
- Secrets can be leaked via Git history
- Compromised secrets are difficult to rotate
Example of an insecure approach:
```ruby
SECRET_KEY_BASE = "hardcoded_secret_value"
```
Once committed, this secret is effectively public forever.
---
## Rails 5.1: Encrypted Secrets
Rails 5.1 introduced encrypted secrets using `config/secrets.yml`.
A typical secure configuration looks like this:
```yaml
production:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
```
In this approach:
- Secrets are stored outside the codebase
- Environment variables are injected at runtime
- Different environments can use different secrets
This pattern is commonly used in:
- Docker
- CI/CD pipelines
- Cloud platforms
## Rails 5.2+: Encrypted Credentials
Rails 5.2 introduced encrypted credentials, which are now the recommended
approach.
Credentials are stored in:
- `config/credentials.yml.enc`
They are encrypted using a master key stored in:
- `config/master.key`
Credentials are edited using:
```bash
rails credentials:edit
```
Example usage in application code:
```ruby
Rails.application.credentials.secret_key_base
```
## Important Rules
- `master.key` must **NEVER** be committed to version control
- `credentials.yml.enc` **is safe** to commit
- Secrets can be rotated without changing application code
---
## Why RailsGoat Is Different
RailsGoat intentionally avoids secure secret management in order to:
- Demonstrate insecure patterns
- Teach developers how vulnerabilities arise
- Provide hands-on security training
This is a deliberate design choice and should **NOT** be copied into real
applications.
---
## Recommended Best Practices
For real-world Rails applications:
- Never hardcode secrets
- Use environment variables or encrypted credentials
- Never commit `master.key`
- Rotate secrets regularly
- Restrict access to production secrets
+80
View File
@@ -0,0 +1,80 @@
## Openshift Deployment
To deploy Railsgoat with Openshift you must first have a working [Openshift Cluster](https://docs.okd.io/latest/welcome/index.html) installed. The Railsgoat Openshift deployment currently supports Postgres on the native Openshift Postgres imagestream.
```bash
$ oc new-project railsgoat --description="Railsgoat Openshift Deployment" --display-name="Railsgoat"
```
## Edit the Build Strategy
Since Railsgoat supports both normal Docker deployment and openshift deployment, the Openshift deployment is located in the `openshift-configs` directory. Find the railsgoat build in your openshift deployment and edit the dockerStrategy so that it reads something like:
```
strategy:
dockerStrategy:
dockerfilePath: openshift-configs/Dockerfile
from:
kind: ImageStreamTag
name: 'ruby:2.6.5'
namespace: railsgoat
type: Docker
```
### Creating a Database Service
Although Railsgoat in Openshift can be used with the development SQL Lite database, it also takes advantage of the PostgreSQL database image in Openshift for more creative demonstrations and an expansion of SQL attacks. To create the database service you will use the `oc new-app` command and will need to pass some environment variables. You can change these to anything you want.
```bash
$ oc new-app postgresql -e POSTGRESQL_DATABASE=db_name -e POSTGRESQL_USER=username -e POSTGRESQL_PASSWORD=password
```
You can also set the password for the database admin by appending the previous command with:
```bash
-e POSTGRESQL_ADMIN_PASSWORD=admin_pw
```
To deploy Railsgoat alongside the postgres database, you will need to run:
```bash
$ oc new-app https://github.com/OWASP/railsgoat.git --name=railsgoat -e POSTGRESQL_USER=username -e POSTGRESQL_PASSWORD=password -e POSTGRESQL_DATABASE=db_name -e DATABASE_SERVICE_NAME=postgresql -e RAILS_ENV=openshift
```
If you changed the database environment variables, make sure they match up.
Enter the deployments of your new Railsgoat project and locate the railsgoat deployment config. Add the following to the config under the container object.
```
command:
- /bin/bash
- '-c'
args:
- rails server -p 3000 -b 0.0.0.0
ports:
- containerPort: 3000
protocol: TCP
```
From the openshift console run the following where `<RAILSGOAT POD ID>` is the active pod (for example, `railsgoat-2-dkalf`):
```bash
$ oc rsh <RAILSGOAT POD ID>
```
From the terminal:
```bash
$ rails db:migrate
```
Create the railsgoat service using the template in the openshift-configs folder by either creating it in the openshift terminal window or pulling it directly from git.
```bash
$ oc create -f https://raw.githubusercontent.com/relotnek/railsgoat/master/openshift-configs/railsgoatservice.yaml
```
Expose the service
```bash
$ oc expose service railsgoat
```
Once the railgoat deployment is running navigate to the indicated route