Ticket #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: | ||
| Blocking: | Blocked by: |
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
comment:1 Changed 13 months ago by rwaldron
- Priority changed from undecided to low
- Resolution set to wontfix
- Status changed from new to closed
- Component changed from unfiled to core
comment:2 Changed 13 months 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 13 months 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 13 months 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 13 months 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 13 months 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 13 months ago by rwaldron
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 13 months 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.
Please follow the bug reporting guidlines and use jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.
Sorry, but this would create a massive backwards compatibility break. jQuery.fn.init can be overridden with a custom constructor.