Contribute to Open Source. Search issue labels to find the right project for you!

Optional challenge hints

  • In accordance with add an additional question INSERT a hint along with each CTFd Challenge? that takes the hints from the webapps API
  • Warn in CLI when choosing YES for hints but the Juice Shop instance to retrieve the challenges from has hints disabled
  • Make sure that the default Juice Shop instance on Heroku is launched with hints enabled
Updated 30/04/2017 10:12

Show vulnerability page/location/tipp in scoreboard


As a student, new to security, I want to know the location of a vulnerability. As an advanced security specialist I don’t want to see the location of a vulnerability.

Therefore, an advanced score-board function and an newbie score-board function is need. I prefere to have a button on the top of the score-board which is labled as “Newbie modus on” to turn on the effect of giving tipps on hover.

  • Hover: “XSS Tier 1”, Tipp: Can be found on http://localhost:3000/#/search
  • Hover “Login Admin”, Tipp can be found on http://localhost:3000/#/search
  • Hover “Access a confidential document”, Tipp can be found during the order process

I am open to discuss this in more detail during the App Sec EU.

Updated 30/04/2017 10:07 3 Comments

Multiple Versions of Chocolatey


What You Are Seeing?

Multiple versions of chocolatey when doing clist -l (Including .9.x and .10.x versions)

What is Expected?

One version, 0.10.5

How Did You Get This To Happen? (Steps to Reproduce)

Unsure, experiencing on multiple computers. They are set to “cup all -y” at boot.

Output Log

clist -l Chocolatey v0.10.5 chocolatey 0.10.5 chocolatey 0.10.3 chocolatey-core.extension 1.3.0 chocolatey-windowsupdate.extension 1.0.2 flashplayeractivex jre8 8.0.121 KB2919355 1.0.20160915 KB2919442 1.0.20160915 KB2999226 1.0.20161201 KB3033929 1.0.2 Logicity 1.7.0018.1 skype vcredist140 14.10.25008.0 vcredist2015 14.0.24215.20170201 vlc 15 packages installed.

Had a remote session with Rob already who couldn’t find anything in the logs. Can provide what ever is requested, and can usually find a computer with this issue to remote back in if needed.

Updated 28/04/2017 17:52 1 Comments

Tweaks to DB structure and migration strategy


/pico/:pico_id/:rid/vars/:varname can have rids that collide with other pico values should be /entvars/:pico_id/:rid/:varname

/resultset/:rid/vars/:varname -> /appvars/:rid/:varname

/pico/:pico_id/ruleset/:rid -> /pico-rulesets/:pico_id/:rid

As a rule of thumb should try and keep things shallow, so when grabbing data by ranges we don’t end up pulling out more data then needed.

As part of the startup process core should check for migrations that need to be run on the db. Based on a /migration/[version, log] in the db that lets it know migrations it needs to run to. Each migration is a script given access to levelup to run any operations needed to fix the database layout, ideally reading the data, then running a single batch transaction of writes. The startup phase should guarantee no other writes will happen during the migration

<!— @huboard:{“order”:0.24915148571665002,“milestone_order”:0.24885269818129185} –>

Updated 27/04/2017 16:27

cChocoSource does not update priority correctly for existing source


To work aournd the -Source issue with cChocoPackageInstaller I’m trying to shuffle around the order of the sources in the configi file. If a source is present and I simply want to change the priority the element is not updated properly. To work around, I’m removing the source and andding it back in with a new priority. No a huge deal but just wanted to point it out in case other run across this.

Updated 26/04/2017 19:43 2 Comments

Limit non-admin list to self service only.


Currently with feature useBackgroundServiceWithSelfServiceSourcesOnly enabled, a user without admin permissions can do choco list and return items from all configured sources by default, including packages from sources that are not configured for self service.

Would it be possible for non elevated users to only have self service packages returned, as its the only items they can actually install.

Updated 26/04/2017 17:55 4 Comments

Add support for adding/remove property pages via MSBuild properties


The legacy project system respects the following properties to add/remove configuration and configuration-independent property pages:


For example, C#:


Or VB:

Updated 26/04/2017 00:41

Avante Configurator module


Super-user builds a data item, want to track changes made through this program. PRC triggers to treat this data as part of the software so it can be delivered to live, etc. PRC is treating data as part of the application.

