Skip to content

No xss in filters sidebar#5275

Merged
deivid-rodriguez merged 2 commits intomasterfrom
fix/no_xss_in_filters_sidebar
Dec 15, 2017
Merged

No xss in filters sidebar#5275
deivid-rodriguez merged 2 commits intomasterfrom
fix/no_xss_in_filters_sidebar

Conversation

@deivid-rodriguez
Copy link
Member

Fixes #5198.
Supersedes #5265.

end

it "normalizes Arbre elements" do
expect(pretty_format(Arbre::Element.new.br)).to eq("<br>\n")
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an unexpected change in output from this patch. Before the ouput would be <br />, now it's <br>. Seems ok?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its fine. No need to be self closing in HTML5.

Copy link
Member Author

@deivid-rodriguez deivid-rodriguez Dec 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only issue would be user searching for literal <br /> on a text field but current filter will show <br>... Could be confusing somehow but seems reeeeally edge...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And an improvement anyways because previously nothing would be displayed, just some whitespace.

@deivid-rodriguez deivid-rodriguez force-pushed the fix/no_xss_in_filters_sidebar branch from 744b8d1 to aa32957 Compare December 5, 2017 14:53
@zorab47
Copy link
Contributor

zorab47 commented Dec 5, 2017

Should it only be sanitizee if the string isn't already considered .html_safe?? Perhaps users would optionally like to output HTML? Just a thought.

@deivid-rodriguez
Copy link
Member Author

Mmm, I think that's what sanitize does? It cleans up some backlisted tags but allows the ones considered harmless. That's why <br> passes through, but <script> disappears in the pretty_format unit tests.

@deivid-rodriguez deivid-rodriguez force-pushed the fix/no_xss_in_filters_sidebar branch from aa32957 to 0456e2d Compare December 5, 2017 17:16
@markstory
Copy link
Contributor

There is still an issue in the else case when an ActiveRecord::Base instance is provided.
The else case uses ends up in auto_link or in display_name

else
if defined?(::ActiveRecord) && object.is_a?(ActiveRecord::Base) ||
defined?(::Mongoid) && object.class.include?(Mongoid::Document)
auto_link object
else
display_name object
end
end

The auto_link method uses display_name as a default value,

def auto_link(resource, content = display_name(resource))

The current code for display_name is missing escaping

def display_name(resource)
render_in_context resource, display_name_method_for(resource) unless resource.nil?
end
# Looks up and caches the first available display name method.
# To prevent conflicts, we exclude any methods that happen to be associations.
# If no methods are available and we're about to use the Kernel's `to_s`, provide our own.
def display_name_method_for(resource)
@@display_name_methods_cache ||= {}
@@display_name_methods_cache[resource.class] ||= begin
methods = active_admin_application.display_name_methods - association_methods_for(resource)
method = methods.detect{ |method| resource.respond_to? method }
if method != :to_s || resource.method(method).source_location
method
else
DISPLAY_NAME_FALLBACK
end
end
end

This an acute problem when the ActiveRecord model implements one of the name methods defined in

register :display_name_methods, [ :display_name,
:full_name,
:name,
:username,
:login,
:title,
:email,
:to_s ]

The end result is XSS from user supplied data stored in active record models.

@deivid-rodriguez
Copy link
Member Author

Thanks so much @markstory! Can you send us a patch fixing the other issues?

@markstory
Copy link
Contributor

@deivid-rodriguez Sure, would you like a pull request to this branch or to master?

@deivid-rodriguez
Copy link
Member Author

I think master is fine, it should be pretty independent from the code in this PR, right? Thanks!

@deivid-rodriguez deivid-rodriguez merged commit c872533 into master Dec 15, 2017
@deivid-rodriguez deivid-rodriguez deleted the fix/no_xss_in_filters_sidebar branch December 15, 2017 18:24
varyonic pushed a commit that referenced this pull request Dec 15, 2017
The display_name helper can end up invoking methods on ActiveRecord
models or other arbitrary ruby objects that can contain unsafe user
supplied data resulting in XSS holes.

Refs #5198
Refs #5265
Refs #5275
@rdlugosz
Copy link

rdlugosz commented Dec 21, 2017

Yes, this seems heavy handed. In our project, this strips the target= attribute out of links, so you cannot have certain links open in new tabs. This even happens when a string is marked as html_safe, (for example, if you wrap the link_to in a call to raw like: raw(link_to "foo", "bar")).

I'm all for sanitizing the strings, but perhaps the step should be ignored when strings are declared to be safe?

edit: fwiw, we're seeing this in columns in our index. I mention it since this patch was to fix an XSS problem in the sidebar, but (perhaps not obviously?) it applies much more broadly.

@deivid-rodriguez
Copy link
Member Author

Sorry about that, fixes welcome 🙏!

Or if the old situation is preferred, we can always revert my patch and release a new patch level version. I'm sorry I don't have time to contribute again now... 😞

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants