Ongeveer 'n jaar gelede het ons by DataLine bekendgestel om kwesbaarhede in IT-toepassings te soek en te ontleed. Die diens is gebaseer op die Qualys-wolkoplossing, oor die werking daarvan . In die loop van 'n jaar van werk met die oplossing, het ons 291 skanderings vir verskillende werwe en opgehoopte statistieke oor algemene kwesbaarhede in webtoepassings uitgevoer.
In die artikel hieronder sal ek jou presies wys watter gate in webwerfsekuriteit agter verskillende vlakke van kritiek weggesteek is. Kom ons kyk watter kwesbaarhede die skandeerder veral gereeld gevind het, hoekom dit kan voorkom en hoe om jouself te beskerm.
Qualys verdeel alle webtoepassingskwesbaarhede in drie vlakke van kritiek: laag, medium en hoog. As jy kyk na die verspreiding volgens "erns", blyk dit dat alles nie so erg is nie. Daar is min kwesbaarhede met 'n hoë vlak van kritiek, meestal is almal nie-krities:
Maar onkrities beteken nie skadeloos nie. Hulle kan ook ernstige skade veroorsaak.
Top "nie-kritiese" kwesbaarhede
- Kwesbaarhede vir gemengde inhoud.
Die standaard vir webwerfsekuriteit is die oordrag van data tussen die kliënt en die bediener via die HTTPS-protokol, wat enkripsie ondersteun en inligting teen onderskepping beskerm.
Sommige werwe gebruik gemengde inhoud: Sommige data word oorgedra via die onveilige HTTP-protokol. Dit is hoe dit die meeste oorgedra word passiewe inhoud – inligting wat slegs die vertoning van die webwerf raak: prente, css-style. Maar soms is dit hoe dit oorgedra word aktiewe inhoud: skrifte wat die gedrag van die webwerf beheer. In hierdie geval, met behulp van spesiale sagteware, kan jy inligting ontleed met aktiewe inhoud wat van die bediener af kom, jou antwoorde dadelik verander en die masjien laat werk op 'n manier wat nie deur sy skeppers bedoel is nie.
Nuwer weergawes van blaaiers waarsku gebruikers dat werwe met gemengde inhoud onveilig is en blokkeer die inhoud. Webwerfontwikkelaars ontvang ook blaaierwaarskuwings in die konsole. Byvoorbeeld, dit is hoe dit binne lyk :
Wat is gevaarlik: Aanvallers gebruik 'n onveilige protokol om gebruikersinligting te onderskep, skrifte te vervang en namens hom versoeke na die webwerf te stuur. Selfs as 'n werfbesoeker nie data ingevoer het nie, beskerm dit hom nie teen nie uitvissing – verkryging van vertroulike inligting deur gebruik te maak van bedrieglike metodes. Byvoorbeeld, deur 'n skrip te gebruik, kan jy die gebruiker herlei na 'n onveilige werf wat voorgee as een wat aan die gebruiker bekend is. In sommige gevalle lyk die kwaadwillige webwerf selfs beter as die oorspronklike, en die gebruiker kan self die vorm invul en vertroulike data indien.Wat 'n webontwikkelaar moet onthou: Selfs al het die werfadministrateur 'n SSL/TLS-sertifikaat geïnstalleer en gekonfigureer, kan 'n kwesbaarheid ontstaan as gevolg van menslike foute. Byvoorbeeld, as jy op een van die bladsye nie 'n relatiewe skakel plaas nie, maar 'n absolute skakel van http, en daarby het jy nie herleidings van http na https opgestel nie.
Jy kan gemengde inhoud op 'n werf opspoor deur 'n blaaier te gebruik: soek die bladsy se bronkode, lees kennisgewings in die ontwikkelaarkonsole. Die ontwikkelaar sal egter lank en vervelig met die kode moet peuter. U kan die proses bespoedig met outomatiese ontledingsinstrumente, byvoorbeeld: , gratis Lighthouse-sagteware of betaalde sagteware Screaming Frog SEO Spider.
Die kwesbaarheid kan ook ontstaan as gevolg van probleme met verouderde kode - kode wat geërf is. Byvoorbeeld, as sommige bladsye gegenereer word met behulp van 'n ou sjabloon, wat nie die oorgang van werwe na https in ag neem nie.
- Koekies sonder die "HTTPOnly" en "veilige" vlae.
Die "HTTPOnly"-kenmerk beskerm koekies teen verwerking deur skrifte wat aanvallers gebruik om gebruikersdata te steel. Die "veilige" vlag laat nie toe dat koekies in duidelike teks gestuur word nie. Kommunikasie sal slegs toegelaat word as die veilige HTTPS-protokol gebruik word om koekies te stuur.
Albei eienskappe word in die koekie-eienskappe gespesifiseer:
Set-Cookie: Secure; HttpOnlyWat is gevaarlik: As die werfontwikkelaar nie hierdie kenmerke gespesifiseer het nie, kan 'n aanvaller die gebruiker se inligting van die koekie onderskep en dit ontgin. As koekies vir stawing en magtiging gebruik word, sal hy die gebruiker se sessie kan kaap en aksies op die webwerf namens hom kan uitvoer.
Wat 'n webontwikkelaar moet onthou: As 'n reël, in gewilde raamwerke word hierdie eienskappe outomaties ingestel. Maar kyk steeds na die webbedienerkonfigurasie en stel die vlag: Set-Cookie HttpOnly; Veilig.
In hierdie geval sal die "HTTPOnly"-kenmerk koekies onsigbaar maak vir jou eie JavaScript.
- Padgebaseerde kwesbaarhede.
Die skandeerder rapporteer so 'n kwesbaarheid as dit 'n publiek toeganklike lêer of webwerfgids met potensieel vertroulike inligting vind. Dit bespeur byvoorbeeld individuele stelselkonfigurasielêers of toegang tot die hele lêerstelsel. Hierdie situasie is moontlik as toegangsregte verkeerd op die webwerf gestel is.
Wat is gevaarlik: As die lêerstelsel "uitsteek", kan 'n aanvaller in die bedryfstelsel-koppelvlak val en probeer om dopgehou met wagwoorde te vind as dit in duidelike teks gestoor word (moenie dit doen nie!). Of jy kan wagwoord-hashes steel en die wagwoord brute force, en ook probeer om voorregte in die stelsel te verhoog en dieper in die infrastruktuur in te beweeg.
Wat 'n webontwikkelaar moet onthou: Moenie van toegangsregte vergeet nie en stel die platform, webbediener, webtoepassing op sodat dit onmoontlik is om die webgids te “ontsnap”.
- Vorms vir die invoer van sensitiewe data met outomatiese invul geaktiveer.
As 'n gebruiker gereeld vorms op webwerwe invul, stoor hul blaaier hierdie inligting met behulp van die outovul-funksie.
Vorms op webwerwe kan velde insluit met sensitiewe inligting, soos wagwoorde of kredietkaartnommers. Vir sulke velde is dit die moeite werd om die vorm-outovulfunksie op die webwerf self te deaktiveer.
Wat is gevaarlik: As die gebruiker se blaaier sensitiewe inligting stoor, kan 'n aanvaller dit later onderskep, byvoorbeeld deur uitvissing. In wese stel 'n webontwikkelaar wat van hierdie nuanse vergeet het, sy gebruikers op.
Wat 'n webontwikkelaar moet onthou: In hierdie geval het ons 'n klassieke konflik: gerief vs sekuriteit. As 'n webontwikkelaar aan gebruikerservaring dink, kan hy bewustelik outovoltooi kies. Byvoorbeeld, as dit belangrik is om te volg – aanbevelings vir toeganklikheid van inhoud vir gebruikers met gestremdhede.
Vir die meeste blaaiers kan jy outovoltooiing deaktiveer met die autocompete="off"-kenmerk, byvoorbeeld:
<body> <form action="/af/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>Maar dit sal nie vir Chrome werk nie. Dit word omseil met JavaScript, 'n variant van die resep kan gevind word .
- Die X-Frame-Options-opskrif is nie in die werfkode gestel nie.
Hierdie kopskrif beïnvloed raam-, iframe-, inbed- of objekmerkers. Met sy hulp kan u die inbedding van u webwerf binne 'n raam heeltemal verbied. Om dit te doen, moet jy die waarde X-Frame-Options: deny spesifiseer. Of jy kan X-Frame-Options spesifiseer: sameoorsprong, dan sal inbedding in 'n iframe slegs op jou domein beskikbaar wees.
Wat is gevaarlik: Die afwesigheid van so 'n kop kan op kwaadwillige werwe gebruik word om clickjacking. Vir hierdie aanval skep die aanvaller 'n deursigtige raam bo-op die knoppies en bedrieg die gebruiker. Byvoorbeeld: swendelaars raam sosiale netwerkbladsye op 'n webwerf. Die gebruiker dink hy klik 'n knoppie op hierdie webwerf. In plaas daarvan word die klik onderskep en die gebruiker se versoek word na die sosiale netwerk gestuur waar daar 'n aktiewe sessie is. Dit is hoe aanvallers strooipos namens die gebruiker stuur of intekenare en laaiks kry.
As jy nie hierdie kenmerk deaktiveer nie, kan 'n aanvaller jou toepassingknoppie op 'n kwaadwillige werf plaas. Hy stel dalk belang in jou verwysingsprogram of jou gebruikers.
Wat 'n webontwikkelaar moet onthou: Die kwesbaarheid kan voorkom as X-Frame-Options met 'n botsende waarde op die webbediener of lasbalanseerder gestel is. In hierdie geval sal die bediener en balanseerder eenvoudig die kopskrif herskryf, aangesien hulle 'n hoër prioriteit het in vergelyking met die backend-kode.
Die ontken- en dieselfde oorsprongwaardes van die X-Frame-Options-kopskrif sal inmeng met die werking van die Yandex-webkyker. Om die gebruik van iframes vir die webkyker toe te laat, moet jy 'n aparte reël in die instellings skryf. Byvoorbeeld, vir nginx kan jy dit so instel:
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 invoer) kwesbaarhede.
Dit is 'n kwesbaarheid in die werf se stilering. Dit kom voor as relatiewe skakels soos href="/af/somefolder/styles.css/" gebruik word om toegang tot styllêers te verkry. 'n Aanvaller sal hiervan voordeel trek as hulle 'n manier vind om die gebruiker na 'n kwaadwillige bladsy te herlei. Die bladsy sal 'n relatiewe skakel in sy url invoeg en 'n style-oproep simuleer. Jy sal 'n versoek kry soos badsite.ru/…/somefolder/styles.css/, wat kwaadwillige aksies onder die dekmantel van 'n styl kan uitvoer.
Wat is gevaarlik: 'n Bedrieër kan hierdie kwesbaarheid uitbuit as hulle 'n ander sekuriteitsgat vind. As gevolg hiervan is dit moontlik om gebruikersdata van koekies of tokens te steel.
Wat 'n webontwikkelaar moet onthou: Stel die X-Content-Type-Options kopskrif op: nosniff. In hierdie geval sal die blaaier die inhoudtipe vir die style nagaan. As die tipe anders as teks/css is, sal die blaaier die versoek blokkeer.
Kritieke kwesbaarhede
- 'n Bladsy met 'n wagwoordveld word vanaf die bediener oor 'n onveilige kanaal versend (HTML-vorm wat wagwoordveld(e) bevat, word oor HTTP bedien).
Die reaksie van die bediener oor 'n ongeënkripteerde kanaal is kwesbaar vir "Man in the middle" aanvalle. 'n Aanvaller kan verkeer onderskep en homself tussen die kliënt en bediener inwig terwyl die bladsy van die bediener na die kliënt beweeg.
Wat is gevaarlik: Die bedrieër sal die bladsy kan vervang en vir die gebruiker 'n vorm vir vertroulike data stuur, wat na die aanvaller se bediener sal gaan.
Wat 'n webontwikkelaar moet onthou: Sommige werwe stuur vir gebruikers 'n eenmalige kode per e-pos/foon in plaas van 'n wagwoord. In hierdie geval is die kwesbaarheid nie so krities nie, maar die meganisme sal die lewens van gebruikers bemoeilik.
- Stuur 'n vorm met aanmelding en wagwoord oor 'n onveilige kanaal (aanmeldvorm word nie via HTTPS ingedien nie).
In hierdie geval word 'n vorm met 'n login en wagwoord vanaf die gebruiker na die bediener gestuur via 'n ongeënkripteerde kanaal.
Wat is gevaarlik: Anders as die vorige geval, is dit reeds 'n kritieke kwesbaarheid. Dit is makliker om sensitiewe data te onderskep, want jy hoef nie eers kode te skryf om dit te doen nie.
- Gebruik JavaScript-biblioteke met bekende kwesbaarhede.
Tydens die skandering was die mees gebruikte biblioteek jQuery met 'n uitgebreide aantal weergawes. Elke weergawe het ten minste een, of selfs meer, bekende kwesbaarhede. Die impak kan baie verskil, afhangende van die aard van die kwesbaarheid.
Wat is gevaarlik: Daar is misbruik vir bekende kwesbaarhede, byvoorbeeld:
Wat 'n webontwikkelaar moet onthou: Keer gereeld terug na die siklus: soek na bekende kwesbaarhede - herstel - kontroleer. As jy verouderde biblioteke doelbewus gebruik, byvoorbeeld om ouer blaaiers te ondersteun of om geld te spaar, soek 'n geleentheid om 'n bekende kwesbaarheid reg te stel. - Cross-site scripting (XSS).
Cross-Site Scripting (XSS), of cross-site scripting, is 'n aanval op 'n webtoepassing wat daartoe lei dat wanware in die databasis ingebring word. As Qualys so 'n kwesbaarheid vind, beteken dit dat 'n potensiële aanvaller sy eie js-skrip in die werfkode kan of reeds ingevoer het om kwaadwillige aksies uit te voer.Gebergte XSS gevaarliker, aangesien die skrip op die bediener ingebed is en uitgevoer word elke keer as die aangeval bladsy in die blaaier oopgemaak word.
Gereflekteer XSS makliker om uit te voer aangesien 'n kwaadwillige skrif in 'n HTTP-versoek ingespuit kan word. Die toepassing sal 'n HTTP-versoek ontvang, sal nie die data valideer nie, sal dit verpak en dadelik stuur. As 'n aanvaller verkeer onderskep en 'n skrif invoeg soos
<script>/*+что+то+плохое+*/</script>dan sal 'n kwaadwillige versoek namens die kliënt gestuur word.
'n Treffende voorbeeld van XSS: js-snuffels wat bladsye simuleer vir die invoer van CVC, kaartvervaldatum, ensovoorts.
Wat 'n webontwikkelaar moet onthou: Gebruik die script-src-kenmerk in die Content-Security-Policy-kopskrif om die kliëntblaaier te dwing om slegs kode van 'n vertroude bron af te laai en uit te voer. Byvoorbeeld, script-src 'self' witlys net alle skrifte vanaf ons webwerf.
Die beste praktyk is inlyn-kode: laat slegs inlyn-javascript toe deur die onveilige-inlyn-waarde te gebruik. Hierdie waarde laat die gebruik van inline js/css toe, maar verbied nie die insluiting van js-lêers nie. In kombinasie met script-src 'self' skakel ons eksterne skrifte uit om uitgevoer te word.Maak seker dat jy alles aanteken met behulp van report-uri en kyk na pogings om dit op die webwerf te implementeer.
- SQL-inspuitings.
Die kwesbaarheid dui op die moontlikheid om SQL-kode in 'n webwerf in te spuit wat direk toegang tot die webwerf se databasis verkry. SQL-inspuiting is moontlik as data van die gebruiker nie gekeur word nie: dit word nie gekontroleer vir korrektheid nie en word dadelik in die navraag gebruik. Dit gebeur byvoorbeeld as 'n vorm op 'n webwerf nie kyk of die invoer ooreenstem met die datatipe nie.Wat is gevaarlik: As 'n aanvaller 'n SQL-navraag in hierdie vorm invoer, kan hy die databasis laat crash of vertroulike inligting openbaar.
Wat 'n webontwikkelaar moet onthou: Moenie vertrou wat van die blaaier af kom nie. U moet uself aan beide die kliëntkant en die bedienerkant beskerm.
Aan die kliëntkant, skryf veldvalidering met JavaScript.
Ingeboude funksies in gewilde raamwerke help ook om verdagte karakters op die bediener te ontsnap. Dit word ook aanbeveel om geparameteriseerde databasisnavrae op die bediener te gebruik.
Bepaal waar presies die interaksie met die databasis op die webtoepassing plaasvind.
Interaksie vind plaas wanneer ons enige inligting ontvang: 'n versoek met 'n id (verandering van id), die skep van 'n nuwe gebruiker, 'n nuwe opmerking of nuwe inskrywings in die databasis. Dit is waar SQL-inspuitings kan plaasvind. Selfs as ons 'n rekord uit die databasis verwyder, is SQL-inspuiting moontlik.
Algemene aanbevelings
Moenie die wiel herontdek nie – gebruik bewese raamwerke. As 'n reël is gewilde raamwerke veiliger. Vir .NET - ASP.NET MVC en ASP.NET Core, vir Python - Django of Flask, vir Ruby - Ruby on Rails, vir PHP - Symfony, Laravel, Yii, vir JavaScript - Node.JS-Express.js, vir Java - Lente MVC.
Volg verskafferopdaterings en werk gereeld op. Hulle sal 'n kwesbaarheid vind, dan 'n uitbuiting skryf, dit publiek beskikbaar stel, en alles sal weer gebeur. Teken in op opdaterings van stabiele weergawes van die sagtewareverskaffer.
Gaan toegangsregte na. Aan die bedienerkant, hanteer altyd jou kode asof dit, van die eerste tot die laaste letter, geskryf is deur jou mees gehate vyand, wat jou werf wil breek, die integriteit van jou data skend. Boonop is dit soms waar.
Gebruik klone, toetswebwerwe en gebruik dit dan vir produksie. Dit sal eerstens help om foute en foute in 'n produktiewe omgewing te vermy: 'n produktiewe omgewing bring geld, 'n eenvoudige produktiewe omgewing is van kritieke belang. Wanneer u enige probleem byvoeg, regmaak of toemaak, is dit die moeite werd om in 'n toetsomgewing te werk, dan die funksionaliteit en kwesbaarhede wat gevind word na te gaan, en dan te beplan om met die produksie-omgewing te werk.
Beskerm jou webtoepassing met en integreer verslae van die kwesbaarheidskandeerder daarmee. DataLine gebruik byvoorbeeld Qualys en FortiWeb as 'n bondel dienste.
Bron: will.com