{"id":84184,"date":"2020-06-05T19:42:31","date_gmt":"2020-06-05T17:42:31","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/smertnye-grehi-bezopasnosti-sajta-chto-my-uznali-iz-statistiki-skanera-uyazvimostej-za-god"},"modified":"2020-06-05T19:42:31","modified_gmt":"2020-06-05T17:42:31","slug":"smertnye-grehi-bezopasnosti-sajta-chto-my-uznali-iz-statistiki-skanera-uyazvimostej-za-god","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/smertnye-grehi-bezopasnosti-sajta-chto-my-uznali-iz-statistiki-skanera-uyazvimostej-za-god","title":{"rendered":"Die Tods\u00fcnden der Website-Sicherheit: Was wir aus der Statistik des Schwachstellenscanners im vergangenen Jahr gelernt haben","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Vor etwa einem Jahr haben wir bei DataLine Dienst<\/a><\/noindex> einen Dienst zur Suche und Analyse von Schwachstellen in IT-Anwendungen gestartet. Basis des Dienstes ist die Cloud-L\u00f6sung Qualys, \u00fcber die wir bereits berichtet haben<\/a><\/noindex>. Im Laufe eines Jahres haben wir 291 Scans f\u00fcr verschiedene Websites durchgef\u00fchrt und Statistiken zu verbreiteten Schwachstellen in Webanwendungen gesammelt.\u00a0<\/p>\n

Im folgenden Artikel werde ich zeigen, welche Sicherheitsl\u00fccken auf Websites hinter verschiedenen Kritikalit\u00e4tsstufen verborgen sind. Lassen Sie uns ansehen, welche Schwachstellen der Scanner besonders h\u00e4ufig gefunden hat, warum sie auftreten k\u00f6nnen und wie man sich sch\u00fctzen kann.\u00a0<\/p>\n

\"Die
\n<\/a><\/noindex>
\nQualys klassifiziert alle Schwachstellen von Webanwendungen in drei Kritikalit\u00e4tsstufen: niedrig, mittel und hoch. Betrachtet man die Verteilung nach \u201eSchweregrad\u201c, scheint es nicht so schlimm zu sein. Hochkritische Schwachstellen sind rar, die meisten sind nicht kritisch:\u00a0<\/p>\n

\"Die
\n
\nAber nicht kritische Schwachstellen sind nicht gleich harmlos. Auch sie k\u00f6nnen erheblichen Schaden anrichten.\u00a0<\/p>\n

Top \u201enicht kritische\u201c Schwachstellen<\/h2>\n

<\/p>\n

    \n
  1. Schwachstellen im Zusammenhang mit gemischtem Inhalt.<\/b>\n

    Der Sicherheitsstandard f\u00fcr Websites ist die \u00dcbertragung von Daten zwischen Client und Server \u00fcber das HTTPS-Protokoll, das Verschl\u00fcsselung unterst\u00fctzt und Informationen vor Abh\u00f6rung sch\u00fctzt.\u00a0<\/p>\n

    Einige Websites verwenden gemischten Inhalt<\/i>: sie \u00fcbertragen Teile der Daten \u00fcber das ungesicherte HTTP-Protokoll. H\u00e4ufig \u00fcbertragen sie passiven Inhalt<\/i> \u2013 Informationen, die nur das Erscheinungsbild der Seite beeinflussen: Bilder, CSS-Stile. Aber manchmal wird auch aktiver Inhalt<\/i>\u00fcbertragen: Skripte, die das Verhalten der Website steuern. In diesem Fall kann spezielle Software die vom Server empfangenen Informationen mit aktivem Inhalt analysieren, die Antworten in Echtzeit modifizieren und die Maschine dazu bringen, anders zu arbeiten, als von ihren Sch\u00f6pfern vorgesehen.\u00a0<\/p>\n

    Webbrowser neuerer Versionen warnen die Benutzer, dass Websites mit gemischtem Inhalt unsicher sind, und blockieren Inhalte. Webentwickler erhalten ebenfalls Warnungen vom Browser in der Konsole. So sieht das beispielsweise aus in Firefox<\/a><\/noindex>:\u00a0<\/p>\n

    \"Die
    \n
    \nWie gef\u00e4hrlich ist<\/b>: Angreifer verwenden das ungesicherte Protokoll, um Benutzerinformationen abzufangen, Skripte zu manipulieren und Anfragen im Namen der Website zu senden. Selbst wenn ein Besucher der Website keine Daten eingegeben hat, sch\u00fctzt das nicht vor Phishing <\/i>\u2013 \u00dcber das Herausfiltern vertraulicher Informationen durch betr\u00fcgerische Methoden. Beispielsweise kann mit einem Skript der Benutzer auf eine unsichere Website umgeleitet werden, die sich als bekannt ausgibt. In einigen F\u00e4llen sieht die b\u00f6swillige Website sogar besser aus als das Original, und der Benutzer kann das Formular selbst ausf\u00fcllen und vertrauliche Daten \u00fcbermitteln.\u00a0<\/p>\n

    Was Webentwickler beachten sollten<\/b>: Selbst wenn der Website-Administrator ein SSL\/TLS-Zertifikat installiert und konfiguriert hat, kann eine Schwachstelle durch den menschlichen Faktor entstehen. Zum Beispiel, wenn auf einer der Seiten kein relativer, sondern ein absoluter Link mit http gesetzt wurde und zudem keine Weiterleitungen von http nach https eingerichtet wurden.\u00a0<\/p>\n

    Gemischte Inhalte auf einer Website k\u00f6nnen mithilfe des Browsers festgestellt werden: durch Durchsuchen des Quellcodes der Seite oder Lesen von Benachrichtigungen in der Entwicklerkonsole. Allerdings wird der Entwickler lange und m\u00fchsam im Code w\u00fchlen m\u00fcssen. Der Prozess kann mit automatisierten Analysetools wie folgt beschleunigt werden: SSL Check<\/a><\/noindex>, kostenlose Software Lighthouse oder kostenpflichtige Software Screaming Frog SEO Spider.<\/p>\n

    Eine Schwachstelle kann auch durch Probleme mit Legacy-Code entstehen \u2013 Code, der geerbt wurde. Zum Beispiel, wenn Teile der Seiten nach einer alten Vorlage generiert werden, die den \u00dcbergang der Websites zu https nicht ber\u00fccksichtigt.\u00a0\u00a0\u00a0\u00a0\n<\/li>\n

  2. Cookies ohne die Flags \u201eHTTPOnly\u201c und \u201esecure\u201c.<\/b>\n

    Das Attribut \u201eHTTPOnly\u201c sch\u00fctzt Cookies vor der Verarbeitung durch Skripte, die von Angreifern zur Stehlen von Benutzerdaten verwendet werden. Das Flag \u201esecure\u201c erlaubt die \u00dcbertragung von Cookies nicht im Klartext. Der Datenaustausch ist nur erlaubt, wenn f\u00fcr die \u00dcbertragung von Cookies das sichere Protokoll HTTPS verwendet wird.\u00a0<\/p>\n

    Beide Attribute werden in den Eigenschaften der Cookies festgelegt:<\/p>\n

    Set-Cookie: Secure; HttpOnly<\/code><\/pre>\n
    \nWie gef\u00e4hrlich ist<\/b>: Wenn der Website-Entwickler diese Attribute nicht angegeben hat, kann ein Angreifer Benutzerdaten aus den Cookies abfangen und missbrauchen. Wenn Cookies zur Authentifizierung und Autorisierung verwendet werden, kann er die Benutzersitzung \u00fcbernehmen und im Namen des Benutzers auf der Website handeln.\u00a0<\/p>\n
    Was Webentwickler beachten sollten<\/b>: In der Regel werden diese Attribute in beliebten Frameworks automatisch gesetzt. Aber \u00fcberpr\u00fcfen Sie dennoch die Konfiguration des Webservers und setzen Sie das Flag: Set-Cookie HttpOnly; Secure. <\/p>\n
    Dabei macht das Attribut \u201eHTTPOnly\u201c die Cookies auch f\u00fcr Ihr eigenes JavaScript unsichtbar.\u00a0\u00a0\n<\/li>\n
  3. Path-Based Vulnerabilities (\u201epfadbasierte\u201c Schwachstellen).<\/b>\n
    Der Scanner meldet solche Sicherheitsanf\u00e4lligkeiten, wenn er eine \u00f6ffentlich zug\u00e4ngliche Datei oder ein Verzeichnis der Website mit potenziell vertraulichen Informationen findet. Zum Beispiel entdeckt er einzelne Dateien mit Systemkonfigurationen oder den Zugriff auf das gesamte Dateisystem. Diese Situation kann auftreten, wenn die Zugriffsrechte auf der Website falsch eingestellt sind.<\/p>\n
    Wie gef\u00e4hrlich ist<\/b>: Wenn das Dateisystem \"nach au\u00dfen zeigt\", kann ein Angreifer in die Benutzeroberfl\u00e4che des Betriebssystems eindringen und versuchen, Ordner mit Passw\u00f6rtern zu finden, falls sie im Klartext gespeichert sind (so sollte man es nicht machen!). Oder er kann Passwort-Hashes stehlen und versuchen, das Passwort zu knacken, sowie versuchen, Privilegien im System zu erh\u00f6hen und tiefer in die Infrastruktur vorzudringen.\u00a0\u00a0<\/p>\n
    Was Webentwickler beachten sollten<\/b>: Vergessen Sie nicht die Zugriffsrechte und konfigurieren Sie die Plattform, den Webserver, die Webanwendung so, dass es nicht m\u00f6glich ist, aus dem Webverzeichnis \"zu entweichen\".\n<\/li>\n
  4. Formulare zur Eingabe vertraulicher Daten mit aktivierter Auto-Completion-Funktion.<\/b>\n
    Wenn ein Benutzer h\u00e4ufig Formulare auf Websites ausf\u00fcllt, speichert sein Browser diese Informationen mithilfe der Auto-Completion-Funktion.\u00a0<\/p>\n
    Formulare auf Websites k\u00f6nnen Felder mit vertraulichen Informationen enthalten, beispielsweise Passw\u00f6rter oder Kreditkartennummern. F\u00fcr solche Felder sollte die Auto-Completion-Funktion auf der Website deaktiviert werden.\u00a0<\/p>\n
    Wie gef\u00e4hrlich ist<\/b>: Wenn der Browser des Benutzers vertrauliche Informationen speichert, kann ein Angreifer sie sp\u00e4ter abfangen, beispielsweise durch Phishing. Im Grunde genommen setzen Webentwickler, die diesen Aspekt vergessen, ihre Benutzer einem Risiko aus.\u00a0<\/p>\n
    Was Webentwickler beachten sollten<\/b>: In diesem Fall haben wir einen klassischen Konflikt: Komfort vs. Sicherheit. Wenn der Webentwickler an den Komfort des Benutzers denkt, kann er bewusst die Auto-Completion w\u00e4hlen. Beispielsweise wenn es wichtig ist, den Web Content Accessibility Guidelines<\/a><\/noindex> \u2013 Richtlinien zur Barrierefreiheit von Inhalten f\u00fcr Benutzer mit Behinderungen.\u00a0<\/p>\n
    F\u00fcr die meisten Browser kann die Auto-Completion mit dem Attribut autocompete=\"off\" deaktiviert werden, beispielsweise:<\/p>\n
    \u00a0<body>\n    <form action="\/de\/form\/submit\/" method="get" autocomplete="off" data-trp-original-action="\/form\/submit">\n      <div>\n        <input type="text" placeholder="Vorname">\n      <\/div>\n      <div>\n        <input type="text" id="lname" placeholder="Nachname" autocomplete="on">\n      <\/div>\n      <div>\n        <input type="number" placeholder="Kreditkartennummer">\n      <\/div>\n      <input type="submit">\n    <input type="hidden" name="trp-form-language" value="de"\/><\/form>\n  <\/body><\/code><\/pre>\n
    \nAber f\u00fcr Chrome funktioniert das nicht. Dies wird durch JavaScript umgangen, eine Rezeptvariante findet man hier<\/a><\/noindex>.\u00a0\n<\/li>\n
  5. Im Code der Website ist der Header X-Frame-Options nicht gesetzt.\u00a0<\/b>\n
    Dieser Header beeinflusst die Tags frame, iframe, embed oder object. Mit ihm kann das Einbetten Ihrer Website in ein Frame vollst\u00e4ndig untersagt werden. Dazu muss der Wert X-Frame-Options: deny angegeben werden. Alternativ kann X-Frame-Options: sameorigin verwendet werden, wodurch das Einbetten in ein iframe nur auf Ihrer Domain m\u00f6glich ist.<\/p>\n
    Wie gef\u00e4hrlich ist<\/b>: Das Fehlen eines solchen Headers kann auf b\u00f6sartigen Websites f\u00fcr Clickjacking<\/i>verwendet werden. Bei einem solchen Angriff erstellt der Angreifer ein transparentes Frame \u00fcber Schaltfl\u00e4chen und t\u00e4uscht den Benutzer. Zum Beispiel platzieren Betr\u00fcger ein Frame auf der Website sozialer Netzwerke. Der Benutzer denkt, er klickt auf eine Schaltfl\u00e4che auf dieser Website. Stattdessen wird der Klick abgefangen und die Anfrage des Benutzers wird an das soziale Netzwerk gesendet, in dem eine aktive Sitzung besteht. Auf diese Weise versenden die Angreifer Spam im Namen des Benutzers oder manipulieren Abonnenten und Likes.\u00a0<\/p>\n
    Wenn diese M\u00f6glichkeit nicht untersagt wird, kann ein Angreifer die Schaltfl\u00e4che Ihrer Anwendung auf einer b\u00f6sartigen Website platzieren. Er k\u00f6nnte an Ihrem Partnerprogramm oder an Ihren Benutzern interessiert sein.\u00a0\u00a0<\/p>\n
    Was Webentwickler beachten sollten<\/b>: Eine Schwachstelle kann auftreten, wenn X-Frame-Options mit einem konfliktreichen Wert auf dem Webserver oder dem Lastenverteilerserver gesetzt wird. In diesem Fall werden der Server und der Lastenverteilerserver den Header einfach \u00fcberschreiben, da sie eine h\u00f6here Priorit\u00e4t im Vergleich zum Backend-Code haben.\u00a0\u00a0<\/p>\n
    Die Werte deny und sameorigin des Headers X-Frame-Options w\u00fcrden die Arbeit des Yandex Webvisors behindern. Um die Verwendung von iframe f\u00fcr den Webvisor zu erm\u00f6glichen, muss eine separate Regel in den Einstellungen geschrieben werden. Zum Beispiel kann man f\u00fcr nginx folgendes konfigurieren:<\/p>\n
    http{\n...\n map $http_referer $frame_options {\n \"~webvisor.com\" \"ALLOW-FROM http:\/\/webvisor.com\";\n default \"SAMEORIGIN\";\n }\n add_header X-Frame-Options $frame_options;\n...\n}\n\n<\/code><\/pre>\n
    \n<\/li>\n
  6. Schwachstellen PRSSI (Path-relative stylesheet import).\u00a0\u00a0<\/b>\n
    Dies ist eine Schwachstelle in den Stilen der Website. Sie tritt auf, wenn zur Verlinkung von Stylesheets relative Links wie href=\"\/somefolder\/styles.css\/\" verwendet werden. Ein Angreifer k\u00f6nnte dies ausnutzen, wenn er einen Weg findet, den Benutzer auf eine b\u00f6sartige Seite umzuleiten. Die Seite w\u00fcrde den relativen Link in ihre URL einf\u00fcgen und einen Zugriff auf die Styles vort\u00e4uschen. Es w\u00fcrde eine Anfrage wie badsite.ru\/...\/somefolder\/styles.css\/ entstehen, die im Namen des Styles sch\u00e4dliche Aktionen durchf\u00fchren k\u00f6nnte.\u00a0<\/p>\n
    Wie gef\u00e4hrlich ist<\/b>: Ein Betr\u00fcger kann diese Schwachstelle ausnutzen, wenn er eine weitere Sicherheitsl\u00fccke findet. Dadurch k\u00f6nnen Benutzerdaten aus Cookies oder Tokens gestohlen werden.<\/p>\n
    Was Webentwickler beachten sollten<\/b>: Setzen Sie den Header X-Content-Type-Options: nosniff. In diesem Fall \u00fcberpr\u00fcft der Browser den Inhaltstyp f\u00fcr Styles. Wenn der Typ von text\/css abweicht, blockiert der Browser die Anfrage.\n<\/li>\n<\/ol>\n
    <\/p>\n
    Kritische Schwachstellen<\/h2>\n
    <\/p>\n
      \n
    1. Die Seite mit dem Passwortfeld wird \u00fcber einen ungesicherten Kanal bereitgestellt (HTML-Formular mit Passwortfeld(en) wird \u00fcber HTTP bereitgestellt).<\/b>\n
      Die Antwort vom Server \u00fcber einen unverschl\u00fcsselten Kanal ist anf\u00e4llig f\u00fcr Man-in-the-Middle-Angriffe. Ein Angreifer kann den Verkehr abfangen und sich zwischen Client und Server schalten, w\u00e4hrend die Seite vom Server zum Client \u00fcbertragen wird.\u00a0<\/p>\n
      Wie gef\u00e4hrlich ist<\/b>: Ein Betr\u00fcger kann die Seite manipulieren und dem Benutzer ein Formular f\u00fcr vertrauliche Daten senden, die an den Server des Angreifers gesendet werden.\u00a0<\/p>\n
      Was Webentwickler beachten sollten<\/b>: Einige Websites senden anstelle eines Passworts einen Einmal-Code an die E-Mail\/Telefonnummer der Benutzer. In diesem Fall ist die Schwachstelle nicht so kritisch, jedoch erschwert der Mechanismus den Benutzern das Leben.\n<\/li>\n
    2. Absenden des Formulars mit Benutzername und Passwort \u00fcber einen ungesicherten Kanal (Login-Formular wird nicht \u00fcber HTTPS gesendet).<\/b>\n
      In diesem Fall wird vom Benutzer ein Formular mit Benutzername und Passwort \u00fcber einen unverschl\u00fcsselten Kanal an den Server gesendet.<\/p>\n
      Wie gef\u00e4hrlich ist<\/b>: Im Gegensatz zum vorherigen Fall handelt es sich hierbei um eine kritische Schwachstelle. Es ist einfacher, vertrauliche Daten abzufangen, da hierf\u00fcr nicht einmal Code geschrieben werden muss.\u00a0\n<\/li>\n
    3. Verwendung von JavaScript-Bibliotheken mit bekannten Schwachstellen.<\/b>\n
      W\u00e4hrend der Scanzeit wurde jQuery zur am h\u00e4ufigsten verwendeten Bibliothek mit einer breiten Palette von Versionen. In jeder der Versionen gibt es mindestens eine, wenn nicht sogar mehrere bekannte Schwachstellen. Die Auswirkungen k\u00f6nnen unterschiedlich sein \u2013 abh\u00e4ngig von der Art der Schwachstelle.<\/p>\n
      Wie gef\u00e4hrlich ist<\/b>: F\u00fcr bekannte Schwachstellen gibt es Exploits, zum Beispiel diese:<\/p>\n
      \"Die
      \n
      \nWas Webentwickler beachten sollten<\/b>: Kehren Sie regelm\u00e4\u00dfig zum Zyklus zur\u00fcck: Suche nach bekannten Schwachstellen \u2013 Behebung \u2013 \u00dcberpr\u00fcfung. Wenn Sie veraltete Bibliotheken bewusst verwenden, beispielsweise um alte Browser zu unterst\u00fctzen oder um Kosten zu sparen, suchen Sie nach M\u00f6glichkeiten, bekannte Schwachstellen zu beheben.\u00a0\n<\/li>\n
    4. Cross-Site Scripting (XSS).\u00a0<\/b>
      \nCross-Site Scripting (XSS), oder Cross-Site-Skripte, sind Angriffe auf Webanwendungen, bei denen sch\u00e4dlicher Code in der Datenbank erscheint. Wenn Qualys eine solche Schwachstelle findet, kann ein potenzieller Angreifer einen eigenen JS-Skript-Code in die Seite einf\u00fcgen oder hat dies bereits getan, um sch\u00e4dliche Aktionen durchzuf\u00fchren.<\/p>\n
      Stored XSS (Gespeicherte XSS)<\/b> sind gef\u00e4hrlicher, da das Skript auf dem Server eingef\u00fcgt wird und jedes Mal ausgef\u00fchrt wird, wenn die angegriffene Seite im Browser ge\u00f6ffnet wird.<\/p>\n
      Reflected XSS (Reflektierte XSS)<\/b> ist einfacher durchzuf\u00fchren, da ein b\u00f6swilliges Skript in eine HTTP-Anfrage eingesetzt werden kann. Die Anwendung erh\u00e4lt die HTTP-Anfrage, \u00fcberpr\u00fcft die Daten nicht, packt sie ein und sendet sie sofort. Wenn der Angreifer den Datenverkehr abf\u00e4ngt und ein Skript vom Typ <\/p>\n
      <script>\/*+\u0447\u0442\u043e+\u0442\u043e+\u043f\u043b\u043e\u0445\u043e\u0435+*\/<\/script> <\/code><\/pre>\n
      \neinf\u00fcgt, wird eine sch\u00e4dliche Anfrage im Namen des Clients gesendet.<\/p>\n
      Ein pr\u00e4gnantes Beispiel f\u00fcr XSS sind JS-Sniffer, die Seiten zum Eingeben von CVC, Ablaufdatum der Karte usw. imitieren.\u00a0<\/p>\n
      Was Webentwickler beachten sollten<\/b>: Im Header Content-Security-Policy verwenden Sie das Attribut script-src, damit der Browser des Kunden nur Code von einer vertrauensw\u00fcrdigen Quelle l\u00e4dt und ausf\u00fchrt. Zum Beispiel whitelistet script-src 'self' alle Skripte nur von unserer Website.\u00a0
      \nDie beste Praxis ist Inline-Code: Erlauben Sie nur Inline-JavaScript mit dem Wert unsafe-inline. Dieser Wert erlaubt die Verwendung von Inline-JS\/CSS, verbietet jedoch nicht das Einbinden von JS-Dateien. In Kombination mit script-src 'self' verbieten wir die Ausf\u00fchrung externer Skripte.<\/p>\n
      Loggen Sie unbedingt alles \u00fcber report-uri und beobachten Sie die Versuche, in die Webseite einzudringen.\n<\/li>\n
    5. SQL-Injection.<\/b>
      \nEine Schwachstelle zeigt die M\u00f6glichkeit an, SQL-Code auf die Website einzubringen, der direkt auf die Datenbank der Website zugreift. Eine SQL-Injektion ist m\u00f6glich, wenn Benutzerdaten nicht escapes werden: Sie werden nicht auf G\u00fcltigkeit gepr\u00fcft und direkt in der Anfrage verwendet. Zum Beispiel passiert dies, wenn ein Formular auf der Website die Eingaben nicht auf den Datentyp \u00fcberpr\u00fcft.\u00a0<\/p>\n
      Wie gef\u00e4hrlich ist<\/b>: Wenn ein Angreifer in ein solches Formular eine SQL-Anfrage eingibt, kann er die Datenbank zum Absturz bringen oder vertrauliche Informationen preisgeben.\u00a0<\/p>\n
      Was Webentwickler beachten sollten<\/b>: Vertrauen Sie nicht dem, was vom Browser kommt. Schutzma\u00dfnahmen sollten sowohl auf der Client- als auch auf der Serverseite ergriffen werden.\u00a0<\/p>\n
      Auf der Client-Seite implementieren Sie eine \u00dcberpr\u00fcfung der Felder mit JavaScript.\u00a0<\/p>\n
      Integrierte Funktionen in beliebten Frameworks helfen ebenfalls dabei, verd\u00e4chtige Zeichen auf dem Server zu maskieren. Es wird auch empfohlen, parametrische Abfragen f\u00fcr Datenbanken auf dem Server zu verwenden.<\/p>\n
      Bestimmen Sie, wo genau die Interaktion mit der Datenbank in der Webanwendung stattfindet.\u00a0<\/p>\n
      Interaktion entsteht, wenn wir Informationen erhalten: eine Anfrage mit einer ID (\u00c4nderung der ID), die Erstellung eines neuen Benutzers, ein neuer Kommentar \u2013 neue Eintr\u00e4ge in der Datenbank. Hier k\u00f6nnen SQL-Injektionen auftreten. Selbst beim L\u00f6schen eines Eintrags aus der Datenbank ist eine SQL-Injektion m\u00f6glich.\n<\/li>\n<\/ol>\n
      <\/p>\n
      Allgemeine Empfehlungen<\/h2>\n
      \nErfinden Sie das Rad nicht neu \u2013 verwenden Sie bew\u00e4hrte Frameworks.<\/b>. In der Regel sind beliebte Frameworks sicherer. F\u00fcr .NET sind das ASP.NET MVC und ASP.NET Core, f\u00fcr Python Django oder Flask, f\u00fcr Ruby Ruby on Rails, f\u00fcr PHP Symfony, Laravel, Yii, f\u00fcr JavaScript Node.JS - Express.js, f\u00fcr Java Spring MVC.<\/p>\n
      Achten Sie auf die Updates des Anbieters und aktualisieren Sie regelm\u00e4\u00dfig.<\/b>. Eine Schwachstelle wird gefunden, dann wird ein Exploit geschrieben, \u00f6ffentlich gemacht, und alles beginnt von neuem. Melden Sie sich f\u00fcr Updates zu stabilen Versionen vom Softwareanbieter an.<\/p>\n
      \u00dcberpr\u00fcfen Sie die Zugriffsrechte.<\/b>. Auf der Serverseite sollten Sie immer Ihren Code so behandeln, als w\u00e4re er von Ihrem \u00e4rgsten Feind verfasst, der darauf aus ist, Ihre Website zu zerst\u00f6ren und die Integrit\u00e4t Ihrer Daten zu verletzen. Zumal es manchmal tats\u00e4chlich so ist.<\/p>\n
      Verwenden Sie Klone, Testumgebungen, und gehen Sie erst dann in die Produktion.<\/b>. Das hilft, um Fehler in der Produktionsumgebung zu vermeiden: die Produktionsumgebung bringt Geld, Ausfallzeiten sind kritisch. Bei der Hinzuf\u00fcgung, Korrektur oder Behebung eines Problems sollte die Arbeit zun\u00e4chst in einer Testumgebung durchgef\u00fchrt, die Funktionalit\u00e4t und entdeckten Schwachstellen \u00fcberpr\u00fcft und anschlie\u00dfend die Arbeit mit der Produktionsumgebung geplant werden.\u00a0<\/p>\n
      Sch\u00fctzen Sie die Webanwendung mithilfe von Web Application Firewall<\/a><\/noindex> und integrieren Sie damit Berichte von Schwachstellenscannern.<\/b>. Beispielsweise werden bei DataLine als Verbindung zwischen den Diensten Qualys und FortiWeb verwendet.
      \n
      Quelle:       habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
      \u041f\u0440\u0438\u043c\u0435\u0440\u043d\u043e \u0433\u043e\u0434 \u043d\u0430\u0437\u0430\u0434 \u043c\u044b \u0432 DataLine \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u043b\u0438 \u0441\u0435\u0440\u0432\u0438\u0441 \u0434\u043b\u044f \u043f\u043e\u0438\u0441\u043a\u0430 \u0438 \u0430\u043d\u0430\u043b\u0438\u0437\u0430 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0435\u0439 \u0432 \u0418\u0422-\u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f\u0445. \u0412 \u043e\u0441\u043d\u043e\u0432\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u0430 \u2013 \u043e\u0431\u043b\u0430\u0447\u043d\u043e\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 Qualys, \u043f\u0440\u043e \u0440\u0430\u0431\u043e\u0442\u0443 \u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u043c\u044b \u0443\u0436\u0435 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u043b\u0438. \u0417\u0430 \u0433\u043e\u0434 \u0440\u0430\u0431\u043e\u0442\u044b \u0441 \u0440\u0435\u0448\u0435\u043d\u0438\u0435\u043c \u043c\u044b \u043f\u0440\u043e\u0432\u0435\u043b\u0438 291 \u0441\u043a\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0434\u043b\u044f \u0440\u0430\u0437\u043d\u044b\u0445 \u0441\u0430\u0439\u0442\u043e\u0432 \u0438 \u043d\u0430\u043a\u043e\u043f\u0438\u043b\u0438 \u0441\u0442\u0430\u0442\u0438\u0441\u0442\u0438\u043a\u0443 \u043f\u043e \u0440\u0430\u0441\u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0435\u043d\u043d\u044b\u043c \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044f\u043c \u0432 \u0432\u0435\u0431-\u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f\u0445.\u00a0 \u0412 \u0441\u0442\u0430\u0442\u044c\u0435 \u043d\u0438\u0436\u0435 \u044f \u043f\u043e\u043a\u0430\u0436\u0443, \u043a\u0430\u043a\u0438\u0435 \u0438\u043c\u0435\u043d\u043d\u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84185,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84184","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\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\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Die Tods\u00fcnden der Sicherheit einer Website: Was wir aus der Statistik des Schwachstellenscanners im letzten Jahr gelernt haben | ProHoster","description":"Vor etwa einem Jahr haben wir bei DataLine einen Service zur Suche und Analyse von Schwachstellen in IT-Anwendungen gestartet.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/smertnye-grehi-bezopasnosti-sajta-chto-my-uznali-iz-statistiki-skanera-uyazvimostej-za-god","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\u043c\u0435\u0440\u0442\u043d\u044b\u0435 \u0433\u0440\u0435\u0445\u0438 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0441\u0430\u0439\u0442\u0430: \u0447\u0442\u043e \u043c\u044b \u0443\u0437\u043d\u0430\u043b\u0438 \u0438\u0437 \u0441\u0442\u0430\u0442\u0438\u0441\u0442\u0438\u043a\u0438 \u0441\u043a\u0430\u043d\u0435\u0440\u0430 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0435\u0439 \u0437\u0430 \u0433\u043e\u0434 | ProHoster","og:description":"\u041f\u0440\u0438\u043c\u0435\u0440\u043d\u043e \u0433\u043e\u0434 \u043d\u0430\u0437\u0430\u0434 \u043c\u044b \u0432 DataLine \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u043b\u0438 \u0441\u0435\u0440\u0432\u0438\u0441 \u0434\u043b\u044f \u043f\u043e\u0438\u0441\u043a\u0430 \u0438 \u0430\u043d\u0430\u043b\u0438\u0437\u0430 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0435\u0439 \u0432 \u0418\u0422-\u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f\u0445.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/smertnye-grehi-bezopasnosti-sajta-chto-my-uznali-iz-statistiki-skanera-uyazvimostej-za-god","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":"2020-06-05T17:42:31+00:00","article:modified_time":"2020-06-05T17:42:31+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"84184","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":"","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":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:03:50","updated":"2022-09-30 12:56:20","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\/84184","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=84184"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/84184\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/84185"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=84184"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=84184"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=84184"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}