Cross Site Scripting (XSS)

Cross Site Scripting(XSS), Siteler Arası Komut Dosyası Çalıştırma saldırısıdır. Kötü niyetli komut dosyalarının, başka türlü iyi huylu ve güvenilir web sitelerine enjekte edildiği bir tür sızma saldırısıdır. Bu saldırı şeklindeki saldırgan, genellikle bir tarayıcı tarafı komut dosyası biçiminde kötü amaçlı bir kodu, farklı bir son kullanıcıya göndermek için bir web uygulaması kullanarak çalıştırır. Bu saldırıların başarılı olmasına izin veren kusurlar oldukça yaygındır ve bir web uygulamasının, kullanıcıların veri girişi yaptığı her yerde, girilen verinin doğrulamadan veya encode edilmeden post edilmeye çalışıldığı , sunucu tarafına gönderilmeye çalışıldığı yerlerde meydana gelir.

OWASP(Open Web Application Security Project), yazılımın güvenliğini artırmak için çalışan, kar amacı gütmeyen ve tüm dünyada kabul gören bir vakıftır. OWASP’ a göre üç tür XSS bulunmaktadır. Önceleri, Stored XSS ve Reflected XSS olmak üzere iki ana XSS türü tanımlanmış, sonrasında, 2005 yılında Amit Klein tarafından DOM Based XSS tanımlanmıştır. 

Stored XSS genellikle, kullanıcı girdisi bir veritabanında, bir mesaj forumunda, ziyaretçi günlüğünde, yorum alanında vb. gibi hedef sunucuda depolandığında oluşur. Ve daha sonra bir kurban, depolanan verileri web uygulamasından o olmadan alabilir. HTML5 ve diğer tarayıcı teknolojilerinin ortaya çıkmasıyla, saldırı yükünün mağdurun tarayıcısında (örneğin bir HTML5 veritabanı gibi) kalıcı olarak saklandığını ve hiçbir zaman sunucuya gönderilmediğini düşünebiliriz.

Reflected XSS, bir web uygulaması tarafından bir hata mesajı, arama sonucu veya isteğin bir parçası olarak kullanıcı tarafından sağlanan girdilerin bir kısmını veya tamamını içeren verilerin  güvenli hale getirilmeden tarayıcıda işlenip, kullanıcı tarafından sağlanan verileri kalıcı olarak depolamaksızın başka bir yanıtta kullanıcı girdisi anında döndürüldüğünde ortaya çıkar.  Bazı durumlarda, kullanıcı tarafından sağlanan veriler tarayıcıdan asla ayrılmayabilir.

DOM Based XSS, ile ilgili ilk makaleyi(“DOM Based Cross Site Scripting or XSS of the Third Kind” (WASC writeup), Amit Klein, July 2005) yayınlayan Amit Klein tarafından tanımlandığı üzere, DOM Tabanlı XSS, kaynaktan havuza tüm bozuk veri akışının tarayıcıda gerçekleştiği, yani verilerin kaynağı DOM'da ki havuz da, DOM'dadır ve veri akışı tarayıcıdan asla ayrılmaz. Örneğin, kaynak (kötü amaçlı verilerin okunduğu yer) sayfanın URL 'i (ör. Document.location.href) veya HTML'nin bir öğesi olabilir ve kötü amaçlı verilerin yürütülmesine neden olan hassas bir yöntem çağrısı olabilir (ör., document.write).

2012 yılına kadar XSS türleri bu şekilde üç tür olarak kabul görmüş. Ancak 2012 yılı ortalarında araştırma topluluğu bu türlerin bir biri ile örtüşen tarafları olduğunu ve Server XSS(Stored Server XSS, Reflected Server XSS) ve Client XSS(Stored Client XSS, Reflected Client XSS) olarak iki türde gruplayarak duyurmuş ve bu türler kabul görmüştür.

Server XSS, kullanıcı tarafından sağlanan güvenilmeyen veriler sunucu tarafından oluşturulan bir HTTP yanıtına dahil edildiğinde oluşur. Bu verilerin kaynağı talepten veya saklanan bir konumdan olabilir. Bu nedenle, hem Reflected Server XSS'e hem de Stored Server XSS'e sahip olunabilir. Bu durumda, güvenlik açığının tamamı sunucu tarafındaki koddadır ve tarayıcı yalnızca yanıtı işliyor ve içine gömülü herhangi bir geçerli komut dosyasını çalıştırıyor demektir.

