1

Topic: And still slightly about [] JS

Excellent presentation of Natali Silvanovich from Google P0 how design JS involves appearance  in its fulfilling environments on example Chakra. And from myself concerning JS I can add also that in an adjacent subject in  though broke off darkness of copies, but for some reason so did not recall (like) one important property of language:  the code written on it. Including  its safety. At dynamic languages with , for the clear reasons and so all is not quite healthy. And JS with its type system based (actually) on monkey-patching'e, forces   to smoke all who is anyhow connected to static analysis area. For an example the small statistics. In 2014 I and one more developer for 2 months  from zero a prototype of the abstract interpreter C#. Hardly earlier one developer from an adjacent command for 3 months  a prototype of the abstract interpreter PHP. Two developers from one more command approximately for the same time time mastered interpreter Java prototype. But anybody from us, till now (when those prototypes grew for a long time already in a product with two major releases and one hundred minor) does not know, from what side to steal up to analyzer JS prototyping. And security-suddenness with tests as though you will not cover, therefore  TDD here it is perfect  Here such "excellent" language from a belltower of our brother. UPD: the link on  Natali: https://conference.hitb.org/hitbsecconf … Chakra.pdf

2

Re: And still slightly about [] JS

Hello, kochetkov.vladimir, you wrote: KV>... Does not know, from what side to steal up to prototyping JS. Where , in language or in DOM?

3

Re: And still slightly about [] JS

Hello, kochetkov.vladimir, you wrote: KV> And from myself concerning JS I can add also that in an adjacent subject though broke off darkness of copies, but for some reason so did not recall (like) one important property of language:  the code written on it. Including  its safety. At dynamic languages with , for the clear reasons and so all is not quite healthy. And JS with its type system based (actually) on monkey-patching'e, forces   to smoke all who is anyhow connected to static analysis area. For an example the small statistics. In 2014 I and one more developer for 2 months  from zero the abstract interpreter C#. Hardly earlier one developer from an adjacent command for 3 months  a prototype of the abstract interpreter PHP. Two developers from one more command approximately for the same time time mastered interpreter Java prototype. But anybody from us, till now (when those prototypes grew for a long time already in a product with two major releases and one hundred minor) does not know, from what side to steal up to prototyping JS. It will be very lonely  because very few people understands safety problems. Here article at least with the description of the general situation explicitly is required.

4

Re: And still slightly about [] JS

Hello, kochetkov.vladimir, you wrote: KV> But anybody from us, does not know till now, from what side to steal up to prototyping JS. Strange it. It wooden, and in browsers appeared in the core because of the primitiveness.

5

Re: And still slightly about [] JS

Hello, fin_81, you wrote: _> Hello, kochetkov.vladimir, you wrote: KV>>... Does not know, from what side to steal up to prototyping JS. _> Where , in language or in DOM? In DOM there are the , but they are faster purely engineering and the initial message I spoke not about them. At the abstract interpretation, in particular, for each changeable variable all values which __ at it to be in current execution point are saved, and also for each of these values the condition at which this variable value is actual is saved. , after interpretation of such code: a = 10; if (b> 5) {a + = b} the variable an in exit point from conditional statement will have following values: a = {b <=5-> 10, b> 5-> 10+b}. Change of any variable under a condition (in conditional statement, at each iteration of a cycle or in an exception handler, after the conditional reset from function, etc.) Actually adds in  a variable one more conditional  and adds conditions of all previous values (with optimization on a subject of that values with contradictory conditions are discarded). At worst, it gives EXPSPACE from cyclomatic complexity of the code. It is actual for all languages and JS here with anything especially is not selected. On the other hand, the type of object from the point of view of the analyzer is a description of the protocol of its interaction with other objects, i.e. an exchange of values between its variables and variables of other objects. In static languages the information on types allows to adhere to one model constructed on the basis of all these protocols during the analysis. In dynamic languages, this model should be deduced on the fly, on a course of the abstract interpretation of the code. In the languages admitting monkey-patching, at each change of any type under a condition, the amount of models actually doubles. Assignment of variable value to object with the changed type demands reflection in all "" model. Only already with conditions and values of model, and values of a specific variable of its specific object. And in JS model change is the main method of construction of types All it together gives such combinatorial explosion on storage, what even concerning the simple code becomes very uneasy to scroll simply at least the abstract interpreter. And after, all these conditions (added by restrictions, characteristic for resolved property of the code) still leave in SMT-solver which gives EXPTIME from their volume (which EXPSPACE. I will remind). The analyzer working on time for e^n^n looks very sadly.  the primary goal of any modern analyzer consists in reasonable approximation of the researched code to retain all these exponents in a bridle.  scrolling only the first N iterations of cycles or a recursion, for example, can be such, or only significant iterations (if property of significance manages to be deduced from a cycle invariant), etc. Analyzer JS should work actively also also with approximation of the computational model in which frames the abstract interpretation as it "slightly" depends on all types defined in application is carried out. And here about it, also ten scientific operations from every corner of the globe will not be typed. And the majority from existing, is the whole dissertations, instead of articles on 2-3 pages. Therefore existing analyzers are content with the model simplified to a disgrace and stupidly break off on more or less complex code (about  JS in language from 6 instructions, I generally am silent). For tasks IDE still though somehow it is possible to name it comprehensible, but at the analysis of security it leads to heap appearance  both sorts that brings all favor of such analyzer somewhere close to naught.... <<RSDN@Home 1.0.0 alpha 5 rev. 0>>

