911a52ee83
This isn't the cleanest approach, but should be good for now. Obviously, there are two contexts for these specs: one is from the maintainer's standpoint, the other is from the trainee who is using RailsGoat for training. The maintainer wants all of these specs to pass, to ensure the vulnerabilities are still functional as vulnerabilities. The trainee could potentially use these specs (though reading the specs contains spoilers) to track and verify their fixes. I've wired in a pending block around each assertion that checks a method to see what the result of the pending call would be. You can see examples of how this works with conditions here: https://www.relishapp.com/rspec/rspec-core/v/2-14/docs/pending/pending-examples This means these specs will all fail now by default (the trainee context), but will pass, when vulnerable, if the RAILSGOAT_MAINTAINER env var is set. The only flaw at the moment is that in the trainee context, fixing the vulnerabilities will result in the specs going from failing to _pending_, not passing (which makes sense, given how we're using RSpec's pending functionality). Maybe it'd be simpler/better to have a boolean toggle of our own somehow wrap the assertions in blocks to do explicitly what we want (flip-flop the result based on the context).
18 lines
580 B
Ruby
18 lines
580 B
Ruby
require 'spec_helper'
|
|
|
|
feature 'sensitive information disclosure' do
|
|
before do
|
|
UserFixture.reset_all_users
|
|
@normal_user = UserFixture.normal_user
|
|
@normal_user.work_info.update_attribute(:SSN, '999-99-9999')
|
|
end
|
|
|
|
# this won't work with javascript_driver, as it'll apply the javascript
|
|
# function to mask this value and the source will be overwritten.
|
|
scenario 'full ssn returned to view' do
|
|
login @normal_user
|
|
|
|
visit "/users/#{@normal_user.user_id}/work_info"
|
|
pending(:if => verifying_fixed?) { page.source.should include '999-99-9999' }
|
|
end
|
|
end |