Štruktúra hromadne vyrábaného CMS je bezpečnostné riziko

Ostatný, článok som končil malou výzvou, ktorá evidentne zaujala. Tak to trochu dnes rozvediem.Tá výzva znela:

Ako správneho audítora ma samozrejme napadla jedna zaujímavá úloha: Zistite, koľko eShopov má priamo prístupný xml súbor v ktorom informujú rôzne tovarové katalógy o svojom sortimente. Nie je nad to dať k dispozícii svoj každotýždenne aktualizovaný cenník v štrukturovanej podobe do rúk konkurencie. Že neviete čo s ním? Trendy, nie absolútne čísla sú zaujímavé.

Ako v komentári poznamenal Bystro, zásadné je, že musí ísť v prvom rade o hromadne vyrábaný systém. Individuálne, na mieru postavený systém týmto netrpí. Teda ak vývojár vo všetkých svojich systémoch nepoužíva na pomenovanie súboru so skriptami na generovanie pätičky webu názov footer.php ;-), alebo nepodľahol prispôsobeniu sa pseudoštandardom v umiestňovaní súborov. To len aby som naznačil cestu kadiaľ sa vydať. Ale vráťme sa k hromadne vyrábaným systémom.

V tomto prípade je štruktúra všetkých súborov rovnaká a je vysoko pravdepodobné, že všetky inštalácie takéhoto hromadne vyrábaného systému budú podobné ako vajce vajcu. Dám pre názornosť príklad: Všetky inštalácie WordPress poskytujú RSS kanál na adrese www.example.com/feed/ Ak sa niektorý majiteľ blogu rozhodne, že neposkytne verejne svoje RSS a stiahne všetky odkazy na RSS súbor z verejnej časti webu, stále je tu možnosť zadať priamo do adresného riadka URL adresu www.example.com/feed/ a s vysokou pravdepodobnosťou sa zobrazí RSS toho blogu napriek tomu, že blogér sa snažil ho neposkytovať. (Túto fintu štandardne používam, keď chcem odoberať komentáre, pretože odkaz na RSS komentárov (webu alebo článku) často chýba.)

Jedna ochrana je vymazať aj php súbory, ktoré obsahujú skripty na generovanie RSS kanálov z inštalácie WordPressu. Druhá možnosť je, tak ako bolo naznačené v predchádzajúcom článku, zamedziť prístup do daného adresára pomocou súboru .htaccess (formou presmerovania, zaheslovania, čohokoľvek rozumného).

A ako je to s tými xml súbormi pre rôzne produktové katalógy? Nuž, aby daný katalóg mohol zobrazovať vo svojich výsledkoch vyhľadávania moje produkty aj s cenami aj fotkami aj s popiskami, musí si pre tieto dáta pravidelne ku mne chodiť jeho robot. Takže na dohodnutom mieste musí byť k dispozícii súbor (nazvime ho cennik.xml) vo formáte, ktorý dokáže ten robot analyzovať. Ďalej nebudem v rozvíjaní pokračovať, pretože je to už rovnaké ako v horeuvedenom príklade s RSS. Len dodám, že v tomto prípade sú na tom veľmi podobne hromadne vyrábané ako aj individuálne vyrábané systémy. Spája ich práve zraniteľné miesto reprezentované frázou na dohodnutom mieste.

Myslíte, že aj v prípade RSS je to len taká sranda? Predstavte si, že na poskytovanie RSS kanála používate službu feedburner.com, aby ste svojim inzerentom vedeli vyčísliť počet odberateľ a teda inzertný dosah. A platbu máte dohodnutú progresívne podľa ich počtu. Ak si niekto do svojej RSS čítačky zadá priamu adresu www.example.com/feed/ nebude do štatistík feedburner.com zarátaný, nedostanete za neho peniaze…

Keď sme pri tých RSS štatistikách, bavím sa pravidelne, keď linkujem vo svojom celulózovom výluhu smerom na server medialne.sk Tomáš to vyriešil elegantne a to tak, že každé URL v RSS kanále má na konci /RSS/ Samozrejme netuším, ako to interne vyhodnocujú, ale minimálne moje odkazy nie sú z RSS čítačky. Ale o tom som už písal. Uvádzam to len ako súvislosť.

Tento príklad ukazuje ešte na jednu výzvu. A tou je chyba merania pomocou parametrov v URL. Ak zmena URL nezmení cieľ kam sa dostanem, je len otázka času, kedy si s URL začnú užívatelia pohrávať. Známy je tým server www.sme.sk, ktorý má URL adresy v tvare www.sme.sk/IDčlánku/čokoľvek-čo-vás-napadne. Pre vyšperkovaný (o úpravu anchor textu) príklad netreba chodiť ďaleko: Zdravotné sestry zarábajú milióny (pred kliknutím sledujte aj URL adresu)

Takže to uzavrieme

Kvalitne nainštalovaný hromadne vyrábaný systém by mal mať ošetrené maximum možností parazitného priameho prístupu do adresárovej štruktúry. Treba sa vždy zamyslieť čo je pre chod webu skutočne dôležité, aby bolo prístupné z verejnej zóny internetu. A do tretice: Po inštalácii paranoidne všetko zakázať a povoliť prístup len tam, kde je to pre návštevníka potrebné. Pre objednávateľa platí: Pýtajte sa, ako je zabezpečený priamy prístup k súborom admin sekcie, k individuálne poskytovaným pracovným súborom (napríklad pre cenníky pre špecializované katalógy) z verejnej zóny internetu.

Ide o zabezpečenie systému pred nepovolaným prístupom zvonku, takže platí aj všeobecné pravidlo: Náklady na ochranu musia byť primerané cene chráneného predmetu a hodnote potenciálnych strát.

Súvisiace:
Utajovať alebo publikovať svoje štrukturované dáta?
Zdieľať?

3 komentáre pri “Štruktúra hromadne vyrábaného CMS je bezpečnostné riziko

  1. u hromadnych CMS je to otazka predstavivosti tvorcu.

    ak si on povie, ze http://www.example.org/feed.php je dobre pre vsetkych, tak uz je to zle :-)

    vsetky taketo stycne body, ktore interaguju s citatelmi, strojmi z vonku atd. by mali byt do sirokej miery modifikovatelne.

    napr. len z dovodu, ze ja ako byvaly majitel ineho CMS nechcem menit RSS odkazy, tak novy CMS musi vediet elegantne preklenut tento problem.

    Co sa tyka nasosiek pre data v strukturovanej forme, je az nevyhnutne, aby sa to dalo individualizovat do tej miery, aby sa nedal pouzity system spoznat.

    blbym prikladom je napr. BUXUS. Ten uz spozna podla roznych priznakov ktokolvek, kto sa trosku posnazi.

    A pokial ho zrovna neobalis nejakym externym prekladom URL adries, tak zrejme ten system sam seba moc nemaskuje. Nehovoriac o tom, ze tento plateny(!!!) system maju cudzie weby linkovany v footeri ako keby slo pomaly o freeware :-)
    Buxus som spomenul preto, lebo je velmi rozsireny (inak ziadny iny zamer nemam).

Komentáre sú uzavreté.