Web güvenliğinin günümüzde dahi yeterli ciddiyetle ele alınmadığı izlenimi içerisindeyim. Söz konusu durum malesef sadece kişisel sayfalar için değil aynı zamanda büyük kurum ve kuruluşlar için de böyle. Gerek konunun ciddiyet ve önemini vurgulamak gerekse de hızlı bir başlangıç yapmanın faydalı olacağını düşündüm.
Web güvenliği hakkında bilgi edinmek için birçok nedeniniz var:
- kişisel verilerinizin sızdırılmasından endişe duymak
- web uygulamalarınızı daha güvenli hale getirmek
- iş mülakatlarında web güvenliği hakkındaki sorulara hazır olmak vb.
Bu paylaşım, bazı yaygın web güvenliği terminolojilerinin doğru ve anlaşılması kolay bir şekilde açıklanmasını hedeflemektedir.
Fakat ilk olarak birkaç konsept üzerinde duralım:
İki Temel Güvenlik Kavramı:
Hiç kimse % 100 güvende değildir!
Saldırılara karşı % 100 koruma diye birşey yoktur. Biri size bunu söylüyorsa, yanılıyordur.
Tek bir koruma katmanı yeterli değildir!
Güvenlik bu kadar basit bir konsept değildir.
Cross-Origin Resource Sharing (CORS)
Hiç böyle görünen bir hata aldınız mı?
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.
CORS’nin size nasıl yardımcı olduğunu açıklamak için önce cookie / çerez ‘ler, özellikle de kimlik doğrulama çerezleri hakkında konuşalım. Kimlik doğrulama çerezleri, bir sunucuya oturum açtığınızı söylemek için kullanılır ve o sunucuya yaptığınız herhangi bir istekle birlikte otomatik olarak gönderilir.
Diyelim ki Facebook’ta oturum açtınız ve kimlik doğrulama çerezleri kullanılıyor. Sizi pissoyguncu.com’a yönlendiren bit.ly/r43nugi’ye (URL adı kısaltma servisi) tıkladınız. Pissoyguncu.com içindeki bir script / betik, facebook.com’a kimlik doğrulama tanımlama bilginizi gönderen istemci taraflı bir istekte bulunur!
CORS’un olmadığı bir senaryoda, siz bilmeden hesabınızda değişiklikler yapabilirler. Tabi ki, paylaşımlarınızda bit.ly/r43nugi yayınlayana ve tüm arkadaşlarınız onu tıklayana ve ardından tüm arkadaşlarınızın da paylaşımlarına bit.ly/r43nugi gönderene ve döngü kötü bir genişlikte devam edene kadar. Hikayenin sonunda Facebook’un tüm kullanıcıları pissoyguncu.com tarafından işkal ediliyor. (:
CORS’un kullanıldığı senaryoda, Facebook, yalnızca facebook.com kaynaklı isteklerin sunucularındaki verileri düzenlemesine izin verir. Başka bir deyişle, kaynaklar arası kaynak paylaşımını sınırlarlar. Şöyle düşünüyor olabilirsiniz…
Peki pissoyguncu.com, istemlerde bulunan header / başlığı facebook.com’dan geliyormuş gibi görünecek şekilde değiştirebilir mi?
Denenebilir, ancak işe yaramaz çünkü tarayıcı bunu görmezden gelir ve gerçek kaynağı kullanır.
Tamam, peki ya pissoyguncu.com, isteği sunucu tarafında yaparsa?
Bu durumda, CORS’u atlatabilirler, ancak kimlik doğrulama çerezinizi gönderemeyecekleri için bir anlam ifade etmeyecektir. İstemci tarafındaki çerezlerinize erişmek için komut dosyasının istemci tarafında yürütülmesi gerekir.
Content Security Policy (CSP)
CSP’yi anlamak için öncelikle web’deki en yaygın güvenlik açıklarından biri hakkında konuşmamız gerekiyor: siteler arası betik dosyası oluşturulması (cross-site scripting) anlamına gelen XSS.
XSS, kötü amaçlı kullanıcının istemci taraflı kodunuza JavaScript enjekte etmesidir.
Ne yapacaklar? Fon rengini kırmızıdan maviye mi değiştirmek isteyecekler?
Birinin, ziyaret ettiğiniz bir web sitesinin istemci taraflı koduna başarıyla JavaScript enjekte ettiğini varsayalım.
Kötü niyetli olacak ne yapabilirler?
- Sizmiş gibi davranarak başka bir siteye HTTP isteklerinde bulunabilirler.
- Bir bağlantı etiketi ekleyerek, sizi bulunduğunuzla aynı görünen fakat kötü niyetli özelliklere sahip bir web sitesine gönderebilirler.
- Satır içi JavaScript ile bir betik etiketi ekleyebilirler.
- Bir betik etiketi ekleyerek JavaScript dosyasının uzaktan çağırılmasını sağlayabilirler.
- Sayfayı kaplayan, web sitesinin bir parçası gibi görünen ve şifrenizi girmenizi isteyen bir iç çerçeve ekleyebilirler.
İmkanlar sadece bunlarla sınırlı değil.
CSP, aşağıdakileri sınırlayarak bunun olmasını önlemeye çalışır:
- iframe’de neler açılabilir
- hangi stylesheet’ler yüklenebilir
- istekler nerede yapılabilir vb.
Peki CSP nasıl çalışıyor?
Bir bağlantıya tıkladığınızda veya tarayıcınızın adres çubuğuna bir web sitesi URL’si yazdığınızda, tarayıcınız bir GET isteğinde bulunur. Sonunda, bazı HTTP başlıklarıyla birlikte HTML sunan bir sunucuya doğru yol alır. Hangi başlıkları aldığınızı merak ediyorsanız, konsolunuzdaki Ağ sekmesini açın ve bazı web sitelerini ziyaret edin.
content-security-policy: default-src * data: blob:; script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self'; style-src data: blob: 'unsafe-inline' *; connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;
Şimdi direktifleri inceleyelim.
- default-src: açıkça listelenmeyen diğer tüm CSP direktiflerini kısıtlar.
- script-src: yüklenebilecek betikleri kısıtlar.
- style-src: yüklenecek stylesheet’leri kısıtlar.
- connect-src: komut dosyası arabirimleri kullanılarak yüklenebilecek URL’leri kısıtlar (fetch, XHR, ajax vb.)
Yukarıda gösterilen bu dördünden çok daha fazla CSP yönergesi olduğunu unutmayın. Tarayıcı, CSP başlığını okuyacak ve bu yönergeleri sunulan HTML dosyasındaki her şeye uygulayacaktır. Direktifler uygun şekilde ayarlanmışsa, yalnızca gerekli olana izin verilir.
CSP başlığı yoksa hiçbir şey kısıtlanmaz.
HTTPS ya da HTTP Secure
HTTPS özünde oldukça basittir. HTTPS şifrelenir, HTTP şifrelenmez.
Öyleyse, hassas veriler göndermiyorsanız bu neden önemli?
MITM (Man in the Middle): Ortadaki Adam
Bir kafede şifresiz halka açık bir Wi-Fi kullanıyorsanız, birisinin router / modem gibi davranması oldukça kolaydır. Böylece tüm istek ve yanıtlar onların üzerinden geçer. Verileriniz şifrelenmemişse, onunla istediklerini yapabilirler. Tarayıcınıza ulaşmadan önce HTML, CSS veya JavaScript’i düzenleyebilirler. XSS hakkında bildiklerimiz göz önüne alındığında, bunun ne kadar kötü olabileceğini tahmin edebilirsiniz.
Tamam, ama bilgisayarım ve sunucu nasıl şifreleyeceğini / şifresini çözeceğini biliyor ama bu MITM bilmiyor?
İşte tam bu noktada SSL (Secure Socket Layer – Güvenli Soket Katmanı) ve daha yakın zamanda TLS (Transport Layer Security – Taşıma Katmanı Güvenliği) devreye girmiştir. TLS, HTTPS içinde kullanılan şifreleme teknolojisi olarak 1999’da SSL’yi devralmıştır. TLS’nin tam olarak nasıl çalıştığı bu yazının kapsamı dışındadır.
HTTP Strict-Transport-Security (HSTS)
Tekrar örnek olarak Facebook’un başlığını / header kullanalım:
strict-transport-security: max-age=15552000; preload
- max-age: bir tarayıcının bir kullanıcıyı HTTPS kullanarak bir web sitesine erişiyor olduğunu ne kadar süreyle hatırlaması gerektiğini belirtir.
- preload: Google tarafından barındırılan bir hizmettir ve HSTS spesifikasyonunun bir parçası değildir.
Bu başlık yalnızca siteye HTTPS kullanarak eriştiğinizde geçerlidir. Siteye HTTP aracılığıyla eriştiyseniz, yok sayılır. Nedeni ise HTTP’nin güvensiz olmasıdır.
Aynı örnek ile devam edelim. Facebook.com’a ilk kez erişiyorsunuz ve HTTPS’in HTTP’den daha güvenli olduğunu biliyorsunuz, bu nedenle https://facebook.com üzerinden erişiyorsunuz. Tarayıcınıza HTML’i yazdığınızda, gelecekteki istekler için HTTPS kullanmasını söyleyen yukarıdaki başlığı alır. Bir ay sonra birisinin size http://facebook.com kullanarak bir Facebook bağlantısı gönderdiğini ve sizin ona tıkladığınızı varsayalım. Bir ay max-age yönergesinde belirtilen 15552000 saniyeden daha az olduğu için tarayıcınız isteği HTTPS olarak göndererek olası bir MITM saldırısını önleyecektir.
Sonuç
Web geliştirme yolculuğunuzun neresinde olursanız olun web güvenliği önemlidir. Güvenlik, sadece iş unvanlarında açıkça belirtilen kişiler için değil, herkes için önemli olması gereken bir konudur.
Mehmet Türker
Technical Account Manager & Cyber Security Engineer
Endpoint Bilgi Teknolojileri Güvenliği ArGe A.Ş – 2022
LinkedIn