{"id":29957,"date":"2019-10-31T21:32:53","date_gmt":"2019-10-31T18:32:53","guid":{"rendered":"https:\/\/prohoster.info\/blog\/skanirovanie-na-uyazvimosti-i-bezopasnaya-razrabotka-chast-1\/"},"modified":"2019-10-31T21:32:53","modified_gmt":"2019-10-31T18:32:53","slug":"skanirovanie-na-uyazvimosti-i-bezopasnaya-razrabotka-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/skanirovanie-na-uyazvimosti-i-bezopasnaya-razrabotka-chast-1","title":{"rendered":"Vulnerability Scanning and Secure Development. Part 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Vulnerability
\n
\nIn their professional activities, developers, pentesters, and security specialists encounter processes such as Vulnerability Management (VM) and (Secure) SDLC.
\nThese terms encompass various sets of practices and tools that are interwoven, although their users differ.<\/p>\n

Technological progress has not yet advanced to the point where a single tool can replace a human for analyzing the security of infrastructure and software.
\nIt is interesting to understand why this is the case and what problems arise.
\n<\/a><\/noindex><\/p>\n

Processes<\/h2>\n

\nThe Vulnerability Management process is designed for continuous monitoring of the security of infrastructure and patch management.
\nThe Secure SDLC process aims to maintain application security throughout its development and operation.<\/p>\n

A similar part of these processes is the Vulnerability Assessment process, which involves vulnerability scanning.
\nThe primary difference in scanning within VM and SDLC is that in the former, the goal is to detect known vulnerabilities in third-party software or configurations, such as an outdated version of Windows or a default community string for SNMP.
\nIn the latter case, the aim is to identify vulnerabilities not just in third-party components (dependencies), but first and foremost in the code of the new product.<\/p>\n

This leads to differences in tools and approaches. In my view, the task of discovering new vulnerabilities in an application is significantly more interesting, as it is not limited to version fingerprinting, banner gathering, password brute-forcing, etc.
\nFor effective automated application vulnerability scanning, algorithms are needed that take into account the semantics of the application, its purpose, and specific threats.<\/p>\n

An infrastructure scanner can often be replaced by a timer, as expressed by avleonov.<\/a><\/noindex>The essence is that statistically, you can consider your infrastructure vulnerable if you haven\u2019t updated it, say, in a month.<\/p>\n

Tools<\/h2>\n

\nScanning, like security analysis, can be performed as both a black box and a white box.<\/p>\n

Black Box<\/h4>\n

\nIn black box scanning, the tool must be able to interact with the service through the same interfaces that users employ.<\/p>\n

Infrastructure scanners (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, etc.) search for open network ports, collect \"banners\", determine the versions of installed software, and check their knowledge base for vulnerabilities in these versions. They also attempt to detect configuration errors, such as default passwords or open access to data, weak SSL ciphers, etc.<\/p>\n

Web application scanners (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, etc.) can also identify known components and their versions (e.g., CMS, frameworks, JS libraries). The main steps of a scanner are crawling and fuzzing.
\nDuring crawling, the scanner collects information about existing application interfaces and HTTP parameters. In fuzzing, mutated or generated data is injected into all detected parameters to provoke an error and uncover vulnerabilities.<\/p>\n

Such application scanners belong to the classes of DAST and IAST \u2014 namely Dynamic and Interactive Application Security Testing.<\/p>\n

White Box<\/h4>\n

\nIn white box scanning, the differences are greater.
\nWithin the VM process, scanners (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, etc.) are often given access to systems, conducting an authenticated scan. This way, the scanner can unload the installed package versions and configuration parameters directly from the system, rather than guessing them from the banners of network services.
\nThe scan becomes more accurate and complete.<\/p>\n

In the case of white box scanning (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, etc.), it usually involves static code analysis and the use of corresponding SAST tools \u2014 Static Application Security Testing.<\/p>\n

Issues<\/h2>\n

\nMany issues arise during scanning! I personally encounter most of them while providing services for building scanning processes and secure development, as well as during security analysis work.<\/p>\n

I will highlight three main groups of problems, which are confirmed by discussions with engineers and heads of information security departments in various companies.<\/p>\n

Problems with web application scanning<\/h4>\n

<\/p>\n

    \n
  1. The difficulty of implementation.<\/b> Scanners need to be deployed, configured, and customized for each application, allocate a testing environment for scans, and integrate into the CI\/CD process for them to be effective. Otherwise, it will just be a useless formal procedure yielding only false positives.<\/li>\n
  2. Duration of the scan.<\/b> Scanners still struggle with deduplication of interfaces and can spend days scanning a thousand pages with 10 parameters each, treating them as different, even though they are governed by the same code. At the same time, decisions about deploying to production during the development cycle must be made quickly.<\/li>\n
  3. Meager recommendations.<\/b> Scanners provide rather vague recommendations, and developers may not always quickly grasp how to reduce risk based on them, and more importantly, whether it needs to be done right now or if it can wait.<\/li>\n
  4. Destructive impact on the application.<\/b> Scanners can indeed launch a DoS attack on the application and can create a large number of entities or alter existing ones (for example, creating tens of thousands of comments on a blog), so it's unwise to run a scan in production mindlessly.<\/li>\n
  5. Low quality of vulnerability detection.<\/b> Scanners typically use a fixed set of payloads and may easily overlook a vulnerability that does not fit their known application behavior patterns.<\/li>\n
  6. Misunderstanding of the application's functions by the scanner.<\/b> Scanners do not inherently understand what 'internet banking', 'payment', or 'comment' is. They only recognize links and parameters, leaving a vast array of potential business logic vulnerabilities completely uncovered; they won't deduce double charging, peek into someone else's data by ID, or manipulate balances through rounding.<\/li>\n
  7. Misunderstanding of the page semantics by the scanner.<\/b> Scanners cannot read FAQs, do not recognize CAPTCHAs, and will not intuitively understand how to register, that they need to log in again, that the 'logout' button should not be pressed, and how to sign requests when changing parameter values. As a result, a significant portion of the application may remain completely unscanned.<\/li>\n<\/ol>\n

    Problems with scanning source code.<\/h4>\n

    <\/p>\n

      \n
    1. False positives.<\/b> Static analysis is a complex task that often requires numerous compromises. Accuracy is often sacrificed, and even expensive enterprise scanners produce a large number of false positives.<\/li>\n
    2. The difficulty of implementation.<\/b> To improve the accuracy and completeness of static analysis, it is necessary to refine scanning rules, and writing these rules can be quite labor-intensive. Sometimes it is easier to locate all instances of a bug in the code and fix them than to write a rule to detect such cases.<\/li>\n
    3. Lack of support for dependencies.<\/b> Large projects depend on many libraries and frameworks that extend the capabilities of the programming language. If the scanner's knowledge base does not include information about dangerous areas (\"sinks\") in these frameworks, this will create a blind spot, and the scanner won't even comprehend the code.<\/li>\n
    4. Duration of the scan.<\/b> Finding vulnerabilities in code is a complex task in algorithmic terms. Therefore, the process can easily be prolonged and require significant computational resources.<\/li>\n
    5. Low coverage.<\/b> Despite the resource consumption and lengthy scanning process, developers of SAST tools still have to make compromises and do not analyze all the states that the program may be in.<\/li>\n
    6. Reproducibility of findings.<\/b> Pointing to a specific line and call stack that lead to a vulnerability is excellent, but often the scanner does not provide enough information to verify the existence of the vulnerability from the outside. After all, a flaw can exist in dead code that is unreachable to an attacker.<\/li>\n<\/ol>\n

      Infrastructure scanning issues.<\/h4>\n

      <\/p>\n

        \n
      1. Insufficient inventory.<\/b> In large infrastructures, especially those that are geographically dispersed, it is often most challenging to understand which hosts need to be scanned. In other words, the scanning task is closely tied to asset management.<\/li>\n
      2. Poor prioritization.<\/b> Network scanners often produce many results that have vulnerabilities that are practically not exploitable, yet their risk level is formally considered high. The consumer receives a report that is difficult to interpret, and it is unclear what should be fixed first.<\/li>\n
      3. Meager recommendations.<\/b> The knowledge base of scanners often contains only very general information about vulnerabilities and ways to fix them, so admins will have to equip themselves with Google. The situation is slightly better with whitebox scanners, which may provide a specific command for fixing.<\/li>\n
      4. Manual work.<\/b> There can be many nodes in infrastructures, which means many potential flaws, the reports on which have to be examined and analyzed manually at every iteration.<\/li>\n
      5. Poor coverage.<\/b> The quality of infrastructure scanning directly depends on the volume of the knowledge base about vulnerabilities and software versions. However, It turns out<\/a><\/noindex>, even for market leaders, the knowledge base is not comprehensive, and there is a lot of information in free solutions' databases that the leaders lack.<\/li>\n
      6. Patch management issues.<\/b> Most often, patching vulnerabilities in the infrastructure involves updating a package or changing a configuration file. A major issue here is that the system, especially legacy, may behave unpredictably as a result of the update. Essentially, integration tests will have to be performed on the live infrastructure in production.<\/li>\n<\/ol>\n

        Approaches<\/h2>\n

        \nWhat to do?
        \nIn the next segments, I will discuss examples and how to tackle many of the listed problems, but for now, I will indicate the main areas where improvements can be made:<\/p>\n

          \n
        1. Aggregation of various scanning tools.<\/b> With the correct use of multiple scanners, significant increases in the knowledge base and detection quality can be achieved. It is possible to find even more vulnerabilities than the sum total of all scanners run separately, allowing for a more accurate risk assessment and better recommendations.<\/li>\n
        2. Integration of SAST and DAST.<\/b> Coverage of DAST can be increased, and the accuracy of SAST improved through information exchange between them. Source code can provide information about existing routes, and DAST can check whether the vulnerability is visible externally.<\/li>\n
        3. Machine Learning\u2122.<\/b> In 2015, I discussed<\/a><\/noindex> Volume Provisioning. still<\/a><\/noindex>) discussed the application of statistics to give scanners a hacker\u2019s intuition and speed them up. This is undoubtedly food for thought for the future of automated security analysis.<\/li>\n
        4. Integration of IAST with automated tests and OpenAPI.<\/b> In the CI\/CD pipeline, it is possible to create a scanning process based on tools that operate as HTTP proxies, along with functional tests that work via HTTP. OpenAPI\/Swagger tests and contracts will provide the scanner with missing information about data flows, allowing it to scan the application in various states.<\/li>\n
        5. Proper configuration.<\/b> A suitable scanning profile needs to be created for each application and infrastructure, taking into account the number and nature of interfaces and the technologies used.<\/li>\n
        6. Customization of scanners.<\/b> Often, an application cannot be scanned without modifying the scanner. For example, a payment gateway where each request must be signed. Without writing a connector to the gateway protocol, scanners will mindlessly send requests with incorrect signatures. Specialized scanners for specific types of vulnerabilities, such as Insecure Direct Object Reference<\/a><\/noindex><\/li>\n
        7. Risk management.<\/b> Using various scanners and integrating with external systems such as Asset Management and Threat Management will allow a multitude of parameters to be used for assessing risk levels, enabling management to obtain an accurate picture of the current state of security in development or infrastructure.<\/li>\n<\/ol>\n

          Stay tuned, and let's revolutionize vulnerability scanning!
          \n
          Source:           habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

          \u0412 \u0440\u0430\u043c\u043a\u0430\u0445 \u043f\u0440\u043e\u0444\u0435\u0441\u0441\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u043e\u0439 \u0434\u0435\u044f\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u0430\u043c, \u043f\u0435\u043d\u0442\u0435\u0441\u0442\u0435\u0440\u0430\u043c, \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u0438\u043a\u0430\u043c \u043f\u0440\u0438\u0445\u043e\u0434\u0438\u0442\u0441\u044f \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0441 \u0442\u0430\u043a\u0438\u043c\u0438 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430\u043c\u0438, \u043a\u0430\u043a Vulnerability Management (VM), (Secure) SDLC. \u041f\u043e\u0434 \u044d\u0442\u0438\u043c\u0438 \u0441\u043b\u043e\u0432\u043e\u0441\u043e\u0447\u0435\u0442\u0430\u043d\u0438\u044f\u043c\u0438 \u0441\u043a\u0440\u044b\u0432\u0430\u044e\u0442\u0441\u044f \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0435 \u043d\u0430\u0431\u043e\u0440\u044b \u043f\u0440\u0430\u043a\u0442\u0438\u043a \u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c\u044b\u0445 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043f\u0435\u0440\u0435\u043f\u043b\u0435\u0442\u0435\u043d\u044b \u043c\u0435\u0436\u0434\u0443 \u0441\u043e\u0431\u043e\u0439, \u0445\u043e\u0442\u044f \u0438\u0445 \u043f\u043e\u0442\u0440\u0435\u0431\u0438\u0442\u0435\u043b\u0438 \u0440\u0430\u0437\u043b\u0438\u0447\u0430\u044e\u0442\u0441\u044f. \u0422\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u043f\u0440\u043e\u0433\u0440\u0435\u0441\u0441 \u043f\u043e\u043a\u0430 \u043d\u0435 \u0434\u043e\u0448\u0451\u043b \u0434\u043e \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u043e\u0434\u043d\u0438\u043c \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u043e\u043c \u0437\u0430\u043c\u0435\u043d\u0438\u0442\u044c \u0447\u0435\u043b\u043e\u0432\u0435\u043a\u0430 \u0434\u043b\u044f \u043f\u0440\u043e\u0432\u0435\u0434\u0435\u043d\u0438\u044f \u0430\u043d\u0430\u043b\u0438\u0437\u0430 \u0437\u0430\u0449\u0438\u0449\u0451\u043d\u043d\u043e\u0441\u0442\u0438 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u044b \u0438 \u041f\u041e. […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-29957","post","type-post","status-publish","format-standard","hentry"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Vulnerability Scanning and Secure Development. Part 1 | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/en\/blog\/skanirovanie-na-uyazvimosti-i-bezopasnaya-razrabotka-chast-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0421\u043a\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u043d\u0430 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438 \u0438 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430. \u0427\u0430\u0441\u0442\u044c 1 | ProHoster","og:url":"https:\/\/prohoster.info\/en\/blog\/skanirovanie-na-uyazvimosti-i-bezopasnaya-razrabotka-chast-1","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:32:53+00:00","article:modified_time":"2019-10-31T18:32:53+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"29957","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"Article","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-20 23:11:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:45:24","updated":"2026-01-20 23:11:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/29957","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=29957"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/29957\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=29957"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=29957"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=29957"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}