Dauðasyndir öryggis vefsíðna: það sem við lærðum af tölfræði um varnarleysisskanna fyrir árið

Fyrir um ári síðan hófum við hjá DataLine þjónustu að leita og greina veikleika í upplýsingatækniforritum. Þjónustan byggir á Qualys skýjalausninni, um rekstur hennar við sögðum þegar. Á árinu sem við unnum með lausnina gerðum við 291 skönnun fyrir mismunandi síður og söfnuðum tölfræði um algenga veikleika í vefforritum. 

Í greininni hér að neðan mun ég sýna þér nákvæmlega hvaða holur í öryggi vefsíðna eru falin á bak við mismunandi stig gagnrýni. Við skulum sjá hvaða veikleika skanninn fann sérstaklega oft, hvers vegna þeir gætu átt sér stað og hvernig á að vernda þig. 

Qualys skiptir öllum veikleikum vefforrita í þrjú gagnrýnistig: lágt, miðlungs og hátt. Ef þú skoðar dreifinguna eftir „alvarleika“ virðist sem allt sé ekki svo slæmt. Það eru fáir veikleikar með mikla gagnrýni, aðallega allir ekki mikilvægir: 

En gagnrýnislaust þýðir ekki skaðlaust. Þeir geta einnig valdið alvarlegum skaða. 

Helstu „ekki mikilvægir“ veikleikar

1. Varnarleysi í blandað efni.

   Staðall fyrir öryggi vefsíðna er flutningur gagna á milli biðlara og netþjóns í gegnum HTTPS samskiptareglur, sem styður dulkóðun og verndar upplýsingar gegn hlerun. 

   Sumar síður nota blandað efni: Sum gögn eru flutt í gegnum óörugga HTTP samskiptareglur. Þannig er það oftast komið á framfæri óvirkt efni – upplýsingar sem hafa aðeins áhrif á birtingu síðunnar: myndir, css stíll. En stundum er þetta hvernig það er sent virkt efni: forskriftir sem stjórna hegðun síðunnar. Í þessu tilviki, með því að nota sérstakan hugbúnað, geturðu greint upplýsingar með virku efni sem kemur frá netþjóninum, breytt svörum þínum í skyndi og látið vélina virka á þann hátt sem höfundar hennar höfðu ekki ætlað sér. 

   Nýrri útgáfur vafra vara notendur við því að síður með blönduðu efni séu óöruggar og loka fyrir efnið. Hönnuðir vefsíðna fá einnig vafraviðvaranir í stjórnborðinu. Til dæmis, svona lítur það út inni Firefox: 

   
   
   Af hverju er það hættulegt?: Árásarmenn nota óörugga siðareglur til að stöðva notendaupplýsingar, skipta um forskriftir og senda beiðnir á síðuna fyrir hans hönd. Jafnvel þó að gestur síðunnar hafi ekki slegið inn gögn verndar það hann ekki fyrir vefveiðar - afla trúnaðarupplýsinga með sviksamlegum aðferðum. Til dæmis, með því að nota skriftu, geturðu vísað notandanum á óörugga síðu sem líkist því að notandinn þekki. Í sumum tilfellum lítur illgjarn síða jafnvel betur út en upprunalega og notandinn getur sjálfur fyllt út eyðublaðið og sent inn trúnaðargögn. 

   Það sem vefhönnuður ætti að muna: Jafnvel þótt umsjónarmaður vefsvæðisins hafi sett upp og stillt SSL/TLS vottorð getur varnarleysi komið upp vegna mannlegra mistaka. Til dæmis, ef þú setur ekki afstæðan hlekk á einni af síðunum, heldur algeran hlekk frá http, og að auki settir þú ekki upp tilvísanir frá http til https. 

   Þú getur greint blandað efni á vefsvæði með vafra: leitaðu í frumkóða síðunnar, lestu tilkynningar í stjórnborði þróunaraðila. Hins vegar mun verktaki þurfa að fikta við kóðann í langan tíma og leiðinlega. Þú getur flýtt fyrir ferlinu með sjálfvirkum greiningartækjum, til dæmis: SSL stöðva, ókeypis Lighthouse hugbúnaður eða greiddur hugbúnaður Screaming Frog SEO Spider.

   Einnig gæti varnarleysið komið upp vegna vandamála með eldri kóða - kóða sem var arfur. Til dæmis, ef sumar síður eru búnar til með gömlu sniðmáti, sem tekur ekki tillit til breytinga á síðum yfir á https.    

