OWASP Nedir? OWASP Mobile Top 10 – Türkçe

OWASP Nedir? OWASP Mobile Top 10 – Türkçe

Merhaba, bu yazıda OWASP nedir/kimlerdir, OWASP Mobile Top 10 ne anlam ifade etmektedir, mobil uygulamalarda en çok karşılaşılan riskler nelerdir? Bu konulardan bahsetmeye çalışacağım. Daha çok teknik bi’ yazı olacağını şimdiden belirtmek isterim. İyi okumalar dilerim.

OWASP Nedir?

Open Web Application Security Project (OWASP) yani Açık Web Uygulama Güvenlik Projesi, kendilerini yazılımların güvenliklerini geliştirmek için çalışan, kâr amacı gütmeyen kuruluş olarak tanıtıyorlar.

OWASP Mobile Top 10 Ne Anlamalıyız ?

OWASP, mobil uygulama geliştiricilerin en çok yaptığı 10 riskli davranışı, Mobile Top 10 adı altında ayrıntılı şekilde paylaşıyor. En son 2016 yılında yayımlanan bu listeyi irdeleyeceğiz. Bakalım mobilci arkadaşlar en çok hangi açıkları bilmeyerek bırakıyorlar.

OWASP Mobile Top 10 Listesi


Improper Platform Usage – Hatalı Platform Kullanımı

Mobil uygulama geliştiricisinin en çok dikkat etmesi gereken yerlerden birisi de AndroidManifest.xml dosyasıdır. AndroidManifest dosyasında uygulama için gerekli izinler istenir. Bu izinleri bir önceki yazımda anlatmıştım, oradan bakabilirsiniz. Geliştirici, bu izinleri kullanıcıdan yani sizden almak için AndroidManifest dosyasına eklemesi gerekir.

Android’in eski versiyonlarında, android 4.2 ve öncesi, “exported” özelliği default olarak true gelmekteydi. Güvenlik açığı tam olarak burada başlıyor. Adından da anlaşılabileceği gibi exported yani dışa aktarma özelliği geliştirici değiştirmediği sürece aktif oluyor. Örneğin depolama izni isteyen bir uygulama indirdiniz ve depolama işlemi gerçekleştireceği için doğal olarak depolama iznine erişim verdiniz. Ancak uygulamayı geliştiren kişi exported ifadesini false yapılmasını bilmiyordu ve yapmadı. Bu yüzden indirdiğiniz başka bir uygulama sizden depolama izni istemeden izni verdiğiniz uygulamanın exported ettiği verileri yani depolama alanınıza erişebilir.

<provider 
       android:authorities="com.els.filebrowser" 
       android:enabled="true" 
       android:exported="true"
       android:grantUriPermissions="true" 
       android:name="com.els.filebrowser.accessfile"/>

Yukarıda zafiyetli bir uygulamanın AndroidManifest.xml dosyasından alınmış bir örnek var.

paint :Dd

Sadece depolama olarak düşünmeyin, bir uygulamanın sizden isteyebileceği tüm izinleri düşünün ve zararlı uygulamanın size izin sormadan diğer uygulamaları kullanarak neler yapabileceğini hayal edin.

anahtar kelimeler: androidmanifest.xml, keychain, intent

Insecure Data Storage – Güvensiz Veri Depolama

Veri depolama bir çok mobil uygulama/oyun için gereklidir. Örneğin kullanıcı ayarlarını takip etmek, uygulama kapatılıp açıldığında kullanıcıyı tanımak gibi özellikler için veri depolama kullanılması gerekir. Bu tarz hassas veriler içermeyen, başkası tarafından görülmesi problem olmayan veriler (public data) telefon içerisinde tutulabilir lakin önemli, korunması gereken, hassas veriler telefon içerisinde tutulmamalıdır. Bu verilerin sınıflandırılması (public-private data) hakkında daha sonra konuşabiliriz.

** Kullanılan depolama tekniklerini şöyle sıralayabiliriz:

  • Shared Preferences
  • SQLite Databases
  • Realm Databases
  • Internal Storage (Dahili Depolama)
  • External Storage (Harici Depolama)

Şifrelenmeden tutulan veriler özellikle hassas bilgiler ise ve telefon içerisinde tutuluyor ise dinamik analiz ile çok rahat bu bilgiler elde edilebilir.

