Ja a Synergy

Posted by pX on October 1, 2008 None comments

Práve včera mi došiel objednaný notebook a akonáhle som si ho v práci položil vedľa 4och monitorov pracovného pc, zneľúbilo sa mi “prechytávanie” medzi klávesnicou PC a notebookom. Spomenul som si na projekt akéhosi softwarového KVM switchu (vkastne iba KM) a po chvíli som ho našiel – Synergy.

Synergy je opensource-ová aplikácia, ktorá umožňúje ovládať viacero PC jednou klávesnicou a myšou veľmi intuitívne. Po zadefinovaní relatívnej polohy jednotlivých PC stačí myšou doslova prejsť na druhý počítač – kurzor sa zjaví na ňom, a vstup z klávesnice je presmerovaný tiež. Toto všetko sa deje cez sieťové spojenie.

Už pri downloadovaní som sa ale zľakol toho, že medzi podporovanými systémami nieje Windows Vista (OS na mojom notebooku). (Za to podporujú Win XP, Mac OS X, X11 na UNIXoch a dokonca Win 2000, NT, 98, 95…) Z jedného fóra som sa ale dozvedel, že s Vistou ľudia problémy nemajú. No môj prípad bol ešte o to zvláštnejší, že na PC použivam naraz 4 monitory, teda by som sa veľmi nečudoval, keby to Synergy nechutilo.

Teda hurá do toho. Po spustení som zistil, že nastavenia tohoto programu vôbec niesú user friendly – po zbežnom prečítaní manuálu som ale program nastavil, spustil na hostiteľskom (PC) aj klientskom (notebook) počítači a tieto sa na seba bez problémov napojili. S viacerými monitormi problém nebol, kurzor plynulo prešiel cez okraj pravého monitora na notebook. Dokonca som nespozoroval ani žiadne zdržanie v reakciách kurzoru na klientskom PC. Jediný problém bol, že som sa myšou nevedel dostať naspäť na hostiteľský PC. Po krátkom googlení som zistil, že programu treba povedať nielen to, že notebook je napravo od PC, ale aj to, že PC je naľavo od notebooku.

Odvtedy tento systém fungoval úplne nádherne, mierne nepohodlie bolo cítiť iba ak som sa snažil prejsť na druhý PC počas plnej CPU záťaže hostiteľského PC. Na druhý problém som narazil až keď som šiel písať tento blogpost – celý systém (spustený na XP a Viste) má trochu problémy so striedaním charsetov. Ale toto ma takmer vôbec neobmedzuje a ešte sa na to určite pozriem do manuálu.

Ak teda niekedy používate (alebo chcete používať) viacero PC umiestnených vedľa seba naraz, nemôžem vám neodporučiť Synergy.

PS: ďaľšou veľmi prijemnou featurou je synchronizácia clipboardu, ktorá ale funguje iba s textami. Žiadne pokročilé funkcie ako drag&drop súborov medzi počítačmi implementované niesú.

ASP.NET Validátory

Posted by pX on July 23, 2008 None comments

Približne pred rokom som začal programovať v ASP.NET/C#, odvtedy som postupne objavoval ASP.NET framework a bol som maximálne spokojný s tým, ako je navrhnutý a ako dobre sa s ním dá pracovať.

Jednou z pekných feature ASP.NET sú validátory formulárov. Ku každej controle (TextBox, DropDownList, RadioButtonList, CheckBox ale aj ku custom controlom) sa dá pridať validátor, ktorý dokáže zvalidovať danú controlu. Existujú preddefinované validátory – hlavné sú:
* RequiredFieldValidator – controla musí mať definovanú neprázdnu hodnotu
* CompareValidator – hodnota controly musí byť zhodná s hodnotou inej controly (napr registračný formulár – heslo zvyčajne treba zadať 2x)
* RangeValidator – hodnota controly musí byť z určitého rozsahu
* RegularExpressionValidator – hodnota controly musí matchovat regulárny výraz
* CustomValidator – controla sa validuje vlastným kódom (zadefinovanom v nadradenej controle)

Všetky tieto validátory validujú dáta na strane servra, ale môžu validovať dáta už aj na strane klienta (zabránia odoslaniu formulára). Na každú controlu môže byť naviazaných viacero validátorov. Validátory môžu mať nastavenú aj tzv ValidationGroup a ErrorMessage. ValidationGroup sa používa v prípade, že potrebujeme validovať rôzne časti formulára. ErrorMessage sa zasa použije v prípade, že controle nezbehne validácia.Veľmi príjemná je aj controla ValidationSummary, ktora sa klientovi zobrazí pri neúspešnej validácii a sú v nej vypísané ErrorMessage všetkých validátorov, ktoré ohlásili pri validácii chybu.

