Yeni Nesil Robots.txt - Apple App-Site-Association

Invicti Security Team - 29 Nisan 2019 -

Robots.txt dosyasını botlar geze dursun, Custom URI'lardan dolayı ortaya çıkan güvenlik ihlaline Apple'dan yeni uygulama: Apple App-site Association, Robots.txt'den daha fazlasını geliştiricilere sunuyor.

Yeni Nesil Robots.txt - Apple App-Site-Association

Capture the flag yarışmalarında katılımcıların web uygulamalarında sıkça kullandığı ve arama motoru robotlarının web sitelerindeki gezinimlerini kontrol eden robots.txt dosyasının iOS versiyonu Apple tarafından geliştirildi. Apple-app-site-association (AASA) isimli dosyadaki konfigürasyonlar ile web uygulama geliştiricileri, sitelerine bir link vasıtasıyla gelen iOS kullanıcılarının kendi platformlarına uyarlanmış uygulamalarını veya sitelerini ziyaret etmelerini sağlayabiliyor. Bu ve bunun gibi yönlendirme mekanizmalarını Apple, ‘Universal Link’ (Evrensel Bağlantı) olarak adlandırdığı yöntem ile gerçekleştiriyor. Bu yazımızda Robots.txt, Universal Link ve AASA’nın ne olduğundan bahsedeceğiz.

Robots.txt Nedir ve Ne İçin Kullanılır?

Robots.txt olarak bilinen robot engelleme standardı, 1994’de Martijn Kosner isimli programcı tarafından önerilen, sunucularda bot gibi her türlü web crawler’ın Denial of Service (DoS) saldırılarına yol açmasını engelleyecek bir düzenleme. Bu düzenleme sayesinde siteyi ziyaret eden robotların sitenin hangi sayfalarına erişim izni olduğu belirtiliyor. Genellikle bu robotları arama motorları siteleri sınıflandırmak ve kategorilendirmek için kullanır. Web sitesi yöneticisi web sitenin kök dizinine robots.txt adlı dosyada aşağıdaki formatta talimatları belirtir. Birçok direktifi mevcut olan robots.txt dosyasının zorunlu olduğu iki ana direktifi vardır. User-agent bot’un adını, Disallow ise, adından da anlaşılacağı gibi, bu botun ziyaret etmesinin istenmediği dizini belirtir. Her bir dizin için ayrı bir Disallow direktifi gerekmektedir.

User-agent: Googlebot
Disallow: /ornek-altdizin/

Spidering olarak da bilinen crawling işlemi, arama motor robotlarının web sitelerini gezip ve içeriği toparlayıp indexledikten sonra kullanıcıya sunmasına deniyor. Bu işlem gerçekleşirken, bir robotun ilk yapacağı iş, girdiği sitenin robots.txt dosyasına bakıp kendisine verilen izine göre sitede gezinim yapmak. Bir robots.txt dosyası eksikliğinde veya yanlış konfigürasyonunda robotlar default olarak sitenin tüm dizinlerini ziyaret edip indexleyecektir. Ancak unutmamak gereken iki önemli nokta var:

  • Zararlı robotlar robots.txt’yi tamamen yok sayacaktır
  • Robots.txt dosyası public erişime açık. Bu yüzden kimsenin görmesini istemediğiniz bilgileri bu dosyada bulundurmamalısınz.

Son maddeyi dikkate almayan site yöneticilerinin ihmalkârlığından dolayı saldırganlar, sızma testlerini gerçekleştirenler ve CTF yarışmacıları bu dosya içerisinde bulunan sitenin gizli dizinlerini, stage ve admin panellerinin adreslerini keşfedebilir. Netsparker bir sitenin robots.txt dosyasını rahatlıkla bulup raporluyor.

Mobil Uygulamalarda Veri Alışverişinin Kısa Geçmişi ve Universal Linkler 

Universal Linkleri anlamak için iOS 9'a kadar uygulamalar arası veri alışverişinin nasıl gerçekleştiğine dair bir retrospektif sunalım.

iOS 9’a kadar bir uygulama; başka bir uygulama, örneğin Facebook uygulaması, üzerinden bir kişi ya da kuruluşun profilini görüntülemek istiyorsa bu talebini Custom URI denilen bir yöntem ile gerçekleştirebiliyordu. fb://profile/33138223345 adresi söz konusu uygulama üzerinden Facebook uygulamasını açabiliyor ve Wikipedia'ya ait Facebook profil sayfasını görüntüleyebiliyordu.

Bu görece kolay ve zahmetsiz bir yöntemdi. Fakat birkaç dezavantajı da beraberinde getiriyordu. Bunlardan ilk ve en önemlisi bu custom URI'ların ancak ve ancak bu isteği karşılayacak bir uygulama cihazda kurulu olduğu takdirde iş göreceği idi. Şayet bu isteği yorumlayacak bir uygulama telefonda kurulu değilse bunun için varsayılan bir fallback mekanizması yoktu.

