Favori (Akıllı) Defansif Programlama En İyi Uygulamaları [kapalı]

Eğer savunma kodlaması için Favori (akıllı) tekniklerinizi seçmek zorunda olsaydınız, bunlar ne olurdu? Mevcut dillerim Java ve Objective-C (arka plan C ++ 'da) olmasına rağmen, herhangi bir dilde cevap vermekten çekinmeyin. Buradaki vurgu ,% 70'inden fazlasının zaten bildiği teknikler dışında akıllı savunma tekniklerine olacaktır . Şimdi hile çantanızın derinliklerine inme zamanı.

Başka bir deyişle, bu ilginç örnek dışında düşünmeye çalışın :

• if(5 == x) yerine if(x == 5) : istenmeyen atamayı önlemek için

İşte bazı ilginç en iyi savunma programlama uygulamalarına bazı örnekler (dile özgü örnekler Java'dadır):

- Değişkenlerinizi değiştirmeniz gerektiğini bilene kadar değişkenlerinizi kilitleyin

Yani, değiştirmeniz gerekeceğini bilinceye kadar tüm değişkenleri finalbildirebilirsiniz, bu noktada final. Yaygın olarak bilinmeyen bir gerçek, bunun yöntem parametreleri için de geçerli olduğudur:

public void foo(final int arg) { /* Stuff Here */ }

- Kötü bir şey olduğunda, geride bir kanıt bırakın

Bir istisnanız olduğunda yapabileceğiniz birkaç şey vardır: Açıkçası oturum açmak ve bazı temizlik yapmak birkaç şey olacaktır. Ancak bir kanıt izi de bırakabilirsiniz (örn. "DOSYA catchYÜKLENEMEZ " veya 99999 gibi sentinel değerlerine değişkenleri ayarlamak, bir istisna -block'u aşarsanız hata ayıklayıcıda yararlı olacaktır ).

- Tutarlılık söz konusu olduğunda: şeytan ayrıntıda gizlidir

Kullandığınız diğer kütüphanelerle tutarlı olun. Örneğin, Java'da, bir değer aralığı ayıklayan bir yöntem oluşturuyorsanız, alt sınırı kapsayıcı ve üst sınırını özel hale getirin . Bu String.substring(start, end), aynı şekilde çalışan yöntemler gibi tutarlı hale getirecektir . O endeksler Sıfır (gelmektedir diziler, tutarlı elemanların yineleme dahil olmak üzere çeşitli işlemleri yapar gibi bu şekilde davranmasına Güneş JDK yöntemlerin bu türdeki tüm bulacaksınız Anin dizinin (uzunluğuna) münhasır ).

Peki senin favori savunma uygulamaların neler?

Güncelleme: Henüz yapmadıysanız, giriş yapmaktan çekinmeyin. Resmi yanıtı seçmeden önce daha fazla yanıt gelmesi için bir şans veriyorum .

C ++, bir zamanlar çit sonrası hataları yakalamak için biraz fazladan bellek sağlamak için yeni tanımlamayı sevdim.

Şu anda, Test Odaklı Geliştirme lehine savunma programlamasından kaçınmayı tercih ediyorum . Hataları hızlı ve harici olarak yakalarsanız, kodunuzu savunma manevraları ile karıştırmanıza gerek yoktur, kodunuz KURU -er'dir ve savunmanız gereken daha az hatayla karşılaşırsınız.

WikiKnowledge'un yazdığı gibi :

Defansif Programlamadan Kaçının, Yerine Hızlı Başarısız Olun.

Defansif programlama ile, verilerdeki bazı arızaları telafi etmeye çalışan kod yazma alışkanlığı, arayanların arayan ve altyordam arasındaki sözleşmeye uymayan veriler sağlayabileceğini ve altyordamın bir şekilde başa çıkması gerektiğini varsayan kod yazma alışkanlığını kastediyorum Bununla.

SQL

Verileri silmem gerektiğinde

select *    
--delete    
From mytable    
Where ...

Koştuğumda, nerede ibaresini unuttuğumu veya yok ettiğimi bileceğim. Bir güvenliğim var. Her şey yolundaysa, '-' yorum belirteçlerinden sonra her şeyi vurgularım ve çalıştırırım.

Düzenleme: Çok fazla veri siliyorsam, sadece * yerine count (*) kullanacağım

Uygulama başladığında makul bir bellek yığını ayırın - Bence Steve McConnell bunu Kod Tamamlama'da bir bellek paraşütü olarak adlandırdı .

Bu, ciddi bir şeyin yanlış gitmesi ve sonlandırmanız gerektiğinde kullanılabilir.

Bu belleği öne ayırmak size bir güvenlik ağı sağlar, çünkü bu belleği boşaltabilir ve ardından aşağıdakileri yapmak için kullanılabilir belleği kullanabilirsiniz:

• Tüm kalıcı verileri kaydet
• Tüm uygun dosyaları kapatın
• Hata iletilerini bir günlük dosyasına yazma
• Kullanıcıya anlamlı bir hata gösterin

Varsayılan bir durumda olmayan her switch deyiminde, programı bir hata iletisiyle iptal eden bir vaka eklerim.

#define INVALID_SWITCH_VALUE 0

switch (x) {
case 1:
  // ...
  break;
case 2:
  // ...
  break;
case 3:
  // ...
  break;
default:
  assert(INVALID_SWITCH_VALUE);
}

Bir numaralandırmanın çeşitli durumlarını (C #) işlerken:

enum AccountType
{
    Savings,
    Checking,
    MoneyMarket
}

Sonra, bazı rutinin içinde ...

switch (accountType)
{
    case AccountType.Checking:
        // do something

    case AccountType.Savings:
        // do something else

    case AccountType.MoneyMarket:
        // do some other thing

    default:
-->     Debug.Fail("Invalid account type.");
}

Bir noktada bu numaraya başka bir hesap türü ekleyeceğim. Ve bunu yaptığımda, bu anahtar deyimini düzeltmeyi unutacağım. Bu yüzden Debug.Faildikkatimi bu gerçeğe çekmek için (Hata Ayıklama modunda) korkunç çöküyor. Eklediğimde, case AccountType.MyNewAccountType:korkunç bir çökme durur ... başka bir hesap türü ekleyene ve buradaki durumları güncellemeyi unutana kadar.

(Evet, burada polimorfizm muhtemelen daha iyidir, ancak bu sadece kafamın üstünden bir örnek.)

Hata mesajlarını bir dizeyle (özellikle kullanıcı girişine bağlı olan) yazdırırken, her zaman tek tırnak kullanırım ''. Örneğin:

FILE *fp = fopen(filename, "r");
if(fp == NULL) {
    fprintf(stderr, "ERROR: Could not open file %s\n", filename);
    return false;
}

Buradaki tırnak eksikliği %sgerçekten kötü, çünkü dosya adı boş bir dize veya sadece boşluk veya başka bir şey. Yazdırılan mesaj elbette:

ERROR: Could not open file

Yani, her zaman yapmak daha iyidir:

fprintf(stderr, "ERROR: Could not open file '%s'\n", filename);

Sonra en azından kullanıcı bunu görür:

ERROR: Could not open file ''

Bunun son kullanıcılar tarafından gönderilen hata raporlarının kalitesi açısından büyük bir fark yarattığını düşünüyorum. Genel bir şey yerine böyle komik görünümlü bir hata mesajı varsa, sadece "dosyalarımı açmaz" yazmak yerine kopyalayıp yapıştırmaları çok daha olasıdır.

SQL Güvenliği

Verileri değiştirecek herhangi bir SQL yazmadan önce, her şeyi geri alma işleminde sararım:

BEGIN TRANSACTION
-- LOTS OF SCARY SQL HERE LIKE
-- DELETE FROM ORDER INNER JOIN SUBSCRIBER ON ORDER.SUBSCRIBER_ID = SUBSCRIBER.ID
ROLLBACK TRANSACTION

Bu, kalıcı olarak kötü bir silme / güncelleme yürütmenizi engeller. Ayrıca, her şeyi yürütebilir ve makul kayıt sayılarını doğrulayabilir veya her şeyin doğru göründüğünden emin olmak SELECTiçin SQL ile - arasında deyimler ekleyebilirsiniz ROLLBACK TRANSACTION.

Beklediğiniz şeyi yaptığından tamamen emin olduğunuzda, ROLLBACKdeğerini değiştirin COMMITve gerçekte çalıştırın.

Tüm diller için:

Değişkenlerin kapsamını mümkün olan en düşük seviyeye indirin. Onları bir sonraki ifadeye taşımak için sağlanan Eschew değişkenleri . Var olmayan değişkenler, anlamanız gerekmeyen değişkenlerdir ve sorumlu tutulamazsınız. Aynı nedenden ötürü Lambdas'ı mümkün olduğunca kullanın.

Şüphe duyduğunuzda, uygulamayı bombalayın!

Kontrol her başında parametreyi her yöntemi (explictly kendiniz kodlama veya sözleşmeye dayalı programlama kullanarak olmadığı değil mesele burada yapar) ve doğru istisna ve / veya anlamlı hata mesajı ile bomba kodunda herhangi ön şart ise karşılanmadı.

Kodu yazdığımızda hepimiz bu örtülü önkoşulları biliyoruz , ancak açıkça kontrol edilmezlerse, bir şeyler daha sonra ters gittiğinde ve düzinelerce yöntem çağrısı, belirtinin ve gerçek konumun ayrılığını ayırdığında kendimiz için labirentler yaratıyoruz. burada bir ön koşul karşılanmaz (= sorunun / hatanın gerçekte olduğu yer).

Java'da, özellikle koleksiyonlarda API'yı kullanın, bu nedenle yönteminiz Liste türü (örneğin) döndürüyorsa aşağıdakileri deneyin:

public List<T> getList() {
    return Collections.unmodifiableList(list);
}

Sınıfınızdan kaçmak için ihtiyaç duymadığınız hiçbir şeye izin vermeyin!

Perl’de herkes

use warnings;

severim

use warnings FATAL => 'all';

Bu, herhangi bir derleyici / çalışma zamanı uyarısı için kodun ölmesine neden olur. Bu çoğunlukla başlatılmamış dizelerin yakalanmasında yararlıdır.

use warnings FATAL => 'all';
...
my $string = getStringVal(); # something bad happens;  returns 'undef'
print $string . "\n";        # code dies here

C #:

string myString = null;

if (myString.Equals("someValue")) // NullReferenceException...
{

}

if ("someValue".Equals(myString)) // Just false...
{

}

Dizgede uzunluk, indexOf, mid vb gibi işlemler yapmadan önce string.IsNullOrEmpty öğesinin c # kontrolünde

public void SomeMethod(string myString)
{
   if(!string.IsNullOrEmpty(myString)) // same as myString != null && myString != string.Empty
   {                                   // Also implies that myString.Length == 0
     //Do something with string
   }
}

[Düzenle]
Şimdi ayrıca .NET 4.0, ayrıca değerin sadece boşluk olup olmadığını denetler aşağıdakileri yapabilirim

string.IsNullOrWhiteSpace(myString)

Java ve C # 'da, her iş parçacığına anlamlı bir ad verin. Bu, iş parçacığı havuzu iş parçacıklarını içerir. Yığın dökümlerini çok daha anlamlı hale getirir. Hatta iş parçacığı havuzu iş parçacıkları için anlamlı bir ad vermek için biraz daha fazla çaba gerektirir, ancak bir iş parçacığı havuzu uzun süren bir uygulamada bir sorun varsa, bir yığın dökümü oluşmasına neden olabilir ( SendSignal.exe hakkında bilmek , değil mi? ), günlükleri alın ve çalışan bir sistemi kesintiye uğratmadan hangi iş parçacıklarının olduğunu söyleyebilirim ... her neyse. Kilitlenme, sızıntı, büyüme, sorun ne olursa olsun.

VB.NET ile, Visual Studio'nun tamamı için varsayılan olarak Option Explicit ve Option Strict'i açın.

C ++

#define SAFE_DELETE(pPtr)   { delete pPtr; pPtr = NULL; }
#define SAFE_DELETE_ARRAY(pPtr) { delete [] pPtr; pPtr = NULL }

ardından tüm ' pPtr sil ' ve ' sil [] pPtr ' çağrılarınızı SAFE_DELETE (pPtr) ve SAFE_DELETE_ARRAY (pPtr) ile değiştirin

Şimdi yanlışlıkla 'pPtr' işaretçisini sildikten sonra kullanırsanız, 'erişim ihlali' hatası alırsınız. Düzeltmek rastgele bellek bozulmalarından çok daha kolaydır.

Java ile, üretim kodunu iddialar kapalıyken çalıştırsanız bile assert anahtar kelimesini kullanmak kullanışlı olabilir:

private Object someHelperFunction(Object param)
{
    assert param != null : "Param must be set by the client";

    return blahBlah(param);
}

İddialar kapalı olsa bile, en azından kod, parametrenin bir yerde ayarlanması beklendiğini belgelemektedir. Bunun özel bir yardımcı işlev olduğunu ve genel bir API'nın üyesi olmadığını unutmayın. Bu yöntem yalnızca sizin tarafınızdan çağrılabilir, bu nedenle nasıl kullanılacağı konusunda belirli varsayımlar yapmak sorun değildir. Genel yöntemler için, geçersiz giriş için gerçek bir istisna atmak daha iyidir.

Ben bulamadık readonlyReSharper bulana kadar anahtar kelime, ama şimdi özellikle hizmet sınıfları için, içgüdüsel kullanabilirsiniz.

readonly var prodSVC = new ProductService();

Java'da bir şey olduğunda ve nedenini bilmiyorum, bazen Log4J'yi şu şekilde kullanacağım:

if (some bad condition) {
    log.error("a bad thing happened", new Exception("Let's see how we got here"));
}

bu şekilde bana beklenmedik duruma nasıl geldiğimi gösteren bir yığın izlemesi alıyorum, asla kilidin açılmadığı bir kilit söyleyin, boş olamaz bir şey söyle. Açıkçası, eğer gerçek bir İstisna atılırsa, bunu yapmam gerekmiyor. Bu, aslında başka bir şey rahatsız etmeden üretim kodunda neler olduğunu görmem gerektiğinde. Ben yok bir özel durum atmak istiyorum ve bir tane anlayamadım. Sadece olanları işaretlemek için uygun bir mesajla bir yığın izlemesini istiyorum.

Visual C ++ kullanıyorsanız, bir temel sınıfın yöntemini her geçtiğinizde override anahtar sözcüğünü kullanın . Bu şekilde, herhangi biri temel sınıf imzasını değiştirirse, yanlış yöntem sessizce çağrılmak yerine derleyici hatası atar. Daha önce var olsaydı bu beni birkaç kez kurtaracaktı.

Misal:

class Foo
{
   virtual void DoSomething();
}

class Bar: public Foo
{
   void DoSomething() override { /* do something */ }
}

Gerçekten süresiz olarak uzun sürebileceğini beklemediğim sürece , Java'da kilidin kilidini açmak için neredeyse hiç süresiz olarak beklemeyi öğrendim . Gerçekçi olarak, kilit birkaç saniye içinde kilidini açacaksa, sadece belirli bir süre bekleyeceğim. Kilit açılmazsa, yığını günlüklere şikayet edip döküyorum ve sistemin kararlılığı için en iyi olana bağlı olarak ya kilit açılmış gibi devam edin ya da kilit hiç açılmamış gibi devam edin.

Bu, bunu yapmaya başlamadan önce gizemli olan birkaç yarış koşulunu ve sahte kilitlenme koşullarını izole etmeye yardımcı oldu.

C #

• Genel yöntemde başvuru türü parametreleri için null olmayan değerleri doğrulayın.
• Ben sealedistemediğim yerde bağımlılıkları tanıtmak önlemek için sınıflar için çok kullanıyorum . Mirasa izin vermek, kazara değil açık bir şekilde yapılmalıdır.

Bir hata mesajı verirken, en azından program bir hata atma kararı verdiğinde sahip olduğu bilgileri sağlamaya çalışın.

"İzin reddedildi" size bir izin sorunu olduğunu söylüyor, ancak sorunun neden veya nerede oluştuğu hakkında hiçbir fikriniz yok. "İşlem günlüğü / dosyam: dosya salt okunur dosya sistemi" yazılamıyor, en azından yanlış olsa bile kararın verildiği temeli bilmenizi sağlıyor - özellikle yanlışsa: yanlış dosya adı? yanlış mı açıldı? başka beklenmedik hata? - ve sorun yaşadığınızda nerede olduğunuzu bilmenizi sağlar.

C # 'da asyayınlamak için anahtar kelimeyi kullanın.

string a = (string)obj

obj bir dize değilse bir istisna atar

string a = obj as string

obj bir dize değilse, null değerini bırakacaktır

Hala null değerini dikkate almanız gerekir, ancak bu genellikle istisnaları aramaktan daha doğrudur. Bazen "döküm veya havaya uçurma" tipi davranışlar istersiniz, bu durumda (string)objsözdizimi tercih edilir.

Kendi kodumda, assözdizimini yaklaşık% 75 oranında ve (cast)sözdizimi yaklaşık% 25 kullandığımı görüyorum .

Herhangi bir giriş için hazır olun ve beklenmedik bir şekilde aldığınız herhangi bir giriş, günlüklere dökün. (Bu nedenle, kullanıcıdan şifreleri okuyorsanız, günlüklere dökmeyin! Bu tür binlerce iletiyi saniyede günlüklere kaydetmeyin. Oturum açmadan önce içerik, olasılık ve sıklık nedeni .)

Sadece kullanıcı girişi doğrulamasından bahsetmiyorum. Örneğin, XML içermeyi beklediğiniz HTTP isteklerini okuyorsanız, diğer veri biçimlerine hazır olun. Yalnızca XML beklediğim yerde HTML yanıtlarını gördüğüme şaşırdım - isteğimin farkında olmadığım şeffaf bir proxy'den geçtiğini ve müşterinin cehaletini talep ettiğini görünceye kadar - ve proxy istek. Böylece proxy, istemcime bir HTML hata sayfası döndürerek istemciden yalnızca XML verisi bekleyen karışıklığı karıştırdı.

Böylece, telin her iki ucunu da kontrol ettiğinizi düşünseniz bile, herhangi bir kötü niyetli olmadan beklenmedik veri formatları alabilirsiniz. Beklenmedik bir giriş durumunda hazırlıklı olun, savunmacı bir şekilde kodlayın ve tanı çıktısı sağlayın.

Sözleşme ile Tasarım yaklaşımını kullanmaya çalışıyorum. Herhangi bir dil tarafından çalışma süresi benzetilebilir. Her dil "iddia" yı destekler, ancak hatayı daha kullanışlı bir şekilde yönetmenizi sağlayan daha iyi bir uygulama yazmak kolay ve rahattır.

In Top 25 En Tehlikeli Programlama Hataları "Yanlış Girdi Doğrulama" bölümünde "Bileşenler Arasında güvensiz Etkileşim" en tehlikeli hatadır.

Yöntemlerin başına önkoşul önerileri eklemek , parametrelerin tutarlı olduğundan emin olmak için iyi bir yoldur. Yöntemlerin sonunda yazıyorum Hedefşartlar o çıktı olmak inteded ne olduğunu kontrol edin.

Değişmezleri uygulamak için , herhangi bir sınıfa "sınıf tutarlılığını" kontrol eden, önkoşul ve sonkoşul makrosu tarafından otomatik olarak çağrılması gereken bir yöntem yazıyorum.

Kod Sözleşme Kütüphanesini değerlendiriyorum .

Java

Java api'nin değişmez nesneler kavramı yoktur, bu kötüdür! Final bu durumda size yardımcı olabilir. Final ile değiştirilemeyen her sınıfı etiketleyin ve sınıfı buna göre hazırlayın .

Bazen değerlerini asla değiştirmediklerinden emin olmak için yerel değişkenlerde final kullanmak yararlı olabilir. Bunu çirkin ama gerekli döngü yapılarında yararlı buldum. Bir değişkeni düzeltmek olsa bile, bir değişkeni yanlışlıkla tekrar kullanmak kolaydır.

Alıcılarınızda savunma kopyasını kullanın . İlkel bir türü veya değiştirilemez bir nesneyi döndürmediğiniz sürece, nesneyi kapsüllemeyi ihlal etmeyecek şekilde kopyaladığınızdan emin olun.

Asla klon kullanmayın, bir kopya oluşturucu kullanın .

Eşittir ve hashCode arasındaki sözleşmeyi öğrenin. Bu çok sık ihlal ediliyor. Sorun, vakaların% 99'unda kodunuzu etkilememesidir. İnsanlar eşittir, ancak hashCode umrunda değil. Kodunuzun kırılabileceği veya garip davranabileceği durumlar vardır, örn. Haritadaki anahtar olarak değiştirilebilir nesneler kullanın.

Ben echoPHP bir çok kez yazmayı unuttum :

<td><?php $foo->bar->baz(); ?></td>
<!-- should have been -->
<td><?php echo $foo->bar->baz(); ?></td>

Denemek ve neden -> baz () aslında sadece yankılama değildi bir şey döndürmüyordu anlamaya sonsuza kadar sürer! : -S Yani EchoMeyankılanması gereken herhangi bir değerin etrafına sarılabilecek bir sınıf yaptım :

<?php
class EchoMe {
  private $str;
  private $printed = false;
  function __construct($value) {
    $this->str = strval($value);
  }
  function __toString() {
    $this->printed = true;
    return $this->str;
  }
  function __destruct() {
    if($this->printed !== true)
      throw new Exception("String '$this->str' was never printed");
  }
}

Ve sonra geliştirme ortamı için, yazdırılması gereken şeyleri sarmak için bir EchoMe kullandım:

function baz() {
  $value = [...calculations...]
  if(DEBUG)
    return EchoMe($value);
  return $value;
}

Bu tekniği kullanarak, eksik olan ilk örnek echoşimdi bir istisna atar ...

C ++

Yeni yazdığımda, hemen delete yazmalıyım. Özellikle diziler için.

C #

Özelliklere erişmeden önce, özellikle de Meditor desenini kullanırken null olup olmadığını kontrol edin. Nesneler iletilir (ve daha önce belirtildiği gibi kullanılarak kullanılmalıdır) ve sonra null'a karşı kontrol edin. Boş olmayacağını düşünseniz bile yine de kontrol edin. Şaşırdım.

Dinamik, çalışma süresi günlük düzeyi ayarlarına izin veren bir günlük sistemi kullanın. Genellikle günlüğe kaydetmeyi etkinleştirmek için bir programı durdurmanız gerekiyorsa, hatanın meydana geldiği nadir durumları kaybedersiniz. İşlemi durdurmadan daha fazla günlük bilgisi açabilmeniz gerekir.

Ayrıca, linux üzerindeki 'strace -p [pid]', sistem çağrılarının bir işlem (veya linux iş parçacığı) yapmasını istediğinizi gösterecektir. İlk başta garip görünebilir, ancak genellikle sistem çağrılarının hangi libc çağrıları tarafından yapıldığına alıştıktan sonra, alan teşhisinde bunun için çok değerli olduğunu göreceksiniz.