Harici API'lerden beklenmeyen değerlere karşı korunmalı mıyım?

Diyelim ki harici bir API'den girdi alan bir işlevi kodluyorsunuz MyAPI.

Bu harici API'nin MyAPI, a stringveya a döndüreceğini belirten bir sözleşmesi vardır number.

O gibi şeyler karşı korumak için önerilen mı null, undefined, booleanbunun API parçası olmadığı halde, vb MyAPI? Özellikle, bu API üzerinde kontrol sahibi olmadığınız için, statik tip analizi gibi bir şeyle garanti veremezsiniz, bu yüzden üzgün olmaktan daha güvenli olmak daha iyidir.

Sağlamlık İlkesi ile ilgili olarak düşünüyorum .

Kaynak ne olursa olsun, yazılımınızın girişlerine asla güvenmemelisiniz. Sadece tiplerin doğrulanması değil, aynı zamanda girdi ve iş mantığı aralıkları da önemlidir. Yorum başına, bu OWASP tarafından iyi tanımlanmıştır

Bunu yapmamak, daha sonra temizlemeniz gereken atık verilerinde sizi en iyi şekilde bırakacaktır, ancak en kötü durumda, eğer yukarı yöndeki hizmet bir şekilde tehlikeye atılırsa (Hedef kesmek qv) kötü niyetli istismarlar için bir fırsat bırakacaksınız. Aradaki sorunların kapsamı, başvurunuzun kurtarılamaz duruma getirilmesini içerir.

Yorumlardan belki de cevabımın biraz genişleme yapabileceğini görebiliyorum.

"Girdilere hiçbir zaman güvenme" ifadesiyle, yalnızca yukarı akış ya da aşağı akış sistemlerinden her zaman geçerli ve güvenilir bilgiler alacağınızı varsayamayacağınız anlamına gelmez ve bu nedenle bu girişi her zaman kabiliyetinizden en iyi şekilde çıkarmanız veya reddetmeniz gerekir. o.

Bir tartışma, örnek olarak ele alacağım yorumlarda ortaya çıktı. Evet, işletim sisteminize bir dereceye kadar güvenmek zorundasınız, örneğin, 1 ile 10 arasında bir sayı isteyip istemediğiniz ve "bob" ile yanıt verdiğinde rastgele bir sayı üreticisinin sonuçlarını reddetmek mantıksız değildir.

Benzer şekilde, OP durumunda, başvurunuzun yalnızca yukarı akış servisinden geçerli bir girişi kabul ettiğinden kesinlikle emin olmalısınız. Tamam değilken ne yaptığınız size bağlıdır ve başarmaya çalıştığınız asıl işletme işlevine büyük ölçüde bağlıdır, ancak minimal olarak daha sonra hata ayıklamak için günlüğe kaydeder ve uygulamanızın geçmemesini sağlarsınız kurtarılamaz veya güvensiz bir duruma.

Birinin / bir şeyin size verebileceği her girdiyi asla bilemeseniz de, iş gereksinimlerine göre izin verilenleri kesinlikle sınırlandırabilir ve buna dayalı olarak bir tür girdi beyaz listesi yapabilirsiniz.

Evet , elbette. Fakat cevabın farklı olabileceğini düşündüren nedir?

API'nin sözleşmenin söylediklerini geri getirmemesi durumunda programınızın öngörülemeyecek şekilde davranmasına kesinlikle izin vermek istemezsiniz, değil mi? Yani en azından bir şekilde böyle bir davranışla uğraşmak zorundasın . Asgari bir hata işleme biçimi her zaman (çok az!) Çabaya değerdir ve böyle bir şeyi uygulamamak için kesinlikle hiçbir sebep yoktur.

Bununla birlikte, bu gibi bir durumla başa çıkmak için ne kadar çaba harcamalısınız, büyük ölçüde dava bağımlıdır ve yalnızca sisteminiz bağlamında cevaplanabilir. Genellikle, kısa bir günlük girişi ve uygulamanın incelikle sona erdirilmesi yeterli olabilir. Bazen, bazı "yanlış" geri dönüş değerleri biçimleriyle başa çıkarak, bazı ayrıntılı istisna işlemlerini uygulamakta daha iyi olursunuz ve belki de bazı geri dönüş stratejileri uygulamak zorunda kalırsınız.

Ancak, yalnızca bir kurum içi elektronik tablo formatlama uygulaması yazıyorsanız, 10 kişiden daha az kişi tarafından kullanılıyorsa ve bir uygulama çökmesinin finansal etkisinin oldukça düşük olduğu yerlerde veya yeni bir otonom araç sürüşü yaratıyorsanız, bu çok büyük bir fark yaratır. Uygulama çökmesine neden olabilecek bir sistem.