6

Re: And still slightly about [] JS

Hello, neFormal, you wrote: F> it will be very lonely  because very few people understands safety problems. F> here article at least with the description of the general situation explicitly is required. My answer fin_81 see above. Specificity of safety there only that the majority of questions about presence  in the code (that the Author generally is: kochetkov.vladimir Date: 19.04 23:08 the task, BTW) whether it is reduced to "can a data stream from set of sources A come to execution point from set of dangerous functions B, corresponding thus to grammar (or to set ), specific to a class of attacks to a specific element b from set B?" . A and B for JS it is possible to appreciate here: https://github.com/wisec/domxsswiki/wiki (sources is A, sinks is B). Without stipulations about grammar this task dares rather easily, even for JS, but gives a heap . The stipulation about grammar does not leave  chance, but only under condition of absence of approximations of the code or, especially, its computational model. As leads us to about what I wrote fin_81.... <<RSDN@Home 1.0.0 alpha 5 rev. 0>>

7

Re: And still slightly about [] JS

Hello, Glory, you wrote: KV>> But anybody from us, does not know till now, from what side to steal up to prototyping JS. Strange it. It wooden, and in browsers appeared in the core because of the primitiveness. Well, in browsers how much I remember, it appeared because it under them and . But it does not change an essence. Idle time for the developer! = idle time for the analyzer. LISP, for example - is even easier, but to do under it the analyzer... Personally I would not undertake... <<RSDN@Home 1.0.0 alpha 5 rev. 0>>

8

Re: And still slightly about [] JS

Hello, kochetkov.vladimir, you wrote: KV>>>... Does not know, from what side to steal up to prototyping JS. _>> Where , in language or in DOM? KV>... In the languages admitting monkey-patching... Almost all dynamic languages admit it. For js is different  for construction of types. Can it is necessary sharpen under them analyzers? And crude js hardly where it is used for creation counting for something.

9

Re: And still slightly about [] JS

Hello, fin_81, you wrote: _>... And crude js hardly where it is used for creation counting for something. And generally, the analysis crude moreover  a js-code smells slightly of unreasonable expenditure of resources, i.e. .

10

Re: And still slightly about [] JS

Hello, fin_81, you wrote: _> And generally, the analysis crude moreover  a js-code smells slightly of unreasonable expenditure of resources, i.e. . Yes it is fine. Not that JS - x86 the assembler  analyze.

11

Re: And still slightly about [] JS

Hello, Glory, you wrote: _>> And generally, the analysis crude moreover  a js-code smells slightly of unreasonable expenditure of resources, i.e. . Yes it is fine. Not that JS - x86 the assembler  analyze. It is possible to analyze all. And here that turns out at synthesis?

12

Re: And still slightly about [] JS

Hello, kochetkov.vladimir, you wrote: KV> Well, in browsers how much I remember, it appeared because it under them and . But it does not change an essence. Idle time for the developer! = idle time for the analyzer. LISP, for example - is even easier, but to do under it the analyzer... Personally I would not undertake Then at what here was specific JS? There is a subset of languages to which we do not apply (more likely very restrictedly apply) the described approach to the safety analysis.

