Nielsenová úvaha nezasahuje do použiteľnosti a bezpečnosti samotnej ochrany. Nielsen v článku kritizuje tzv. hviezdičkovanie hesla, ktoré podľa jeho slov “nezvyšuje úroveň bezpečnosti, zato vás stojí biznis vďaka chybám pri prihlásení”. Skôr ako sa pustíte do zvyšku tohoto článku si prosím prečítajte Nielsenov článok, nebudem sa moc vracať k jeho úvahám.

Názor

Je mi jasné, že mnohým čitateľom sa už pri nadpise zakrvavil pohľad a teraz všetko čítajú cez tento filter. Skúste však na chvíľku odložiť emócie. Nielsen má v jednej veci pravdu. Hviezdičkovanie hesla prináša problémy aj tým, ktorí sú schopní písať na klávesnici bez toho, aby sa na ňu museli pozerať. Táto technická zručnosť vyžaduje dokonalú memorizáciu všetkých kláves klávesnice, čo trvá nejaký ten čas (a tisícky hodín napísaných textov). Drvivá väčšina bežných užívateľov túto zručnosť nemá. Mnohí teda píšu heslo na niekoľkokrát (empiricky overené), alebo ho napíšu niekam inam a potom prekopírujú do políčka pre heslo. Niektoré weby však toto neumožňujú (JavaScript) a tak sa užívateľ trápi. Tieto problémy sa stávajú zriedkavejšími s narastajúcou zručnosťou užívateľa v písaní na klávesnici, nezmiznú však úplne. Občas sa aj majster tesár utne. Určite ste sami už žiadali o zresetovanie hesla z dôvodu, že ste ho nevedeli a ak web poslal aktuálne heslo (čo fakt niektoré robia), tak ste boli prekvapení, že ste mali chybu v písmenku, či dvoch.

Pre

Nielsen navrhuje, aby políčka pre heslo boli nahrádzané bežným políčkom, do akého vypisujete prihlasovacie meno. Tento krok podporuje tvrdením, že hviezdičkovanie vzniklo ako ochrana pred zlodejom, ktorý vám pozerá cez rameno. Nielsen tvrdí, že ak by zlodej chcel, môže vám jednoducho pozerať na prsty.

Na toto vyhlásenie zareagovalo mnoho ľudí, pričom najčastejšie tvrdili, že “heslo píšem tak rýchlo, že by som ho ani sám nedokázal odsledovať”. Bohužiaľ, Nielsen nijak nerozviedol svoje argumenty a tak to skúsim ja. Michal Zalewski, odborník na bezpečnosť, ktorého si veľmi vážim (dnes zamestnanec Googlu), napísal pred niekoľkými rokmi článok, ktorý nazval “Cracking safes with thermal imaging“. Michalov server odišiel do večných vôd Arpanetu a tak je odkaz už len na Google Cache, kde bohužiaľ nie sú obrázky, ktoré krásne ilustrovali tento útok. Pri útoku sa používa kamera, ktorá dokáže snímať termálne teplo, ktoré človek zanecháva pri stlačení jednotlivých kláves. Pri tejto forme útoku vám nepomôže ani rýchlosť, kamera bez problémov zaznamená každé stlačenie klávesy. Kameru je možné zakúpiť jednoducho a aj relatívne lacno napríklad aj tu. Ďalšou možnosťou je tento rok predstavená technika útoku, ktorá umožňuje snímanie kláves za pomoci laseru.

Proti

Som si vedomý, že nie každý zlodej bude mať “po ruke” takéto zariadenie. Faktom je, že odhviezdičkovanie hesla by prinieslo niekoľko situácií, ktoré by mohli ohroziť užívateľovu bezpečnosť. Napríklad bezpečnostné kamery. Je síce pravda, že väčšina týchto kamier má katastrofálny obraz, ale niektoré dokážu zo seba vymačkať už slušnú kvalitu.
Ďalšia problematická situácia môže byť, ak sa za vás niekto postaví, alebo prezentujete a potrebujete živú ukážku v ktorej sa budete prihlasovať, alebo vám zazvoní súrne telefón v polovici hesla a vy budete musieť opustiť počítať (heslá bývajú väčšinou logické slová [málokto má doma psa xf32Zsa7] takže ich nie je problém dokončiť).
Ďalším problémom môže byť malware, ktorý robí screenshoty pri písaní (zameriava sa na bankové weby, ktoré prišli s virtuálnou klávesnicou, pričom malware neustále sníma obraz pri každom kliknutí, či stlačení písmenka).
V neposlednom rade môže spôsobiť problém aj cache (pamäť) prehliadačov, ktoré si pamätajú texty zadávané do formulárov. S tým je samozrejme spojené aj predvyplňovanie formulárov, ktoré je síce možné zakázať aj na strane serveru aj na strane užívateľa, no ruku na srdce. Koľkí to tak doma máte nastavené a koľkí to tak nastavajú na samotnom webe?
Každopádne sa predvyplňovanie formulárov dá vypnúť cez parameter AUTOCOMPLETE ako v tomto príklade.

<FORM AUTOCOMPLETE="off">
<input type=text AUTOCOMPLETE="off">

Zmeny a možnosti

Na oboch stranách existujú argumenty, ktoré potvrdzujú a aj vyvracajú tento návrh. Preto je podľa mňa potrebné hľadať kompromis. Nielsen ho vidí v poskytnutí checkboxu (zaškrtávací štvorček), ktorý by za pomoci JavaScriptu zmenil typ políčka a tým ho za/odhviezdičkoval. Štandardne by však podľa Nielsena malo byť políčko bez hviezdičiek a na požiadanie by si ho užívateľ zahviezdičkoval, i keď pripúšťa prípady, kedy by mohlo byť políčko zahviezdičkované už od začiatku, ako napríklad prihlasovací formulár do banky.

Ja si nemyslím, že by však užívatelia boli veľmi schopní posúdiť prípadne riziko. Dnes je veľmi veľa portálov previazaných a tak strata hesla k jednému môže viesť k problémom u ďalších. Netreba zabúdať aj na to, že množstvo užívateľov používa rovnaké heslá, často len jedno či dve pre celý internet. Vtedy môže byť strata hesla veľmi kritická, i keď ste oň prišli na relatívne nepodstatnom webe.

Úplne vylúčenie hviezdičkovania podľa mňa reálne nie je. Príkladom môže byť PIN kód v bankomate, alebo dôležitosťou podobné údaje, ktoré by si asi nik neželal zobrazovať v čitateľnej forme. Ak niekto chce, môže si heslo odhviezdičkovať za pomoci rôznych nástrojov či doplnkov a to nielen pre prehliadač, ale aj pre samotný systém. Pre prehliadač Firefox môžete využiť rozšírenie Unhide Passwords, ktoré vám umožní zobraziť zahviezdičkované heslo. Ostatne, sám som kedysi písal na túto tému článok.

Ja vidím riešenie v zobrazovaní posledného napísaného písmenka po dobu napríklad 1s. Aj mne by sa občas takáto vymoženosť hodila. Princíp je jednoduchý. Pri písaní vidíte vždy posledné písmenko po dobu 1s, potom sa zmení na hviezdičku. Ak sa nemýlim, tento princíp je aplikovaný v iPhonoch. Podľa mňa je to jedno z najlepších riešení, ktoré je možné aplikovať na túto formu autentifikácie užívateľa.

Príklad:
a
*s
**c
***d
****g
*****

Ak vás nebaví stále vypĺňať formuláre ručne, je možné používať rôzne automatizované riešenia, ako napríklad KeePass, PassPack, alebo môj obľúbený, ale bohužiaľ platený, Roboform. Tieto nástroje vám umožnia rýchlo a jednoducho spravovať tisícky hesiel pre rôzne weby, čím nielen odstránia potrebu používať jedno, či dve heslá pre jeden web, ale zároveň vám umožnia používať veľmi komplikované, predgenerované heslá, ktoré si ani sami nezapamätáte (a ani nemusíte). Tie môžete ukladať online a využívať ich kdekoľvek sa nachádzate. Aj tu sú samozrejme riziká, ktoré si je potrebné uvedomiť, ale o tých zase inokedy.

