Posts

HTTP Dersleri – Ders 5 – Güvenlik

/0 Comments/in /by

HTTP Dersleri – Ders 1 – Temel kavramlara genel bakış
HTTP Dersleri – Ders 2 – Mimari Yönleri
HTTP Dersleri – Ders 3 – İstemci Kimliği
HTTP Dersleri – Ders 4 – İstemci Doğrulama Mekanizmaları
HTTP Dersleri – Ders 5 – Güvenlik
HTTP Dersleri – Sözlük

HTTP serisini takip ettiyseniz, artık HTTP güvenliği yolculuğuna çıkmaya hazırsınız demektir. Güzel bir yolculuk olacak, söz veriyorum.

Birçok şirket güvenlik ihlallerine maruz kalmıştır. Sadece birkaç önemli özelliği belirtmek için: Dropbox, Linkedin, MySpace, Adobe, Sony, Forbes ve daha birçokları kötü niyetli saldırıların son noktalarında. Birçok hesap ele geçirildi ve en azından birisinde hesabınız vardır.

Aslında şuradan kontrol edebilirsiniz, Have I Been Pwned.

E-posta adresim, güvenlik ihlalinin kurbanı olan 4 farklı web sitesinde bulundu.

Web uygulaması güvenliğinin pek çok özelliği vardır, bir makalede ele alınacak çok şey var, ancak en başından başlayalım. Önce HTTP iletişimimizi nasıl güvenli yapacağımızı öğrenelim.

Bu makalede, hakkında daha fazla bilgi edineceksiniz:

  • Gerçekten HTTPS’ye ihtiyacınız var mı?
  • HTTPS’nin temel kavramları
  • SSL-TLS
  • TLS el sıkışma
  • Sertifika ve Sertifika Yetkilileri
  • Sertifika zincirleri
  • HTTPS zayıf yönleri

Üzerinden geçilecek çok şey var, o yüzden hemen başlayalım.

Gerçekten HTTPS’ye ihtiyacınız var mı?

Düşünüyor olabilirsiniz: “Elbette bütün web sitelerinin korunması gerekmez”. Bir web sitesi hassas verilere hizmet etmiyorsa veya herhangi bir form gönderiminde bulunmuyorsa, yalnızca “Güvenli” yazan URL çubuğunda küçük yeşil işareti almak için sertifikalar satın almak ve web sitesini yavaşlatmak aşırı olacaktır.

Bir web siteniz varsa, mümkün olduğunca hızlı yüklenmesi çok önemlidir, dolayısıyla gereksiz şeyler yüklememeye çalışın.

İlk etapta korunması gerekmeyen web sitesinizi güvence altına almak için neden acımasızca HTTPS’ye taşıma sürecine girdiniz? Üstelik bunun parasını ödemeniz de gerekiyor.

Buna gerçekten değer mi bakalım.

HTTPS iletilerinizi şifreler ve MITM sorununu çözer

HTTP serisinin önceki bölümünde farklı HTTP kimlik doğrulama mekanizmaları ve güvenlik kusurları hakkında konuştuk. Hem temel hem de Digest kimlik doğrulamasının çözemediği sorun man-in-the-middle (ortadaki adam) saldırısıdır. Ortadaki adam, sizinle iletişim kurduğunuz web sitesi arasına kendisini yerleştiren kötü amaçlı bir programı temsil eder. Amacı orijinal mesajları her iki yönden de çevirmek ve değiştirilen mesajları tekrar iletmek suretiyle kendisini gizlemektir.

İletişimin orijinal katılımcıları, mesajlarının dinlendiğinden haberdar olmayabilir.

HTTPS, iletişimi şifreleyerek MITM saldırı sorununu çözer. Şimdi, bu, trafiğinizin artık dinlenemeyeceği anlamına gelmiyor. Bu, iletilerinizi dinleyen ve kesen herkesin içeriğini göremeyeceği anlamına gelir. Mesajın şifresini çözmek için anahtara ihtiyacı vardır. Bunun nasıl olduğunu tam olarak biraz sonra öğreneceğiz.

Hadi devam edelim.

Sıralama sinyali olarak HTTPS