13

Re: And still slightly about [] JS

Hello, kochetkov.vladimir, you wrote: KV> Excellent presentation of Natali Silvanovich from Google P0 how design JS involves appearance  in its fulfilling environments on example Chakra. ... And the link? Or it in May? Though idea the specific example is obvious, interesting. KV> and from myself concerning JS I can add also that in an adjacent subject though broke off darkness of copies, but for some reason so did not recall (like) one important property of language:  the code written on it. Including  its safety. At dynamic languages with , for the clear reasons and so all is not quite healthy. And JS with its type system based (actually) on monkey-patching'e, forces   to smoke all who is anyhow connected to static analysis area. For an example the small statistics. In 2014 I and one more developer for 2 months  from zero the abstract interpreter C#. Hardly earlier one developer from an adjacent command for 3 months  a prototype of the abstract interpreter PHP. Two developers from one more command approximately for the same time time mastered interpreter Java prototype. But anybody from us, till now (when those prototypes grew for a long time already in a product with two major releases and one hundred minor) does not know, from what side to steal up to prototyping JS. I am afraid, only at rigid restriction of language. Lower layer feature set (restricted by possibilities) plus on upper something like TypeScript, probably, even more clamped in frames. And an absolute prohibition to change/modify prototypes. Then it is possible to speak about chances. KV> and security-suddenness with tests as though you will not cover, therefore  TDD here it is perfect  Here such "excellent" language from a belltower of our brother. Well, TDD and with any C does not help, when the indirect code starts to modify another's storage. Here Java/C# good examples just "golden mean" between upper and lower layer, and between two permissivenesses.

14

Re: And still slightly about [] JS

Hello, kochetkov.vladimir, you wrote: KV> And security-suddenness with tests as though you will not cover, therefore  TDD here it is perfect  Here such "excellent" language from a belltower of our brother. And with the assembler x86 it was easier or how?

15

Re: And still slightly about [] JS

Hello, kochetkov.vladimir, you wrote: KV> In static languages the information on types allows to adhere to one model constructed on the basis of all these protocols during the analysis. In dynamic languages, this model should be deduced on the fly, on a course of the abstract interpretation of the code. And type hinting here helps or not?

16

Re: And still slightly about [] JS

Hello, anonymous, you wrote: A> Then at what here it is is specific JS? There is a subset of languages to which it is not applicable (more likely very restrictedly the described approach to the safety analysis is applicable). Can thus, what it is most widespread of this subset?

17

Re: And still slightly about [] JS

Hello, neFormal, you wrote: KV>> In static languages the information on types allows to adhere to one model constructed on the basis of all these protocols during the analysis. In dynamic languages, this model should be deduced on the fly, on a course of the abstract interpretation of the code. F> and type hinting here helps or not? Any indirect piece of the code which was not checked and at all from this source Here comes, and changes object type. And that starts to behave absolutely differently. And  continues to show that all .

18

Re: And still slightly about [] JS

Hello, netch80, you wrote: KV>>> In static languages the information on types allows to adhere to one model constructed on the basis of all these protocols during the analysis. In dynamic languages, this model should be deduced on the fly, on a course of the abstract interpretation of the code. F>> and type hinting here helps or not? N> any indirect piece of the code which was not checked and at all from this source Here comes, and changes object type. And that starts to behave absolutely differently. And  continues to show that all . Yes, it is clear. I simply think, can really calculate used types, to put down them, and then to run more simple "typified" analyzer.

19

Re: And still slightly about [] JS

Hello, Ops, you wrote: A>> Then at what here it is is specific JS? There is a subset of languages to which it is not applicable (more likely very restrictedly the described approach to the safety analysis is applicable). Ops> can thus, what it is most widespread of this subset? And?

20

Re: And still slightly about [] JS

Hello, fin_81, you wrote: _> And generally, the analysis crude moreover  a js-code smells slightly of unreasonable expenditure of resources, i.e. . And what here variants? How to the analyzer the crude js-code gets not? We admit, speech about the web application where on js the front-end is implemented only. Here - lie in the directory/scripts 100500 scripts and their dependences. Here entry point: ` http://host.domain/path/to/controller2?param1=test1&param2=test2` which processes the controler implemented by class Controller2 on severe C#. How to the analyzer to learn, which leave scripts in reply to this request and how their input data will be connected the dataful answer of the server?... <<RSDN@Home 1.0.0 alpha 5 rev. 0>>

