Slijede razlike između dviju inačica stranice.
Starije izmjene na obje strane Starija izmjena Novija izmjena | Starija izmjena | ||
racfor_wiki:dinamicka_analiza_sigurnosti_aplikacija [2021/01/16 17:43] smatesic [Literatura] |
racfor_wiki:dinamicka_analiza_sigurnosti_aplikacija [2023/06/19 18:17] (trenutno) |
||
---|---|---|---|
Redak 3: | Redak 3: | ||
===== Summary ===== | ===== Summary ===== | ||
- | Security testing is crucial to ensuring | + | Security testing is crucial to ensuring |
losses of private data and to some - loss of reputation. Costs of testing are non-negligible, | losses of private data and to some - loss of reputation. Costs of testing are non-negligible, | ||
the cost of data breaches in total is even greater. | the cost of data breaches in total is even greater. | ||
Redak 19: | Redak 19: | ||
Application security is a vital, but often neglected aspect of software development which if done incorrectly can lead to both financial losses and losses of private information. In fact, IBM has published information that the average total cost of one data breach is almost four million dollars [1]. With such costs in mind, the number of data breaches must be minimized. However, in as short a time period as the first six months of 2019. a staggering 4.1 billion records have been exposed due to security breaches [2]. The exposed data contained emails and passwords with percentages of seventy and sixty-five, respectively. According to a report from PTSecurity published in 2019. breaches of sensitive data were a threat in sixty-eight percent of tested web applications [3]. As the ongoing pandemic forces many interactions to take on a digital form, the need for secure web applications and software in general is perhaps higher than ever. To counteract the evident threat that insecure web applications and software in general pose, testing is highly needed. Although testing is expensive, data breach costs already outweigh the cost of testing and also include non-material costs such as loss of reputation [4][5]. There are a few forms of testing one can employ, but one form of testing that very closely simulates a cyber-attack is dynamic application security testing which will henceforth be referred to as " | Application security is a vital, but often neglected aspect of software development which if done incorrectly can lead to both financial losses and losses of private information. In fact, IBM has published information that the average total cost of one data breach is almost four million dollars [1]. With such costs in mind, the number of data breaches must be minimized. However, in as short a time period as the first six months of 2019. a staggering 4.1 billion records have been exposed due to security breaches [2]. The exposed data contained emails and passwords with percentages of seventy and sixty-five, respectively. According to a report from PTSecurity published in 2019. breaches of sensitive data were a threat in sixty-eight percent of tested web applications [3]. As the ongoing pandemic forces many interactions to take on a digital form, the need for secure web applications and software in general is perhaps higher than ever. To counteract the evident threat that insecure web applications and software in general pose, testing is highly needed. Although testing is expensive, data breach costs already outweigh the cost of testing and also include non-material costs such as loss of reputation [4][5]. There are a few forms of testing one can employ, but one form of testing that very closely simulates a cyber-attack is dynamic application security testing which will henceforth be referred to as " | ||
===== Dynamic testing ===== | ===== Dynamic testing ===== | ||
- | Dynamic testing and static testing are the two most basic types of security tests one can perform. Dynamic testing is in its essence differentiated from static testing by the fact that it is performed on live code. This means that testing takes place in an enviroment where the code is running, as opposed to static testing which is performed over a static code base. What this means in practice is that dynamic testing can very closely simulate an attack from the outside. To make dynamic testing as similar to an attack as possible it adopts the "black-box" | + | Dynamic testing and static testing are the two most basic types of security tests one can perform . Dynamic testing is in its essence differentiated from static testing by the fact that it is performed on live code [6]. This means that testing takes place in an enviroment where the code is running, as opposed to static testing which is performed over a static code base. What this means in practice is that dynamic testing can very closely simulate an attack from the outside |
- | The purpose of dynamic testing is to find flaws in the design of the system and, if testing requires it, exploit found vulnerabilities so that the damage potential each threat has can be plainly seen. Dynamic testing relies mainly on testing the HTTP and HTTPS protocol and some advanced testing can be against other more specific protocols, however the basic tests are generally attempts at leveraging HTTP requests to achieve remote code execution, code injection or exploitation of other vulnerabilities such as Cross-site scripting. | + | The purpose of dynamic testing is to find flaws in the design of the system and, if testing requires it, exploit found vulnerabilities so that the damage potential each threat has can be plainly seen. Dynamic testing relies mainly on testing the HTTP and HTTPS protocol and some advanced testing can be against other more specific protocols, however the basic tests are generally attempts at leveraging HTTP requests to achieve remote code execution, code injection or exploitation of other vulnerabilities such as Cross-site scripting |
+ | ===== Dynamic testing strong suites ===== | ||
+ | As mentioned in the previous chapter, dynamic testing is programming language agnostic [9][8]. This is perhaps the greatest advantage over static testing because automated tools used for testing can be written in a "one size fits all" fashion. A static testing tools must be written with programming languages in mind and must account for changes in syntax as most static testing tools also provide styling checks. However, a dynamic testing tool must be written with regards to protocols. Given the fact that protocols do not change as drastically as programming languages do, and more importantly one protocol, HTTP for example, is used across a huge number of applications. This makes a dynamic testing tool usable with many web applications for quick and easy results. | ||
+ | The other big advantage worth mentioning is the fact that dynamic testing tools give far less false positives [9]. A false positive is a situation where the tool has reported a vulnerability when in reality there is none. This might seem like a meaningless drawback to static testing, however when reviewing big projects - be it a huge codebase or many entry points in the web API, the results can overwhelm testers and correctly identified vulnerabilities are harder to extract from the heap of false positives. | ||
- | |||
- | |||
- | |||
- | ===== Dynamic testing strong suites ===== | ||
- | |||
- | As mentioned in the previous chapter, dynamic testing is programming language agnostic. This is perhaps the greatest advantage over static testing because automated tools used for testing can be written in a "one size fits all" fashion. A static testing tools must be written with programming languages in mind and must account for changes in syntax as most static testing tools also provide styling checks. However, a dynamic testing tool must be written with regards to protocols. Given the fact that protocols do not change as drastically as programming languages do, and more importantly one protocol, HTTP for example, is used across a huge number of applications. This makes a dynamic testing tool usable with many web applications for quick and easy results. | ||
- | |||
- | The other big advantage worth mentioning is the fact that dynamic testing tools give far less false positives. A false positive is a situation where the tool has reported a vulnerability when in reality there is none. This might seem like a meaningless drawback to static testing, however when reviewing big projects - be it a huge codebase or many entry points in the web API, the results can overwhelm testers and correctly identified vulnerabilities are harder to extract from the heap of false positives. | ||
===== Dynamic testing drawbacks ===== | ===== Dynamic testing drawbacks ===== | ||
- | One of the two most significant drawbacks as opposed to static testing is that dynamic testing can detect not nearly as many vulnerabilities as static testing can. This is because static testing covers the entirety of the code base and as such can detect vulnerabilities even in code that is perhaps run only in some specific circumstances which dynamic testing would possibly miss. The other significant drawback is the fact that dynamic testing requires a functioning system which means that testing can begin at the end of the development life-cycle. Static testing, on the other hand, can be utilised during the entirety of development thus saving resources. | + | One of the two most significant drawbacks as opposed to static testing is that dynamic testing can detect not nearly as many vulnerabilities as static testing can [9]. This is because static testing covers the entirety of the code base and as such can detect vulnerabilities even in code that is perhaps run only in some specific circumstances which dynamic testing would possibly miss. The other significant drawback is the fact that dynamic testing requires a functioning system which means that testing can begin at the end of the development life-cycle |
As far as the scope of discoverable vulnerabilities, | As far as the scope of discoverable vulnerabilities, | ||
- | Another important disadvantage to using dynamic testing is that it offers no information as to which parts of the code are responsible for the detected vulnerabilities. This means that upon completion a tester must analyze the uncovered security flaws and then deduce which part of the system is responsible. It must be said, however, that some vulnerabilities such as SQL injection have well-known causes which give the tester a very good idea of the problem origin. | + | Another important disadvantage to using dynamic testing is that it offers no information as to which parts of the code are responsible for the detected vulnerabilities. This means that upon completion a tester must analyze the uncovered security flaws and then deduce which part of the system is responsible. It must be said, however, that some vulnerabilities such as SQL injection have well-known causes which give the tester a very good idea of the problem origin |
===== Dynamic testing tools ===== | ===== Dynamic testing tools ===== | ||
- | Tools provide much needed automatization when it comes to security testing. Although tools provide help to testers both in dynamic and static testing scenarios, static testing has a much better use for the automatization they offer because of the potential for enormous code bases which can be daunting to analyze manually. That being said, dynamic testing also has uses for tools. Many tools exist, both open-source and commercial, which can help a tester in finding vulnerabilities. OWASP provides a list of vulnerability scanning tools aimed at web applications which they have deemed the best in the business. | + | Tools provide much needed automatization when it comes to security testing. Although tools provide help to testers both in dynamic and static testing scenarios, static testing has a much better use for the automatization they offer because of the potential for enormous code bases which can be daunting to analyze manually. That being said, dynamic testing also has uses for tools. Many tools exist, both open-source and commercial, which can help a tester in finding vulnerabilities. OWASP provides a list of vulnerability scanning tools aimed at web applications which they have deemed the best in the business |
- | The tool chosen to demonstrate what open-source dynamic security testing tools can do is OWASP ZAP. It is an open-source web scanner developed by OWASP with thourough and user-friendly documentation. In its core it is a MITM proxy. | + | The tool chosen to demonstrate what open-source dynamic security testing tools can do is OWASP ZAP. It is an open-source web scanner developed by OWASP with thourough and user-friendly documentation. In its core it is a MITM proxy [11]. |
{{: | {{: | ||
Redak 59: | Redak 55: | ||
The target URL will be http:// | The target URL will be http:// | ||
- | To start testing, simply click the Attack button. Testing takes quite a long time because of the extensive list of features the application has. | ||
- | |||
{{: | {{: | ||
+ | Scan results are shown in the image above. As the image shows, ZAP can provide information on the most common and dangerous vulnerabilities. | ||
+ | ===== Conclusion ===== | ||
+ | Even though certain drawbacks keep it from being the ultimate security testing method in all cases, dynamic testing still presents a valuable method of testing in most cases, and even the best in some scenarios. To utilize its potential to the fullest, a combination of manual testing and automated tool-based testing is recommended. | ||
+ | Many very good tools exist, some of which are open source, so that even the penetration-testing enthusiasts can test their applications to improve upon their development. Other, commercial tools, serve to improve professional testing quality and reduce costs which can help mitigate a lot of threats to data security which are present because testing bears a greater price than many would accept. | ||
+ | To make sure a system is secure in a broader set of scenarios, a hybrid method should be used - a combination of dynamic and static testing. | ||
+ | This would allow for a tester to assess the full security profile of a system. | ||
+ | |||
- | + | ===== Sources | |
- | + | ||
- | + | ||
- | ===== Zaključak ===== | + | |
- | + | ||
- | Even though certain drawbacks keep it from being the ultimate security testing method in all cases, dynamic testing still presents a valuable method of testing in most cases, and even the best in some scenarios. To utilize its potential to the fullest, a combination of manual testing and automated tool-based testing is recommended. Many very good tools exist, some of which are open source, so that even the penetration-testing enthusiasts can test their applications to improve upon their development. Other, commercial tools, serve to improve professional testing quality and reduce costs which can help mitigate a lot of threats to data security which are present because testing bears a greater price than many would accept. | + | |
- | + | ||
- | ===== Literatura | + | |
[1] IBM, Cost of a Data Breach Study Report highlights, https:// | [1] IBM, Cost of a Data Breach Study Report highlights, https:// | ||
Redak 87: | Redak 81: | ||
[7] Acutenix, 6.3.2019, DAST vs SAST: A Case for Dynamic Application Security Testing, https:// | [7] Acutenix, 6.3.2019, DAST vs SAST: A Case for Dynamic Application Security Testing, https:// | ||
+ | |||
+ | [8] WhitesourceSoftware, | ||
+ | |||
+ | [9] HDivSecurity, | ||
+ | |||
+ | [10] OWASP, Vulnerability Scanning Tools, https:// | ||
+ | |||
+ | [11] OWASP ZAP, Documentation, |