SA-CONTRIB-2009-081 – Abuse – Cross Site Scripting

The Abuse module enables users to flag nodes and comments as offensive, bringing them to the attention of the site maintainer for review. The module suffers from a Cross Site Scripting (Cross Site Scripting) vulnerability. Such an attack may lead to a malicious user gaining full administrative access.

O zaman gönderdiğim e-posta

Abuse module displays flagged nodes in a moderation queue without applying filters (without calling node_view) on them.

Module version: abuse 5.x-1.x-dev at (http://drupal.org/node/123349)

Steps to reproduce:

• Install abuse.module.
• Enable flagging of any content type at “admin/settings/abuse” page.
• Flag a node by using “Flag as offensive” link on “node/#nid” page.
• Go to “admin/content/abuse” page. Under any tab one can see unfiltered node contents.

Artık aynı algoritmayı uygulayan Drupal, WordPress, bbPress, phpBB ve Gallery yazılımları arasında kullanıcı hesapları parola yenilemeye gerek kalmadan taşınabilecek.

phpass algoritmasının uygulaması Drupal dağıtımındaki password.inc dosyasından alıp aşağıya eklediğim 5 satır kod içerisinde kolaylıkla anlaşılabilir.

$hash = md5($salt . $password, TRUE);
do {
  $hash = md5($hash . $password, TRUE);
} while (--$count);
$output =  $setting . _password_base64_encode($hash, 16);

Uygulama bildiğimiz “parola” + “rastgele karakterler öbeği” yöntemini temel alıyor. Parola’ya önce rastgele karakterlerden oluşan bir kelime ekleniyor. Oluşan karakter dizisi bilinen algoritmalardan biriyle (MD5, SHA1) karmaşıklaştırılıyor (hash). Daha sonra bu işlem belirli bir miktar tekrarlanıyor. En sonunda ortaya çıkan karmaşıklaştırılmış ürüne ilk belirlenen rastgele karakterler ve işlemin tekrarlanma değeri ekleniyor. Böylece kullanılan rastgele karakterler ve tekrarlanma sayısının ileride tekrar kullanılabilmesi sağlanıyor. Bilgisayarların ileride daha hızlı olacağı ve bu yöntemi aşabileceği göz önünde bulundurularak tekrarlanma miktarının her yeni Drupal sürümünde arttırılması öngörülüyor.

Pardus depolarındaki PHP paketleri bize bu desteği sağlamıyor. Bir süre önce Pardus’un hata takip sistemine durumu anlatan bir kayıt girmiştim. Umarım kısa zamanda ilgi görür.

Drupal 7.x sürümünü Pardus’a kurabilmek için PHP’yi kaynak kodlarından derlemek gerekiyor. Derlemeye hazırlanırken phpinfo() fonksiyonunun çıktısından Pardus’a özgü “configure” ayarlarını alıp bu ayarların en sonuna aşağıdaki iki ayarı ekleyin:

--with-pdo-pgsql=shared
--with-pdo-mysql=shared

Kurulum sırasında PHP “/etc/apache2/apache2.conf” dosyasının var olmasını gerektiriyor. Bu sorunu çözmek için aşağıdaki komut yeterli oluyor:

sudo ln /etc/apache2/httpd.conf /etc/apache2/apache2.conf

PHP derleme ve kurulum işlemi bittikten sonra “/etc/php/php.ini” dosyasını açıp “Dynamic Extensions” bölümünün altına aşağıdaki satırları ekleyin:

extension=pdo.so
extension=pdo_pgsql.so
extension=pdo_mysql.so

Hepsi bu kadar. Apache’yi yeniden başlattıktan sonra Drupal kurulumuna geçebilirsiniz.

Aşağıda anlatacağım yöntemler Drupal 7 sürümü için geçerlidir. Drupal 6 için bazı değişiklikler yapılması gerekebilir.

Geçen hafta Drupal’ın geliştirilmekte olan 7.x sürümü için bir yama hazırladım. Aggregator eklentisine OPML içe aktarım özelliğini getiren bu yama için bazı testler yazmam gerekti. Drupal, 7.x sürümü ile birlikte kendi test eklentisine kavuştuğu için artık testleri ile birlikte gönderilmeyen yamalar çekirdek dağıtıma kabul edilmiyor.

OPML içe aktarım özelliği için Aggregator menüsüne yeni bir form sayfası eklenmesi gerekiyordu. Kendi halinde bir sayfaya yerleştirilmiş bu form için yazdığım testler başka formlar için tam bir test kalıbı oluşturacak nitelikte oldu.

Bir Drupal formunu 3 adımda test edebiliriz. Birinci adımda önce formu oluşturur sonra beklediğimiz form alanlarının basılıp basılmadığını test ederiz.

/**
 * OPML içe aktarım formunu oluştur.
 */
function testOPMLImportForm() {
  $this->drupalGet('admin/content/aggregator/add/opml');
  $this->assertText('A single OPML document may contain a collection of many feeds.', t('Yardım metninin görüntülenmesi test ediliyor.'));
  $this->assertFieldByName('files[upload]', '', t('Dosya yükleme alanının görüntülenmesi test ediliyor.'));
  $this->assertFieldByName('remote', '', t('OPML dosyası adresi alanının görüntülenmesi test ediliyor.'));
  $this->assertFieldByName('refresh', '', t('Güncelleme alanının görüntülenmesi test ediliyor.'));
  $this->assertFieldByName('category[1]', '1', t('Dizin listesi alanının görüntülenmesi test ediliyor.'));
}

İkinci adımda form alanlarına aklımıza gelen bütün geçersiz bilgileri gireriz. Daha sonra formu gönderip ne gibi hata mesajları verdiğini test ederiz.

/**
 * OPML içe aktarım formunu geçersiz bilgiler ile gönder.
 */
function testOPMLImportFormValidate() {
  $form = array();
  $this->drupalPost('admin/content/aggregator/add/opml', $form, t('Import'));
  $this->assertRaw(t('You must <em>either</em> upload a file or enter a URL.'), t('Bilgi alanları boş bırakılmamalı hatası test ediliyor.'));
  $path = $this->getEmptyOpml();
  $form = array(
    'files[upload]' => $path,
    'remote' => file_create_url($path),
  );
  $this->drupalPost('admin/content/aggregator/add/opml', $form, t('Import'));
  $this->assertRaw(t('You must <em>either</em> upload a file or enter a URL.'), t('Dosya yükleme ve adres alanlarından yalnızca biri doldurulmalı hatası test ediliyor.'));
  $form = array('remote' => 'invalidUrl://empty');
  $this->drupalPost('admin/content/aggregator/add/opml', $form, t('Import'));
  $this->assertText(t('This URL is not valid.'), t('Girilen adres geçersiz hatası test ediliyor.'));
}

Üçüncü ve son adımda form alanlarına geçerli bilgiler gireriz. Formu gönderdiğimizde girdiğimiz bilgilerin beklediğimiz gibi işleyip işlemediğini test ederiz.

/**
 * OPML içe aktarım formunu geçerli bilgiler ile gönder.
 */
function testOPMLImportFormSubmit() {
  $feeds[0] = $this->getFeedEditArray();
  $form = array(
    'files[upload]' => $this->getValidOpml($feeds),
    'refresh'       => '900',
    'category[1]'   => 'gezegen',
  );
  $this->drupalPost('admin/content/aggregator/add/opml', $form, t('Import'));
  $feeds_from_db = db_query("SELECT f.title, f.url, f.refresh, cf.cid FROM {aggregator_feed} f LEFT JOIN {aggregator_category_feed} cf ON f.fid = cf.fid");
  $refresh = $category = TRUE;
  while ($feed = db_fetch_array($feeds_from_db)) {
    $title[$feed['url']] = $feed['title'];
    $url[$feed['title']] = $feed['url'];
    $category = $category && $feed['cid'] == 1;
    $refresh = $refresh && $feed['refresh'] == 900;
  }
  $this->assertEqual($title[$feeds[0]['url']], $feeds[0]['title'], t('Veritabanı kaydı tespit edildi.'));
  $this->assertTrue($refresh, t('Güncelleme bilgisi doğrulandı.'));
  $this->assertTrue($category, t('Dizin bilgisi doğrulandı.'));
}

Geçen gün Zend eklentisinin geliştiricisi yeterli zaman ayıramadığı için bana da CVS’ye yazma yetkisi verdi. Aslında haftalar önce bana bunu teklif etmişti fakat ben yanaşmamıştım. Geçen gün tekrar bazı yamalar hazırlayıp gönderdikten sonra bana sormadan yazma yetkisini vermiş. Artık bana da kabul etmek kalıyor.

Zend Framework eklentisi ile birlikte Drupal.org’da 6 eklentinin geliştiricisi konumundayım.

Bir süredir Joomla! ve SMF etkileşimiyle oluşturduğum bir site için alternatif arayışındaydım. Artık bu arayışım sona erdi. Drupal‘ı buldum.

Joomla! ve SMF’nin beni tatmin edememesinin bazı nedenleri var. Birincisi Joomla!’nın standart dağıtımında bir topluluk sitesi için ihtiyaç duyulan özelliklerin hiçbiri bulunmuyor. Kullanıcı yönetimi, mesaj tahtası, kişisel günlük, yorumlar, geri izlemeler ilk olarak aklıma gelen eksiklikler. Üçüncü şahısların yazmış oldukları eklentiler ise her zaman güvenlik sorunları oluşturuyor.

SMF’yi kullanmaktan vazgeçmemin ise farklı bir sebebi var. SMF’nin kullandığı lisans sözleşmesi diğer açık kaynak yazılım lisansları ile uyumsuz. Bana göre bu uyumsuzluk SMF’nin gelişimini yavaşlatıyor. Örneğin bu tarihte en güncel olan 1.1.3 sürümünde hala WYSIWYG editörü bulunmuyor. Piyasada bazı açık kaynaklı WYSIWYG editörleri bulunmasına rağmen lisans kısıtlamaları nedeniyle bu editörler SMF paketine dahil edilemiyor. Bu nedenle SMF geliştiricileri bütün bileşenleri sıfırdan yazmak zorundalar. Sonuç olarak özgür yazılım camiasının desteğinden mahrum olan SMF’nin gelişimi sancılı oluyor.

Joomla! ile SMF’nin bütünleşmesini sağlayan köprü eklentisi de lisans uyumsuzluğu nedeniyle askıya alındı. Bu nedenle yakında yepyeni sürümleri yayımlanacak olan iki yazılımın da yolları tamamen ayrılacak.

Drupal’ı tercih etmemin nedenlerine gelelim. Kullanmaya başlayalı henüz birkaç saat geçmesine rağmen yazılımdan oldukça etkilendim. Topluluk yönetimi için ihtiyaç duyulan özellikler (kullanıcı yönetimi, mesaj tahtası, kişisel günlük, yorumlar, geri izlemeler) standart dağıtımın içinde geliyor. Bu özelliği, amacım bir topluluk sitesi oluşturmak olduğunda, Drupal’ı diğer seçenekler arasında ilk tercihim yapıyor.

Drupal’ı öne çıkaran bir diğer sebep de drupal.org’daki temalar dizini. Yeni bir tema arayışına girdiğimde bakacağım ilk adres bu dizin olacaktır. Bu sayede zaman kaybı en aza inecek ve temanın güncellemelerini daha rahat takip edebileceğim.

Artık bir topluluk sitesi kurmak istediğimde yazılım tercihim Drupal olacak. Bunun dışındaki çalışmalarda işin gereksinimlerine göre diğer sistemleri göz önünde bulunduracağım.

Oylamada ilk üçe giren yazılımlar:

1. Joomla!- $5,000
2. Drupal – $3,000
3. Plone – $2,000

İnternet üzerinden yapılan oylamada bir şanslı oyveren de iPod Nano kazandı.

Haberin ayrıntılarını bu bağlantıdan okuyabilirsiniz:

http://www.packtpub.com/

İçerik yönetim sistemleri hakkında ayrıntılı bilgi için:

http://www.joomla.org/

http://drupal.org/

http://plone.org/