Shared Preferences ile depolanan veriler ‘/data/data/<package-name>/shared_prefs’ içerisinde tutulur. adb ile shell alındığında bu adreste tutulan verileri elde edebilirsiniz.

SQLite Database, verileri ‘/data/data/<package-name>/databases’ adresinde tutar. Shared Preferencesde olduğu gibi SQLiteda da mevzu bahis aynı.

Shared Preferences -> /data/data//shared_prefs

SQLite Database -> /data/data//databases

Realm Database -> /data/data/<package-name>/files/

anahtar kelimeler: sharedpreferences, sqlite db, realm db, dahili depolama, harici depolama, cache, cookie, keychain

Insecure Communication – Güvenli Olmayan Haberleşme

Günümüzdeki çoğu uygulama, web ile haberleşerek varlığını sürdürüyor. Bunun için API dediğimiz Application Programming Interface yani başka uygulamalardaki özelliği kendi uygulamamızda da kullanmamıza yarayan arabirim kullanılıyor. İnternette var olan hava durumunu kendi uygulamanızda göstermek isterseniz oturup var olan API’leri kullanabileceğiniz gibi kendiniz de yazabilirsiniz. API’lerin ayrıntısı başka yazımızın konusu olsun diyelim ve devam edelim.

Gerçek senaryo üzerinden gidelim. Bir tane üniversite sınavı, liseye geçiş sınavı, kpss vs. sorularının soru ve çözümünü paylaşabileceğiniz uygulama indirdiniz. Daha uygulamanın başında giriş yaparken/kayıt olurken kullanıcı adı, email ve parola gibi gerekli alanları doldurup tıkladığınızda bu bilgiler API’ye gidiyor ve doğruluğu sorgulanıyor. Burada OWASP listesindeki diğer maddeler de devreye giriyor lakin onları kendi başlıkları altında anlatacağım. Bu maddede anlatılmak istenen konu şu: Eğer hassas veriler clear-text olarak yani şifrelenmeden, saf haliyle http ile API’ye gidiyor ise ve başka herhangi bir kimlik doğrulaması(başlıklardan biri) yapılmıyorsa uygulamanın trafiği izlenip hassas verilere ulaşabiliriz. Sadece izlemek değil API’ye ulaşan hassas verilere müdahale bile edebiliriz. Kaldı ki sadece bizim hassas verilerimiz değil diğer kullanıcıların da verilerine ulaşabiliriz.

Bunlardan bir tanesi, kullanıcılara atanan ID sırayla veriliyorsa örn: 1070. kayıt yapan kişinin ID’si 1070 ve 1071.kayıt yapan kişinin ID’si 1071 ise API’ye giden ID değerini, uygulamanın trafiğine müdahale ederek değiştirdiğinizde diğer kullanıcıların verilerine ulaşabilirsiniz.

anahtar kelimeler: ssl/tls, http, https, sertifika

Insecure Authentication – Güvensiz Kimlik Doğrulama

Kimlikten kastımız uygulamanın beni ‘ben’ olarak gördüğü verilerdir. Genelde kullanıcı adı ve parola ile sağlanır, bu en basit yöntemdir. Bunun haricinde genelimizin duyduğu İki Adımlı Doğrulama (2FA) da kullanılabilir. Giriş yaparken kullandığımız kullanıcı adı ve parola, veri tabanındaki değerler ile eşleşmesine bakılır ve bizim yetkilerimiz tanımlanır.

Örneğin iki adımda doğrulamaya sahip uygulamada haddinden fazla deneme yaparak (brute-force) 4 haneli kodu bulabilir ve 2FA atlatabiliriz.

anahtar kelimeler: kimlik doğrulama türleri, (benlik kavramı)

Insufficient Cryptography – Yetersiz Kriptografi(Şifreleme)

Bu maddeye kadar hassas verilerden konuştuk ve konuşmaya da devam edeceğiz. Sürekli bi’ verileri şifreleme derdindeyiz. Evet böyle bir derdimiz var ve şifreleme dediğimiz olay dijital ortamdan önce de vardı, var olmaya da devam edecek. Benim ve mesajı iletmek istediğim kişi/ler dışında başkası bilmesin/öğrenemesin diye yola çıkılan bu yolda olay zamanla birçok tekniğe, methodolojiye ev sahipliği yapmış. Sadece bilgisayar alanında değil matematik alanında ve dahi sosyal hayatımızda kullandığımız şifreleme birçok alana hitap eden ve bu alanlardan beslenen bir konudur.

