Admin cast, uprava textu a pridavani obrazku ... a dalsi funkce je mozne spustit jen v prohl. mozilla, Xinha editor nejde treba v Opere, na zmeny webu pouzivejte proto mozilla prohl. > FireFox

obsah prilohy nahrat do root zencart

Configuration > My Store > HTML Editor zmenis > Xinha editor

Připojit soubor:

---

Xinha_editor_for zencart 1.0a CZ.zip Velikost: 923.55 KB; Hits: 225

Srrry napsal jsem > sobory, ale jde jenom o jeden soubor > security_patch_v138_20080919.php

Malem bych zapomnel >

UPDATE k bezpecnostnimu upozorneni: SQL Injection Risk

31 Aug. byl zverejnen post upozornujici na moznost SQL Injection zranitelnosti, original tady > http://www.zen-cart.com/forum/showthread.php?t=106701

Proto je potrebne upravit php kod hned na nekolika mistech.

Security Patch se doporucuje pro verze >

vsechny v1.2.x a v1.3.x obchody by meli instalovat tento jednoduchy patch:

a) Download a unzip prilozeny file.
b) Pouzit Vas FTP program a upload-nout soubory do adr. > /includes/extra_configures/


* Tato jedina oprava je pro obe verze v1.2.x and v1.3.x
* Jestli jste pouzili patch z 31.8., muzete ho prepsat aktualnim bez nezadoucich bocnich efektu;)
* Jestli jste nepouzili patch z 31.8., nemusite :) jenom hlavne instalujte aktualni.


Podekovani Yuki Shida at zen-cart.jp za objeveni teto bezpecnostni diry.

Original patch tady >
http://www.zen-cart.com/forum/attachment.php?attachmentid=4547&d=1221882257

Happy patching

Připojit soubor:

---

security_patch_v138_20080919.php.zip Velikost: 0.80 KB; Hits: 143

<span style="color: #FF0000;">
tak toto mne opravdu dostalo

'ale vyhledavat bez diakritiky ti na utf8 nejde :)'

myslis tim, ze kdyz zadam neexistujici retezec, treba slovo káva budu hledat jako kava ? Mas pravdu opravdu to nejde :(

@setlocale(LC_TIME, 'cs_CZ.UTF-8');
LC_TIME = len lokalne pre zobr. casu
spravne to ma ma byt >
LC_ALL = vsetky lokalne premenne
@setlocale(LC_ALL, 'cs_CZ.UTF-8')

Skus >
1.Uploadni file enable_error_logging.php do adr. /includes/extra_configures/, nebo do /admin/includes/extra_configures ,jestli chces zjistit bug v adminu
2.Over si prava v adr. /cache/ musi byt pravo zapisu > 777
3.Otestuj bugove stranky
4.Otvor posledny subor /cache/myDEBUG-xxxxxxx.log a uvidis cely zoznam chyb, ktore ti urcite pomozu zistit pricinu:)
5.Nezabudni potom zmazat subor/ry enable_error_logging.php z adr. /includes/extra_configures , alebo si ho aspon premenuj na .php1 z .php

Připojit soubor:

---

debug_error_logging_utility_1-0.zip Velikost: 1.42 KB; Hits: 144

Web-coder paranoia
19 August, 2008 - 06:09 — ph4r05

Rozoberiem známe koncepty zabezpečenia webových stránok proti útokom typu únos session a pokúsim sa navrhnúť riešenia na zefektívnenie obrany proti týmto útokom.

Pri písaní článku sa nejedenraz vyskytol problém typu „čo bolo skôr: sliepka či vajce“ ( resp. problém so správnym topologickým usporiadaním grafu ), preto prosím ospravedlňte skákanie z témy do témy.

Lemma 1: Nič nie je dokonalé ( vrátane mojej gramatiky, kódov, formátovania článku... )