Príklad: V registračnom formulári, využívajúcom validátory, je možné použiť takýto jednoduchý kád na zvalidovanie celeho formulara (a vypísanie chybových hlášok):

protected void registerUser()
{
Page.Validate("RegistrationForm");

if (Page.IsValid)
{
// tu mame istotu, ze su vsetky data validne
... // samotna registracia
}
}

ALE

Nedávno som potreboval na stránku umiestniť Captcha, siahol som teda po hotovom riešení – ReCaptcha. K tejto službe sú už priamo od poskytovateľov dostupné knižnice do ASP.NET, ktoré fungujú veľmi sympaticky – stačí includnut controlu, nastaviť jej private a public key (prípadne ďaľšie nepovinné nastavenia) a výsledok dostaneme v Page.IsValid, nakoľko sa controla sama zaregistruje medzi validátory na stránke.

Stránka, na ktorej som sa chystal toto riešenie použiť bola ale zložitá, potreboval som použiť ValidationGroup, ktorý controla nepodporovala. Rozhodol som sa ho teda do controly dopísať, čo si vyžadovalo štúdium útrob validácie v ASP.NET. Pri tom som zistil, že interface IValidator (ktoré ReCaptcha controla dedila) nemá zadefinovanú property ValidationGroup, ale túto má zadefinovanú až (a iba) trieda BaseValidator (ktorá nemusí byť vhodná na každé použitie – dedí po triede Label, čo je v mojom prípade neželané).

Z toho vyplýva, že je nemožné spraviť jednoduchú, elegantnú custom controlu, ktorá je sama sebe plnohodnotným validátorom. Situácia sa dá vyriešiť až zabalením controly spolu s CustomValidator-om do novej controly, ktorá bude mať vyvedené nastavenia ValidationGroup a ErrorMessage – na tomto riešení je nepekný fakt, źe kód validátora a samotnej controly je v rôznych controloch.

Screw you guys, I’m going to Bulgaria

Posted by pX on July 3, 2008 None comments

Už dlhšie máme s partiou naplánovanú dovolenku, kde by sme sa úspešne vyhli počítačom a internetu. Dnes nadišiel čas odchodu, teda Vám oznamujem, že budem týždeň offline, bez možnosti (a hlavne chuti) komunikácie s ostatným svetom.

Antivirus software whitelisting

Posted by pX on June 18, 2008 None comments

Česká pobočka Symantecu vydala tlačovú správu o nimi zamýšľanom napredovaní antivírusových riešení. V nej je spomenutých hneď niekoľko zaujímavých štatistických čísel (okrem iného z nich aj vyplýva, že cena za ukradnuté World of Warcraft konto je niekoľkonásobne vyššia ako cena ukradnutých informácií o kreditnej karte) – podľa Symantec-u bolo na konci roku 2007 viac ako 1 200 000 variánt malware. V ich štúdii je tiež spomenuté, že v roku 2007 bolo 65% všetkého uvoľneného unikátneho software charakterizovaného ako nebezpečný kód.

A tieto alarmujúce čísla napovedajú, že bude v budúcnosti jednoduchšie identifikovať neškodný software ako identifikovať malware. Tu ale správnemu paranoikovi vhupne do hlavy ďaľšie spiknutie. Buď bude používať antivírus, alebo bude neustále atakovaný malware-om. Antivírus ale bude musieť na základe rôznych algoritmov / databáz identifikovať spúštaný (resp príchodzí) software (teda bude mať dokonalý prehľad nie o infikáciách počítača, ale o jeho regulérnom software) a navyše bude rozhodovať o tom, či ho dovolí na počítači spustiť (resp vôbec uložiť). Toto môžu byť dosť citlivé informácie/schopnosti a nechcel by som, aby nimi nejaký program disponoval (a čo si ešte paranoik môže myslieť o zasielaní týchto informácií na “anonymné štatistiky” :-) )

CSS history exploit

Posted by pX on June 17, 2008 None comments