Yakın zamanda Google, HTTPS’yi bir sıralama sinyali yaptı.

Bu ne anlama geliyor?

Bu, bir web yöneticisiyseniz ve Google sıralamanızı önemsiyorsanız, HTTPS’yi web sitenizde kesinlikle uygulamalısınız. Bazılarının kalite içeriği ve geri dönüş gibi işaretleri kadar güçlü olmasa da, kesinlikle önemlidir.

Bunu yaparak, Google, web yöneticilerine mümkün olan en kısa sürede HTTPS’ye geçme ve internetin genel güvenliğini artırma konusunda teşvik sağlar.

Tamamen ücretsizdir

Bir web sitesi için HTTPS’yi (SSL / TLS) etkinleştirmek için bir Sertifika Otoritesi tarafından verilen bir sertifikaya ihtiyacınız vardır. Yakın geçmişe kadar sertifikalar pahalıydı ve her yıl yenilenirdi.

Let’s Encrypt geliştiricilerine teşekkürler ki sertifikayı ücretsiz alabilmekteyiz. Cidden, onlar tamamen ücretsizdir.

Şifreleme sertifikalarının kolayca yüklenip, büyük bir şirket desteğinin verildiği harika bir topluluktur. Ana sponsorlarına bir göz atın ve onlara destek veren şirketlerin listesine göz atın. Birkaç tanesini tanıyabilirsiniz.

Let’s Encrypt, DV (Domain Doğrulama) ile çalışır. Her sertifikanın ömrü 90 gündür ve otomatik olarak yenilenir.

Her harika teknoloji gibi, kötü tarafı da var. Sertifika artık kolaylıkla bulunabildiğinden, Kimlik Avı web siteleri tarafından istismar ediliyor.

Her Şey Hızla İlgilidir

HTTPS kullanan siteler çok daha hızlı çalışmaktadır. httpvshttps.com‘ye bir göz atın.

Peki orada ne oldu? Neden HTTPS çok daha hızlıdır? Bu nasıl mümkün olabilir?

HTTPS, HTTP 2.0 protokolünü kullanmak için şarttır.

Ağ sekmesine bakarsak, HTTPS durumunda görüntülerin h2 protokolü üzerinden yüklendiğini göreceğiz. Ve akış çok farklı görünüyor.

HTTP 2.0 şu anda yaygın olan HTTP / 1.1’in halefidir.

HTTP / 1.1’e göre pek çok avantajı vardır:

  • Metinsel değil, ikili.
  • Tek bir TCP bağlantısı üzerinden birden fazla isteği paralel olarak gönderebileceği anlamına gelen tam çoğullama
  • HPACK sıkıştırmasını kullanarak yükü azaltır
  • Daha hızlı şifrelenmiş bağlantılar sağlayan yeni ALPN uzantısını kullanır
  • Ek gidiş dönüş sürelerini (RTT) azaltır, böylece web siteniz daha hızlı yüklenir

ve daha bir çoğu.

Şimdilik ikna olmadıysanız, muhtemelen bazı tarayıcıların şifrelenmemiş içeriğe karşı savaş başlattığını bilmelisiniz. Google, Chrome’un güvensiz web sitelerine nasıl davranacağını net bir şekilde açıklayan bir blog yayınladı.

Chrome sürüm 56’dan önce ve sonra nasıl göründüğü aşağıda belirtilmiştir.

Şimdi ise bu şekilde gözükmektedir;

Halen ikna olmadınız mı?

HTTPS’ye Geçmek Karmaşıktır

Bu aynı zamanda geçmiş zamanların kalıntılarıdır. HTTPS’ye geçmek, HTTP üzerinden yüklenen kaynakların yoğunluğu nedeniyle uzun süredir var olan web siteleri için daha zor olabiliyor olsa da, barındırma sağlayıcıları genellikle bu işlemi daha kolay hale getirmeye çalışmaktadır.

Birçok barındırma sağlayıcıları, HTTPS’ye otomatik geçiş sunar. Seçenekler panelinde bir düğmeyi tıklamak kadar kolay olabilir.