Záver

Doteraz som sa držal len prvej časti Nielsenovho článku, ktorý sa týkal hviezdičkovania hesla. V druhej časti kritizoval používanie RESET tlačítka, ktoré podľa neho dnes už nemá (a malo vôbec niekedy?) opodstatnenie. Ja s ním musím len súhlasiť. Občas sa mi v niektorých formulároch, ktoré obsahujú toto nechutné tlačítko stane, že namiesto odoslať stlačím RESET. Väčšinou za to môže zle poradie tlačítok, kedy RESET reaguje ako prvý na akciu vyvolanú stlačením klávesy ENTER. To u mňa vždy vyvolá riadnu zúrivosť a preto som si napísal skript pre Greasemonkey, ktorý tlačítko RESET vždy z webu odstráni.

A na úplný záver. Samotný Bruce Schneier súhlasí s Nielsenom. Pod jeho článkom nájdete momentálne 133 komentárov, kde sa dajú nájsť aj zaujímavé názory (ale musíte sa najskôr obrniť proti fakt hlúpym komentárom).

Popis

Podstata útoku spočíva v tom, že útočník odosiela nekompletné požiadavky na server, presnejšie nekompletné hlavičky požiadaviek. Apache a niektoré ďalšie HTTP servery (zoznam neskôr) na to reagujú tak, že čakajú na dokončenie celej požiadavky (hlavičky) a nechávajú pripojenie medzi útočníkom a serverom otvorené až do prijatia všetkých potrebných údajov, resp. do vypršania času. A to práve umožňuje útočníkovi zasielať väčšie množstvo požiadaviek, ktoré však nikdy nebudú kompletné. Výsledkom je preťaženie webového servera (procesu) a jeho následný pád. Podľa testov rôznych bezpečnostných analytikov je takto možné zhodiť približne 98% všetkých funkčných serverov, ktoré používajú niektorý zo zraniteľných HTTP serverov.

Robert týmto krokom vyvolal veľmi vášnivú diskusiu, pretože dal bežným užívateľom (script kiddies) do rúk nástroj, ktorý veľmi efektívne môžu používať na poškodzovanie veľkého množstva webov. Ochrana je pritom relatívne zložitá, občas veľmi neefektívna. Nástroj nazval Slowloris, je naprogramovaný v jazyku Perl. Jeho najefektívnejšie využitie je na systémoch Unix-like, ktoré nemajú obmedzenia na množstvo otvorených socketov. Windows toto obmedzenie má, umožňuje len 140 aktívnych socketov, čo znemožňuje útok v prípade, že nastavenie časového limitu pre prijatie zbytku hlavičky webovým serverom je nižší, než 60 sekúnd.

Postihnuté sú tieto aplikácie:

• Apache 1.x
• Apache 2.x
• dhttpd
• GoAhead WebServer
• Squid (nepotvrdené)
• WebSense “block pages” (nepotvrdené)
• Trapeze Wireless Web Portal (nepotvrdené)
• Verizon’s MI424-WR FIOS Cable modem (nepotvrdené)
• Verizon’s Motorola Set-Top Box (port 8082 and requires auth – nepotvrdené)
• BeeWare WAF (nepotvrdené)

Zaručene v poriadku sú tieto aplikácie:

• IIS6.0
• IIS7.0
• lighttpd
• nginx
• Cherokee (potvrdené komunitou)
• Netscaler
• Cisco CSS (potvrdené komunitou)

Ochrana

Majitelia webových serverov majú niekoľko možností, ako zmierniť, či úplne zabrániť tomuto druhu útoku, ak teda používajú niektorý z náchylných aplikácií.

Výmena

Samozrejme, že je možné vymeniť zraniteľnú aplikáciu za takú, ktorá zraniteľná nie je. Problémom však býva, že často je webový server uspôsobený na fungovanie konkrétnej aplikácie a prehodiť tieto nastavenia nebýva jednoduchá záležitosť. Týka sa to napríklad zmeny pravidiel pre mod_rewrite, ktoré nie sú rovnaké v ostatných serverových aplikáciach.

Load ballancer a proxy

Ak vaša aplikácia vyžaduje viac ako jediný webový server, je možnosť sa vyhnúť celému problému za pomoci load ballanceru, alebo proxy umiestneného pred vašimi webovými servermi. Samozrejme, toto proxy nesmie byť náchylné na tento typ útoku, potom stráca táto ochrana zmysel.

Nastavenia

Ak však máte len jediný server, na ktorom beží Apache, jednoduchšou možnosťou je zmeniť nastavenia. Najdôležitejším nastavením je zmena TimeOut Directive, ktorá je štandardne nastavená na 300. Toto nastavenie určuje, ako dlho má Apache čakať na dokončenie požiadavky pri POST, PUT aj GET požiadavkách, pokým uzavrie spojenie. V tomto časovom limite musí útočník poslať 256 požiadaviek, ktoré sú štandardne povolené. Vhodné je zvoliť veľmi nízky čas, i keď je potrebné si dávať pozor, aby ste nezvolili prinízky čas a neobmedzili tak svojich bežných užívateľov. Dobré je zvoliť čas okolo 15 sekúnd, možno až 30.

Bohužiaľ, Slowloris sa vie tejto situácii ľahko prispôsobiť. V nastaveniach útoku je možné zmeniť čas vypršania požiadaviek na ľubovoľnú hodnotu, podľa ktorej sa útok graduje. Ak teda nastavíte čas do vypršania požiadavky na 4 sekundy, nástroj odošle 256 požiadaviek v tomto časovom limite, čo predstavuje podľa meraní približne len 45 kb/s. To znamená, že užívateľ s bežným domácim pripojením dokáže poľahky zložiť takmer akýkoľvek veľký web, ktorý je náchylný na tento typ útoku.

Ďalšou možnosťou je obmedzenie množstva požiadaviek pre jednú IP adresu. K tomuto je možné využiť napríklad modul pre Apache mod_limitipconn, alebo na UNIX-like systémoch je možné využiť ipt_recent/ipt_limit modul, ktorý robí tú istú vec ale na úrovni systému. So striktným nastavením však veľmi opatrne, pretože môžete veľmi ľahko odstaviť bežných užívateľov, ktorí sú nútení svojím ISP surfovať cez proxy servery. Príkladom je zahraničné AOL, ktoré je týmto povestné.

Bohužiaľ, v dnešnej dobe nie je najmenší problém zakúpiť niekoľko tisíc proxy za pár korún. Sú špecializované, hlavne ruské weby, ktoré ponúkajú za niekoľko dolárov prístup k veľkému množstvu proxy serverov, ktoré túto ochranu absolútne obchádzajú a pri neustálej obmene identifikátorov prehliadačov, zmeny veľkosti požiadavky, atď. je útočník prakticky nezastaviteľný.

Viac možností mi v tejto chvíli nenapadá. Je potrebné si podrobne naštudovať nastavenia vášho webového servera a aplikovať vybrané obmedzenia, resp. si nájsť inú formu ochrany. Akútnosť tejto zraniteľnosti je veľmi vysoká, preto je dosť možné, že sa čoskoro objavia nové verzie aplikácií, ktoré túto zraniteľnosť odstránia.

Záver

Robert nenechal nikoho ani vydýchnuť a už vo svojom ďalšom článku oznámil, že našiel ďalší spôsob, ako za pomoci DOS útoku spomaliť, resp. zhodiť akýkoľvek webový server. Viac si môžete prečítať v článku “HTTP Longevity During DoS“.

Ak teda prevádzkujete webový server, snažte sa ponoriť sa do tajov možných nastavení a nespoliehajte sa na aktuálnu funkčnosť dodávanú štandardne s aplikáciou.

API predstavuje akýsi most medzi aplikáciou a programovacím jazykom, ktorý nemá priamy prístup ku zdrojovým kódom webu, resp. k databázam (ktoré sú poväčšine najpodstatnejšie). Programátor, ktorý API vytvoril v ňom vie určiť všetky pravidlá pre prístup a nakladanie s dátami, pričom dokáže zároveň ochrániť svoje dáta v databáze, ako aj skripty na serveri.
Takto programátor, ktorý nie je priamym tvorcom projektu získa prístup k dátam, s ktorými vie narábať, ako napríklad čítať ich, posielať dáta späť aplikácii, atď.

