Mixed Content Uyarısını Giderme ve Yeşil Kilidi Geri Getirme

Adres çubuğundaki yeşil kilit gitti, yerine "Not Secure" yazısı veya bir uyarı simgesi geldi ve tarayıcı konsolunda şuna benzer bir satır tekrarlanıyor: Mixed Content: The page at 'https://example.com/' was loaded over HTTPS, but requested an insecure resource 'http://example.com/img/logo.png'. This request has been blocked. Eğer şu anda bunu görüyorsanız, sorun neredeyse her zaman https:// ile yüklenen bir sayfanın içinde yüklenen bir http:// kaynağıdır. Tarayıcı bunu ya engeller ya da yalnızca uyarır ve her iki durumda da kullanıcı güveni zedelenir.

Çoğu kişinin geç fark ettiği nokta: mixed content her zaman sitenizin hacklendiği anlamına gelmez. Yani eski bir görsel, font, script veya iframe hâlâ güvensiz protokolle çağrılıyor demektir. Bu ikisi arasındaki farkı ciddiye alın, çünkü çözüm yolu tamamen farklıdır.

Yeşil kilit neden gider ve tarayıcı neyi engeller

Tarayıcılar iki mixed content kategorisini ayırır. Birinci kategori passive veya görsel olandır: görsel, video, ses dosyası. Bunlar genellikle yalnızca uyarı alır ve yüklenir, ancak yeşil kilidi yok eder. İkinci kategori active veya aktif olandır: JavaScript, CSS, XHR/fetch, iframe, WebSocket. Bunlar acımasızca engellenir. Yani sitenin görünümü sağlam olabilir ama bir analitik scripti veya sohbet widget'ı hiç çalışmayabilir ve siz yalnızca "form çalışmıyor" diye ticket alırsınız.

Daha az görülen üçüncü bir durum da vardır: https'ten http'ye redirect. Örneğin sitedeki bir bağlantı http:// ile başlar ve sunucunuz onu güvenli sürüme yönlendirmez. Sonuç bir döngü veya güvensiz bir sayfadır. Sorunun DNS veya alan adı kayıtlarından kaynaklanmadığından emin olmak için DNS ve ağ kontrol araçlarını kullanın ve herhangi bir değişiklikten önce A ve CNAME kayıtlarını kontrol edin.

Konsol ve basit bir komutla tam kaynağı bulma

İlk yaptığım şey şudur: sayfayı Chrome'da açarım, F12 tuşuna basarım, Console sekmesine geçerim ve mixed filtresini yazarım. Suçlu dosyanın tam adresi orada yazılıdır. Sayıları fazlaysa, Network sekmesine Protocol sütununu eklerim ve tüm http isteklerinin görünmesi için başlığına tıklarım. Bu yöntem kaynak kodda aramaktan daha hızlıdır.

Site kendi sunucunuzdaysa ve shell erişiminiz varsa, basit bir grep tüm alan adını tarar:

grep -rIn --include="*.php" --include="*.html" --include="*.css" --include="*.js" \
  -e 'http://' /var/www/html | grep -v 'https://' | head -50

-I bayrağı ikili dosyaları atlar ve -n satır numarası verir. WordPress kullanıyorsanız, bu komut wp-content klasöründe genellikle eklenti CSS dosyalarında ve ikon fontlarında birkaç eşleşme bulur. Orada kalın, çünkü en çok suçlu bu iki kategoridir.

Kaynak dosyada değil de veritabanındayken

Grep hiçbir şey bulamadıysa ama konsol hâlâ hata veriyorsa, kaynak veritabanındadır. WordPress'te http:// adresleri wp_options tablosunda (siteurl ve home anahtarları), wp_posts içinde yazı içeriklerinde ve wp_postmeta meta verilerinde gizlenir. Önce yalnızca bir sorguyla sayın, sonra değiştirin:

SELECT COUNT(*) FROM wp_posts WHERE post_content LIKE '%http://example.com%';

Sayı küçükse elle düzeltin. Yüzlerce kayıt varsa, herhangi bir işlemden önce yedek alın ve sonra wp search-replace ile ilerleyin:

wp search-replace 'http://example.com' 'https://example.com' --all-tables --precise --dry-run

--dry-run bayrağını kaldırmayın. Önce çıktıyı görün, sonra çalıştırın. --precise da serileştirilmiş değiştirmeleri ve serialized verilerin bozulmasını önler. Bu bayrak olmadan, wp_options içinde kayıtlı widget'lar değiştirme sonrası boşalır ve siz eklentinin bozulduğunu düşünürsünüz.

Burada hata yapılıyor: çoğu kişi doğrudan phpMyAdmin'e gider ve bir UPDATE ... REPLACE() ile her şeyi değiştirir. Sonuç şu olur: site açılır ama page builder eski içeriği göstermez veya tema ayarları varsayılana döner. Belirtisi de şudur: yönetim panelinde her şey vardır ama ön yüzde bazı bölümler boştur. Nedeni tam olarak, dize uzunluğu artık kayıtlı sayıyla uyuşmayan serialized veridir.

Toplu düzeltme ve geri dönüşü önleme

Temizlikten sonra iki iş kaldı. Birincisi, Content-Security-Policy başlığını ciddiye alın. Basit bir komutla tarayıcının neye izin verdiğini görebilirsiniz:

curl -sI https://example.com | grep -i -e 'content-security-policy' -e 'strict-transport-security'

Eğer Strict-Transport-Security max-age=31536000 değeriyle dönmediyse, HSTS etkin değildir ve tarayıcı hâlâ http sürümünü denemeye izinlidir. Bu başlığı Nginx'te şöyle eklerim:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

İkincisi, genel yönlendirme. Nginx'te 80 numaralı port için her şeyi https'e gönderen ayrı bir blok koyun. Bunu yapmazsanız, forumlarda veya eski e-postalarda kalan her eski bağlantı kullanıcıyı tekrar güvensiz sayfaya getirir ve siz sorunun çözüldüğünü düşünürsünüz.

Burada kabul etmeniz gereken maliyet: HSTS tek yönlüdür. Tarayıcı onu gördüğünde, max-age süresi dolana kadar sitenizi http üzerinden açmaya izinli değildir. Eğer sonradan SSL sertifikası süresi dolarsa veya sunucuyu taşırsanız ve sertifika hazır değilse, kullanıcılar katı bir hatayla karşılaşır ve tarayıcı önbelleğini temizlemekten başka çareleri kalmaz. Bu yüzden max-age'i önce 300 saniye gibi küçük bir sayıyla test edin, sonra bir yıla çıkarın.

İşi kısaltan araçlar

Really Simple SSL veya Better Search Replace gibi eklentiler işi hızlı yapar, ancak her birinin bir maliyeti vardır. Birincisi bazen .htaccess dosyanızla çakışır ve manuel yönlendirmelerinizi etkisiz kılar; ikincisi büyük veritabanlarında zaman aşımına uğrayabilir. Siteniz birkaç yüz bin kayıttan fazlaysa, eklenti yerine SSH üzerinden WP-CLI kullanın. Daha hızlıdır ve iş ortasında kesilmez.

Tüm bunlardan sonra hâlâ hata görüyorsanız, kaynak muhtemelen harici bir servisten geliyor: bir CDN scripti, bir Google fontu veya bir harita iframe'i. Bunları tema kaynağında veya eklenti ayarlarında bulup https sürümüyle değiştirmelisiniz. Sorunun sunucu tarafında olmadığından ve servislerin çalıştığından emin olmak için servislerin anlık durumunu kontrol edin. Siteniz sürekli saldırı hedefiyse ve bu değişiklikler sürekli geri dönüyorsa, dosya manipülasyonu olasılığını ciddiye alın; bu durumda WordPress güvenliği; wp-config'ten kendileri açık olan eklentilere doğru başlangıç noktasıdır.

Pratik bir not: her değişiklikten sonra tarayıcı önbelleğini ve CDN önbelleğini temizleyin. Gördüğüm ticket'ların yarısı, geliştiricinin değişikliği yapması ama tarayıcının eski sürümü göstermesi ve onun düzeltilmediğini düşünmesi yüzündendir.

Sık sorulan sorular

Mixed Content sitenin gerçek güvenliğini etkiler mi yoksa yalnızca görünüşte mi?

Her ikisi de. Passive kısım daha çok görünüştedir ve yeşil kilidi yok eder, ancak active kısım gerçekten tehlikelidir. Bir script http yolundan yüklenirse, ağ yolundaki herkes onu manipüle edebilir ve kullanıcının tarayıcısına istediği kodu gönderebilir. Yani güvenli sayfanız bir bilgi hırsızlığı aracına dönüşebilir.

SSL kurduktan sonra neden hâlâ Mixed Content uyarısı alıyorum?

Çünkü sertifika kurulumu yalnızca sunucunun tarayıcıyla iletişimini şifreler ve içeriğinizdeki adresleri değiştirmez. Veritabanında veya tema dosyalarında http:// adresi kaldığı sürece tarayıcı onu güvensiz görür. Yalnızca sertifikayı kurmak değil, adresleri de düzeltmeniz gerekir.

WordPress ayarlarında site adresini değiştirmek sorunu çözer mi?

Yalnızca bir kısmını. siteurl ve home değişikliği WordPress tarafından üretilen adresleri düzeltir, ancak yazı içeriklerindeki, meta verilerdeki ve eklenti CSS dosyalarındaki adresler olduğu gibi kalır. Tam kapsama için tüm veritabanında arama ve değiştirme yapmalısınız.

Hangi eklentinin sorumlu olduğunu nasıl anlarım?

Eklentileri tek tek devre dışı bırakın ve her seferinde konsolu mixed filtresiyle kontrol edin. Hata bir eklentiyi devre dışı bırakınca gidiyorsa, suçlu odur. Daha kesin yol, Network sekmesinde Protocol sütununa bakmak ve güvensiz istek gönderen alan adını bulmaktır; genellikle alan adı o eklentiyi ele verir.

Bu işin bir kez ve sonsuza kadar bitmesini istiyorsanız, temizlikten sonra veritabanı ve dosyalar üzerinde haftalık otomatik bir tarama koyun ki eklenen ilk http:// adresi kullanıcı tarafından görülmeden önce bulunsun. Ciddi trafiği olan ve her dakikanın maliyetli olduğu siteler için ServerNet sunucu güvenlik hizmetleri tam da bu izleme ve sıkılaştırma katmanını kapsar.