Antaŭ proksimume jaro, ni ĉe DataLine lanĉis serĉi kaj analizi vundeblecojn en IT-aplikoj. La servo baziĝas sur la nuba solvo Qualys, pri kies funkciado . Dum unu jaro da laborado kun la solvo, ni faris 291 skanadon por malsamaj retejoj kaj amasigis statistikojn pri oftaj vundeblecoj en TTT-aplikoj.
En la suba artikolo mi montros al vi precize, kiaj truoj en retejo-sekureco estas kaŝitaj malantaŭ malsamaj niveloj de kritiko. Ni vidu kiajn vundeblecojn la skanilo trovis precipe ofte, kial ili povus okazi kaj kiel protekti vin.
Qualys dividas ĉiujn vundeblecojn de TTT-aplikaĵoj en tri nivelojn de kritiko: malalta, meza kaj alta. Se vi rigardas la distribuon laŭ "graveco", ŝajnas, ke ĉio ne estas tiel malbona. Estas malmultaj vundeblecoj kun alta nivelo de kritiko, plejparte ĉiuj estas ne-kritikaj:
Sed senkritika ne signifas sendanĝera. Ili ankaŭ povas kaŭzi gravan damaĝon.
Ĉefaj "ne-kritikaj" vundeblecoj
- Miksaj enhavaj vundeblecoj.
La normo por reteja sekureco estas la translokigo de datumoj inter la kliento kaj la servilo per la HTTPS-protokolo, kiu subtenas ĉifradon kaj protektas informojn kontraŭ interkapto.
Iuj retejoj uzas miksita enhavo: Iuj datumoj estas transdonitaj per la nesekura HTTP-protokolo. Tiel oni plej ofte transdonas ĝin pasiva enhavo – informoj, kiuj influas nur la montradon de la retejo: bildoj, css-stiloj. Sed foje jen kiel ĝi estas transdonita aktiva enhavo: skriptoj kiuj kontrolas la konduton de la retejo. En ĉi tiu kazo, uzante specialan programaron, vi povas analizi informojn kun aktiva enhavo venanta de la servilo, modifi viajn respondojn sur la flugo kaj igi la maŝinon funkcii en maniero ne celita de ĝiaj kreintoj.
Pli novaj versioj de retumiloj avertas uzantojn, ke retejoj kun miksita enhavo estas nesekuraj kaj blokas la enhavon. Retejaj programistoj ankaŭ ricevas retumilavertojn en la konzolo. Ekzemple, jen kiel ĝi aspektas :
Kio estas danĝera: Atakantoj uzas nesekuran protokolon por kapti uzantajn informojn, anstataŭigi skriptojn kaj sendi petojn al la retejo en lia nomo. Eĉ se vizitanto de la retejo ne enigis datumojn, ĉi tio ne protektas lin kontraŭ phishing – akiri konfidencajn informojn per fraŭdaj metodoj. Ekzemple, uzante skripton, vi povas redirekti la uzanton al nesekura retejo kiu maskas kiel konata al la uzanto. En iuj kazoj, la malica retejo aspektas eĉ pli bona ol la originalo, kaj la uzanto povas mem plenigi la formularon kaj sendi konfidencajn datumojn.Kion retejo-programisto devus memori: Eĉ se la administranto de la retejo instalis kaj agordis SSL/TLS-atestilon, vundebleco povas aperi pro homa eraro. Ekzemple, se en unu el la paĝoj oni metas ne relativan ligilon, sed absolutan ligilon de http, kaj krome oni ne starigis alidirektilojn de http al https.
Vi povas detekti miksitan enhavon en retejo per retumilo: serĉu la fontkodon de la paĝo, legu sciigojn en la programista konzolo. Tamen, la programisto devos tuŝi la kodon dum longa tempo kaj tede. Vi povas akceli la procezon per aŭtomataj analizaj iloj, ekzemple: , senpaga Lighthouse-programaro aŭ pagita programaro Screaming Frog SEO Spider.
Ankaŭ, la vundebleco povas ekesti pro problemoj kun hereda kodo - kodo heredita. Ekzemple, se iuj paĝoj estas generitaj per malnova ŝablono, kiu ne konsideras la transiron de retejoj al https.
- Kuketoj sen la flagoj "HTTPOnly" kaj "sekura".
La atributo "HTTPOnly" protektas kuketojn kontraŭ traktado de skriptoj, kiujn atakantoj uzas por ŝteli uzantdatenojn. La "sekura" flago ne permesas ke kuketoj estu senditaj en klara teksto. Komunikado nur estos permesita se la sekura HTTPS-protokolo estas uzata por sendi kuketojn.
Ambaŭ atributoj estas specifitaj en la kuketaj propraĵoj:
Set-Cookie: Secure; HttpOnlyKio estas danĝera: Se la retejo-programisto ne specifis ĉi tiujn atributojn, atakanto povus kapti la informojn de la uzanto de la kuketo kaj ekspluati ĝin. Se kuketoj estas uzataj por aŭtentigo kaj rajtigo, li povos kaperi la seancon de la uzanto kaj fari agojn en la retejo en lia nomo.
Kion retejo-programisto devus memori: Kiel regulo, en popularaj kadroj ĉi tiuj atributoj estas aŭtomate fiksitaj. Sed ankoraŭ kontrolu la agordon de la retservilo kaj agordu la flagon: Set-Cookie HttpOnly; Sekura.
En ĉi tiu kazo, la atributo "HTTPOnly" faros kuketojn nevideblaj por via propra JavaScript.
- Voje-Bazitaj Vundeblecoj.
La skanilo raportas tian vundeblecon se ĝi trovas publike alireblan dosieron aŭ retejan dosierujon kun eble konfidencaj informoj. Ekzemple, ĝi detektas individuajn sistemajn agordajn dosierojn aŭ aliron al la tuta dosiersistemo. Ĉi tiu situacio eblas se alirrajtoj estas malĝuste fiksitaj en la retejo.
Kio estas danĝera: Se la dosiersistemo "eltenas", atakanto povas fali en la operaciuman interfacon kaj provi trovi dosierujojn kun pasvortoj se ili estas konservitaj en klara teksto (ne faru tion!). Aŭ vi povas ŝteli pasvortajn haŝojn kaj krudforton la pasvorton, kaj ankaŭ provi levi privilegiojn en la sistemo kaj pliprofundiĝi en la infrastrukturon.
Kion retejo-programisto devus memori: Ne forgesu pri alirrajtoj kaj agordu la platformon, TTT-servilon, TTT-aplikaĵon por ke ne eblas "eskapi" la TTT-dosierujon.
- Formoj por enigi sentemajn datumojn kun aŭtomata plenigo ebligita.
Se uzanto ofte plenigas formularojn en retejoj, ilia retumilo konservas ĉi tiujn informojn uzante la aŭtomatan plenigon.
Formoj en retejoj povas inkluzivi kampojn kun sentemaj informoj, kiel pasvortoj aŭ nombroj de kreditkartoj. Por tiaj kampoj, indas malŝalti la funkcion de aŭtomata plenigo de formularo en la retejo mem.
Kio estas danĝera: Se la retumilo de la uzanto stokas sentemajn informojn, atakanto povas kapti ĝin poste, ekzemple per phishing. Esence, retejo-programisto, kiu forgesis ĉi tiun nuancon, starigas siajn uzantojn.
Kion retejo-programisto devus memori: En ĉi tiu kazo, ni havas klasikan konflikton: oportuno kontraŭ sekureco. Se retejo-programisto pensas pri sperto de uzanto, li povas konscie elekti aŭtomatan kompletigon. Ekzemple, se gravas sekvi – rekomendoj pri alirebleco de enhavo por uzantoj kun handikapoj.
Por plej multaj retumiloj, vi povas malŝalti aŭtomatan kompletigon per la atributo autocompete="off", ekzemple:
<body> <form action="/eo/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>Sed ĝi ne funkcios por Chrome. Ĉi tio estas evitita uzante JavaScript, varianto de la recepto troveblas .
- La kaplinio X-Frame-Options ne estas agordita en la retejo-kodo.
Ĉi tiu kaplinio influas kadron, iframe, enkonstrui aŭ objektotikedojn. Kun ĝia helpo, vi povas tute malpermesi enigi vian retejon en kadron. Por fari tion, vi devas specifi la valoron X-Frame-Options: deny. Aŭ vi povas specifi X-Frame-Options: sameorigin, tiam enkonstruado en iframe nur estos disponebla en via domajno.
Kio estas danĝera: La foresto de tia kaplinio povas esti uzata sur malicaj retejoj por clickjacking. Por ĉi tiu atako, la atakanto kreas travideblan kadron sur la butonoj kaj trompas la uzanton. Ekzemple: skamantoj enkadrigas sociajn retajn paĝojn en retejo. La uzanto pensas, ke li alklakas butonon en ĉi tiu retejo. Anstataŭe, la klako estas kaptita kaj la peto de la uzanto estas sendita al la socia reto kie estas aktiva sesio. Tiel atakantoj sendas spamon nome de la uzanto aŭ akiras abonantojn kaj ŝatojn.
Se vi ne malŝaltas ĉi tiun funkcion, atakanto povas meti vian aplikan butonon sur malica retejo. Li eble interesiĝas pri via plusendprogramo aŭ viaj uzantoj.
Kion retejo-programisto devus memori: La vundebleco povas okazi se X-Frame-Options kun konflikta valoro estas agordita sur la retservilo aŭ ŝarĝbalancilo. En ĉi tiu kazo, la servilo kaj ekvilibristo simple reverkos la kaplinion, ĉar ili havas pli altan prioritaton kompare kun la malantaŭa kodo.
La neaj kaj samdevenaj valoroj de la kaplinio X-Frame-Options malhelpos la funkciadon de la retspektilo Yandex. Por permesi la uzon de iframoj por la retspektilo, vi devas skribi apartan regulon en la agordoj. Ekzemple, por nginx vi povas agordi ĝin tiel:
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 stilfolio import) vundeblecoj.
Ĉi tio estas vundebleco en la stilo de la retejo. Ĝi okazas se relativaj ligiloj kiel href="/eo/somefolder/styles.css/" estas uzataj por aliri stildosierojn. Atakanto profitos tion se ili trovos manieron redirekti la uzanton al malica paĝo. La paĝo enigos relativan ligilon en sia url kaj simulos stilvokon. Vi ricevos peton kiel badsite.ru/…/somefolder/styles.css/, kiu povas fari malicajn agojn sub la aspekto de stilo.
Kio estas danĝera: Fraŭdisto povus ekspluati ĉi tiun vundeblecon se ili trovas alian sekurecan truon. Kiel rezulto, eblas ŝteli uzantajn datumojn de kuketoj aŭ ĵetonoj.
Kion retejo-programisto devus memori: Agordu la kaplinion X-Content-Type-Options al: nosniff. En ĉi tiu kazo, la retumilo kontrolos la enhavan tipon por la stiloj. Se la tipo estas alia ol teksto/css, la retumilo blokos la peton.
Kritikaj vundeblecoj
- Paĝo kun pasvortkampo estas elsendita de la servilo per nesekura kanalo (HTML-formularo enhavanta pasvortkampon(j) estas servata per HTTP).
La respondo de la servilo super neĉifrita kanalo estas vundebla al "Viro en la mezo" atakoj. Atakanto povas kapti trafikon kaj kojni sin inter la kliento kaj servilo dum la paĝo vojaĝas de la servilo al la kliento.
Kio estas danĝera: La fraŭdisto povos anstataŭigi la paĝon kaj sendi al la uzanto formularon por konfidencaj datumoj, kiu iros al la servilo de la atakanto.
Kion retejo-programisto devus memori: Iuj retejoj sendas al uzantoj unufojan kodon retpoŝte/telefone anstataŭ pasvorton. En ĉi tiu kazo, la vundebleco ne estas tiel kritika, sed la mekanismo malfaciligos la vivon de uzantoj.
- Sendante formularon kun ensaluto kaj pasvorto tra nesekura kanalo (Ensalutu Formo Ne Estas Sendita Per HTTPS).
En ĉi tiu kazo, formo kun ensaluto kaj pasvorto estas sendita de la uzanto al la servilo per neĉifrita kanalo.
Kio estas danĝera: Male al la antaŭa kazo, ĉi tio jam estas kritika vundebleco. Estas pli facile kapti sentemajn datumojn ĉar vi eĉ ne bezonas skribi kodon por fari ĝin.
- Uzante JavaScript-bibliotekojn kun konataj vundeblecoj.
Dum la skanado, la plej uzata biblioteko estis jQuery kun ampleksa nombro da versioj. Ĉiu versio havas almenaŭ unu, aŭ eĉ pli, konatajn vundeblecojn. La efiko povas esti tre malsama depende de la naturo de la vundebleco.
Kio estas danĝera: Estas ekspluatoj por konataj vundeblecoj, ekzemple:
Kion retejo-programisto devus memori: Regule revenu al la ciklo: serĉu konatajn vundeblecojn - ripari - kontroli. Se vi intence uzas heredajn bibliotekojn, ekzemple por subteni malnovajn retumiloj aŭ por ŝpari monon, serĉu ŝancon ripari konatan vundeblecon. - Interreteja skribo (XSS).
Cross-Site Scripting (XSS), aŭ trans-eja skriptado, estas atako kontraŭ TTT-aplikaĵo kiu rezultigas malbonvaron enkondukantan en la datumbazon. Se Qualys trovas tian vundeblecon, tio signifas, ke ebla atakanto povas aŭ jam enkondukis sian propran js-skripton en la retejo-kodon por fari malicajn agojn.Stokita XSS pli danĝera, ĉar la skripto estas enigita en la servilo kaj efektivigita ĉiufoje kiam la atakita paĝo estas malfermita en la retumilo.
Reflektita XSS pli facile efektivigebla ĉar malica skripto povas esti injektita en HTTP-peton. La aplikaĵo ricevos HTTP-peton, ne validigos la datumojn, pakos ĝin kaj sendos ĝin tuj. Se atakanto kaptas trafikon kaj enmetas skripton kiel
<script>/*+что+то+плохое+*/</script>tiam malica peto estos sendita nome de la kliento.
Frapa ekzemplo de XSS: js sniffers, kiuj simulas paĝojn por enigi CVC, karton eksvalidiĝo, ktp.
Kion retejo-programisto devus memori: En la kaplinio Content-Security-Policy, uzu la script-src-atributon por devigi la klientan retumilon nur elŝuti kaj ekzekuti kodon el fidinda fonto. Ekzemple, script-src 'self' listigas ĉiujn skriptojn nur de nia retejo.
La plej bona praktiko estas Enlinia kodo: nur permesu enlinian javaskripton uzante la nesekuran-enlinian valoron. Ĉi tiu valoro permesas la uzon de enlinia js/css, sed ne malpermesas la inkludon de js-dosieroj. En kombinaĵo kun script-src 'self' ni malebligas eksterajn skriptojn por esti ekzekutita.Nepre ensalutu ĉion uzante report-uri kaj rigardu provojn efektivigi ĝin en la retejon.
- SQL-injektoj.
La vundebleco indikas la eblecon injekti SQL-kodon en retejon, kiu rekte aliras la datumbazon de la retejo. SQL-injekto eblas se datumoj de la uzanto ne estas ekzamenitaj: ĝi ne estas kontrolita por ĝusteco kaj tuj estas uzata en la konsulto. Ekzemple, ĉi tio okazas se formularo en retejo ne kontrolas ĉu la enigo kongruas kun la datumtipo.Kio estas danĝera: Se atakanto enmetas SQL-demandon en ĉi tiun formularon, li povas kraŝi la datumbazon aŭ malkaŝi konfidencajn informojn.
Kion retejo-programisto devus memori: Ne fidu tion, kio venas de la retumilo. Vi devas protekti vin ambaŭ ĉe la klienta flanko kaj la servilo.
Ĉe la kliento, skribu kampan validigon per JavaScript.
Enkonstruitaj funkcioj en popularaj kadroj ankaŭ helpas eskapi suspektindajn karakterojn sur la servilo. Oni rekomendas ankaŭ uzi parametrajn datumbazajn demandojn sur la servilo.
Determini kie precize okazas la interago kun la datumbazo sur la retejo-aplikaĵo.
Interago okazas kiam ni ricevas ajnan informon: peto kun id (ŝanĝo de id), la kreado de nova uzanto, nova komento, aŭ novaj enskriboj en la datumbazo. Ĉi tie povas okazi SQL-injektoj. Eĉ se ni forigas rekordon de la datumbazo, SQL-injekto eblas.
Ĝeneralaj rekomendoj
Ne reinventu la radon - uzu provitajn kadrojn. Kiel regulo, popularaj kadroj estas pli sekuraj. Por .NET - ASP.NET MVC kaj ASP.NET Core, por Python - Django aŭ Flask, por Ruby - Ruby on Rails, por PHP - Symfony, Laravel, Yii, por JavaScript - Node.JS-Express.js, por Java - Printempa MVC.
Sekvu vendistajn ĝisdatigojn kaj ĝisdatigu regule. Ili trovos vundeblecon, poste skribos ekspluatadon, disponigos ĝin publike, kaj ĉio denove okazos. Abonu ĝisdatigojn al stabilaj versioj de la softvarvendisto.
Kontrolu alirrajtojn. Ĉe la servilo, ĉiam traktu vian kodon kvazaŭ ĝi, de la unua ĝis la lasta letero, estis skribita de via plej malamata malamiko, kiu volas rompi vian retejon, malobservi la integrecon de viaj datumoj. Krome, foje ĉi tio estas vera.
Uzu klonojn, testejojn, kaj poste uzu ilin por produktado. Ĉi tio helpos, unue, eviti erarojn kaj erarojn en produktiva medio: produktiva medio alportas monon, simpla produktiva medio estas kritika. Aldonante, riparante aŭ fermante ajnan problemon, indas labori en testa medio, poste kontroli la funkciecon kaj vundeblecojn trovitajn, kaj poste plani labori kun la produktadmedio.
Protektu vian TTT-aplikaĵon per kaj integri raportojn de la vundebleco skanilo kun ĝi. Ekzemple, DataLine uzas Qualys kaj FortiWeb kiel pakaĵon de servoj.
fonto: www.habr.com