Client XSS, kullanıcı tarafından sağlanan güvenilir olmayan veriler DOM 'u güvenli olmayan bir JavaScript çağrısıyla güncellemek için kullanıldığında oluşur. Bir JavaScript çağrısı, DOM'a geçerli JavaScript eklemek için kullanılabiliyorsa, güvenli değildir. Bu verinin bu kaynağı DOM'dan olabilir veya sunucu tarafından gönderilmiş olabilir (bir AJAX çağrısı veya bir sayfa yükleme yoluyla). Verilerin nihai kaynağı, bir request ten, Client da veya Server da depolanan bir konumdan olabilir. Bu nedenle, hem Reflected Client XSS'e hem de Stored Client XSS'e sahip olunabilir.

Bu yeni tanımlarla, DOM Tabanlı XSS 'in tanımı değişmez. DOM Tabanlı XSS, basitçe Client XSS 'in bir alt kümesidir; burada veri kaynağı Server dan ziyade DOM'da bir yerdedir.

Hem Server XSS hem de Client XSS 'in depolanabileceği veya yansıtılabileceği göz önüne alındığında, bu yeni terminoloji, Dave Wichers ’ın DOM Tabanlı XSS ​​konuşmasında gösterildiği gibi, bir eksende Client & Server XSS ve diğer eksende Stored and Reflected XSS ile basit, temiz, 2 x 2 matris ile ifade edilmiştir;

Önerilen Server XSS ten korunma yöntemleri;

Server XSS, bir HTML yanıtına güvenilmeyen verilerin eklenmesinden kaynaklanır. Çoğu durumda Server XSS 'e karşı en kolay ve en güçlü savunma şudur:

• Context-sensitive server side output encoding(Bağlama duyarlı sunucu tarafı çıktı kodlaması)

Bağlama duyarlı sunucu tarafı çıktı kodlamasının nasıl uygulanacağına ilişkin ayrıntılar, OWASP XSS (Siteler Arası Komut Dosyası) Önleme Hile Sayfasında (https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html) ayrıntılı olarak sunulmuştur. Sunucu XSS'i önlemeye yardımcı olmak için girdi doğrulama veya veri sterilizasyonu gerçekleştirilebilir, ancak doğrulama işlemi bağlama duyarlı çıktı kodlamasından çok daha zordur.

Önerilen Client XSS Savunmaları;

Client XSS, DOM'u güvenli olmayan bir JavaScript çağrısıyla güncellemek için güvenilmeyen verilerin kullanılması durumunda ortaya çıkar. Client XSS'ye karşı en kolay ve en güçlü savunma şudur:

• Güvenli JavaScript API'leri kullanmak

Bununla birlikte, geliştiriciler genellikle hangi JavaScript API'lerinin güvenli olup olmadığını bilmezler, en sevdikleri JavaScript kitaplığındaki hangi yöntemlerin güvenli olduğunu umursamazlar. Hangi JavaScript ve jQuery yöntemlerinin güvenli ve güvensiz olduğuna dair bazı bilgiler, Dave Wichers'ın 2012 XSS 'de OWASP AppSec ABD'de sunulan DOM Tabanlı XSS ​​konuşmasında sunulmuştur(“Unraveling some of the Mysteries around DOM Based XSS” (OWASP AppSec USA), Dave Wichers, 2012). Bir JavaScript yönteminin güvenli olmadığını biliyorsanız, birincil öneri; kullanmak için alternatif bir güvenli yöntem bulmaktır. Herhangi bir nedenle yapamazsanız, bu verileri güvenli olmayan JavaScript yöntemine geçirmeden önce tarayıcıda bağlama duyarlı çıktı kodlaması yapılabilir. OWASP 'ın bunun nasıl doğru bir şekilde yapılacağına dair rehberliği ise ; DOM Based XSS​​Önleme Hile Sayfasında(https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html) sunulmuştur . Bu kılavuzun, verilerin gerçekte nereden geldiğine bakılmaksızın (DOM veya Sunucu) tüm İstemci XSS türleri için geçerli olduğunu unutmamak gerekir.