Bu yüzden ne yaptığınızı yansıtmaya dair hiçbir kısayol yoktur , sağduyunuzu kullanmak her zaman zorunludur.

Sağlamlık İlkesi - özellikle, “kabul ettiğinizde liberal olmak” yarısı - yazılımda çok kötü bir fikirdir. Başlangıçta, fiziksel kısıtlamaların mühendislik toleranslarını çok önemli hale getirdiği donanım bağlamında geliştirilmiştir, ancak yazılımda, birileri sizi hatalı biçimlendirilmiş veya başka şekilde uygunsuz girdiler gönderdiğinde, iki seçeneğiniz vardır. Ya reddedebilirsiniz, (tercihen neyin yanlış gittiğine dair bir açıklama yaparak) ya da ne anlama geldiğini anlamaya çalışabilirsiniz.

EDIT: Yukarıdaki ifadede yanıldığımı ortaya koydu. Sağlamlık İlkesi, donanım dünyasından değil, İnternet mimarisinden, özellikle de RFC 1958'den geliyor . Belirtir:

3.9 Gönderirken kesin ve alırken hoşgörülü olun. Uygulamalar ağa gönderilirken tam olarak teknik özelliklere uymalı ve ağdan hatalı girişi tolere etmelidir. Şüphe durumunda, şartname gerektirmedikçe, hatalı girişi sessizce, bir hata mesajı döndürmeden atın.

Bu, açıkça konuşursak, baştan sona kadar yanlış. Bu yazıda verilen nedenlerden dolayı "hatalı bir girişi, hata mesajı vermeden sessizce at" dan ziyade daha yanlış yazılmış bir hata işleme kavramını anlamak zordur.

Ayrıca, bu noktada daha fazla ayrıntılandırılması için IETF makalesinde Dayanıklılık İlkesinin Zararlı Sonuçları .

Projenize atmak için Google'ın Arama ekibine eşdeğer kaynaklara sahip olmadığınız sürece asla, asla, asla bu ikinci seçeneği tercih etmeyin, çünkü bu belirli bir sorun alanında iyi bir işe yakın bir şey yapan bir bilgisayar programı ile gelmesi gereken budur. (Ve o zaman bile, Google’ın önerileri yarı yarıya soldan çıkacak gibi hissediyorlar.) Bunu yapmaya çalışırsanız, sonunda yapacağınız şey programınızın sık sık yorumlamaya çalıştığı büyük bir baş ağrısı. X'in hatalı girişi, gönderenin gerçekte ne anlama geldiği Y idi.

Bu iki nedenden dolayı kötü. Açık olan, çünkü sisteminizde kötü verileriniz var. Daha az belirgin olanı, birçok durumda, ne sizin ne de gönderenin, bir şey yüzünüze patladığında yolun aşağısına kadar bir şeylerin ters gittiğinin farkına varamayacağınızdır, ve sonra aniden düzeltmek için büyük, pahalı bir karmaşaya sahip olursunuz ve hiçbir fikriniz olmaz. ne ters gitti çünkü farkedilir etki kök nedenden o ana kadar kaldırılmıştır.

Bu yüzden Hızlı Arıza prensibi var; API'nize uygulayarak baş ağrısı çeken herkesi kurtarın.

Genel olarak, her ne zaman uygulanabilirse en azından aşağıdaki kısıtlamaları yerine getirmek için kod oluşturulmalıdır:

1. Doğru girdi verildiğinde doğru çıktı üretin.

2. Geçerli girdi verildiğinde (bu doğru olabilir veya olmayabilir), geçerli çıktı (aynı şekilde) üretin.

3. Geçersiz giriş yapıldığında, normal girişin neden olduğu veya bir hata sinyali olarak tanımlananların ötesinde herhangi bir yan etki olmadan işlem yapın.

Birçok durumda, programlar özellikle geçerli olup olmadıklarına dikkat etmeden çeşitli veri bölümlerinden geçer. Bu tür parçalar geçersiz veri içeriyorsa, programın çıktısı muhtemelen sonuç olarak geçersiz veri içerecektir. Bir program tüm verileri doğrulamak için özel olarak tasarlanmadıysa ve geçersiz girdi verilse bile geçersiz çıktı üretmeyeceğini garanti etmiyorsa , çıktısını işleyen programlar, içindeki geçersiz veri olasılığına izin vermelidir.

