On 4/4/07, Arnar Birgisson [EMAIL PROTECTED] wrote:
Hi all,
This is an interesting discussion, and the issue is something
developers need to be aware of. I'm not going to pass judgement on if
it should be blamed on frameworks (client-side or otherwise).
I think we should mention it in the
This has worried me also.
The problem is that the json load could be included in a rogue web
page by using a script tag. Since the author of this page has total
control of what he will display he can subvert the javascript
interpreter to run whatever he like when the json object is executed
It can be done almost transparently, by simply replacing
/^while\(1\);/ with in evalJSON(). This would leave data without
the safeguard as-is. The only code it would brake, would be code that
relied on having such code running, and that would be insane anyway
...
I prefer while(1); over
I agree with you, while(1); is better. :-) A bit uglier, but you are
correct that some data could get out of the comment.
The problem is that the evalJSONRequest() don't use the evalJSON()
function to evaluate the JSON. This is bad, because there are in fact
two ways of evaluating JSON on using
On 4/3/07, troels knak-nielsen [EMAIL PROTECTED] wrote:
This might be of interest.
http://www.fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking.pdf
That paper is very misleading. It doesn't really have anything to do
with client-side toolkits at all.
The exploit in question
On 4/3/07, Victor Bogado [EMAIL PROTECTED] wrote:
That paper is very misleading. It doesn't really have anything to do
with client-side toolkits at all.
I don't agree, it is irresponsible from the part of a toolkit to offer
a short-cut to a much desired operation that is known to be
have you read the link I sent? it is possible to leak information with
objects on the outside, sure it uses this feature that only ie and
firefox implement but fact is that those two are responsible for 90%
or more of all user in the internet. The proposed fix is simple enough
to implement, both
On 4/3/07, Victor Bogado [EMAIL PROTECTED] wrote:
have you read the link I sent? it is possible to leak information with
objects on the outside, sure it uses this feature that only ie and
firefox implement but fact is that those two are responsible for 90%
or more of all user in the
Bob Ippolito wrote:
However, I'm going to go ahead and support comment-wrapped JSON just
so you all will shut up.
Here's a better idea: Why doesn't someone show you an example of
MochiKit being attacked in this way, then you'll fix it if the attack is
caused by MochiKit :)
signature.asc
If the server-side doesn't send arrays, then it's not a problem and we
don't need a new specification or any changes to the clients.
If nothing else, it's probably a good thing to mention in the documentation.
--
troels
--~--~-~--~~~---~--~~
You received this
Valerio's (of mootools fame) response when asked to comment on that
article: Comment? On this bullshit? [...] Security is made server-side,
not client side. There is no such thing as security in javascript.
Look, Bob's right. That fact of the matter is that Javascript can be changed
in any way,
11 matches
Mail list logo