Veľmi ma zaujal článok CSS exploit a neexistující soukromí na webu, pojednávajúci o zneužiteľnosti jednej feature CSS (dokonca už verzie 1). Zneužiteľná je schopnosť odlišne štýlovať odkazy vedúce na navštívené url, teda :visited. Pomocou tohoto CSS selektoru môžete nastaviť spomínaným odkazom odlišný štýl ako nenavštíveným, čo je pre používateľa príjemná vlastnosť.

Zároveň je to ale skrytý informačný kanál z histórie browsera do oblasti prístupnej JavaScript-u ale informácia sa môže dostať mimo Vášho počítača aj inak.

Príklad: dajme tomu, že tento exploit ide zneužiť e-shop. Na svoju stránku schová odkazy na konkurenčné e-shopy a nastaví im ID v tvare “konkurenciameno” (napríklad konkurenciaeshop2, konkurenciaeshop3), podľa toho, na ktoré e-shopy odkaz vedie. V CSS potom použije takéto pravidlá:


#konkurenciaeshop2 { background-image: url(log.php?eshop2); }
#konkurenciaeshop2 { background-image: url(log.php?eshop3); }
...

Skript log.php potom vráti prázdny obrázok, ale popri tom dostane a zaloguje aj informáciu o tom, že užívateľ, ktorý si obrázok pýta, navštívil danú stránku. Túto informáciu môže uložiť k užívateľovým session dátam a následne ich zneužiť.

Toto je primitívny spôsob zneužívania takéhoto chovania browsrov, ale pomocou JavaScriptu sa dá doviesť k dokonalosti. Nevýhodou je, že vždy môžete otestovať iba konkrétnu URL. Ale skript sa môže chovať tak, že dostane zoznam úvodných stránok, ktoré otestuje. Následne oznámi servru, ktoré z úvodných stránok má užívateľ (obeť?) v histórii, na čo mu server zašle ďaľšiu sadu URL-čiek (na danej doméne), ktoré skript tiež otestuje. Takto je možné dokonca zistiť napríklad aké produkty si užívateľ prehliadal na konkurenčných stránkach a podľa toho upravovať cenu, za ktorú by mu ich e-shop (útočník?) predal.

Samozrejme tento exploit nieje taký závažný ako niektoré iné, ktoré inštalujú rôzny malware, ale zaujímavé (a nebezpečné) na ňom je, že toto chovanie je z užívateľovho hľadiska feature, navyše podporovaná takmer všetkými browsermi.

Cvičenie: Web #2

Posted by pX on June 14, 2008 None comments

Popri sledovaní live streamu z BarCamp-u som dostal ďaľší nápad na zadanie cvičenia. Osobne sa mi toto cvičenie ľúbi najviac zo všetkých (mojich) a dúfam, že sa bude páčiť aj vám.

Správnu odpoveď (ktorú si môžete overiť tu) nájdete pri vŕtaní sa v deravej stránke na tejto url.

Viac hintov vám azda nebude treba, diera podľa mňa bije do očí dostatočne.

Ešte pripomeniem, že ak ste zaregistrovaní na mojom blogu a prihlásení cez prihlasovací systém cvičení, tak sa váš nick objaví vo výsledkovej listine úspešných riešiteľov.

Cvičenie: Captcha

Posted by pX on June 13, 2008 None comments

Nedávno mi ehmo (synopsi) povedal, že by nebolo odveci vytvoriť aj dáke cvičenia na prelomenie (z počiatku jednoduchých) captcha systémov. No a dnes som si našiel trochu času a prvé (dúfam, že bude záujem aj o pokračovanie) cvičenie vyrobil.

Vašou úlohou je 100 krát za sebou vyriešiť jednoduchý captcha systém. Na každý pokus máte (od vyrenderovania stránky po prijatie vašej odpovede na servri) jeden a pol sekundy. Po zvládnutí úlohy vám stránka prezradí tajnú frázu, ktorú si môžete overiť tu.

Ak ste ešte žiadne moje cvičenie z bezpečnosti neriešili, prečítajte si aj článok o cvičeniach.

Ako fungujú internetové platby cez i-banking

Posted by pX on June 7, 2008 2 comments

V tomto článku by som chcel ozrejmiť, ako fungujú internetové platby cez i-banking. Prednedávnom som niektoré platobné systémy implementoval a preddávnom ma veľmi zaujímalo, ako asi tieto platby fungujú (a preto sa s vami, o mnou nadobudnuté informácie, delím). Na príklade budem opisovať komunikáciu medzi aplikáciou e-shopu a aplikáciou internetbankingu.

