Thanks Jeremy. I'll work on a PR. On Monday, February 18, 2019 at 10:50:49 PM UTC-5, Jeremy Evans wrote: > > On Monday, February 18, 2019 at 7:24:57 AM UTC-8, Benjamin Hutton wrote: >> >> Currently, I am re-defining #nested_attributes_create in my Resource >> class, changing that one line to this: >> >> obj = if reflection.associated_class == Blocks::Base >> attributes[:type].constantize.new >> > > I think that approach is way too dangerous. There is no guarantee > that attributes[:type] references one of the STI subclasses. I would not > be surprised if that results in an RCE vulnerability (not sure that it > does, but I wouldn't bet against it). > > >> 1. Is there a better way to do this (other than abandoning STI or trying >> to separate this out into multiple associations)? >> > > Not sure if there is a better way. Separating this into multiple > associations or not using STI both seem reasonable to me. > > >> 2. Is this change or something similar something that Sequel would >> consider merging in? >> > > Not acceptable in the present form as mentioned above. I could possibly > consider something similar to: > > if klass_map = reflection[:nested_attributes_create_class_map] > klass = > klass_map[attributes[reflection[:nested_attributes_create_class_column] || > 'type']] > end > klass ||= reflection.associated_class > obj = klass.new > > assuming appropriate tests and documentation. What I like about that > approach is that does not tie nested_attributes to something specific to > STI, could be used for other reasons, and doesn't allow an attacker the > ability to pick the class generated. > > Thanks, > Jeremy >
-- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
