Pokračovat ve čtení »]]> Jedná se o MVC aplikaci napsanou v PHP 5.3

Použil jsem Zend Framework 1 a to zejména z důvodu dobré dostupnosti dokumentace a literatury. Další aplikace ale už budu raději vyvíjet v nette nebo jiném frameworku, neboť u Zend-u jsem narazil na dost nečekané a otravné limity zejména v oblasti spolupráce s Ajax, jquery, přizpůsobení vzhledu, atd.

Dále také používám MYSQL 5.5, Apache 2 a APC resp. memcached daemona.

Vstupem jsou textové (csv) tabulky jednotlivých uskutečněných volání (volající, volaný čas zahájení, čas ukončení). Výstupem jsou faktury v pdf a xml pro jednotlivé koncové zákazníky, dále seznamy jednotlivých uskutečněných volání konkrétního uživatele, jež lze v html prohlížet, filtrovat, sumarizovat a řadit podle různých sloupců.

Tento projekt je stále ještě ve stádiu vývoje, nebyl zatím předán zadavateli, takže ještě nemohu zveřejňovat veškeré podrobnosti, na které bych chtěl upozornit. Jakmile to bude možné, tento text rozšířím o konkrétní ukázky a zajímavosti, na které jsem v průběhu vývoje této aplikace narazil.

• Podle volajícího ID (číslo A)  se načtou data uživatele a patřičný ceník uživateli přiřazený.
• v ceníku se vyhledá tarif odpovídající předčíslí s největším stupněm shody s volaným ID (číslo B)
• každý ceník má cca 6000 řádků, tedy z důvodu urychlení využíváme cachování pomocí jedné z více možných metod memcached, APC, RAM, RAMDISK
• podle Timestampu volání se určí, zda se jedná o silný či slabý provoz (svátky, Vánoce, Velikonoce, víkendy atd)
• na základě údajů z ceníku se určí také tarifikace, která je rozdílná pro různé kategorie uživatelů a také pro různé destinace volání (60+60, 60+1, 30+1, 15+15, 1+1)
• spočítá se výsledná cena
• musí se ošetřit přechody mezi vysokým a nízkým tarifem v rámci jednoho hovoru
• musí se ošetřit různé chytáky ve speciálních tarifech (linky 810, 900,906, 976, 1188, 1301 apod)
• kontroluje se minimální marže (koncová cena pro zákazníka vs. spojovací poplatky operátorům a poskytovatelům)
• v případě chyby (nenalezen uživatel nenalezen tarif atd) nejsou faktury vygenerovány a vše se vrátí ze zálohy do původního stavu

další je myslím nejlépe patrné ze screenshotů:

Uživatel + JS

◄ Back

Next ►

Picture 1 of 19

Editace uživatele. Verifikace polí formuláře pomocí javascriptu.

Pokračovat ve čtení »]]> XSS znamená cross-site scripting. Je to velmi často používaná metoda útoku, kdy útočník propašuje škodlivý kód do PHP či jiné aplikace. Docílí tak toho, že uživatel či správce, který aplikaci použije, aniž by to spozoroval spustí kód z jiného umístění.

Tato metoda předpokládá, že buď má útočník přístup pro zápis do nějaké části (souboru) aplikace (špatné zabezpečení, bezpečností díra, chyba v kódu) a injektuje tak odkaz např. do css.

Nebo je tam tento backdoor už od začátku a třeba několik měsíců o sobě nedá vědět, dokud se útočník nerozhodne útok provést (samozřejmě – to se nás netýká, my stahujeme všechny pluginy pro wordpress z ověřených zdrojů a kontrolujeme všechny řádky jejich kódu!)

Asi nejčastější případ je, že se útočníkovi povede tento škodlivý kód dostat do dat, které se cílené osobě zobrazují. Toto je možné provést libovolnou akcí, která předpokládá zobrazení infikovaných dat v prohlížeči administrátora či osoby, na níž je útok veden.

Asi nebude problém nalézt nějakou akci uživatele, jež vyžaduje zobrazení v prohlížeči např. administrátora – takové přidání nového příspěvku do diskuze, zadání nové objednávky v e-shopu, žádost zadaná přes kontaktní formulář, a spousta dalších jiných akcí toto předpokládá.

Je to velmi jednoduché – útočníkovi stačí najít neošetřené textové či jiné uživatelské vstupy, přes které krom standardního textu projdou také znaky <> :/”

schválně si zkuste, kolik diskuzních fór či e-shopů dovolí registrovat uživatele s adresou dejme tomu

Tonda Novak

<script src=”http://www.bouska.biz/public/xsstest.js”></script>

Praha 1

(Můžete si vyzkoušet – soubor xsstest.js z příkladu v případě spuštění vyvolá popup okno s varováním.)

Samozřejmě, že toto ještě neznamená, že potenciálně škodlivý skript xsstest.js se skutečně SPUSTÍ

Pokud programátor odvedl svou práci v přijatelné kvalitě, budou buď tagy zcela vypuštěny a nebo budou převedeny opisem  na neškodný textový řetězec, který nezpůsobí spuštění tohoto kódu ale pouze zobrazení uvedeného textu. Text pak např. místo znaku  < obsahuje řetězec &lt který prohlížeč interpretuje jako text a nikoliv jako začátek tagu. Filtrování je možno provézt minimálně na dvou místech: při přijímání dat z formuláře a nebo až při jejich zobrazování v pohledu. Důsledný programátor použije pro jistotu filtrování na obou místech.

Pokud však programátor byl lempl, tak se filtrování neprovede, data se v nezměněné podobě uloží a při dalším zobrazení se prohlížeči pošlou opět v nefiltrované podobě.

Tak schválně… kolik běžně používaných diskuzních fór, CMS, ERP, seznamek,  bazarů, eshopů a jiných běžně dostupných aplikací nefiltruje data a dovolí Vám registrovat se s výše uvedenou adresou (přezdívkou, poznámkou, vzkazem pro administrátora)

Tak to by bylo pro tentokrát vše, v příštím dílu si povíme, jak může vlastně škodit ten škodlivý kód.