<!— @huboard:{“order”:12.961060385573168,“milestone_order”:0.9961077893511842} –>

Updated 25/04/2017 14:53

Call a BASIC program for triggers


PRC sometimes triggers a file, can launch a stub PRC subroutine. So, there will need to be a means from MVON# to work with the triggers. We want to trigger the specific menu that changed, etc.

Enable file level triggers to call BASIC subroutines.

<!— @huboard:{“order”:12.962356491611725,“milestone_order”:0.9962074001301192} –>

Updated 25/04/2017 14:50 1 Comments

CA1812 (Avoid uninstantiated internal classes) should be aware of indirect instantiation


Analyzer package

Example: Microsoft.CodeQuality.Analyzers


CA1812: Avoid uninstantiated internal classes

Repro steps

  1. Declare an internal type
  2. Use Json.NET to directly or indirectly deserialize an instance of the type

Expected behavior

CA1812 is not reported.

Actual behavior

CA1812 is reported if the only instantiations of the type occur through Json.NET.

Updated 26/04/2017 23:10 16 Comments

Szavazások UI részéhez


ez egy korábbi doksi

<!— @huboard:{“order”:4.999000149980002,“milestone_order”:0.9998000299960005} –>

Updated 24/04/2017 15:25 2 Comments

LiDe UI docx


<!— @huboard:{“order”:4.999500049995,“milestone_order”:0.9999000099990001} –>

Updated 24/04/2017 09:44 1 Comments

ZFR - create wiki page



  • [x] Iteration goals
  • [x] Team roles
  • [ ] Print screen:
    • [ ] Before
    • [ ] After
  • [ ] Points
  • [x] Diagrams' references
  • [ ] Code Reviews' Links
    • [ ] Avihai
    • [ ] Sapir
    • [ ] Hodaya
    • [ ] Avishai
    • [ ] Karin
    • [ ] Course’s Crew.
  • [x] Meetings' Summaries
  • [ ] Iteration’s Summary
  • [ ] Next Iteration’s Planning
Updated 23/04/2017 13:16

Hud redesign

  • Remove the daryl head?
  • Decrease size of piggy bank and put money amount next to it? (That way it can go over 5 digits)
  • Where to put skill EXP?
  • For quest HUD, perhaps only draw one quest at a time and the others are just the quest icons lined up in a row horizontally? That way the player can use left/right on analog stick to cycle and it takes up less space. Still can collapse. If so, what about the quest check marks?

<!— @huboard:{“order”:4.746232614983725e-64,“milestone_order”:4.6494651877300115e-64} –>

Updated 23/04/2017 00:07

Face login


Returning users should be identified by face reckognition. Allowing them to be identified only by photo

<!— @huboard:{“order”:5.9994000599940005,“milestone_order”:0.9998000299960005} –>

Updated 22/04/2017 16:32

[Request] Front-load all user input for `cup all`


In summary:

cup all currently iterates through each package, where it

  1. Check package for updates. If found,
  2. Asks for user confirmation (yes/no/print). If yes,
  3. installs the package

Rinse and repeat for each package on the system.

I propose that step 3 is NOT run until steps 1-2 have been completed for all packages. That is to say,

  1. Check package for updates. If found,
  2. Asks for user confirmation (yes/no/print). If yes or no, remember the user’s choice.
  3. Don’t act on the choice yet, repeat 1-2 for all packages on the system.
  4. Now proceed with installing which packages were approved to install.

Installs/updates can sometimes be a lengthy process! Rather than having to sit with and interact with chocolatey through the entire update queue, it would be more efficient if chocolatey would get all interactive prompts out of the way as soon as possible. Tell chocolatey what to do, then set it loose!

Relevant snippets from gitter discussion:

It’s not clear, but many of my comments on gitter are actually talking about this, AND another feature request, which already exists here

Updated 26/04/2017 16:42 2 Comments

Add SQLite and console as INSERT output targets


Extended CLI Questions

:white_check_mark: Juice Shop URL to retrieve challenges? :white_check_mark: Secret key \<or> URL to ctf.key file? - [ ] SQL statements output target? (select from: File, Console, SQLite) - [ ] (only if SQLite was selected) Location of CTFd SQLite database? ({workdir}/CTFd/ctfd.db)

:white_check_mark: DELETE all CTFd Challenges before INSERT statements? :white_check_mark: SELECT all CTFd Challenges after INSERT statements?

Process extensions

  • [ ] Test connection to SQLite database (fail CLI if file not found, locked or otherwise corrupt)
  • [ ] Programmatically connect to SQLite db and execute & commit generated statements (fail CLI on any error)
  • [ ] Implement output to console as alternative to file
Updated 21/04/2017 13:20

"Juice Shop" CTFd-theme


CTFd supports custom themes. It would be great to have one for OWASP Juice Shop!

General customization ideas

  • similar color scheme as as the shop (Bootswatch slate)
  • include the generic and/or CTF-variant logo (see #6)

Challenge selection visualization

  • shelf with bottles and packs of juice (=challenge) in different colors (=category) and sizes (=price value), being “emptied” when solved
  • Juice Shop logo in b/w split into jigsaw pieces where each represents a challenge, being colorized when solved

Please post ideas in the comments below!

Updated 21/04/2017 12:27

Analyze security of app with checklist


Zen Rails Security Checklist


This document provides a list of security measures to be implemented when developing a Ruby on Rails application. It is designed to serve as a quick reference and minimize vulnerabilities caused by developer forgetfulness.

This checklist is meant to be a community-driven resource. Your contributions are welcome!

Disclaimer: This document does not cover all possible security vulnerabilities. The authors do not take any legal responsibility for the accuracy or completeness of the information herein.

Supported Rails Versions

This document focuses on Rails 4 and 5. Vulnerabilities that were present in earlier versions and fixed in Rails 4 are not included.

<!– START doctoc generated TOC please keep comment here to allow auto update –> <!– DON’T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE –>

Table of Contents

<!– END doctoc generated TOC please keep comment here to allow auto update –>

The Checklist


Injection attacks are #1 at the OWASP Top10. - [ ] Don’t use standard Ruby interpolation (#{foo}) to insert user inputted strings into ActiveRecord or raw SQL queries. Use the ? character, named bind variables or the ActiveRecord::Sanitization methods to sanitize user input used in DB queries. Mitigates SQL injection attacks. - [ ] Don’t pass user inputted strings to methods capable of evaluating code or running O.S. commands such as eval, system, syscall, %x(), and exec. Mitigates command injection attacks.

Resources: - Ruby on Rails Security Guide - SQL Injection - Rails SQL Injection Examples

Authentication (Devise)

Broken Authentication and Session Management are #2 at the OWASP Top 10. - [ ] Enforce a minimum password length of 8 characters or more. Mitigates brute-force attacks. - [ ] Consider validating passwords against: - Dictionary words. Since passwords have a minimum length requirement, the dictionary need only include words meeting that requirement. - A list of commonly used passwords such as these. The password_strength and StrongPassword gems provide such feature. - A leaked password database such as PasswordPing. - Context-specific words, such as the name of the application, the username, and derivatives thereof. - [ ] Consider the pros and cons of enforcing password complexity rules such as mixtures of different character types. Most applications use it. However, the latest NIST Guidelines advise against it. An alternative is to increase the minimum length requirement and encourage the usage of passphrases. Devise only validates password length. Gems such as devise_security_extension, StrongPassword, devise_zxcvbn, and password_strength provide additional password validation capabilities, such as entropy calculation (based on password complexity). Validation may also be implemented with regex (code sample). Mitigate brute-force attacks. - [ ] Lock the account after multiple failed login attempts. Use Devise’s lockable module. Mitigates brute-force attacks. - [ ] Require users to confirm their e-mail addresses on sign-up and when the e-mail address is changed. Use Devise’s confirmable module and set config.reconfirmable = true in config/initializers/devise.rb. Mitigates the creation of bogus accounts with non-existing or third-party e-mails. - [ ] Require users to input their old password on password change. Mitigates unauthorized password changes on session hijacking, CSRF or when a user forgets to log out and leaves the PC or mobile device unattended. - [ ] Expire the session at log out and expire old sessions at every successful login. Devise does that by default. Also use Devise’s timeoutable module to expire sessions after a period of inactivity (e.g., 30 minutes). Mitigates CSRF, session hijacking and session fixation attacks by reducing their time-frame. - [ ] Notify user via email on password change. Set config.send_password_change_notification = true in config/initializers/devise.rb. Does not prevent an attacker from changing the victim’s password, but warns the victim so he can contact the system administrator to revoke the attacker’s access. - [ ] Use generic error messages such as “Invalid email or password” instead of specifying which part (e-mail or password) is invalid. Devise does that by default. Mitigates user enumeration and brute-force attacks. - [ ] Ensure all non-public controllers/actions require authentication. Add before_action :authenticate_user! to ApplicationController and skip_before_action :authenticate_user! to publicly accessible controllers/actions. Avoid unauthorized access due to developer forgetfulness. - [ ] Consider using the devise_security_extension gem, which provides additional security for Devise. - [ ] Consider using two-factor authentication (2FA) as provided by Authy. See the devise-two-factor and authy-devise gems. Provides a highly effective extra layer of authentication security. - [ ] Consider requiring authentication in config/routes.rb by putting non-public resources within a authenticate :user do block (see the Devise Wiki). Requiring authentication in both controllers and routes may not be DRY, but such redundancy provides additional security (see Defense in depth)). - [ ] Consider restricting administrator access by IP. If the client’s IP is dynamic, restrict by IP block/ASN or by country via IP geolocation (country).

Sessions & Cookies

Broken Authentication and Session Management are #2 at the OWASP Top 10. - [ ] Don’t store data such as money/point balances or user privileges in a cookie or a CookieStore Session. Store it in the database instead. Mitigates replay attacks. - [ ] Consider always using encrypted cookies. This is the default behavior in
Rails 4 when secret_key_base is set. Strengthens cookie encryption and mitigates multiple attacks involving cookie tampering. - [ ] Unless your JavaScript frontend needs to read cookies generated by the Rails server, set all cookies as httponly. Search the project for cookie accessors and add httponly: true. Example: cookies[:login] = {value: 'user', httponly: true}. Restricts cookie access to the Rails server. Mitigates attackers from using the victim’s browser JavaScript to steal cookies after a successful XSS attack.

Resources: - Ruby on Rails Security Guide - Sessions

Cross-Site Scripting (XSS)

XSS is #3 at the OWASP Top 10.

Handling User Input
  • [ ] Always validate user input that may eventually be displayed to other users. Attempting to blacklist characters, strings or sanitize input tends to be ineffective (see examples of how to bypass such blacklists). A whitelisting approach is usually safer. Mitigates multiple XSS attacks.
  • [ ] Consider using the loofah-activerecord gem to scrub your model attribute values. Mitigates multiple XSS attacks.
  • [ ] If you must create links from user inputted URLs, be sure to validate them. If using regex, ensure that the string begins with the expected protocol(s), as in \Ahttps?. Mitigates XSS attacks such as entering javascript:dangerous_stuff()// as a website URL that is displayed as a link to other users (e.g., in a user profile page).
  • [ ] When using regex for input validation, use \A and \z to match string beginning and end. Do not use ^ and $ as anchors. Mitigates XSS attacks that involve slipping JS code after line breaks, such as\n<script>dangerous_stuff();</script>.
  • [ ] Do not trust validations implemented at the client (frontend) as most implementations can be bypassed. Always (re)validate at the server.
    Output Escaping & Sanitization
  • [ ] Escape all HTML output. Rails does that by default, but calling html_safe or raw at the view suppresses escaping. Look for calls to these methods in the entire project, check if you are generating HTML from user-inputted strings and if those strings are effectively validated. Note that there are dozens of ways to evade validation. If possible, avoid calling html_safe and raw altogether. For custom scrubbing, see ActionView::Helpers::SanitizeHelper Mitigates XSS attacks.*
  • [ ] Avoid sending user inputted strings in e-mails to other users. Attackers may enter a malicious URL in a free text field that is not intended to contain URLs and does not provide URL validation. Most e-mail clients display URLs as links. Mitigates XSS, phishing, malware infection and other attacks.

Resources: - Ruby on Rails Security Guide - XSS - OWASP XSS Filter Evasion Cheat Sheet - OWASP Ruby on Rails Cheatsheet - Cross-site Scripting (XSS) - Plataformatec Blog - The new HTML sanitizer in Rails 4.2


  • [ ] Force HTTPS over TLS (formerly known as SSL). Set config.force_ssl = true in config/environments/production.rb. May also be done in a TLS termination point such as a load balancer, Nginx or Passenger Standalone. Mitigates man-in-the-middle and other attacks.
  • [ ] Use the SSL Server Test tool from Qualys SSL Lab to check the grade of your TLS certificate. Be sure to use the strongest (yet widely compatible) protocols and cipher suites, preferably with Ephemeral Diffie-Hellman support. Mitigates multiple SSL/TLS-related attacks such as BEAST and POODLE.
  • [ ] Consider rate-limiting incoming HTTP requests, as implemented by the rack-attack and rack-throttle gems. Mitigates web scraping, HTTP floods, and other attacks.
    Security-related headers
  • [ ] Consider using the Secure Headers gem. Mitigates several attacks.
  • [ ] Consider obfuscating the web server banner string. In other words, hide your web server name and version. Mitigates HTTP fingerprinting, making it harder for attackers to determine which exploits may work on your web server.

Authorization (Pundit)

  • [ ] Implement authorization at the server. Hiding links/controls in the UI is not enough to protect resources against unauthorized access. Mitigates forced browsing attacks.
  • [ ] Ensure all controllers/actions which require authorization call the authorize or policy_scope method (sample code). Mitigates forced browsing attacks due to developers forgetting to require authorization in some controller actions.
  • [ ] When using DB records associated to users to populate select boxes, radio buttons or checkboxes, instead of querying by association (user.posts), consider using policy_scope. See additional details and sample code. Improves readability and maintainability of authorization policies.

Resources: - Pundit: Ensuring policies and scopes are used - Pundit: Scopes


File Uploads
  • [ ] Avoid using user controlled filenames. If possible, assign “random” names to uploaded files when storing them in the OS. If not possible, whitelist acceptable characters. It is safer to deny uploads with invalid characters in the filenames than to attempt to sanitize them. Mitigates Directory Traversal Attacks such as attempting to overwrite system files by uploading files with names like ../../passwd.
  • [ ] Avoid using libraries such as ImageMagick to process images and videos on your server. If possible, use an image/video processing service such as Transloadit, Cloudinary, or imgix. Mitigates multiple image/video processing related vulnerabilities such as these.
  • [ ] Process uploaded files asynchronously. If not possible, implement per-client rate limiting. Mitigates DoS Attacks that involve overloading the server CPU by flooding it with uploads that require processing.
  • [ ] Do not trust validations implemented at the client (frontend) as most implementations can be bypassed. Always (re)validate at the server.
  • [ ] Validate files before processing. Mitigates DoS Attacks such as image bombs.
  • [ ] Whitelist acceptable file extensions and acceptable Media Types (formerly known as MIME types). Validating file extensions without checking their media types is not enough as attackers may disguise malicious files by changing their extensions. Mitigates the upload of dangerous file formats such as shell or Ruby scripts.
  • [ ] Limit file size. Mitigates against DoS attacks involving the upload of very large files.
  • [ ] Consider uploading directly from the client (browser) to S3 or a similar cloud storage service. Mitigates multiple security issues by keeping uploaded files on a separate server than your Rails application.
  • [ ] If allowing uploads of malware-prone files (e.g., exe, msi, zip, rar, pdf), scan them for viruses/malware. If possible, use a third party service to scan them outside your server. Mitigates server infection (mostly in Windows servers) and serving infected files to other users.
  • [ ] If allowing upload of archives such as zip, rar, and gz, validate the target path, estimated unzip size and media types of compressed files before unzipping. Mitigates DoS attacks such as zip bombs, zipping malicious files in an attempt to bypass validations, and overwriting of system files such as /etc/passwd.
    File Downloads
  • [ ] Do not allow downloading of user-submitted filenames and paths. If not possible, use a whitelist of permitted filenames and paths. Mitigates the exploitation of directory traversal vulnerabilities to download sensitive files.

Resources: - Ruby on Rails Security Guide - File Uploads and Downloads

Cross-Site Request Forgery (CSRF)

  • [ ] Enforce CSRF protection by setting protect_from_forgery with: :exception in all controllers used by web views or in ApplicationController.
  • [ ] Use HTTP verbs in a RESTful way. Do not use GET requests to alter the state of resources. Mitigates CSRF attacks.
  • [ ] Up to Rails 4, there was a single CSRF token for all forms, actions, and methods. Rails 5 implements per-form CSRF tokens, which are only valid for a single form and action/method. Enable it by setting config.action_controller.per_form_csrf_tokens = true.

Resources: - Ruby on Rails Security Guide - CSRF - Big Binary Blog - Each form gets its own CSRF token in Rails 5

Sensitive Data Exposure

  • [ ] If possible, avoid storing sensitive data such as credit cards, tax IDs and third-party authentication credentials in your application. If not possible, ensure that all sensitive data is encrypted at rest (in the DB) and in transit (use HTTPS over TLS). Mitigate theft/leakage of sensitive data.
  • [ ] Do not log sensitive data such as passwords and credit card numbers. You may include parameters that hold sensitive data in config.filter_parameters at initializers/filter_parameter_logging.rb. For added security, consider converting filter_parameters into a whitelist. See sample code. Prevents plain-text storage of sensitive data in log files.
  • [ ] HTML comments are viewable to clients and should not contain details that can be useful to attackers. Consider using server-side comments such as <%# This comment syntax with ERB %> instead of HTML comments. Avoids exposure of implementation details.
  • [ ] Avoid exposing numerical/sequential record IDs in URLs, form HTML source and APIs. Consider using slugs (A.K.A. friendly IDs, vanity URLs) to identify records instead of numerical IDs, as implemented by the friendly_id gem. Additional benefits include SEO and better-looking URLs. Mitigates forced browsing attacks and exposure of metrics about your business, such as the number of registered users, number of products on stock, or number of receipts/purchases.
  • [ ] Do not set config.consider_all_requests_local = true in the production environment. If you need to set config.consider_all_requests_local = true to use the better_errors gem, do it on config/environments/development.rb. Prevents leakage of exceptions and other information that should only be accessible to developers.
  • [ ] Don’t install development/test-related gems such as better_errors and web-console in the production environment. Place them within a group :development, :test do block in the Gemfile. Prevents leakage of exceptions and even REPL access if using better_errors + web-console.
    Credentials & Secrets
  • [ ] Do not commit sensitive data such as secret_key_base, DB, and API credentials to git repositories. Avoid storing credentials in the source code, use environment variables instead. If not possible, ensure all sensitive files such as /config/database.yml, config/secrets.yml (and possibly /db/seeds.rb if it is used to create seed users for production) are included in .gitignore. Mitigates credential leaks/theft.
  • [ ] Use different secrets in the development and production environments. Mitigates credential leaks/theft.
  • [ ] Use a secret_key_base with over 30 random characters. The rake secret command generates such strong keys. Strengthens cookie encryption, mitigating multiple cookie/session related attacks.

Routing, Template Selection, and Redirection

  • [ ] Don’t perform URL redirection based on user inputted strings. In other words, don’t pass user input to redirect_to. If you have no choice, create a whitelist of acceptable redirect URLs or limit to only redirecting to paths within your domain (example code). Mitigates redirection to phishing and malware sites. Prevent attackers from providing URLs such as to victims.
  • [ ] Do not use a user inputted string to determine the name of the template or view to be rendered. Prevents attackers from rendering arbitrary views such as admin-only pages.
  • [ ] Avoid “catch-all” routes such as match ':controller(/:action(/:id(.:format)))' and make non-action controller methods private. Mitigates unintended access to controller methods.

Resources: - OWASP Ruby on Rails Cheatsheet - Redirects and Forwards (URL validation)

Third-party Software

  • [ ] Apply the latest security patches in the OS frequently. Pay special attention to internet-facing services such as application servers (Passenger, Puma, Unicorn), web servers (Nginx, Apache, Passenger Standalone) and SSH servers.
  • [ ] Update Ruby frequently.
  • [ ] Watch out for security vulnerabilities in your gems. Run bundler-audit frequently or use a service like Snyk, Gemnasium (both free for open-source development) or Appcanary.

Security Tools

  • [ ] Run Brakeman before each deploy. If using an automated code review tool like Code Climate, enable the Brakeman engine.
  • [ ] Consider using a continuous security service such as Detectify.
  • [ ] Consider using a Web Application Firewall (WAF) such as NAXSI for Nginx, ModSecurity for Apache and Nginx. Mitigates XSS, SQL Injection, DoS, and many other attacks.


  • [ ] Use strong parameters in the controllers. This is the default behavior as of Rails 4. Mitigates mass assignment attacks such as overwriting the role attribute of the User model for privilege escalation purposes.
  • [ ] Implement Captcha or Negative Captcha on publicly exposed forms. reCAPTCHA is a great option, and there is a gem that facilitates Rails integration. Other options are the rucaptcha and negative-captcha gems. Mitigates automated SPAM (spambots).

Details and Code Samples

Password validation regex

We may implement password strength validation in Devise by adding the following code to the User model. ``` validate :password_strength


def password_strength minimum_length = 8 # Regex matches at least one lower case letter, one uppercase, and one digit complexity_regex = /\A(?=.[a-z])(?=.[A-Z])(?=.*[0-9])/ # When a user is updated but not its password, the password param is nil if password.present? && password.length < minimum_length || !password.match(complexity_regex) errors.add :password, ‘must be 8 or more characters long, including at least one lowercase letter, one uppercase letter, and one digit.’ end end ```

Pundit: ensure all actions are authorized

Add the following to app/controllers/application_controller.rb after_action :verify_authorized, except: :index, unless: :devise_controller? after_action :verify_policy_scoped, only: :index, unless: :devise_controller?

Add the following to controllers that do not require authorization. You may create a concern for DRY purposes. after_action_skip :verify_authorized after_action_skip :verify_policy_scoped

Pundit: only display appropriate records in select boxes

Think of a blog-like news site where users with editor role have access to specific news categories, and admin users have access to all categories. The User and the Category models have an HMT relationship. When creating a blog post, there is a select box for choosing a category. We want editors only to see their associated categories in the select box, but admins must see all categories. We could populate that select box with user.categories. However, we would have to associate all admin users with all categories (and update these associations every time a new category is created). A better approach is to use Pundit Scopes to determine which categories are visible to each user role and use the policy_scope method when populating the select box.

# app/views/posts/_form.html.erb
f.collection_select :category_id, policy_scope(Category), :id, :name

Convert filter_parameters into a whitelist

Developers may forget to add one or more parameters that contain sensitive data to filter_parameters. Whitelists are usually safer than blacklists as they do not generate security vulnerabilities in case of developer forgetfulness. The following code converts filter_parameters into a whitelist.

# config/initializers/filter_parameter_logging.rb
if Rails.env.production?
  # Parameters whose values are allowed to appear in the production logs:
  WHITELISTED_KEYS = %w(foo bar baz)

  # (^|_)ids? matches the following parameter names: id, *_id, *_ids
  WHITELISTED_KEYS_MATCHER = /((^|_)ids?|#{WHITELISTED_KEYS.join('|')})/.freeze

  Rails.application.config.filter_parameters << lambda do |key, value|
    unless key.match(WHITELISTED_KEYS_MATCHER)
  # Keep the default blacklist approach in the development environment
  Rails.application.config.filter_parameters += [:password]


  • Bruno Facca - LinkedIn - Email: bruno at facca dot info


Contributions are welcome. If you would like to correct an error or add new items to the checklist, feel free to create an issue and/or a PR. If you are interested in contributing regularly, drop me a line at the above e-mail to become a collaborator.

References and Further Reading


Released under the MIT License.

Updated 21/04/2017 06:43

Stop saying "0 packages failed."


When an install is successful it would be better if the report didn’t say “0 packages failed” If you’re spooling through the terminal history looking for failures this unnecessarily catches your eye.

“0 packages failed does not add any new information to the "choloatey installed 3/3 packages” message that precedes it.

It would be better if it only mentioned failure when the number of packages that failed > 0. And maybe even consider changing “Chocolatey installed x/y packages” to “Chocolatey installed all packages” when x==y

Updated 26/04/2017 17:59 2 Comments

chocolatey.config gets corrupted when multiple processes access simultaneously


What You Are Seeing?

Broken chocolatey.config after two processes use choco.exe at the same time. (sometimes) <?xml version="1.0" encoding="utf-8"?> <chocolatey xmlns:xsd="" xmlns:xsi=""> <containsLegacyPackageInstalls>false</containsLegacyPackageInstalls> <commandExecutionTimeoutSeconds>0</commandExecutionTimeoutSeconds> <config> <add key="cacheLocation" value="" description="Cache location if not TEMP folder." /> <add key="containsLegacyPackageInstalls" value="true" description="Install has packages installed prior to 0.9.9 series." /> <add key="commandExecutionTimeoutSeconds" value="2700" description="Default timeout for command execution." /> <add key="

What is Expected?

config shouldn’t be corrupted

How Did You Get This To Happen? (Steps to Reproduce)

Two processes -> both use choco.exe at the very same time (choco list is sufficient)

This Issue is a follow-up of GH-1047

Updated 20/04/2017 12:19

Parsing and Loading | Add Bag Tag ID data element


One data element that we’re missing from the APIS message is the bag IDs given to checked luggage. This would save the analyst from calling the airline to request information about a traveler if the luggage needed additional screening.


FTX+BAG+++UA123456' (one bag) FTX+BAG+++UA987654:3 (three bags, 987654, 987655, and 987656)

<!— @huboard:{“order”:1.225160555266397,“milestone_order”:0.9757257065930717} –>

Updated 19/04/2017 20:45

Packages should be able to opt-out of AutoUninstaller


Currently, the AutoUninstaller always runs, regardless of whether the package contains chocolateyUninstall.ps1 or not. For many packages this is harmless. There are some packages, however, where the AutoUninstaller may break other applications. This will happen if a native installer installed a shared component, which is still needed even after uninstalling the package which originally installed it.

Here is a concrete example.

Each of the Visual Studio 2017 product packages (visualstudio2017professional, visualstudio2017buildtools and other visualstudio2017xyz packages) downloads and executes the Visual Studio setup bootstrapper, which performs the following actions: - if the Visual Studio Installer application is not present on the system, install it, - invoke the Visual Studio Installer to install the specific Visual Studio product.

Therefore, the first installed Visual Studio product will install the Visual Studio Installer and all subsequent VS products will add themselves to the existing VS Installer instance.

Uninstalling the VS Installer removes all VS 2017 products installed on the machine. Because of that, the chocolateyUninstall.ps1 scripts of VS 2017 product packages only invoke the VS Installer, telling it to uninstall the specific VS product. Uninstallation of the VS Installer is handled by a separate package, visualstudio2017-installer, which is a dependency of all VS 2017 product packages.

There is no documented way of installing just the VS Installer itself, so visualstudio2017-installer cannot do it and the Installer gets installed by the first installed VS 2017 product package. The Installer appears in Programs and Features and Chocolatey records that fact for the VS product package. Now, when the product package is uninstalled, its uninstall script leaves the VS Installer intact (because other VS product packages may require it), but the AutoUninstaller “helpfully” proceeds to uninstall it, removing all other VS products present on the machine. (This is slightly mitigated by the fact that Chocolatey does not recognize the uninstaller type and asks the user for permission to proceed, but most users will probably agree.)

I see two solutions: 1) skip running the AutoUninstaller if the package contains chocolateyUninstall.ps1, 2) provide a way for packages to tell Chocolatey to skip running the AutoUninstaller (either as package metadata extension or, preferably, a new helper/.NET API callable from chocolateyUninstall.ps1).

Updated 20/04/2017 12:19 2 Comments

Move capabilities from language-specific to "managed"



We should move the language-specific capabilities on components, such as: [AppliesTo(ProjectCapability.CSharpOrVisualBasicOrFSharp)]



To a more general capability, such as:

[AppliesTo("Managed + CPS")]

Make note that C++/CLI uses “Managed”, so we should either combine with “CPS” to avoid that (they don’t define it) or come up with a new capability.

Updated 20/04/2017 18:49

Cloudflare returning 524 on push - even though package push is successful


Cloudflare is returning origin timeouts even though pushing is successful. This has been noted in Gitter and with customers.

References: * * / *

Updated 24/04/2017 15:45 6 Comments

Fork me on GitHub