it-swarm-tr.com

Web uygulaması geliştiricileri JSON saldırılarına karşı nasıl savunmalıdır?

JSON korsanlığı karşı en iyi savunma nedir?

Standart savunmaları numaralandırabilir, güçlü ve zayıf yönlerini açıklayabilir mi? İşte gördüğüm bazı savunmalar önerdi:

  1. JSON yanıtı herhangi bir gizli/herkese açık olmayan veri içeriyorsa, yanıtı yalnızca istek doğrulanırsa sunun (örneğin, kimliği doğrulanmış bir oturumu gösteren çerezlerle birlikte gelir).
  2. JSON verileri gizli veya herkese açık olmayan bir şey içeriyorsa, bunu gizli, tahmin edilemeyen bir URL'de barındırın (ör. 128 bit şifreleme kalitesinde rastgele bir sayı içeren bir URL) ve bu gizli URL'yi yalnızca veri.
  3. while(1); ifadesini JSON yanıtının başına koyun ve istemcinin JSON'ı ayrıştırmadan önce ayırmasını sağlayın.
  4. İstemciden JSON verileri için istekleri POST (bir GET değil) olarak göndermesini isteyin ve sunucunun JSON verileri için GET isteklerini yoksaymasını isteyin.

Bunların hepsi güvenli mi? Bunlardan birini diğerlerinden seçmek için herhangi bir neden var mı? Kaçırdığım başka savunma var mı?

42
D.W.

İlk savunma üst düzey varlık olarak bir nesne gerektirir geçerli JSON kullanarak belirtime bağlı kalmaktır. Bilinen tüm saldırılar, üst düzey nesne bir dizi ise, yanıtın geçerli Java <script> etiketi kullanılarak ayrıştırılabilen kod kodu olduğu gerçeğine dayanır.

JSON yanıtı gizli/herkese açık olmayan veriler içeriyorsa, yanıtı yalnızca istek doğrulanırsa sunun (örneğin, kimliği doğrulanmış bir oturumu gösteren çerezlerle birlikte gelir).

Saldırı için ön koşul budur , hafifletme değildir. Tarayıcının A sitesi için bir çerezi varsa, A sitesine yönelik tüm isteklere dahil eder. Bu istek B sitesinde bir <script> etiketi tarafından tetiklenmiş olsa bile doğrudur.

JSON verileri gizli veya herkese açık olmayan bir şey içeriyorsa, bunu gizli, tahmin edilemeyen bir URL'de barındırın (ör. 128 bit şifreleme kalitesinde rastgele bir sayı içeren bir URL) ve bu gizli URL'yi yalnızca veri.

URL'ler bir güvenlik özelliği olarak kabul edilmez . Tüm yaygın arama motorlarında, ziyaret edilen URL'leri tekrar arama motoru satıcısına bildiren tarayıcı eklentileri/araç çubukları bulunur. Yalnızca açıkça ziyaret edilen URL'leri rapor etseler de, bunu JSON URLS için de riske atmam.

İstemciden JSON verileri için istekleri POST (bir GET değil) olarak göndermesini isteyin ve sunucunun JSON verileri için GET isteklerini yoksaymasını isteyin.

Bu <script> içerilmesini engelleyecektir.

Süre (1); JSON yanıtının başlangıcında ve istemcinin JSON ayrıştırılmadan önce yanıtını kaldırmasını isteyin.

Bu yaklaşımın değiştirilmiş bir sürümünü öneririm: Başına </* Ekleyin . while(1) iki nedenden dolayı sorunludur: Öncelikle kötü amaçlı yazılım tarayıcısını (istemciler, proxy'ler ve arama motorunda) tetikleme olasılığı yüksektir. İkincisi, web sörfçülerinin CPU'suna karşı DoS saldırıları için kullanılabilir. Bu saldırılar açıkça sunucunuzdan kaynaklanıyor.

28

Google, bu tür saldırılara karşı kendini savunmak için " ayrıştırılamaz haksızlık " kullanır. Bu güvenlik açığı firefox 3'te düzeltildi idi. Güvenlik açığı, tarayıcıların JSON belirtimini uygulama biçiminden kaynaklanır.

3
rook

1) JSON yanıtı herhangi bir gizli/herkese açık olmayan veri içeriyorsa, yanıtı yalnızca istek doğrulanırsa sunun (örneğin, kimliği doğrulanmış bir oturumu gösteren çerezlerle birlikte gelir). 2) JSON verileri gizli veya herkese açık olmayan bir şey içeriyorsa, bunu gizli, tahmin edilemeyen bir URL'de barındırın (ör. 128 bit şifreleme kalitesinde rastgele bir sayı içeren bir URL) ve bu gizli URL'yi yalnızca yetkilendirilmiş kullanıcılarla/istemcilerle paylaşın veriye bakın.

Hem (1) hem de (2) yapmak için iyi bir neden yoktur.

Birincisi ABAC, ikincisi ZBAC. Birden fazla erişim kontrol şeması kullanarak derinlemesine savunma elde etmeye çalışmak, işleri çok karmaşık hale getiriyor.

3) JSON yanıtının başlangıcına while(1); ifadesini koyun ve istemcinin JSON'ı ayrıştırmadan önce bu sorunu çözmesini sağlayın.

4) İstemciden JSON verileri için istekleri POST (bir GET değil) olarak göndermesini isteyin ve sunucunun JSON verileri için GET isteklerini yoksaymasını isteyin.

Bunlar ince fikirlere benziyor ve kimlik bilgilerinin kötüye kullanılmamasını sağlamaya yardımcı olduğu için derinlemesine savunma yapıyor.

Bunlara ek olarak,

5) JSON'a yalnızca SSL veya başka bir güvenli kanal üzerinden hassas verilerle hizmet verin.

mITM yoluyla veri sızmasını önlemek için.

2
Mike Samuel