Popüler PHP CMS yıllardan Tarihsel güvenlik açıkları?

8 Cevap php

Ben bir PHP CMS, ben halk tarafından kullanılabilir olacağını umuyoruz birini oluşturma. Güvenlik önemli bir konudur ve benim uygulamada onlar geçmişte olduğu bazı güvenlik açıkları veya açıklarını ne önlemek olduğunu vb Wordpress, Joomla, Drupal gibi popüler PHP CMS yıllardan bazı öğrenmek istiyorum ve ben bunları önlemek için hangi stratejileri kullanabilirsiniz? Onlar baştan doğru ele çünkü onlar belki de bir güvenlik açığı olarak yüz vermedi ile ilgili olması gereken diğer konular nelerdir? Ne ek güvenlik özellikleri veya önlemler Eğer dakika ayrıntıları sistem düzeyinde güvenlik yaklaşımları şey eklemek istiyorsunuz? Please be as specific as possible. Her zamanki saldırı vektörleri çoğunun genellikle farkında değilim, ama tüm üsleri kapalı olduğundan emin olmak istiyorum, bu yüzden de açık söz korkmayın. PHP 5.2 + varsayalım.

Edit: Ben bir topluluk wiki için bu değişen ediyorum. Arkh mükemmel cevabı kabul olsa bile bunları varsa, ben hala daha başka örnekler de ilgileniyorum.

8 Cevap

Cross-Site Request Forgery (CSRF)

Description :

Temel fikir, onun tarayıcı POST başlatmak veya saldırı CMS isteği GET edecek bir sayfaya kullanıcıyı kandırmak için.

Imagine you know the email of a CMS powered site administrator. Email him some funny webpage with whatever you want in it. In this page, you craft a form with the data used by the admin panel of the CMS to create a new admin user. Send those data to the website admin panel, with the result in a hidden iframe of your webpage. Voilà, you got your own administrator account made.

How to prevent it :

Her zamanki yolu tüm formları rastgele kısa ömürlü (saat 15mn) Nonce üretmektir. CMS bir form verilerini aldığınızda Nonce yolunda ise, ilk denetler. Aksi takdirde, veri kullanılmaz.

CMS examples :

More information :

wikipedia sayfada ve üzerine OWASP project.

Bad şifre storing

Description :

Veritabanı kesmek ve WikiLeak gibi bir şey üzerinde yayınlanan olsun düşünün. Kullanıcıların büyük bir kısmı web sitelerinin bir sürü için aynı oturum açma ve parola kullanın bilerek, bunları almak kolay olmak istiyorsun?

Veritabanı verileri kamu kalırsanız Hayır yapılan zararları azaltmak gerekir.

How to prevent it :

  • İlk fikir, onları karma etmektir. Çünkü kötü bir fikir olduğu rainbow tables (hash md5 ama örneğin sha512 olmasa bile).
  • İkinci fikir: böylece hackerlar her parolayı bruteforce zorundadır karma önce eşsiz bir rasgele tuz ekleyin. Sorun korsan hızlı karma bir sürü hesaplayabiliriz olduğunu.
  • Yani, mevcut fikir şifreleri karma için yavaş yapmak için: Eğer sık ​​sık bunu yapmayın çünkü umurumda değil. O 1 ms başına üretilen 1000 karma aldığı Ama saldırgan ağlayacağım.

Sürecini kolaylaştırmak için, phpass bazı şifre guru tarafından geliştirilen kütüphane kullanabilirsiniz.

CMS examples :

More information :

phpass page.

Cross Site Scripting (XSS)

Description

Bu saldırıların amacı, web sitenizin meşru kullanıcı tarafından idam edilecek bazı dosyasını görüntülemek yapmaktır.

Kalıcı ya da değil: Bu iki tür var. İlki kullanıcı kaydedebilirsiniz şey, gönderilen bir istek tarafından verilen parametreler üzerindeki diğer sayısında genellikle gelir. İşte bir örnek, kalıcı değildir:

<?php
if(!is_numeric($_GET['id'])){
  die('The id ('.$_GET['id'].') is not valid');
}
?>

Şimdi saldırgan sadece http://www.example.com/vulnerable.php?id=<script>alert('XSS')</script> gibi bağlantıları gönderebilirsiniz

How to prevent it

Siz müşteriye çıktı şeyi filtre gerekir. Kolay yolu, kullanıcı herhangi bir html kaydetmek izin istemiyorsanız htmlspecialchars kullanmaktır. Onları çıkış html (kendi html veya bbcode gibi diğer şeylerden üretilen bazı ya) izin Ama, çok dikkatli olmak zorunda. İşte img etiketinin "onerror" olayını kullanarak eski bir örnek: vBulletin vulnerability. Yoksa eski Myspace's Samy var.

CMS examples :

More information :