Myšlienky použité v článku nie sú ničím prevratné; veľa sa o tejto problematike písalo a na internete je množstvo materiálov o obrane či zneužití. Chcem upozorniť na dôležitosť tejto zraniteľnosti a ukázať spôsoby ochrany, ktoré proti útokom na session používam, keď nie je možné nasadiť https a SSL certifikáty. Článok má zmysel len z polovice bez vašich postrehov a komentárov.

In medias res:
Aby systém fungoval, potrebuje mechanizmus na generovanie kľúčov ( tokenov ), podľa ktorých overuje platnosť danej akcie. ( Ide o implementáciu stavového automatu, požiadavka na akciu musí byť v systéme zaregistrovaná)

Spracovanie požiadavky nastane až po overení platnosti kľúča. Token je unikátny pseudonáhodný reťazec na jedno použitie. Platnosť tokenov navyše zviažeme na session, aby nebolo môžné vygenerovať tisíce nových platných tokenov na akciu. Takto bude existovať maximálne jeden platný token pre jednu akciu v dannej session.

Týmto spôsobom ochránime všetky formuláre. Každý formulár dostane pri svojom vygenerovaní nový token s identifikačným číslom tokenu. Ak sa dvojica ID, token nenachádza v databáze, je formulár neplatný a nedôjde k jeho spracovaniu.
Táto koncepcia má svoje výhody. Pomerne ľahko môžeme implementovať:

1. ochranu proti floodovaniu
Obmedzením ako často, resp. koľko platných tokenov za určitý čas môže byť generovaných pre danú akciu – v závislosti od IP klienta, kľúča session klienta, typu akcie, ... Záleží od konkrétnej situácie. Ak systém detekuje preťaženie, môže istú akciu zablokovať na náhodný časový interval pre všetkých klientov [ niečo ako JAM signál na ethernete ], alebo len pre konkrétnu IP adresu. Je dôležité precízne zvážiť nastavenia hraníc pre detekciu útoku typu flood, aby mechanizmus naozaj fungoval ako obrana, nie ako pomôcka na DoS utok na systém.

2. čiastočnú ochranu proti botom, tvz. bot retardér
Obmedzením platnosti tokenu - napríklad platnosť 3 sekundy až 5 minút po vygenerovaní. Za predpokladu, že bot je natoľko „inteligentný“, že vždy prečíta token zo stránky, s ktorým sa následne pokúsi spáchať určitú akciu, podarí sa mu to až za ďalšie 3 sekundy, pretože token nadobudne platnosť až 3 sekundy po vygenerovaní. Čo predstavuje výrazné spomalenie pre bota. Ak ide o bota, ktorý používa ukradnutú session, možno nápor požiadaviek (pred limitom) ľahko zaregistrovať a účet zablokovať. Bruteforce, či slovníkový útok na prihlasovací sýstém, bude podstatne pomalší, taktiež dolovanie dát z verejných databáz. Nehovoriac o tom, že použitie systému CAPTCHA mnoho botov „odrovná“, CAPTCHA je pomerne efektívna obrana, no nemyslím si, že integrovanie CAPTCHA do každého formulára je správna cesta zabezpečovania webov)

Modelová situácia: som útočník a nerátam s tým, že obľúbený chat portál disponuje touto vymoženosťou. Spravím bota, ktorý po ukradnutí SESSID mojej profesorky vydoluje všetkých priateľov z databázy a stiahne všetku emailovú komunikáciu. V momente, ako začne môj bot získavať informácie, systém zaregistruje vniknutie a konto dočasne zablokuje. ( systém sa môže zdať ľahko prekonateľný, no v spojení s ďalšími prvkami spomenutými neskôr v článku tvorí silnejší komplex )