2. Vafrakökur án „HTTPOnly“ og „Secure“ fánanna.

   „HTTPOnly“ eigindin verndar vafrakökur frá því að vera unnin af forskriftum sem árásarmenn nota til að stela notendagögnum. „Secure“ fáninn leyfir ekki að vafrakökur séu sendar í skýrum texta. Samskipti verða aðeins leyfð ef örugg HTTPS samskiptaregla er notuð til að senda vafrakökur. 

   Báðar eiginleikar eru tilgreindir í eiginleikum vafraköku:

   Set-Cookie: Secure; HttpOnly

   Af hverju er það hættulegt?: Ef verktaki vefsvæðisins tilgreindi ekki þessa eiginleika gæti árásarmaður stöðvað upplýsingar notandans úr vafrakökunni og nýtt þær. Ef vafrakökur eru notaðar til auðkenningar og heimildar mun hann geta rænt setu notandans og framkvæmt aðgerðir á síðunni fyrir hans hönd. 

   Það sem vefhönnuður ætti að muna: Að jafnaði eru þessir eiginleikar stilltir sjálfkrafa í vinsælum ramma. En athugaðu samt stillingar vefþjónsins og stilltu fánann: Set-Cookie HttpOnly; Öruggt.

   Í þessu tilviki mun „HTTPOnly“ eigindin gera vafrakökur ósýnilegar fyrir eigin JavaScript.  

3. Veitir sem byggjast á veikleikum.

   Skannarinn tilkynnir um slíkan varnarleysi ef hann finnur opinbera skrá eða vefsíðuskrá með hugsanlega trúnaðarupplýsingum. Til dæmis greinir það einstakar kerfisstillingarskrár eða aðgang að öllu skráarkerfinu. Þetta ástand er mögulegt ef aðgangsréttur er rangt stilltur á síðunni.

   Af hverju er það hættulegt?: Ef skráarkerfið „stafur út“ getur árásarmaður dottið inn í stýrikerfisviðmótið og reynt að finna möppur með lykilorðum ef þær eru geymdar í skýrum texta (ekki gera það!). Eða þú getur stolið lykilorði og þvingað lykilorðið og reynt að hækka réttindi í kerfinu og fara dýpra inn í innviðina.  

   Það sem vefhönnuður ætti að muna: Ekki gleyma aðgangsréttindum og stilla vettvang, vefþjón, vefforrit þannig að ómögulegt sé að „sleppa“ vefskránni.

4. Eyðublöð til að slá inn viðkvæm gögn með sjálfvirkri útfyllingu virkt.

   Ef notandi fyllir oft út eyðublöð á vefsíðum geymir vafrinn þessar upplýsingar með því að nota sjálfvirka útfyllingareiginleikann. 

   Eyðublöð á vefsíðum geta innihaldið reiti með viðkvæmum upplýsingum, svo sem lykilorðum eða kreditkortanúmerum. Fyrir slíka reiti er þess virði að slökkva á sjálfvirkri útfyllingu eyðublaðs á síðunni sjálfri. 

   Af hverju er það hættulegt?: Ef vafri notandans geymir viðkvæmar upplýsingar getur árásarmaður stöðvað þær síðar, til dæmis með vefveiðum. Í raun er vefhönnuður sem hefur gleymt þessum blæbrigði að setja upp notendur sína. 

   Það sem vefhönnuður ætti að muna: Í þessu tilfelli erum við með klassíska átök: þægindi vs öryggi. Ef vefhönnuður er að hugsa um notendaupplifun getur hann meðvitað valið sjálfvirka útfyllingu. Til dæmis ef það er mikilvægt að fylgja Leiðbeiningar um aðgengi að vefi – ráðleggingar um aðgengi að efni fyrir notendur með fötlun. 

   Fyrir flesta vafra geturðu slökkt á sjálfvirkri útfyllingu með eigindinni autocompete="off", til dæmis:

    <body>
       <form action="/is/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>

   En það mun ekki virka fyrir Chrome. Þetta er sniðgengið með JavaScript, afbrigði af uppskriftinni er að finna hér. 

