17 Ekim 2020 Cumartesi

Çevik(Agile) Yazılım Geliştirme Metodolojileri

         Agile Software Development(Çevik yazılım geliştirme), yazılım geliştirme süreçleri içerisinde(SDLC-Software Development Life Cycle) kabul edilen etkin bir yazılım geliştirme metodoloji türüdür. En iyi yazılım ürününü, en hızlı, en güvenli, yazılım geliştirme paradigmalarına en uygun olarak geliştirmek, SDLC nin ilk zamanlarından itibaren ortaya çıkan, şekillenen bir sorun olmuştur. Buna çözüm olarak, Waterfall, Spriral, … ve son olarak Çevik yazılım geliştirme methodolojisi 2000 li yılların başlarında bir grup software development influencer tarafından duyurulmuştur.  2001 yılında Utah, Snowbird'deki bir kayak merkezinde 17 kişilik software development influencer kendi aralarında çevik yazılım geliştirme yaklaşımları üzerinde hem fikir olup, çevik yazılım geliştirme manifestosu yayınlamışlardır(http://agilemanifesto.org). Ayrıca imzaladıkları manifestoyu, kendileri ile aynı fikirde olup imzalamak isteyenlere de açmışlardır(http://agilemanifesto.org/display/index.html).

Bu manifesto da;

Süreçler ve araçlardan ziyade bireyler ve etkileşimlere
Kapsamlı dökümantasyondan ziyade çalışan yazılıma
Sözleşme pazarlıklarından ziyade müşteri ile işbirliğine
Bir plana bağlı kalmaktan ziyade değişime karşılık vermeye

            değer verdiklerini, çevik yazılım geliştirebilme açısından sol taraftaki maddelerin değerini kabul etmekle birlikte, sağ taraftaki maddeleri daha değerli bulduklarını ifade etmişlerdir.

Manifestonun detayında ise; 12 temel prensibi(http://agilemanifesto.org/principles.html) benimsemişler ve bunları da kayıt altına alıp imzalamışlardır. Bu prensipler;

1) En önemli önceliğimiz değerli yazılımın erken ve devamlı teslimini sağlayarak müşterileri memnun etmektir.

2) Değişen gereksinimler yazılım sürecinin son aşamalarında bile kabul edilmelidir. Çevik süreçler değişimi müşterinin rekabet avantajı için kullanır.

3) Çalışan yazılım, tercihen kısa zaman aralıkları belirlenerek birkaç haftada ya da birkaç ayda bir düzenli olarak müşteriye sunulmalıdır.

4) İş süreçlerinin sahipleri ve yazılımcılar proje boyunca her gün birlikte çalışmalıdırlar.

5) Projelerin temelinde motive olmuş bireyler yer almalıdır. Onlara ihtiyaçları olan ortam ve destek sağlanmalı, işi başaracakları konusunda güven duyulmalıdır.

6) Bir yazılım takımında bilgi alışverişinin en verimli ve etkin yöntemi yüzyüze iletişimdir.

7) Çalışan yazılım ilerlemenin birincil ölçüsüdür.

8) Çevik süreçler sürdürülebilir geliştirmeyi teşvik etmektedir. Sponsorlar, yazılımcılar ve kullanıcılar sabit tempoyu sürekli devam ettirebilmelidir.

9) Teknik mükemmeliyet ve iyi tasarım konusundaki sürekli özen çevikliği artırır.

10) Sadelik, yapılmasına gerek olmayan işlerin mümkün olduğunca arttırılması sanatı, olmazsa olmazlardandır.

11) En iyi mimariler, gereksinimler ve tasarımlar kendi kendini örgütleyen takımlardan ortaya çıkar.

12) Takım, düzenli aralıklarla nasıl daha etkili ve verimli olabileceğinin üzerinde düşünür ve davranışlarını buna göre ayarlar ve düzenler.

