Uygulamam php üzerinden charles ile kırılıyor. Engellemenin bir yolu var mı?

Merhabalar öncelikle iyi forumlar. Uygulamam dediğim gibi charles ile php dosyalarına erişip post atıp MySQL veri tabanına kredi ekletebiliyor. Bunu engellemenin bir yolu var mı? SSL aktif ancak yine de nasıl yapıyorlarsa charles ile dosyaları tekrar tekrar kullanabiliyorlar. Anladığım kadarıyla emulator yardımı ile mobil uygulamayı açıp charles ile trafiği kontrol ediyorlar. Bütün php dosyaları gözüküyor. Tabi ki php kodlarını göstermiyor ancak post atabiliyor.

bu tarz şeyler için csrf token gibi ek güvenlik önlemleri var bunu tamamen engellemenin hiçbir yolu yok sadece işi zorlaştırabilirsin. Post limiti koymak gibi önlemler alabilirsin. Ayrıca krediyi nasıl ekletiyor? Authorization olayı yok mu

Teşekkür ederim. Ama bu tokeni hem uygulamadan gönderip hem php üzerinden nasıl onaylatacağım onu çözemedim. Google play iap token geldi aklıma şöyle bir yol işe yarar mı? Google play iap da oluşan tokeni alıp tek kullanımlık olacak şekilde veri tabanına kayıt etsem bu iş görür mü acaba?

Yaptığın şeyin tam olarak ne olduğunu anlamam lazım. Uygulama içi satın almada mı post kullanıyorsun kredi ne kredisi işlemleri bana açıklaman lazım

Uygulama içi satın alma kullanıyorsan alışveriş sonrası google sana şu şekilde bir cevap gönderiyor

{
 "orderId":"12999763169054705758.1371079406387615",
 "packageName":"com.example.app",
 "productId":"exampleSku",
 "purchaseTime":1345678900000,
 "purchaseState":0,
 "developerPayload":"bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ",
 "purchaseToken":"rojeslcdyyiapnqcynkjyyjh"
 }

orderId yi google api ile doğrulayıp productId kullanarak gerekli kredi yüklemesini yapıp orderid yi kendi vertabanına ekleyebilirsin böylelikle aynı sorgu tekrar gönderilirse orderId zaten veritabanında olduğu için kredi yüklemesini yapmazsın sahte bir orderid yollanırsa da google api bunu doğrulamayacaktır. Direkt rest api ile satın alma doğrulaması olmadan kredi yükletmek zaten bu şekilde kötüye kullanımla sonuçlanır

Revenuecat bu işler için kullanılıyor hem ios hem android satın alımları doğrulayıp tüm kontroller yaptırabileceğin bir api

https://docs.revenuecat.com/docs/creating-play-service-credentials

Merhaba tekrardan ilginiz için çok teşekkür ederim. Bu işimi bir tık çözebilirdi ancak ads kısmında da aynı şekilde kredi eklettiğim için muhtemelen yine kırılacaktı. En azından kullanıcının günlük ads ile kredi kazanma miktarı sınırlı ancak bu da yayılırsa işime gelmezdi. Şöyle bir yoldan gittim %100 çözüm olur mu bilmiyorum. csrf token burda baya işime yaradı en azından algoritması.
Sorunum bu arada daha açık bir şekilde şöyleydi:
Uygulama üzerinden post ederek krediyi kullanıcıya veriyordum. Charles ile buradaki kredi ekleme phpsini tekrar tekrar kullanıp kendilerine kredi ekliyordı.
Çözümüm:
1) Başka bir php üzerinde token oluşturup bunu kayıt ettiriyorum.
2) Oluşturduğum token yine php üzerinden olduğu için muhtemelen charles ile gözükecekti. Bu yüzden 100 karakter arasına oluşturduğum tokeni dağattım ve bunu yaparken uygulama içinde çözmesi için dağıtma yolunu kayıt ettim. Daha basit örneklendirecek olursam elimizde cfa5 diye bir key olsun. 10 karakterli yeni bir key oluşturmuş olalım fc5fad24cd olsun. Bu yeni oluşturdum token içine gizlemek için rastgele numaralar oluşturdum 1-10 arası aynı olmayan. Mesela 4-6-7-10 olsun her bir harf için bir numara. Bunları da 10 lu token içindeki karakterler ile değiştirdim. Yeni uzun token bu oldu fc5cafa4c5
3) Asıl tokeni kayıt ettirdiğim yer ile kontrol ettiriyorum eğer doğru ise kayıtlı token siliniyor. Kayıtlı yer de boş olduğu için tokenlerin uniq olmasına gerek kalmıyor. Veya tokenleri bir yere kayıt ettirip sürekli oradan bu token kullanılmış mı diye kontrol ettirmeme de gerek kalmıyor.

Bilmiyorum ne kadar anlatabildim ancak csrf token çok işime yaradı tekrardan teşekkürler. Ben anlatırken ve yaparken yoruldum. Umarım kırılması o kadar kolay değildir.
Ve son olarak bir soru daha sormak istiyorum. Charles bu şekilde $_SESSION içindeki olan değişkenleri de yakalayabiliyor mu?

