Gelmeyen bir ödeme için sipariş nasıl yola çıkar?

Havale dekontunun ekran görüntüsü, Türkiye'de satıcının yıllardır tanıdığı bir kanıt türü. Kripto tarafında aynı mesaj bu kez işe yarayan işlem hash'iyle geliyor ve blok gezgininde gerçekten bir transfer çıkıyor.

Bu raylarda dolandırıcılık geri çevirme olamaz. Transfer kesinleştikten sonra başvurulacak kart şeması ve satıcıyı borçlandıracak ihraççı banka yok. Geriye teslimattan önceki pencere kalıyor: birinin ödediğini söylemesiyle deponun, lisans sunucusunun ya da destek temsilcisinin buna göre davranması arasındaki dakikalar.

O pencerede yedi saldırı yaşıyor ve hepsi üç soruya bakıyor. Para gerçekten geldi mi, bu mesajı kim yazdı, bu çıkışı kim yetkilendirdi. Her saldırının yanında onu durduran kontrol ve o kontrolün bittiği nokta var — sınırı söylenmeden anlatılan kontrol, sınırının ötesinde de güvenilen kontroldür.

Birinci soru: para gerçekten geldi mi?

Hash doğru çıkıyor ve tuzak tam olarak bu.

Blok gezginine yapıştırın: karşınıza gerçek bir transfer, yanında tutar ve token sembolü gelir. Üçü de o transferi bu faturaya bağlamaz, en zayıfı da semboldür. EIP-20'de name ve symbol isteğe bağlıdır ve standart, arayüzlere bu değerlerin var olmasını beklememelerini söyler.

Sembol, kontratı yazanın seçtiği metinden ibaret.

Kontrol, faturanın kendi durumudur. Ödeme, transfer o faturanın adresine ulaşıp ağı ve tutarı için belirlenmiş derinliğe kadar onaylandığında alacak olarak yazılır: Ethereum'da 100 dolara kadar iki blok, 10.000 doların üzerinde otuz iki; altı ağda ise blok saymak yerine ağın kendi kesinliği beklenir.

Alıcı beklerken tespit edilen her transfer ödeme sayfasında satır satır listelenir, henüz onaylanmamış olanlar dahil.

Derinlik, mutlak kesinliğin kanıtı değil onunla kurulmuş dengedir. Zincir yeniden düzenlenir de yazılmış transfer düşerse satıcının rakamı değişmez; açık, platform tarafında kalır.

Fatura, paranın gelip gelmediğini cevaplar. Bu siparişin çıkmayı hak edip etmediğini asla.

Faturayı kapatmayan para nereye gider?

Satıcının bakiyesine. Faturaya değil.

Bunun dört biçimini alıcı elle üretebilir: ödeme penceresi kapandıktan sonra gönderilen transfer, hâlihazırda ödenmiş, süresi dolmuş ya da iptal edilmiş faturaya yapılan transfer, başka bir varlıkta gelen transfer — USDT ile fiyatlanmış faturaya USDC — ve üzerinde hiç fatura olmayan adrese düşen transfer. Dördü de satıcının bakiyesine geçer, komisyonu her zamanki gibi kesilerek.

Faturaya ise hiçbir şey olmaz; ödendi işareti almaz. Bu alacak türünün tanımlı bir olayı olmadığı için sunucunuza hiçbir teslimat düşmez — siparişi webhookla kapatan sistem parayı hiç görmez. Uyarı yine de çıkar, yalnızca başka kanaldan: e-postaya ve panele bildirim gider, Bakiye sayfasında da kendi bloğu durur. Nedeni, tutarı, komisyonu, biliniyorsa gönderen adres ve işlem hash'i orada.

Yani alıcının mesajı doğru bir cümle taşıyor. Bakiyenize bakın, para orada. Öyle. Gelişi teyit edip siparişi salıveren temsilci, faturanın hâlâ ödenmedi gösterdiği işi kapatmış oluyor.

Bir ayrıntı satıcının lehine işler: kabul edilen başka bir ağdan gelen aynı varlık, o faturanın adresi onu alıyorsa faturayı bire bir öder. Her fatura almaz ve adresin kapsamadığı zincirden gönderilen para düştüğü yerde kalır.

Sınırı açık söylemekte fayda var. Para satıcıya ulaştı ve bir kısmını geri göndermek, birinin yetkilendirmesi gereken giden transferdir — alıcının kendi başına başlattığı iade yok, ödeme katmanında verilmiş geri dönüş sözü de yok.

"Ödendi"yi tarayıcı söylüyorsa

Sonucu, sonuçta çıkarı olan tanığa sormuş olursunuz.

Aynı kusurun iki sürümü var. Birincisinde sipariş, dönüş adresinde ya da ödeme katmanından gelen JavaScript olayında ödendi işaretlenir — Low-Code SDK bunlardan beş tane yayar, hepsi window üzerinde CustomEvent ve hepsi katmanın ne yaptığını bildirir.