5. X-Frame-Options hausinn er ekki stilltur í kóða vefsvæðisins. 

   Þessi haus hefur áhrif á ramma-, iframe-, embed- eða hlutmerkingar. Með hjálp þess geturðu algjörlega bannað að fella síðuna þína inn í ramma. Til að gera þetta þarftu að tilgreina gildið X-Frame-Options: deny. Eða þú getur tilgreint X-Frame-Options: sameorigin, þá verður innfelling í iframe aðeins í boði á léninu þínu.

   Af hverju er það hættulegt?: Skortur á slíkum haus er hægt að nota á skaðlegum síðum til að clickjacking. Fyrir þessa árás býr árásarmaðurinn til gagnsæjan ramma ofan á hnappana og platar notandann. Til dæmis: svindlarar ramma inn samfélagsmiðlasíður á vefsíðu. Notandinn heldur að hann sé að smella á hnapp á þessari síðu. Þess í stað er smellurinn hleraður og beiðni notandans er send á samfélagsnetið þar sem er virk lota. Þetta er hvernig árásarmenn senda ruslpóst fyrir hönd notandans eða fá áskrifendur og líkar við. 

   Ef þú slökktir ekki á þessum eiginleika getur árásarmaður sett forritahnappinn þinn á illgjarna síðu. Hann gæti haft áhuga á tilvísunarforritinu þínu eða notendum þínum.  

   Það sem vefhönnuður ætti að muna: Varnarleysið getur komið fram ef X-Frame-Options með andstæða gildi er stillt á vefþjóninum eða álagsjafnvægi. Í þessu tilviki munu þjónninn og jafnvægismaðurinn einfaldlega endurskrifa hausinn, þar sem þeir hafa meiri forgang miðað við bakendakóðann.  

   Afneitun og sama upprunagildi X-Frame-Options haussins munu trufla virkni Yandex vefskoðarans. Til að leyfa notkun á iframes fyrir vefskoðarann ​​þarftu að skrifa sérstaka reglu í stillingarnar. Til dæmis, fyrir nginx geturðu stillt það svona:

   http{
   ...
    map $http_referer $frame_options {
    "~webvisor.com" "ALLOW-FROM http://webvisor.com";
    default "SAMEORIGIN";
    }
    add_header X-Frame-Options $frame_options;
   ...
   }
   
   

6. PRSSI (Path-relative stylesheet import) varnarleysi.  

   Þetta er varnarleysi í stíl síðunnar. Það gerist ef afstæðir hlekkir eins og href="/is/somefolder/styles.css/" eru notaðir til að fá aðgang að stílskrám. Árásarmaður mun nýta sér þetta ef hann finnur leið til að beina notandanum á illgjarna síðu. Síðan mun setja hlutfallslegan hlekk inn í vefslóðina sína og líkja eftir stílkalli. Þú munt fá beiðni eins og badsite.ru/…/somefolder/styles.css/, sem getur framkvæmt illgjarnar aðgerðir í skjóli stíls. 

   Af hverju er það hættulegt?: Svikari gæti nýtt sér þennan varnarleysi ef hann finnur annað öryggisgat. Fyrir vikið er hægt að stela notendagögnum úr vafrakökum eða táknum.

   Það sem vefhönnuður ætti að muna: Stilltu X-Content-Type-Options hausinn á: nosniff. Í þessu tilviki mun vafrinn athuga innihaldsgerðina fyrir stílana. Ef tegundin er önnur en texti/css mun vafrinn loka fyrir beiðnina.

Mikilvægar veikleikar

