Side navigation
#11627 closed bug (wontfix)
Opened April 24, 2012 02:01AM UTC
Closed April 24, 2012 02:09AM UTC
Last modified April 24, 2012 02:43AM UTC
provide an option to disallow the $ function from creating elements
| Reported by: | sayrer@gmail.com | 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.
Attachments (0)
Change History (9)
Changed April 24, 2012 02:09AM UTC by comment:1
| component: | unfiled → core |
|---|---|
| priority: | undecided → low |
| resolution: | → wontfix |
| status: | new → closed |
Changed April 24, 2012 02:13AM UTC by comment:2
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.
Changed April 24, 2012 02:17AM UTC by comment:3
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?
Changed April 24, 2012 02:28AM UTC by comment:4
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.
Changed April 24, 2012 02:32AM UTC by comment:5
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?
Changed April 24, 2012 02:33AM UTC by comment:6
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?
Changed April 24, 2012 02:35AM UTC by comment:7
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.
Changed April 24, 2012 02:36AM UTC by comment:8
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.
Changed April 24, 2012 02:43AM UTC by comment:9
OK thanks guys.
Sorry, but this would create a massive backwards compatibility break. jQuery.fn.init can be overridden with a custom constructor.