charles browser da ne varsa yakalar,
csrf token pek işe yaracağını sanmıyorum, şundan ötürü charles da breakpoint vardır sen csrf token li post işlemini daha sunucuya varmaadan charles araya girip düzenleme imkanı sağlıyor,
charles normalde ssl bağlantıları browser a kendi sertifakasını yükleyerek çözebiliyor,
bence en sağlıklı çözüm sunucu ve client arasına veri alışverişini de kendi şifrelemeniz ile encode etmek
sonuçta bu bir uygulama uygulama içinden sunucuya gönderilecek verileri encrpyt edersiniz, daha sonra da sunucu tarafında bu verileri decrypt ettiken sonra işlemi tamamlarsanız, charles ile aradaki iletişimi çözseler bile görecekleri kargacık burgacık şifrelenmiş veriler olacaktır.
bu çözülemez mi tabiki çözülebilir ama her önüne gelen çözemez işin uzmanı tarafından çözülebilir,
işleri çözecek kişi için bir tık daha zorlaştırmak isterseniz de, devamlı değişken encrpyt yöntemi kullanabilirsiniz,
o da şöyle kullanıcı app inize login olduğunda kullanıcıya özel bir encrpy key berlilerseniz bunu da sunucu tarafında tutarsınız o kullanıcının işlemlerini o key ile çözersiniz, bu keyler her login de veya yaarım saatte bir veya 5 işlemde bir değişcek şekilde ayarlarsınız daha sıkı bir sisteminiz,
diğer bir yöntem veya ek bir yöntem olarak da ssl hsts açmak olur, hsts de kullanıcı çözdüğü verileri düzgün göremez fakat bunun da uzman kullanıcılar için charles tarafında çözümü var.
sonuç olarak %100 bir çözüm çok zor fakat bunun minumum seviyeye düşürmek amacınız olabilir, herşeyi yaptıktan sonra yapılan hileyi de algılayacak bir sistem gelirşirirseniz de geriye kalan 3-5 taneyi ayıklamak daha güzel olabilir,
kolay gelsin



ek sonradan aklıma csrf ile alakalı daha kolay bir şekilde çözüm yöntemi geldi
şimdi siz bir tane bayımsız bir csrf gönderip kontrol sağlıyorsunuz,
ek bir csrf daha oluşturup bunu bağımlı şekilde yapabilirsiniz.,
şöyleki mesela kullanıcı userid ve bakiye bilgileri post ediyor size bu bilgileri kullarake client tarafında bir hashlenmiş olarak gönderirirsiniz tıpku bir csrf gibi
örnek cient tarafın md5(userid.bakiye.secretkey)
hem hashli hemde salt düz veri şekilde userid ve bakiye gönderildiği için sunucu tarafından tekrar hashleyip iki hash in birbirine eşit olup olmadığını da kontrol edebilirsiniz.
if( gelenhash == md5($post['userid'].$post['bakiye'].secretkey) )

Teşekkür ederim ilginiz için. Şuan da bir nevi encrpyt - decrypt sistemi kullanıyorum. Sistem iki taraflı çalıştığı için token post edilirken gözüküyordu. Tokeni oluşturup saf halini mysql üzerinde kullanıcı içinde saklıyorum. Token örneğin asf ise bunu 100 karakter içeren bir hash'a saklıyorum o da mesela 20 üzerinden örnek verecek olursam asdfasdfasdfasdfasdf olsun (bu da random oluşuyor token de) daha sonra bunu belirli bir dizi ile içerisinde değiştirme yaparak alıyorum. Php üzerinde token şu şekilde gözüküyor örnek: 3 karakterli asf tokenine her birine bir numara atayalım a=6 s=12 f=18 (Buradaki numaralar önceden rastgele oluşturdum 32 karakterli md5 kodu olduğu için tersine mühendislik ile de çözmesi kolay olmayacağını düşünüyorum) bunu da random hash'a gizleyince bu şekilde oluyor asdfaadfasdsasdfafd bunun çözümü de uygulama içinde yapılıyor ve saf token ortaya çıkıp tekrar php ye gönderiliyor. Php üzerinden de sql üzerinde daha önce kayıtlı olan veri ile karşılaştırıyorum. Charles te asdfaadfasdsasdfafd şeklinde gözüktüğü için içinden keyin ayıklanması epey uğraş verici. Ha bu arada bütün işlemler bittikten sonra mysql de kullanıcı datasından siliyorum bunu. Daha sonra her işlem için önce token oluşturulup daha sonra kredi eklenme çalışması gerekiyor. Eğer tokeni oluştursa bile göreceği sadece rastgele oluşturulmuş ve içinde token saklı bir hash oluyor. Anlatması benim için baya zor umarım anlatabilmişimdir. Ha bu arada %100 çözüm olur mu bilmiyorum kırılmaz bu da umarım . Kırılması için 32 tane numaranın çözülmesi lazım hangi karakterin hangi karakter ile yer değiştirildiğini bulunması gerekecek.

uygulamanı pm den gönderirsen müsait bir zamanda deneme yapabilirim.