November 3, 2010

Dreamweaver – WordPress – Dynamically related files could not be resolved

Do Dreamweaveru pribudlo za poslednú dobu niekoľko užitočných vylepšení. Jedným z nich je aj možnosť napojenia na WordPress a ďalšie CMS (Joomla, Drupal).

Čo je však nepríjemné, tak po nastavení WordPressu a naimportovaním do Dreamweaveru, môžete naraziť toto hlásenie: “Dynamically related files could not be resolved“. Nezáleží na tom, ako aktívne stláčate Retry, chybové hlásenie zostáva. 😉

V prípade WordPressu tento problém nastane, ak sú nastavené Trvalé odkazy na inú hodnotu, než Základný. Prepnite túto hodnotu, odstráňte .htaccess a reštartujte Dreamweaver. Pozor, zmena sa bez reštartu neprejaví.

Po ťuknutí na Discover sa automaticky načítajú všetky súbory.

Ďalšie informácie o Dreamweaveri nájdete v článku od Petra Pecháčka.

Január 10, 2010

Vaše CMS je deravé ako rešeto

Aktualizované: pridané ďalšie užitočné informácie.

Je to tak. Nuž, nič moc s tým nenarobíte. Nech si zvolíte akýkoľvek softvér, vždy obsahuje chyby. Ako zabrániť útočníkovi v zneužití chyby?

Prvá a najpodstatnejšia ochrana je záloha. Stále existuje prekvapujúce množstvo webov, ktoré sú bohaté na obsah a autori nemajú skonfigurovanú ani najjednoduhšiu zálohu. V naivnej viere sa ženú do budúcnosti a dúfajú, že ich neupgradovaný CMS nenájde žiadny škaredý robot. Věd určite sa nemôže stať, aby im niekto kompletne zmazal web.

Dobrá záloha vás ochráni aj pred veľkou chybou, ako je napríklad kompletný výmaz všetkých vašich dát. Nie raz som už videl, ako človek začal mazať. Bohužial mazal iný adresár, než si myslel.

Ďalším prvkom ochrany je správna konfigurácia web servera. PHP Safe Mode síce zďaleka nie je elegantné riešenie na všetko, ale ochráni váš web server pred jednoduchými spôsobmi zneužitia. Je až zarážajúca ignorancia PHP vývojárov, ktorí nie sú ochotní napísať aplikáciu tak, aby bežala so zapnutým Safe Mode. Toto svoje správanie prehlasujú za feature a náramne ich prekvapí, keď im cez ich skvelú aplikáciu vytiahnu zoznam všetkých účtov zo servera.

Tretím prvkom je sledovanie bezpečnostných chýb, ktoré sa objavia. Nejedná sa o nič komplikované. Zvládne to aj bežný používateľ, ktorý vie pracovať s RSS. Čítačku stačí nasmerovať na Open Source Vulnerability Database a sledovať RSS softvéru, ktorý používate.

Krátky prehľad zraniteľností:

Za odkazy na OSVDB ďakujem Pavlovi Ľuptákovi zo SOIT.

Update: Pôvodne bol tento článok zameraný len základné problémy s PHP. Pavol však napísal ešte ďalší kus užitočných informácii. Časť z nich nájdete aj v jeho prezentácii. Tu je citát z jeho príspevku:

PHP Safe mod nedoporucujem pouzivat (je to “deprecated v PHP 5.3” a kompletne sa to odstrani v PHP 6), zo strany programatorov treba striktne pouzivat len
prepared statements (parametrizovane ziadosti), vid:http://php.net/manual/en/pdo.prepared-statements.php
http://sk.php.net/manual/en/function.mysqli-bind-param.php
idealne nasadit 3rd layer architekturu aplikacie (stored procedury) vstupy/vystupy idealne whitelistovat (povolit len to, co je potrebne a zvysok zakazat), proti XSS pouzivat HTML entity
http://sk2.php.net/manual/en/function.htmlentities.php
Ak ako programatori neviete co od radosti, tak mozete skusit aj PHPIDS
http://php-ids.org/

Ak mate PHP aplikaciu, do ktorej nevidite a chcete ju ochranit, tak urcite treba PHP Suhosin http://www.hardened-php.net/suhosin/, na Apacheovi
mod_security http://www.modsecurity.org/, voci SQL injection nasadit Core GRASP http://grasp.coresecurity.com/ alebo GreenSQL http://www.greensql.net/
Virtualhosty striktne segregovat (suexec/suphp) a chrootovat pod  neprivilegovanym uzivatelom. A v ramci paranoie nasadit SELinux so zapnutym RBAC/DTE/MLS idealne v strict mode.

A po tomto vsetko si mozes povedat, ze to mas trochu bezpecne …

  • Preklady

  • Odkazy

  • Twitter

    Follow @jurajmichalek on twitter.

  • Štítky

  • Rubriky

  • Komentáre