Bunların yanı sıra genel perspektifte bakacak olursak, tüm web sunucularında HTTP TRACE desteğini kapatmak da fayda sağlayacaktır.

Kaynaklar:

·         https://owasp.org/

·         https://owasp.org/www-community/attacks/xss/#

·         https://owasp.org/www-community/Types_of_Cross-Site_Scripting

·         http://www.webappsec.org/projects/articles/071105.shtml

·         https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

 

TASARIM DESENLERİ (Design Patterns)

Yazılım tasarım desenleri; yaygın olarak ortaya çıkan yazılımsal sorunların çözümü için test edilmiş, kanıtlanmış, tüm yazılım geliştiricileri tarafından kabul görmüş genel yazılımsal çözümlerdir. Yazılımda tasarım desenlerini, ilk kez resmi olarak 1995 yılında, Erich Gamma, Richard Helm, Ralph Johnson ve John Vlissides GOF(Gang Of Four - Dörtlü Çete) yayınladıkları kitap ile dünyaya duyurdular. Bu güne kadar GOF ekibinin duyurmuş olduğu 23 adet tasarım deseni ile ilgili; yayınlanmış sorunların çözümünün aksini iddia eden yada alternatif çözüm üreten bir yazılım geliştirici henüz çıkmadı. Yeni tasarım desenleri duyuruldu, ancak, bunlarda farklı sorunlara farklı çözüm önerileri sunuldu. Yayınlanmış olan bu 23 adet yazılım tasarım deseni Creational (Yaratımsal), Structural(Yapısal) ve Behavioral(Davranışsal) tasarım desenleri olmak üzere 3 grupta toplanmıştır.

Faydaları; özetle ifade edecek olursak, tavsiye edilmiş ve kabul görmüş olan tüm yazılım geliştirme prensipleri, yöntemleri ve paradigmalarında belirtilmiş olan yazılım geliştirme kazanımlarına katkı sağlar diyebiliriz. En iyi yazılım ürününü en kısa, en güvenli, en yönetilebilir, en hızlı ... en mükemmel yapmamıza yardımcı olan kod şablonları dır diyebiliriz. Başlıklar halinde biraz açacak olursak;

• Yazılım geliştirme süreci(SDLC-Software Development Life Cycle)nin etkinliğini, verimini artırır, süreç yönetimini kolaylaştırır.
• Kod okunabilirliğini artırır,
• Yazılımın üretim ortamına çıkma ve ondan sonraki bakım maliyetini azaltır.
• Defensive(güvenli) kod geliştirmeye yardımcı olur.
• Yazılım geliştiricilerini teknik borç yükünden kurtarır.
• SOLID, GRASP, … gibi standart, prensip ve paradigmalara uygun kod geliştirmeyi sağlar.
• Gelen tüm yeni yazılım gereksinimlerini hızlı bir şekilde karşılayabilmeye.(Efektif, hızlı , çevik kod geliştirmeye) yardımcı olur.

Tabi eğer anti pattern a düşmezsek, söz konusu yukarıdaki faydaların sağlanmasını beklemek lazımdır. Kullanacağınız tasarım deseni yanlış ve gereksiz kullanıldığında fayda yerine zarar da getirebilir. Buna dikkat etmek gerekir.

Şu ana kadar ihtiyacım doğrultusunda tecrübe ettiğim tasarım desenlerini buraya not düşmeye çalışacağım;

Creational Design Patterns

Singleton: Oluşturulacak olan bir nesnenin sadece bir kez oluşturulmasını garanti eder.

Builder: Karmaşık, çok nitelikli nesneleri kolayca oluşturmayı sağlar.

Factory Method: Bir nesnenin implementasyonunu soyutlayarak(gizleyerek) oluşturmayı(initialize etmeyi) sağlar.

Abstract Factory: Factory Method un yaptığı işi yapar, ancak, birden fazla türde nesne oluşturulacak ise her bir nesne türünün soyutlanarak create edilmesini sağlar

Prototype: Bir nesnenin aynı özelliklerde ve atanmış değerleri ile birlikte bir prototipinin kopyalanarak oluşturulmasını sağlar. Oluşturulan kopya işlemi “Shallow(Sığ) copy” ve “Deep(Derin) copy” olmak üzere iki türlü yapılabilmektedir. Shallow copy de nesnenin sadece primitive değişkenlerinin değerleri kopyalanır, Deep copy de ise hem primitive hemde geriye kalan tüm referans tipli alt nesnelerinin değerleri kopyalanır.