1. Síða með lykilorðareit er send frá þjóninum yfir óörugga rás (HTML eyðublað sem inniheldur lykilorðareit(a) er þjónað yfir HTTP).

   Viðbrögð þjónsins yfir ódulkóðaðri rás eru viðkvæm fyrir „Maður í miðjunni“ árásum. Árásarmaður getur stöðvað umferð og fleygt sig á milli biðlarans og netþjónsins þegar síðan fer frá þjóninum til biðlarans. 

   Af hverju er það hættulegt?: Svindlarinn mun geta skipt út síðunni og sent notandanum eyðublað fyrir trúnaðargögn sem fara á netþjón árásarmannsins. 

   Það sem vefhönnuður ætti að muna: Sumar síður senda notendum einskiptiskóða með tölvupósti/síma í stað lykilorðs. Í þessu tilviki er varnarleysið ekki svo mikilvægt, en vélbúnaðurinn mun flækja líf notenda.

2. Að senda eyðublað með notandanafni og lykilorði yfir óörugga rás (innskráningareyðublað er ekki sent í gegnum HTTPS).

   Í þessu tilviki er eyðublað með notandanafn og lykilorði sent frá notandanum til netþjónsins í gegnum ódulkóðaða rás.

   Af hverju er það hættulegt?: Ólíkt fyrra tilvikinu er þetta nú þegar mikilvægur varnarleysi. Það er auðveldara að stöðva viðkvæm gögn vegna þess að þú þarft ekki einu sinni að skrifa kóða til að gera það. 

3. Notkun JavaScript bókasöfn með þekktum veikleikum.

   Við skönnunina var mest notaða bókasafnið jQuery með miklum fjölda útgáfur. Hver útgáfa hefur að minnsta kosti einn, eða jafnvel fleiri, þekkta veikleika. Áhrifin geta verið mjög mismunandi eftir eðli veikleikans.

   Af hverju er það hættulegt?: Það eru hetjudáðir fyrir þekkta veikleika, til dæmis:

   
   
   Það sem vefhönnuður ætti að muna: Farðu reglulega aftur í hringrásina: leitaðu að þekktum veikleikum - laga - athugaðu. Ef þú notar eldri bókasöfn af ásettu ráði, til dæmis til að styðja við eldri vafra eða til að spara peninga, skaltu leita að tækifæri til að laga þekktan varnarleysi. 

4. Cross-site scripting (XSS). 
   Cross-Site Scripting (XSS), eða cross-site scripting, er árás á vefforrit sem leiðir til þess að spilliforrit er komið inn í gagnagrunninn. Ef Qualys finnur slíkan varnarleysi þýðir það að hugsanlegur árásarmaður getur eða hefur þegar sett sitt eigið js forskrift inn í kóðann á vefsvæðinu til að framkvæma illgjarnar aðgerðir.

   Geymt XSS hættulegra, þar sem handritið er innbyggt á þjóninn og keyrt í hvert sinn sem árásarsíðan er opnuð í vafranum.

   Endurspeglað XSS auðveldara í framkvæmd þar sem illgjarnt handrit er hægt að sprauta inn í HTTP beiðni. Forritið mun fá HTTP beiðni, mun ekki staðfesta gögnin, pakka þeim og senda þau strax. Ef árásarmaður stöðvar umferð og setur inn skriftu eins og

   <script>/*+что+то+плохое+*/</script> 

   þá verður illgjarn beiðni send fyrir hönd viðskiptavinarins.

   Sláandi dæmi um XSS: js sniffers sem líkja eftir síðum til að slá inn CVC, gildistíma korts og svo framvegis. 

   Það sem vefhönnuður ætti að muna: Í Content-Security-Policy hausnum, notaðu script-src eigindina til að þvinga biðlara vafra til að hlaða niður og keyra kóða frá traustum uppruna. Til dæmis, script-src 'self' hvítlistar eingöngu öll forskriftir frá síðunni okkar. 
   Besta aðferðin er innbyggður kóði: leyfðu aðeins innbyggðu javascript með því að nota óörugga innbyggða gildið. Þetta gildi leyfir notkun á inline js/css, en bannar ekki að js skrár séu teknar með. Í samsettri meðferð með script-src 'self' slökkum við á að ytri skriftur verði keyrðar.

   Vertu viss um að skrá allt með report-uri og skoðaðu tilraunir til að innleiða það inn á síðuna.