Sen wikipedia ve OWASP kontrol edebilirsiniz. Ayrıca ha.ckers sayfada XSS vektörü bir şey var.

Mail header injection

Description :

Posta başlıkları CRLF (\r\n) sekansı ile ayrılır. Eğer itibaren bunu kullanıyor gibi (postalar göndermek için bazı kullanıcı verileri kullanın: ya :) için daha başlıklarını enjekte edebilir. Bu ile, sunucudan anonim posta gönderebilirsiniz.

How to prevent it :

Üstbilgi tüm \n, \r, %0a ve %0d karakteri filtre.

CMS examples :

More information :

Wikipedia her zamanki gibi iyi bir başlangıçtır.

SQL Injection

Description :

Eski klasik. Doğrudan kullanıcı girişini kullanarak bir SQL sorgusu oluşturmak zaman olur. Gerektiği gibi bu giriş hazırlanmış ise, bir kullanıcı o tam olarak ne istediğinizi yapabilirsiniz.

How to prevent it :

Simple. Don't form SQL queries with user input. Use parameterized queries. Consider any input which is not coded by yourself as user input, be it coming from the filesystem, your own database or a webservice for example.

CMS example :

More information :

Wikipedia ve OWASP konuda gerçekten iyi sayfaları var.

Http response splitting

Description :

E-posta başlığı gibi, http başlıkları CLRF dizisi ile ayrılır. Uygulama çıktı başlıklarına kullanıcı girişi kullanıyorsa, kendi tekne için kullanabilirsiniz.

How to prevent it :

Gibi e-postalar için, filtre \n, \r, %0a ve başlığının bir parçası olarak kullanmadan önce kullanıcı girişi %0d karakter. Sen de urlencode senin başlıkları.

CMS examples :

More information :

Ben size saldırı, bu tür hakkında bilgilerin bir çok şey bulabileceğiniz gibi biraz tahmin izin vereceğim. OWASP ve Wikipedia.

Session hijacking

Description :

In this one, the attacker want to use the session of another legitimate (and hopefully authenticated) user. For this, he can either change his own session cookie to match the victim's one or he can make the victim use his (the attacker's) own session id.

How to prevent it :

Nothing can be perfect here : - if the attacker steal the victim's cookie, you can check that the user session matches the user IP. But this can render your site useless if legitimate users use some proxy which change IP often. - if the attacker makes the user use his own session ID, just use session_regenerate_id to change the session ID of a user when his rights change (login, logout, get in admin part of the website etc.).

CMS examples :

More information :

Konuyla ilgili Wikipedia sayfa.

Other

  • User DoSing : if you prevent bruteforcing of login attempt by disabling the kullanıcı adıs tried and not the IP the attempts come from, anyone can block all your users in 2mn. Same thing when generating new şifres : don't disable the old one until the user confirm the new one (by loging with it for example).
  • Dosya sistemi üzerinde bir şeyler yapmak için kullanıcı girişi kullanma. Bu yardımları ile karışık kanser olsaydı böyle Filtre. Bu kaygı kullanımı dahildir ve yolu, kullanıcı girişi kısmen yapılır dosyalarda gerektirir.
  • eval, system, exec ya da kullanıcı girişi ile birlikte, bu tür bir şey kullanma.
  • Eğer web erişilebilir dizininde web erişilebilir istemediğiniz dosyaları koymayın.

Eğer OWASP sayfada okuyabilirsiniz bir çok şey var.

Ben phpBB gelen oldukça komik bir tane hatırlıyorum. Autologin çerez bir kullanıcı kimliği ve şifreli şifreyi (tuz) içeren bir tefrika dizi içeriyordu. Gerçek değeri ile bir mantıksal şifresini değiştirin ve sen olmak istedim herkes gibi giriş yapabilirsiniz. Eğer weaktyped dil sevmiyor musun?

Örneğin, sistem güvensiz sistemlerde aramaları - phpBB olduğu bir diğer konu, kendi PHP kodu çalıştırmak için etkin, hangi ile (e modifier) bir geri vardı arama anahtar kelime vurgusu için bir düzenli ifade oldu ya da sadece çıkış MySQL giriş / parola almak için yapılandırma dosyası.

Yani bu hikayeyi özetlemek için:

  • PHP weaktyped olduğu için dikkat (md5( "secretpass" ) == true).
  • Bir geri (ya da daha kötüsü, eval) olarak kullanılabilecek tüm kodu ile dikkatli olun.

Ve tabii ki zaten benden önce bahsedilen diğer konular vardır.

Ben ile CMSes anlaşma gördüğüm başka bir uygulama düzeyinde güvenlik sorunu yetersiz sayfasını veya işlev düzeyinde erişim yetkisi olduğunu. Diğer bir deyişle, güvenlik bu bağlantıları görmek için yetkili yalnızca bağlantıları gösteren, ancak tam kullanıcı hesabı sayfayı görüntülemek veya sayfada kez işlevselliği kullanmak için yetkili olduğunu kontrol etmiyor tarafından ayarlanmaktadır.

