Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #17096 > unrolled thread

eval - how to

Back to article view | Back to comp.lang.javascript

Contents

  eval - how to Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-11-09 12:47 +0100
    Re: eval - how to Asen Bozhilov <asen.bozhilov@gmail.com> - 2012-11-09 05:53 -0800
      Re: eval - how to Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-11-09 22:28 +0100
        Re: eval - how to Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-11-10 10:23 +0100
        Re: eval - how to Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-11-10 11:15 +0100
          Re: eval - how to Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-11-11 00:35 +0100
            Re: eval - how to Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-11-11 20:34 +0100
      Re: eval - how to Dr J R Stockton <reply1245@merlyn.demon.co.uk.invalid> - 2012-11-10 22:42 +0000
    Re: eval - how to Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-11-09 17:46 +0100
      Re: eval - how to Tim Streater <timstreater@greenbee.net> - 2012-11-09 17:00 +0000
        Re: eval - how to Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-11-09 18:19 +0100
      Re: eval - how to Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-11-09 22:49 +0100
        Re: eval - how to Asen Bozhilov <asen.bozhilov@gmail.com> - 2012-11-09 16:40 -0800
          Re: eval - how to Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-11-10 11:36 +0100
            Re: eval - how to Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-11-10 13:29 +0100
              Re: eval - how to Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-11-10 13:55 +0100
                Re: eval - how to Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-11-10 14:17 +0100
                  Re: eval - how to Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-11-10 20:50 +0100
                    Re: eval - how to Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-11-10 22:54 +0100
                      Re: eval - how to Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-11-11 15:22 +0100
                        Re: eval - how to Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-11-11 16:24 +0100
                          Re: eval - how to Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-11-11 19:23 +0100
            Re: eval - how to Asen Bozhilov <asen.bozhilov@gmail.com> - 2012-11-11 10:40 -0800
              Re: eval - how to Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-11-11 20:41 +0100
                Re: eval - how to Asen Bozhilov <asen.bozhilov@gmail.com> - 2012-11-11 13:34 -0800
                  Re: eval - how to Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-11-11 23:03 +0100
        Re: eval - how to Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-11-10 10:21 +0100
    Re: eval - how to SAM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> - 2012-11-10 04:16 +0100

Page 2 of 2 — ← Prev page 1 [2]

#17165

W dniu 2012-11-11 15:22, Thomas 'PointedEars' Lahn pisze:
> Cezary Tomczyk wrote:
>
>> W dniu 2012-11-10 20:50, Thomas 'PointedEars' Lahn pisze:
>>> BTW, iframe cross-domain scripting requires a proper `X-Frame-Options'
>>> response header field value in case document.domain is not applicable.
>>
>> Which mostly should not be a problem to set this header.
>
> How so?

I do not understand your question. I was thinking about sending header 
from server with "X-Frame-Options" which should be easy if you have 
access to server.

As for X-Frame-Options I found more about that here: 
https://developer.mozilla.org/pl/docs/The_X-FRAME-OPTIONS_response_header

> Please trim your quotes to the relevant minimum.

Sometimes it's hard do define what is "relevant minimum". Everybody has 
a own definition.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

[toc] | [prev] | [next] | [standalone]

#17172

Cezary Tomczyk wrote:

> W dniu 2012-11-11 15:22, Thomas 'PointedEars' Lahn pisze:
>> Cezary Tomczyk wrote:
>>> W dniu 2012-11-10 20:50, Thomas 'PointedEars' Lahn pisze:
>>>> BTW, iframe cross-domain scripting requires a proper `X-Frame-Options'
>>>> response header field value in case document.domain is not applicable.
>>> Which mostly should not be a problem to set this header.
>> How so?
> 
> I do not understand your question. I was thinking about sending header
> from server with "X-Frame-Options" which should be easy if you have
> access to server.

IMHO, the most likely use-case scenario for this header field is that you do 
_not_ have access to the server, and that the person providing a service 
that you want to use sets it for a specific resource.

> As for X-Frame-Options I found more about that here:
> https://developer.mozilla.org/pl/docs/The_X-FRAME-OPTIONS_response_header

Exactly.
 
>> Please trim your quotes to the relevant minimum.
> 
> Sometimes it's hard do define what is "relevant minimum". Everybody has
> a own definition.

While that is true, quoting *everything* from a 100+ lines posting as you 
did e. g. in <news:k7mocc$sec$1@speranza.aioe.org> certainly is not 
appropriate by any reasonable measure as it wastes precious resources 
(space, time, nerves) needlessly.  You can [summarize] if all else fails.

See also <http://www.netmeister.org/news/learn2quote.html>


PointedEars
-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[toc] | [prev] | [next] | [standalone]

#17173

Thomas 'PointedEars' Lahn wrote:

> Even if it was not a cross-origin request, there is no guarantee that the
> data are coming from the requested site.  You can work around the SOP
> yourself by setting up a transparent proxy for certain requests to your
> server, and there can still be a man-in-the-middle (MITM)-attack when you
> did not.

