printf(" SaltwaterC ");

Cu riscul de a supăra vreo câțiva spălați pe creier ce suferă de ‘fanboyism’, WordPress încă suge pe partea de securitate. Da, s-au făcut progrese, da, timpul de răspuns al echipei de dezvoltare este scăzut (vezi cazul 2.8.4), da, am eu mania unor reguli stricte (prea stricte în opinia neavizată a unora), da, am boala bug report. În fine, prin Iunie am încercat lupta împotriva morilor de vânt din punctul de vedere al posibilitaților de a lansa vectori de atac CSRF prin intermediul WordPress – folosind cont fără opțiunea de ‘unfiltered HTML’. Și da, aș fi contribuit cu un patch – deși problema nu este ușoară. Ca o paranteză, în cazul WordPress măcar am reușit să creez puțină vâlvă – alții precum cei de la SMF (Simple Machine Forums) nici în ziua de astăzi nu au răspuns la mail privind această problemă a CSRF-ului.

Sunt conștient de faptul că la nivel de WordPress problemele sunt minore sau inexistente datorită acelui sistem de token signature (wp_nonce), dar cumulat cu plug-in-uri defecte sau potențiale vulnerabilități pot duce la un efect de domino. Chiar descoperisem un plug-in vulnerabil la acest tip de atac, dar a fost patch-uit înainte să apuc să dau mail dezvoltatorului. Știu că unii pot atribui poveștii de mai sus valențe beletristice legate de droburi de sare, dar eu sunt dintre cei ce s-au mai fript cu WordPress – din fericire nu pe blogul personal. De fapt mulți dezvoltatori de plug-in-uri nu au o cultură a securității, și ca să nu fiu ipocrit, chiar și plug-in-ul subsemnatului are o problemă minoră ce ar putea fi exploatată printr-ul XSS+AJAX – deși e foarte dificil, dar nu mai este menținut din Ianuarie (va urma o rescriere completă). Iar o platformă atât de eterogenă are punctul cel mai slab localizat în codul cel mai slab – ce adesea va fi primul atacat având în vedere că acest aspect este o regulă în (in)securitate, iar caracterul deschis al platformei și plug-in-urile aferente elimină orice urmă de ’security through obscurity’.

Pe de altă parte, la anumite probleme răspunsul a fost destul de prompt. În aceeași zi cu povestirea cu CSRF-ul de mai sus am dat un mail echipei de securitate cu niște XSS vectors localizați. S-a scris despre asta, deși detaliile sunt vagi. Problema raportată se manifestă doar pe IE 6, unele și pe IE 7, dar echipa WordPress nu s-a obosit să dea detalii. Atacurile se puteau lansa prin proprietăți CSS nefiltrate. Browserele decente nu suferă de această problema, dar judecând după cota de piață a IE 6 & 7 – lucrurile nu sunt roz. Din păcate vulnerabilitatea se regăsește în toate versiunile anterioare lui 2.8.2, deci în cazul în care un blog arbitrar are posibilitatea de user registration și contribuție – este recomandat minim WP 2.8.2. Problema e însăși acea kses, menținută de către dezvoltatorii WordPress. Oficial proiectul kses e mort – nu a mai avut suport de prin 2006. Iar kses nu a fost concepută ca o bibliotecă sigură până la paranoia. Spre exemplu HTML Purifier bifează cu succes toate test case-urile ce se găsesc in cheat sheet-ul celor de la ha.ckers.org dar nu observ nici un efort în adoptarea acestuia. Au fost făcute plug-in-uri în acest sens – dar această funcționalitate ar trebui să fie ‘core level’. Filtrul WordPress a fost testat parțial de către subsemnatul – iar rezultatul îl vedeți mai sus. Nu am testat event handlers pe JavaScript pentru ca sunt 90 si ceva, iar un test case corect ar fi preferabil sa il codez, nu sa il fac de mana din motive de dimensiuni.

