Nasıl bir PHP web uygulaması rakiplerine sırlarını ifşa olmadan güvenli bir şekilde hata ayıklamak gerekir?

Son zamanlarda bir program yaptım. 2 satır kod silmeyi unutuyorum. Bu hata bana her gün 800 $ 'a mal oldu.

PHP ile programlama yapıyordum. Bir ziyaretçi proxy kullanıyorsa, başka bir yere yönlendirir. Bazı kodlar ioncube içerdiğinden hata ayıklayıcı kullanmak imkansızdı. Program, ne olursa olsun, başka bir yere yönlendirdiği için, kodun hangi bölümünün yürütüldüğünü görmek zor.

Bu yüzden her yere bir grup hata ayıklama bilgisi koydum. Zaten onları silerim diye düşündüm.

Hata ayıklamanın en doğal yolu, hata ayıklama bilgilerini bir dosyaya koymaktır. Sorun genellikle proxy kullanıyorum. Bu yüzden programı değiştirdikten sonra, genellikle dosya dosyasını filezilla ile indirmem gerekiyor. Genellikle metin dosyası neyi göstermesi gerektiğini düşündüğümü göstermez. Sonunda sadece web'de hata göstermeye karar verdim.

Hata ayıklama moduna sahip olmayı düşündüm. Ancak, hata ayıklama bilgilerini silmeyi unutacağımdan korkuyorum.

Ben kullanıcı örneğin? Debuggingmode = 1 yaparsanız hata ayıklama modu olan düşündüm. Ancak, bir şekilde rakibimin gizli anahtar kelimeyi tahmin edebileceği paranoyaktım.

Çoğu hata ayıklama bilgisini sildim. Birini silmeyi unutuyorum ve bu yalnızca kullanıcılar doğru ülkeden proxy kullanıyorsa görünür. Görünen o ki doğru ülkeden vekaletim yok ve bunun farkında değildim. Program 24 saat çalıştıktan sonra, bunu ana alanıma yükledim.

Rakipim proxy kullanarak hata ayıklama koduna bakın. Bu fikri kopyaladı ve günde 800 dolar kaybettim.

Geçmişe baktığımda, nerede yanlış yaptığımı görmekte gerçekten zorlanıyorum. Çok dikkatli davrandım. Yine de oldu.

Nasıl bir PHP web uygulaması rakiplerine sırlarını ifşa olmadan güvenli bir şekilde hata ayıklamak gerekir?

Nerede yanlış yaptığımı görmekte gerçekten zorlanıyorum

En büyük hata, tekerleği yeniden keşfetmenizdi. Günlüğe kaydetme için varsayılan mekanizmaları kullanmak yerine , sayfadaki bilgileri görüntüleyen kendinizinkini icat ettiniz . Günlüğe kaydetme çerçevesi, günlükleri günlük dosyalarında depolamayı tercih ederek, bu günlüklere daha sonra sunucuya SSHing tarafından başvurmanızı sağlar.

Hatalara gelince, hatasız kod üretmek resmi kanıt gibi belirli tekniklerin kullanılması anlamına gelir . Pahalılıkları göz önüne alındığında, bu teknikler uçak trafiğini veya uzay servislerini kontrol eden, ancak hemen hemen her iş uygulaması için aşırıya kaçan uygulamalar gibi hayati önem taşıyan uygulamalar için uygundur.

