-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Rasmus Lerdorf wrote:
> We should probably have done it this way right from
> the beginning, but since we didn't and since we don't really want to
> deal with the potential BC issues of changing working code, we have to
> add it as an option at th
The second is the one I'm trying to address, wherein data that belongs
in a JS parsing context may (coincidentally) contain HTML parsable data.
For *whatever* reason, this data may accidently be echoed outside of a
JS context, or a parsing/rendering error may lead to the browser
switching unex
payload to innerHTML, you are hosed. Using the \u syntax, even if you
mess up and that blob of data finds its way to an innerHTML, nothing
nasty can happen. Basically this is a more robust context-protected way
I'm not sure this is correct - if you just write something like:
var =
payload to innerHTML, you are hosed. Using the \u syntax, even if you
mess up and that blob of data finds its way to an innerHTML, nothing
nasty can happen. Basically this is a more robust context-protected way
I'm not sure this is correct - if you just write something like:
var =
Rasmus Lerdorf skrev:
It may not be the browser that misses the
Keryx Web wrote:
> Alexey Zakhlestin skrev:
>> I think I understand what the use-case is…
>>
>> If the browser doesn't know anything about tag, it is
>> supposed to interpret it's contents as html… In which case, html-tags
>> which appear in javascript code will actually become active ones
>>
>
>
Alexey Zakhlestin skrev:
I think I understand what the use-case is…
If the browser doesn't know anything about
I think I understand what the use-case is…
If the browser doesn't know anything about
I think I understand what the use-case is…
If the browser doesn't know anything about
One thing to consider is changing json_encode to add a header
Content-type: application/json (or x-javascript), unless the additional
arguments are used..
That way someone using the function to intermingle with HTML will be
faced with the fact they have to encode the output, otherwise it breaks
Alan Knowles wrote:
> One thing to consider is changing json_encode to add a header
> Content-type: application/json (or x-javascript), unless the additional
> arguments are used..
> That way someone using the function to intermingle with HTML will be
> faced with the fact they have to encode the o
One thing to consider is changing json_encode to add a header
Content-type: application/json (or x-javascript), unless the additional
arguments are used..
That way someone using the function to intermingle with HTML will be
faced with the fact they have to encode the output, otherwise it breaks
This is just a different way of encoding Javascript which depending on
the context of use will enable Javascript to be embedded securely. Not
providing an alternate encoding is a bit like arguing that we shouldn't
have base64_encode() because if used incorrectly it could be insecure.
I'm not sa
Stanislav Malyshev wrote:
>> Stuff like this often isn't completely deterministic. The attack
>> vectors will move around and new ones will be discovered but since the
>> syntax Sara is proposing is completely valid JSON it gives people
>> another tool. Documenting specific attack vectors is usef
Stuff like this often isn't completely deterministic. The attack
vectors will move around and new ones will be discovered but since the
syntax Sara is proposing is completely valid JSON it gives people
another tool. Documenting specific attack vectors is useful too, of
course, but a secondary co
Alexey Zakhlestin wrote:
> On 12/2/07, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
>> The \u syntax is specific to JSON, yes.
>
> \u syntax is specific to javascripts string literals, regular
> expressions and identifiers[1]
> And JSON is not the only way to deliver data into javascript. Manual
> ap
On 12/2/07, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
> The \u syntax is specific to JSON, yes.
\u syntax is specific to javascripts string literals, regular
expressions and identifiers[1]
And JSON is not the only way to deliver data into javascript. Manual
approaches are still useful
[1] -
htt
Alexey Zakhlestin wrote:
> Is such filtering specific to JSON? Does it have some use out of JSON-context?
> Maybe it would be better to provide a set of functions for encoding
> characters into '\u'-entities? (similiar to htmlentities,
> htmlspecialchars)
>
> because if we speak of 'theoretical' p
Is such filtering specific to JSON? Does it have some use out of JSON-context?
Maybe it would be better to provide a set of functions for encoding
characters into '\u'-entities? (similiar to htmlentities,
htmlspecialchars)
because if we speak of 'theoretical' problem, we might end
reimplementing t
Stanislav Malyshev wrote:
>> I can't because I don't know of any successful vectors *currently*. I
>> also would have sworn that echoing htmlentified data was safeuntil
>> I came across a browser where it wasn't.
>
> So that's what I wanted to understand, because if we add this feature,
> we
I can't because I don't know of any successful vectors *currently*. I
also would have sworn that echoing htmlentified data was safeuntil I
came across a browser where it wasn't.
So that's what I wanted to understand, because if we add this feature,
we should give some explanation on when
Stanislav Malyshev wrote:
You're absolutely correct that this won't save us from brain-dead
engineers, what it will save us from is broken browsers which
misinterpret otherwise legitimate data and get broken out of their
proper context. (Yes, I've seen browsers do exactly this, and you can
pro
if we want to
we should do
echo htmlspecialchars(json_encode($stringValue)) instead actually, and
yes JSON_HEX_TAG will help avoiding htmlspecialchars() just like
urlencode()ed data which never contains < > or so.
i'm not sure if there is problem if you put json_encode()ed data in
You're absolutely correct that this won't save us from brain-dead
engineers, what it will save us from is broken browsers which
misinterpret otherwise legitimate data and get broken out of their
proper context. (Yes, I've seen browsers do exactly this, and you can
probably guess which versions)
To that end, the attached patch allows the caller to be paranoid about
their data and stipulate that <>&' should be encoded to hex references
instead. This doesn't stop a web developer from dropping that content
into an innerHTML of course, but it's one more rope holding the ship
together.
C
To that end, the attached patch allows the caller to be paranoid about
their data and stipulate that <>&' should be encoded to hex references
instead. This doesn't stop a web developer from dropping that content
into an innerHTML of course, but it's one more rope holding the ship
together.
C
str_replace() *can* fix the problem, but when you have a series of
nested arrays and objects, solving that problem with a separate loop
becomes onerous.
-Sara
P.S. - Sorry about the tripple post before...
Alexey Zakhlestin wrote:
is it really needed?
str_replace can easily do that…
it just
is it really needed?
str_replace can easily do that…
it just looks like this "unidentified problem" is not specific to json
On 11/29/07, Sara Golemon <[EMAIL PROTECTED]> wrote:
> While it's technically "safe" to include user supplied data in
> json_encode() serialized values. The fact that chara
Sara Golemon wrote:
> While it's technically "safe" to include user supplied data in
> json_encode() serialized values. The fact that characters such as <>&'
> remain as is means there room for some as-yet unidentified problem
> either in the browser's rendering or (more likely) elsewhere in one's
While it's technically "safe" to include user supplied data in
json_encode() serialized values. The fact that characters such as <>&'
remain as is means there room for some as-yet unidentified problem
either in the browser's rendering or (more likely) elsewhere in one's
codebase for this data
While it's technically "safe" to include user supplied data in
json_encode() serialized values. The fact that characters such as <>&'
remain as is means there room for some as-yet unidentified problem
either in the browser's rendering or (more likely) elsewhere in one's
codebase for this data
While it's technically "safe" to include user supplied data in
json_encode() serialized values. The fact that characters such as <>&'
remain as is means there room for some as-yet unidentified problem
either in the browser's rendering or (more likely) elsewhere in one's
codebase for this data
32 matches
Mail list logo
