SMM panelde bot saldırıları ve API kötüye kullanımı: anahtarı elinde olan tehdit

Bir panel sahibi güvenliği düşündüğünde aklına dışarıdan gelen saldırı gelir: yük, parola deneme, açık tarayıcıları. Oysa açık API'si olan bir panelin ikinci bir kapısı vardır ve o kapı tamamen meşru görünür: istekler geçerli bir anahtarla, sizin kendi kayıtlı müşterinizden gelir ve normal trafikten ayırt edilemez. Bir bayinin tek bir curl satırıyla panelinize ne yapabileceğini, bunu hangi denetimlerin durdurduğunu ve düğme gizlemenin neden hiçbir işe yaramadığını ele alıyoruz.

Anahtarınız elinde olan bir saldırı

Sıradan saldırıdan farkı temeldir ve geri kalan her şey buradan çıkar. Dıştan gelen saldırı kapıda karşılanır: trafik süzgeci, giriş deneme sınırı, captcha - bunun için panel güvenliği üzerine ayrı bir inceleme var. Burada ise tam tersi: trafik meşru, anahtar gerçek, müşteri var ve hiçbir kapı süzgeci bu isteği geri çevirmez.

Üstelik çoğu zaman kötü niyet de yoktur. Pratikte üç kaynak var:

• İşini özensiz otomatikleştiren bayi. Betiği her siparişin durumunu on saniyede bir sorar, herhangi bir hatada döngüyle yeniden dener ve yanıt geç geldiğinde siparişi ikinci kez gönderir. Saldırmıyor, sadece düşünmemiş.
• Sınırları yoklayan müşteri. Bir adetlik sipariş, bir milyonluk sipariş, boş bağlantı, status içinde başkasının sipariş numarası. Genelde merak, bazen keşif.
• Kendisine ait olmayan bir anahtarı ele geçiren kişi. Anahtarlar bayinin deposundan, ekran görüntüsünden ya da eski çalışandan sızar. Panel için o hâlâ «sizin müşteriniz».

Temel kural: arayüz hiçbir şeyi korumaz

En sık buraya takılırlar. Düğmeyi gizlemek, hizmeti vitrinden çekmek, bir bölümü kapatmak - bunların hepsi yalnızca tarayıcının gördüğünü değiştirir. Anahtarı olan müşteri ise tarayıcıyı hiç açmaz.

Bizim çekirdeğimizde bu kural üç ayrı sunucu denetimiyle sabitlenmiştir ve her birinin açıklamasında aynı düşünce yazılıdır: o olmasa yasak tek bir curl satırıyla aşılırdı.

• Gizli hizmet hâlâ sipariş edilebilir. Coğrafi kısıt, vitrinden çekme, «gizli» işareti - bunlar gösterimle ilgilidir. Denetim, siparişin verildiği anda sunucuda olmalıdır; yoksa belirli bir ülke için kataloğdan çektiğiniz hizmet doğrudan istekle rahatça siparişe girer.
• Kapatılmış eylem hâlâ çağrılabilir. Müşterilere iptali ya da telafiyi yasakladıysanız düğme hesaptan kalkar, ama API metodu yerinde durur. Yetkiler, eylemin gerçekten yapıldığı yerde denetlenmelidir.
• Engellenmiş müşterinin anahtarı elindedir. Engel girişi kapatır, ama elindeki anahtar aynı kalır. API hesabın durumunu sormuyorsa, engel bir saniyede aşılır.

Bir de dördüncüsü, en geneli. Siparişin bütün denetimleri - hizmetin uygunluğu, miktar sınırları, e-posta onayı, hizmet tipi, bakiyenin yetip yetmediği - bütün girişlerin geçtiği tek bir yerde durmalıdır: vitrin formu da, API de, misafir ödemesi de. Bunları çağıran taraflara dağıtmak olmaz: er ya da geç bir giriş, diğerinin reddettiğini kabul eder ve bu ayrışma sessizce olur.

Sahte ve çöp siparişler

İkinci katman, biçimsel olarak geçerli ama size hiçbir şey getirmeyen siparişler. Her biri sağlayıcıya gider, onun sınırlarını yer ve ayıklaması sizin vaktinizi alır.

• Aynı bağlantıya çift sipariş. Özensiz bayi betiğinin klasik belirtisi: yanıt geç geldi, betik siparişin oluşmadığını sandı ve yeniden gönderdi. Çaresi hizmet düzeyinde bir işarettir: önceki hâlâ işlerken aynı hizmetin aynı bağlantısına ikinci siparişi kabul etmemek. Bir ayrıntı önemli - tamamlanmış ve iptal edilmiş siparişler engellememeli, çünkü teslimden sonra yeniden sipariş vermek tamamen meşrudur ve bunu yasaklamak yalnızca destek talebi üretir.
• Sınır dışı miktarlar. Hizmetin alt ve üst sınırı sunucuda denetlenmelidir. Ayrıca adım: sağlayıcı yalnızca yüzlük kabul ediyorsa 250'lik sipariş reddedilir ve para müşterinin bakiyesinden çoktan çıkmıştır.
• Drip-feed porsiyonları. Burada dikkatli entegratörler bile yanılır. Hizmet sınırları porsiyona, yani tek bir çalıştırmanın hacmine uygulanır, siparişin toplamına değil. Toplama bakan denetim, sağlayıcının ilk çalıştırmada dağıtacağı bir siparişi geçirir.
• Yanlış hizmet tipi. Özel yorumlarda miktar satır sayısıdır, paket hizmetler sipariş başına fiyatlanır, abonelik ise hacme göre hiç fiyatlanmaz. API her tip için ayrımsız quantity kabul ederse, hesapladığınız tutar sağlayıcının hesapladığından ayrılır. Hangi tipler var ve hangi parametreleri alıyor - API metotları başvurusunda.

