Laravel Türkiye Discord Kanalı Forumda kod paylaşılırken dikkat edilmesi gerekenler!Birlikte proje geliştirmek ister misiniz?

Weepay Ödeme Entegrasyonu CallBackUrl de Auth Erişimi Problemi

Serhatt · 2022-11-29T17:32:58+00:00

Merhabalar laravel projeme weepay ödeme sistemi entegrasyonu yapıyorum fakat şöyle bir sorunla karsılastım weepay den callback url ime postları alamıyordum C...

Serhatt

koti42 bu tüm rotaların CSRF verification unu kaldırmazmı?
bize sadece site dısından post alabilecegimiz callback url i nin CSRF verification korumasını kaldırmak yetiyor
ödeme sitesinden bize post basarılı sekilde geliyor yukarıda örnekte gelen sonuc var
tek sorun callback url içinde auth un null olması

BoraN7

Callback URL e User id ve benzersiz token göndermek bence en sağlıklı çözüm.

Laravel in şifre sıfırlamada yaptığı gibi ek tablo kullanılabilir.
id,token,user_id olur.
İşlem bittiğinde token in olduğu kayıt silinir.
URL i token ile korumuş olursun.

mgsmus

Serhatt Eğer session kullanıyorsanız config/session.php içerisinde same_site değerini null yapın. Token auth kullanıyorsanız zaten orada kullanıcı olmaz, orderId üzerinden Order modeline erişip orada User'a ulaşabilirsiniz.

BoraN7

mgsmus Bu değeri null a çekmek bir güvenlik zaafiyetine sebep olur mu?

Serhatt

mgsmus
Cevap için teşekkürler abi

'same_site' => null,

bu sorunu çözdü ama güvenlik yönünden bir problem yaşatmaz dimi bize bu

BoraN7

Bu bana çok güvenilir gelmedi esasen.

config/session.php içerisinde şöyle bir açıklama girilmiş;

/*
    |--------------------------------------------------------------------------
    | Same-Site Cookies
    |--------------------------------------------------------------------------
    |
    | This option determines how your cookies behave when cross-site requests
    | take place, and can be used to mitigate CSRF attacks. By default, we
    | will set this value to "lax" since this is a secure default value.
    |
    | Supported: "lax", "strict", "none", null
    |
    */

Bunu null yaptığımızda, sitemizi olası CSRF ataklarına karşı savunmasız bırakmış olmuyor muyuz? @mgsmus

mgsmus

BoraN7 Siz bir istek ile sitenizden ayrılıp başka bir siteye (domaine) geçtiğinizde o site size post ile dönerken çerez ile dönmüyor, o yüzden oturumu kaybediyorsunuz. Bu ayarı null yaptığınızda çerez ile birlikte geldiği için oturum kaldığı yerden devam ediyor. Elbette bu ayarı null olarak kullanacaksanız SESSION_SECURE_COOKIE değerinin de true olması ve uygulamanın da https ile çalışıyor olması lazım. Yoksa güvenlik açığı oluşacaktır (tarayıcı zaten blokluyor sanırım)

Serhatt

mgsmus
bu son söylediginiz sekilde ayarlamak herhangi bir xss acıgı olustururmu acaba baska yerlerde bize
zaten bu rotalara auth dısında kullanıcı giremeyecek
direk configden müdahale ettigimiz için sistem genelinde yapılmıs oluyor degisiklik
sadece bir rota için bu işlem yapılamıyormu acaba bu same_site olayı

mgsmus

Serhatt Öncelikle şunu netleştireyim; Weepay size dönerken POST isteği ile dönüyorsa ve siz oturumu devam ettirmek istiyorsanız benim bildiğim kadarıyla mevcut tarayıcılarda bunu yapmanın tek yolu SameSite=None; Secure, yani Laravel karşılığı olan same_site değerinin null ya da none yapılması ve https ile SESSION_SECURE_COOKIE=true kullanmak. O yüzden (Weepay size ait değilse) burada pek bir seçeneğiniz yok.

XSS açığı dediğiniz şey sadece burada değil kullanıcı tarafından gönderilen her türlü veri için geçerli. Kullanıcı tarafından verilen hiçbir şeyi tarayıcıya direkt basmayacaksınız. Blade ya da Vue kullanıyorsanız {{ }} tagları içinde basacaksınız.

CSRF olayında ise, 3. parti bir yer size post atıyorsa size göndereceği csrf tokenı bilemeyeceği için VerifyCsrfToken::$except[] içerisine eklemekten başka yolunuz yok. Elbette koti42 dediği gibi kesinlikle yapmayın, sadece ilgili rotaları verin.

BoraN7

mgsmus Ben Serhatt arkadaşımıza callback URL e user e ait uuid göndererek işlemi tamamlamasını önerdim.
Tabii uuid yi gören kullanıcı o URL e tekrar istek atıp suistimal etmesin diye token vs oluşturup tedbir alabilir.
Ben şahsen same_site ayarının değiştirilmesini çok sağlıklı bulmuyorum. Hatta yanlış hatırlamıyorsam Taylor Otwell de lax da bırakılmasını öneriyordu.

Ama tabii benim yöntemi uygulamak istemezse geriye @mgsmus un önerisi kalıyor.

Aklıma başka yol gelmedi.

Serhatt

olay simdi netlesti tam olarak çok teşekkürler bilgiler için hayırlı geceler dilerim.

mgsmus

BoraN7 Weepay post atıyorsa same_site mecburen null olacak. lax ile deneyebilir ama çalışmayacaktır diye düşünüyorum. Get ile dönseydi lax olurdu ki zaten tarayıcılarda SameSite verilmemişse varsayılan lax. Bu bir tercih meselesi değil. Tercih varsa o da Weepay yerine get ile dönüş yapan ya da hiç dönüş yapmadan işlemi gerçekleştiren bir ödeme aracı kullanmak.

Adrese bir şey eklemeden de, gelen orderId ya da paymentId'ye göre de önlem alınabilir. Ben kendi yaptığım sistemde müşterinin verdiği adrese post gönderirken headers içine bazı verilerden hmac ile hash oluşturup ekliyorum. Müşteri de aynı hash'i kendi tarafında oluşturuyor ve bizden gelen istekteki ile karşılaştırıyor, eğer sınamayı geçerse demek ki istek, doğru veri ve doğru adresten geliyordur diye isteği içeri alıp işliyor. Bu önlemi Weepay'in alması gerekiyordu.

Taylor şöyle demiş:

Personally I suggest using "lax". It would not be very typical for other sites to be making full POSTs to your domain anyways.

Ben alternatif bir yöntem bilmiyorum.

BoraN7

mgsmus Anladım hocam.

Bu arada sizin bu yazdıklarınızdan sonra WeePay'i bir inceleyeyim dedim.

Kendi sayfalarında da sizin belirttiğiniz gibi same_site=none olarak kullanılması gerektiğini belirtmişler.

https://developer.weepay.co/destek/sikca-sorulan-sorular/google-chrome-samesite-problemi-nasil-cozulur

@Serhatt