Prosím, nemýľte si webové API s aplikačným. Jedná sa o dve rozdielne veci, i keď vo svojej podstate veľmi podobné.

Webové API skutočne umožnilo veľký rozmach rôznych služieb. Ako dobrá ilustrácia poslúži produkt z dielne spoločnosti Google, Maps. Tieto mapy pozná drvivá väčšina návštevníkov internetu. Ak si chcete umiestniť vlastné mapy na svoj web a do nich napríklad dopisovať, dopĺňať miesta, či vytvárať iné značky, na to všetko slúži API, ktoré vám toto všetko umožní. Jeden príklad za všetky slová.

V tomto článku by som sa rád zameral na bezpečnosť API ako systému. O návrhu API z pohľadu programátora písať nebudem. Ak máte o túto tému záujem, rád by som vám dal do pozornosti dokument od Jasmina Blanchette-a zo spoločnosti Trolltech, súčasť Nokie The Little Manual of API Design, ktorý je napísaný skutočne excelentne.

Bezpečnosť

API samozrejme poskytuje určitú formu ochrany samotnému tvorcovi webu, ktorý neumožňuje nikomu priamy prístup ku svojím dátam, ale všetky požiadavky si najskôr prefiltruje, aby jeho web nedostal “chrípku” vďaka niekoho šikovnosti. Mnoho vývojárov zabúda na bezpečnosť API. Mnohokrát som sa stretol s webom, ktorý mal relatívne slušne riešenú bezpečnosť, vrátane ochrany proti CSRF a XSS. Jeho API však umožňovalo vložiť dáta bez dodatočnej filtrácie, resp. bez dobrej dodatočnej filtrácie, čo vyústilo v bezpečnostnú zraniteľnosť. Takýchto API nájdete dnes tisíce.

Aby som však nepísal veľmi abstraktne, vezmem za vzor dnes jednu z veľmi populárnych služieb, ktorá stojí výlučne na svojom API, Twitter. Služba je dnes veľmi populárna a moderná s obrovskou hodnotou. Vďaka kvalitnému API sa služba rozšírila veľmi rýchlo medzi geekov a dnes dobíja srdcia aj mainstreamu.

Twitter si prešiel svojimi bezpečnostnými škandálmi, ktoré vyústili do veľmi výrazného zlepšenia bezpečnosti celého API. To je samozrejme veľmi dobrá správa. Aby sme si však pripomenuli, najväčšími bezpečnostnými incidentami boli asi tieto (samozrejme len tie, ktoré sa týkajú API, nie brute force útoku, phishingu, atď.)

• Not just social history, actual information from Twitter
  Dion Almaer upozornil na to, že ak ste sa autorizovali cez webový prehliadač u API, je možné za pomoci JavaScriptu veľmi jednoduchým spôsobom získať akékoľvek informácie, ktoré API poskytuje.
• Mikeyy worm
  17 ročný mladík, Michael Mooney, sa preslávil za niekoľko hodín vytvorením červa, ktorý zneužíval zlú filtráciu prichádzajúcich správ.

Twitter samozrejme zažil aj iné bezpečnostné incidenty, ale tie sa len málo, alebo vôbec netýkali samotného API. Ako som už spomenul, Twitter dal na radu odbornej komunity a prijal nového člena, ktorý sa dnes stará o bezpečnosť celého systému, vrátane návrhov pre správnu filtráciu správ. V tomto bode je Twitter relatívne bezpečný, až kým sa neobjaví nová technika, ktorá však bude mať globálnejší dopad, nielen na Twitter samotný.

Čo však Twitter už neovplyvňuje je bezpečnosť tretích aplikácií, teda aplikácií, ktoré neprogramovali iní programátori a ktoré vďaka API dokážu nahradiť celé webové rozhranie Twitteru, nájsť ľudí, ktorých by ste určite mali sledovať, alebo vypočítať pre vás štatistiky vašej aktivity. Takýchto aplikácií sú stovky a každý deň pribúdajú ďalšie. I tu Twitter narazil na určitý problém a to vo forme autentifikácie, ktorú používa/l. Donedávna Twitter umožňoval jedinú formu autentifikácie užívateľa cez API a to za pomoci HTTP autentifikácie (čo bol jeden z dôvodov prečo bolo možné vytvoriť skript pre získanie dát z API cez JavaScript bez vedomia užívateľa). Dnes už Twitter podporuje aj oveľa lepší OAuth, v ktorom bolo len nedávno objavená bezpečnostná zraniteľnosť, čo viedlo k dočasnému odstaveniu protokolu. Napriek tomu je tento protokol ďaleko bezpečnejší a dáva samotným užívateľom väčšiu kontrolu nad tým, čo môže aplikácie s jeho dátami robiť. To samozrejme nie jediná výhoda OAuth-u. Narozdiel od bežnej HTTP autentifikácie nemusíte v OAuth ako užívateľ poskytnúť meno a heslo, čo viedlo k ďalším bezpečnostným problémom.

Toto je len časť bezpečnosti Twitteru, keďže toto sú veci, ktoré vie Twitter ovplyvniť na svojej strane. Vďaka API sa objavili skutočne tisíce aplikácií, bez ktorých si niektorí dnes už ani nevedia fungovanie Twitteru predstaviť (resp. vie si vôbec niekto?). Práve v tom je “zakopaný pes”. Tisícky aplikácií robia tisícky programátorov s rôznymi znalosťami, skúsenosťami a teda aj rozdielnymi schopnosťami navrhnúť bezpečnú aplikáciu. Mnoho z týchto aplikácií vyžaduje niektorú z foriem autentifikácie užívateľa s Twitterom. To znamená, že užívateľ sa momentálne musí spoľahnúť nielen na bezpečnosť samotného Twittru, ale aj na bezpečnosť danej aplikácie, ktorá má vďaka API takmer rovnaké možnosti ako samotný Twitter. Ak sa teda nachádza bezpečnostná zraniteľnosť v takejto aplikácií, je užívateľ rovnako zraniteľný ako keby sa táto zraniteľnosť nachádzala na samotnom Twittri. Samozrejme, tento celý koncept vychádza len z predpokladu, že užívateľ využíva túto aplikáciu.

Dôsledky sa najlepšie ilustrujú na skutočnom príklade. Môj priateľ Aviv Raff nedávno napísal článok Cross-Web2.0 Scripting, v ktorom ukázal, akým jednoduchým spôsobom môže byť napadnutá populárna služba twitpic.com. Dôvodom je tentokrát chyba samotných programátorov mimo Twitteru, ktorí sa spoliehajú na “čistotu” dát, ktoré z twittru dostali a tie potom bez akejkoľvek úpravy (alebo opäť po nedostatočnej filtrácii) zobrazujú na svojom webe. Tento fakt môže mať za následok vznik nového červa, ktorý infikuje každého užívateľa zraniteľnej aplikácie. Ak sa útočníkovi podarí nájsť takúto zraniteľnosť na viacerých populárnych službách/aplikáciách, môže sa jednať doslova o pandémiu a postihnuté môžu byť milióny užívateľov.

Aj tu je samozrejme možnosť riešenia opäť na strane Twittru. S Avivom sme niekoľko krát preberali možnosť vytvorenia univerzálneho Web API Firewall, ktorý by vyhodnocoval prichádzajúce správy a snažil sa v nich nájsť škodlivé informácie, napríklad pokus o pridanie kusu JavaScriptového kódu do správy, atď. Tento nápad však má aj svoje muchy. Twitter dostáva každú minútu stovky tisíc správ a tak by asi bolo veľmi problematické vytvoriť takýto firewall, ktorý by dokázal spracovať také obrovské množstvo dát v reálnom čase za nízke náklady.