Verileri erkenden onaylamak çoğu zaman arzu edilirken, her zaman özellikle pratik değildir. Diğer şeylerin yanı sıra, bir veri grubunun geçerliliği diğer parçaların içeriğine bağlıysa ve bazı adımlar dizisine beslenen verilerin çoğunluğu yol boyunca filtrelenecekse, bu işlemden geçen verileri sınırlayan tüm aşamalar, her şeyi doğrulamaya çalışmaktan çok daha iyi performans sağlayabilir.

Ayrıca, bir programa yalnızca önceden doğrulanmış veriler verilmesi beklense bile, pratik olduğunda, yine de yukarıdaki kısıtlamaları yerine getirmesi iyi olur . Her işlem adımında tam doğrulamanın tekrarlanması çoğu zaman büyük bir performans kaybı olacaktır, ancak yukarıdaki kısıtlamaları yerine getirmek için gereken sınırlı doğrulama miktarı çok daha ucuz olabilir.

İki senaryoyu karşılaştıralım ve bir sonuca varmaya çalışalım.

Senaryo 1 Uygulamamız, harici API'nin sözleşmeye uygun davranacağını varsaymaktadır.

Senaryo 2 Uygulamamız, harici API'nin hatalı davranabileceğini varsayıyor, bu nedenle önlemler alıyor.

Genel olarak, herhangi bir API veya yazılımın sözleşmeleri ihlal etme olasılığı vardır; bir hata veya beklenmeyen koşullar nedeniyle olabilir. Bir API bile, iç sistemlerde beklenmedik sonuçlara yol açan sorunlar yaşıyor olabilir.

Eğer programımız harici API'nin sözleşmelere bağlı kalacağını ve herhangi bir önlem eklemekten kaçınacağını varsayarak yazıyorsa; Sorunlarla karşı karşıya olan parti kim olacak? Entegrasyon kodunu yazan bizler olacağız.

Örneğin, seçtiğiniz boş değerler. Diyelim ki, API sözleşmesine göre, yanıtın boş değerleri olmamalıdır; ancak eğer aniden ihlal edilirse, programımız NPE ile sonuçlanacaktır.

Bu nedenle, uygulamanızın beklenmeyen senaryoları ele almak için ek bir kod içerdiğinden emin olmanın daha iyi olacağına inanıyorum.

Her zaman gelen verileri doğrulamanız gerekir - kullanıcı tarafından girilen veya başka bir şekilde - bu harici API'den alınan veriler geçersiz olduğunda işlemek için bir işlem yapmanız gerekir.

Genel olarak konuşursak, organizasyon dışı sistemlerin birleştiği herhangi bir dikiş, doğrulama, yetkilendirme (sadece doğrulama ile tanımlanmadıysa) ve doğrulama gerektirmelidir.

Genel olarak, evet, her zaman hatalı girdilere karşı korunmanız gerekir, ancak API türüne bağlı olarak, "koruma" farklı anlamlara gelir.

Bir sunucuya harici bir API için yanlışlıkla sunucunun durumunu çökerten veya bozan bir komut oluşturmak istemezsiniz, bu nedenle buna karşı korunmanız gerekir.

Örneğin bir konteyner sınıfı (liste, vektör, vb.) Gibi bir API için istisnalar atmak tamamen iyi bir sonuçtur, sınıf örneğinin durumunu tehlikeye atmak bir dereceye kadar kabul edilebilir (örn. Hatalı bir karşılaştırma operatörüyle sağlanan sıralı bir konteyner Sıralandığında), uygulamanın çökmesi bile kabul edilebilir, ancak uygulamanın durumunu tehlikeye sokmak - örneğin sınıf örneği ile ilgisiz rastgele hafıza konumlarına yazmak - büyük olasılıkla değildir.

Biraz farklı bir fikir vermek için: Sözleşmesini ihlal etse bile, sadece verdiğiniz verilerle çalışmanın kabul edilebilir olduğunu düşünüyorum. Bu kullanıma bağlıdır: Bu sizin için bir dize olması GEREKEN bir şey mi, yoksa sadece görüntülemeniz / kullanmadığınız bir şey mi? Başka bir API tarafından sağlanan verilerin yalnızca% 1'ine ihtiyaç duyan bir API'm var. % 99'da ne tür bir veri olduğu daha az umrumda değildi, bu yüzden hiçbir zaman kontrol etmeyeceğim.