■ Bkz . Fast Company dergisinde doğru olanları yazıyorlar .
_{Makale NASA'da kullanılan metodolojiyi ve bu şekilde yazılım üretmenin maliyetini açıklamaktadır.}

■ Bkz. Mekanizasyon Kanıtı (Mackenzie 2004).
_{Kitap, yazılımın otomatik kanıtının tarihini, bu kanıtın artılarını ve eksilerini ve işletmelerin güvenilir yazılım yazmak için yaygın olarak kullanılmadığı nedenleri açıklamaktadır.}

Bununla birlikte, yazılım kalitesini sağlamak için iş uygulamaları için kullanılan bir dizi teknik vardır. Bunlar aşağıdakileri içerir ancak bunlarla sınırlı değildir:

• Resmi olmayan kod incelemeleri,
• Resmi kod denetimleri,
• Test yapmak,
• Kodun kişisel masa başı kontrolü,
• vb.

■ Bkz. Kod tamamlandı (McConnell 2004), Programlama Verimliliği (Jones 1986a), Yazılım Hata Giderme Etkinliği (Jones 1996) ve Mücadele Kusurları Hakkında Öğrendiklerimiz (Shull ve ark. 2002).

Ayrıca, sürekli entegrasyonu ve sürekli teslimatı da unutmayın. Revize edilmiş bir kod incelemeleri ve birim testi sırasında kaçırılan ancak uygulama dağıtıldığında yakalanan bir sorun olduğu görülüyorsa, üretimdeki uygulamayı otomatik olarak çalışan bir sürüme geri döndürmeye yardımcı olur.

■ Bkz . Güvenli Sürekli Dağıtımın Sırrı (video)
_{Dağıtımdan önce bulunamayan hataların üretimde çok uzun süre kalmasını önlemek için Google'da hangi tekniklerin ayarlandığını açıklar. Ayrıca pdiffsunum katmanıyla ilgisi olmayanlar da dahil olmak üzere hataları yakalamak için nasıl kullanıldığını açıklar .}

Üretimde asla hata ayıklamamalısınız.

Her zaman üretim ortamıyla aynı olan ve orada hata ayıklayan bir test ortamına sahip olmalısınız.

Test ortamındaki kodu değiştirmeniz gerektiğinde (hata ayıklama ifadeleri eklemek gibi), bunların üretime girmediğinden emin olmalısınız.

Profesyonel bir kurulum genellikle şöyle görünür:

Production
   ^
Staging
   ^
Development

Uygulamanızın "Üretim", "Evreleme" ve "Geliştirme" örnekleri mümkün olduğunca aynı olmalıdır, böylece "Üretim" de oluşan bir hata "Evreleme" ve "Geliştirme" de çoğaltılabilir, ancak yine de birbirinden tamamen ayrılabilir. böylece örneklerden birinde ne olursa olsun diğerlerini etkilemez.

Bir sorunu analiz etmeniz gerektiğinde, bunu "Geliştirme" de yaparsınız. Hata ayıklama ifadeleriyle uğraşın ve istediğiniz her şeyi deneyin. Bir çözüm bulduğunuzda, bu düzeltmeyi "Aşamalandırma" daki değişmemiş kod tabanına uygular ve düzeltmenin çalıştığını doğrularsınız. Sonra "Üretim" düzeltmesini teşvik.

Uygun bir sürüm kontrolü ve derleme yönetim sistemi bu konuda size yardımcı olabilir.

Bu nadiren yapılır, çünkü çabaya değmez. Günde 800 dolar kaybedseniz bile, bir programı doğru bir şekilde kanıtlama çabası bundan daha büyük hale gelir, bu da bunu yapmak için bir iş vakası olmadığı anlamına gelir.

Belirli olmak durumunda olan (Uzay Mekiği yazılım veya füze kontrolü için örneğin) çok, o zaman resmi vb doğrulama, olası tüm girdilerin kapsamlı sınama, Verilen gerçekleştirmenizi değer, aynı zamanda son derece var zor yanı sıra yavaş ve pahalı. Ancak milyar dolarlık bütçeleri olan projelerde de son derece parlak insanlar var. (Ya da belki de eskiden - bugünün manşetleri bu kuralla çelişiyor gibi görünüyor.)

Bazen canlı bir sistemde hata ayıklamanız gerekebilir. Evet, bir geliştirme veya hazırlama kopyası olması gerekir. Ama her zaman farklılıklar olacak. Bu, özellikle kod, donanımda müşteri donanımında tükeniyorsa geçerlidir. Veya potansiyel olarak birçok farklı müşteri kurulumu.

Geçmişte & debugging = 1 tekniğini kullandım . Çoğu PHP geliştiricisinin olduğundan şüpheleniyorum. Bu, kodda, uygulamada daha ayrıntılı hata ayıklamayı etkinleştiren bir anahtarı çevirdi. Bu bilgiler genellikle bir günlük dosyasına - genellikle apache günlüğüne (error_log () kullanılarak) dökülür. Ancak, çıktı da alabilirsiniz. Örneğin profil oluşturucumuz bilgi toplayıp sayfanın altındaki çeşitli ölçütleri çıktılar. Hata ayıklama bilgilerini bir HTML yorumu olarak veya yalnızca sayfa kaynağını görüntülediğinizde görüntülenebilen gizli bir öğede de verebilirsiniz.

Sitenizde 'kullanıcılar' varsa, hata ayıklamayı yalnızca belirli bir kullanıcıyla sınırlandırabilirsiniz. Bu şekilde, bir kişi hata ayıklamayı etkinleştirmeye çalışırsa, o kullanıcı olarak oturum açmadığı sürece hala çalışmayacaktır.

Şimdi, sunucuya bağlanmak için FileZilla kullandığınızı söylemiştiniz. Bir geliştirici gerçekten sunucuya SSH erişimine sahip olmalıdır. Bu hata ayıklamayı sizin için çok daha kolay hale getirecektir. Örneğin, hata ayıklama ifadelerinizi Apache hata günlüğüne çıkarırsanız, IP adresiniz için bu dosyayı kolayca grep edebilir ve son sayfa isteğiniz tarafından oluşturulan hata ayıklama bilgilerini görebilirsiniz.

Diğer herkes genel davayı zaten ele aldı:

Resmi Doğrulama (/ Kanıtlanmış Kod): Gerçek dünya programları için mümkün değil, resmi olarak kanıtlanmış 4000 satırlı bir OS çekirdeği olmasına rağmen, birçok Rus CS Doktora Öğrencisinin aylarca sürdüğünü lütfen unutmayın (lütfen bu projenin adını hatırlayın, yorum yapın)

CI Testi << Otomatik Test << Test : Test vakalarınızın% 100 kapsama sahip olup olmadığını kontrol etmek için bir kapsama aracı kullandığınızdan emin olun.

Hata ayıklama kodunu üretimde bırakma özel durumunuz için, her ikisi de kaynak kodun yeni (Aşama / Son Test) ortamına dağıtımın bir parçası olarak yeniden kodlanmasını gerektiren 2 seçeneğim var.

1. Derleme zamanında çıkarın. #ifdef DEBUGOluşturma hedefini (Hata Ayıkla veya Serbest Bırak) denetlemek ve derleme zamanında bunları otomatik olarak kaldırmak için hata ayıklama kodunu C # ve C gibi yapılara sarın .

2. Dağıtım zamanında işaretleyin. Gerçek çevrede çalıştırılmaması gereken kodun yanına bir yorum koyun. Örneğin //TODO: Remove This Before Deployment, Staging'e geçirildiğinde (konuşlandırıldığında), kodu derlemeden önce //TODO:, kaynak kodda hiçbir Bayrak yorumu (örneğin ) kalmadığından emin olmak için kontrol eden basit bir komut dosyası aracılığıyla çalıştırın .

Ben uzun vadeli ve tekrar isteyeceksiniz için eski öneririz (Örn. Ayrıntılı günlük modu), ve daha sonra hata ayıklama sırasında hızlı bir hack ise (Örn kod aracılığıyla dağınık çeşitli printfs)

Diğerlerinin benden önce söyledikleri gibi, mümkünse otomatik ve iyi kod kapsamına sahip birçok test (çoğunlukla ve sorunsuz) çoğunlukla hatasız bir yazılıma sahip olmanın anahtarıdır.

Sorununuzun açıklamasını yeterince iyi anlarsam, hata ayıklama bilgileri sunucunuz tarafından sunulan sayfada gösterilir. Bu durumda, bu bilgileri sunucunuzdaki uygun günlüklere koymayı düşünmelisiniz. Bu şekilde üretime 'ayrıntılı' bir sürüm dağıtsanız bile, son kullanıcıya hiçbir zaman gösterilmez. Bu, aksi halde yapmak için çok iyi nedenleriniz olmadıkça, üzerinde çalıştığınız proje ne olursa olsun iyi bir şeydir.

Başkalarının üretimde hata ayıklama hakkında söyledikleri doğrudur. Ama bazen yine de yaptım. Ve bence bunu yapmanın sizinkinden daha güvenli yolları var, ancak hiçbir şey kusursuz değildir.

Bu kadar yüksek güvenliğe ihtiyacım yok, kullanıcıların ekranlarında bir sürü anlamsızlık görmelerini istemiyorum.

$debug = true;
$allowed_ips = array('192.168.0.220','173.46.89.255'); // limit to your own ip's. If your competitor knows them, though, he can spoof it! But if your stuff is not top secret, it's ok. 

if(!in_array($_SERVER['REMOTE_ADDR'],$allowed_ips) ) {
  $debug = false;
}

if($debug) {
  echo '<pre>' . print_r($some_variable) . '</pre>';
}

Artık kullanıcılar gerçekten istemedikçe hata ayıklama işleminizi görmeyecek. 800 $ / gün tutarınız bu hata ayıklama bilgisini gizli tutmaya bağlıysa , yukarıdaki kodu kullanmayın . Ancak, bilgi o kadar hassas değilse, yukarıdakiler bir GET değişkenine bağlı olmaktan veya sırlarınızı tüm bir ülkeye ifşa etmekten çok daha iyi olacaktır.

Alternatif olarak, debugölçütlerinize göre yazdırmaya izin verilip verilmediğini kontrol edecek bir sınıf veya işlev oluşturabilirsiniz. İşte bu yaptığım şey.

Bunun gibi bir şey:

class debug {
  public $on = false;
  public static function print($variable) {
    if($on) {
      echo '<pre>' . print_r($some_variable) . '</pre>';
    }
  }
}

debug::print($some_variable); // class checks if printing is allowed. If not, no printing occurs.

Bana 800 $ / gün (geliştirme aşamasında) yapacak programım için, sitenin herhangi bir bölümüne erişmek ve bazı IP'lere hata ayıklama bilgilerini kısıtlamak için bir parola istemek için apache mod auth kullanıyorum. Sorunuz beni daha iyi güvenliğe bakmam gerektiğini düşündürüyor.

Aslında, burada iki ek doğrulama yapmam gerekiyordu. Bunlardan biri &debug=1istekteki parametredir. Ayrıca, "gizli" bir sayfaya (tercihen kimlik doğrulamasıyla) çağrı yaparak yalnızca sizin etkinleştirebileceğiniz bazı özel oturum değişkenlerini veya çerez ayarlarını da kullanabilirsiniz .

İkinci doğrulama, yapılandırma dosyasında, çeşitli IP'lere sahip bir dizi olması ve yalnızca bu dizideki bir IP'den yapılan çağrıların hata ayıklama işlevini tetikleyebilmesidir. gibi bir şey

Yapılandırmada:

$debugAllowedIPs = array('127.0.0.1', '192.168.0.1', /* add more IPs here */);

Küresel olarak erişilebilecek bir yerde aşağıdaki yöntemi kullanın:

function getClientIp() {
    if (!empty($_SERVER['HTTP_CLIENT_IP']))  return $_SERVER['HTTP_CLIENT_IP'];
    if (!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) return $_SERVER['HTTP_X_FORWARDED_FOR'];
    return $_SERVER['REMOTE_ADDR'];
}

Ve kodunuzda şöyle bir şey çağırın:

if (in_array(getClientIp(), $debugAllowedIPs)) { /* show debug info here */ }

Lütfen getClientIp()yöntemdeki kodun güvenli olmadığından, değerinin $_SERVER['HTTP_X_FORWARDED_FOR']kolayca aldatıldığını unutmayın, ancak sorunuzun karşılığını alma amacına hizmet etmelidir.