Je tu však aj iné riešenie, ktoré som už poslal tvorcom API a ktoré dúfam zapracujú. Celý tento bezpečnostný problém vyplýva z toho, že Twitter síce sanitizuje zobrazované dáta na svojom webe, ale pri posielaní cez API tak už nerobí. Občas je sanitizácia skutočne prekážkou a preto som navrhol takéto riešenie.

Ako príklad si vezmeme jedno z volaní, v ktorom Twitter ako odpoveď vracia informácie o užívateľovi, users/show.
Podstatou tohoto volania je poslať požiadavku na URL http://twitter.com/users/show.format spolu s niekoľkými povinnými a nepovinnými parametrami. Výsledkom sú dáta, ktoré užívateľ zadal do systému v neošetrenej podobe. Aby teda nedochádzalo k takýmto problémom, pridá sa ešte jeden nepovinný parameter, ktorý bude štandardne vedený ako TRUE a ktorý bude hovoriť o tom, či majú dáta byť ošetrené samotným API, alebo nie. Takto by sa predišlo veľkému množstvu bezpečnostných incidentov, ktoré môžu nastať.

Priamo súvisí aj bezpečnosť webov, ktoré zobrazujú zoznam vybraných twittov. Robia tak na základe Search API, ktoré im na základe požiadavky vracia len twitty, ktoré vyhovujú dopredu zadaným kritériám. Najčastejšie však tvorcovia týchto webov zabudnú na dodatočnú sanitizáciu prechádzajúcich správ a výsledkom je opäť bezpečnostná zraniteľnosť.

Opäť jedna skutočná ukážka, ktorá vám lepšie ozrejmí celú situáciu. Na screenshotoch na boku postupne môžete vidieť twitt, ktorý obsahoval HTML tag spolu s kľúčovým slovom, ktoré je vyhľadávane za pomoci Twitter Search API a zobrazované na konkrétnom webe.
Na druhom screenshote môžete vidieť už daný web, ktorý patrí projektu Eclipse Galileo a ktorý obsahoval túto bezpečnostnú chybu. Odoslaním twittu obsahujúceho HTML tag sa na samotnom Twitteri nič nestalo, ale na webe, ktorý tieto dáta získaval cez API bol tag inicializovaný (rovnako by bol aj JavaScript) a vykreslený prehliadačom.

Dôsledkom týchto chýb je prakticky výborná forma rozosielania malware na dôveryhodné weby, ktoré týmto prepožičajú svoje stránky útočníkom. Užívateľ je veľmi náchylný, ak sa objaví okno na vykonanie prakticky akejkoľvek interakcie na webe, ktorý dôverne pozná. Takto je možné infikovať doslova milióny ľudí a to vďaka len 140 znakom.

Snáď som zodpovedal rovnakú otázku tým, ktorí ma sledujú a čudujú sa, prečo z času na čas odošlem twitt s HTML tagom.

Záver

Bezpečnosť API by nemala byť ani trošku podceňovaná, pretože následky môžu byť veľmi nepríjemné. Ak zvládnete svoje API dostatočne ošetriť pre všetky formy útokov, budete mať v rukách silný nástroj, ktorý vám môže poľahky poraziť konkurenciu, alebo spopularizovať vašu službu.

Ako som spomínal na začiatku, tentokrát som sa rozhodol spraviť celé stretnutie vonku, v otvorenom priestore. Je tu určité riziko, že by mohlo byť škaredo a v takom prípade vám dám dopredu vedieť (pravdepodobne deň vopred), kde sa akcia presunie. Aj keby sa počasie na nás začalo hnevať až po príchode na miesto, v okolí je veľa podnikov, kam sa môžeme uchýliť.

Takže najdôležitejšie informácie:
Kedy: 20.06.2008 od 15:00
Miesto konania: Kuchajda (mapa)
Kontakt: meetup@synopsi.com
Facebook: Stretnutie na Facebooku

Doplnené
Ak by náhodou v sobotu pršalo, tak sa celé stretnutie presúva do reštaurácie ROSSO NERO!, ktorá je blízko Kuchajdy.

Ako vždy, budem rád, ak sa dopredu prihlásite aj na Facebooku, aby sme na vás mysleli už pred vaším príchodom. Konkrétne miesto na Kuchajde uvádzať nebudem, jazero nie je veľmi veľké a snáď už každý ma spozná podľa výzoru. Ak nie, kontaktujte ma vopred, dám vám nejaký iný kontakt.

Verím, že si užijeme príjemné posedenie a diskusiu, spolu s dobrým jedlom (majú tam cigánsku, chladné nápoje vrátane piva, langoše, atď.). Upozorňujem, že vstup na Kuchajdu je spoplatnený (kto vie prečo). Ak sa chcete poplatku vyhnúť, musíte vojsť cez bránu od Polusu a povedať, že idete “na Mólo”, čo je tamojšia reštaurácia, kde pravdepodobne skončíme, ak by pršalo.

Teším sa na stretnutie.

Od napísania prvého článku sa služba pochopiteľne rozvinula, zmenila design a bolo do nej pridaných niekoľko vylepšení. Keďže niekoľko priateľov túto službu aktívne používa, zaujímalo ma, ako je na tom s bezpečnosťou a ako moc si vzali tvorcovia moje rady k srdcu. A tak som začal pátrať. Prejsť celý web mi trvalo iba hodinu (nie je moc rozsiahly), pričom som spozoroval niekoľko príjemných vylepšení.

Tvorcovia sa snažili použiť všetky dostupné metódy pre ochranu koláčikov, aby si s nimi mohol útočník akurát tak … . Tie najchrumkavejšie koláčiky nesú vlajočky “secure” a “httpOnly“. To je skutočne skvelá správa. Taktiež pridali ochranu proti CSRF vo forme tokenov, ktoré síce nie sú bezchybné, ale aspoň tam nie sú len pre okrasu a dokážu zlámať paprčky pokušiteľom.

Nasleduje však bohužiaľ. Tvorcovia urobili niekoľko zásadných chýb, na ktoré som ich upozorňoval už vtedy a dodnes ich v podstate úplne ignorovali. Jednou z nich bola perzistentná XSS, ktorú som dokonca vtedy demonštroval v prvom videu. Táto XSS sa nachádzala v názve počítača, ktorý sa dal zmeniť priamo na webe. Tvorcovia sa uchýlili k tzv. “security through obscurity” (aj keď to nie je zrovna vzorový príklad) a zraniteľnosť považovali za zabezpečenú vďaka anti-CSRF tokenu. Ako iste viete, bez znalosti daného tokenu nemôže útočník vložiť bez vedomosti obete svoje dáta (často obsahujúce kus JavaScriptu). Teda primárnym cieľom útočníka je nájsť miesto, ako získať daný token. Ja som ho našiel behom chvíľky. Napísať jednoduchý kód, ktorý za pomoci XMLHttpRequest a Xpath získa daný token, ktorý následne použije na odoslanie týchto dát bola už maličkosť. Pridaním JavaScriptu do mena počítača, ktorý vyzerá nezmenene, pretože JavaScriptový kód nevidno, zaručí, že pri každej návšteve stránky sa skript inicializuje a znovu vykoná naprogramovanú úlohu.

Ja som si však všimol ešte jednu veľmi zaujímavú vec. DropBox umožňuje veľmi jednoducho zmeniť emailovú adresu majiteľa a to jednoduchým zadaním nového emailu. I keď služba vyžaduje pri zmene hesla zadať aj pôvodné heslo, pri emaile nevyžaduje nič. A tak bola na svete nová idea, ako získať užívateľské konto, nielen jeho dáta (i keď toto by dobrý útočník nikdy neurobil, pripraviť sa o stály prístup do konta, ktorého majiteľ o tom vôbec netuší a tak pridáva stále nové dáta). Napriek tomu sa jedna o veľmi zaujímavú a lákavú možnosť.

Celý počin si môžete pozrieť na videu nižšie. Chcel by som upozorniť, že som kontaktoval tvorcov služby a akútne chyby okamžite odstránili a podľa ich slov nasadili nejakú formu WAF (Web Application Firewall), ktorá by mala pomôcť v budúcnosti včas odhaliť akúkoľvek formu útoku.