Web sitenizi HTTPS üzerinden kurmayı planlıyorsanız, barındırma sağlayıcısının önce HTTPS geçişi sunup sunmadığını kontrol edin. Veya kabuk erişimine sahipse, şifrelemek ve biraz sunucu yapılandırması ile kolayca kendiniz yapabilirsiniz.

Bu nedenle, HTTPS’ye geçmek için sebepler bunlar. Herhangi bir sebep yok mu?

Umarım, şimdiye kadar sizi HTTPS değerinden ikna etmiştimdir.

HTTPS’nin temel kavramları

HTTPS, Köprü Metni Aktarım Protokolü Güvenli (Hypertext Transfer Protocol Secure) anlamına gelir. Etkili bir şekilde istemci ve sunucu HTTP üzerinden ancak güvenli SSL / TLS bağlantısı üzerinden iletişim kurar.

Serinin önceki bölümlerinde, HTTP iletişiminin nasıl çalıştığını öğrendik, ancak SSL / TLS bölümü neydi ve hem SSL hem de TLS’yi neden kullanıyoruz?

Onunla başlayalım.

SSL-TLS

SSL (Güvenli Yuva Katmanı) ve TLS (Aktarım Katmanı Güvenliği) terimleri birbirlerinin yerine kullanılılabilirdi, ancak aslında, bugün birileri SSL sözü ettiğinde muhtemelen TLS demek istiyordur. TLS daha yeni bir teknolojidir.

SSL aslında Netscape tarafından geliştirildi, ancak sürüm 1.0 bugünün ışığını hiç görmedi. Sürüm 2.0 1995’te, 1996’da da 3.0 sürümünde tanıtıldı ve daha sonradan ne kadar uzun süre kullanıldılarsa da, halef TLS zaten yol almaya başlamıştı. Bu durum 2014’e kadar devam etti. TLS’den SSL’ye düşüş, sunucular tarafından desteklendi ve POODLE saldırısının bu kadar başarılı olmasının başlıca nedeni oldu.

Bundan sonra, SSL’ye geçiş tamamen devre dışı bırakıldı.

Sizinkini veya Qualys SSL Labs aracıyla başka bir web sitesini kontrol ederseniz, muhtemelen böyle bir şey göreceksiniz:

Gördüğünüz gibi, SSL 2 ve 3 hiç desteklenmiyor ve TLS 1.3 hala kapalı değil.

Ancak, SSL çok uzun süredir bu kadar yaygın olduğundan, çoğu insanın aşina olduğu ve şimdi hemen hemen her şey için kullanılan bir terim haline geldi. Dolayısıyla, TLS yerine SSL kullanan birisini duyduğunuzda, yalnızca tarihsel nedenlerden ötürü, SSL olduklarından değil.

Şimdi bunu bir kenara bıraktık, artık daha uygun olduğundan TLS’i kullanacağım.

Peki, istemci ve sunucu nasıl güvenli bir bağlantı kuruyor?

TLS El Sıkışması

İstemci ve sunucu arasındaki gerçek şifreli iletişim başlamadan önce, “TLS el sıkışması” adlı işlemi gerçekleştirirler.

Aşağıdaki gibi işler (çok basitleştirilmiştir, ek bilgiler için bağlantılar aşağıdadır).

Bağlantı kurulduktan sonra şifreli iletişim başlar.

Gerçek mekanizma bundan çok daha karmaşıktır, ancak HTTPS’yi uygulamak için el sıkışma uygulamasının tüm gerçek ayrıntılarını bilmeniz gerekmez.

Bilmeniz gereken şey, istemci ile sunucu arasında anahtarlar ve sertifikalar değiştiren ilk bir el sıkışması olmasıdır. Bu el sıkışma sonrasında, şifrelenmiş iletişim başlamaya hazırdır.

Tam olarak nasıl çalıştığını bilmek isterseniz, RFC 2246‘a bakabilirsiniz.

TLS el sıkışma görüntüsünde sertifikalar gönderiliyor, bu nedenle bir sertifikanın neyi temsil ettiğini ve nasıl verildiğini görelim.

Sertifika ve Sertifika Yetkilileri (CA’lar)

Sertifikalar, HTTPS üzerinden güvenli iletişimin çok önemli bir parçasıdır. Bunlar, güvenilir Sertifika Yetkililerinden biri tarafından verilir.