Man in the middle is not the case. Usually serious API-s communicate
through the SSL, which breaks MITM attacks.
If the communication between the your client and your server is not
secured and if there is MITM, your client has definetely more troubles
to care about JSON parsing.
If the resource is *trusted* still don't see the problem with Function
constructr.

[toc] | [prev] | [next] | [standalone]

#17176

Asen Bozhilov wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Even if it was not a cross-origin request, there is no guarantee that the
>> data are coming from the requested site.  You can work around the SOP
>> yourself by setting up a transparent proxy for certain requests to your
>> server, and there can still be a man-in-the-middle (MITM)-attack when you
>> did not.
> 
> Man in the middle is not the case. Usually serious API-s communicate
> through the SSL, which breaks MITM attacks.

It certainly helps to avoid them; it does not prevent them, and it certainly 
does not "break" them in any meaning of the word.  There is a good reason 
why Microsoft recommended upgrading to 1024-bit certificates recently.

> If the communication between the your client and your server is not
> secured and if there is MITM, your client has definetely more troubles
> to care about JSON parsing.

While I was not talking about JSON specifically, your logic is still flawed.

> If the resource is *trusted* still don't see the problem with Function
> constructr.

Trust is relative.  There is no 100% secure system.


PointedEars
-- 
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
  -- Richard Cornford, comp.lang.javascript, 2011-11-14

[toc] | [prev] | [next] | [standalone]

#17181

Thomas 'PointedEars' Lahn wrote:

> > Man in the middle is not the case. Usually serious API-s communicate
> > through the SSL, which breaks MITM attacks.
>
> It certainly helps to avoid them; it does not prevent them, and it certainly
> does not "break" them in any meaning of the word.  There is a good reason
> why Microsoft recommended upgrading to 1024-bit certificates recently.

You are still missing the point. If you and your client have MITM
attack you have really bigger problem than parsing of JSON. If there
is MITM it could change anything on your page, also your parsing JSON
script. MITM attacks through the SSL cannot be achieved. Most of the
attacks depend on that the client initialize unsecure connection to
the server exactly before starting the secure connection. MITM in that
case becomes communicate with the server through the secured channel,
while serves the data to the client through unsecure channel. So this
is not exactly MITM and gracefully could be prevent, especially when
we talk about transparent server side proxy.

[toc] | [prev] | [next] | [standalone]

#17182

Asen Bozhilov wrote:

> Thomas 'PointedEars' Lahn wrote:
>> > Man in the middle is not the case. Usually serious API-s communicate
>> > through the SSL, which breaks MITM attacks.
>>
>> It certainly helps to avoid them; it does not prevent them, and it
>> certainly does not "break" them in any meaning of the word.  There is a
>> good reason why Microsoft recommended upgrading to 1024-bit certificates
>> recently.
> 
> You are still missing the point. If you and your client have MITM
> attack you have really bigger problem than parsing of JSON.

Which does not negate the possibility of such an attack.

> If there is MITM it could change anything on your page, also your parsing
> JSON script.

Again, I was not talking about JSON specifically.

> MITM attacks through the SSL cannot be achieved. […]

Patently wrong.


PointedEars
-- 
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[toc] | [prev] | [next] | [standalone]

#17113

Cezary Tomczyk wrote:

> As for parsing JSON string and according to what wrote Asen. Quick
> review of David Mark code bring me [1]:
> 
> [...]
>   return function(s) { return (new Function('return (' + s + ')'))(); };
> [...]
> 
> On the other hand, looked into the code
> https://github.com/douglascrockford/JSON-js/blob/master/json2.js [2] and
> I see much, much more complicated regexps and rest of code to check JSON
> string before its evaluated.
> 
> Now I am more confused than before. Why code [1] is so simple and code
> [2] is so complicated?

One executes ECMAScript-conforming code.  The other evaluates *data* that 
needs to be parsed according to JSON, which is a *subset* of ES syntax, 
instead.

Until there were implementations of ES 5 there was no built-in JSON 
parser/serializer, and for some other programming languages there still is 
not.  So people (starting with Douglas Crockford, who devised JSON) wrote 
and are writing libraries to support it.


PointedEars
-- 
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[toc] | [prev] | [next] | [standalone]

#17112

Le 09/11/12 12:47, Cezary Tomczyk a écrit :
> According to "Better not use eval() because ... ":
>
> How to use eval in a correct way?
>
> For example when I'll get the JavaScript (or any other EcmaScript
> implementation) code through XMLHttpRequest then how to safely eval the
> code?


the correct way is : DO NOT use eval ;-)

maybe :

document.getElementsByTagName('script')[0].innerHTML += xhr.responseText;

or :

var s = document.createElement('script');
s.type = 'text/javascript';
s.innerHTML = xhr.responseText;
document.getElementsByTagName('head')[0].appendChild(s);


Not sure IE will appreciate !
-- 
Stéphane Moriaux avec/with iMac-intel

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.javascript

csiph-web