Limitleri tüketmek

Üçüncü katman en can sıkıcısı, çünkü tek bir müşteriye değil hepsine birden vurur. Durumları arasız döngüyle soran bir betik ortak istek bütçesini yer ve onunla birlikte bütün diğer bayiler takılır.

Sayısal ölçekler. Bizde müşteri API'si dakikada yüz küsur istekle, yönetici API'si kabaca üç katıyla sınırlı; bu bir tutarsızlık değil: müşteri anahtarını genelde bir insan ya da küçük bir betik kullanır, yönetici API'sine ise robot ve yığınlarla gelir. Yaygın motor üzerindeki panellerde sınır daha da sıkıdır - panel başına saniyede beş istek civarı, ve gerçek bir entegrasyonda buna çarpmak sanıldığından kolaydır.

Önceden akla gelmeyen iki sonuç:

• Bütçe ortak, suçlu tek. Sayaç anahtara göre değil adrese göre sayıyorsa, aynı ağdaki birkaç bayi tek bir bütçeyi paylaşır. Özensiz tek bir betik ötekilerin işini durdurur ve şikâyete hepsi gelir.
• Başkasının limitleri de sizindir. Panel sağlayıcıya onun kurallarıyla gider ve tek bir müşteriden gelen sipariş seli oradaki payınızı yakar. Ardından onun API'si her şeye ret vermeye başlar ve çözmek size kalır.

Doğru yanıt yasak değil, toplu metotlar ve anlaşılır belgelerdir. Durumları yüze kadar numarayla yığın hâlinde sormak, tek tek döngüyle aynı işi görür ama iki taraf için de yüz kat ucuzdur. Bayileriniz bunu bilmiyorsa, tek tek dövmeye devam ederler.

Anahtarlarla ne yapmalı

• Anahtar uzun ve rastgele olmalı. Kriptografik üreticiden altmış küsur karakter. Müşteri numarasından ya da e-postasından türetilmiş anahtar tahmin edilebilir.
• Yenileme bir düğme olmalı, destek talebi değil. Sızıntı nadir değildir; düzeltmesi yazışma gerektiriyorsa müşteri hiçbir şey yapmaz.
• Anahtar dışarı geri dönmemeli. Ne API yanıtlarında, ne dışa aktarımlarda, ne de yönetici panelindeki müşteri listesinde. Bir kez gösterilir, sonrası yalnızca yenilemedir.
• Yalnızca HTTPS. Anahtar istek parametresi olarak gider, yani şifresiz protokolde aradaki her düğüme baştan sona görünür.

Bütün bunlar nasıl görülür

İçeriden kötüye kullanımın asıl sorunu, sorun gibi görünmemesidir: siparişler oluşur, para döner, panel çalışır. Elde olması gereken asgari şeyler:

• Siparişte kaynak işareti. Anahtarla verilen sipariş, vitrinden verilenden ayırt edilebilmeli. Bu olmadan cironuzun ne kadarının API üzerinden geçtiğini bile söyleyemezsiniz.
• Müşteri kırılımı. İsteklerin yüzde doksanını, cironun yüzde ikisini üreten tek bir bayi ancak bu kırılımda görünür. Düzenli olarak başka neye bakmak gerektiği panel metrikleri incelemesinde.
• Yalnızca başarılar değil, retler. «Hatalı API anahtarı» yanıtlarındaki sıçrama biri deniyor demektir. «Hatalı hizmet» sıçraması ise genelde bir betiğin eskimiş katalog kopyasıyla çalıştığını gösterir.

Özet

Açık API bir delik değil, panelin büyümesinin asıl yoludur: anahtarı olan bayi, elle toplanamayacak bir hacim getirir ve API zaten bunun için vardır. Sadece bir siteyi savunduğunuz gibi savunulmaz. Bütün kurallar sunucuda durur, bütün girişler aynı denetimlerden geçer, sınırlar önceden ilan edilir, toplu metotlar belgelenir ve anahtar tek tıkla yenilenir. Gizlenmiş düğme hiçbir şeyi korumaz ve bunu deneyerek öğrenmektense baştan kabul etmek ucuzdur. Anahtarın kime ve niçin verileceği bayiler için panel API'si yazısında.

Bunun canlı bir panelde nasıl işlediğini hiç para harcamadan görebilirsiniz: kendi kataloğumuz üzerinden geçen siparişler hiç sayılmaz, üçüncü taraf sağlayıcılarda ise ayın ilk 100 siparişi ücretsizdir. Anahtar hemen verilir, yani kendi betiğinizi daha ilk gün üzerinde çalıştırabilirsiniz.