Dijital sertifika, bir web sitesini kullanırken web sitesinin kullanıcılarının güvenli bir şekilde iletişim kurmalarını sağlar.

Örneğin, blogumda gezinirken kullandığınız sertifika şöyle görünür:

Örneğin, Chrome kullanıyorsanız, Sertifikaları kendiniz incelemek için Geliştirici Araçları’ndaki (F12) Güvenlik sekmesine gidin.

İki şeyi işaret etmek istiyorum. İlki kırmızı kutuda, sertifikanın gerçek amacının ne olduğunu görebilirsiniz. Sadece doğru web sitesiyle konuştuğunuzdan emin olabilirsiniz. Birisi, örneğin iletişim kurduğunuzu düşündüğünüz web sitesini kimliğine bürünmüşse, kesinlikle tarayıcınız tarafından bilgilendirilirsiniz.

Meşru bir sertifika ile meşru bir siteye girmişseniz, kimlik bilgileriniz çalınmayacağı anlamına gelmez. Yani dikkatli olmalısınız. Sol üstteki Yeşil “Güvenli”, doğru web sitesi ile iletişim kurduğunuz anlamına gelir. Bu web sitesinin sahibinin dürüstlüğü konusunda hiçbir şey söylemez.

Genişletilmiş doğrulama sertifikaları, tüzel kişinin web sitesini denetlediğini kanıtlamaktadır. EV (Extended Validation) sertifikaların, internetin tipik kullanıcısı için faydalı olup olmadığı konusunda devam etmekte olan bir tartışma var. Bunları, URL çubuğunuzun sol tarafındaki özel metin ile tanıyabilirsiniz. Örneğin, twitter.com’a göz attığınızda şunları görebilirsiniz:

Bu, şirketlerinin web sitelerinin arkasındaki olduğunu kanıtlamak için EV (Extended Validation) sertifikası kullandıkları anlamına geliyor.

Sertifika zincirleri

Öyleyse neden tarayıcınız sunucunun geri gönderdiği sertifikaya güvenmeli? Herhangi bir sunucu bir parça dijital dokümantasyon gönderebilir ve bunun ne olmasını istediğinizi iddia edebilir.

Burada kök sertifikalar gelir. Genellikle sertifikalar zincirlenir ve kök sertifika makinenizin örtük olarak güvendiği belgedir.

Code-maze.com için şu şekildedir:

En düşük olan alan sertifika, üstündeki sertifika tarafından imzalanmış ve benzeri … Kök sertifikaya ulaşılıncaya kadar.

Ama kök sertifikayı kim imzalar?

Şey, kendisi imzalar.

Yayınlanan: AddTrust External CA Root, Yayınlayan: AddTrust External CA Root.

Makineniz ve tarayıcılarınız, göz attığınız alanın güvenilir olduğuna güvenmek için güvenilen kök sertifikaların bir listesine sahiptir. Sertifika zinciri herhangi bir nedenden dolayı kırılmışsa, siteniz bazı makinelerde güvensiz olarak görüntülenir.

Windows’ta güvenilen kök sertifikaların listesini kontrol etmek için windows ® düğmesini + R tuşlarına basarak ve certmgr.msc yazarak sertifika yöneticisini çalıştırın. Daha sonra güvenilen sertifikaları Güvenilen Kök Sertifika Yetkilileri bölümünde bulabilirsiniz. Bu liste Windows, IE ve Chrome tarafından kullanılır. Öte yandan Firefox, kendi listesini yönetiyor.

Sertifika değişimi yaparak, istemci ve sunucu, doğru tarafla konuştıklarını bildiklerini ve şifreli mesaj aktarmaya başlamasını isteyebilir.

HTTPS’in Zayıf Yönleri

HTTPS, site arkasında düzgün bir şekilde uygulanmadığında yanlış bir güvenlik hissi sağlayabilir. Müşteri bilgilerini ayıklamak için birçok farklı yol var ve birçok site HTTPS kullanıyor olsa bile veri sızdırıyor olabilir. Web sitesinden hassas bilgi almak için MITM dışında birçok başka mekanizma bulunmaktadır.