Opisovaná situácia: zákazník si na e-shope vyberie tovar, potvrdí objednávku a chce zaplatiť cez i-banking svojej banky.

Priebeh platby

Schéma priebehu internetových platieb

Po objednávke musí zákazník zvoliť, aký druh platby použije na zaplatenie, pretože aj keď majú slovenské banky (aspoň tie, s ktorými mám skúsenosť) veľmi podobné protokoly na platby, nie sú rovnaké a napríklad Tatra banka má dokonca 2 druhy platieb (TatraPay a CardPay). E-shop následne má všetky informácie, aby vygeneroval payment request (na obrázku krok 1). V payment requeste je okrem iného uvedená suma, identifikácia obchodníka (e-shopu), identifikátor platby (variabilný symbol, niekedy aj špecifický symbol a konštantný symbol) a návratová url na stránku obchodníka. Payment request bude zaslaný banke prostredníctvom zákazníkovho browsra – teda potenciálne nebezpečným kanálom. Preto treba dodatočne zabezpečiť integritu a autenticitu dát uvedených v payment requeste.

Používaným spôsobom zabezpečenia payment requestu je podpis prenášaných dát. Podpísané musia byť všetky dôležité atribúty uvedené vyššie. Tieto sú skombinované do základu podpisu, z ktorého sa spraví hash. Hash sa následne zakryptuje symetrickou šifrou (používanými sú DES a 3DES) kľúčom, ktorý je známy iba obchodníkovi a banke (kľúče samozrejme rozdeľuje banka a každému obchodníkovi by mala prideliť iný kľúč), a vypadne podpis. Podpis je pridaný ako ďaľší atribút payment requestu.

E-shop teda má už kompletné údaje o payment requeste. Väčšinou sú to dvojice názov-hodnota, ktoré sa podľa špecifikácie príslušného protokolu zapracujú do HTML formu alebo URL a zobrazené v zákazníkovom prehliadači. Zákazníkov browser potom opustí obchodníkov web odoslaním payment requestu na server banky (podľa typu platby GET alebo POST HTTP requestom) (na obrázku kroky 2,3).

Banka následne autentifikuje zákazníka (prihlasovacími údajmi do i-bankingu, grid kartou, “kalkulačkou”…) a ten môže potvrdiť platbu (na obrázku krok 4). Ešte pred potvrdením platby ale musí banka samozrejme overiť digitálny podpis payment requestu a ten aj validovať (či sú správne zadané údaje etc.). Po potvrdení platby banka spracuje transakciu a vygeneruje payment response, ktorý obsahuje minimálne identifikátor platby (variabilný symbol) a výsledok transakcie. Prirodzene aj payment response je chránený digitálnym podpisom, ktorý sa spravidla generuje rovnakým postupom ako v payment requeste. Výsledky platby môžu byť OK (transakcia prebehla/prebehne), fail (transakcia neprebehne) a pri niektorých typoch e-platieb tiež timeout (platba zatiaľ neprebehla). Keď už banka vygenerovala payment response, zákazníkov browser je s payment response-om presmerovaný naspäť na stránku obchodníka (na obrázku kroky 5,6) (stránka obchodníka, kam má byť zákazník presmerovaný po spracovaní transakcie, bola uvedená v payment requeste – väčšinou sa používa HTTP GET).

Obchodník musí overiť podpis a validnosť payment response-u a ak sa to podarí, môže spracovať výsledok platby (na obrázku krok 7). Najprv musí spárovať platbu, ktorej sa payment response týkal, s objednávkou, ktorú zákazník odoslal. Na toto slúži identifikátor platby. Ďalej môže pokračovať v spracúvaní objednávky.

Zabezpečenie

Ako ste možno postihli, o celé zabezpečenie doteraz opísaného protokolu sa starajú podpisy správ vymieňaných medzi bankou a obchodníkom. Potencionálnemu útočníkovi (zákazník) by teda stačilo vedieť vygenerovať želaný payment response a dobre ho podpísať, aby mohol obchodníka presvedčiť o tom, že za objednané produkt(y) už zaplatil. Preto je veľmi dôležité zabezpečenie tajného symetrického kľúča, ktorý nesmie uniknúť ani z banky, ani od obchodníka.

Toto môže byť celkom riskantné, preto banky obchodníkovi väčšinou posielajú zabezpečeným mailom sumáre platieb realizovaných cez i-banking. Obchodník tak môže zistiť, ktorá objednávka v skutočnosti zaplatená nebola.