Kriptoloji, Kryptos logos, anlayacağımız dilden Kryptos -> gizli, logos -> deyi* anlamlarına gelmekte. Gizli deyi!. Şifreleme, evvel zamanda saçlarla bile yapılmıştır. Nasıl mı ? Biraz araştırma sizi sonuca götürecektir (ilk çıkan sonuçlar saçları düzleştirme şifreleri tarzına .d doğru cevabı bulmak için doğru soruyu sorun!). Şifreleme konuşmak benim haddime değil naçizane kendi düşüncelerimi paylaştım/paylaşıyorum.

Bizim şu an için ilgilendiğimiz alan dijital ortamda olan şifreleme. Veriler şifrelenmeli derken ilkel kalmış tekniklerle ya da kolayca çözebileceğimiz şekilde şifrelensin demiyoruz. Örneğin Sezar şifreleme ile şifrelenmiş metni kolay bir şekilde ve az uğraşla decrypt(çözümlemek) edebiliriz. Başka bir örnek base64 ile şifrelenmiş metinler. Çok basit bir google araması ile base64 ile şifrelenmiş metni decode edebiliyoruz. Mobil uygulama içerisinde eğer veriler kendi yazdıkları algoritmaya göre şifreleniyorsa orada da devreye uygulamayı decompile edip, kodlara erişip, şifreleme algoritmasını anlayıp, decrypt etmek giriyor (tabii algoritmanın anlaşılabilirliğine bağlı olarak. belki de çözemeyiz). İletişim, depolama ve birçok alanda kullandığımız şifreleme, işte bu yüzden önemli. Şifreleme alanını şimdilik burada bırakalım.

anahtar kelimeler: encryption/decryption, şifreleme algoritmaları

Insecure Authorization – Güvensiz Yetkilendirme

Daha önceki iletişim maddesinde verdiğim ID örneğinde eğer doğrulama yapılmadan API’ye giden her istek kullanıcıların verilerini döndürüyorsa sıkıntı büyük. Örneğin benim uygulama içerisindeki ID’im 1453. Profil sayfama tıkladığımda API’ye id=1453 olarak gidecek ve bana ait veriler dönecek, profil sayfam yüklenecektir. Belki de Herkese açık olmasın dediğim veriler (örn: mail adresim, cinsiyetim) de dönecek. Eğer ben API’ye giden id değerini başka bi’ kullanıcının id’si ile değiştirirsem ve arada yetkilendirme sorgusu olmazsa, ‘sen kimsin kardeşim, admin misin değil misin?’ diyen birisi çıkmazsa, o kullanıcının gizlediği veriler de dönecektir. Gelen isteğin kimden geldiğine bakılmaz ise son kullanıcının görmemesi gereken veriler yetkilendirme hatasından dolayı kullanıcı tarafından da görülebilecektir. Sömürülmesi bu kadar basitken kendisi ciddi zafiyetlerden sayılır.

Authentication ile Authorization (Kimlik doğrulaması ile Yetkilendirme) aynı kavram değildirler.

Authentication = sen, sen misin? Authorization = bunu yapmaya yetkin var mı?

anahtar kelimeler: yetkilendirme, API

Client Code Quality – İstemci Kod Kalitesi

Bu risk direkt olarak kod seviyesindeki zayıflıklardan kaynaklıdır. Uygulama içerisinde kullandığımız 3.parti kütüphaneleri test edip incelememiz gereklidir. Bazen sizin yazdığın kodda zafiyet bulunmasa da kullandığınız kütüphanede zafiyet bulunduğu için uygulamanız sömürülebilir. Bu madde altına yazabileceğimiz zafiyetler arasında şunlar vardır: buffer overflows, format-string, SQL injection.

anahtar kelime: code-level hatalar

Code Tampering – Kod Kurcalama