Web sitelerinin HTTPS üzerinden çalışmasına rağmen HTTP bağlantılarına sahip olabilmesi bir başka potansiyel sorunu. Bu MITM saldırısı için bir şans olabilir. Web sitelerini HTTPS’ye taşırken bu fark edilmeyebilir.

Ve bir de bonus olarak bir tane daha var: Güvensiz bir sayfadan erişilen oturum açma formları, güvenli bir sayfaya yüklenmiş olsalar bile potansiyel olarak tehlikeye girebilirler. Bu nedenle, bir websiteyi önlemek için tüm web sitesini güvende tutmak en iyisidir.

Referanslar;

Orijinali: https://www.code-maze.com/http-series-part-5/

HTTP Dersleri – Ders 4 – İstemci Doğrulama Mekanizmaları

/0 Comments/in /by

HTTP Dersleri – Ders 1 – Temel kavramlara genel bakış
HTTP Dersleri – Ders 2 – Mimari Yönleri
HTTP Dersleri – Ders 3 – İstemci Kimliği
HTTP Dersleri – Ders 4 – İstemci Doğrulama Mekanizmaları
HTTP Dersleri – Ders 5 – Güvenlik
HTTP Dersleri – Sözlük

Önceki bölümde, web sitelerinin ziyaret eden kullanıcıyı tanımlamak için kullanabilecek farklı yollardan bahsettik.

Fakat tanımlama sadece bir iddiayı temsil eder. Kendinizi tanımlarken, birisi olduğunuzu iddia ediyorsunuz. Fakat bunun kanıtı yok.

Kişisel id’nizi göstermek veya şifrenizi girmek gibi kimlik doğrulama ile iddia ettiğiniz kişi olduğunuza dair bir kanıt gösteriyorsunuz.

Çoğu zaman, web sitelerini hassas kaynaklarını sunmak için bu kanıta ihtiyacı vardır.

HTTP, sunucuların zorluklar çıkarmalarına ve ihtiyaç duydukları kanıtları elde etmelerine olanak tanıyan kendi kimlik doğrulama mekanizmalarına sahiptir. Ne olduklarını ve nasıl çalıştıklarını öğreneceksiniz. Ayrıca, her birinin artılarını ve eksilerini de ele alacağız ve kendi başlarına kullanılabilecek kadar iyi olup olmadığını keşfedeceğiz (spoyler: iyi değiller).

Bu makalede, aşağıdaki konular hakkında bilgi edineceksiniz:

  • HTTP kimlik doğrulaması nasıl çalışır?
  • Temel kimlik doğrulama
  • Özet kimlik doğrulaması

HTTP kimlik doğrulama mekanizmalarına derinlemesine girmeden önce, HTTP kimlik doğrulamasının ne olduğundan bahsedelim.

HTTP kimlik doğrulaması nasıl çalışır?

Kimlik doğrulama, kendinizi Web sunucusuna tanıtmanın bir yoludur. İstenen kaynaklara erişme hakkına sahip olduğunuzu gösteren bir kanıt göstermeniz gerekiyor. Genellikle, sunucu tarafından doğrulanan ve sonra kaynağa erişip erişemeyeceğinize karar veren kullanıcı adı ve parola (anahtar ve gizli) kombinasyonunu kullanarak yapılır.

HTTP, iki kimlik doğrulama protokolü sunar:

  • Temel kimlik doğrulama
  • Özet kimlik doğrulaması

Her biri hakkında daha fazla bilgi edinmeden önce, bazı temel kavramları inceleyelim.

1. HTTP, bir zorlama / yanıt kimlik doğrulama çerçevesi kullanır

Ne anlama geliyor?

Birisi bir istek gönderdiğinde, ona hemen yanıt vermek yerine, sunucu kimlik doğrulama talebi gönderir. Gizli bilgileri (kullanıcı adı ve parola) girerek kimliğini kanıtlamak için kullanıcıyı zorlar.

Bundan sonra, verilen kimlik bilgileri kullanılarak istek tekrar edilir ve doğruysa, kullanıcı beklenen yanıtı alır. Kimlik bilgilerinin yanlış olması durumunda, sunucu zorluğu tekrar gönderir veya yalnızca hata iletisini gönderir.

