sâmbătă, octombrie 13, 2012

The Scrum Way!

Cateva probleme observate in viata de zi cu zi folosind Scrum - o sinteza de idei care mi s-au parut de folos si le-am notat aici. Daca incepeti un proiect nou sau folositi deja Scrum (agile) in proiectele voastre se poate sa va fie de folos si voua (trebuie sa aveti notiuni de baza de Scrum pentru a intelege cele descrise in continuare).


Nu toti oamenii sunt pregatiti pentru Scrum si agile dar mai ales pentru a dezvolta in echipa; la inceput scoala si mai apoi firmele de la noi nu incurajeaza echipa. Vorbesc aici de ideea de beautifull team cu oameni de valoare asemanatoare lucrand impreuna pe termen lung (indefinit) si nu de chirurg cu asistenti cum se intapla de obicei la noi. La noi se incurajeaza individul (Competence Culture bazata pe specializare, certificari, etc si nu Collaboration or Cultivation Culture). Ca un contra exemplu in scolile din Japonia, elevii fac toate activitatile din timpul zilei  impreuna in grupe iar cea mai mare pedeapsa pentru cineva este aceea de a fi exclus din grup; poate nu intamplator Scrum isi are radacini si in Japonia (Takeuchi and Nonaka - The Scrum Way). Astfel intr-o echipa Scrum trebuie detectati sabotorii si distinsi de cei care sunt doar sceptici (sunt usor de distins pe scrum board, planning, si in general prin atitudinea care o au fata de metodologie) - o solutie pentru sabotori este ca ei sa fie gestionati prin management clasic in afara echipei de Scrum.

De la inceput trebuie respectate principiile fundamentale ale metodologiei Scrum pentru a nu face de fapt dezvoltare adhoc (poate este mai rau decat a folosi efectiv si corect RUP sau orice metodologie neagila dar iterativa - exludem Waterfall despre care este stiut ca este un esec inca din anii 70 in tarile civilizate dar care la noi este folosita pe scara larga -  deoarece esecul sau succesul in proiecte nu conteaza). Empirismul in Scrum vine din reglarile pe care le facem la nivelul acestor reguli de baza (spre exemplu estimarile), dar regulile trebuie respecate absolut si nu arbitrar. De asemenea rolurile in Scrum trebuie respectate si de asemenea metricile trebuie folosite - planning cu estimari, determinarea velocity (cel mai sigur in sprint 3), mentinerea unui ritm continuu: sustainable pace. Daca nu folosim toate acestea, obtinem doar rezultate partiale cum ar fi focusare, sincronizare pentru echipa, unele sprinturi reusite.

Story-urile nu trebuie sa fie use case-uri detaliate - trebuie incurajate discutiile si nu scrierea de documente iar product owner-ul trebuie sa fie mereu disponibil pentru ceilalti pentru a le clarifica in timpul sprint-ului - nu trebuie sa faca o alta activitate (mai grav, el trebuie sa participe la stand up meeting pentru a urmari evolutia storiurilor si a actualiza backlog-ul pentru sprinturile urmatoare - atentie: nu pentru task-uri ci pentru story-urile de pe scrum board); Story-urile trebuie sa aiba o forma as a/when/then care implica si flow nu doar aspecte statice (pagini spre exemplu); pot fi initialal epics sau teme pana la grooming; de asemena, pentru a compensa lipsa specificatiilor, codul trebuie sa fie bine scris (clean code) si acoperit cu teste pentru ca el devine un fel de documentatie a proiectului (deoarece alta documentatie nu exista)