5. SQL innspýting.
   Varnarleysið gefur til kynna möguleikann á að sprauta SQL kóða inn á vefsíðu sem fer beint inn í gagnagrunn vefsíðunnar. SQL innspýting er möguleg ef gögn frá notanda eru ekki skimuð: ekki er athugað hvort þau séu rétt og þau eru notuð strax í fyrirspurninni. Þetta gerist til dæmis ef eyðublað á vefsíðu athugar ekki hvort inntakið passi við gagnagerðina. 

   Af hverju er það hættulegt?: Ef árásarmaður slær inn SQL fyrirspurn á þetta form getur hann hrundið gagnagrunninum eða afhjúpað trúnaðarupplýsingar. 

   Það sem vefhönnuður ætti að muna: Treystu ekki því sem kemur úr vafranum. Þú þarft að vernda þig bæði á biðlarahlið og miðlarahlið. 

   Skrifaðu staðfestingu á reitnum á viðskiptavininum með JavaScript. 

   Innbyggðar aðgerðir í vinsælum ramma hjálpa einnig til við að komast undan grunsamlegum persónum á þjóninum. Einnig er mælt með því að nota gagnagrunnsfyrirspurnir með færibreytum á þjóninum.

   Ákveðið hvar nákvæmlega samskiptin við gagnagrunninn eiga sér stað á vefforritinu. 

   Samskipti eiga sér stað þegar við fáum einhverjar upplýsingar: beiðni með auðkenni (breyting á auðkenni), stofnun nýs notanda, ný athugasemd eða nýjar færslur í gagnagrunninum. Þetta er þar sem SQL innspýting getur átt sér stað. Jafnvel þótt við eyðum skrá úr gagnagrunninum er SQL innspýting möguleg.

Almennar tillögur

Ekki finna upp hjólið aftur - notaðu sannaða ramma. Að jafnaði eru vinsælar rammar öruggari. Fyrir .NET - ASP.NET MVC og ASP.NET Core, fyrir Python - Django eða Flask, fyrir Ruby - Ruby on Rails, fyrir PHP - Symfony, Laravel, Yii, fyrir JavaScript - Node.JS-Express.js, fyrir Java - Vor MVC.

Fylgstu með uppfærslum söluaðila og uppfærðu reglulega. Þeir munu finna varnarleysi, skrifa síðan hetjudáð, gera það aðgengilegt opinberlega og allt mun gerast aftur. Gerast áskrifandi að uppfærslum á stöðugum útgáfum frá hugbúnaðarframleiðandanum.

Athugaðu aðgangsrétt. Á netþjónahliðinni skaltu alltaf meðhöndla kóðann þinn eins og hann, frá fyrsta til síðasta staf, hafi verið skrifaður af hataðasta óvini þínum, sem vill brjóta síðuna þína, brjóta í bága við heilleika gagna þinna. Þar að auki, stundum er þetta satt.

Notaðu klóna, prófunarsíður og notaðu þá til framleiðslu. Þetta mun í fyrsta lagi hjálpa til við að forðast mistök og mistök í afkastamiklu umhverfi: afkastamikið umhverfi færir peninga, einfalt framleiðsluumhverfi er mikilvægt. Þegar einhver vandamál er bætt við, lagað eða lokað er þess virði að vinna í prófunarumhverfi, athuga síðan virknina og veikleikana sem finnast og ætla síðan að vinna með framleiðsluumhverfið. 

Verndaðu vefforritið þitt með Vefur eldvegg og samþætta skýrslur frá varnarleysisskannanum við það. Til dæmis notar DataLine Qualys og FortiWeb sem þjónustubúnt.

Heimild: www.habr.com