Na záver by som chcel upozorniť, že služby ako DropBox, SugarSync, Box.net môžu byť skvelí pomocníci pri práci, hlavne ak presúvate neustále súbory medzi niekoľkými počítačmi, no je potrebné mať na pamäti aj riziko straty údajov, ako aj ich odcudzenia. Ak teda chcete na tieto úložiská vkladať citlivé súbory, vždy ich zašifrujte silnou šifrou, čim by ste mohli zaručiť ich bezpečnosť (aspoň nateraz).

Logo v stiahnuteľnej forme

Len minimum spoločností poskytuje svoje logo v stiahnuteľnej forme, najlepšie v niektorom z bežných formátov, ako napríklad eps, či pdf. Je to skutočne výnimkou ako pravidlom, pritom ak sa na vás niekto pokúsi odkázať, určite nebude mať radosť, že vaše logo bude musieť dolovať z hlavičky vášho webu a následne sa snažiť odstrániť rušivé prvky, ktoré sa tam poväčšine nachádzajú. Je to skutočne nepríjemná, pre laika veľmi otravná a zdĺhavá činnosť, ktorá často vyústi do veľmi zlých výsledkov.

Raz som počul názor, že logo na stránku v takejto forme spoločnosť nedala preto, že by ho mohol niekto ukradnúť a použiť sám. Kopírovaniu loga, jeho zaujímavých a nápaditých častí sa samozrejme vyhnúť nedá, ale to by ste ho nemohli dať skutočne nikde, ani len na hlavičkový papier, aby ho nik neokopíroval. Potom však logo stráca zmysel. Ak vám niekto skopíruje logo, sám sa vystavuje možnosti, že si ho bude niekto zamieňať s vami.

Dajte k dispozícií viacero kontaktov

Hlavne pri väčších firmách (viac ako jedna osoba) je dôležité, aby existovalo niekoľko emailov, ktoré budú plniť rozličné úlohy. Vo svete sa zaužívala tradícia anglicky napísaných kontaktov a tak by ste sa jej mali držať aspoň pri tých najzákladnejších kontaktoch.

• security@domena.sk – pre mňa jeden z najdôležitejších kontaktov. Vždy pri pokuse kontaktovať akúkoľvek spoločnosť s nájdenou zraniteľnosťou posielam email na túto adresu. Ak sa vráti chybná odozva, alebo sa nikto neozve, potom píšem na konkrétny email z webu
• press@domena.sk – email pre novinára, ktorý by mal kontrolovať najlepšie PR spoločnosti, alebo jej hovorca, alebo ktokoľvek kompetentný. Na tento email chodievajú otázky od novinárov, ktoré by ste mali zodpovedať v limitovanom čase.
• webmaster@domena.sk – email smerujúci do rúk priamo správcovi webu, resp. niekomu, kto vie ako zastihnúť niekoho kompetentného aby mu mohol tento email poslať. Často je to druhá možnosť, kam poslať objavené zraniteľnosti či prípadné technické problémy webu.
• info@domena.sk – nie som si istý, nakoľko je táto forma emailu obľúbená u nás, ale pre mňa znamená možnosť zaslať bežné otázky týkajúce sa spoločnosti

Ďalšie emaily veľmi závisia od charakteru spoločnosti. Ak spoločnosť ponúka nejaké produkty, mala by určite mať email support@domena.sk o to viac, ak sa jedná o produkty predávané online. Každá bežná spoločnosť a o to viac tie veľké (viac ako 100 zamestnancov) by mali mať segmentované emaily, aby bolo možné dosiahnuť ich odborníkov na danú problematiku. Mnohokrát sa stane, že bežný pracovník nepostúpi dôležitý technický email kompetentnej osobe, pretože mu neporozumie.

Informácie pre tlač

Ak sa vaša spoločnosť z času na čas objaví v tlači, resp. ak rozosielate oficiálne tlačové správy, bolo by dobré, keby ste ich u seba na webe nielen zlučovali na jednom mieste, ale aj umožnili novinárom získať ďalšie konkrétne informácie o vašej spoločnosti. Taktiež by nemal chýbať mailový a telefonický kontakt na kompetentnú osobu, ktorá vie novinárovi poskytnúť všetky potrebné informácie v stanovenom limite. Drvivá väčšina novinárov má uzávierky, ktoré musí stihnúť a tak aj odpovede sú často limitované časovou dobou. Ak chcete mať pod kontrolou informácie, ktoré o vás budú publikované (teda aspoň do miery, ktorá vám bola umožnená), bolo by určite lepšie, aby ste túto časť neopomínali.

Bežné informácie a kontakty

Určite by ste nemali zabudnúť na najzákladnejšie informácie, ako je celé znenie vašej spoločnosti, možno odkaz na obchodný register, adresa sídla, telefonický kontakt, ičo a prípadne aj dič, číslo účtu a určite aj mapa s trasou, ako sa k vám dostať od najznámejšieho bodu v okolí. Dnes to už skutočne nie je problém a vaším návštevníkom to môže veľmi pomôcť sa zorientovať.

Plné meno spoločnosti udávajte hlavne preto, že sa občas vyskytnú prípady, kedy sa objavia dve spoločnosti s veľmi podobnými menami, ktoré odlišuje možno len písmenko, alebo podobne. Najčastejšie sa tieto prípady objavia vtedy, ak tá druhá spoločnosť niečo vyparatí a začne sa o nej hovoriť v nie príliš lichotivých súvislostiach.

Ešte by som rád dodal, že by ste na webe mali mať telefonický kontakt, kde sa dá niekto zastihnúť aj mimo pracovnej doby, hlavne kvôli technickým poruchám, či nečakaným situáciám. Nestávajú sa bežne, ale z času na čas sa môže takýto kontakt veľmi hodiť.

Záver

Je možné, že by ste našli aj ďalšie veci, ktoré by mali byť na bežnom firemnom webe. Mne však napadli tieto, pretože mi chýbajú dosť pravidelne a často musím absolvovať veľmi frustrujúci proces, aby som sa dostal k tomu správnemu človeku, či informácií. To potom nevrhá najlepšie svetlo na spoločnosť a občas to môže vyústiť do problémov (viď kauza Azet).

Ako vždy, ak máte nejaké pripomienky, návrhy alebo nápady, píšte ich do komentárov.

A to ma privádza k hlavnej myšlienke článku. V najbližších dvoch týždňoch mám hneď niekoľko stretnutí s rôznymi predstaviteľmi investičných fondov (všetky sú zahraničné) a tak by som chcel dať priestor každému, kto sa zaujíma o túto oblasť, alebo zakladá/založil/uvažuje o založení vlastného startupu, aby mi do komentáru spísal všetky otázky, ktoré mu v tejto súvislosti napadnú a ktoré považuje za kľúčové, aby uspel. Tieto otázky píšte priamo do komentárov, ja z nich potom spravím výťah a skúsim ich postupne predniesť jednotlivým spoločnostiam (snáď ma s nimi nepošlú do čerta).

V najbližšom období by som rád začal seriál, kde by som chcel zmapovať všetko, čo postretlo mňa pri hľadaní investora, pri vymýšľaní prezentácií a ich prednese, čo považujem za dôležité a čo naopak asi od vás očakávajú investori a samozrejme, po prvom spustení alfa verzie projektu by som rád začal písať aj o ňom.

Verím, že aj takto dokážem aspoň trošku pomôcť a naviesť začínajúce projekty na tú správnu cestu za úspechom.

Ak ste niekedy zakladali internetový obchod, alebo máte web, ktorý predáva službu či produkt a museli ste implementovať platobný systém pre jednu, či viacero slovenských bánk, tak potom isto viete, aké pracné a časovo náročné môže takáto relatívne jednoduchá úloha byť. Práve projekt MONOGRAM EPayment sa snaží túto časť zmierniť do štádia, kedy bude implementácia otázkou niekoľkých minút. Knižnice sú v tomto momente dostupné v jazykoch PHP a C#, časom by sa mali objaviť ďalšie.

