1

Topic: [] we Search vulnerability in the code: the theory, practice and perspectives SAST

article on a subject of used algorithms in our static analyzer: https://habrahabr.ru/company/pt/blog/305000/ In "philosophy" because the majority of theses therefrom are applicable and to the task of the analysis of the code as a whole, not only to search ... <<RSDN@Home 1.2.0 alpha 5 rev. 76>>

2

Re: [] we Search vulnerability in the code: the theory, practice and perspectives SAST

Hello, kochetkov.vladimir, you wrote: KV> Zapilil article on a subject of used algorithms in our static analyzer: without being experts in the specific given area, but having a wide experience in the field of "automatic" (machine) generation of programs, I can tell that the idea in my opinion come up with at the very beginning of article that "all this art of a deceit" is true. But nevertheless to work over "this" subject it is necessary. Besides recalling one big operation in which code of robots it was automatically generated on the base, errors of their ancestors, I can tell - for vulnerability search it is necessary to solve "simply" the reverse task - "on what data the program appears in the given state". That is the task of creation of the reverse code. That is we take a state and it is generated "the reverse" program which produces the input data. The task solved but only in sets naturally.

3

Re: [] we Search vulnerability in the code: the theory, practice and perspectives SAST

Hello, Andrew. W Worobow, you wrote: AWW> Besides recalling one big operation in which code of robots it was automatically generated on the base, errors of their ancestors, I can tell - for vulnerability search it is necessary to solve "simply" the reverse task - "on what data the program appears in the given state". That is the task of creation of the reverse code. That is we take a state and it is generated "the reverse" program which produces the input data. The task solved but only in sets naturally. The thought interesting, but in practice does not work such approach. The matter is that vulnerability determination through the forbidden states is of interest mostly from the theoretical point of view as completely closed system there is meant the program. In real programs the code ` ExecuteSqlQuery ("SELECT * FROM" + Request. Params ["parm"]) ` it is subject to a SQL-injection, but in the forbidden states as a result of attack it results not the program, and a SQL server which will fulfill this request.... <<RSDN@Home 1.2.0 alpha 5 rev. 76>>

4

Re: [] we Search vulnerability in the code: the theory, practice and perspectives SAST

To read about the analysis of the code about search of tricks normally it is rather entertaining. But here a message to apply static (or even dynamic) the analyzer for detection  in a web is too similar to attempt to treat illness symptoms, instead of its reasons.

5

Re: [] we Search vulnerability in the code: the theory, practice and perspectives SAST

Hello, VTT, you wrote: VTT> to Read about the analysis of the code about search of tricks normally it is rather entertaining. VTT> but here a message to apply static (or even dynamic) the analyzer for detection  in a web is too similar to attempt to treat illness symptoms, instead of its reasons. And in what of an etiology and how it on yours should be treated?

6

Re: [] we Search vulnerability in the code: the theory, practice and perspectives SAST

Well here for example in article there is mention XSS, but a problem not in the resulted piece of the code, and in the arbitrary performance  that on the browser side. A companion who sawed in due time netscape, hardly reflected on safety issues. The main thing was to have time to make new  faster competitors. And here in 30 years of development of a World Wide Web herein we have that we have...

7

Re: [] we Search vulnerability in the code: the theory, practice and perspectives SAST

Hello, kochetkov.vladimir, you wrote: KV> Zapilil article on a subject of used algorithms in our static analyzer: https://habrahabr.ru/company/pt/blog/305000/ In "philosophy" because the majority of theses therefrom are applicable and to the task of the analysis of the code as a whole, not only to search  http://www.pcworld.com/article/3093420/ … eless.html

8

Re: [] we Search vulnerability in the code: the theory, practice and perspectives SAST

Hello, 0BD11A0D, you wrote: BDA> Hello, kochetkov.vladimir, you wrote: KV>> Zapilil article on a subject of used algorithms in our static analyzer: https://habrahabr.ru/company/pt/blog/305000/ In "philosophy" because the majority of theses therefrom are applicable and to the task of the analysis of the code as a whole, not only to search  BDA> http://www.pcworld.com/article/3093420/ … eless.html TL/DR for those who was too lazy to read original article of those guys: they took standard NIST' a test dial-up for Java/C and, using the approach similar with described in my article, imported cases of these examples in real  projects which then scanned two not named analyzers (SAST on the basis of symbolical executions and DAST on the basis of classical ). As a result, have been found out only about 2 % from total number of cases. However, though the idea of obtaining of test cases on the basis of real projects is interesting enough, its implementation does not withstand any criticism: 1. Note that the names of tools under evaluation are being withheld in reporting results. Careful evaluation is a large and important job, and we would not want to give it short shrift, either in terms of careful setup and use of tools, or in presenting and discussing results. Almost all modern means DAST and SAST demand some preset adjustment on the specific project. Some, demand project adjustment on the specific analyzer. Their start stupidly "from the button", in most cases, leads to obtaining of not representative results of the analysis. 2. That it is possible to formalize in terms of properties of the researched code, it is possible to detect means of the automated analysis with mathematical accuracy. That it is impossible to formalize, it is possible to detect only  that gives at the best approximately equal ratio  both types to correct results. The considerable part of cases of test dial-up Juliet contains examples of lacks, instead of . A difference in between in relationship of cause and effect: the lack is something present or missing in the code that further on the code can result (and can and not result) in vulnerability origin. The majority of lacks are not formalized. Besides, the task of means of the analysis of security is search first of all , instead of lacks. Presence in the code of a lack speaks nothing about its security - the lack can and "not shoot", and can and be generally the realized decision of developers of the code (for example, usage not kriptograficheski-strong PRNG there where it and it is not required), in difference from vulnerability. 3. 3/4 cases  this dial-up, show non-formalizable to vulnerability. While 3/4  to really actual attacks for a web (http://projects.webappsec.org/w/page/13 … sification) to itself are quite formalizable. Actually, and guys in article write that it is not necessary to do an output about efficiency of specific means SAST and DAST on their operation. But to that journalist, probably so it would be necessary to break covers that it in haste passed this part = /

