{"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 gr\u00f6\u00dften Sicherheitsrisiken f\u00fcr Websites: Was wir aus der Statistik des Schwachstellenscanners im letzten Jahr gelernt haben","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Vor etwa einem Jahr haben wir bei DataLine Dienst<\/a><\/noindex> ein Tool zur Suche und Analyse von Schwachstellen in IT-Anwendungen eingef\u00fchrt. Die Grundlage des Services ist die Cloud-L\u00f6sung Qualys, \u00fcber deren Funktionalit\u00e4ten wir bereits berichtet haben<\/a><\/noindex>. Im Laufe eines Jahres haben wir 291 Scans f\u00fcr unterschiedliche Websites durchgef\u00fchrt und eine Statistik zu h\u00e4ufigsten Schwachstellen in Webanwendungen gesammelt.\u00a0<\/p>\n

Im folgenden Artikel zeige ich Ihnen, welche Sicherheitsl\u00fccken sich hinter den verschiedenen Kritikalit\u00e4tsstufen verbergen. Lassen Sie uns die Schwachstellen betrachten, die der Scanner besonders h\u00e4ufig gefunden hat, warum sie auftreten k\u00f6nnen und wie man sich sch\u00fctzt.\u00a0<\/p>\n

\"Die
\n<\/a><\/noindex>
\nQualys kategorisiert alle Schwachstellen von Webanwendungen in drei Kritikalit\u00e4tsstufen: niedrig, mittel und hoch. Wenn man sich die Verteilung nach \u201aSchwere\u2018 anschaut, scheint es, als w\u00e4re die Lage nicht so schlecht. Es gibt nur wenige Schwachstellen mit hohem Kritikalit\u00e4tsgrad, die Mehrheit ist unkritisch:\u00a0<\/p>\n

\"Die
\n
\nAber unkritisch bedeutet nicht harmlos. Sie k\u00f6nnen ebenfalls erhebliche Sch\u00e4den verursachen.\u00a0<\/p>\n

Die h\u00e4ufigsten \u201eunkritischen\u201c Schwachstellen<\/h2>\n

<\/p>\n

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

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

    Einige Websites verwenden gemischte Inhalte<\/i>: sie \u00fcbertragen einen Teil der Daten \u00fcber das ungesch\u00fctzte HTTP-Protokoll. Oft handelt es sich dabei um statische Inhalte<\/i> : Informationen, die nur die Darstellung der Website beeinflussen, wie Bilder und CSS-Stile. Manchmal werden jedoch auch dynamische Inhalte<\/i>: Skripte, die das Verhalten der Website steuern, auf diese Weise \u00fcbertragen. Dabei kann spezielle Software die vom Server kommenden Informationen mit dynamischen Inhalten analysieren, ihre Antworten in Echtzeit \u00e4ndern und den Computer dazu bringen, anders zu funktionieren, als es seine Entwickler beabsichtigt hatten.\u00a0<\/p>\n

    Moderne Browser warnen die Benutzer, dass Websites mit gemischten Inhalten unsicher sind, und blockieren den Inhalt. Auch die Entwickler von Websites erhalten Warnmeldungen vom Browser in der Konsole. So sieht das beispielsweise in Firefox<\/a><\/noindex>:\u00a0<\/p>\n

    \"Die
    \n
    \naus. Was ist die Gefahr?<\/b>: Angreifer nutzen ungesicherte Protokolle, um Benutzerdaten abzufangen, Skripte zu manipulieren und Anfragen im Namen des Nutzers an die Website zu senden. Selbst wenn der Besucher der Website keine Daten eingegeben hat, sch\u00fctzt ihn das nicht vor Phishing <\/i>\u2013 dem Abgreifen von vertraulichen Informationen durch betr\u00fcgerische Methoden. Beispielsweise kann ein Skript den Benutzer auf eine unsichere Website umleiten, die sich als f\u00fcr ihn vertraut ausgibt. In einigen F\u00e4llen sieht die b\u00f6sartige Website sogar besser aus als das Original, und der Benutzer k\u00f6nnte die Formulare selbst ausf\u00fcllen und vertrauliche Informationen \u00fcbermitteln.\u00a0<\/p>\n

    Was Webentwickler beachten sollten<\/b>: Selbst wenn der Administrator der Website ein SSL\/TLS-Zertifikat installiert und konfiguriert hat, k\u00f6nnen Schwachstellen aufgrund menschlicher Fehler entstehen. Zum Beispiel, wenn auf einer der Seiten ein absoluter Link mit http anstelle eines relativen Links gesetzt wurde und zus\u00e4tzlich keine Weiterleitungen von http auf https eingerichtet wurden.\u00a0<\/p>\n

    Mischinhalte auf einer Website k\u00f6nnen mithilfe des Browsers erkannt werden: Durchsuchen Sie den Quellcode der Seite oder lesen Sie Benachrichtigungen in der Entwicklerkonsole. Allerdings muss der Entwickler oft m\u00fchsam im Code suchen. Der Prozess kann mit automatisierten Analysetools beschleunigt werden, zum Beispiel: SSL \u00dcberpr\u00fcfung<\/a><\/noindex>, das freie Tool Lighthouse oder die kostenpflichtige Software Screaming Frog SEO Spider.<\/p>\n

    Ein weiterer Schwachpunkt kann durch Probleme mit Legacy-Code entstehen \u2013 also Code, der vererbt wurde. Zum Beispiel, wenn einige Seiten mit einem alten Template generiert werden, das den Wechsel auf HTTPS nicht ber\u00fccksichtigt.\u00a0\u00a0\u00a0\u00a0\n<\/li>\n

  2. Cookies ohne die Flags \"HTTPOnly\" und \"secure\".<\/b>\n

    Das Attribut \"HTTPOnly\" sch\u00fctzt die Cookies vor der Verarbeitung durch Skripte, die von Angreifern verwendet werden, um Benutzerdaten zu stehlen. Das Flag \u201esecure\u201c erlaubt nicht die \u00dcbertragung von Cookies im Klartext. Der Datenaustausch wird nur gestattet, wenn die Cookies \u00fcber das sichere Protokoll HTTPS gesendet werden.\u00a0<\/p>\n

    Beide Attribute werden in den Cookie-Eigenschaften festgelegt:<\/p>\n

    Set-Cookie: Secure; HttpOnly<\/code><\/pre>\n
    \naus. Was ist die Gefahr?<\/b>: Wenn der Webentwickler diese Attribute nicht festgelegt hat, kann ein Angreifer Benutzerdaten aus Cookies abfangen und missbrauchen. Wenn Cookies f\u00fcr die Authentifizierung und Autorisierung verwendet werden, kann er die Benutzersitzung \u00fcbernehmen und im Namen des Nutzers auf der Website agieren.\u00a0<\/p>\n
    Was Webentwickler beachten sollten<\/b>: In der Regel werden diese Attribute in g\u00e4ngigen Frameworks automatisch eingestellt. \u00dcberpr\u00fcfen Sie dennoch die Konfiguration des Webservers und setzen Sie das Flag: Set-Cookie HttpOnly; Secure. <\/p>\n
    Das Attribut \u201eHTTPOnly\u201c macht die Cookies jedoch auch f\u00fcr Ihr eigenes JavaScript unsichtbar.\u00a0\u00a0\n<\/li>\n
  3. Path-Based Vulnerabilities (\u201epfadbasierte\u201c Schwachstellen).<\/b>\n
    Der Scanner meldet eine solche Schwachstelle, wenn er eine \u00f6ffentlich zug\u00e4ngliche Datei oder ein Verzeichnis der Website mit potenziell vertraulichen Informationen findet. Zum Beispiel, wenn er individuelle Dateien mit Systemkonfigurationen oder den vollst\u00e4ndigen Zugriff auf das Dateisystem entdeckt. Eine solche Situation kann auftreten, wenn auf der Website die Zugriffsrechte falsch eingestellt sind.<\/p>\n
    aus. Was ist die Gefahr?<\/b>: Wenn das Dateisystem \"nach au\u00dfen schaut\", kann ein Angreifer in die Benutzeroberfl\u00e4che des Betriebssystems eindringen und versuchen, Ordner mit Passw\u00f6rtern zu finden, wenn diese unverschl\u00fcsselt gespeichert sind (das sollte man vermeiden!). Alternativ kann er Hashes von Passw\u00f6rtern stehlen und durch Ausprobieren ein Passwort finden. Zudem k\u00f6nnte er versuchen, seine Berechtigungen im System zu erh\u00f6hen und sich tiefer in die Infrastruktur vorzuwagen.\u00a0\u00a0<\/p>\n
    Was Webentwickler beachten sollten<\/b>: Vergessen Sie nicht die Zugriffsrechte und konfigurieren Sie die Plattform, den Webserver und die Webanwendung so, dass ein \"Entkommen\" aus dem Webverzeichnis unm\u00f6glich ist.\n<\/li>\n
  4. Formulare zur Eingabe vertraulicher Daten mit aktivierter Autocomplete-Funktion.<\/b>\n
    Wenn ein Benutzer h\u00e4ufig Formulare auf Websites ausf\u00fcllt, speichert sein Browser diese Informationen \u00fcber die Autocomplete-Funktion.\u00a0<\/p>\n
    Formulare auf Websites k\u00f6nnen Felder mit vertraulichen Informationen enthalten, wie z.B. Passw\u00f6rter oder Kreditkartennummern. F\u00fcr solche Felder sollte die Autocomplete-Funktion auf der Website deaktiviert werden.\u00a0<\/p>\n
    aus. Was ist die Gefahr?<\/b>: Wenn der Browser des Nutzers sensible Informationen speichert, kann ein Angreifer diese sp\u00e4ter abfangen, beispielsweise durch Phishing. Im Grunde genommen setzt ein Webentwickler, der diesen Faktor vergisst, seine Nutzer einem Risiko aus.\u00a0<\/p>\n
    Was Webentwickler beachten sollten<\/b>: In diesem Fall haben wir einen klassischen Konflikt: Komfort vs. Sicherheit. Wenn ein Webentwickler an den Komfort des Nutzers denkt, k\u00f6nnte er sich bewusst f\u00fcr die Autovervollst\u00e4ndigung entscheiden. Zum Beispiel, wenn es wichtig ist, den Vorgaben zu folgen. Web Content Accessibility Guidelines<\/a><\/noindex> \u2013 Richtlinien zur Barrierefreiheit von Inhalten f\u00fcr Nutzer mit Einschr\u00e4nkungen.\u00a0<\/p>\n
    F\u00fcr die meisten Browser kann die Autovervollst\u00e4ndigung mit dem Attribut autocompete=\"off\" deaktiviert werden, zum Beispiel:<\/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
    \nDoch f\u00fcr Chrome funktioniert das nicht. Dies wird in der Regel mit JavaScript umgangen, ein Rezept daf\u00fcr findet sich hier<\/a><\/noindex>.\u00a0\n<\/li>\n
  5. Im Code der Webseite ist der Header X-Frame-Options nicht festgelegt.\u00a0<\/b>\n
    Dieser Header hat Auswirkungen auf die Tags frame, iframe, embed oder object. Damit kann man das Einbetten der eigenen Webseite innerhalb eines Frames vollst\u00e4ndig verbieten. Daf\u00fcr muss der Wert X-Frame-Options: deny festgelegt werden. Alternativ kann man X-Frame-Options: sameorigin angeben, wodurch das Einbetten im iframe nur auf der eigenen Domain m\u00f6glich ist.<\/p>\n
    aus. Was ist die Gefahr?<\/b>: Das Fehlen eines solchen Headers kann auf b\u00f6sartigen Webseiten f\u00fcr Clickjacking<\/i>verwendet werden. Bei einem solchen Angriff erstellt der Angreifer einen transparenten Frame \u00fcber den Schaltfl\u00e4chen und t\u00e4uscht den Benutzer. Beispielsweise platzieren Betr\u00fcger einen Frame auf der Webseite sozialer Netzwerke. Der Benutzer glaubt, er klickt auf eine Schaltfl\u00e4che auf dieser Seite. Stattdessen wird der Klick abgefangen und eine Anfrage des Benutzers an das soziale Netzwerk gesendet, wo eine aktive Sitzung besteht. So versenden die Angreifer Spam im Namen des Benutzers oder manipulieren Abonnenten und Likes.\u00a0<\/p>\n
    Wenn diese M\u00f6glichkeit nicht ausgeschlossen wird, kann der Angreifer eine Schaltfl\u00e4che Ihrer Anwendung auf einer b\u00f6sartigen Webseite 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 die X-Frame-Options mit einem konfliktierenden Wert auf dem Webserver oder Lastenausgleichsger\u00e4t festgelegt sind. In diesem Fall \u00fcberschreibt der Server und der Lastenausgleich einfach den Header, da sie eine h\u00f6here Priorit\u00e4t haben im Vergleich zum Backend-Code.\u00a0\u00a0<\/p>\n
    Die Werte deny und sameorigin des X-Frame-Options-Headers beeintr\u00e4chtigen die Funktion des Yandex-Webvisors. Um die Verwendung von iframes f\u00fcr den Webvisor zu erm\u00f6glichen, muss eine separate Regel in den Einstellungen erstellt werden. Zum Beispiel kann dies f\u00fcr nginx so konfiguriert werden:<\/p>\n
    http{\n...\n\u00a0map $http_referer $frame_options {\n\u00a0"~webvisor.com" "ALLOW-FROM http:\/\/webvisor.com";\n\u00a0default "SAMEORIGIN";\n\u00a0}\n\u00a0add_header X-Frame-Options $frame_options;\n...\n}\n\n<\/code><\/pre>\n
    \n<\/li>\n
  6. PRSSI-Schwachstellen (Path-relative Stylesheet-Import).\u00a0\u00a0<\/b>\n
    \u042d\u0442\u043e \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c \u0432 \u0441\u0442\u0438\u043b\u044f\u0445 \u0441\u0430\u0439\u0442\u0430. \u041e\u043d\u0430 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0435\u0442, \u0435\u0441\u043b\u0438 \u0434\u043b\u044f \u043e\u0431\u0440\u0430\u0449\u0435\u043d\u0438\u044f \u043a \u0444\u0430\u0439\u043b\u0430\u043c \u0441\u0442\u0438\u043b\u0435\u0439 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e\u0442\u0441\u044f \u043e\u0442\u043d\u043e\u0441\u0438\u0442\u0435\u043b\u044c\u043d\u044b\u0435 \u0441\u0441\u044b\u043b\u043a\u0438 \u0432\u0438\u0434\u0430 href="\/somefolder\/styles.css\/". \u0417\u043b\u043e\u0443\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0438\u043a \u0432\u043e\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0441\u044f \u044d\u0442\u0438\u043c, \u0435\u0441\u043b\u0438 \u043d\u0430\u0439\u0434\u0435\u0442 \u0441\u043f\u043e\u0441\u043e\u0431 \u043f\u0435\u0440\u0435\u0432\u0435\u0441\u0442\u0438 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044f \u043d\u0430 \u0432\u0440\u0435\u0434\u043e\u043d\u043e\u0441\u043d\u0443\u044e \u0441\u0442\u0440\u0430\u043d\u0438\u0446\u0443. \u0421\u0442\u0440\u0430\u043d\u0438\u0446\u0430 \u043f\u043e\u0434\u0441\u0442\u0430\u0432\u0438\u0442 \u043e\u0442\u043d\u043e\u0441\u0438\u0442\u0435\u043b\u044c\u043d\u0443\u044e \u0441\u0441\u044b\u043b\u043a\u0443 \u0432 \u0441\u0432\u043e\u0439 url \u0438 \u0438\u043c\u0438\u0442\u0438\u0440\u0443\u0435\u0442 \u043e\u0431\u0440\u0430\u0449\u0435\u043d\u0438\u0435 \u043a \u0441\u0442\u0438\u043b\u044f\u043c. \u041f\u043e\u043b\u0443\u0447\u0438\u0442\u0441\u044f \u0437\u0430\u043f\u0440\u043e\u0441 \u043d\u0430\u043f\u043e\u0434\u043e\u0431\u0438\u0435 badsite.ru\/…\/somefolder\/styles.css\/, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043f\u043e\u0434 \u0432\u0438\u0434\u043e\u043c \u0441\u0442\u0438\u043b\u044f \u043c\u043e\u0436\u0435\u0442 \u0441\u043e\u0432\u0435\u0440\u0448\u0430\u0442\u044c \u0432\u0440\u0435\u0434\u043e\u043d\u043e\u0441\u043d\u044b\u0435 \u0434\u0435\u0439\u0441\u0442\u0432\u0438\u044f.\u00a0<\/p>\n
    aus. Was ist die Gefahr?<\/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 pr\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 vom Server \u00fcbertragen (HTML-Formular mit Passwortfeld(en) wird \u00fcber HTTP bereitgestellt).<\/b>\n
      Antworten vom Server \u00fcber einen unverschl\u00fcsselten Kanal sind anf\u00e4llig f\u00fcr Angriffe vom Typ \"Man-in-the-Middle\". Ein Angreifer kann den Datenverkehr abfangen und sich zwischen den Client und den Server schalten, w\u00e4hrend die Seite vom Server zum Client l\u00e4uft.\u00a0<\/p>\n
      aus. Was ist die Gefahr?<\/b>: Ein Betr\u00fcger k\u00f6nnte die Seite manipulieren und dem Benutzer ein Formular f\u00fcr vertrauliche Daten senden, die dann an den Server des Angreifers gesendet werden.\u00a0<\/p>\n
      Was Webentwickler beachten sollten<\/b>: Einige Webseiten senden anstelle eines Passworts einen Einmalcode an die E-Mail\/Telefonnummer der Benutzer. In diesem Fall ist die Schwachstelle nicht so kritisch, doch der Mechanismus erschwert den Nutzern das Leben.\n<\/li>\n
    2. Das Senden des Formulars mit Benutzername und Passwort \u00fcber einen ungesicherten Kanal (Anmeldeformular wird nicht \u00fcber HTTPS \u00fcbermittelt).<\/b>\n
      In diesem Fall wird vom Benutzer eine Formular mit Benutzername und Passwort \u00fcber einen unverschl\u00fcsselten Kanal an den Server gesendet.<\/p>\n
      aus. Was ist die Gefahr?<\/b>: Im Gegensatz zum vorherigen Fall handelt es sich hierbei bereits um eine kritische Sicherheitsanf\u00e4lligkeit. Es ist einfacher, sensible Daten abzufangen, da hierf\u00fcr nicht einmal Code geschrieben werden muss.\u00a0\n<\/li>\n
    3. Verwendung von JavaScript-Bibliotheken mit bekannten Sicherheitsanf\u00e4lligkeiten.<\/b>\n
      W\u00e4hrend des Scanvorgangs wurde jQuery zur meistgenutzten Bibliothek, die eine umfangreiche Versionenanzahl aufweist. In jeder Version gibt es mindestens eine, h\u00e4ufig jedoch mehrere bekannte Schwachstellen. Die Auswirkungen k\u00f6nnen unterschiedlich sein \u2013 abh\u00e4ngig von der Art der Sicherheitsanf\u00e4lligkeit.<\/p>\n
      aus. Was ist die Gefahr?<\/b>: F\u00fcr bekannte Sicherheitsanf\u00e4lligkeiten gibt es Exploits, wie beispielsweise:<\/p>\n
      \"Die
      \n
      \nWas Webentwickler beachten sollten<\/b>: Kehren Sie regelm\u00e4\u00dfig zum Zyklus zur\u00fcck: Suche nach bekannten Sicherheitsanf\u00e4lligkeiten \u2013 Behebung \u2013 \u00dcberpr\u00fcfung. Wenn Sie absichtlich veraltete Bibliotheken verwenden, etwa zur Unterst\u00fctzung \u00e4lterer Browser oder zur Kostensenkung, suchen Sie nach M\u00f6glichkeiten zur Behebung der bekannten Sicherheitsanf\u00e4lligkeit.\u00a0\n<\/li>\n
    4. Cross-Site-Skripte (XSS).\u00a0<\/b>
      \nCross-Site-Scripting (XSS) oder Cross-Site-Skripte sind Angriffe auf Webanwendungen, bei denen schadhafter Code in der Datenbank eingebettet wird. Wenn Qualys eine solche Sicherheitsanf\u00e4lligkeit entdeckt, bedeutet das, dass ein potenzieller Angreifer seinen js-Skript in den Code der Website einf\u00fcgen kann oder bereits eingef\u00fcgt hat, um sch\u00e4dliche Aktionen auszuf\u00fchren.<\/p>\n
      Stored XSS (XSS gespeichert)<\/b> sind gef\u00e4hrlicher, da das Skript auf dem Server implementiert wird und jedes Mal ausgef\u00fchrt wird, wenn die angegriffene Seite im Browser ge\u00f6ffnet wird.<\/p>\n
      Reflected XSS (XSS reflektiert)<\/b> sind einfacher durchzuf\u00fchren, da das b\u00f6sartige Skript in die HTTP-Anfrage eingebettet werden kann. Die Anwendung erh\u00e4lt die HTTP-Anfrage, \u00fcberpr\u00fcft die Daten nicht, verpackt sie und sendet sie sofort. Wenn der Angreifer den Datenverkehr abf\u00e4ngt und ein Skript wie <\/p>\n
      <script>\/*+\u0447\u0442\u043e+\u0442\u043e+\u043f\u043b\u043e\u0445\u043e\u0435+*\/<\/script> <\/code><\/pre>\n
      \neinf\u00fcgt, wird eine b\u00f6sartige Anfrage im Namen des Clients gesendet.<\/p>\n
      Ein anschauliches Beispiel f\u00fcr XSS: JS-Sniffer, die Seiten zur Eingabe von CVC, Ablaufdatum der Karte usw. nachahmen.\u00a0<\/p>\n
      Was Webentwickler beachten sollten<\/b>: \u0412 \u0437\u0430\u0433\u043e\u043b\u043e\u0432\u043a\u0435 Content-Security-Policy \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0439\u0442\u0435 \u0430\u0442\u0440\u0438\u0431\u0443\u0442 script-src, \u0447\u0442\u043e\u0431\u044b \u0431\u0440\u0430\u0443\u0437\u0435\u0440 \u043a\u043b\u0438\u0435\u043d\u0442\u0430 \u0437\u0430\u0433\u0440\u0443\u0436\u0430\u043b \u0438 \u0438\u0441\u043f\u043e\u043b\u043d\u044f\u043b \u0442\u043e\u043b\u044c\u043a\u043e \u043a\u043e\u0434 \u0441 \u0434\u043e\u0432\u0435\u0440\u0435\u043d\u043d\u043e\u0433\u043e \u0438\u0441\u0442\u043e\u0447\u043d\u0438\u043a\u0430. \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, script-src ‘self’ \u0432\u043d\u043e\u0441\u0438\u0442 \u0432 \u0431\u0435\u043b\u044b\u0439 \u0441\u043f\u0438\u0441\u043e\u043a \u0432\u0441\u0435 \u0441\u043a\u0440\u0438\u043f\u0442\u044b \u0442\u043e\u043b\u044c\u043a\u043e \u0441 \u043d\u0430\u0448\u0435\u0433\u043e \u0441\u0430\u0439\u0442\u0430.\u00a0
      \n\u041d\u0430\u0438\u043b\u0443\u0447\u0448\u0435\u0439 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u043e\u0439 \u0441\u0447\u0438\u0442\u0430\u0435\u0442\u0441\u044f Inline code: \u0440\u0430\u0437\u0440\u0435\u0448\u0438\u0442\u0435 \u0442\u043e\u043b\u044c\u043a\u043e inline javascript \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u0437\u043d\u0430\u0447\u0435\u043d\u0438\u044f unsafe-inline. \u0422\u0430\u043a\u043e\u0435 \u0437\u043d\u0430\u0447\u0435\u043d\u0438\u0435 \u0440\u0430\u0437\u0440\u0435\u0448\u0430\u0435\u0442 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c inline js\/css, \u043d\u043e \u043d\u0435 \u0437\u0430\u043f\u0440\u0435\u0449\u0430\u0435\u0442 \u043f\u043e\u0434\u043a\u043b\u044e\u0447\u0430\u0442\u044c js-\u0444\u0430\u0439\u043b\u044b. \u0412 \u043a\u043e\u043c\u0431\u0438\u043d\u0430\u0446\u0438\u0438 \u0441\u043e script-src ‘self’ \u043c\u044b \u0437\u0430\u043f\u0440\u0435\u0449\u0430\u0435\u043c \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u0442\u044c \u0432\u043d\u0435\u0448\u043d\u0438\u0435 \u0441\u0446\u0435\u043d\u0430\u0440\u0438\u0438.<\/p>\n
      Stellen Sie sicher, dass Sie alles mit report-uri protokollieren und versuchen, Einf\u00fcgungen in die Website zu erkennen.\n<\/li>\n
    5. SQL-Injektionen.<\/b>
      \nDiese Schwachstelle erm\u00f6glicht das Einf\u00fcgen von SQL-Code in die Website, der direkt auf die Datenbank zugreift. Eine SQL-Injektion tritt auf, wenn Benutzerdaten nicht gepr\u00fcft und direkt in Anfragen verwendet werden. Dies passiert beispielsweise, wenn ein Formular auf der Website keine Eingabewerte auf ihren Datentyp \u00fcberpr\u00fcft.\u00a0<\/p>\n
      aus. Was ist die Gefahr?<\/b>: Wenn ein Angreifer eine solche Anfrage in ein Formular eingibt, kann er die Datenbank zum Absturz bringen oder vertrauliche Informationen preisgeben.\u00a0<\/p>\n
      Was Webentwickler beachten sollten<\/b>: Vertrauen Sie nicht darauf, was vom Browser kommt. Es ist wichtig, sowohl auf der Client- als auch auf der Serverseite Schutzma\u00dfnahmen zu ergreifen.\u00a0<\/p>\n
      F\u00fchren Sie auf der Client-Seite eine \u00dcberpr\u00fcfung der Eingabefelder mit JavaScript durch.\u00a0<\/p>\n
      Eingebaute Funktionen in g\u00e4ngigen Frameworks helfen ebenfalls, verd\u00e4chtige Zeichen auf dem Server zu maskieren. Es wird auch empfohlen, auf dem Server parameterisierte Datenbankabfragen zu verwenden.<\/p>\n
      Bestimmen Sie, wo genau das Interagieren mit der Datenbank in der Webanwendung erfolgt.\u00a0<\/p>\n
      Interaktion tritt auf, wenn wir Informationen erhalten: eine Anfrage mit der ID (ID-\u00c4nderung), die Erstellung eines neuen Benutzers, ein neuer Kommentar \u2013 neue Eintr\u00e4ge in der Datenbank. Hier k\u00f6nnen SQL-Injection-Angriffe auftreten. Selbst wenn wir einen Eintrag aus der Datenbank l\u00f6schen, k\u00f6nnte eine SQL-Injektion m\u00f6glich sein.\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 popul\u00e4re Frameworks sicherer. F\u00fcr .NET sind das ASP.NET MVC und ASP.NET Core, f\u00fcr Python \u2013 Django oder Flask, f\u00fcr Ruby \u2013 Ruby on Rails, f\u00fcr PHP \u2013 Symfony, Laravel, Yii, f\u00fcr JavaScript \u2013 Node.js mit Express.js, f\u00fcr Java \u2013 Spring MVC.<\/p>\n
      Achten Sie auf Vendor-Updates und aktualisieren Sie regelm\u00e4\u00dfig<\/b>. Eine Schwachstelle wird entdeckt, dann wird ein Exploit geschrieben, ver\u00f6ffentlicht und alles wiederholt sich. Abonnieren Sie die Updates f\u00fcr stabile Versionen des Softwareanbieters.<\/p>\n
      \u00dcberpr\u00fcfen Sie die Zugriffsrechte<\/b>. Behandeln Sie Ihren Code von der Server-Seite immer so, als ob er von Ihrem \u00e4rgsten Feind geschrieben wurde, der versucht, Ihre Website zu hacken und die Integrit\u00e4t Ihrer Daten zu verletzen. Manchmal ist es tats\u00e4chlich so.<\/p>\n
      Verwenden Sie Klone, Testumgebungen und implementieren Sie \u00c4nderungen erst dann in die Produktionsumgebung<\/b>. Das hilft, um in erster Linie Fehler und Pannen in der Produktivumgebung zu vermeiden: Die Produktivumgebung bringt Geld, und Ausfallzeiten sind in der Produktivumgebung kritisch. Bei der Hinzuf\u00fcgung, Korrektur oder Schlie\u00dfung eines Problems sollten Arbeiten in einer Testumgebung durchgef\u00fchrt werden, dann die Funktionalit\u00e4t und entdeckte Schwachstellen \u00fcberpr\u00fcft werden, bevor die Arbeiten an der Produktivumgebung geplant werden.\u00a0<\/p>\n
      Sch\u00fctzen Sie die Webanwendung mithilfe von Web Application Firewall<\/a><\/noindex> und integrieren Sie Berichte von Vulnerability-Scannern<\/b>. Zum Beispiel werden bei DataLine die Dienste Qualys und FortiWeb als Kombination genutzt.
      \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 t\u00f6dlichen S\u00fcnden der Website-Sicherheit: Was wir aus der Schwachstellenscanner-Statistik des letzten Jahres gelernt haben | ProHoster","description":"Vor etwa einem Jahr haben wir bei DataLine einen Service zur Suche und Analyse von Schwachstellen in IT-Anwendungen gestartet. Der Dienst basiert auf der Cloud-L\u00f6sung von Qualys, \u00fcber die wir bereits berichtet haben. Im vergangenen Jahr haben wir 291 Scans f\u00fcr verschiedene Websites durchgef\u00fchrt und Statistiken zu h\u00e4ufigen Schwachstellen in Webanwendungen gesammelt. Im folgenden Artikel werde ich zeigen, welche genau.","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. \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. \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","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"},"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}]}}