Ekrandaki göstergeyi döndürmek için iyi. Ödeme durumu değil, üstelik konsolu açan alıcı hepsini kendi tetikleyebilir.

İkincisinde tutar sayfadan gelir. Widget onu beş kaynaktan öncelik sırasıyla çözer ve kaynaklar aynı ölçüde güvenli değildir: price_id sunucuda duran fiyattır, dolayısıyla istek hiç tutar taşımaz; amount_selector ise bir input elemanının .value değerini okur.

Alıcının düzenleyebildiği sayfada bu, fiyatı alıcının söylemesi demektir. MITRE sınıfı CWE-602 olarak kaydediyor — sunucunun, kendisini korumak üzere tasarlanmış mekanizmayı uygulaması için istemciye bel bağlaması.

Fiyatı sunucuya taşımak ödeme sayfasını güvenli yapmaz; tek bir kararı erişilemez yere taşır. Sipariş başına değişen sepeti yine sizin kodunuz fiyatlamak zorunda, ödendi durumunun da alıcının yazamayacağı yerden gelmesi gerekiyor.

İkinci soru: bu mesajı kim yazdı?

Geri çağırma adresi genel internette bir adrestir ve JSON kabul eder.

Sahte bir invoice.paid için hiçbir yere erişim gerekmez: doğru biçim, doğru fatura kimliği ve gövdeyi okuyan işleyici yeter. CWE-345 tam olarak bunun kaydı — verinin kaynağını veya gerçekliğini yeterince doğrulamayan, bu yüzden geçersiz veriyi kabul eden ürün.

Her teslimat HMAC-SHA256 ile imzalanır ve X-Webhook-Signature başlığı bileşiktir: bir zaman damgası ve bir ya da birden çok v1 değeri. Secret yenilendiğinde başlık 24 saat boyunca iki değer taşır ve ikisinden biri tutabilir; alıcı tarafın v1'i alan değil liste olarak ayrıştırmasının nedeni budur.

Neyin hash'lendiği ve her dil için sabit süreli karşılaştırma imza sayfasında duruyor. Bu yazı kodu değil, güven kararını üstleniyor.

Sonra tekrar var; insanları asıl şaşırtan yer burası. X-Webhook-Timestamp her teslimata basılır ve giden tarafta kendi penceresi dayatılmaz — tolerans, doğrulayanın kararıdır.

Dokümantasyon 300 saniyeyi aşan teslimatın reddedilmesini ister ve resmî SDK'lar beş dakikayı varsayılan alır; birinin üzerine kurulan entegrasyon kontrolü hazır devralır.

Yalnızca HMAC'e bakarak elle yazılmış doğrulayıcı ise bir hafta önce yakalanmış teslimatı kabul eder ve üzerindeki imza gerçektir.

Bir olay, iki teslimat, iki sevkiyat

Kopyaların çoğu saldırı değil; işleyiciyi yanlış yazmayı kolaylaştıran da bu.

On saniyelik zaman aşımına çarpan deneme yeniden denenir; bir döngü, bir dakikadan sekiz saate açılan aralarla on bir denemedir ve uçtan uca yaklaşık on altı saat sürer. Başarısız olay elle yeniden oynatılabilir.

Dağıtım bunun üstüne ekler: aynı kategoriye bağlı iki uç nokta, tek olayın iki teslimatını alır.

Saldırganın yapması gereken tek şey, yakaladığı bir teslimatı yeniden göndermek.

Tek istekte iki kimlik yolculuk ediyor; kontrol, her birine kendi işini vermek. X-Webhook-Id — yani evt_… — teslimat kimliğidir, tekilleştirmeyi onunla yapın. data içindeki inv_… ticari kimliktir; uç noktalar arasında ve bütün durum geçişlerinde aynı kalır, siparişi ona yazın.

İkisini takas etmek iki yönden de kaybettirir: sipariş tablosunu teslimat kimliğiyle anahtarlarsanız iki uç nokta tek ödemeyi iki kez kaydeder; tekilleştirmeyi fatura kimliğiyle yaparsanız confirming'i izleyen paid çöpe gider. Aynı webhookun neden iki kez geldiğini ayrı bir yazı işleyici üzerinden anlatıyor.

Tekilleştirme ikinci işleyişi durdurur, ikinci gelişi değil. Döngü sürdükçe teslimat gelmeye devam eder ve tükenen döngü uç noktayı değil olayı başarısız işaretler.

Merdivende saatler geçirmiş bir confirming, kendisinden sonraki paid'in ardına da düşebilir; en son geleni uygulayan işleyici, ödenmiş siparişi geriye yürütür.

Üçüncü soru: bu çıkışı kim yetkilendirdi?

Talebi karşılayan kişi hangi adresi yapıştırdıysa oraya.