Podporované nie sú všetky slovenské banky, ktoré poskytujú systém online platieb, ale len tie najväčšie, resp. najbezpečnejšie z nich. Ako sa uvádza na oficiálnej stránke projektu, “platobné protokoly [nepodporovaných bánk] nepodporujú okamžité bezpečné spätné informovanie obchodníka o priebehu autorizácie platby.” I tak je zoznam relatívne veľký a zahŕňa veľkú časť potencionálnych klientov, vrátane systému CardPay, ktorý ponúka spoločnosť Tatra Banka pre spracovanie platby cez platobnú kartu.

• Podporované banky
• Slovenská Sporiteľňa – SporoPay online
• Tatra banka – CardPay
• Tatra banka – TatraPay
• VÚB – E-Platba

Ďalšie dve banky, UniCredit Bank a Volksbank budú podporované v najbližšej verzii.

Knižnice sú distribuované pod licenciou LGPL a stiahnuť si ich môžete bezplatne tu, vrátane testovacej aplikácie. K dispozícii je aj SVN pre najnovšiu verziu knižníc.

Spoločnosť spolu s knižnicami vytvorila aj testovací simulátor, na ktorom si môžete odskúšať funkčnosť svojej implementácie. Táto drobnosť vás môže zachrániť od veľkého problému, ktorý by mohol nastať, ak by ste niečo prehliadli a vaši zákazníci by nemohli zaplatiť za tovar/službu, ktorú si objednali. EPayment simulátor poskytuje presne tú istú odozvu ako banka (ktorá by mala takýto simulátor ponúkať bezplatne priamo na svojich stránkach) [peniaze vám ale na účet neprídu :)], čím vám pomôže odladiť vašu implementáciu, či už využívate knižnice MONOGRAM EPayment, alebo máte vlastné.

Nezabudnite si dávať veľký pozor na bezpečnosť, pretože práve platobná časť systému býva najviac napadanou útočníkmi pri ich pokusoch. Ak teda nájdete nejakú chybu, alebo sa stretnete s problémom, ktorý sa vám bude javiť ako podozrivý, určite ho nahláste tvorcom, ktorí sa postarajú o prípadne odstránenie chyby.

A na záver, ak by ste chceli knižnice napísať v inom jazyku, alebo ich implementovať do niektorého z frameworkov, napíšte tvorcom a oni vaše riešenie radi pridajú do portfólia (samozrejme spolu s vaším menom).

Po registrácií som sa začal potulovať po prázdnej sále, kde vystavovali rôzne startupy. Ako prví dorazili dvaja mladí študenti zo Švédska, ktorí prezentovali projekt (www.touchtech.se) zameraný na viac-dotykové zariadenia, ako napríklad iPhone, alebo Surface. Počas čakania na ďalších účastníkov konferencie sme prebrali meniacu sa situáciu vo Švédsku (súd so zakladateľmi The Pirate Bay, monitorovanie odchádzajúceho trafficu) a porovnali úroveň školstva.

To sa už vstupná hala začínala zapĺňať účastníkmi a tak sme si šli každý po svojom. Celú konferenciu som mapoval postupne na mojom twitter konte pod tagom #eis.

Zahájenie

Konferenciu zahájil Dan’l Lewin, Corporate Vice-President, Strategic & Emerging Business zo spoločnosti Microsoft na tému Podpory, resp. propagovania spoločnosti v meniacej sa dobe. Samozrejme vo svoje prednáške narážal na krízu, ktorá nás nedávno zastihla a ktorá dosť významne znížila záujem investorov o podporu novovznikajúcich spoločností. Lewin v tejto súvislosti vyhlásil: “Na vytváranie spojenectiev, podpory projektov a investovania do startupov je vždy ta správna doba, aj v dobe, keď zúri finančná kríza”. Najväčšiu podporu nových investícií majú podľa Lewina Izrael a India. Podľa grafov mnohonásobne prebiehali ostatné krajiny, vrátane USA. Slovensko bolo v grafe pravdepodobne najmenšie, menšie ako Bulharsko, alebo Rumunsko (v Európe sa zameral len na krajiny únie vrátanie Švajčiarska a Nórska). Možno nič prekvapivé, no napriek tomu zaujímavé. Z európskych krajín ma najviac startupov Anglicko, napriek nižšej podpore štátu.

V záverečnej časti prezentácie dal Lewin za určitý vzor spoločnost Microsoft, ktorá má po svete 13 výskumno-vývojových stredísk a viac ako stovku vývojových stredísk. Spoločnosť Microsoft v posledných rokov vyvíja čim ďalej tým väčšie úsilie v podpore nových a inovatívnych projektov a to napríklad aj za pomoci projektu BizSpark.

Druhú prednášku začal Jan Muehlfeit, Chairman of Microsoft Europe a napriek tomu, že som ju už raz videl v Bratislave, opäť som si ju s chuťou pozrel. Muehlfeit hneď na začiatku spomenul, že na univerzite študoval “Scientific Communism”, čo rozosmialo celé publikum. Práve táto prednáška bola zábavná, nabitá energiou a plná veľmi trefných postrehov. Muhlfeit mnohokrát spomenul, že úspech, či už krajiny, alebo spoločnosti spočíva v tom, koľko veľkých mozgov dokáže pritiahnuť a samozrejme si ich aj udržať (nie, nie je to prípad Slovenska). Muhlfeit sa v prednáške zameral aj na tzv. rozvojové krajiny, ktoré dnes začínajú preberať úlohu novátorov ako aj spotrebiteľov, ako Čína a India. Škoda, že neexistuje video záznam prednášok, táto by sa vám zaručene páčila.

Prvé kolo StartUpov

Na konferencii boli usporiadané dve kolá StartUpov, ktoré mali 5 minút na to, aby sa odprezentovali v tom najlepšom svetle. Niektoré boli zaujímavé, iné zase nie. Každú prezentáciu však sledovalo niekoľko odborníkov z investičných spoločností, ktorí na konci ohodnotili tie najlepšie prezentácie na základe siedmych kritérií.

Prvý panel

Nasledovala panelová diskusia na tému “European Innovation Ecosystem: Best practices from across Europe; top countries and ecosystem partnerships”, počas ktorej padlo niekoľko veľmi zaujímavých myšlienok, s ktorými som sa viac či menej stotožňoval. Ján Široký zo spoločnosti IDC CEMA hneď na začiatku spomenul veľmi slabú podporu štátov strednej Európy pre nové projekty, veľmi slabú podporu školstva a priveľkú byrokraciu (čo mu musí dať za pravdu každý, kto sa čo i len pokúsil v týchto končinách niečo urobiť). Účastníci panelu sa zhodli na tom, že najväčšie problémy investičných spoločností sú ich nedostatočná spoločná komunikácia a spolupráca, a veľmi striedme publikovanie nadobudnutých znalostí. Je jasné, že žiadny investor sa nechce pripraviť o dobrú šancu investovať, no práve on by mal byť ten, kto vás predstaví možno ďalším investorom aj v prípade, že on sám nemá záujem. Jean-Michel Deligny zo spoločnosti Go4Venture sa priznal, že sú v strednej Európe nový a nejaký čas potrvá, kým sa na trhu rozkukajú. Väčšina panela s ním súhlasila, čo znamená, že najbližších pár rokov sa nemusíme veľmi tešiť na prílev veľkých investícií pre nové projekty. Všetci však opäť pripomenuli, že ak sa nevytvorí dostatočne priaznivé prostredie zo strany vlád jednotlivých štátov, investori budú prichádzať len sporadicky a veľmi pomaly. Samozrejme, pozastavenie rozvoja v tejto oblasti má dnes na svedomí aj finančná kríza, ktorá podľa účastníkov panelovej diskusie znížila počet záujemcov o investovanie a teda znížila aj prostriedky jednotlivých fondov.

Druhé kolo StartUpov

Druhé kolo StartUpov bolo opäť plné rôznych projektov, ktoré sa snažili získať investorov pre svoje myšlienky. V druhom kole predstavil jediný český startup Michal Bláha www.ontheroad.to.

Druhý panel