2. Kimlik doğrulama ile ilgili istek / yanıt başlıkları

Sunucu, WWW-Authenticate yanıt başlığını kullanarak sorunu çözer. Kimlik doğrulama protokolü ve güvenlik bölgesi ile ilgili bilgileri içerir.

İstemci kimlik bilgilerini girdikten sonra istek tekrar gönderilir. Bu sefer kimlik doğrulama algoritması ve kullanıcı adı / şifre kombinasyonu içeren Yetkilendirme başlığı ile.

Kimlik bilgileri doğruysa, sunucu isteğe bağlı bir Kimlik Doğrulama-Bilgisi yanıt başlığında yanıt ve ek bilgi verir.

3. Güvenlik alanları

Güvenlik alanları, farklı erişim kaynaklarını sunucu üzerindeki farklı kaynak gruplarıyla ilişkilendirmenin yolunu sağlar. Bunlara koruma alanları denir.

Bunun etkili olduğu, erişmek istediğiniz kaynağa bağlı olarak farklı kimlik bilgileri girmeniz gerekebilir.

Sunucu, birden çok alandan oluşabilir. Örneğin, yalnızca web sitesi yöneticilerinin erişebileceği web sitesi istatistik bilgileri ve diğer kullanıcıların resimlere erişebilecekleri ve indirebilecekleri web sitesi görüntüleri için bir tane olması gerekir.

/admin/statistics/financials.txt -> Alan = “Yönetici İstatistikleri”

/images/img1.jpg -> Alan = “Resimler”

Financials.txt dosyasına erişmeye çalıştığınızda, sunucu tarafından itiraz edileceksiniz ve yanıt aşağıdaki gibi görünecektir:

HTTP/1.0 401 Unauthorized
WWW-Authenticate: Basic realm="Admin Statistics"

Güvenlik alanlarıyla ilgili daha fazla bilgi: https://tools.ietf.org/html/rfc7235#section-2.2

Basit HTTP kimlik doğrulama örneği

Şimdi noktaları, en basit HTTP kimlik doğrulama örneğine (Temel kimlik doğrulama, aşağıda açıklanmıştır) bakarak bağlayalım:

1. User Agent -> Sunucu

Kullanıcı, sunucudaki bazı resimlere erişim isteğinde bulunur.

GET /gallery/personal/images/image1.jpg HTTP/1.1
Host: www.somedomain.com

2. Sunucu -> User Agent

Sunucu, kimlik doğrulama sorununu kullanıcıya gönderir.

HTTP/1.1 401 Access Denied
WWW-Authenticate: Basic realm="gallery"

3. User Agent -> Sunucu

Kullanıcı kendisini form girişi yoluyla tanımlar.

GET /gallery/personal/images/image1.jpg HTTP/1.1
Authorization: Basic Zm9vOmJhcg==

4. Sunucu -> User Agent

Sunucu, kimlik bilgilerini denetler ve 200 OK durum kodunu ve resim verisini gönderir.

HTTP/1.1 200 OK
Content-type: image/jpeg
...<image data>

O kadar da karışık değil, değil mi?

Şimdi aşağıya detaylı inceleme yapalım ve temel kimlik doğrulamaya bakalım.

Temel kimlik doğrulama

En yaygın ve desteklenen kimlik doğrulama protokolüdür. HTTP / 1.0’dan beri var olmuştur ve her büyük istemci onu uygular.

Yukarıdaki örnek, Temel kimlik doğrulamasını kullanarak kimlik doğrulamasının nasıl yapılacağını göstermektedir. Uygulamak ve kullanmak oldukça basit, ancak bazı güvenlik kusurları var.

Güvenlik sorunlarına başlamadan önce, Temel kimlik doğrulamasının kullanıcı adı ve şifre ile nasıl ilgilendiğini görelim.

Temel kimlik doğrulama, kullanıcı adını ve parolasını bir dizede paketler ve bunları iki nokta üst üste (:) kullanarak ayırır. Bundan sonra, bunları Base64 kodlaması kullanarak kodlar. Karmaşık gözükmesine rağmen, karıştırılmış karakter dizisi güvenli değildir ve kolayca çözülür. Base64 kodlamanın amacı şifrelemek değil, HTTP başlıklarında uluslararası karakterlere izin verilmemesi nedeniyle kullanıcı adı ve parolasını uyumlu hale getirmektir.