3. bezpečné prihlasovanie do systému bez použitia SSL
Mechanizmus predstavuje istý krok medzi http a https. Znemožňuje sniffovanie hesiel, resp. útočníkovi je získané heslo na nič. Predpokladajme, že používateľ nepatrí medzi 10% tých, čo majú vypnutý javascript. Aby formulár podporoval oba typy prihlasovania, javascript môže nastaviť skryté <input pole na nejakú hodnotu v prípade, že hashovanie funguje ( napríklad sa pokusí zahashovať vzorový reťazec a porovná ho s predlohou, ak sa nezhodujú alebo je javascript úplne vypnutý, použije sa pôvodná autentifikácia)

Prihlasovací formulár má priradený svoj token. Trik je vo využití jedinečnosti a jedno použiteľnosti tohto tokenu. Zadané heslo sa pred odoslaním zahashuje algoritmom ( napríklad SHA1 ), pričom sa pridá salt, ktorým bude práve spomínaný token.
Útočník tak síce môže odchytiť hash, ale bude mu na nič, lebo je použiteľný iba s platným tokenom, ktorý práve vypršal. ( môže ale čakať, než sa token zopakuje v rovnakej kombinácii s identifikátorom )

Na strane servera skontrolujem token, ak je platný tak:

<?php
.
.
.
$dbhash = $user->get_hash( $user_name ); // z databázy vytiahnem hash hesla používateľa
$result_hash = sha1 ( $formular_token . $dbhash ); // zahashujem s pridaným saltom
If ( $result_hash === $user_password ) { // porovnám s odoslaným heslom
return true; // zhodujú sa, autentifikácia prebehla úspešne
}
else return false;

Zatiaľ sme použili verifikaciu tokenu len na formuláre. Možno tak ošetriť aj prístup na niektoré stránky sytému, napríklad v administrácia ( back ende )

Mechanizmus tokenov má svoje výhody aj nevýhody. Môžete vyjadriť váš názor v diskusii pod článkom.

Jedna z nevýhod je zvýšená náročnosť na systém. Vygenerovaný token je nutné niekam zapísať, taktiež jeho overenie vyžaduje minimálne jedeno čítanie. Ak by mechanizmus nebol ošetrený ochranou proti floodu, mohol by sa útočník pokúsiť vygenerovať tisíce tokenov a zahltiť systém.

SESSION
Najčastejšie útoky na session mechanizmus sú:

a.) Session fixation
príklad: podhodenie obeti nám známeho Session ID ( ďalej SESSID ), ak prinútime obeť, aby klikla na odkaz:
http://youtube.com/?watch=abcdef&SESSID=43a46fc3103221a...
a následne sa prihlásila, veľmi jednoducho získame zraniteľnú autentifikovanú session

b.) Session hijacking – ukradnutie SESSID autentifikovanej obete. Keďže sa SESSID zväčša prenáša v cookie alebo v URL, je veľmi jednoduché získať ho. Obľúbené techniky sú napríklad:

* sniffovanie trafficu v lokálnych sieťach ( wifi hotspoty sú na túto techniku ako stvorené, tie s WEPkom sú často väčším magnetom pre lokálnych záškodníkov ako nešifrované siete), sniffovať môžeme aj ak obeť sedí na rovnakom káblovom switchi, jeden z útokov:
MAC flooding ( switch sa snaží učiť, aké MAC adresy su prípojené na jeho porty, výsledky ukladá do CAM tabuľky, ktorá má však limitovanú veľkosť. Cisco switche 16kb to 128kb = 100 až 100,000 položiek. Keď dôjde k preplneniu tejto tabulky, switch sa začne chovať ako hub a broadcastovať traffic na všetky porty)
* MITM (man-in-the-middle), útočník presmeruje komunikáciu medzi obeťou a serverom cez seba. Výhodou útoku je jednoduchosť injektovania dát do spojenia
* XSS útokom. Majme web ktorý obsahuje XSS zraniteľnosť a obeť na ňom autentifikovanú. Stačí naviesť obeť, aby klikla na náš odkaz využívajúci zraniteľnosť webu. Náš script prečíta SESSID obete a pošle nám ho na server. Čo ďalej to je na vás

