Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 3 of 3 total
Thread use of eval() / CreateObject()
Wed, Feb 12 2020 7:35 PMPermanent Link

erickengelke

Popular wisdom from industry bodies such as OWASP, Mozilla and others recommend we avoid using JavaScript's eval() because bad actors can use it to execute arbitrary code at run time.

Here are some industry links making the case
https://cheatsheetseries.owasp.org
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval

EWB relies heavily on eval() for its CreateObject() function used to create many types objects.  That is, I belive, the only time in the library it is called, but it is called a lot.

The next release should offer an alternative we can use to create objects.

One way would be to have a Pascal-ish asm
like this:
var x : Date
begin
 asm x = new Date()
 result := x;
end
 
where the remainder of the line would be treated as pure javascript.  

Or maybe there are other solutions.  But I think this is something to be addressed.

This concern is raised if your code is ever evaluated by a professional Penetration Tester.  I underwent several such audits for some clients  and this was the only major concern I couldn't address on my own.

Erick
EWB Programming Books and Component Library
http://www.erickengelke.com
Wed, Feb 19 2020 12:42 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Erick,

<< EWB relies heavily on eval() for its CreateObject() function used to create many types objects.  That is, I belive, the only time in the library it is called, but it is called a lot. >>

Define "heavily". Smile

The only place that CreateObject is used is in 3 places:

1) TLocationServices (WebComps), and it is used to create an empty object with a literal: CreateObject('{}').

2) For creating passive event listeners for touch events.  There's no choice here - this is how they need to be handled, and, again, these are created using literals that you can see in the code.

3) Google Maps support (WebMaps): same thing, CreateObject('{}').

All of the CreateObject('{}') calls could be replaced with MyExternalObject.Create types of calls, if you want, but it won't make any difference in the end result because none of them are using any external input in the creation of the JS objects.

<< The next release should offer an alternative we can use to create objects. >>

You can create external JS object instances just like you create normal object instances, it's just a matter of making sure that you have the proper external declarations in your code.  For example, if you wanted to create a date (a DateTime value type in EWB, which is just an integer in both JS and EWB) using the JS Date object (as opposed to just using the numerous date/time functions in EWB that do this for you, like the Date() function), you would use this code:

type

  external TDate emit Date = class
     end;

function CreateDate: DateTime;
begin
  Result:=TDate.Create;
end;

You just need to declare the interface to the TDate class so that it matches the JS implementation.

<< One way would be to have a Pascal-ish asm
like this:
var x : Date
begin
 asm x = new Date()
 result := x;
end >>

Sorry, no, I won't be doing that.  You completely remove the compiler's ability to type-check the JS calls that way, and it opens up huge holes in the quality of the resulting application.
 
<< This concern is raised if your code is ever evaluated by a professional Penetration Tester.  I underwent several such audits for some clients  and this was the only major concern I couldn't address on my own. >>

I've never seen a penetration test look at the browser code before.  Browser code is sandboxed, so the issue of invalid inputs in the browser code is typically not a major concern unless the browser application is connecting to an unknown web server and eval'ing response content from that server.  EWB never eval's data coming from the web server (see above), and always parses the data (JSON) directly, for this very reason.

Tim Young
Elevate Software
www.elevatesoft.com
Wed, Feb 19 2020 9:00 PMPermanent Link

erickengelke

Tim Young [Elevate Software] wrote:

Erick,

<< EWB relies heavily on eval() for its CreateObject() function used to create many types objects.  That is, I belive, the only time in the library it is called, but it is called a lot. >>

> Define "heavily". Smile

I agree with your assessment, and you know circles around my and most people's JavaScript knowledge, but I was just passing along comments from one of the "pen"itration testers who pointed to the resources I mentioned as proof that this was a crisis.  I convinced the client that iEWB wasn't unreasonable since there was no situation where we were passing anything but constant preprogrammed constants.

> I've never seen a penetration test look at the browser code before.  Browser code is sandboxed, so the issue
> of invalid inputs in the browser code is typically not a major concern unless ....

The nature of penetration testing is competitive, and sometimes paranoia-inducing, sometimes leading to somewhat overzealous claims and reports.   

In the end, the client believed my word and the output of the expensive IBM scanner which could not break in with two weeks of constant attempts.  

Erick
EWB Programming Books and Component Library
http://www.erickengelke.com
Image