Záverom

Opisoval som spoločné vlastnosti fungovania internetových platieb. Samozrejme, že niesú všetky rovnaké. Niektoré protokoly môžu mať podporu na session dáta obchodníka, niektoré používajú okrem variabilného symbolu aj ďaľšie vlastnosti na identifikáciu platby, niektoré majú podporu na zadanie jazyka zobrazeného i-bankingového systému v payment requeste a podobne.

EBanking server simulator

Posted by pX on May 24, 2008 None comments

Pred nedávnom som implementoval knižnicu na EBanking (konkrétne som mal za úlohu implementovať SLSP SporoPay, TatraPay, CardPay a VUB EPlatbu). Všetky tieto protokoly komunikujú so servermi príslušnej banky cez klientov browser HTTP protokolom.

V skratke: stránka vyskladá payment request (zoznam pomenovaných hodnôt, napr mena, suma, variabilný symbol…), dôležité dáta zhashuje a zašifruje symetrickou šifrou kľúčom, ktorý má iba banka a stránka. Výsledkom toho je podpis, ktorý chráni dáta – ak by sa počas prenosu zmenili, tak to druhá strana dokáže zistiť a zmenené dáta ignorovať, akoby vôbec neprišli. Podpis sa pridá k hodnotám a tie sa cez klientov browser odošlú na server jeho banky – väčšinou formou HTTP GET – tj postačí obyčajný odkaz. Banka teda má údaje o tom, čo chce klient zaplatiť, klient sa potom autentifikuje na stránke banky a potvrdí transakciu, na čo banka vytvorí response rovnakým spôsobom, ako predtým stránka robila request a klient je presmerovaný naspäť na stránku obchodníka, ktorý dostal podpísanú správu od banky.

No a nakoľko nieje vždy po ruke človek, ktorý má v danej banke konto, debugging tohoto procesu je nepríjemný. Preto som spravil narýchlo tento tool, ktorý simuluje server banky. Vyplníte typ transakcie (v súčasnosti sú podporované SporoPay, TatraPay, CardPay a VUB ePlatba), zadáte request vo forme URL a zdieľaný kľúč na vytvorenie podpisu a potom si môžete vybrať, či chcete response OK (transakcia sa podarila), Fail (transakcia sa nepodarila) alebo Timeout (transakcia ešte neskončila). Výsledkom je response vo forme URL – copy&paste do browsera a preskočili ste presmerovanie na banku a debugovať môžete donekonečna – dokonca ani nemusíte mať zriadené konto v banke, aj keď to je potom problém sa dostať k špecifikáciám, podľa ktorých je nutné platobný systém implementovať.

Tool vydávam pod GPL licenciou, hlavne z toho dôvodu, aby ste videli, že sa nejedná o malware.

Zdrojové kódy nájdete na svn://dev.monogram.sk/pokojny/EBankingServerSimulator , binárka je na stiahnutie tu. Použitým jazykom je C# , .NET 2.0, takže ho zatiaľ spustíte iba na windowse.

Cvičenie: manipulácia webových ankiet

Posted by pX on May 9, 2008 2 comments

Nedávno ma kamarát poprosil o zahlasovanie v jednej on-line ankete. Spamovaním svojich známych s touto prosbou chcel docieliť lepšie umiestnenie.

V tom ma napadlo zadanie nového cvičenia: manipulácia webových ankiet. Vyrobil som stránku s (podľa mňa) priemerným anketovacím systémom. Tento v určitej miere zamedzuje opätovnému hlasovaniu. Hlasy môžu putovať jednotlivým súťažiacim (predpokladám, že každý bude hlasovať za seba :-) ). No a Vašou úlohou je (ako inak) získať čo najviac hlasov.

Súťaž prebieha v kolách – každý deň nové kolo. Pri uzavretí kola sa obnovia celkové výsledky. “Vyhráva” ten súťažiaci, ktorý bude mať najviac hlasov za niektoré z uplynulých kôl. Súťaž nemá koniec, iba ak by bol na servri cítiť znateľný nárast trafficu, tak pouvažujem nad jej ukončením.

Link na stránku s anketou

Keď sa chcete zúčastniť súťaže, musíte mať vytvorené konto. Úlohu som si uľahčil o to, že sa používajú kontá ľudí zaregistrovaných na mojom blogu. Prihlásiť sa do súťaže je možné Vaším prihlasovacím menom na stránke s anketou.

Príjemnú zábavu!