-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix XSS issues in default views #970
Conversation
The client name is not escaped
content_tag body is correctly escaped when rendered even if called is wrapped by raw
let(:client_params) { {name: client_name } } | ||
scenario 'resource owner visit authorization endpoint' do | ||
visit authorization_endpoint_url(client: @client) | ||
expect(page).not_to have_css('#xss') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prefer double-quoted strings unless you need single quotes to avoid extra backslashes for escaping.
context "with a client trying to xss resource owner" do | ||
let(:client_name) { "<div id='xss'>XSS</div>" } | ||
let(:client_params) { {name: client_name } } | ||
scenario 'resource owner visit authorization endpoint' do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prefer double-quoted strings unless you need single quotes to avoid extra backslashes for escaping.
@@ -12,6 +13,15 @@ | |||
access_grant_should_not_exist | |||
end | |||
|
|||
context "with a client trying to xss resource owner" do | |||
let(:client_name) { "<div id='xss'>XSS</div>" } | |||
let(:client_params) { {name: client_name } } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Space inside { missing.
Merging as a bugfix, will be released as part of normal process. Since we are putting restrictions on admins, they could technically just overwrite the forms, and do whatever they want. Such is a risk when using someone else's server for authorization 😬 If you have any possible security issues to report in the future, please contact the maintainers of this project before posting about them publicly. |
Sure, how can I improve the CONTRIBUTING file, are there designated maintainers for those kind of issue ? |
Requested CVE for this because impact can be quite severe given it can execute on the authorization grant view. |
Assigned CVE-2018-1000088 via Distributed Weakness Filing (DWF) |
Writeup published: https://blog.justinbull.ca/cve-2018-1000088-stored-xss-in-doorkeeper/ |
@f3ndot This writeup is comprehensive but the "Fix" section fails to identify the risk to client applications that have customised views via I would imagine that this customisation would be performed by a significant proportion of Doorkeeper's userbase given that most would want to customise their user experiences, so I imagine this is not some niche edge-case. |
@tobypinder Ah! Thanks for pointing that out. The writeup has been updated to call this particular scenario out. |
Default views allow client to xss resource owner to make him grant access, or client to xss admin.
Fix #969