Tehlikeli HTTP Metodları Nasıl Devre Dışı Bırakılır

Herhangi bir şeyi devre dışı bırakmadan önce sunucunuzun gerçekte neyi kabul ettiğine dair net bir resme ihtiyacınız var. Pek çok sunucu, hiç kasıtlı olarak etkinleştirmediğiniz metodları açığa çıkaran izin verici varsayılan ayarlarla gelir.

• curl -v -X OPTIONS https://alanadi.com/ komutunu çalıştırın ve Allow yanıt başlığını inceleyin — bu başlık, kabul edilen tüm metodları listeler.
• Her metodu ayrı ayrı test edin: curl -v -X TRACE https://alanadi.com/, curl -v -X PUT https://alanadi.com/test.txt, curl -v -X DELETE https://alanadi.com/test.txt.
• Yalnızca kök dizini değil, tüm alt dizinleri ve API uç noktalarını kontrol edin — farklı sanal ana bilgisayarlar veya uygulama rotaları farklı fiilleri kabul edebilir.
• Web sunucunuzun erişim günlüklerini gözden geçirerek beklenmedik istemcilerden gelen PUT, DELETE, TRACE, CONNECT veya PATCH kullanımını tespit edin.
• Sensagraph, uç noktalarınızı etkin HTTP metodları için otomatik olarak tarar ve tehlikeli olanları tarama raporunda işaretler.

Her HTTP metodu doğası gereği kötü niyetli değildir; ancak birkaçı, genel kullanıma açık sunucularda etkin bırakıldığında rutin olarak istismar edilir.

• TRACE / TRACK: İstemcinin isteğini yanıt gövdesinde geri yankılar. Saldırganlar bunu, HttpOnly ayarlanmış olsa bile çerez ve kimlik doğrulama başlıklarını çalmak için Siteler Arası İzleme (XST) saldırılarında kullanır.
• PUT: İstemcilerin dosyaları doğrudan sunucuya yüklemesine veya üzerine yazmasına izin verir. Kimlik doğrulamasız bir PUT isteği, saldırganın saniyeler içinde bir web kabuğu yerleştirmesine olanak tanır.
• DELETE: İstemcilerin sunucudaki dosyaları kaldırmasına izin vererek veri imhasına veya site tahribatına yol açar.
• CONNECT: Sunucuya bir TCP tüneli kurması talimatı verir. Kötüye kullanıldığında sunucunuzu saldırganlar için açık bir proxy'ye dönüştürür.
• PATCH (korumasız): Kaynakları kısmen değiştirebilir; kimlik doğrulama ve yetkilendirmeyle korunmazsa yetkisiz veri manipülasyonuna olanak tanır.
• OPTIONS (ayrıntılı): Doğası gereği tehlikeli değildir, ancak üretim ortamında tam Allow başlığını açıklamak, saldırganlara saldırı yüzeyinizin ücretsiz bir haritasını sunar. Minimal veya boş bir yanıt döndürmeyi düşünün.

Apache, hangi HTTP metodlarına izin verileceğini kontrol etmek için <Directory>, <Location> veya .htaccess bloklarında Limit ve LimitExcept direktiflerini kullanır.

• Ana Apache yapılandırma dosyanızı açın (genellikle /etc/apache2/apache2.conf veya /etc/httpd/conf/httpd.conf).
• Uygulamanızın gerçekten ihtiyaç duyduğu metodları (genellikle GET, POST, HEAD) açıkça izin veren ve geri kalanını reddeden bir <LimitExcept> direktifi ekleyin:
  

  <LimitExcept GET POST HEAD>
    Require all denied
  </LimitExcept>

• TRACE metodunu özellikle engellemek için global yapılandırmanıza veya sanal ana bilgisayar bloğunuza şu satırı ekleyin: TraceEnable Off
• .htaccess dosyası kullanıyorsanız, dizin bazında kontrol için aynı LimitExcept bloğunu oraya da ekleyin.
• Yeniden yüklemeden önce yapılandırma sözdizimini doğrulayın: apachectl configtest
• Apache'yi yeniden yükleyin: sudo systemctl reload apache2 (Debian/Ubuntu) veya sudo systemctl reload httpd (RHEL/CentOS).

