Fórumok
Van egy - sajnos megvásárolt - wordpress pluginem, amiben egy ilyen remek dolgot találtam:
if($_GET['userid']) {
$config = $wpdb->get_results("SELECT * FROM ".$wpdb->prefix."data_table WHERE id=".$_GET['userid']);
Az még nekem is marha feltűnő, hogy ez így nagyon nem pompás. Nyilván van az ilyen esetekre már kicsiszolt preg_match vagy valami más minta, amit használni illik, és biztos jobb lesz mintha én találom ki a langyos vizet.
Légyszi help, mert a PHP-hoz (is) hülye vagyok :D
Hozzászólások
if($_GET['userid']) {
$config = $wpdb->get_results("SELECT * FROM ".$wpdb->prefix."data_table WHERE id=".mysql_real_escape_string($_GET['userid']));
--
Coding for fun. ;)
A mysql_real_escape_string jó, de igazából a $wpdb ojjektum (azaz a szülő osztály) megfelelő függvényét vagy a WP beépített változó kezelését kéne használni. Ráadásul a mysql_real_escape stringnek kell egy link resource is.
Ami a hab a tortán: "Use of this extension is discouraged. Instead, the MySQLi or PDO_MySQL extension should be used. See also MySQL: choosing an API guide and related FAQ for more information."
Link: http://hu.php.net/manual/en/function.mysql-real-escape-string.php
Az extra bónusz, pedig hogy eleve üres változóra és legalább egy is_numeric-re lehetne szűrni mielőtt betolja bármilyen függvénynek és utána escape-el. :)
mysql_real_escape_string()
Ha nem rak az SQL sztringben köré aposztrófokat, akkor nem sokra jó a real escape string, csak csinál egy syntax errort legfeljebb, de egy csomó mindent le lehet kérdezni aposztrófok nélkül is. Ha tudja, hogy int lesz, akkor intval() lehet a célszerűbb, mint gyors hack. :)
A jelen esetben majdnem biztos hogy int lesz. De egy általános megoldás se lenne rossz. Egyelőre betettem a mysql_real_escape_string-et mindenhová ahol értelmét láttam.
Köszönöm a gyors segítséget :)
Ha az az ID valami numerikus dolog szeretne lenni (a kod alapjan ez a helyzet), akkor legcelszerubb arrol meggyozodni, hogy tenyleg numerikus-e (is_numeric).
Viszont ahol egy ilyen van, ott tobb is akad, altalanos megoldas viszont jelenleg nem nagyon van, max. eletehetsz valami wafot, es remenykedhetsz, hogy mukodokepes marad.
Szerencsére nincs sok plugin, épp az ilyenek miatt. Amik vannak, azokat végiggreppeltem, és láttam, hogy gondoltak a nyomorokra (pl. volt (int) a numerikus értékeknél). Ebben az egy pluginban viszont még a szándékot se leltem, ehe.
Az is_numeric()-kel figyelni kell, 0xabcd hexaban ertelmes, emiatt true. 1e10 szinten ertelmes (exponens), pedig mindkettoben vannak betuk.
Egyebkent Bobby Tables szereti feltorni az ilyen oldalakat..
--
My gold plated butt-plug business is being sued by Apple.
Apparently they have a patent for overpriced crap for arseholes.
"pedig mindkettoben vannak betuk"
Nem a betuk jelentenek gondot, hanem az ertelmezesi inkonzisztencia a kod meg a db kozott. Ha barmi, ami az is_numeric szerint szam, az a mysql szerint is, akkor nincs gond - es itt ez a helyzet.
mondjuk kezdesnek valami ilyesmi:
if(isset($_GET['userid']) && $_GET['userid'] && is_numeric($_GET['userid']) && preg_match("/^([0-9]+)$/", $_GET['userid']) ) {
$config = $wpdb->get_results("SELECT * FROM ".$wpdb->prefix."data_table WHERE id=" . (int)$_GET['userid']);
...
de en inkabb egy ilyesmi megoldasra allnek at:
if(isset($_GET['userid']) && $_GET['userid']) {
$config = $wpdb->get_results2("SELECT * FROM ".$wpdb->prefix."data_table WHERE id=?", array((int)$_GET['userid']));
...
Miert kell nekem sajnalnom a Klubradiot?
Ne halmozd...
A if ($_GET['userid']) vizsgálata önmagában korbácsolással jutalmazandó, ráadásul az isset($_GET['userid']) mellett felesleges is. Arról nem is beszélve, hogy az is_numeric() bármely értéket elfogad, amely számként értelmezhető de erre meg úgy is ott a preg_match...
Exception helyett opcionálisan lehet dobni InvalidArgumentException() -t
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Pláne, hogy az isset fv. használatán is elgondolkodnék.
array_key_exists
--
unix -- több, mint kód. filozófia.
Life is feudal
Az isset nem függvény. array_key_exists() -nek egy hátránya, hogy megengedi a null értéket is, amely nekünk jelen esetben szintén nem kell.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Az isset nem függvény.
No offense. Ha nem függvény akkor micsoda?
♲♻♲
Nyelvi konstruktor. Olyasmi, mint az 'if' vagy '&&'.
Itt egy lista róluk PHP-ban: http://php.net/manual/en/reserved.keywords.php
Itt pedig egy hosszú és részletes magyarázat példákkal: http://stackoverflow.com/questions/1180184/what-is-the-difference-betwe…
Értem, köszönöm.
♲♻♲
> Nyelvi konstruktor.
O.o Ennek ez a magyar szakirodalomban a neve? Ugye nem?
Nem inkább nyelvi elem?
Ez meg bennem is felebresztette a kigyot, es felszisszentem. A language construct szot szerette volna forditani, hat ez lett belole... Egyebkent egy kiskapus konyvben elferne ;-)
--
De.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
nem, mert konstrukció :)
Ez az egyik baj a PHP-vel: egyes nyelvi elemek úgy néznek ki, mint egy függvény (eval, list, stb. ráadásul sokan az echo-t meg a require/include[_once] -kat is függvényként ábrázolják kódban, ami AFAIK plusz egy felesleges kiértékelést okoz a zárjójel miatt), amit jobb IDE-k ugyan kiemelnek, de többnyire inkább nem.
Aztán ha valaki nem nézi meg, hogy mégis mi ez a nyelv (ami a PHPistukák 100%-a, a maradék kóderek 95%-a és a
programozók 50%), amivel dolgozik, akkor érik ilyen kellemetlen meglepetések az embert.
Arról nem is beszélve, hogy kétlem, hogy a scriptnyelvekben programozók nagy része egyáltalán tisztában van ilyen fogalmakkal, mint érték/referencia szerinti átadás, függvény, metódus, osztály, interface, absztrakció, PHP esetén, típusok közötti különbség, tömb, hashmap, list, stb.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Főleg, hogy a dokumentáció sem teljesen egyértelmű ezen a téren, hiszen itt a függvényeknél listázza:
http://php.net/manual/en/indexes.functions.php
Máshol pedig azt írja, hogy nem is igazán függvény...
♲♻♲
$wpdb->prepare kell neked.
Ha már fizettél érte, nem lehet kiverni belőlük, hogy javítsák meg? :) Elveszted a garanciát :P
--
joco voltam szevasz
ez mekkora :-)
Miert kell nekem sajnalnom a Klubradiot?
Írtam a supportnak, még semmi válasz.
Mondjuk eddig is tudtam, hogy szoftver(support)ért fizetni rettentő nagy lutri. Egyelőre még a Corel support is kevesebbet tud mint én.
meg ha mar wp, akkor olvass ide vonatkozo doksit
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Igen, ezt várnám a nagyszerű fejlesztőktől, hogy ne trágyahalmot toljanak ki a kezük közül. Alighanem ideje elkönyvelnem a veszteséget, és keresni egy másik plugint, lehetőleg olyat, amihez nem kell kézzel átmatatnom az összes érintett bejegyzést, de ez már egy másik történet.
hmm. kiket nem kell majd keresni? :)
---
Egy jól megállapított probléma félig megoldott probléma.
- Charles Kettering
http://php.net/manual/en/function.filter-input.php
esetleg ezt a $_GET -ek helyett.
Úgy látszik a mysql_real_escape_string nem jött be. Nyomtak egy ilyen get-et:
Ezzel megszerezték a szükséges e-mailt.
Majd noszogatták kicsit a wordpress-t, hogy küldjön jelszócserét:
A mysql logban szépen látszik is:
És szaporán ki is olvasták a szükséges kulcsot:
Majd jelszót váltottak, akkor már a wordpressen keresztül.
Leellenőrizem, a mysql_real_escape_stringet a javasoltnak megfelelően adtam meg, de úgy látszik nem használt. Most az indiai fejlesztő megoldását tettem be, ami egy preg_replace, de azt már le akarom cserélni egy $wpdb->prepare megoldásra, de mivel a php-hoz se értek, ezt inkább majd a hétvégén, amikor majd jobban ráérek utánaolvasni.
is_numeric()
t
(int) ? Máshol ezt láttam.
Int az csak castol, de nem validál. Tipikus látszatmegoldás hozzánemértőktől.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Tipikus hozzászólás egy olvasni/értelmezni nemtudótól... Az (int) igenis alkalmas lehet arra, hogy kiküszöbölje a problémát (feltéve, hogy csak int lehet az ID-ben). Ellenkező esetben preg->bukta, mysql_real_escape_string->bukta. Az is_numeric-re még nem láttam működő megoldást, ennek ellenére már nem használom. Prepared statement mindenhol alapból, + is_numeric/(int) (mysqli, de mivel ahhoz van még mit fejleszteni főleg hibakezelésben, át fogok térni a PDO-ra). A preg-et megkerülő megoldások előtt kalapot emeltem, ebben a ferdeszeműek az ászok :)
A PHP biztonságról lehetne hónapokig tartó szemináriumokat tartani. A kedvencem a hogyan futtassunk PHP-t egy képfájlból, de még rengeteg ilyen vicces (legtöbbször Apacs alapbeállításra/funkcióra) visszavezethető módszer van hackelni. Logokból, és orosz klienscímekből kiindulva finom dolgokat találni...
A preg miert bukta? Ebben az esetben akar meg jo is lehet, ha jo regexet valaszt a delikvens.
--
Jeleztem, hogy jelen esetben nem ér semmit a real_escape_string. Hogy miért? Mert az ugyan kiescapeeli (vagy hogy írják) a string határolókat, de a query-ben nem volt string.
A javított escapeelős kód ilyesmi lett volna:
$wpdb->get_results("SELECT * FROM ".$wpdb->prefix."data_table WHERE id='".mysql_real_escape_string($_GET['userid'])."';");
A WP-s megoldás (vaktában):
$wpdb->query( $wpdb->prepare('SELECT * FROM '.$wpdb->prefix.'data_table WHERE id=%d;', $_GET['userid']));
Legalább láthattunk egy valódi példát ennek kihasználására :)
"Legalább láthattunk egy valódi példát ennek kihasználására :)"
Jaja. Amúgy szerencsére egyelőre csak vicces a dolog :D
Jobb helyeken még mindig illene előtte ellenőrizni, hogy esetleg valóban int jött-e /o\
http://hup.hu/node/118176#comment-1512196
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Persze, hogy kell validálni, de most csak valami gyorsgány kellett, úgy értettem a kiírásból :)
Az a baj, hogy nekem nem világos, hogy hogyan fordul át a GET tartalma. A %20 nyilván szóköz lesz, így első körben lehetne vágni az első szóköztől a string végéig mindent. De nem tudom, hogy lehet-e szóközt csempészni egy sql statementbe, hogy nem a szóköz karakter van ott, illetve fogalmam sincs, hogy szóköz helyett szerepelhet-e pl. logikai operátor, olyasmi mint a &, esetleg parancselválasztó mint a bashban: ls;date Ehhez viszont sql könyvet kéne olvasnom.
Igazság szerint azt is meg kéne néznem, hogy az id-re van-e bárhol olan megkötés, validálás, hogy nem lehet benne szóköz, mert jelenleg már arra hajlok, hogy még a numerikus típus se tuti, lehet hogy string, amiben elvileg bármi lehet.
Mondjuk a tábladefiníciót megnézhetném, de most rohannom kell.
De miért kell erőlködni szóközökkel meg hasonlóval ahelyett, hogy szimplán megnézné, hogy csak szám jött-e a $_GET['id'] -ben és ha nem, szimplán elküldi az anyjába az usert?
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Mert az csak akkor jó, hogy ha az ID csak szám lehet.
De megnéztem a tábladefiníciót, int típusú az oszlop, így a probléma jelentősen egyszerűsödött.
barmi is lehet, megfeleloen validalni kell. ennyi.
t
+1. Nem Escapeléssel kell trükközni, hanem validálni, validálni, validálni...
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Pont ezért kérdeztem. Gondoltam van erre jól kitalált módszer, ezért jobb ha nem én találok ki valamit. Pláne hogy nem vagyok programozó és a php-hoz se értek. Meg az sql-hez se :D
escape-elni :)
t
Ja, egyúttal az összes többi WP exploitra is patkold meg a rendszert. Hogy melyikekre?
http://exploitsdownload.com/search?q=wordpress
--
Coding for fun. ;)
Óóó, itt nagyon cuki dolgok vannak :) És ezek még nincsenek javítva?
Hagyd már a faszba a mysql_real_escape-et.
http://hup.hu/node/118176?comments_per_page=9999#comment-1512308 ezt olvasd el végre.
1. már rég hagytam
2. elolvastam
3. honnét tudjam hogy melyik megoldást válasszam az ajánlott 3-4 közül? Pláne hogy elég sokszor jönnek cáfolatok a korábban tutinak véltre.
A megoldás alighanem a sajátom lesz, a stringet vágom az ötödik karaktertől, így az ID elmehet 99999-ig, és csak hogy legyen benne, teszek egy (int)-et.
/o\
De úgy látom tökmindegy...
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Úgy látom már két ember szerint vagyok hülye, amiért nem az Ő megoldását választom :D
Az enyém speciel a "hivatalos" filter függvény, de nem baj.
Azért csinálták, hogy ne neked kelljen tákolni. Pont ezért céloztunk a gondolkodásbeli problémákra :-)
Ha nem ezt vagy saxusét használod, csak magaddal baszol ki, ahogy az történt is.
A saxusét választottam, mert úgy döntöttem, hogy csak olyat használok fel, amit értek is. Ám abban helyből van egy tipikus hiba, helyesen így lenne szerintem:
A magyarázatát lásd itt: http://blog.php-security.org/archives/76-Holes-in-most-preg_match-filte…
Egyelőre még keresem a problémákat vele, nekem az szúrt szemet elsőnek, hogy semmiféle hosszvalidálás nincs benne, ezért keresgéltem, hogy buffer overflow-ra használható lenne-e. De mindenhol esküdöztek, hogy a php nem olyan, illetve hazafelé a metrón gondolkoztam, és gyanítom, hogy a proxy vagy a http szerver előbb kiakadna egy lehetetlenül hosszú url-en, így ez aligha lesz probléma.
Egyelőre amúgy a fejlesztő által adott preg_replace van bent, ami leginkább ennek az inverze, kitakarít kb. mindent, ami nem szám. Ez se annyira szimpatikus megoldás, ezért akarom lecserélni.
Gyorsan csináltam pár tesztet, és bugosnak tűnik a filter:
Itt tesztelem: http://blog.fisher.hu/b.php?userid=aa-------------------123a4\n5344590
Ez ezt adja vissza:
Ami nekem nem tűnik valid int-nek. Legalábbis az (int) megvetően néz rá.
php-ben a sok minuszjel legális :) ugyanis az int opcionális mínuszjelekből majd utána minimum egy számjegyből áll :-D
A 3. paramétert úgy variálod, ahogy akarod, a sanitize pl megtisztítást jelent. A validate filterekkel (pl. FILTER_VALIDATE_INT) tudsz hamist kérni, ha nem szám pl.
Itt vannak tételesen, típusonként: http://www.php.net/manual/en/filter.filters.php
Speciel így utólag, nekem sem tűnik értelmesnek a sanitize_int, ami gyakorlatilag kiszűri a nem-számjegyeket a stringből. Neked a validate fog kelleni. Ekkor:
$userid = filter_input(INPUT_GET, 'userid', FILTER_VALIDATE_INT, array('options' => array('min_range' => 0)));
echo $userid;
ez FALSE lesz ha nem szám, s a szám, ha okés. Try.
"php-ben a sok minuszjel legális :)"
Oké, de erre:
Én ezt kapom:
Try, try... ezt akartam elkerülni. De alighanem az lesz, hogy akkor FILTER_VALIDATE_INT lesz, és ha nem számként ismeri fel, akkor csinálok valamit.
Ne keverd a szezont a fazonnal :)
A ---4 és a '---4' között annyi a különbség, hogy utóbbi egy string, amely a type juggling miatt átalakítható int-té. Amelynek semmi köze a PHP nyelv syntaxisához.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Jó, de én ---4-et írtam. Azzal meg - ha int - tudni kéne mat. műveletet végezni.
intként, nem stringként. próbáld ki: echo -1 * '---4'; Tüstént nem fogsz hibát kapni. Csak php verziótól függően vagy +4et vagy nullát.
Ez PHP, nem valami erősen típusos nyelv. Ne várd a csodát.
Áh, tehát számot és stringet össze lehet szorozni? Ijesztő :(
Én abból indultam ki, hogy a (int)---4 az nulla, a (int)-4 meg -4. És nekem tulajdonképpen az utóbbira van szükségem.
En most mar tenyleg nem ertekel...
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Mint írtam, nem értek a php-hoz, nem vagyok fejlesztő se. Van egy blogom, amin volt egy hibásan megírt plugin, ehhez kértem segítséget, pont azért, mert magamtól biztos csak rosszabb megoldásokat tudnék.
Ha csak 0..9 karaktereket engedsz, helyből nem lehet benne minusz jel.
Egyébként: a két módszert lehet kombinálni is. :)
A filter_input-tal nekem a személyes problémám az, ad "default" értéket, ha hibás érték jön. Miért? Ha hibás érték jön, miért pl. az 1-es userid-t adjuk meg? (Ami jó eséllyel valami admin user). Mindezt ahelyett, hogy hibás adat esetén a próbálkozót elküldenénk melegebb éghajlatra.
Ha már mindenképp filter_input, akkor szerintem így:
(Ilyen esetben semmiképp se castold át (int)-é, különben a null értéket 0-vá castolja!)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Ha csak 0..9 karaktereket engedek, akkor eleve nincs probléma :)
Ezt mondom már mióta...
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Ezért írtam, hogy a te változatodat választottam, mert az egyszerű, csak pár perc google után már javítanom kellett.
Az ellenőrzés után azért a $wpdb->prepare() -t nem ártana propagálni, mert a WP doksi szerint is az a nyerő. Fullos exceptiont főleg nem célszerű dobni egy adott CMS-en belül, hanem a saját hibakezelő függvényét kellene bedrótozni, bár én nem értek a WP-hez sem, meg a PHP-hoz is csak kicsit. :)
Természetesen a prepare nem maradhat el.
Exception dobása meg teljesen jó lenne, mert általános. Egyetlen probléma, hogy valószínűleg a WP hírből sem ismeri (ismerve az átlag PHP-s "hiba"(nem)"kezelés", de alapvetően a probléma szempontjából lényegtelen.
Ha meg már hackelni akar valaki, akkor akár egy nyuszikát is ki lehet rajzolni a parasztnak, oly' mindegy.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Még mindíg jobb, mint a csípőből @-al indított függvénynevek, aztán jön a fejvesztő úr/hölgy, a "dehátnemmondsemmilyenhibát" és "nemlehetfejleszteniaszerveren" örökzölddel. Az hogy az éles gépen nem is kéne fejveszteni az megint egy érdekes kérdéskör. :D
Exception nem lesz, max. kap egy ártalmatlan értéket a változó.
Áh, feladom...
Viszont magyarázd már el, hogy mégis milyen logika mentén akarsz te egy érvénytelen inputra _bármiféle_ kódot végrehajtani ahelyett, hogy elhajtanád a próbálkozót a francba? :)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Szerintem az egesz mar ott bukik, hogy a userid siman get parameterkent kozlekedik oda-vissza.
Amikor par eve hackthissite-on peldakat oldottam meg, az ilyen ?userid=234 atirasa ?userid=1-re kb. a bemelegito feladatok kozt szerepelt.
--
My gold plated butt-plug business is being sued by Apple.
Apparently they have a patent for overpriced crap for arseholes.
elmagyarazhatnad, hogy miert jobb a rossz bacsiknak, ha GET-ben szalad a userid, mintha mondjuk POST-ban, vagy kukiban, whatever-ben?
Miert kell nekem sajnalnom a Klubradiot?
Jobb helyeken van egy belepeskori auth. (user/pass keres), utana - ha ez megfelelo - letarolnak egy session cookie-t, es a username/userid (amit epp hasznalnak) server oldalon marad.
Ha ehelyett a userid ide-oda kozlekedik a bongeszo es a server kozott, akkor a user siman atirhatja, es hozzaferhet mas userek adataihoz. Esetleg admin jogot is kaphat, ha annyira hulye volt a rendszert keszito indiai biorobot.
--
My gold plated butt-plug business is being sued by Apple.
Apparently they have a patent for overpriced crap for arseholes.
Ki mondta, hogy az user a saját adataihoz fér hozzá? Ld. hupon a profil oldalt meg a track oldalt. Attól, hogy userid, még nem biztos, hogy a saját userid.
Az meg hogy GET vagy POST vagy COOKIE az totálisan irreleváns. Kliens oldaltól érkező adat => meg kell győződni arról, hogy valóban az-e, amire számítunk, minden egyéb esetben meg kell tagadni a kérés kiszolgálását.
És ez totálisan független a jogosultságkezeléstől, session hijackingtól és más egyéb, magasabb szintű funkcióktól.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
A hupos pelda jogos, valoban nem csak emiatt johet be userid. Az SQL injection hegyek utan - rosszindulatuan, de talan jogosan - felteteleztem, hogy a userid-t nem erre hasznalja az illeto. Csak finoman jeleztem, hogy ez a plugin valahol az alapoknal lehet nagyon elrontva. (ha jol ertem, eddig ketszer jottek be a plugin miatt)
A GET/POST/Cookie nyilvan nem szamit, bongeszobol jon, manipulalhato.
--
My gold plated butt-plug business is being sued by Apple.
Apparently they have a patent for overpriced crap for arseholes.
Ha ehelyett a userid ide-oda kozlekedik a bongeszo es a server kozott, akkor a user siman atirhatja, es hozzaferhet mas userek adataihoz.
jahogy te igy ertetted. Ez szamomra annyira trivialis, hogy bemondasra nem hissszuk el, hogy uid=0 vagy, hanem login utan session-t nyitunk user belanak, es onnantol kezdve nem kell a userid-nek sehogysem ide-oda mennie, sot a user szamara sokszor teljesen mindegy a userid-je.
Miert kell nekem sajnalnom a Klubradiot?
Nemide.
Totálisan irreleváns.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
talan:
Rekurzivan vegigmesz az osszes user inputon es castolsz/mysql_real_escape_string()/addslashes()/etc
Összességében nézve, ez a topic nagyon szép ékes bizonyítéka annak, hogy a szakma úgy általában miért van olyan véleménnyel a (magukat programozónak hivő) PHP tákolókról, amilyenről.
Ez a topic kb. egy az egyben mehetne a TDWTF-re.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
including wordpress?
Of course.
--