{"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\/de\/blog\/skanirovanie-na-uyazvimosti-i-bezopasnaya-razrabotka-chast-1","title":{"rendered":"Scannen auf Schwachstellen und sichere Entwicklung. Teil 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Scannen
\n
\nIm Rahmen der beruflichen T\u00e4tigkeit m\u00fcssen Entwickler, Pentester und Sicherheitsfachleute mit Prozessen wie Vulnerability Management (VM), (Secure) SDLC umgehen.
\nHinter diesen Begriffen verbergen sich verschiedene Praktiken und verwendete Werkzeuge, die miteinander verbunden sind, obwohl ihre Anwender unterschiedlich sind.<\/p>\n

Der technische Fortschritt hat bisher nicht dazu gef\u00fchrt, dass ein Werkzeug den Menschen bei der Analyse der Sicherheit von Infrastruktur und Software ersetzen kann.
\nEs ist interessant zu verstehen, warum das so ist und mit welchen Problemen man konfrontiert ist.
\n<\/a><\/noindex><\/p>\n

Prozesse<\/h2>\n

\nDer Prozess des Vulnerability Management (\u00abRisikomanagement von Schwachstellen\u00bb) dient der kontinuierlichen \u00dcberwachung der Sicherheit der Infrastruktur und dem Patch-Management.
\nDer Prozess des Secure SDLC (\u00absicherer Entwicklungszyklus\u00bb) dient dazu, die Sicherheit der Anwendung w\u00e4hrend der Entwicklung und des Betriebs zu gew\u00e4hrleisten.<\/p>\n

Ein \u00e4hnlicher Teil dieser Prozesse ist der Prozess der Vulnerability Assessment \u2013 Schwachstellenbewertung und Schwachstellenscan.
\nDer Hauptunterschied beim Scannen im Rahmen von VM und SDLC besteht darin, dass im ersten Fall das Ziel darin besteht, bekannte Schwachstellen in Drittsoftware oder in der Konfiguration zu entdecken. Zum Beispiel eine veraltete Windows-Version oder eine Standard-Community-Zeile f\u00fcr SNMP.
\nIm zweiten Fall hingegen besteht das Ziel darin, Schwachstellen nicht nur in externen Komponenten (Abh\u00e4ngigkeiten), sondern in erster Linie im Code des neuen Produkts zu finden.<\/p>\n

Dies f\u00fchrt zu Unterschieden in den Werkzeugen und Ans\u00e4tzen. Meiner Meinung nach ist die Suche nach neuen Schwachstellen in der Anwendung deutlich interessanter, da sie nicht auf die Fingerabdruckbestimmung von Versionen, das Sammeln von Bannern, das Ausprobieren von Passw\u00f6rtern usw. reduziert werden kann.
\nF\u00fcr qualitativ hochwertige automatisierte Schwachstellenscans von Anwendungen sind Algorithmen erforderlich, die die Semantik der Anwendung, ihren Zweck und spezifische Bedrohungen ber\u00fccksichtigen.<\/p>\n

Ein Infrastruktur-Scanner kann oft durch einen Timer ersetzt werden, wie es avleonov<\/a><\/noindex>ausgedr\u00fcckt hat. Es geht darum, dass Sie statistisch gesehen Ihre Infrastruktur als verwundbar betrachten k\u00f6nnen, wenn Sie sie, sagen wir, einen Monat lang nicht aktualisiert haben.<\/p>\n

Werkzeuge<\/h2>\n

\nDas Scannen, ebenso wie die Sicherheitsanalyse, kann sowohl als Black Box als auch als White Box durchgef\u00fchrt werden.<\/p>\n

Black Box<\/h4>\n

\nBeim Blackbox-Scanning muss das Werkzeug in der Lage sein, mit dem Dienst \u00fcber dieselben Schnittstellen zu arbeiten, \u00fcber die auch die Benutzer arbeiten.<\/p>\n

Infrastruktur-Scanner (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose usw.) suchen nach offenen Netzwerkports, sammeln \"Banner\", bestimmen die Versionen der installierten Software und suchen in ihrer Wissensdatenbank nach Informationen \u00fcber Schwachstellen in diesen Versionen. Sie versuchen auch, Konfigurationsfehler zu erkennen, wie z. B. Standardpassw\u00f6rter oder offenen Zugriff auf Daten, schwache SSL-Verschl\u00fcsselungen usw.<\/p>\n

Webanwendungs-Scanner (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP usw.) k\u00f6nnen ebenfalls bekannte Komponenten und deren Versionen bestimmen (zum Beispiel CMS, Frameworks, JS-Bibliotheken). Die Hauptschritte des Scanners sind Crawling und Fuzzing.
\nW\u00e4hrend des Crawlings sammelt der Scanner Informationen \u00fcber existierende Schnittstellen der Anwendung und HTTP-Parameter. W\u00e4hrend des Fuzzings werden mutierte oder generierte Daten in alle entdeckten Parameter eingef\u00fcgt, um einen Fehler auszul\u00f6sen und eine Schwachstelle zu entdecken.<\/p>\n

Solche Anwendungsscanner geh\u00f6ren zu den Klassen DAST und IAST \u2013 entsprechend Dynamic und Interactive Application Security Testing.<\/p>\n

Wei\u00dfer Kasten<\/h4>\n

\nBeim Whitebox-Scannen gibt es mehr Unterschiede.
\nIm Rahmen des VM-Prozesses erhalten Scanner (Vulners, Incsecurity Couch, Vuls, Tenable Nessus usw.) oft Zugang zu den Systemen, indem sie einen authentifizierten Scan durchf\u00fchren. So kann der Scanner die installierten Paketversionen und Konfigurationsparameter direkt aus dem System herunterladen, ohne sie anhand von Bannern der Netzwerkdienste erraten zu m\u00fcssen.
\nDer Scan wird genauer und vollst\u00e4ndiger.<\/p>\n

Wenn es um Whitebox-Scanning (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs usw.) von Anwendungen geht, handelt es sich normalerweise um die statische Analyse von Code und die Verwendung entsprechender Werkzeuge der Klasse SAST \u2013 Static Application Security Testing.<\/p>\n

Probleme<\/h2>\n

\nEs gibt viele Probleme mit dem Scannen! Mit den meisten davon muss ich pers\u00f6nlich umgehen, wenn ich Dienstleistungen zur Etablierung von Scanning-Prozessen und sicherer Entwicklung anbiete, sowie bei der Durchf\u00fchrung von Sicherheitsanalysen.<\/p>\n

Ich m\u00f6chte 3 Hauptgruppen von Problemen hervorheben, die sowohl durch Gespr\u00e4che mit Ingenieuren als auch mit Leitern von IT-Sicherheitsdiensten in verschiedenen Unternehmen best\u00e4rkt werden.<\/p>\n

Probleme beim Scannen von Webanwendungen<\/h4>\n

<\/p>\n

    \n
  1. Schwierigkeiten bei der Implementierung.<\/b> Scanner m\u00fcssen implementiert, konfiguriert und f\u00fcr jede Anwendung angepasst werden, Testumgebungen f\u00fcr Scans bereitgestellt und in den CI\/CD-Prozess integriert werden, um effektiv zu sein. Andernfalls wird es ein nutzloses, formales Verfahren, das h\u00f6chstens falsche Alarme erzeugt.<\/li>\n
  2. Dauer des Scans.<\/b> Selbst 2019 hatten Scanner Probleme mit der Deduplication von Schnittstellen und k\u00f6nnen Tag und Nacht tausend Seiten mit zehn Parametern auf jeder scannen, wobei sie diese als unterschiedlich betrachten, obwohl derselbe Code f\u00fcr sie verantwortlich ist. Dabei muss die Entscheidung \u00fcber das Deployment in der Produktionsumgebung im Rahmen des Entwicklungszyklus schnell getroffen werden.<\/li>\n
  3. Mangelnde Empfehlungen.<\/b> Scanner geben ziemlich allgemeine Empfehlungen ab und der Entwickler kann nicht immer schnell erkennen, wie er das Risiko senken kann, und vor allem, ob es notwendig ist, dies sofort zu tun oder ob es noch nicht dringlich ist.<\/li>\n
  4. Destruktive Auswirkungen auf die Anwendung.<\/b> Scanner k\u00f6nnen durchaus einen DoS-Angriff auf die Anwendung durchf\u00fchren und k\u00f6nnen eine gro\u00dfe Anzahl von Entit\u00e4ten erzeugen oder bestehende \u00e4ndern (zum Beispiel Zehntausende von Kommentaren in einem Blog erstellen), weshalb man sie nicht gedankenlos in der Produktion ausf\u00fchren sollte.<\/li>\n
  5. Niedrige Qualit\u00e4t der Schwachstellenerkennung.<\/b> Scanner verwenden in der Regel ein festes Array an Payloads und k\u00f6nnen leicht eine Schwachstelle \u00fcbersehen, die nicht in ihr bekanntes Verhaltensmuster passt.<\/li>\n
  6. Missverst\u00e4ndnis der Funktionen der Anwendung durch den Scanner.<\/b> Scanner wissen von sich aus nicht, was \"Internet-Banking\", \"Zahlung\", \"Kommentar\" ist. F\u00fcr sie existieren nur Links und Parameter, sodass ein gro\u00dfer Teil m\u00f6glicher Schwachstellen in der Gesch\u00e4ftslogik v\u00f6llig unentdeckt bleibt. Sie w\u00fcrden nicht auf die Idee kommen, eine doppelte Abbuchung vorzunehmen, auf fremde Daten per ID zuzugreifen oder das Guthaben durch Rundungsfehler zu manipulieren.<\/li>\n
  7. Missverst\u00e4ndnis der Semantik der Seiten durch den Scanner.<\/b> Scanner k\u00f6nnen keine FAQs lesen, k\u00f6nnen Captchas nicht erkennen, und sie w\u00fcrden nicht auf die Idee kommen, wie man sich registriert und dass man sich dann neu einloggen muss, nicht auf \"Logout\" klicken sollte und wie man Anfragen bei Ver\u00e4nderung von Parameterwerten signiert. Infolgedessen kann ein gro\u00dfer Teil der Anwendung v\u00f6llig ungescannt bleiben.<\/li>\n<\/ol>\n

    Probleme beim Scannen des Quellcodes.<\/h4>\n

    <\/p>\n

      \n
    1. Falsche Alarme.<\/b> Statische Analyse ist eine komplexe Aufgabe, bei der oft viele Kompromisse eingegangen werden m\u00fcssen. H\u00e4ufig muss auf Genauigkeit verzichtet werden, und selbst teure Unternehmensscanner liefern eine riesige Anzahl von Fehlalarmierungen.<\/li>\n
    2. Schwierigkeiten bei der Implementierung.<\/b> Um die Genauigkeit und Vollst\u00e4ndigkeit der statischen Analyse zu erh\u00f6hen, m\u00fcssen die Scan-Regeln \u00fcberarbeitet werden, und das Schreiben dieser Regeln kann sich als zu zeitaufwendig erweisen. Manchmal ist es einfacher, alle Stellen im Code mit einem bestimmten Fehler zu finden und sie zu beheben, als eine Regel zu schreiben, um solche F\u00e4lle zu erkennen.<\/li>\n
    3. Fehlende Unterst\u00fctzung f\u00fcr Abh\u00e4ngigkeiten.<\/b> Gro\u00dfe Projekte sind von einer Vielzahl von Bibliotheken und Frameworks abh\u00e4ngig, die die M\u00f6glichkeiten der Programmiersprache erweitern. Wenn im Wissensbestand des Scanners keine Informationen \u00fcber gef\u00e4hrliche Stellen (\u201eSinks\u201c) in diesen Frameworks enthalten sind, wird dies zu einem blinden Fleck und der Scanner versteht den Code einfach nicht.<\/li>\n
    4. Dauer des Scans.<\/b> Die Suche nach Vulnerabilit\u00e4ten im Code ist eine komplexe Aufgabe, auch in Bezug auf Algorithmen. Daher kann der Prozess durchaus zeitaufwendig sein und erhebliche Rechenressourcen erfordern.<\/li>\n
    5. Geringe Abdeckung.<\/b> Trotz des Ressourcenverbrauchs und der Dauer des Scans m\u00fcssen Entwickler von SAST-Tools dennoch Kompromisse eingehen und nicht alle Zust\u00e4nde analysieren, in denen sich das Programm befinden kann.<\/li>\n
    6. Reproduzierbarkeit der Auffindungen.<\/b> Ein Hinweis auf eine bestimmte Zeile und den Stack-Trace, der zu einer Vulnerabilit\u00e4t f\u00fchrt, ist gro\u00dfartig, aber in der Realit\u00e4t gibt der Scanner oft nicht gen\u00fcgend Informationen, um die Existenz der Vulnerabilit\u00e4t von au\u00dfen zu \u00fcberpr\u00fcfen. Schlie\u00dflich kann das Problem auch in totem Code liegen, der f\u00fcr einen Angreifer unerreichbar ist.<\/li>\n<\/ol>\n

      Probleme beim Scannen der Infrastruktur.<\/h4>\n

      <\/p>\n

        \n
      1. Unzureichende Inventarisierung.<\/b> In gro\u00dfen Infrastrukturen, insbesondere geographisch verteilten, ist es oft am schwierigsten zu verstehen, welche Hosts gescannt werden m\u00fcssen. Mit anderen Worten, die Scan-Aufgabe steht in enger Verbindung mit dem Asset Management.<\/li>\n
      2. Schlechte Priorisierung.<\/b> Netzwerkscanner liefern h\u00e4ufig viele Ergebnisse mit Schw\u00e4chen, die in der Praxis nicht ausnutzbar sind, aber formal als hochriskant gelten. Der Verbraucher erh\u00e4lt einen Bericht, der schwer zu interpretieren ist, und es ist unklar, was vorrangig behoben werden muss.<\/li>\n
      3. Mangelnde Empfehlungen.<\/b> In der Wissensdatenbank des Scanners gibt es oft nur sehr allgemeine Informationen zu Schwachstellen und deren Behebung, sodass Administratoren sich mit Google bewaffnen m\u00fcssen. Die Situation ist etwas besser bei Whitebox-Scannern, die konkrete Befehle zur Behebung ausgeben k\u00f6nnen.<\/li>\n
      4. Manuelle Arbeit.<\/b> In Infrastrukturen kann es viele Knoten geben, also potenziell viele Schwachstellen, deren Berichte bei jeder Iteration manuell ausgewertet und analysiert werden m\u00fcssen.<\/li>\n
      5. Schlechte Abdeckung.<\/b> Die Qualit\u00e4t der Scannung der Infrastruktur h\u00e4ngt direkt vom Umfang der Wissensdatenbank zu Schwachstellen und Softwareversionen ab. Dabei, stellt sich heraus<\/a><\/noindex>, dass selbst Marktf\u00fchrer nicht \u00fcber eine umfassende Wissensdatenbank verf\u00fcgen, und dass in Datenbanken kostenloser L\u00f6sungen viele Informationen vorhanden sind, die bei den Marktf\u00fchrern fehlen.<\/li>\n
      6. Probleme mit Patch-Management.<\/b> H\u00e4ufig besteht das Patch-Management von Schwachstellen in der Infrastruktur aus der Aktualisierung eines Pakets oder der \u00c4nderung einer Konfigurationsdatei. Ein gro\u00dfes Problem hier ist, dass das System, insbesondere Legacy-Systeme, sich infolge eines Updates unvorhersehbar verhalten kann. Im Grunde m\u00fcssen Integrationspr\u00fcfungen in der Live-Infrastruktur im Produktivbetrieb durchgef\u00fchrt werden.<\/li>\n<\/ol>\n

        Ans\u00e4tze<\/h2>\n

        \nWas soll man also tun?
        \nMehr \u00fcber Beispiele und wie man vielen der genannten Probleme begegnen kann, werde ich in den n\u00e4chsten Teilen erz\u00e4hlen, w\u00e4hrend ich jetzt die Hauptbereiche auff\u00fchre, in denen man t\u00e4tig werden kann:<\/p>\n

          \n
        1. Aggregation verschiedener Scanning-Tools.<\/b> Bei richtiger Nutzung mehrerer Scanner kann eine erhebliche Erh\u00f6hung der Wissensdatenbank und der Qualit\u00e4t der Erkennung erzielt werden. Man kann sogar mehr Schwachstellen finden, als alle Scanner zusammen, die einzeln betrieben werden, w\u00e4hrend man das Risiko genauer bewerten und mehr Empfehlungen geben kann.<\/li>\n
        2. Integration von SAST und DAST.<\/b> Man kann die Abdeckung von DAST und die Genauigkeit von SAST durch den Austausch von Informationen zwischen ihnen erh\u00f6hen. Aus den Quellcodes k\u00f6nnen Informationen \u00fcber vorhandene Routen gewonnen werden, und mit DAST kann \u00fcberpr\u00fcft werden, ob die Schwachstelle von au\u00dfen sichtbar ist.<\/li>\n
        3. Machine Learning\u2122.<\/b> Im Jahr 2015 habe ich erz\u00e4hlt<\/a><\/noindex> (und noch<\/a><\/noindex>) \u00fcber die Anwendung von Statistiken, um Scannern die Intuition eines Hackers zu geben und sie zu beschleunigen. Das ist definitiv ein N\u00e4hrboden f\u00fcr die Weiterentwicklung der automatischen Sicherheitsanalyse in der Zukunft.<\/li>\n
        4. Integration von IAST mit automatisierten Tests und OpenAPI.<\/b> Im Rahmen einer CI\/CD-Pipeline ist es m\u00f6glich, einen Scan-Prozess auf der Grundlage von Tools zu erstellen, die als HTTP-Proxy fungieren, und von funktionalen Tests, die \u00fcber HTTP ausgef\u00fchrt werden. Tests und Vertr\u00e4ge von OpenAPI\/Swagger geben dem Scanner die fehlenden Informationen \u00fcber Datenstr\u00f6me und erm\u00f6glichen es ihm, die Anwendung in verschiedenen Zust\u00e4nden zu scannen.<\/li>\n
        5. Richtige Konfiguration.<\/b> F\u00fcr jede Anwendung und Infrastruktur muss ein geeigneter Scan-Profil erstellt werden, das die Anzahl und Art der Schnittstellen sowie die verwendeten Technologien ber\u00fccksichtigt.<\/li>\n
        6. Anpassung der Scanner.<\/b> Oft kann eine Anwendung nicht gescannt werden, ohne den Scanner anzupassen. Ein Beispiel ist ein Zahlungsgateway, bei dem jede Anfrage signiert werden muss. Ohne das Schreiben eines Connectors zum Protokoll des Gateways werden Scanner gedankenlos Anfragen mit falscher Signatur senden. Es ist auch notwendig, spezialisierte Scanner f\u00fcr bestimmte Arten von Schwachstellen zu schreiben, wie zum Beispiel Insecure Direct Object Reference<\/a><\/noindex><\/li>\n
        7. Risikomanagement.<\/b> Die Nutzung verschiedener Scanner und die Integration mit externen Systemen wie Asset Management und Threat Management erm\u00f6glicht es, viele Parameter zur Bewertung des Risikoniveaus zu nutzen, sodass das Management ein angemessenes Bild \u00fcber den aktuellen Stand der Sicherheit von Entwicklung oder Infrastruktur erh\u00e4lt.<\/li>\n<\/ol>\n

          Bleiben Sie dran und lassen Sie uns das Schwachstellenscannen revolutionieren!
          \n
          Quelle:           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\udd47 Schwachstellenscanning und sichere Entwicklung. Teil 1 | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/de\/blog\/skanirovanie-na-uyazvimosti-i-bezopasnaya-razrabotka-chast-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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\/de\/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\/de\/wp-json\/wp\/v2\/posts\/29957","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=29957"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/29957\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=29957"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=29957"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=29957"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}