Nginx, Apache'nin LimitExcept direktifine doğrudan bir eşdeğere sahip değildir; ancak sunucu yapılandırmanızda bir if bloğu veya map direktifiyle aynı sonucu elde edebilirsiniz.

• Nginx sunucu bloğu yapılandırmanızı açın (örn. /etc/nginx/sites-available/alanadi.conf).
• GET, POST veya HEAD dışındaki herhangi bir metod için HTTP 405 döndürmek üzere ilgili server veya location bloğunun içine şunu ekleyin:
  

  if ($request_method !~ ^(GET|POST|HEAD)$) {
    return 405;
  }

• Daha ayrıntılı bir yaklaşım için http düzeyinde bir map bloğu kullanarak bir değişken ayarlayın, ardından bunu konum başına kontrol edin — bu, iç içe if ifadelerini önler.
• TRACE metodunun açıkça engellendiğinden emin olun; Nginx varsayılan olarak uygulama düzeyinde TRACE işlemez, ancak bir proxy'nin arkasına iletilmediğini doğrulayın.
• Yapılandırma sözdizimini test edin: sudo nginx -t
• Nginx'i yeniden yükleyin: sudo systemctl reload nginx

Internet Information Services, istekler uygulama kodunuza ulaşmadan önce HTTP fiillerini web sunucusu düzeyinde engellemenize olanak tanıyan yerleşik bir modül olan İstek Filtreleme özelliğini sunar.

• IIS Yöneticisi'ni açın, sitenizi seçin ve İstek Filtreleme üzerine çift tıklayın.
• HTTP Fiilleri sekmesine tıklayın, ardından Fiili Reddet'e tıklayın ve her tehlikeli metodu ekleyin: TRACE, TRACK, PUT, DELETE, CONNECT, PATCH (kullanılmıyorsa).
• Alternatif olarak, web.config dosyasını doğrudan düzenleyin ve <system.webServer> içine şunu ekleyin:
  

  <security>
    <requestFiltering>
      <verbs>
        <add verb="TRACE" allowed="false" />
        <add verb="TRACK" allowed="false" />
        <add verb="PUT" allowed="false" />
        <add verb="DELETE" allowed="false" />
        <add verb="CONNECT" allowed="false" />
      </verbs>
    </requestFiltering>
  </security>

• WebDAV kullanmıyorsanız WebDAV modülünün devre dışı olduğundan emin olun — WebDAV, PUT ve DELETE metodlarını otomatik olarak yeniden etkinleştirir.
• Değişiklikleri yaptıktan sonra IIS uygulama havuzunu veya siteyi yeniden başlatın.

Web sunucusu yapılandırması ilk savunma hattınızdır; ancak uygulama çerçeveniz de istenmeyen HTTP fiillerini bağımsız olarak reddetmelidir — bu derinlemesine savunma prensibinin bir gereğidir.

• Node.js / Express: Rotaları yalnızca kullandığınız metodlar için tanımlayın (örn. app.get(), app.post()). Diğer metodlar için 405 döndüren bir genel ara katman yazılımı ekleyin:
  app.use((req, res) => res.status(405).send('Method Not Allowed'));
• Django: Görünümünüzün işlediği metodları beyaz listelemek için sınıf tabanlı görünümlerde http_method_names özelliğini kullanın ya da @require_http_methods(['GET', 'POST']) dekoratörünü tercih edin.
• Spring Boot (Java): Metodları @RequestMapping düzeyinde method özniteliğiyle kısıtlayın; örn. @GetMapping, @PostMapping.
• Laravel (PHP): Rotaları açık metod yardımcılarıyla tanımlayın (Route::get(), Route::post()) ve geniş metod listeleriyle Route::any() veya Route::match() kullanmaktan kaçının.
• Rails (Ruby): Kaynak odaklı yönlendirmeyi kullanın ve standart dışı eylemler eklemekten kaçının. routes.rb içindeki rotaları kısıtlayın.
• 405 yanıtıyla birlikte, uç noktanızın gerçekten desteklediği metodları listeleyen uygun bir Allow başlığı döndürün.