Structural Design Patterns

Adapter: İki uyumsuz nitelikte olan nesnenin niteliklerinin uyumlu hale getirilmesini sağlar. Günlük hayata uyarlanarak ifade edecek olursak, prize takılan adaptör gibi düşünülebilir. Normalde 220 volt tan farklı voltajlarda çalışan cihazlar için mutlaka bir adaptör gereklidir.

Decorator: Bir nesnenin var olan özelliklerini bozmadan, değiştirmeden  o nesneye yeni özellikler, yeni nitelikler eklenmesini sağlar. (Bir tabloyu dekore edip o tabloya çerçeve eklemek gibi)

Facade: Çoklu, karmaşık yazılımsal alt sistemlere erişimi, soyutlayarak, basitleştirerek bir arayüz üzerinden, yani bir cephe üzerinden ilgili yazılımsal alt sisteme erişimi ve kullanım kolaylığını sağlar.

Proxy: Gerçek nesne üzerinde gerçekleştirilecek işlemler çok kaynak gerektirdiğinde, o işlemleri yapmak imkansızlaşır. Bu durumda gerçek nesne yerine vekil nesneler üretilerek çözüm bulmayı sağlar. (Cache server gibi)

Behavioral Design Patterns

Command: Bir request bir nesne altına komut olarak sarmalanarak, requesti invoke edecek nesnelere iletilip, ilgili nesnede çalıştırılmasını sağlar.

Observer: Bir nesnenin, gözlemci olan başka bir nesneye kendini kaydettirmesi sonrasında, o nesnenin kendisinde gerçekleşen eventlerin, durum değişikliklerinin ilgili gözlemci sınıf tarafından yayınlanmasını sağlar.

State: Kapsamı(context i) belli olan bir nesnenin var olan durumunun(state inin) if condition ları kullanmadan değiştirebilmesini sağlar. Her durum(state) için ayrı bir nesne oluşturulur. Oluşturulan her state nesnesi de var olan ortak kapsamda(context te) farklı davranış gösterir.

Strategy: Bir nesnenin yapmış olduğu davranışı veya çalışma şeklini runtime da değiştirebilmeyi sağlar. Her davranış için ayrı nesne oluşturulup, context nesnesinin constructor undan enjekte edilir. State de kapsam nesnesinin durum değişikliği söz konusudur, strateji deseninde ise kapsam nesnesinin farklı stratejide davranış göstermesi söz konusudur.

Template Method: Yapılacak her ortak işlem için ortak parametreleri kullanan bir şablonu(template i) oluşturularak effective kod yazabilmeyi sağlar. Ortak işlemler için copy/paste yapmaktan kurtarır. Her nesnenin ortak işlemine ait farklı değerler üretmesini sağlar(Arif‘in dilekçesi, Ahmet’in dilekçesi, …vs.). Abstract class içinde ortak işlemlerin yapılacağı methodlar tanımlanır. Parametrelerin değiştiği nesneler abstract class tan inherite edilir.  

Visitor: Bir ziyaretçi nesnesi, aynı işlemi farklı model nesnelerine göre farklı davranışlarda yaptırır. Strateji deseninde de farklı davranışlar için farklı nesneler kullanmıştık ancak visitor deseninde davranış türünü belirleyen ortak methoda visitor nesnesi tarafından davranış türü nesnesi enjekte edilmektedir. Strateji deseninde ise constructor dan enjekte edilmekteydi. Yeni bir ziyaretçi nesne türü gereksinimi olduğunda ilgili ziyaretçi interface inin güncellenmesi gerekmektedir. Strateji deseninde yeni davranış türü gereksiniminde yeni model nesnesinin diğerlerini etkilemeden eklenmesi yeterlidir.

Kaynaklar:

·         https://springframework.guru/gang-of-four-design-patterns/

·         https://en.wikipedia.org/wiki/Design_Patterns

·         https://www.tutorialspoint.com/design_pattern/index.htm

·         http://devnot.com/2015/gizli-tehlike-antipatterns/

·         https://sourcemaking.com/antipatterns/software-development-antipatterns