Din păcate, etic ar fi fost să se menționeze și cine și-a pierdut timpul pentru a le testa aplicația și raporta vulnerabilitatea. Da, nu am fost creditat. Nu este prima oară când se întâmplă, dar în cazul WordPress este deranjant pentru că dialogul nu a mers fin precum în cazul altora. Am ales metoda mail – pentru că din nou, așa e etic, spre deosebire de acțiunea de a pune totul pe grok.org ca sa panichez lumea – ce oricum pune botul la F.U.D. mai mult decât trebuie.

Știu că a vorbi este ușor și in principiu este degeaba. Cum am spus în repetate rânduri, oricine poate să își dea cu părerea – dar nu orice părere conteaza. Cam din perioada amintită mai sus tot ameninț lumea cu un blog engine implementat pe un M.V.C. framework iar motivele sunt evidente. Nu contest cantitatea de timp investită in WordPress, numărul de plug-in-uri disponibile (ce în timp devin enervante pe partea de maintenance), dar prea multă entropie și mentalitate îmbâcsită s-a strâns acolo. Dar pentru a face ceva – evident, este nevoie de timp, motiv pentru care WordPress înca se bucură de acest status quo pe care îl are având în vedere că am facut un numar consistent de deploy-uri la viața mea (iar pe unele le mențin).

Se pare ca m-am cam saturat sa ma chinui a posta articole din interfata web a WordPress deci am inceput sa cercetez optiuni alternative. In concluzie m-am dat pe client relativ dedicat cu mentiunea ca ofera totusi ceva mai multe optiuni. In principiu mare branza nu a fost, desi trebuia sa respecte o singura chestie: sa fie extensie de Firefox. Din moment ce browserul tinde sa fie al doilea sistem de operare la mine pe masina de pe care tastez, am presupus ca exista. Precum titlul o demonstreaza, exista si se numeste Deepest Sender. In caz ca inca iti este lipita de creier intrebarea: dar bine, totusi de ce o extensie de Firefox? – raspunsul este simplu: pentru ca nu scrie nicaieri faptul ca stau mereu sub Windows OS, deci printe altele o chestie dependenta de platforma limiteaza din spatiul de miscare. Da, stiu, geeky. Chiar daca nu ofera acces la absolut toate jucariile din interfata de administrare a WordPress, stie totusi sa faca vreo cateva chestii interesante:

• conturi multiple (nu e musai sa scriu doar pe blogul personal … de fapt stai, nu scriu doar pe blogul personal);
• editor rich text cu posibilitate de a vedea sursa HTML generata si un preview al formatarii;
• cica ar sti sa stea si sub forma de sidebar desi nu m-a prins acest trend pentru browser;
• drag-and-fleosc;
• baga de seama ca ii dai muzica sa roada daca ai FoxyTunes pe aproape
• baga de seama ca tastezi balarii si incearca sa te corecteze – aka spellchecking
• daca pusca Firefoxu’ (se intampla si de astea) atunci o sa incerce sa recupereze cat poate, atata timp cat Firefox-ul nu a puscat cu tot cu disk-ul pe care se afla instalat
• salvarea de drafts, desi nu poate importa draft-urile salvate folosind interfata web a WordPress
• posibilitatea de a modifica ultimele 15 post-uri de pe blog. Este o limitare ce toate engine-urile suportate inafara de LiveJournal o au. Da, Deepest Sender suporta si alte chestii pe langa WordPress.
• mod offline, posibilitatea de a salva si incarca fisiere XML in care se stocheaza articolul;
• asta e adaugata de la mine din burta (oricum nu duc lipsa) – editor rich text ce stie sa colaboreze cu persoana care tasteaza articolul in loc sa lucreze impotriva lui cum face de multe ori TinyMCE aka editorul JavaScript ce vine in mod implicit cu WordPress.
• inca una de la mine – adaugarea de imagini ofera si posibilitatea de a alinia chestiile mult mai usor decat TinyMCE si ofera posibilitatea de a da float la o imagine, chestie ce intr-un WordPress chel lipseste cu desavarsire, deci e nevoie sa se intervina in codul HTML.

In fine, nu sunt toate numai lapte si miere:

• are suficienta grija sa nu stie nimic altceva inafara de sintaxa de baza pentru a insera un link. Fara target, fara title … trist. Din fericire exista tab-ul ‘Source’ dar nu tine de cald precum echivalentul din TinyMCE.
• din pacate are mai putine optiuni de formatare, desi majoritatea sunt suficiente pentru un bloagar de asta fara nevoi speciale;
• faptul ca stie sa vada ultimele chestii postate pe blog este o chestie buna, dar limita de 15 articole este totusi un impediment. Nu stiu sigur daca este o problema cu serverul XML-PRC al WordPress sau pur si simplu o limitare a Deepest Sender.
• ar fi fost un fel de “coolness, I has it” sa poti modifica ad-labam ora la care postezi articolul asa cum interfata web stie sa o faca. Deasemenea, nu am cercetat daca e limitare de client sau de protocol.
• ar fi recomandat sa se nu se inchida clientul atata timp cat se tasteaza un articol. Desi la o deschidere ulterioara stie sa reia procesul de unde a ramas, formatarea articolului a devenit complet cretina si arata de parca a facut-o un copil beat. In rest a fost ochei … chiar mai ochei si mai ascultator decat TinyMCE. Pe deasupra disparuse si posibilitatea de a alege o categorie (o_O), desi la a doua deschidere in timp ce tastam articolul s-a comportat aproape impecabil: a uitat categoria ce o alesesem initial, in rest nu a mai pus probleme.

In conlcluzie, se pare ca o sa ramana o vreme instalat pe la mine prin browser. Flock stiu ca avea o chestie de aceasta, dar il folosesc mai rar datorita suportului slab pentru Firebug, desi e doar un Firefox 3 modificat.

Download

Later Edit: mai are un `annoyance` – si anume faptul ca refuza cu desavarsire sa se pupe cu codul XHTML valid – asta daca nu e potrivit cu mana. S-a observat abia dupa postarea articolului.

De aproximativ un an si jumatate de cand umplu acest blog cu balariile personale am inceput sa urasc de moarte spam-ul. Initial acest blog era pus pe Web de catre un engine destul de simplu, Chipmunk Blogger Script, rescris de subsemnatul in proportie de 80%. Problema spam-ului s-a pus la aproximativ 3 saptamani dupa ce site-ul era pe Web, moment in care au inceput si roboteii sa dea de blogul subsemnatului. Bomboana de pe coliva a fost faptul ca roboteii m-au prins, scuzati franceza, in curul gol. Protectia antispam era la podea, modulul de ban IP era nefunctional, si colac peste pupaza, a fost in perioada aia criminala cand o luna jumatate nu am avut Internet. Au fost suficiente 3 zile pentru ca blogul meu sa aiba peste 1600 mesaje de spam. Deci se intelege de ce ii urasc de moarte. Nu am renuntat atunci si am dat fuga la WordPress, am scris primul meu modul de captcha + dumb question (Are you human? – si implicit pe No) – modul care a fost 100% eficient cat a fost in productie. Dupa care a urmat perioada WordPress in ultimul an si ceva.

Desi WordPress vine la pachet cu Akismet care ar trebui sa apere de spam, initial acest blog, Akismet are un mod pacatos de a lucra cu serverul mama a carui baza de date cu spam o foloseste. Aceasta chestie nu functiona deloc pe hostul meu shared, free – care nu permitea conexiuni remote. Deci am descoperit Spam Karma 2. Plug-in pe care de altfel in folosesc din prima zi de WordPress blogging si de care nu cred ca o sa ma despart [prea repede?].

Sunt adeptul solutiilor KISS-compliant. Dar nu cand vine vorba de spam. Sa zicem ca mi-a pus prea multe probleme la viata mea. Am vrut propriul plug-in de WordPress, atat pentru ca voiam un proiect personal care sa aiba ceva de zis, cat si datorita faptului ca eram nemultumit de solutiile existente. Problema este ca de cand a fost acceptat in repository-ul oficial, cantitatea de spam a crescut de la aproximativ 200 de mesaje in primul an de WordPress, pana la peste 600 in prezent (in luna asta si ceva decat mi-am facut submission-ul). Si inca se incearca.