Druhá panelová diskusia ma zaujímala omnoho viac a vyzeralo, že som nebol sám. Predstavili sa v nej predstavitelia rôznych investičných fondov, ako napríklad Suresh Patel, riaditeľ fondu Verdexus s hodnotou 1 mld. Eur, alebo Jiří Beneš zo spoločnosti 3TS Capital Partners. Diskusiu moderovala energická Jennifer L. Schenker, zakladateľka a šéfredaktorka portálu Informilo. Jej otázky boli absolútne trefné a “tvrdá ruka” neumožňovala účastníkom vybočiť z aktuálnej témy. Túto časť som na twittri pokrýval asi najviac, pretože takmer každá veta, ktorú vypustil ktorýkoľvek účastník panelu bola nabitá informáciami, ktoré sa len ťažko reprodukujú (opäť ma veľmi mrzí, že nie je vyhotovené video). Jiri Benes a Suresh Patel niekoľkokrát spomenuli aj Romana Staněka ako príklad jedného z najúspešnejších zakladateľov startupov v strednej Európe. Na jeho príklade aj vysvetľovali, kedy je spoločnosť pripravená opustiť hranicu štátu, v ktorom projekt vznikol, kedy hranice Európy (kvôli prílevu nových investícií). Jednou zo zaujímavých informácií bolo, že veľká časť niektorých fondov pochádza práve od štátu, ktorý sa takto snaží podporovať novovznikajúce projekty a samozrejme neskôr ťažiť z ich úspechu.

Najzaujímavejšie odpovede padali na otázku: Ako sa majú startupy uchádzať o prostriedky u investorov. Najlepšou z nich bola odpoveď Suresha Patela, ktorý povedal: “Ak robíte dobrý biznis, neposielajte nám vaše biznis plány/nápady. Nás nezaujímajú a skončia v koši. Ak ste dobrí, my si vás nájdeme. Robte len svoju prácu, pracujte tvrdo a snažte sa čo najskôr zaujať pozornosť niektorého z relevantných médií”.

Schenker celkom prekvapila účastníkov panela otázkou: Čo sú tri najhoršie veci, ktoré môže žiadateľ o finančné prostriedky urobiť?

• Ak len začínate, vyhľadávajte tzv. Seed Capitalists, nikoho iného
• Nesnažte sa začať úspechom, to sa ešte nikomu nepodarilo. Začnite tvrdou prácou, úspech sa dostaví sám
• Pri stretnutí sa netvárte ako utrápené smutné šteniatko, ktoré nemá ani na vodu. Hlavu hore!
• Ako CEO musíte poznať finančný stav spoločnosti. Neprenášajte svoju zodpovednosť na CFO, určite nie, ak ste StartUp
• Nechoďte na nás emóciami, iba prácou. Nám je jedno, že ste dobrý človek, to nám investície nevráti
• Neposielajte nám váš biznis plán. Ak chcete komunikovať, pošlite nám PowerPoint prezentáciu hlavnej myšlienky vášho projektu.

Asi takto by sa dali zhrnúť odpovede panelu. Možno sú niektoré trošku tvrdé a človek má po nich chuť prestať, ale v skutočnosti to nie je až také zlé, čo neskôr sami účastníci panelu uznali. Poslednú myšlienku v zozname vyzdvihol Suresh Patel niekoľkokrát ako jednu z najhorších chýb. Mnoho zakladateľov StartUpov má veľké oči a do biznis plánu nezabudnú zahrnúť miliardové výnosy, ktoré sú podľa nich už vlastne isté. “Ak teda viete, že to zarobí miliardy, nás už nepotrebujete,” povedal Patel. “Ak s nami chcete komunikovať, využívajte prostriedky na to určené, ako napríklad PowerPoint. V ňom zachyťte len hlavnú myšlienku, nie každú blbosť, čo váš projekt má a iné nie. Prezentácia nesmie mať viac ako 15 až 20 strán a musí byť zaujímavá od prvého slidu. Nepíšte tam kto ste, čo chcete, koľko máte súrodencov ani nič podobné. Držte sa len hlavnej myšlienky projektu, ktorá nemusí byť jedinečná, ale musí byť jasná a ľahko predstaviteľná. Ak nás zaujme, zvyšok si už vyžiadame sami,” dodal.

Panel sa končil búrlivým potleskom plného publika, pričom sa všetci zleteli ako kobylky okolo účastníkov panelu. Ja som na chodbe odchytil náhliaceho sa Jiřího Beneša, s ktorým som v troch rýchlych vetách predebatoval stav StartuPov na Slovensku a v Českej Republike.

Obed

Na obed som šiel v spoločnosti Suresha Patela, s ktorým sme sa však rozdelili vo veľkej fronte v reštaurácii, kde sa už vyhladovaní účastníci konferencie zbiehali okolo chutných pokrmov. A tak som si sadol ku prvému voľnému stolu, kde som anglicky požiadal dvoch mladých ľudí, či sa smiem pripojiť. Slečna sa usmiala, povedala že smiem a nezabudla v slovenčine dodať, že nemusím s nimi môžem porozprávať aj mojím rodným jazykom. A tak som objavil jediných dvoch slovákov, ktorí sa na konferencii zúčastnili. Česi boli štyria. Dvaja sa zúčastnili panelovej diskusie a dvaja prezentovali svoj StartUp. Každopádne zo slečny sa vykľula zástupkyňa nemeckej investičnej banky a tak bolo o diskusiu postarané. Ako správni slováci sme nezabudli zhodnotiť aktuálnu politickú situáciu u nás a spoločne sme si nad ňou pokrútili hlavami (na verejnosti sa vraj neplače). To sa k nám už ale pridal Suresh Patel a začala sa skutočne zaujímavá diskusia. Pán Patel sa s nami podelil o mnoho zaujímavých informácií zo sveta investícií, ako aj z niekoľkými pikoškami z doby, keď sa rozpadol Sovietsky zväz a on sa rozhodol navštíviť Prahu (19. Novembra), ako mu zmizol kufor pri príchod do hotela, atď. Pre mňa bolo toto stretnutie obohajúcim zážitkom. Pán Patel sa každému po celý čas ospravedlňoval, že nemá so sebou vizitky, no na konci celej konferencie mi jednu venoval.

Ďalšie kolá StartUpov

Nasledovali ďalšie dve kolá StartUpov, kde sa predstavili zvyšné projekty spolu so študentami z niekoľkých vysokých škol západnej Európy, ktorí svoje prezentácie prezentovali konkrétnym potencionálnym investorom (a niektorí mali veru šťastie a zaujali).

Záver

Celá konferencia bola ukončená vyhodnotením najlepších troch startupov, ktoré dostali certifikát, nejakú finančnú hotovosť a darčeky. Za usporiadateľa, spoločnosť Microsoft sa s účastníkmi rozlúčili William Stevens a Jan Muehlfeit, poďakovali za účasť a pozvali všetkých o rok na ďalší ročník konferencie (možno aj v Bratislave).

Týmto sa však pre mňa konferencia neskončila. V hale ma odchytilo niekoľko účastníkov konferencie a začali sme celkom zaujímavú diskusiu ohľadom bezpečnosti a dotkli sme sa aj mnohých iných tém. Nakoniec som k vlaku, ktorý odchádzal o tri hodiny dobiehal na poslednú chvíľu. Mrzí ma, že akcia nebola lepšie spropagovaná a že sa na nej nezúčastnili zástupcovia tlače, resp. portálov, ktorí mohli celú akciu sprostredkovať svojim čitateľom.
Fotky z akcie nemám, usporiadatelia sľúbili, že ich čo najskôr dajú na web, tak potom ich sem doplním aj ja.

Ja sa chcem poďakovať spoločnosti Microsoft a spoločnosti Neopublic Porter Novelli, že som sa mohol zúčastniť tejto skvelej konferencie, vďaka ktorej som nadviazal mnoho verím že do budúcnosti veľmi plodných vzťahov.

Dodatok na záver