9

Re: [] we Search vulnerability in the code: the theory, practice and perspectives SAST

Hello, VTT, you wrote: VTT> Well here for example in article there is mention XSS, but a problem not in the resulted piece of the code, and in the arbitrary performance  that on the browser side. VTT> a companion who sawed in due time netscape, hardly reflected on safety issues. The main thing was to have time to make new  faster competitors. VTT> and here in 30 years of development of a World Wide Web herein we have that we have... Yes, and the Background-nejman did not think to what its idea to store the data and the code in one storage - to it results if only was the operations to publish faster. And who is guilty in appearance possibility in applications of errors of access, various logical ` goto fail; ` and other injections in these yours shellshock' - still it is necessary to clarify Forgive, but it is space. And we people simple - walk by the ground and we aspire to solve problems of the data domain more obvious and achievable methods... <<RSDN@Home 1.2.0 alpha 5 rev. 76>>

10

Re: [] we Search vulnerability in the code: the theory, practice and perspectives SAST

Hello, VTT, you wrote: VTT> Well here for example in article there is mention XSS, but a problem not in the resulted piece of the code, and in the arbitrary performance  that on the browser side. VTT> a companion who sawed in due time netscape, hardly reflected on safety issues. The main thing was to have time to make new  faster competitors. VTT> and here in 30 years of development of a World Wide Web herein we have that we have... To Deliver-1 and to leave from dialogue is certainly convenient method, but with me it does not work. You state that "illness" you see that a certain mercantile uncle bent all web possibility of carrying out XSS of attacks of that probably did not think of safety when implemented the . , the message is clear. And effectively to struggle with this "illness" on yours as?... <<RSDN@Home 1.2.0 alpha 5 rev. 76>>

11

Re: [] we Search vulnerability in the code: the theory, practice and perspectives SAST

Hello, Kodt, you wrote: Practically, parm1 = PrependOdds (count) + parm1 + AppendEvens (count) It so. But the task of an output of the similar formula on a cycle rests all against the same restrictions  models. Even the most advanced scientific operations on this subject cover only some set of special cases. And if the cycle also implicit also is implemented through a recursion or (not by the night will be mentioned) goto there it is necessary to solve at first the task of recognition of boundaries of iteration and conditions of loop termination of Capacity of set of prefixes and suffixes are restricted by capacity of set int'. Yes, in  it 0x7FFFFFFF Is unique that it is possible to get to the bottom, - set of initial lines Request. Params ["param1"] . Well so it and without any cycle, from the very beginning, was . Set Request. Params ["param1"] in practice also it is finite, because Web servers restrict the maximum length URL in GET-inquiry (https://boutell.com/newfaq/misc/urllength.html). Here matter is not in it. Because of presence in a condition cycle on value of the inductive variable, re-recording variable value parm1 in both branches, each iteration actually doubles capacity of set of possible values parm1. And, if not to resort to technicians of type LESE storage for storage of elements of this set at us ends much earlier, than we reach to 0x7FFFFFFF iterations.... <<RSDN@Home 1.2.0 alpha 5 rev. 76>>

12

Re: [] we Search vulnerability in the code: the theory, practice and perspectives SAST

Hello, kochetkov.vladimir, you wrote: Well is not present, it you leave from dialogue towards spherical demagogy. Even a background-nejmana recalled... KV> you state that "illness" you see that a certain mercantile uncle bent all web possibility of carrying out XSS of attacks of that probably did not think of safety when implemented the . , the message is clear. And what, tell, what is not present? At first these mercantile uncles wanted to supervise, as their UNIQUE site is displayed on user side. Then they wanted to supervise, as the user interacts with their site. It is a little more  at them there was an emergency to learn, where the user is, to listen to it, to look at it. KV> And effectively to struggle with this "illness" on yours as? It is necessary to be easier. And  in this direction like as is: That clarify that 90 %   practically are not used, want, that web-standards were similar to standards, instead of on the directory of accessories for the apple device, etc. the Tendency to  an additional functional explicitly contradicts a tendency to safety. A hitch that for many the failure from constant   is represented, how a voluntary failure from competitive struggle.

13

Re: [] we Search vulnerability in the code: the theory, practice and perspectives SAST

Hello, kochetkov.vladimir, you wrote: KV> to Deliver-1 and to leave from dialogue is certainly convenient method, but with me it does not work. You state that "illness" you see that a certain mercantile uncle bent all web possibility of carrying out XSS of attacks of that probably did not think of safety when implemented the . , the message is clear. KV> and effectively to struggle with this "illness" on yours as? As electricians do, and energetics are more true even - lead operations by forces of those experts who has a certificate. For an amateur work - fine and disconnect from a network. And with a waterpipe also. And with the water drain - well it is possible most to make somewhere a cesspool, on 101 kilometer from a city. That is, we take, and  to beat on a head for amateur performance.

14

Re: [] we Search vulnerability in the code: the theory, practice and perspectives SAST

Hello, kochetkov.vladimir, you wrote: KV> you state that "illness" you see that a certain mercantile uncle bent all web possibility of carrying out XSS of attacks of that probably did not think of safety when implemented the . , the message is clear. KV> and effectively to struggle with this "illness" on yours as? To cancel capitalism with its competition without rules. At the same time the mass of other problems dares. And if seriously is not technical, but a social problem. She also dares social methods. By the way, them already offered. http://rsdn.org:8888/forum/philosophy/6529104.1 the author: Glory Date: 19.08 23:53