De ce SK2? Pentru ca mai nou au aparut metode tot mai inteligente de spam. Deja au inceput coderii sa stie metodele KISS compliant (gen: cel care a pus comment sa aiba anterior un comentariu aprobat, sau anumite keyword-uri). Ei bine, am gasit multi boti de spam care postau mesaje aparent nevinovate. Pareau in legatura cu subiectul, se dadeau a fi alt blogger care lasa un comment asa ca sa se afle in treaba. In realitate, majoritatea le-am primit pe pagina XHTML Video Embed, iar unii nici macar nu aveau blog WordPress! Ba mai mult … aceeasi care incercau sa castige increderea, mai incolo veneau cu adevaratul spam, dar fara keyword-uri tipice. Oricum, un simple captcha nu este suficient. Acesti spam bots s-au gasit a fi suficient de inteligenti. Desi SK2 nu are captcha in mod implicit, daca nu gaseste JavaScript si alte rahaturi, atunci baga un modul de captcha la inaintare. Ei bine, si acela a fost spart. Din fericire … dau alte semne, sunt usor de bagat in blacklist, iar odata ajunsi in blacklist, se ocupa plug-in-ul de ele.

Sincer sunt curios care va fi evolutia acestui fenomen. Personal nu imi permit sa scap o cantitate masiva … din moment ce am pus NoFollow Free, risc o penaliare de la Mr. Google.

Cei care viziteaza ceva mai des acest loc, cred ca observa chestia aia albastra din coltul stanga sus. Mentionez din start: daca nu sunteti interesati de indexare, SEO, balarii de astea ce tin de mania Google, rugamintea mea este sa dati scroll peste acest articol.

Dadusem de acest plugin acu destula vreme, dar am uitat de el … In timp ce ma plimbam din blog in blog, mi-a cazut intre ochi chestia de care pomeneam in colt, deci mi-am adus aminte instantateu de modificarea care o aveam in plan acu X zile.

Tin sa precizez ca acu 3-4 luni nu prea ma interesa capitolul SEO. Intra in categoria miscellaneous. De cand am trecut in categoria Web developerilor, orice modificare in output este trecuta prin filtrul ratiunii SEO. Asta este … intra in job description, trebuie aplicat. Evident ca primele chestii pe care le-am invatat le-am aplicat aici pe blog (vesnica mea platforma de teste, dar nu teste in sensul de “BETA”). Rezultatele au inceput sa apara dupa aproximativ doua saptamani, iar asta dupa o reindexare completa a blogului (vechiul setup din pacate nu a putut fi facut compatibil cu asta nou, deci un 301 redirect nu a mers … a trebuit sa schimb toata structura de URL-uri).

Revin la ideea enuntata initial. NoFollow Free este un plugin de WordPress care pune problema in mod invers: continutul care vine din comentarii primeste automat un rel=”external nofollow” in structura anchor-ului, fie ca e vorba de URL-ul autorului, fie ca este vorba de un URL postat de catre persoana care comenteaza. Acest plugin (destul de configurabil de altfel) indeparteaza chestia de mai sus in functie de preferinte, oferind beneficii in materie de PageRank celor care comenteaza. Intentia mea nu a fost niciodata sa tin PR-ul pentru mine … Masura aceasta a fost adoptata in WordPress pentru a evita cresterile de PR pe baza blog spam-ului. Oricum, watchdog-ul numit Spam Karma 2 sta de veghe, a scapat 2 spamuri din 270, deci personal declar deschis sezonul de indexare cu PageRank .

Download NoFollow Free »

PS: personal am idei diferite in ceea ce priveste metoda autorului de a integra functia noff(); cu tema WordPress. Apelul este unul sec <?php noff(); ?> chiar dupa <body>, ceea ce in viziunea mea este gresit din moment ce functia depinde de plugin. Parerea mea (si nu este doar parerea mea) este aceea ca orice functie apelata dintr-un plugin trebuie trecuta printr-o selectie. Apelul corect care rezolva problema activarii pluginului (exemplu: upgrade la engine-ul WordPress) este <?php if (function_exists(noff)) noff(); ?>