"Hatalı olmadığımdan girdilerimi yeterince kontrol etmediğim için" ve "Çok katı olduğum için geçerli verileri reddediyorum" arasında bir denge olmalı.

Bunu benim üstüme çıkarmak her zaman, daima sistemime her girişi kontrol etmektir. Bu, bir API'den döndürülen her parametrenin, programım kullanmasa bile kontrol edilmesi gerektiği anlamına gelir. Bir API'ye gönderdiğim her parametrenin doğruluğunu kontrol etme eğilimindeyim. Bu kuralın sadece iki istisnası vardır, aşağıya bakınız.

Test etmenin nedeni, bir sebeple API / giriş yanlışsa programımın hiçbir şeye güvenemeyeceğidir. Belki de programım API'nin inandığımdan farklı bir şey yapan eski bir sürümüyle bağlantılıydı. Belki de programım harici programda daha önce hiç yaşanmamış bir hataya rastladı. Ya da daha kötüsü, her zaman olur ama kimse umursamıyor! Belki de harici program, programıma veya sistemime zarar verebilecek eşyaları iade etmek için bilgisayar korsanları tarafından kandırılıyordur?

Benim dünyamdaki herşeyi test etmenin iki istisnası:

1. Performansın dikkatli bir şekilde ölçülmesinden sonraki performans:

   • ölçmeden önce asla optimizasyon yapmayın. Tüm giriş / iade verilerinin test edilmesi çoğu zaman gerçek aramaya kıyasla çok az zaman alır, bu nedenle kaldırılması çoğu zaman çok az veya hiç bir şey yapmaz. Yine de hata saptama kodunu saklı tutardım, ama belki de bir makro ile yorumla ya da sadece yorum yaparak.

2. Bir ipucunuz olmadığı zaman hata ile ne yapmalı

   • Tasarımınızın basitçe bulacağınız türde bir hatayı işlemeye izin vermediği durumlarda, sık sık değil, zamanlar vardır. Belki de yapmanız gereken şey bir hata kaydı yapmaktır, ancak sistemde hata kaydı yoktur. En azından bir geliştirici olarak daha sonra bunu kontrol etmenizi sağlayan hatayı "hatırlamanın" bir yolunu bulmak neredeyse her zaman mümkündür. Hata sayacı, günlüğe kaydetmeyi seçmeseniz bile, bir sistemde olması gereken iyi bir şeydir.

Giriş / dönüş değerlerinin tam olarak ne kadar dikkatle kontrol edileceği önemli bir sorudur. Örneğin, API'nin bir string döndürdüğü söylenirse, şunu kontrol ederim:

• veri türü actully bir dizedir

• ve bu uzunluk minimum ve maksimum değerler arasındadır. Dizeleri her zaman programımın işleyebileceği en büyük boyut için kontrol edin (çok büyük dizeler döndürmek ağ bağlantılı sistemlerde klasik bir güvenlik sorunudur).

• Bazı dizeler, ilgili olduğunda "yasadışı" karakterler veya içerik olup olmadığını kontrol etmelidir. Programınız daha sonra bir veritabanı söylemek için dizeyi gönderebilirse, veritabanı saldırılarını kontrol etmek iyi bir fikirdir (SQL enjeksiyonunu arayın). Bu testler en iyi, saldırımın nereden geldiğini belirleyebileceğim ve erken başarısız olabileceğim sistem sınırlarında yapılır. Dizeler daha sonra birleştirildiğinde tam bir SQL enjeksiyon testi yapmak zor olabilir, bu nedenle veritabanını çağırmadan önce test yapılması gerekir, ancak bazı sorunları erken bulmanız yararlı olabilir.

API'ye gönderdiğim parametreleri test etmenin nedeni, doğru sonucu aldığımdan emin olmak. Yine, bu testleri bir API çağırmadan önce yapmak gereksiz görünebilir ancak çok az performans alır ve programımdaki hataları yakalayabilir. Bu nedenle bir sistem geliştirirken testler en değerlidir (ancak bugünlerde her sistem sürekli gelişim içindedir). Parametrelere bağlı olarak, testler aşağı yukarı tamamlanabilir ancak programımın oluşturabileceği çoğu parametrede izin verilen minimum ve maksimum değerleri sık sık ayarlayabildiğinizi bulmaya meyilliyim. Belki bir dize her zaman en az 2 karakter olmalı ve en fazla 2000 karakter uzunluğunda olmalıdır? Minimum ve maksimum değerler, programımın hiçbir zaman tüm parametreleri kullanmayacağını bildiğim için API'nin izin verdiği içeride olmalıdır.