GET /gallery/personal/images/image1.jpg HTTP/1.1
Authorization: Basic Zm9vOmJhcg==

Bu örnekten “Zm9vOmJhcg ==”, Base64 tarafından kodlanmış “foo: bar” dizesinden başka bir şey değildir.

Bu nedenle, istekleri dinleyen herkes kolayca kimlik bilgilerini çözebilir ve kullanabilir.

Bundan daha da kötüsü, kullanıcı adı ve şifreyi kodlamak yardımcı olmayacaktır. Kötü niyetli bir üçüncü taraf, aynı etkiyi elde etmek için şifreli diziyi yine de gönderebilir.

Ayrıca, istek gövdesini değiştiren ve istek başlıklarını sağlam bırakan proxy’lere veya başka herhangi bir saldırıya karşı koruma yoktur.

Gördüğünüz gibi, Temel kimlik doğrulama mükemmel bir yöntem değildir.

Yine de buna rağmen, korunan kaynaklara kazayla erişilmesini önlemek ve bir miktar kişiselleştirme teklif etmek için kullanılabilir.

Daha güvenli ve kullanışlı hale getirmek için, temel kimlik doğrulama, serinin 5. bölümünde bahsettiğimiz SSL üzerinden HTTPS kullanılarak gerçekleştirilebilir.

Bazıları, sisteminizin güvenliği, transfer mekanizmanızın güvenliği kadardır der.

Digest kimlik doğrulaması

Digest kimlik doğrulaması, basit ama güvensiz Temel kimlik doğrulamaya daha güvenli ve güvenilir bir alternatif olarak yapıldı.

Peki, nasıl işliyor?

Digest kimlik doğrulama, şifre bilgilerini gizlemek ve farklı türlerde kötü amaçlı saldırıları önlemek için nonces kullanımı ile birlikte MD5 şifreleme karma yöntemini kullanır.

Bu biraz karışık gelebilir, ancak basit bir örnekte nasıl çalıştığını gördüğünüzde daha net görülecektir.

1. User Agent -> Server

GET /dir/index.html HTTP/1.0
Host: localhost

İstemci, kimliği doğrulanmamış bir istek gönderir.

2. Server -> User Agent

HTTP/1.0 401 Unauthorized
WWW-Authenticate: Digest realm="shire@middleearth.com",
                        qop="auth,auth-int",
                        nonce="cmFuZG9tbHlnZW5lcmF0ZWRub25jZQ",
                        opaque="c29tZXJhbmRvbW9wYXF1ZXN0cmluZw"
Content-Type: text/html
Content-Length: 153
 
<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" />
    <title>Error</title>
  </head>
  <body>
    <h1>401 Unauthorized.</h1>
  </body>
</html>

Sunucu, Digest kimlik doğrulamasını kullanarak istemciyi kimlik doğrulaması yapmaya zorlar ve gerekli bilgileri istemciye gönderir.

3. User Agent -> Server

GET /dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username="Gandalf",
                     realm="shire@middleearth.com",
                     nonce="cmFuZG9tbHlnZW5lcmF0ZWRub25jZQ",
                     uri="/dir/index.html",
                     qop=auth,
                     nc=00000001,
                     cnonce="0a4f113b",
                     response="5a1c3bb349cf6986abf985257d968d86",
                     opaque="c29tZXJhbmRvbW9wYXF1ZXN0cmluZw"

İstemci, yanıt değerini hesaplar ve kullanıcı adı, bölge, URI, nonce, opque, qop, nc ve cnonce ile birlikte gönderir. Bir sürü şey.