Alte principii care trebuie respectate (ordinea conteaza):
  • trebuie tinut cont ca echipa sa fie cross functional si self managed (cuprinde toti oameni de care e nevoie pentru a implementa scopul sprint-ului si nu e nevoie de nimeni din exterior sa-i gestioneze); cei care participa si in extra activitati trebuie introdusi cu o anumita norma - nu trebuie sa faca alte task-uri inafara de cele din sprint; echipa trebuie sa fie relativ constanta pentru a putea calcula velocity si a se putea forma impreuna
  • trebuie sa se lucreze incremental (un set de features facute end to end si gata de delivery in orice increment - adica nu toata aplicatia in lucru la un moment dat); Scrum este o metodologie agila (embrace change) dar si iterativa (iteratii cu cadenta fixa in timp) si incrementala (increment de funtionalitate la finalul fiecarei iteratii - eventual shipable)
  • a nu se folosi pentru inceput unelte/tool-uri sofisticate pentru ca ele nu salveaza (trebuie physical scrum board cu post its, excel product/release/sprint backlog, planning poker cards); uneltele pot fi folosite ulterior cand exista confidence interval pentru velocity
  • a se evita ownership-ul pe parti ale aplicatiei de catre dezvoltatori (chiar daca e un responsabil pe story sau task care se asigura ca va deveni done - per increment lucreaza mai multi in acelasi timp - cunostintele sunt impartasite de mai multi si se evita expuneri de interfete cu  tot felul de integrari costisitoare)
  • viata de zi cu zi a echipei trebuie sa fie ghidata de evenimentele din Scrum; metodologia trebuie sa devina un mod de viata pentru echipa in orele de lucru (ete inacceptabil ca cineva sa cheme pe ceilalti la meeting-uri!)
  • product owner nu este un project manager ci doar un membu al echipei; el nu trebuie in nici un fel sa opreasca sau limiteze creativitatea echipei - nu este responsabil de cum se implemneteaza intern story-urile; el este parte a echipei si nu un judecator al celorlalti - implicarea lui este activa, zi de zi in viata echipei (demo nu inseamna scaun de judecata si de aceea ar fi mai bine sa fie numit review)
  • definitia lui done trebuie negociata de la inceput si bine stiuta de toti (poate fi mai slaba - functionalitatea de baza si mici bug-uri deschise; sau 0 bugs); done in mod ideal inseamna automated unit/integration tested (inseamna ca membrii echipei sa foloseasca TDD, ATDD de la inceput) - testele automate garanteaza calitatea codului pe termen lung (regresii usor de facut)
  • estimarea se poate face in story points (greu la inceput din cauza diferentelor de intelegere a complexitatii si a alegerii unei referinte relativ la care sa se estimeze) care marcheaza cantitatea de munca sau ideal days care insemna spre exemlu 6 din 8 ore pentru o zi
  • product backlog trebuie sa existe inainte de sprint-uri si trebuie mereu mentinut cu grooming de story-uri si estimari noi de story points or ideal days; este datoria PO; trebuie mentinut intre sprinturi si grooming la fiecare sprint planning meeting
  • in planning evaluarea trebuie facuta pe story-uri de toti (nu doar de catre cel care o sa o implementeze - eventual folosind poker planning ca in XP - deoarece la planning nu se stie cine o sa implementeze efectiv)
  • granularitatea pe scrum board (in cazul in care se folosesc ideal days) trebuie sa fie intre 0.5 si 2 zile
    • daca e mai mica -> micromanagement
    • daca e mai mare -> surprize, surprize
  • burndown chart-ul se deseneaza in functie de estimarea a cat mai e de facut si nu a cat s-a facut (intr-un excel se tin noile estimari) - se taie estimarea de pe task si se pune noua estimare (deci nu conteaza cat timp real se pierde ci cat se estimeaza ca o sa mai fie nevoie - de fapt e o reestimare); de asemenea la calcularea velocity conteaza estimarile initiale si nu timpul real cheltuit per story-uri
  • spatiul de lucru (recomandat sa fie open office) trebuie sa fie conform metodologiei; oarecum oamenii trebuie sa stea toti impreuna; scrum board-ul trebuie sa fie langa ei

joi, octombrie 11, 2012

Posibile probleme de securitate (Web - Java)

Enumar un set de probleme de securitate care pot afecta aplicatiile Web si posibile solutii (in particular aplicatii Java bazate pe containerul de servlets). Am pastrat titlurile tipurilor de atac in engleza. Am sa incerc sa mentin lista si sa adaug si altele noi.

SQL INJECTION

Problema: din cauza crearii de query-uri SQL, HQL, JPQL concatenate folosind String-uri este posibil ca continutul introdus de utilizator sa expuna date din baza de date

Solutie: trebuie verificat ca toate query-urile sunt parametrizate folosind engine-ul de persistenta care escapeaza caracterele speciale in mod automat.  

XSS - STORED 

Problema: continutul introdus in pagina este salvat in baza de date si apare in paginile altor utilizatori (pe comments, etc); odata incarcata pagina scriptul se executa si poate trimite SESSION ID sau alte informatii la o adresa data

Solutia: escape in momentul randarii continutului dinamic (Grails: encodeAsHTML(); encodeAsURL() sau folosind ESAPI); Trebuie urmarit ca utilizatorii cu drepturi mai putine sa nu infecteze pe cei care au drepturi mai multe; spre exemplu un form de sugestii accesibil fara autentificare poate ataca prin injectare direct aplicatia de administrare; utilizatorii se pot infecta intre ei printr-un forum in care isi trimit unul altuia comentarii

XSS REFLECTED