Keď útočník smeruje útok na daný server, často krát s vytvorí bota, ktorý po získaní autentifikovanej session automatizuje dolovanie dát a prevádzanie akcií. Čím rýchlejší je útok tým lepšie. Útočník môže za pár sekúnd získať všetky želané informácie, previesť akcie a zahladiť stopy.

Ochrana SESSION:
V projektoch na zabezpečenie session používam triedu, ktorá nad ňou operuje ( implementačný detail: keďže ide o unikátny zdroj, vhodný návrhový vzor pre triedu je singleton )

Implementuje tieto spôsoby obrany:
a.) Fixácia dannej session na IP adresu klienta, keď dôjde k jej zmene platnosť session expiruje (=vyprší)
• Výhody: čiastočná obrana proti session hijackingu.
• Nevýhody:

* niektorí ISP pripájajú klientov do internetu cez systém rotujúcich ( meniacich sa podla stavu systému ) proxy serverov, čím napríklad rozkladajú záťaž na servery. Problém nastane, keď sa proxy legitímneho užívateľa zmení. Zmení sa tak aj jeho IP adresa a session expiruje. V dôsledku čoho môže používateľ stratiť niektoré dáta a je nútený za znovu prihlásiť. Jedným z takýchto ISP je napríklad AOL. Je preto na zváženie, či tento druh obrany implementovať. V mojom riešení som obranu pre klienta zo siete AOL vypol.
* neúčinné, ak sa útočník a obeť pripájajú z rovnakej adresy

b.) Fixácia session na „otlačok“ klienta – do otlačku sa zahŕňa napríklad typ a verzia browsera
• Nevýhody: pomerne jednoduchý a ľahko oklamateľný mechanizmus. Útočníkovy stačí odoslať rovnaké hlavičky ako odosielala obeť a mechanizmus prekoná. Avšak niektorích odradí.

c.) Regenerovanie SESSID s každým načítaním stránky ( tip pre väčších paranoikov: s každou požiadavkou možno meniť aj názov premennej, ktorá SESSID nesie )

Keď sa SESSID stále mení, je vhodné mať podľa čoho session identifikovať. Na tento účel bude slúžiť pseudonáhodný reťazec, ktorý bude uložený v session „bezpečne“ na strane servera, konštantný po celú dobu trvania session = SESSKEY

Doteraz nám na oklamanie mechanizmov stačilo sedieť v rovnakej učebni s rovnakým browserom. Regenerovanie SESSID je ďalším krokom od session hijackingu. Má svoje výhody aj nevýhody. Základným predpokladom je, že na jedno používateľské konto v systéme môže byť prihlásený len jeden človek.

Majme modelovú situáciu:
predpoklady:
- mechanizmy fixácie SESSID na IP adresu klienta a otlačok klienta zlyhali.
- systém je schopný rozpoznať dvoch naraz prihlásených používateľov pod jedným menom. Napríklad uložením aktuálneho kľúča session pre používateľa a času posledného vygenerovaného tokenu pre tohto používateľa.

legitímny používateľ BOB sa pripája na webmail. Jeho session je autentifikovaná. Hackerka Eva práve zistila Bobovu SESSID (napr.: session_a) a chystá sa ukradnúť Bobovi session.

V momente ako Eva použije ukradnutú SESSID na prístup do systému, systém vygeneruje pre Evu novú SESSID (session_b) a Eva je v systéme prihlásená ako Bob.

Problém však nastane, keď Bob bude chcieť komunikovať so serverom v presvedčení, že je prihlásený a že jeho session ( so SESSID = session_a) stále trvá. Avšak systém túto session už nepozná, lebo medzičasom došlo k zmene jej identifikátora. ( na session_b, session_c, ... s každou Evinou požiadavkou sa identifikátor zmenil ) Keď Bob odošle svoju požiadavku, systém mu zobrazí, že session vypršala a že sa má prihlásiť znovu. Ak sa Bob druhýkrát prihlási, systém zistí, že už niekto ako Bob je prihlásený ( má dve autentifikované session na jeden účet s rozdielnym SESSKEY)

