Cobalt Crowdsourced Application PentestCobalt Crowdsourced Application PentestCobalt Crowdsourced Application Pentest

Security

Practices


At Cobalt security is our absolute highest priority. Therefore we take myriad security measures to ensure that the data of our customers and security researchers is secure and safe. In the spirit of openness and transparency, here are some of the security measures we take to protect and defend the Cobalt platform.

Web Application Firewall

All Cobalt site traffic is proxied through CloudFlare. We leverage CloudFlare’s Web Application Firewall (WAF) to protect the site from:

  • Distributed denial of service (DDoS) attacks
  • Blocking of suspicious activity
  • SQL injection, comment spam
  • Possibility of quickly blocking IPs or entire countries

Encrypting Data in Transit

All HTTP-traffic to Cobalt runs over an SSL-encrypted connection and we only accept traffic on port 443. The status of our SSL configuration can be found here.

During a user agent’s (typically a web browser) first site visit, Cobalt sends a Strict Transport Security Header (HSTS) to the user agent that ensures that all future requests should be made via HTTPS even if a link to Cobalt is specified as HTTP. Additionally, current versions of Google Chrome and Firefox hardwire the site to HSTS, guaranteeing that requests are never – not even the very first – made over a non-encrypted connection. Cookies are also set with a secure flag.

Hosting and Database Storage

Cobalt is hosted via Heroku and managed within Amazon data centers that leverage secure Amazon Web Service (AWS) technology.

Encrypting Data at Rest, Database

Cobalt’s backend is supported by a Postgres database to persist data. All data at rest and associated keys are encrypted using the industry-standard AES-256 algorithm. Only once an authorized user is granted access to their data will that subset of data be decrypted. For further details around the encryption at rest please see AWS encryption procedures.

Encrypting Data at Rest, Files

Static files, such as images and other documents are persisted using AWS S3 storage. All static files are encrypted before they’re stored so while at rest they are encrypted.

AWS security Practices

Amazon Web Services undergoes recurring assessments to ensure compliance with industry standards and continually manages risk. By using AWS as a data center operations provider, our data center operations are accredited by:

More information about AWS security can be found here.

Password Policy and Storage

During an account creation and password update, Cobalt requires a strong password that has 8 characters or more, and contains numbers as wells as lower- and uppercase letters. We do not store user passwords: we only store one-way encrypted password hashes using open source audited Bcrypt, including:

  1. Cost ratio 2^12 iterations - delaying brute-force attacks
  2. Per-user-random-salt - protect against rainbow table attacks and encrypted password matching
  3. Password concatenated with two individual app-tokens

If a user incorrectly enters an account password on multiple attempts, the account will be temporarily locked to prevent brute-force attacks. To further protect account access, Two-factor authentication is available to all Cobalt users who use either Google Authenticator or Authy, and can be turned on via the user account security settings.

Following an email change, password change or similar sensitive user account changes occur, the user is always notified in order to quickly be able to respond, should an account attack be undergoing.

Request Throttling and Tracking

We employ Rack::Attack middleware for whitelisting, throttling, and tracking based on predefined security limits of the request.

XSS and CSRF Protection

To prevent Cross-Site Scripting attacks (XSS) all output is per default escaped in our Ruby on Rails framework before hitting the browser potentially causing XSS attacks. We avoid the use of the raw() method potentially causing unwanted data being sent to the browser.

In our Ruby on Rails framework protect_from_forgery is enabled and generates a random csrf_token to prevent against Cross Site Request Forgery (CSRF) attacks.

In addition to these measures, we regularly perform automatic site scans for injection and XSS attacks using external tools like Tinfoil security scanner.

Additionally, Cobalt has implemented the Content Security Policy (CSP) HTTP header which whitelists which assets (javascripts, images, stylesheets, etc.) the user's browser should allow to load and execute. A correctly implemented CSP-header effectively eliminates any malicious javascript (XSS attacks), specially crafted files covered up as images, and similar attacks based on the browser’s trust of the served assets.

Organization

We require all employees to use strong, unique passwords for Cobalt accounts, and to set up two-factor authentication with each device and service where available. All Cobalt employees are required to use recognized password managers like LastPass or 1Password to generate and store strong passwords, and are also required to encrypt local hard drives and enable screen locking for device security. All access to application admin functionalities is restricted to a subset of Cobalt staff and restricted by IP and other security measures.

Monitoring and Notifications

Cobalt uses several services to automatically monitor uptime and site availability. Key employees receive automatic email and SMS notifications in the case of downtime or emergencies. Some of our preferred services for logging and 24h-notification-access are New Relic, and MX Toolbox.

Code Review and static code analysis

Cobalt institutes strict code reviews of changes to sensitive areas of our codebase. We also employ Brakeman for static security code analysis to automatically detect potentially known vulnerabilities through static source code analysis.

Bug Bounty Program

Since launching Cobalt, we’ve instituted our own bug bounty program open to our community of security researchers to further strengthen and secure our code. All vulnerability report submissions are read within hours of receipt, and we aim to respond to all submissions within 48 hours.

Capture the Coin

In addition to our bug bounty program, we also run a Capture the Coin contest to further create transparency around our security. Our Capture the Coin is modelled after traditional Capture the Flag contests. Instead of hiding a flag within our code, we have created a bitcoin based intrusion-detection system by hiding bitcoin private keys in our platform. Security researchers may capture these keys and claim the reward immediately if they are able to find a way to access them.

Emergency

In the event of a security breach, we have created procedures for resolute reactions, including turning off access to the web application, mass password reset and certificate rotations. If our platform is maliciously attacked, we will communicate this information to all of our users as quickly and openly as possible.