Manifestoyu ilk imzalayanlar(http://agilemanifesto.org/authors.html);

Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler

James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick

Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

            Çevik Yazılım Geliştirme Manifestosu ve arkasındaki 12 ilkede ifade edilen değerleri uygulayan şirket, kurum veya organizasyonlar kendilerine özgün uygulama şekillerine göre bu metodolojiden avantaj sağlarlar. Tabiiki dezavantajlı durumlar da söz konusudur. Bu metodolojinin; 

Avantajları;

·         Kısa planlanmış döngüler, değişen gereksinimler ve ani ortaya çıkabilecek değişiklikler için agile metodoloji, kullanan organizasyonlara esneklik imkânı sağlar.

·         Nihai hedefin açıkça tanımlanmadığı yazılım projeleri için faydalıdır. Yazılım projesi ilerledikçe hedefler ortaya çıkacak ve yazılım ürünü bu gelişen gereksinimlere kolayca adapte olabilecektir.

·         Müşterilerin yada proje sahiplerinin ürünlerini oluşturmak ve bu ürünlerle ilgili çıkan problemleri kolayca çözebilmek için müşteri yada proje sahiplerinden aktif bir şekilde geribildirim alınabilmesini sağlar.

·         Ekip katılımına öncelik verilerek kurulan iletişim sayesinde yazılımsal sorunların daha hızlı ve etkin çözülmesini sağlar.

·         Yazılım projeleri hızla ilerlerken ortaya çıkan her problem, bir sonraki döngüde daha iyi bir çözüm için önceki döngüleri basamak olarak kullanabilir. Her yineleme (sprint) sırasında test yapmak, hataların daha hızlı tanımlanmasına ve çözülmesine katkı sağlar. Yazılım projeleri; bu yöntem ile daha tutarlı ve art arda yinelenen adımlarla daha hızlı yazılım ürününü ortaya çıkartabilmeyi sağlar.

·         Müşterilerin, teslim edilen işi görmeleri, girdilerini paylaşmaları ve son ürün üzerinde daha etkili olabilmeleri için çok fazla fırsatları vardır. Müşteriler, yazılım proje ekibiyle çok yakın çalıştıklarından yazılım ürününe olan sahiplik duyguları ve motivasyonları da daha fazladır.

Dezavantajları;

·         Ürün gereksinimleri sürekli değişebileceğinden maliyetler peşinen tahmin edilemez.

·         Müşteriler geri bildirim vermek istediklerinde, akıllarına gelebilecek yeni istekler ek fazları ortaya çıkarır. Agile software development, belirli süreli yinelemeli çıktılara dayalı olduğundan ve proje yöneticileri genellikle görevleri tekrarlamakta olduğundan, başlangıçta teslimat için planlanan bazı öğelerin zamanında tamamlanamaması olasıdır. Yani, projenin herhangi bir anında yeni bir sprint eklenebilir. Bu gibi durumlarda yazılım projelerinin maliyetlerinin artması ve belirlenen bitirme sürelerinin uzaması söz konusudur.

·         Müşterilerden, proje sahiplerinden sürekli geri bildirim almak çalışma ekiplerini alaşağı edebilir ya da bazı müşterilerin zamanı ve hiç ilgisi olmayabilir.

·         Yazılım projelerinin başarısı için gerekli olan dökümantasyon ihmal edilebilir; Agile Manifesto, kapsamlı bir dokümantasyon yerine çalışan yazılımı tercih eder, bu nedenle bazı ekip üyeleri, dokümantasyona odaklanmayı daha az önemli gibi hissedebilirler. Kapsamlı dokümantasyon, proje başarısına yol açmamakla birlikte, çevik takımlar dokümantasyon ve çalışan yazılım arasındaki doğru dengeyi mutlaka bulmalıdırlar. Yani dökümantasyonu olmayan yazılım kaliteli yazılım değildir. Dökümantasyon ile ilgili çok detaylı kapsamdan uzaklaşmak başarıyı artırır önerisi vardır.(“Büyük harita” deyimi)

·         Çevik yazılım projeleri ilk başlarda kesin bir plana sahip olmayabilir, bu nedenle nihai ürün başlangıçta tasarlanandan çok farklı görünebilir. Agile software development çok esnek olduğu için, değişen müşteri geri bildirimlerine dayanarak yeni iterasyonlar eklenebilir. Bu da çok farklı bir hedefe gitmeye yol açabilir. Yazılım projesinin başında hedeflenmiş olan ürün ile proje bitiminde sonuçlanan ürün arasında çok fark olması, müşterileri ve proje sahiplerini olumsuz etkileyebilmektedir.

·         Agile metodolojisini; müşteri ile iletişimi zor olan büyük kurumsal yapılarda uygulamak zor olabilir. Bunun için Agile dönüşüm danışmanlığı veren firmalardan destek alınması yada şirket, kurum yada organizasyon içerisinde bir birim kurup ilgili yetkin personelleri istihdam etmek gerekebilir.

·         Agile methodolojisini uygulamak tek başına yazılım ekiplerinin, sadece bir takımın yada bir kişinin uygulayabileceği bir pratik değildir. Eğer müşteri ile beraber organizasyondaki yönetim, alt yönetim ekipleri ve yazılım geliştirme ekipleri ile birlikte çevik yazılım geliştirme metodolojisi uygulanamazsa yazılım projelerinin çevikliğinden bahsetmek söz konusu olamaz. Yani bu durumda SDLC süreci daha da hantallaştırılmış olur.

Sonuç : Agile metodolojiler 2001 yılında fiilen duyurulmuş olsada, bu ilk başlangıç adımı olarak nitelendirilmiştir. Agile manifesto sunu imzalayanlar “Agile Alliance(çevik ittifak)” isminde bir gönüllü topluluk da oluşturmuşlardır(www.agilealliance.org). “Manifesto for Agile Software Development'ın” orijinal yazarları; “Agile Manifesto'yu yazarak ve Agile Alliance'ı başlatarak Agile yazılım geliştirme gemisini inşa edip denize bıraktıklarını, ancak geminin yelken açmasına ve çevik gelişim liderliğinin bu geminin çok ötesine yayılmasına izin vermekten mutlu olduklarını” ifade etmişlerdir.

Çevik yazılım geliştirme frameworkleri ve yöntemleri olarak; Extremming Programming, Lean Software Development(LSD), Feature-Driven Development(FDD), Adaptive System Development(ASD), Dynamic Systems Development Method(DSDM), Cristal Clear, Test-Driven Development, Rapid Application Development, Emprical Control Method, Scrum, Kanban, Scrumban, … gibi framework ve yöntemler günümüzde tercih edilmektedir. Ancak çeviklik yaklaşımında öyle bir açık kapı ifadesi bırakılmıştır ki her yazılım geliştirme ekibine göre özgün olarak uygulama pratiği söz konusudur. Bu yüzden çevik yazılım geliştirme frameworkleri ve yöntemleri her geçen gün çeşitlenmeye devam etmektedir. Cevik yazılım geliştirme prensiplerinin bir adım ötesini arama çabası olarak, “çıtayı yükseltmek” mottosuyla, 2009 yılında “Software Craftsmanship manifestosu(https://manifesto.softwarecraftsmanship.org/)” bir grup developer community tarafından duyurulmuş ve imzaya açılmış bulunmaktadır. Dolayısıyla, çeviklik metodolojisinin yeni implementation(uyarlama)ları ilerleyen zaman içinde daha da gelişip çeşitlenmeye, evrim geçirmeye devam edecek gibi gözükmektedir.

Not: Çevik yazılım geliştirme metodolojisi ile ilgili, literaturde olan yayınlanmış kaynakları tarayarak bu notları yazmış bulunmaktayım. Özellikle avantaj ve dezavantajlar somut tecrübe isteyen yorumlar olacağından, deneyim ve gözlemlerime göre makaleyi güncellemeyi planlamaktayım.

Kaynaklar:


Gönderen zaman: Hiç yorum yok :
Etiketler: , , , , , ,

3 Ekim 2020 Cumartesi

Cross Site Request Forgery (CSRF,XSRF)

            Cross Site Request Forgery(CSRF veya XSRF), Siteler Arası İstek Sahteciliği yöntemiyle yapılan saldırı, istismar(exploit) türüdür.  Yetkili kullanıcılar dışındaki kötü niyetli kişiler, bir web sitesine, yetkili kullanıcıymış gibi request oluşturup, hedef seçtikleri kullanıcı yada uygulamaya oldukça etkili zararlar verebilmektedirler.  Yani verilebilecek zararın etkisi kullanıcının uygulama içindeki yetkisi ölçüsünde değişkenlik gösterir. Saldırganlar yetkili kullanıcı requestlerini “Man in the middle(Orta adam)” saldırısı, cookie, session datalarını çalma gibi yöntemler ile oluşturabilmektedirler. Yetkili kullanıcının web sitesinde kimliği doğrulanırsa, ilgili web sitesi meşru talepler ile sahte talepler arasında ayrım yapamaz. Bu yöntemde, saldırganlar sahte talepleri yetkili kullanıcılara yaptırmaktadırlar.

Saldırgan(fail), mağdur adına istenmeyen bir işlevi yerine getirmek için mağdurun kimliğini ve ayrıcalıklarını miras alır. Çoğu websitesi için tarayıcı istekleri; kullanıcının oturum tanımlama bilgisi, IP adresi, Windows etki alanı kimlik bilgileri vb. gibi web sitesiyle ilişkili tüm kimlik bilgilerini otomatik olarak içerir. Bu nedenle, kullanıcının şu anda sitede kimliği doğrulanmışsa, site, mağdur tarafından gönderilen sahte talep ile mağdur tarafından gönderilen meşru bir talep arasında ayrım yapamayacaktır. Bazen CSRF saldırısını savunmasız sitenin kendisinde depolamak da mümkündür. Bu tür güvenlik açıklarına "stored CSRF flaws(depolanan CSRF kusurları)" denir. Bu saldırı, HTML'yi kabul eden bir field da bir IMG veya IFRAME etiketini depolayarak veya daha karmaşık bir siteler arası komut dosyası saldırısı(XSS) ile gerçekleştirilebilir. Saldırgan sitede bir CSRF saldırısı depolayabilirse, saldırının ciddiyeti artar. Özellikle, mağdurun saldırıyı içeren sayfayı İnternet'teki rastgele bir sayfadan daha fazla görüntülemesi olasılığı vardır. Bu olasılık doğrultusunda mağdur doğrulanmış bilgileri ile isteği dışında bir saldırıya maruz kalmış olmaktadır.



Şekil 1 : CSRF saldırısı örneği.

            Şekildeki örnekte; fail(saldırgan) ele geçirdiği request’ i, CSRF açığı olan bir bankanın websitesinden login olmuş mağdurlara mail ile gönderip, bu kişilerin hesabından, kendi hesabına para transferi yaptırabilmektedir.

Alınabilecek Önlemler;

·         Her request için CSRF tokenları kullanmak; Örneğin her request için geçerlilik süresi minimum olan JWT(JSON Web Token) endüstri standardında(RFC 7519) tokenlar üretmek ve kullanmak şu an ki teknolojiler itibari ile oldukça güvenlidir.

·         Client tarafından gönderilecek requestlerde; Http request methodu olarak GET değil, POST kullanmak.

·         Request body si içerisindeki önemli dataları , client-side ve server-side olarak mümkünse encrypt-decrypt ederek kullanmak.

·         Oturum çerezleri için her zaman “SameSite Cookie Attribute” (https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#samesite-cookie-attribute) kullanmak.

·         Standart Header lar ile Origin doğrulamak; Source origin ve target origin belirleyip, sunucu tarafında doğrulama yapabiliriz. (CORS filter ekleyebiliriz. Ancak düzgün yapılandırılmış bir CORS politikası önemli olsa da, kendi başına bir CSRF savunması oluşturmaz.)

·         Web site yayınlama yöntemi olarak TLS(SSL) standart protokollerini kullanmak; TLS(Transport Layer Security) önceki ismiyle SSL(Secure Sockets Layer), bilgisayar ağı üzerinden güvenli haberleşmeyi sağlamak için tasarlanmış kriptolama protokolleridir.

OWASP tarafından önerilen ve POC ‘si de yapılan, örnek önleme yöntemlerinden bazılarını içeren Java Web uygulamaları için kod örneğini ; “https://github.com/righettod/poc-csrf” linkinden inceleyebilirsiniz.

Not : Eğer Siteler Arası Komut Dosyası (XSS) zaafiyeti var ise, bu XSS zaafiyeti kullanılarak tüm CSRF önleme tekniklerini bypass etmek mümkündür. Bu yüzden XSS zaafiyetine karşı da önlemler alınması zorunludur.

Kaynaklar:


Gönderen zaman: Hiç yorum yok :
Etiketler: , ,

28 Eylül 2020 Pazartesi

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

 

Gönderen zaman: Hiç yorum yok :
Etiketler: ,

17 Eylül 2020 Perşembe

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:

Gönderen zaman: Hiç yorum yok :
Etiketler: , , , , , , ,
Kaydol: Kayıtlar ( Atom )