Je množstvo možných scenárov, podľa ktorých sa môže systém chovať v takejto situácii. Jeden z nich:

Systém upozorní Boba na to, že je dvakrát prihlásený, zobrazí mu posledné prevedené akcie a upozorní ho, že môže ísť o útok. Ak Bob tieto akcie nerobil a systém ho dosť vystraší, napíše email administrátorovi a neprihlási sa, pokiaľ mu admin nenapíše ako lepšie predchádzať týmto útokom.
Ďalej ho systém upozorní na pravidlá hry (len jeden človek(browser, komp,...) na jedno konto, expirácia session po dobe nečinnosti, nutnosť regulárne sa odhlásiť po skončení práce so systémom, atď... ) zruší všetky session spojené s Bobovým účtom (Evinu a Bobovu) a zablokuje prihlasovanie na Bobovo konto na X minút.

Ak však Eva znemožní Bobovi prihlásiť sa na stránku, alebo mu podhodí svoju kópiu stránky, sú všetky spomínané mechanizmy na strane servera zbytočné ( útok realizovateľný cez MITM, prípadne aktuálnym DNS cache poisoning-om – netreba ani vykladať námahu na kradnutie session, stačí podstrčiť pharmingovú stránku a mnoho používateľov rado udá svoje prihlasovacie údaje)
Obranu klienta proti DNS cache poisoning či MITM môže zaručiť detekčný software nainštalovaný na počítači Boba.

Správanie systému je nutné precízne vyladiť podľa požiadaviek a miery paranoje administrátora tak, aby systém naozaj dobre fungoval. Častokrát to býva veľké umenie.

Ak ste sa v čítaní dostali až sem, uvítam vaše postrehy na zlepšenie tohto článku.
Ak by bol záujem, môžem zverejniť svoje kódy, ktoré implementujú spomínané spôsoby ochrany. V ďalšom dieli by som sa chcel venovať SQL injection.
Average rating





(10 votes)

* ph4r05's blog
* Login or register to post comments
* 2198 reads

Comments
Comment viewing options
Select your preferred way to display the comments and click "Save settings" to activate your changes.
23 August, 2008 - 12:13 — ehmo
ehmo's picture
Re: Web-coder paranoia

v poslednych tyzdnoch som dost bez casu, ale tvoj clanocek som si precital so zaujmom. nie je zly, som rad, ze sa o bezpecnost zaujima stale viac ludi ktori o nej aj pisu

chcel by som vsak doplnit nejake informacie.

v prvom rade tokeny su obrana proti csrf. jedna sa o najzavaznejsiu formu utoku, kedze je takmer neodhalitelna a to hlavne z dovodu, ze je cely utok identifikovany podla rfc 2616 ako bezny http request. session hijacking je dnes relativne velmi znama forma utoku a preto existuju uz base kniznice, ktore by default davaju do session previazanost na dany pocitac. velmi zaujimava myslienka je httpOnly cookie, ktora vo velkej miere dokze zabranit odcudzeniu sessid.

skoda ze si neobjasnil aj session fixation. jedna sa o utok, ked je do linky mozne pridat vlastnu session a aplikovat ju na stranku. na tuto zranitelnost bol velmi dlho nachylny aj azet.sk. dnes je to napriklad 123hry.sk. najcastejsie sa tato zranitelnost objavuje ak programator pouzije napriklad superglobalnu premennu $_SERVER['PHP_SELF'], alebo inu formu, kedy nekontroluje spravnost url a umozni tak vkladat dalsie parametre do stranky. tento utok vyzaduje davku socialneho inzinierstva

