Kayıt defteri nedir
FlareWatch'ün tarihindeki her tekrarlanan hata sınıfı, numaralandırılmış bir korumaya indirgenmiştir: tek paragraflık bir kural, bir gerekçe ve kodu uygulayan yerin göstericisi. Yeni korumaları, önlenmesi gereken bir hata sınıfı veya desenin ortaya çıkması durumunda eklenir.
Kayıt defteri çalışan bir belgedir, pazarlama metni değildir. Amacı, takımı — ve takımın kullandığı denetim-öncelik inceleme döngüsünü — hangi kuralların nerede geçerli olduğu hakkında dürüst tutmaktır. Kayıt defteri, satır içi kod yorumlarından (örn. // Safeguard 24) referans gösterilir, böylece herhangi bir dosyanın okuyucusu, çevreleyen satırları yöneten kuralı bulabilir.
Bu sayfa genel özettir. Tam kayıt defteri, yönettiği kod ile birlikte kaynak havuzunda yer alır. Buradaki amaç, bir güvenlik araştırmacısına, hibe gözden geçirenine veya olası bir katkıcıya, kayıt defterinin kapsadığı kategoriler ve uyguladığı disiplin türü hakkında bir fikir vermektir.
Neden bir kayıt defteri
Bir koruma kayıt defteri ancak aynı hatayı iki kez önlerse kendini kanıtlar. Kayıt defterinin sicili cevap şudur:
- Her koruma, engellediği hatayı adlandırır. Arkasında hatırlanmış bir olay olmayan bir kural, koruma değil stil tercihidir. Stil tercihleri kayıt defterine değil, lint kurallarına aittir.
- Korumalara koddan referans yapılır, sadece belgelerden değil. Bir koruamayı ihlal eden kod değişikliği, inceleme sırasında bayrak olarak okunur çünkü koruma numarası çevreleyen yorumlarda bulunur.
- Bazı korumaları otomatik olarak uygulanır. Bir alt küme ESLint kuralları veya CI'da çalışan shell betikleri aracılığıyla uygulanır. Geri kalanı, uygulamada iyi sonuç vermiş olan yazar disiplini artı denetim-öncelik inceleme deseni ile yapılır.
- Kayıt defteri testler tarafından dürüst tutulur. Birkaç koruma mekanizması, kaynak dosyaları string olarak okuyan ve anti-patternlerin görünmediğini kontrol eden regresyon testleriyle sabitlenir. Kırılganlık özelliktir: anti-patternlere dönen bir gelecek refaktörü, regresyon üretime ulaşmadan test başarısız olur.
Kategoriler
Kayıt defteri alan adına göre düzenlenmiştir. Aşağıdaki kategoriler stabildir; her biri içindeki belirli koruma mekanizmaları yeni hata modları keşfedildikçe eklenir.
| Kategori | Neleri kapsar |
|---|---|
| Kimlik doğrulama ve yetkilendirme | Oturum doğrulaması için tek kontrol noktası, her rotada cüzdan sahipliği kontrolleri, erişim ve yenileme belirteçleri arasında çapraz belirteç reddi, yönetici rotası kapısı. |
| Veri bütünlüğü | Adres normalleştirmesi, üretici/tüketici sınırlarında birim dönüşüm sözleşmeleri, anahtar oluşturucu disiplini ve başarısızlıkları sessizce sıfır değerlere birleştirmeye karşı kurallar. |
| Zincir üstü okumalar | Akıllı sözleşmeden okunan herhangi bir değer için tek uygulama kuralları, zincir üstü kayıttan sözleşme adresi çözümlenmesi ve ödül mantığını çoğaltmaya karşı kurallar. |
| Görüntü doğruluğu | Merkezi sayı, para birimi ve tarih biçimlendirmesi; her sayısal görüntüde null-güvenliği; APR vs. APY etiketleme disiplini; vergiler-oran-etkili disiplini. |
| Uyarılar ve bildirimler | İstemci ve sunucu arasında uyarı değerlendirmesi için tek kaynak; hangi uyarıların izlenen cüzdanlara yayıldığı için açık beyaz listeler; "ödüller indi" uyarısının eski "ödüller mevcut" uyarısını iptal etmesi için sürüm kuralları; cihazlar arası kapat senkronizasyonu. |
| Kalıcılık ve önbellek | Kanonik deponun anahtar-değer arka ucu versus localStorage olduğu durumlara ilişkin kurallar; geçiş disiplini; dağıtım kapsamındaki service worker önbelleği; canlı durum okuyan rotalar için açık dinamik geri çıkış. |
| Kullanıcı arayüzü ve yaşam döngüsü | Sayfa hazırlığı geçitleri, geçici sıfırların bilinen bakiyeleri yer değiştirmesini önleyen monotonik tabanlar ve soğuk-getirme pencerelemeleri sırasında iskelet-görüntüleme için kurallar. |
| İşlem ve araçlar | Açık özellik-başlatma onayı kuralları, uyarı-yüzey değişikliklerine karşı tam paket test çalışmaları, sunucu tarafı kodda yapılandırılmış günlükleme ve kısayol-tarzı düzeltmelere karşı inceleme disiplini. |
Temsili birkaç kural
Bunlar, kaydın karakterini gösteren güvenlik önlemlerinin halkla paylaşılabilir özetleridir. Bunlar paraphrase edilmiş ve kısaltılmıştır; kurallı metin kod yanında bulunur.
Zincir üstü okumalar için tek gerçek kaynağı
Bir akıllı sözleşmeden okunan herhangi bir değer — talep edilebilir ödüller, bakiyeler, stake durumu, dönem verileri, fiyatlar — hizmetler katmanında tam olarak bir işlev tarafından hesaplanır. Bu değere ihtiyaç duyan her özellik aynı işlevi içe aktarır. İki işlev aynı değeri hesaplarsa, biri yanlıştır; kural, üçüncüsünü eklemek değil, birini silmektir.
Oturum doğrulaması için tek darboğaz
FlareWatch'taki her kimlik doğrulamalı rota, oturum çerezlerini tek bir yardımcı aracılığıyla doğrular. Hiçbir rota işleyicisi oturum jetonlarını bağımsız olarak doğrulamaz. Bu değişmez değer, sunucu tarafı iptali evrensel kılır — kontrol için arka kapı yoktur.
Cüzdan başına sahiplik geçitleri, her iki taraf
Cüzdan başına rotalar, istemci tarafında değil sunucu tarafında sahipliği doğrular. Orijinal denetim, önceki çalışmaların istemci tarafı geçitleri kapattığı ancak sunucu tarafı uç noktaları tamamen açık bıraktığı zaman kuralı belirledi. Her iki yarı artık ayrı açık dağıtılabilirler olarak izlenir — istemci tarafında kapalı, sunucu tarafında kapalı — bu arızaya engel olmak için.
Merkezi formatları kullanın, hiçbir zaman satır içi değil
Tüm sayı, para birimi ve tarih biçimlendirmesi küçük bir merkezi yardımcı kümesinden geçer. Hiçbir bileşen satır içi biçimlendirmez. Kuralın stille ilgisi yoktur: tek bir yerel ayar veya para birimi tanımı değiştiğinde, uygulamadaki her yüzey bununla güncellenir. Yüzeyler arasında sapma sessiz ve görmek zordur; ta ki bir kullanıcı fark edene kadar.
Birim dönüştürmeleri her iki uçta belgelenmiştir
Sistem iki bölümü birim belirsiz olabilecek değerler takas ettiğinde (saniye ve milisaniye, ondalık ve yüzde, küçük harf ve sağlama toplamı adresler), sözleşme her iki üretici ve tüketici tarafından belgelenmiştir. Bir uçta yalnızca bir açıklama çürür; yalnızca her iki uçta iddia edilen bir sınır sözleşmesi bir yeniden düzenlemeden kurtulur.
Kullanıcı işlemi başına bir uygulama
Her kullanıcı tarafından başlatılan işlem — izlenen bir cüzdan ekleme, vergi oranı değiştirme, uyarı kapatma, oturumu kapatma — tam olarak bir uygulamaya sahiptir. Kural var çünkü kullanıcı arabiriminin farklı bölümlerinden tetiklenen işlemler eskiden ince şekillerde farklılaşırdı: bir giriş noktası önbelleği temizlerdi, başka biri temizlemezdi ve "işlem X sonrasında eski değer" türü hatalar ortaya çıkardı.
Sesli olması gereken hata modları
Bazı hata modları doğası gereği sessizdir — yanlış sınıflandırılmış bir ödül, bildirim olması gereken bir birim uyuşmazlığı bir no-op haline gelir, kapatma kaydı anahtar-değer deposuna ulaşmaz. Mümkün olduğunda, kayıt, bu değerlerin üreticilerinin sözleşmelerini yeterince sesli bir şekilde bildirmesini gerektirir, böylece bunu ihlal eden gelecekteki bir değişiklik testlerde sessizce başarısız olur ve üretime ulaşmadan önce.
Kayıt nasıl gelişir
- Yeni korumalar. Bir hata sınıfı tekrar ortaya çıktığında veya tek bir hata kalıcı bir kural haklı gösterecek kadar maliyetli olduğunda eklenir.
- Eski korumalar. Kayıtta "eski" işareti ve değiştirme göstericisi ile tutulur, böylece koddaki tarihi referanslar yorumlanabilir kalır.
- Çalışma notlarından yükseltildi. Bazı korumalar bir oturum devir belgesinde gayri resmi kurallar olarak başlar ve ağırlıklarını kanıtladıktan sonra kayıta yükseltilir.
- Üç aylık tarama. Geçici lint istisnaları ve "gelecek çeyrek tarafından yapılması gereken" işaretleri üç aylık bir döngüde kontrol edilir. Yaşlanmış herhangi bir şey ya çözülür ya da açıkça uzatılır.
Bunun neden yayınlandığı
FlareWatch, tam dahili kayıt yerine bu özeti iki nedenle yayınlar.
- Dahili kayıt, kod düzeyinde detay (dosya yolları, anahtar-değer şema adları, olay zaman damgaları) içerir ve bu erişime sahip bir güvenlik gözlemcisine ve ekibe yararlı olsa da, bu erişim olmadan yayınlanması uygun değildir.
- Kategoriler ve disiplin asıl hikayedir. FlareWatch'u değerlendiren bir hibe incelemecisi veya güvenlik araştırmacısı, projenin ne tür bir proje olduğunu, doğruluğu ne kadar ciddiye aldığını ve çalışma döngüsünün nasıl göründüğünü bilmek ister — kural #91'in hangi dosyada olduğunu değil.
Belirli bir korumayla tartışmak, yeni bir koru önermek veya bir boşluğu bildirmek isteyen araştırmacılar [email protected] adresinde iletişime geçebilir.
Daha fazla okuma
- Mimari — FlareWatch nasıl inşa edilir.
- Güvenlik Özellikleri — kimlik doğrulama, yetkilendirme, başlıklar, denetim geçmişi.