Opened 15 years ago
Closed 15 years ago
#2567 closed feature (fixed)
$.ajax should allow filtering JS and JSON responses to remove security measures
Reported by: | eventualbuddha | Owned by: | flesler |
---|---|---|---|
Priority: | major | Milestone: | 1.2.4 |
Component: | ajax | Version: | 1.2.3 |
Keywords: | security | Cc: | |
Blocked by: | Blocking: |
Description
Responses that contain executable JS or even bare JSON may pose a security risk when a malicious site requests such things via a <script>
tag (see http://www.fortify.com/servlet/downloads/public/JavaScript_Hijacking.pdf).
To compliment a server-side JS/JSON mechanism, I propose that jQuery allow users to specify a filter that will remove whatever is added to the payload to render it safe for <script>
tags. Popular methods are prepending while(1);
and wrapping the response in a comment. In this patch I've gone with the latter, using a filter identical to the one Prototype uses. Users are free to choose their own, as it is simply a regular expression. Here is an example of the wrapped JSON:
/*-secure- { "data": {"lang": "en", "length": 25} } */
I'm not super-familiar with jQuery, so there may be problems with this patch, particularly with regard to the tests, so please modify to suit whatever guidelines I missed.
Attachments (2)
Change History (7)
Changed 15 years ago by
Attachment: | json_with_security.diff added |
---|
comment:1 Changed 15 years ago by
Type: | enhancement → feature |
---|
comment:2 Changed 15 years ago by
Owner: | set to flesler |
---|---|
Status: | new → assigned |
Changed 15 years ago by
Attachment: | ajax-filter.diff added |
---|
comment:3 Changed 15 years ago by
I like the idea of using a function but wonder if we should provide an optional, default function for developers to utilize... hopefully making it that much easier to make their JSON feeds more secure.
comment:5 Changed 15 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Added the possibility to use a parsing function by the name of 'dataFilter' at [5620].
I'd prefer a function, that receives a string, and returns a string. That gives more flexibility than a regex. One could simply sanitize the response from possible injection