najhorsou kombinaciou zranitelnosti je xss a csrf. neviem preco ma kazdy pocit, ze xss je vyuzivany len pre ziskavanie cookies uzivatela. z mojho pohladu je to jeho posledna vyhoda. tou najvacsou je, ak utocnik dokaze vytvorit dalsi pristup, alebo zmenit napriklad registracny email. pre neho je daleko vyhodnejsie mat pristup nonstop, ako cakat, ci sa obet chyti. na session hijacking a fixation trpi vacsina bank, hlavne tie ich famozne ib systemy. ak vsak utocnik ziska moznost vykonat csrf utok, je tato zranitelnost "nezaujimva", no i tak sa nou je potrebne zaoberat.

pri tejto prilezitosti by som rad dodal, ze je treba aj rozumne uvazovat pri nasadzovani novych bezpecnostnych opatreni. uzivatel sa na vas z vysoka ... ak ho odhlasi kazdu minutu, lebo vas system sa ho snazi chranit. vzdy je potrebne hladat ochranu taku, ktora bude co najmenej zatazovat uzivatela a co najmenej ovplyvnovat jeho pohodlie. rovnako je to aj s js. dnes okolo 10% ludi nema zapnuty js (alebo ho ma zakazany) kvoli bezpecnosti. ani takyto navstevnici by vsak nemali byt ochudobnovani o prvky ochrany, pret je vzdy na zvazenie, ake bezpecnostne opatrenia vykonat.

budem cakat na dalsie tvoje clanky, celkom sa na ne tesim.
------------------------------
http://blog.synopsi.com

* Login or register to post comments

23 August, 2008 - 12:24 — ph4r05
Re: Web-coder paranoia

zdravim, diky za komentar. o session fixation som sa zmienil len okrajovo
"a.) Session fixation
príklad: podhodenie obeti nám známeho Session ID ( ďalej SESSID ), ak prinútime obeť, aby klikla na odkaz:
http://youtube.com/?watch=abcdef&SESSID=43a46fc3103221a...
a následne sa prihlásila, veľmi jednoducho získame zraniteľnú autentifikovanú session"
ale je tam naznak zneuzitelnosti :)

spojenie XSS,csr so session hijackom som sa chystal obsiahnut v dalsom clanku. kazdopadne je to velmi zaujimavy utok, na nachylnu stranku poslat XSS kod, ked si to admin vo svojom nachylnom administracnom rozhrani precita, script posle session ID a sme adminom tiez

* Login or register to post comments

24 August, 2008 - 10:47 — ehmo
ehmo's picture
Re: Web-coder paranoia

to som chcel vysvetlit uz v predoslom komentari. ak stranka obsahuje csrf, pripadne aj xss zranitelnost, tak je session fixation a hijacking absolutne nezaujimava. csrf je jedna z najhorsich zranitelnosti vobec, pretoze je takmer neodhalitelny a pritom velmi uciny
------------------------------
http://blog.synopsi.com

* Login or register to post comments

22 August, 2008 - 20:11 — ventYl
ventYl's picture
Re: Web-coder paranoia

preco do prdele je to blog a nie clanok?
---
Cuchat s nadchou, to je ako sniffovat bez promiscu.

* Login or register to post comments

22 August, 2008 - 21:09 — ph4r05
Re: Web-coder paranoia

dovod #1: pred dokoncenim som si nebol isty ci bude tento produkt hodny statusu clanku
dovod #2: v pripade spatnych reakcii citatelov. Aby nespatil index spatny clanok

ak uznas za vhodne mozes to hodit medzi clanky.
pripravujem druhy diel o SQL injection. v nie velmi blizkej buducnosti mam na plate xss utoky a prevencia, lamanie captcha, ajax <-> php interakcia cez JSON

* Login or register to post comments

25 August, 2008 - 11:32 — ventYl
ventYl's picture
Re: Web-coder paranoia