Problema: un parametru proaspat introdus este afisat pe site fara escape; un user poate forma un url folosind acest parametru pentru a injecteaza JS in pagina si invita pe altii sa vada acest URL; la randare se executa scriptul respectiv (se poate fura session id)

Solutia: escape in momentul randarii valorii parametrilor care vin direct din request (Grails: encodeAsHTML(); encodeAsURL() sau folosind ESAPI)

MAN IN THE MIDDLE

Problema: chiar daca unele pagini au SSL (pagina de login sa zicem sau cele care contin date despre carduri - IBAN-uri) si nu se poate vedea spre exemplu parola sau alte date confidentiale de pe aceste pagini, pe paginile care nu au SSL pe acel site se pot totusi vedea alte date precum SESSION ID cookie care pot fi folosite pentru session hijacking;

Solutie: tot site-ul trebuie pus pe SSL pentru a evita orice furt de session id; trebuie stabilit daca site-ul contine date de business care pot afecta grav pe utilizator caz in care se face total SSL (exemplu ar fi aplicatiile Google care sunt total sub SSL certificat) sau este un site de entertainment caz in care se poate pune SSL doar pe unele pagini; in orice caz in site este recomandat ca schimbarea de parole sau date importante sa se faca cu parola curenta


DENIAL OF SERVICE

Problema: un user rau intententionat poate incarca sistemul prin apelari succesive de operatii costisitoare facandu-l sa cada sau sa se blocheze (se poate folosi orice tool de load prin inregistrare de scenariu via proxy si repetarea lui paralelizata); chiar daca aplicatia nu este blocata, se pot incarca costurile de hosting daca plata se face per resurse consumate (rularea injectorului poate fi fara sfarsit spre exemplu)

Solutie: folosirea de form token-uri (mecanism deja implementat in Web frameworks: Struts sau Grails) care ar face ca request-urile de pe aceeasi sesiune sa se execute oarecum secvential; trebuie tinut cont ca sesiunile/IP cu care sunt trimise cererile pot fi diferite si deci aceasta solutie este doar partiala; introducerea de limite clare pentru a diminua complexitata operatiei

BRUTE FORCE

Problema: este posibila incercarea de a face brute force pe pagina de login (sau orice pagina care implica credentials) prin incercarea repetitiva a unui numar mare de parole (folosind dictionare si/sau rainbow tables)

Solutiii: introducerea de CAPTCHA pe pagina dupa un numar de incercari (per IP si/sau session); suplimentar, folosirea de token-uri ca in Denial of service (ar opri paralelismul doar la nivel de sesiune); cea mai buna idee este audit pe login pentru a vedea IP-urile de unde vin atacurile (cereri multiple) si a le bana pentru un timp; o alta solotie este blocarea contului dupa un numar de incercari si deblocare la cerere; de tinut cont ca request-ul se poate face prin proxy care poate schimba ip-ul la nivel de protocol inainte de a atinge aplicatia tinta; de asemenea id-ul de sesiune poate fi schimbat mai ales daca pagina atacata nu este sub autentificare


GUESSABLE ID's

Problema: in aplicatie se vehiculeaza id-uri din baza de date (nu neaparat vizibile in query string: hidden fields, cookies, sau parametri vizibili in consola browserului/mesahe HTTP); de obicei id-urile din baza sint consecutive si deci sunt usor de intuit; userii cu aceleasi roluri in aplicatie pot sa vada date ale altor useri care au acelasi rol ca ei

Solutia: de evitat folosirea de id-uri in aplicatie; verificarea conditiilor de business cand se fac cereri cu id-uri (daca userul logat are voie sa le vada); folosirea altor identificatori (folosinf URL rewrite) care sa nu fie usor de ghicit (nume in loc de id daca de exeplu numele este oricum public - trebuie sa fie si unic)


WRONG URL ACCESS

Problema: este posibil ca rolurile sa nu fie bine puse pe pagini astfel incat unele pagini pot fi vazute de cei care nu au dreptul; acelasi lucru pentru apelurile de AJAX - fragmente de pagini pot ramane nesecurizate; sau unele pagini de administrare ale aplicatiei au ramas expuse dupa ce dezvoltarea s-a terminat - eventual consola de server, etc; sau erorile aplicatiei sunt logate direct in productie atunci cand se intampla

Solutie: trebuie intretinuta mereu o lista de pagini cu rolurile asociate (trebuie sa fie acoperita declarativ cu rolurile corespunzatoare in web.xml in cazul securitatii clasile JEE, security.xml sau la nivel de controlere cu adnotari in Spring); la aparitia unei erori se va redirecta spre o pagina cu eroare (404 - page not found; 403 - no rights for this page; 500 - server internal error)