Mimarinizde bir API ağ geçidi, yük dengeleyici veya ters proxy (NGINX Plus, HAProxy, AWS API Gateway, Cloudflare vb.) varsa, bu bileşenler trafiği kaynak sunucunuza ulaşmadan önce yakaladığından metod kısıtlamalarını burada da yapılandırın.

• AWS API Gateway: Her kaynakta yalnızca gerçekten ihtiyaç duyduğunuz HTTP metodlarını tanımlayın. Diğer tüm metodlar otomatik olarak 403 veya 404 döndürür.
• Cloudflare WAF: HTTP metodunun TRACE, PUT, DELETE veya CONNECT olduğu durumlarda (belirli kimlik doğrulamalı bir yolla eşleşmediği sürece) istekleri engelleyen özel bir WAF kuralı oluşturun.
• HAProxy: haproxy.cfg frontend bölümüne bir ACL ekleyin:
  acl bad_method method TRACE TRACK CONNECT
http-request deny if bad_method
• Ters proxy olarak NGINX: proxy_pass direktifinden önce, proxy yapılandırmanızda aynı if ($request_method ...) direktifini uygulayın.
• Ağ geçidinizin ve kaynak sunucunuzun aynı metod kısıtlamalarını uyguladığından emin olun — tutarsızlıklar, kaynak IP'nin açığa çıkması durumunda ağ geçidini atlayarak istismar edilebilir.

Yapılandırma değişikliklerini yaptıktan sonra, tehlikeli metodların engellendiğini ve güvenli metodların hâlâ doğru çalıştığını sistematik olarak doğrulayın. Yanlış bir yapılandırma, meşru işlevleri sessizce bozabilir.

• curl -v -X OPTIONS https://alanadi.com/ komutunu yeniden çalıştırın ve Allow başlığının artık engellenen metodları listelemediğini doğrulayın.
• Engellenen her metodu tek tek test edin ve 405 Method Not Allowed (veya 403 Forbidden) yanıtı aldığınızı, 200 veya 500 almadığınızı doğrulayın.
• GET ve POST isteklerinin hâlâ beklendiği gibi çalıştığını doğrulamak için uygulamanızın normal kullanıcı akışlarını (giriş, form gönderimleri, API çağrıları) test edin.
• Tüm alt alan adlarını, hazırlık ortamlarını ve API uç noktalarını ayrı ayrı test edin — kök alan adındaki bir kısıtlama otomatik olarak alt alan adlarına uygulanmaz.
• Değişikliklerin denetlenebilir ve geri alınabilir olması için yapılandırma dosyalarınız için sürüm kontrolü kullanın.
• Sensagraph, yapılandırma değişikliklerinden sonra sitenizi yeniden tarayarak önceden işaretlenen tüm tehlikeli metodların başarıyla devre dışı bırakıldığını doğrulayabilir.

Tehlikeli metodları bugün devre dışı bırakmak yeterli değildir — yeni dağıtımlar, çerçeve güncellemeleri veya altyapı değişiklikleri bunları yeniden etkinleştirebilir. Sürekli doğrulamayı iş akışınıza dahil edin.

• Tehlikeli HTTP metodlarının yeniden ortaya çıkmasını tespit etmek için düzenli otomatik güvenlik taramaları zamanlayın (en az haftada bir).
• Web sunucunuzu veya WAF'ınızı engellenen bir HTTP metodunu kullanan her istek için uyarı verecek şekilde yapılandırın — ani bir artış aktif bir tarama veya yanlış yapılandırma anlamına gelebilir.
• CI/CD hattınıza HTTP metod denetimi ekleyin: dağıtım sonrası bir duman testi olarak hızlı bir curl -X OPTIONS kontrolü çalıştırın.
• Her büyük bağımlılık güncellemesi, çerçeve yükseltmesi veya altyapı değişikliğinin ardından sunucu ve uygulama yapılandırmalarınızı gözden geçirin.
• HTTP metod kısıtlamalarını kuruluşunuzun güvenlik temel belgelerine ekleyin ve yeni mühendisler için işe alım kontrol listelerine dahil edin.
• Sorunların çözüldüğünü ve yeniden ortaya çıkmadığını sağlamak için bulgularınızı bir güvenlik açığı yönetim platformuyla zaman içinde takip edin.