prave kvoli tomu som pred casom napisal strucne pojednanie o tom, co do blogu patri a co nie. v sucasnosti portal funguje tak, ze ktokolvek si moze zverejnit cokolvek. clanky sa neschvaluju (kazdy napisany clanok skonci niekde v zone, podla toho, kam si ho autor zaradi) a najlepsie clanky sa dostavaju aj na titulku (vzhladom k tomu, ze sa publikuje malo, konci na titulke vsetko). cize nikto nicim titulku spatit nemoze.

a ako uz pisal tommy, v drupale sa z blogu neda spravit clanok. potom su veci, ktore suvisia s bezpecnostou medzi blogmi a jak to raz zlezie z titulky, uz to nikdy nikto nenajde. nasledne je v tom bordel.
---
Cuchat s nadchou, to je ako sniffovat bez promiscu.

* Login or register to post comments

25 August, 2008 - 12:27 — ph4r05
Re: Web-coder paranoia

je mi to jasne. dalsie clanky na konci prelinkujem, aby sa blog nestratil. budem to hadzat medzi clanky

* Login or register to post comments

22 August, 2008 - 23:13 — TommyHot
TommyHot's picture
Re: Web-coder paranoia

Ono je dost problem menit druh contentu, pretoze sa nedaju preniest komentare a rucne sa to nechce robit asi nikomu.
----------
tommyhot@hackingmachine:~$ microsoft &> /dev/null

* Login or register to post comments

28 August, 2008 - 19:50 — paapi
paapi's picture
Re: Web-coder paranoia

Si si istý, že to nejde ?
UPDATE node SET type='story' WHERE nid=3457

* Login or register to post comments

28 August, 2008 - 20:45 — TommyHot
TommyHot's picture
Re: Web-coder paranoia

Dakujem za tvoj komentar, este ze mame vsetci power useri pristup k databaze ;)
----------
tommyhot@hackingmachine:~$ microsoft &> /dev/null

* Login or register to post comments

23 August, 2008 - 02:12 — ph4r05
Re: Web-coder paranoia

Sh*t... tak to je blbe. nj. moja chyba. co s tym ? ( aspon ze je tu este len par komentarov )

* Login or register to post comments

19 August, 2008 - 13:53 — tomkop
Re: Web-coder paranoia

velmi dobry clanok, uvital by som tie kody, cize trosku viac ukazok v praxi.

* Login or register to post comments

19 August, 2008 - 11:18 — pX
pX's picture
Re: Web-coder paranoia

K tomu state tokenu:
.NET ma UIPAB (User Interface Process Application Block). Pomocou UIPAB sa da spravit "mapa" stranok (nemusi ist iba o webstranky, da sa pouzit aj v client-side aplikaciach) vo forme grafu s niekolkymi vstupnymi vrcholmi. Na serverovej strane je potom pristupny ProcessController a ProcessState (oboje moze programmer extendovat a pouzivat vlastne triedy). ProcessController ma hlavne (koderom definovane) metody typu NavigatePayment(Reservation r) - ktore upravia ProcessState (typicky donho ulozia rezervaciu) a presmeruju klienta na novu pejdzu. Tato nova pejdza ma samozrejme pristup k ProcessState-u daneho usera. ProcessState nieje to to iste ako session - session zvykne identifikovat usera kdezto ProcessState identifikuje proces.

a na doplnenie bezpecne prihlasovanie na stranky bez SSL:
http://blackhole.sk/bezpecne-prihlasovanie-na-stranky-bez-ssl
==
The only reason for time is so that everything doesn't happen at once.
Albert Einstein

* Login or register to post comments

19 August, 2008 - 11:07 — zmija
zmija's picture
Re: Web-coder paranoia

clanok, je good, a velmi rad by som si precital clanok o SQL injection co si spomynal, takze tvoju pracu hodnotim velice kladne ;)

* Login or register to post comments

FCT srrry, uz tejden na > kava.kafeshop.cz