Rasmus Lerdorf skrev:
It may not be the browser that misses the script tag. It may be the
developer.
To make things clear. My intention was not to question the value in
escaping data or even to give an opinion whatsoever about Sara's patch.
I was only replying to Alexey's notion that one
Keryx Web wrote:
Alexey Zakhlestin skrev:
I think I understand what the use-case is…
If the browser doesn't know anything about script 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
And in
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
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:
script
var =
-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 this
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:
script
var =
I think I understand what the use-case is…
If the browser doesn't know anything about script 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
The common practice for dealing with this problem is
I think I understand what the use-case is…
If the browser doesn't know anything about script 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
This makes sense. Though wouldn't
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
approaches
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
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 useful too,
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
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
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
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] -
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
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'
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
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 should
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 to
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 to
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 to
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
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 characters
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
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.
Can
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
if we want to
a onclick=process(?php echo json_encode($stringValue); ?)
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
30 matches
Mail list logo
