Virun engem Joer hu mir bei DataLine lancéiert fir Schwachstelle bei IT-Applikatiounen ze sichen an ze analyséieren. De Service baséiert op der Qualys Cloud Léisung, där hir Operatioun erkläert gëtt . Am Laf vun engem Joer mat der Léisung ze schaffen, hu mir 291 Scans fir verschidde Site gemaach a Statistiken iwwer allgemeng Schwachstelle bei Webapplikatiounen gesammelt.
Am Artikel hei ënnen weisen ech Iech genau wéi eng Lächer an der Websäit Sécherheet hannert verschiddene Kritizitéitsniveauen verstoppt sinn. Loosst eis kucken wéi eng Schwachstelle de Scanner besonnesch dacks fonnt huet, firwat se optrieden, a wéi Dir Iech selwer schützt.
Qualys trennt all Webapplikatiounsschwieregkeeten an dräi Kritizitéitsniveauen: niddereg, mëttel an héich. Wann Dir d'Verdeelung no "Gravitéit" kuckt, schéngt et datt alles net sou schlecht ass. Et gi wéineg Schwachstelle mat engem héijen Niveau vu Kritik, meeschtens all sinn net kritesch:
Awer onkritesch heescht net harmlos. Si kënnen och sérieux Schued verursaachen.
Top "net-kritesch" Schwachstelle
- Gemëscht Inhalt Schwachstelle.
De Standard fir Websäit Sécherheet ass den Transfert vun Daten tëscht dem Client an dem Server iwwer den HTTPS Protokoll, deen d'Verschlësselung ënnerstëtzt an d'Informatioun virun der Interceptioun schützt.
E puer Siten benotzen gemëscht Inhalt: Verschidde Donnéeë ginn iwwer den onsécheren HTTP-Protokoll transferéiert. Dëst ass wéi et meeschtens vermëttelt gëtt passiv Inhalt - Informatioun déi nëmmen d'Affichage vum Site beaflosst: Biller, CSS Stiler. Awer heiansdo ass dëst wéi et iwwerdroe gëtt aktiv Inhalt: Scripten déi d'Behuele vum Site kontrolléieren. An dësem Fall, mat Hëllef vu spezielle Software, kënnt Dir Informatioun mat aktive Inhalter vum Server analyséieren, Är Äntwerten op der Flucht änneren an d'Maschinn op eng Manéier funktionnéieren déi net vu senge Creatoren virgesi war.
Méi nei Versioune vu Browser warnen d'Benotzer datt Site mat gemëschten Inhalt onsécher sinn an den Inhalt blockéieren. Websäit Entwéckler kréien och Browserwarnungen an der Konsole. Zum Beispill, esou gesäit et an :
Firwat ass et geféierlech?: Ugräifer benotzen en onséchere Protokoll fir d'Benotzerinformatioun z'ënnerscheeden, Scripten z'ersetzen an Ufroen op de Site a sengem Numm ze schécken. Och wann e Site Visiteur keng Daten aginn huet, schützt dat net virun phishing - Vertraulech Informatioun ze kréien mat betrügeresche Methoden. Zum Beispill, andeems Dir e Skript benotzt, kënnt Dir de Benotzer op eng onsécher Säit viruleeden, déi sech als een dem Benotzer vertraut mécht. A verschiddene Fäll gesäit de béisaarteg Site nach besser aus wéi d'Original, an de Benotzer kann de Formulaire selwer ausfëllen a vertraulech Daten ofginn.Wat e Webentwéckler sollt erënneren: Och wann de Site Administrateur en SSL/TLS Zertifika installéiert a konfiguréiert huet, kann eng Schwachstelle wéinst mënschleche Feeler entstoen. Zum Beispill, wann Dir op enger vun de Säiten net e relativen Link, mee en absolute Link vun http setzt, an zousätzlech keng Viruleedungen vun http op https ageriicht hutt.
Dir kënnt gemëschten Inhalt op engem Site mat engem Browser z'entdecken: Sich de Quellcode vun der Säit, liest Notifikatiounen an der Entwécklerkonsole. Wéi och ëmmer, den Entwéckler muss mat dem Code fir eng laang Zäit an tediously tinchen. Dir kënnt de Prozess mat automatiséierten Analyse Tools beschleunegen, zum Beispill: , Gratis Lighthouse Software oder bezuelte Software Screaming Frog SEO Spider.
Och kann d'Schwachheet entstoen wéinst Probleemer mam Legacy-Code - Code deen ierflecher ass. Zum Beispill, wann e puer Säiten mat enger aler Schabloun generéiert ginn, déi den Iwwergank vu Siten op https net berücksichtegt.
- Cookien ouni "HTTOnly" a "sécher" Fändelen.
Den Attribut "HTTPOnly" schützt Cookien virum Veraarbechtung vu Skripte déi Ugräifer benotze fir Benotzerdaten ze klauen. De "sécher" Fändel erlaabt net datt Cookien am Kloertext geschéckt ginn. Kommunikatioun gëtt nëmmen erlaabt wann de séchere HTTPS Protokoll benotzt gëtt fir Cookien ze schécken.
Béid Attributer ginn an de Cookie Eegeschafte spezifizéiert:
Set-Cookie: Secure; HttpOnlyFirwat ass et geféierlech?: Wann de Site Entwéckler dës Attributer net uginn huet, kéint en Ugräifer d'Informatioun vum Benotzer aus dem Cookie ofbriechen an ausnotzen. Wann Cookien fir d'Authentifikatioun an d'Autorisatioun benotzt ginn, kann hien d'Sessioun vum Benotzer kapéieren an Aktiounen um Site a sengem Numm ausféieren.
Wat e Webentwéckler sollt erënneren: An der Regel, a populäre Kaderen ginn dës Attributer automatesch gesat. Awer nach ëmmer d'Webserverkonfiguratioun kontrolléieren an de Fändel setzen: Set-Cookie HttpOnly; Séchert.
An dësem Fall wäert den Attribut "HTTPOnly" Cookien fir Ären eegene JavaScript onsichtbar maachen.
- Path-baséiert Schwachstelle.
De Scanner mellt esou eng Schwachstelle wann et eng ëffentlech zougänglech Datei oder Websäitverzeechnes mat potenziell vertraulech Informatioun fënnt. Zum Beispill erkennt et individuell Systemkonfiguratiounsdateien oder Zougang zum ganze Dateiesystem. Dës Situatioun ass méiglech wann Zougangsrechter falsch um Site gesat ginn.
Firwat ass et geféierlech?: Wann de Dateiesystem "ausstéckt", kann en Ugräifer an d'Betriebssystem-Interface falen a probéieren Classeure mat Passwierder ze fannen, wa se am Kloertext gespäichert sinn (maacht dat net!). Oder Dir kënnt Passwuert-Hashes klauen an d'Passwuert brute force, a probéiert och Privilegien am System z'erhéijen a méi déif an d'Infrastruktur ze plënneren.
Wat e Webentwéckler sollt erënneren: Vergiesst net iwwer Zougangsrechter a konfiguréiert d'Plattform, de Webserver, d'Webapplikatioun sou datt et onméiglech ass aus dem Webverzeichnis ze "entkommen".
- Formulaire fir sensibel Donnéeën anzeginn mat Auto-Fill aktivéiert.
Wann e Benotzer dacks Formulairen op Websäiten ausfëllt, späichert hire Browser dës Informatioun mat der Autofill Feature.
Formulaire op Websäite kënnen Felder mat sensiblen Informatioun enthalen, wéi Passwierder oder Kreditkaartnummeren. Fir esou Felder ass et derwäert d'Form Autofill Funktioun um Site selwer auszeschalten.
Firwat ass et geféierlech?: Wann de Browser vum Benotzer sensibel Informatioun späichert, kann en Ugräifer se spéider ofbriechen, zum Beispill duerch Phishing. Am Wesentlechen, e Webentwéckler, deen dës Nuance vergiess huet, setzt seng Benotzer op.
Wat e Webentwéckler sollt erënneren: An dësem Fall hu mir e klassesche Konflikt: Komfort vs Sécherheet. Wann e Webentwéckler un d'Benotzererfarung denkt, kann hien bewosst Autocomplete wielen. Zum Beispill, wann et wichteg ass ze verfollegen - Empfehlungen fir Accessibilitéit vum Inhalt fir Benotzer mat Behënnerungen.
Fir déi meescht Browser kënnt Dir Autocomplete mat dem Autocompete="off" Attribut deaktivéieren, zum Beispill:
<body> <form action="/lb/form/submit" method="get" autocomplete="off"> <div> <input type="text" placeholder="First Name"> </div> <div> <input type="text" id="lname" placeholder="Last Name" autocomplete="on"> </div> <div> <input type="number" placeholder="Credit card number"> </div> <input type="submit"> </form> </body>Awer et funktionnéiert net fir Chrome. Dëst gëtt mat JavaScript ëmgoen, eng Variant vum Rezept ka fonnt ginn .
- Den X-Frame-Options Header ass net am Site Code gesat.
Dësen Header beaflosst Frame, iframe, embed oder Objet Tags. Mat senger Hëllef kënnt Dir komplett verbidden Äre Site an engem Frame z'integréieren. Fir dëst ze maachen, musst Dir de Wäert X-Frame-Options spezifizéieren: deny. Oder Dir kënnt X-Frame-Optiounen spezifizéieren: sameorigin, da gëtt d'Ebedding an engem iframe nëmmen op Ärem Domain verfügbar.
Firwat ass et geféierlech?: D'Feele vun esou engem Header kann op béiswëlleg Siten benotzt ginn ze clickjacking. Fir dësen Attack erstellt den Ugräifer en transparente Kader uewen op de Knäppercher an tricks de Benotzer. Zum Beispill: Scammers Kader sozial Netzwierker Säiten op enger Websäit. De Benotzer mengt datt hien e Knäppchen op dësem Site klickt. Amplaz gëtt de Klick ofgefaangen an d'Ufro vum Benotzer gëtt an de sozialen Netzwierk geschéckt wou et eng aktiv Sessioun ass. Dëst ass wéi Ugräifer Spam am Numm vum Benotzer schécken oder Abonnenten a Likes kréien.
Wann Dir dës Fonktioun net deaktivéiert, kann en Ugräifer Är Applikatiounsknäppchen op eng béiswëlleg Säit setzen. Hie kann an Ärem Referralprogramm oder Äre Benotzer interesséiert sinn.
Wat e Webentwéckler sollt erënneren: D'Schwachheet kann optrieden wann X-Frame-Options mat engem konfliktesche Wäert op de Webserver oder de Lastbalancer gesat gëtt. An dësem Fall wäert de Server an de Balancer einfach den Header nei schreiwen, well se eng méi héich Prioritéit hunn am Verglach zum Backend Code.
D'Verleegnen a Sameorigin Wäerter vum X-Frame-Options Header stéieren d'Operatioun vum Yandex Web Viewer. Fir d'Benotzung vun iframes fir de Web Viewer ze erlaben, musst Dir eng separat Regel an den Astellungen schreiwen. Zum Beispill, fir nginx kënnt Dir et esou konfiguréieren:
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - PRSSI (Path-relative Stylesheet Import) Schwachstelle.
Dëst ass eng Schwachstelle am Styling vum Site. Et geschitt wann relativ Linken wéi href="/lb/somefolder/styles.css/" benotzt gi fir Zougang zu Stildateien. En Ugräifer profitéiert dovunner wa se e Wee fannen fir de Benotzer op eng béiswëlleg Säit ze redirectéieren. D'Säit setzt e relativen Link a seng URL a simuléiert e Stilerruff. Dir kritt eng Ufro wéi badsite.ru/…/somefolder/styles.css/, déi béiswëlleg Handlungen ënner dem Deckmantel vun engem Stil ausféiere kënnen.
Firwat ass et geféierlech?: E Bedruch kéint dës Schwachstelle ausnotzen, wa se en anert Sécherheetsloch fannen. Als Resultat ass et méiglech Benotzerdaten vu Cookien oder Tokens ze klauen.
Wat e Webentwéckler sollt erënneren: Setzt den X-Content-Type-Options Header op: nosniff. An dësem Fall kontrolléiert de Browser den Inhaltstyp fir d'Stiler. Wann den Typ anescht ass wéi Text/css, blockéiert de Browser d'Ufro.
Kritesch Schwachstelle
- Eng Säit mat engem Passwuertfeld gëtt vum Server iwwer en onséchere Kanal iwwerdroen (HTML Form mat Passwuertfeld(en) gëtt iwwer HTTP zerwéiert).
D'Äntwert vum Server iwwer en onverschlësselte Kanal ass vulnérabel fir "Mann an der Mëtt" Attacken. En Ugräifer kann den Traffic offangen a sech tëscht dem Client an dem Server keilen wéi d'Säit vum Server op de Client reest.
Firwat ass et geféierlech?: De Betrüger kann d'Säit ersetzen an dem Benotzer e Formulaire fir vertraulech Donnéeën schécken, déi op de Server vum Ugräifer goen.
Wat e Webentwéckler sollt erënneren: E puer Siten schécken de Benotzer en eemolege Code per E-Mail / Telefon amplaz vun engem Passwuert. An dësem Fall ass d'Schwachheet net sou kritesch, awer de Mechanismus wäert d'Liewe vun de Benotzer komplizéieren.
- Schéckt e Formulaire mat Login a Passwuert iwwer en onséchere Kanal (Login Form ass net iwwer HTTPS ofginn).
An dësem Fall gëtt e Formulaire mat engem Login a Passwuert vum Benotzer op de Server iwwer en onverschlësselte Kanal geschéckt.
Firwat ass et geféierlech?: Am Géigesaz zum fréiere Fall ass dëst schonn eng kritesch Schwachstelle. Et ass méi einfach sensibel Donnéeën z'ënnerscheeden, well Dir braucht net emol Code ze schreiwen fir et ze maachen.
- Benotzt JavaScript Bibliothéike mat bekannte Schwachstelle.
Wärend dem Scan war déi meescht benotzte Bibliothéik jQuery mat enger grousser Zuel vu Versiounen. All Versioun huet op d'mannst eng, oder nach méi, bekannte Schwachstelle. Den Impakt ka ganz ënnerschiddlech sinn ofhängeg vun der Natur vun der Schwachstelle.
Firwat ass et geféierlech?: Et gi Exploiten fir bekannte Schwachstelle, zum Beispill:
Wat e Webentwéckler sollt erënneren: Regelméisseg zréck an den Zyklus: Sich no bekannte Schwachstelle - fixen - kontrolléieren. Wann Dir legacy Bibliothéike bewosst benotzt, zum Beispill fir eeler Browser z'ënnerstëtzen oder Geld ze spueren, kuckt no enger Geleeënheet fir eng bekannte Schwachstelle ze fixéieren. - Cross-Site Scripting (XSS).
Cross-Site Scripting (XSS), oder Cross-Site Scripting, ass en Attack op eng Webapplikatioun, déi zu Malware an d'Datebank agefouert gëtt. Wann Qualys esou eng Schwachstelle fënnt, heescht et datt e potenziellen Ugräifer säin eegene js Skript an de Sitecode agefouert huet fir béiswëlleg Handlungen auszeféieren.Gespäichert XSS méi geféierlech, well de Skript op de Server agebonne gëtt an all Kéier wann déi attackéiert Säit am Browser opgemaach gëtt, ausgefouert gëtt.
Reflexéiert XSS méi einfach auszeféieren, well e béiswëlleg Skript kann an eng HTTP-Ufro injizéiert ginn. D'Applikatioun kritt eng HTTP-Ufro, wäert d'Donnéeën net validéieren, packen se a schéckt se direkt. Wann en Ugräifer den Traffic offänkt an e Skript setzt wéi
<script>/*+что+то+плохое+*/</script>da gëtt eng béiswëlleg Ufro am Numm vum Client geschéckt.
E markant Beispill vun XSS: js Sniffers déi Säiten simuléieren fir CVC anzeginn, Verfallsdatum vun der Kaart, asw.
Wat e Webentwéckler sollt erënneren: Am Content-Security-Policy Header benotzt d'Script-src Attribut fir de Client Browser ze zwéngen nëmmen de Code vun enger vertrauter Quell erofzelueden an auszeféieren. Zum Beispill, script-src 'self' whitelists nëmmen all Scripte vun eisem Site.
Déi bescht Praxis ass Inline Code: Erlaabt nëmmen Inline Javascript mat dem onsécheren Inline Wäert. Dëse Wäert erlaabt d'Benotzung vun inline js / css, awer verbitt net d'Inklusioun vu js Dateien. A Kombinatioun mat script-src 'self' deaktivéiere mir extern Scripte fir auszeféieren.Gitt sécher alles mat Report-uri ze protokolléieren a kuckt op Versuche fir se op de Site ëmzesetzen.
- SQL Injektiounen.
D'Vulnerabilitéit weist d'Méiglechkeet un SQL Code an eng Websäit ze sprëtzen déi direkt op d'Datebank vun der Websäit zougräift. SQL Injektioun ass méiglech wann d'Donnéeë vum Benotzer net gepréift ginn: et gëtt net op Richtegkeet gepréift a gëtt direkt an der Ufro benotzt. Zum Beispill geschitt dat wann e Formulaire op enger Websäit net iwwerpréift ob den Input mat der Datentyp entsprécht.Firwat ass et geféierlech?: Wann en Ugräifer eng SQL Ufro an dëse Formulaire agitt, kann hien d'Datebank ofbriechen oder vertraulech Informatioun verroden.
Wat e Webentwéckler sollt erënneren: Vertrau net wat aus dem Browser kënnt. Dir musst Iech souwuel op der Client Säit wéi och op der Server Säit schützen.
Op der Client Säit, schreift Feldvalidatioun mat JavaScript.
Built-in Funktiounen a populäre Kaderen hëllefen och verdächteg Personnagen um Server ze flüchten. Et ass och recommandéiert parametriséiert Datebank Ufroen um Server ze benotzen.
Bestëmmt wou genau d'Interaktioun mat der Datebank op der Webapplikatioun stattfënnt.
Interaktioun geschitt wann mir Informatioun kréien: eng Ufro mat enger ID (Ännerung vun der ID), d'Schafe vun engem neie Benotzer, en neie Kommentar oder nei Entréen an der Datebank. Dëst ass wou SQL Injektiounen kënnen optrieden. Och wa mir e Rekord aus der Datebank läschen, ass SQL Injektioun méiglech.
Allgemeng Recommandatiounen
Erfannen net d'Rad - benotzt bewisen Kaderen. Als Regel sinn populär Kaderen méi sécher. Fir .NET - ASP.NET MVC an ASP.NET Core, fir Python - Django oder Flask, fir Ruby - Ruby on Rails, fir PHP - Symfony, Laravel, Yii, fir JavaScript - Node.JS-Express.js, fir Java - Fréijoer MVC.
Follegt Verkeeferupdates a aktualiséieren regelméisseg. Si fannen eng Schwachstelle, schreiwen dann en Ausnotzen, maachen se ëffentlech verfügbar, an alles wäert erëm geschéien. Abonnéiert Iech op Updates op stabile Versioune vum Softwareverkeefer.
Check Permissiounen. Op der Server Säit, behandelt ëmmer Äre Code wéi wann et, vum éischte bis de leschte Bréif, vun Ärem meescht gehaasste Feind geschriwwe gouf, deen Äre Site briechen wëllt, d'Integritéit vun Ären Donnéeën verletzen. Ausserdeem ass dat heiansdo richteg.
Benotzt Klonen, Testplazen, a benotzt se dann fir d'Produktioun. Dëst hëlleft, éischtens, Feeler a Feeler an engem produktiven Ëmfeld ze vermeiden: e produktivt Ëmfeld bréngt Suen, en einfacht produktivt Ëmfeld ass kritesch. Wann Dir e Problem bäidréit, fixéiert oder zoumaacht, ass et derwäert an engem Testëmfeld ze schaffen, dann d'Funktionalitéit a Schwachstelle ze iwwerpréiwen, an dann ze plangen mat der Produktiounsëmfeld ze schaffen.
Schützt Är Webapplikatioun mat an integréieren Rapporte vum Schwachstelle Scanner mat et. Zum Beispill benotzt DataLine Qualys a FortiWeb als Bündel vu Servicer.
Source: will.com