Bu saldırının saldırgana maliyeti yok ve sistemlerinize hiç dokunmuyor. İade talebi bir hedef adresle gelir — başkasının okuduğu müşteri posta kutusundan ya da ikna edilmiş bir çalışandan.

Kontrol, transfer beyaz listesidir. Ödeme çıkışı yalnızca listede duran adresi yazabilir ve liste boşken transfer tümden kapalıdır. Kayıtlar tek ağa değil, adres artı ağ grubuna göre tutulur: EVM adresini bir kez listeye alan satıcı için o tek satır bütün EVM çıkış ağlarına cevap verir. Karşılaştırma küçük harfe indirilerek yapılır, dolayısıyla checksum yazımı ikinci bir hedef sayılmaz. Kayıt silinmez, iptal edilir — satır yerinde kalır ve denetim izi bütün kalır.

Adres eklemek ayrıcalıklı işlemdir ve o ize düşer.

Kontrolün iki yerde sınırı var. Liste değişikliğindeki ek doğrulama koşulsuz değil: ortada güçlendirilecek bir faktör yoksa adım atlanır.

Yani bu katmanı hazır sayarak plan yapmayın. Ek doğrulama ancak biri TOTP ya da passkey tanımladıktan sonra devreye girer; o zamana kadar kapıda yalnızca liste durur.

İkincisi tek onayın boyu. Tek istekte bin adrese kadar liste eklenir ve bunu tek ek doğrulama karşılar; CSV içe aktarımı da adres başına değil dosya başına tek bildirim üretir.

Kolaylık ile risk burada aynı sayıya bakıyor, dolayısıyla okunması gereken şey listenin kendisi. Listede kimin cüzdanının uçta durduğu da yazmaz: satıcı müşterisinin adresini bilerek listeye alabilir.

Kimin hak ettiği, son tarih ve onayın kimde olduğu ise iade politikasının işi.

Oturum başkasına geçtiğinde

Yukarıdaki her kontrol, onu yapılandıran hesaba cevap verir.

Panelin içinden geri çağırma adresi düzenlenebilir, Webhook Secret yenilenebilir, beyaz liste de formdur. Oturum başkasının olduğunda yukarıdaki altı saldırının hiçbirine gerek kalmaz.

Hesapta oltalanacak parola yok. Giriş; e-posta linki, Google, açık olduğu yerde Telegram OIDC ya da passkey ile yapılır, ikinci faktör olarak TOTP tanımlanabilir.

Bu saldırı karşısında dördü arasında passkey'i ayıran şey, yapıldığı yere bağlı olması: WebAuthn, kimlik bilgisini kaydedildiği güvenen tarafa kapsar ve doğrulayıcı, kaynağı cevaplarının içine katarak bütün işlemleri tek bir kaynağa kapsanmış tutar; başka bir kaynağa karşı tekrar oynatılamaz.

İkna edici benzer alan adı, kullanabileceği hiçbir şey toplayamaz.

Ek doğrulama üç işlemin önünde durur — ikinci faktörü kapatmak, beyaz listeyi değiştirmek, API anahtarının IP listesini düzenlemek — ve her kapsam kendi biletidir, dolayısıyla biri için yakalanan kod başka hiçbir şeyi yetkilendirmez.

Çıkış kimlik bilgisinin, ödeme kimlik bilgisinin talep bile edemeyeceği bir şartı var: IP listesi boş olan çıkış anahtarı sınırsız sayılmaz, kimlik doğrulamada reddedilir.

Parolasız olmak oturumsuz olmak değildir. E-posta linki posta kutusuna düşer ve önce ele geçirilen şey posta kutusudur; o yolu ikinci faktör kapatır ve kimse varsayılan olarak tanımlı değildir. Satıcının sonradan okuyacağı şey kendi işlem kaydı ve giriş geçmişidir — platformun tam kaydı operatörde kalır.

Yedi kontrolün kaçı zaten sizde?

Üçü, kim ne yaparsa yapsın duruyor: faturanın durumu, ödeme çıkışının önündeki beyaz liste ve faturayı ödemeyen transferin faturayı kapatmaması. Diğer dördü yalnızca sizin kodunuz yaparsa var — imzayı ve zaman damgasını doğrulamak, teslimat kimliğiyle tekilleştirmek, fiyatı sunucuda tutmak, ek doğrulamayı açan ikinci faktörü tanımlamak. Dördü de birer öğleden sonralık iş.

Listenin dışında kalan tek durum şu. İmza, transferi anahtarın yetkilendirdiğini söyler; sahibinin bunu istediğini söylemez ve satıcı tarafında çalınmış cüzdanı iyi müşteriden ayıran hiçbir şey yoktur. Bu, destek süreci ve teslimat politikasıdır, kontrol değil; hiçbir güvenlik sayfası onu kapatmaz.