21

Re: And still slightly about [] JS

Hello, neFormal, you wrote: F> I simply think, can really calculate used types, to put down them, and then to run more simple "typified" analyzer. So selected - the same analysis also will be. Types after all will be constructed and declared not is mandatory linearly and right at the beginning, as in  or pascal. In JS they can quite be under the same conditional statements and then each variable using them will concern at once several of them (depending on realizability of appropriate conditions on the input data). Well and hi all the same o (2^n) Manual  - unconditionally helps, but with that stipulation that the correctness of model used by the analyzer will depend on a correctness of the put down types (about what wrote netch80).... <<RSDN@Home 1.0.0 alpha 5 rev. 0>>

22

Re: And still slightly about [] JS

Hello, anonymous, you wrote: A> Then at what here it is is specific JS? There is a subset of languages to which it is not applicable (more likely very restrictedly the described approach to the safety analysis is applicable). BTW is a unique approach to the analysis which can yield a little full results, sufficient for the analysis of security of the code. There are its variations connected to specific performance of insignificant code locations, instead of their abstract interpretation, but it is faster from area of optimization of the initiating approach. And JS here thus that monkey-patching in other dynamic languages __ to be in the code (and, as a rule, it is not welcomed), and in JS it is a basis of the type system implemented in language, i.e. __ to be and consequently practically always is. Well and rules of interpretation of separate idioms of language together with implicit type conversions which the analyzer is obliged to support and thanks to which, became possible existence JSFuck - as though slightly select JS among other (behind an exception, unless, PHP).... <<RSDN@Home 1.0.0 alpha 5 rev. 0>>

23

Re: And still slightly about [] JS

Hello, netch80, you wrote: N> Hello, kochetkov.vladimir, you wrote: KV>> Excellent presentation of Natali Silvanovich from Google P0 how design JS involves appearance  in its fulfilling environments on example Chakra. N> Mneee... And the link? Or it in May? N> though idea the specific example is obvious, interesting. A pancake - the link, certainly, to thrust forgot Updated the start message. N> I Am afraid, only at rigid restriction of language. Lower layer feature set (restricted by possibilities) plus on upper something like TypeScript, probably, even more clamped in frames. And an absolute prohibition to change/modify prototypes. Then it is possible to speak about chances. Well, with TypeScript it is already possible to try to work (but it not that Script which wants while still overwhelming majority of clients), but as a whole all so, yes. N> Here Java/C# good examples just "golden mean" between upper and lower layer, and between two permissivenesses. And Go, by the way, too. And here to analyze Nemerle with Scala - it will be problematic because of the macroes bringing under the abstract interpretation not simply type system, and all components of semantic basis of language:D... <<RSDN@Home 1.0.0 alpha 5 rev. 0>>

24

Re: And still slightly about [] JS

Hello, Ikemefula, you wrote: I> Hello, kochetkov.vladimir, you wrote: KV>> And security-suddenness with tests as though you will not cover, therefore  TDD here it is perfect  Here such "excellent" language from a belltower of our brother. I> and with the assembler x86 it was easier or how? To Whom exactly? If to us (to developers of means of the analysis of the code) yes, it was easier. Truth was specific our decision broadcast  in LLVM IR, feasibly recognizing thus source language constructions, data types, signatures of functions, etc., and the analysis was carried out already within the limits of interpretation received IR. There certainly there were the problems which are connected to necessity to build symbolic-model of all address space and pouring out that  ping was twisted by the interpreter 4 days on Core i7 with 16 GB , is simple to deduce symbolical formulas for all possible ways on the column of a flow of performance. But language of such problems with the analysis as in JS did not cause.... <<RSDN@Home 1.0.0 alpha 5 rev. 0>>

25

Re: And still slightly about [] JS

Hello, kochetkov.vladimir, you wrote: _>> And generally... KV> And what here variants?. You Rajsa with the theorem (I do not know it and I do not understand) everywhere climb. Variants here such - we smile and we wave.