Diğer bir deyişle, bir yönetici hesabı bağlantılar kullanıcı yönetimi sayfalara gitmek için sergiledi. Ancak kullanıcı yönetimi sayfası sadece kullanıcı onlar ve yönetici oturum değil, kaydedilir denetler. Düzenli kullanıcı daha sonra kullanıcı yönetim sayfalarına tam yönetici erişimine sahip sonra, yönetici sayfasında URI elle türleri içinde günlükleri ve bir yönetici dikkate onların hesabını yapar.

Ben bile kullanıcı CC veri görüntülenebilir alışveriş sepeti uygulamaları böyle şeyler gördüm kaç kez şaşıracaksınız.

Bu kadar çok insan farkında unutmak ya da değil ya gibi büyük bir kimse, bir kullanıcı oturum sırf, vb kurabiye ve oturumları dahil olmak üzere komut, herhangi bir veri gönderebilir Ve unutma ki, onlar anlamına gelmez herhangi bir işlem yapabilirsiniz.

Eğer bir açıklama ekleme / düzenleme işleyen bir senaryo vardı Örneğin, bu olabilir:

if ( userIsLoggedIn() ) {
    saveComment( $_POST['commentid'], $_POST['commenttext'] )
}

Sorunun ne olduğunu görebilir miyim? Siz kullanıcı kaydedilir, ancak kullanıcı Yorum sahibi veya yorum düzenlemek mümkün olup olmadığını kontrol etmediğini kontrol etti. Hangi herhangi bir giriş yapmış kullanıcı Yorum kimliği ve içerik ve düzenleme başkalarının Yorum göndermek olabilir demektir!


Başkalarına yazılım sağlayarak zaman Başka bir şey hatırlamıyorum sunucu set up çılgınca değişir olmasıdır. Veri yayınlanmıştır olduğunda örneğin, bunu yapmak isteyebilirsiniz:

if (get_magic_quotes_gpc())
    $var = stripslashes($_POST['var']);
else
    $var = $_POST['var'];

Yani bu kadar çok ..

Burada cevaplar bir dizi hatırlamak belirli VULS veya genel "i webapp yazarken endişelenecek bir şeyler" listesi vardır, ama tarihsel olarak bulundu bildirilen güvenlik açıklarının bir çoğunluğu oldukça güvenilir bir liste istiyorsanız, o zaman daha kötü yapmazdı National Vulnerability Database aramak için

Joomla veya Joomla eklentiler, Wordpress için 199 ve sindirmek için Drupal için 345 rapor 582 güvenlik açıkları vardır.

Ortak webapp VULS jenerik anlaşılması için, OWASP Top Ten project Son zamanlarda herhangi bir web geliştirici için önemli bir okuma güncellenir ve olmuştur.

  • A1: Enjeksiyon
  • A2: Cross-Site Scripting (XSS)
  • A3: Kırık Kimlik Doğrulama ve Oturum Yönetimi
  • A4: Güvensiz Doğrudan Nesne Referanslar
  • A5: Cross-Site Request Sahteciliği (CSRF)
  • A6: Güvenlik misconfiguration
  • A7: Güvensiz Kriptografik Depolama
  • A8: URL Access sınırla uyulmaması
  • A9: Yetersiz Taşıma Katmanı Koruma
  • A10: unvalidated yönlendirmeler ve Forvetler

Aklımda dört büyük olanlar:

  • Güvenilmeyen veri / kod üzerinde exec kullanarak (ya da genel olarak)
  • dahil-ing yerel yürütme için uzak URL dosyaları
  • enabling register globals so that get and post variables get variable values automatically assigned.
  • not escaping db entered data/ allowing SQL injection attacks (usually happens when not using a DB API layer)

Diğer etki POST Disallow / IP Yani Botlar yapamam giriş / formları göndermek.

İşte forum yöneticileri için potansiyel bir hatadır, özellikle, ama aynı zamanda kodları yukarı açılan seçicisi fakat bir form herkes yayınlanmıştır yanıtı aslında mevcut seçeneklerden biri olduğunu doğrulamaz.

Kolejde, phpBB kullanıcının 'ülke' seçici böyle bir doğrulama olduğunu fark etti.

Bunun yerine 'Amerika Birleşik Devletleri' veya 'Afganistan' bizim okul foruma, benim ülkem ne kadar aptal, ya da pis, herhangi bir şey olabilir. Tüm gerekli bir html POST form oldu. Ben yapmıştı nasıl anlamaya birkaç gün dostlarımı aldı, ama yakında, tüm 'havalı' yerine kendi adları altında gösterilen ülkelerin komik ifadeler vardı.

Bir geek üniversiteye gidiyor harika oldu. : D