Bu klasik yöntem güvenlik açısından da bir dizi riski beraberinde getiriyordu. Bir Custom URI'ı birden fazla uygulama paylaşabilirdi. Bunun için önleyici bir mekanizma yoktu.

Custom URI'a yapılacak isteği karşılayacak bir uygulama yoksa isteğin boşa düşeceğinden yukarıda söz etmiştik. Son zamanlarda başvurulan bir yöntem ise güvenlik bakımından tüyleri diken diken edecek cinstendi. Bir Custom URI'a istek yapmadan önce uygulamalar sniffing'e başvurarak, yani bu Custom URI'ı karşılayacak bir uygulama yüklü olup olmadığını peşinen kontrol edebiliyorlardı. Kullanıcının cihazında Facebook uygulaması yahut Wikipedia uygulaması yüklü olup olmadığı bilgisi üçüncü bir uygulama tarafından erişilebilir oluyordu.

Apple-App-Site-Association’ın Getirdiği Güvenlik Mekanizması

Universal Link olarak adlandırdığı bu yeni konsept sayesinde Apple, web'in en önemli unsuru olan URL'i adına yakışır bir şekilde cihaz bağlamında kaynaklara erişim için yeniden anlamlandırıp Custom URI'nin bütün meşakkatlerini çözmeyi hedefledi.

iOS 9'dan itibaren Apple, bu işi web’in doğuşundan itibaren kaynaklara erişmek için kullandığımız evrensel bir anahtar olan URL'ler ile handle etmeye karar verdi. Bu isabetli karar ile birlikte yukarıda saydığımız risklerin tamamını egale eden Apple, sahiplik doğrulamasını zaten domain'in kendisi üzerinden yapıyor; URL ile birlikte talep eden kaynağı handle edecek bir uygulama yoksa yahut uygulamanın kendisi talep edilen kaynağı işlemeye gönüllü değilse Safari ya da varsayılan tarayıcının URL'leri işlemesine devam ediyor.

Peki iOS 9 ile birlikte gelen bu mekanizma hangi adımlarla kotarılıyor?

Bir uygulama iOS cihazına yüklendiğinde uygulama ile ilişkilendirilmiş web sitesinin ana dizininde Apple App Site Association (AASA) adı verilen bir dosyanın var olup olmadığı kontrol ediliyor. JSON tipinde (.json uzantısı değil, buraya dikkat) servis edilmesi beklenen dosyadan, uygulamanın handle edeceği path'lerin listesini barındırması bekleniyor. Bu dosya aynı zamanda HTTPS üzerinden servis edilmek zorunda.

AASA dosyası içerisinde JSON formatında uygulamanın erişmesine izin verilen ve verilmeyen URL’ler bulunmakta. Tıpkı robots.txt dosyasında olduğu gibi, her domain için farklı konfigürasyon gerekmekte ve appID ve path belirtilmekte. İşleyişi robots.txt’ye birçok noktada benzerlik gösteren bu dosya, HTTPS sunucu üzerinde ve /.well-known/apple-app-site-association dizininde bulunması gerekiyor. Aşağıda bu dosyada bulunan Jolly adlı mobil uygulama için kurulan örnek bir konfigürasyon görebilirsiniz. NOT ile başlayanlar, robots.txt’de Disallow direktifinde bulunan pathlerin muadili:

{
  "activitycontinuation": {
    "apps": [
      "W74U47NE8E.com.apple.store.Jolly"
    ]
  },
  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": "W74U47NE8E.com.apple.store.Jolly",
        "paths": [
          "NOT /shop/buy-iphone/*",
          "NOT /us/shop/buy-iphone/*",
          "/xc/*",
          "/shop/buy-*",
          "/shop/product/*",
          "/shop/bag/shared_bag/*",
          "/shop/order/list",
...

AASA’nın Geleceği

Nasıl robots.txt dosyasına gizli dizinler, admin panelleri gibi arama motorlarının indexlemesi istenmeyen adreslerin bulunması mümkünse, apple-app-site-association dosyasında da aynı hassasiyette olan bilgiler mevcut olabilir. Günümüzde robots.txt ile ilgili farkındalık oluşturulduğu için saldırganların merceği altına girebilecek yeni dosya .well-known/apple-app-site-association dizininde olabilir. Bunun sebebi ise, çağımız gereği ziyaret ettiğimiz sitelerin çoğu iOS uygulaması olarak veya iOS cihazların kullanışlılığına sunmak amaçlı entegre edilmiş durumda. Geliştiricilerin bu dosyada da hassas davranmaları gerektiğini hatırlatmak isteriz. Bu dosyanın doğru ve verimli konfigürasyonu için Apple’ın dokümantasyonunu okumanızda fayda var.