Bunları tanımlayalım:

  • nonce ve opaque – istemci tarafından alındığı şekilde döndürülmesi gereken sunucu tarafından tanımlanan dizeler
  • qop (koruma kalitesi) – önceden tanımlanmış değerlerden bir veya daha fazlası (“auth” | “auth-int” | belirteci). Bu değerler özet hesaplamasını etkiler.
  • cnonce – client nonce, qop ayarlanmışsa üretilmelidir. Seçilen düz metin saldırılarından kaçınmak ve ileti bütünlüğünü koruma sağlamak için kullanılır.
  • nc – Qcp ayarlanırsa, nonce sayısı gönderilmelidir. Bu yönergenin amacı, sunucunun, bu sayının kendi kopyasını koruyarak istek tekrarlarını algılamasını sağlamaktır – aynı nc değeri iki kez görüldüyse, istek yeniden yürütülür.

Yanıt özniteliği aşağıdaki şekilde hesaplanır:

HA1 = MD5("Gandalf:shire@middleearth.com:Lord Of The Rings")
       = 681028410e804a5b60f69e894701d4b4
 
HA2 = MD5("GET:/dir/index.html")
       = 39aff3a2bab6126f332b942af96d3366
 
Response = MD5( "681028410e804a5b60f69e894701d4b4:
                 cmFuZG9tbHlnZW5lcmF0ZWRub25jZQ:
                 00000001:0a4f113b:auth:
                 39aff3a2bab6126f332b942af96d3366" )
         = 5a1c3bb349cf6986abf985257d968d86

Qop’a bağlı olarak cevabı nasıl hesaplayacağınızı merak ediyorsanız, RFC 2617‘de bulabilirsiniz.

4. Server -> User Agent

HTTP/1.0 200 OK
Content-Type: text/html
Content-Length: 2345
... <content data>

Sunucu, karmayı tek başına hesaplar ve ikisini karşılaştırır. Eşleşirlerse, istenen verilerle istemciye hizmet eder.

Gördüğünüz gibi, Digest kimlik doğrulamasının anlaşılması ve uygulanması daha karmaşıktır.

Ayrıca, Temel kimlik doğrulamadan daha güvenlidir; ancak, man-in-the-middle saldırısına karşı halen savunmasızdır. RFC 2617, bazı zayıf yönlerini giderdiği için Temel kimlik doğrulama yerine Digest kimlik doğrulamasının kullanılmasını önerir. Ayrıca, Digest kimlik doğrulamasının modern şifreleme standartlarına göre halen zayıf olduğunu ve gücünün büyük oranda uygulanmasına bağlı olduğunu gizlemez.

Yani Digest kimlik doğrulamasının özeti:

  • Ağ üzerinden düz metin parolalar göndermez
  • Tekrar çalma saldırılarını önler
  • Mesaj müdahalesine karşı korucular

Bazı zayıf yönler:

  • Man-in-the-middle saldırı için güvenlik açığı
  • Güvenlik seçeneklerinin birçoğu gerekli değildir ve böylece ayarlanmazsa Digest kimlik doğrulama işlevi daha az güvenli bir şekilde yapılır
  • Şifreleri saklarken güçlü şifre karma algoritmalarının kullanılmasını engeller

Bu gerçekler nedeniyle, Digest kimlik doğrulama hala büyük bir itici güç kazanamadı. Temel kimlik doğrulaması çok basit ve Digest kimlik doğrulamasından daha güvenli SSL ile birleştirildi.

Sonuç

Bu sonuç, HTTP serisinin bu kısmı içindir.

HTTP’nin varsayılan olarak sunduğu farklı kimlik doğrulama mekanizmalarına geçtik ve avantajları ve dezavantajları hakkında konuştuk.

Bu kavramlar sizin için artık ekrandaki harflerden ibaret değildir umarım, bir sonraki seferinde ne olduklarını ve ne zaman uygulayacaklarını bilirsiniz.

Bu mekanizmalarla çözülmeyen güvenlik risklerinin bulunduğunun farkındasınız ve bu yüzden HTTPS ve SSL / TLS gibi kavramlar var. Güvenlik riskleri ve bunları serimizin bir sonraki bölümünde nasıl çözeceğimiz hakkında daha fazla konuşuruz.

Bu bölümdeki kavramlardan bazılarını belirsiz buluyorsanız, HTTP serisinin 1. bölümü 2. bölümüne ve 3. bölümüne bakın.

Sonraki Ders: HTTP Dersleri – Ders 5 – Güvenlik

Referanslar;

Orijinal Yazı: https://www.code-maze.com/http-series-part-4/