Bug Tracker

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#11627 closed bug (wontfix)

provide an option to disallow the $ function from creating elements

Reported by: sayrer@… Owned by:
Priority: low Milestone: None
Component: core Version: 1.7.2
Keywords: Cc:
Blocked by: Blocking:

Description

The $ or jQuery function is primarily used as a search function. I'd like an option to disable its element creation behavior, since this feature is recurring source of new attacks. I'm willing to write the code. However, I wanted to check in first, to see if the jQuery project would take the patch.

Change History (9)

comment:1 Changed 7 years ago by Rick Waldron

Component: unfiledcore
Priority: undecidedlow
Resolution: wontfix
Status: newclosed

Sorry, but this would create a massive backwards compatibility break. jQuery.fn.init can be overridden with a custom constructor.

comment:2 Changed 7 years ago by dmethvin

This is similar to the intent of #11617, making element creation explicit. I think #9521 will prevent most cases of abuse, but certainly if a dev takes arbitrary user input and passes it to $() there is still a chance it can happen.

In practical terms you won't be able to use the option you describe with any code but your own, it's similar to stopping a nosebleed by putting a tourniquet around your neck. The entire jQuery ecosystem knows that $("<html stuff>") creates DOM elements.

I'd like to start with an educational process. Nearly all the problems I've seen are due to people taking querystring parameters and using them as selectors, which never was a good idea in the first place. Adding a flag that is only in the latest version and nobody could use anyway is not the right starting point IMO.

comment:3 Changed 7 years ago by sayrer@…

I wasn't asking for it to be the default. That would be a massive compatibility break. What about a flag? Is the capability you allude to with "jQuery.fn.init" sufficient?

comment:4 Changed 7 years ago by dmethvin

A global flag that modifies the fundamental behavior of jQuery's namesake method isn't going to work, at least not at the point where jQuery is right now. There is too much code that would break.

Clearly you have a grasp of the problems, so you're not one of the people who stumble across #9521 and you don't need the flag anyway. It's the people who don't understand who are being bitten; an optional-and-disabled flag isn't going to help them and their currently-broken code, especially at the moment when #11617 isn't there and there is no other alternative to create working code.

comment:5 Changed 7 years ago by anonymous

Humor me. Pretend I know a little about JS. Let's say I'm an intermediate developer. I still want this. Why not provide it?

comment:6 Changed 7 years ago by sayrer@…

oops. that was from me. Anyway, I can code OK in JS, and I still think this flag is a good idea. What are the counter arguments?

comment:7 Changed 7 years ago by Rick Waldron

My suggestion to define your own jQuery.fn.init means its as sufficient as you make it, the whole reason the constructor exists as an accessible prototype object property is to make it easily replaceable. Or you can impose harsher filters on what is allowed through to the jQuery constructor as-is.

The counter argument is that it solves the wrong problem and as such, it's not going to happen.

comment:8 Changed 7 years ago by dmethvin

Okay, you are in intermediate level developer who loves his plugins. How will you use it? Will your plugins work with it? Most likely they will NOT, and you will post a message on this very bug tracker saying "OMG, there is a problem with jQuery.makeTheWorldSafeForHTML and I cannot use it! The jQuery team must fix my 14 plugins NOW! Otherwise this flag is USELESS!"

The answer is yes, yes you will.

If you think this is a great option, try creating it yourself and see what kind of trouble you run into while using it.

comment:9 Changed 7 years ago by sayrer@…

OK thanks guys.

Note: See TracTickets for help on using tickets.