Evet, kod kurcalama. Geliştiricinin, bir başkası tarafından uygulamanın kodlarıyla oynadığını tespit etmesi oldukça zordur. Bu maddeyi şöyle açabiliriz. Siz uygulamayı IOS tarafında App Store’da, Android tarafında Google Play Store’da paylaştıktan sonra X kişisi sizin uygulamanızı decompile(kaynak koda ulaşma) edip kendisine göre düzenleyip compile(derlemek) edebilir. İçerisine amacına uygun olarak ister kendisine gelir elde edebileceği isterse uygulamayı yükleyenlere zarar verebileceği kodları yazıp compile ettikten sonra 3.parti dağıtımların paylaşıldığı platformlarda, .apk dosyalarının paylaşıldığı sitelerde kendisi adına paylaşabilir. Neden bilinmeyen kaynaklardan uygulama indirmememiz gerektiğini de anladık. Ayrıca frida kullanarak çalışan uygulamanın fonksiyonlarına müdahale edilebilir. Frida da çok geniş bi’ konudur, bu da başka bi’ yazımızın konusu olsun. Örnek amaçlardan birisi de premium özelliklere erişim sağlamaktır. Anlattığım teknikleri kullanarak uygulamanın premium özelliği elde edilebilir. Oyun içi paranın miktarıyla dahi oynanabilir.

Code Tampering’e karşı alabileceğimiz önlemlerden bahsedecek olursak, şunları söyleyebiliriz. Decompile edildikten sonra kodun okunmasını önlemek için uygulamayı obfuscate(bulanıklaştırma) edebiliriz ya da uygulamanın çalıştığı cihazda root/jailbreak kontrolü yapabiliriz.

anahtar kelimeler: frida, hooking, patching, kod modifikasyonu

Reverse Engineering – Tersine Mühendislik

Tersine mühendislik günümüzde çok duyduğumuz, karşılaştığımız bi’ terim. Uygulamalar bildiğiniz gibi compile edilir makine diline çevrilir. ‘Tersine’den kasıt bu decompile etmektir yani compile edilmiş uygulamanın kodlarına ulaşmaya çalışmaktır. Tersine mühendislik sadece yazılım alanında değil somut şekilde var olan makineler üzerinde de yapılabilinir. Makinenin nasıl çalıştığını anlamak için parçalar sökülebilinir, çalışma mantığını kavramak için makine çalıştırılabilinir. Aynı şekilde yazılım alanında da uygulama nasıl çalışıyor, nerede hangi teknolojiler kullanılmış, hangi fonksiyonlar ne için yazılmış gibi soruların cevabına ulaşabiliriz. Çok önemli bi’ kavramdır, dediğim gibi sadece yazılım alanında değil hayatımızın birçok daha alanında kullanabilirsiniz. İnsanlar sizin hakkınızda ne düşündüğünü öğrenmek isterken bile 🙂

anahtar kelimeler: obfuscation, decompile/compile

Extraneous Functionality – Gereksiz İşlevsellik

Geliştiriciler debug modda bazı test amaçlı denemeler, fonksiyonlar yazıyorlar fakat bunu insanlara sunarken silmeyi unutuyolar. Bu da backdoor sahibi bi’ uygulama demek.

Bunun önüne geçmek için android tarafında bizim meşhur AndroidManifest dosyamıza “android:debuggable” false olarak eklenmeli. Ayrıca log class’ını kullanan methodlara dikkat edilmeli, ‘release’ alınırken silinmeli. ProGuard gibi kodlarınızı karmaşıklaştıran (obfuscate eden) programları kullanabilirsiniz. IOS tarafında ise NSLog nedir diye araştırabilirsiniz.

anahtar kelimeler: backdoor(arkakapı), logging, debug mod, dikkat düzeyiniz


Yukarıda yazan maddeleri tek başlarına düşünmeyin, hepsini birer bütünün parçaları olarak görmeye çalışın. Unutmayın bu maddeler, mobil uygulama geliştiricilerinin en çok yaptığı 10 risk. Elbette bu riskler zaman içerisinde değişecektir. Bu yüzden madde(ler)de değil anlamda kalın. Güvenlik ile ilgilenen gençlerin ‘benim neden yazılım bilmem gerek yha’ dememeleri gerektiği umarım bu yazıyla birlikte daha da anlaşılabilir hale gelmiştir.

Yanlış veya eksik gördüğünüz kısımları lütfen benimle paylaşın.

İyi günler, iyi okumalar dilerim. Esen kalınız.

Kaynaklar

* Dil, söz, işaret, mimik vb. anlatım araçlarının bütünü, logos. (sozluk.gov.tr)

** https://mobile-security.gitbook.io/mobile-security-testing-guide/android-testing-guide/0x05d-testing-data-storage

Yazdığım bu yazıda bazı teknik olayları Siber Kulüpler Birliği‘nin eğitimlerinde öğrendim, bu yüzden Mert Can Coşkuner Hocama teşekkür ediyorum.

Related Posts

Facebook Comments