Na konferencii som sa dohodol s niekoľkými investormi a odborníkmi, že ich oslovím s otázkami, ktoré by mohli zaujímať lokálnych zakladateľov startupov a všetci súhlasili, že radi na ne odpovedia. Takže v najbližších týždňoch sa vám pokúsim sprostredkovať najdôležitejšie informácie od lídrov v tejto oblasti, ktoré by vám mohli pomôcť pri budovaní vášho projektu. Ak by ste sa chceli opýtať niečo špecifické, smerujte otázky na môj twitter, alebo na email blog@synopsi.com.

Keď som si ho kupoval, boli na trhu tri zaujímavé prehrávača. Zen, Zune a iPod. Tak som kúpil všetky tri. Zune dostala priateľka, Zen brat a iPod som si nechal ja. Oni dvaja sa mi posťažovali mnohokrát na rôzne problémy, ktoré trápia tieto prehrávače, vrátane veľmi podivného správania Zune pri exspirácii predplateného programu, či prechodu na nový rok (keď globálne vypadli všetky zariadenia).

Aj keď samotný iPod má tiež svoje vrtochy. Za dva roky mi zamrzol možno 7x, čo nie je veľa, no po prvý krát ma to mierne vystrašilo, lebo nepomáhal ani reštart zariadenia. Najväčšou vadou iPodu, ktorá je hodne citeľná na Windowsoch, je ako správne hádate iTunes. Na macoch beží ako hodinky, skutočne výborne a je to veľmi kvalitný správca pre audio/video kolekciu. Na Windowse je to trošku pôrod. Od zapnutia po funkčné spustenie to trvá kľudne aj do minúty, aj napriek tomu, že mám veľmi výkonný PC s veľkou ramkou. iTunes to však nezaujíma. Nechutné sú aj aktualizácie produktu. Ak si nedáte pozor, ľahko sa vám v počítači objaví ďalší prehliadač. Apple k iTunesu pribaľuje rôzne podporné aplikácie, ktoré sa pre istotu štartujú hneď s OS, ako napríklad Bonjour.

iTunes mi už dvakrát zmazal cely playlist a trvalo mi niekoľko hodín pokým som ho obnovil aspoň do použiteľnej podoby (som nepoučiteľný a nezálohujem ho). No napriek tomu mám iTunes rád. Vďaka americkej platobnej karte mám prístup ku všetkému tovaru, ktorý iTunes ponúka (až na pár výnimiek). Za niekoľko centov mám bez námahy hudbu, ktorá sa mi páči. Nedávno bol pridaný aj Genius Bar (nemýliť si s technickou podporou v obchodoch s rovnakým názvom Genius Bar), ktorý funguje veľmi podobne ako online služba last.fm. Pre mňa zásadnou výhodou je však odporúčanie pri nákupe hudby, kedy mi GB väčšinou odporučí hudbu, ktorá sa mi skutočne páči. No a k tomu všetkému sa stal iTunes úplne DRM-FREE, pridal HD filmy, ktoré sa dajú požičať za pár dolárov a samozrejme aplikácie pre iPhone, o ktorom nedávnou napísal svoje davídek.

Toto sú však všetko veci, ktoré nájdete aj u iných spoločností. Možno nie na jednom mieste, ale pravdepodobne aj vo vyššej kvalite. Prečo mám teda rád Apple? Nedávno sa mi stala nepríjemná vec. iTunes zahlásil chybu 5002 a nešlo nič kúpiť, nefungoval ani reštart softvéru, nepomáhalo ani resetnutie chybových hlásení, no proste nič. Ako vždy, prvá cesta ma zaviedla na Google, kde som sa dočítal všetko možné ohľadom tejto chyby, len nie to, čo ju vyvoláva. Mnohé postupy boli pre mňa neakceptovateľné (vymažte všetko a stiahnite znova) a tak som siahol po supporte. Nerád volávam na hotline, pretože sa tam často ozve indicko/pakistansko/írsko/hotentótsky prízvuk a potom je to doslova boj o výslovnosť. Nemám rád ani mailovú komunikáciu, pretože trvá príšerne dlho a ja nie som zrovna trpezlivý človek. Apple však ponúka aj tretiu alternatívu, online chat so skúseným pracovníkom. No popravde, už som zažil veľa “skúsených” pracovníkov, ktorí ma doháňali k monštruóznemu hnevu. I teraz som nebol zrovna dobre naladený, no i tak som sa rozhodol risknúť túto skúsenosť. Dobrej nálade nepridalo ani hľadanie odkazu, odkiaľ sa k chatu dostať. Môžete si to skúsiť sami, mne to trvalo neuveriteľne dlho (môžete sa pochváliť, koľko to trvalo vám, štart tu).

Poznámka na okraj:
Všetky veľké americké spoločnosti pôsobiace online sa vás vždy snažia donútiť hľadať v online sekcii pre support, kde majú niekoľko tisícok strán informácií o problémoch, ktoré by ste mohli mať. Napríklad u Amazonu mi trvalo takmer hodinu nájsť email na press centrum. Môžete to skúsiť sami. Nájsť, nie tipnúť!

Keď sa mi konečne podarilo nájsť odkaz na chat, napísal som do uvítacieho okna svoj problém a spustila sa komunikácia s Danom. Pôvodne som ju chcel celú zverejniť, bohužiaľ obsahuje veľmi veľa osobných informácií a bez nich by nedával samotný text poriadny zmysel. Ale pre ilustráciu sa s vami podelím o niekoľko viet, ktoré mi Dan v našej konverzácii venoval.
Dan: Hello, Rastislav. I'm sorry to hear that you're getting a 5002 error when using the iTunes Store.
Dan: I can see why this would be a concern. I'll be happy to give you some information on how to fix this error message.
Dan: Let me ask you, are you only getting the error when attempting to buy things on the iTunes Store?
Dan: I see. Well, we usually suggest removing the credit card information from your account, and then re-adding it to resolve the error message.
Dan: So I'll be happy to walk you through removing the credit card information on your account, if you'd like.Ako môžete vidieť, jeho prvá reakcia bola poľutovanie nad celým problémom. Viem, v Amerike bežný psychologický trik, u nás neuskutočniteľný sen. Dan mi veľmi rýchlo objasnil, že chyba je na ich strane a že pomáha odstránenie a opätovné pridanie platobnej karty do konta. Nakoniec položil pre mňa trošku infantilnú otázku, či ma môže navigovať pri procese odstránenia a pridania karty. A tak som zo srandy súhlasil. Dan bol extrémne milý po celý čas našej konverzácie a napriek tomu, že som si už nakupoval vybranú hudbu, Dan ma usilovne “koučoval” až do konca. Po každom mojom “ok, done” mi napísal aký som šikovný a ako mi to ide výborne. Keď som končil tento rozhovor, bol som absolútne pokojný, vyrovnaný a uspokojený. Takto si predstavujem podporu, nech už je to kdekoľvek.

Podľa mňa dobrú spoločnosť nerobia najlepšie produkty na trhu, ale najlepšia podpora. Zaručene takou spoločnosťou nie je slovenské UPC. Aj keby mi ponúkali 1Gbit linku za 3 Eurá mesačne, i tak by som s nimi bol nespokojný. Posledné mesiace boli utrpením a každá ďalšia komunikácia s nimi ma uisťuje, že pri prvej príležitosti pôjdem k inej spoločnosti. Ich 24/7 technický hotline funguje (ako sa vyjadril jeden môj kamarát) asi len 24 hodín zo siedmych dní. Za dva mesiace ma to stálo 50 Eur. Dnes využívam malý trik. Namiesto technického sa “prešťukám” k produktovému, ktoré dvíha skôr ako to zazvoní a oni ma vždy prepoja na technické. To vidí potom číslo z firmy a rado dvíha. To je ale iný príbeh.

Áno, Apple ponúka relatívne drahé produkty, ktoré sa v lepších technických parametroch dajú kúpiť lacnejšie. Za tie peniaze si však nekupujete len samotné zariadenie ale aj fantastický support, ktorý je v čase vašej krízy (nefungujúce zariadenie, výpadok služby, atď.) na nezaplatenie. Ja som dnes presvedčený, že moje ďalšie kroky pri nákupe nového hardvéru povedú do Apple.