OWASP Proactive Controls

Netsparker'ın Ekim ayı güncellemesi ile birlikte çok önemli bir özellik rapor klasifikasyonlarımıza eklendi: OWASP Proactive Controls.

OWASP Proactive Controls'u özetleyecek olursak güvenli yazılım geliştirmenin amentüsü diyebiliriz. Yakın bir zamanda 2016 kontrol listesi de duyurulan Proactive Controls'lerin ortaya çıkış amacı ve nedenlerine bizzat Proactive Controls dökümanının giriş kısmında değinilmiş.

Buna göre, yazılımcılar tarafından, yine yazılımcıları güvenli yazılım geliştirme sürecinde desteklemek için yazılan Proactive Controls, yazılımların güvenlik açısından penaltıya düştüğü noktaları geliştiricilerin zihnine bir mıh gibi çakmak niyetinde.

Yazılım geliştiriciler, güvenli yazılım geliştirme ve Demokles'in Kılıcı gibi tepelerinde sallanan deadline kılıçlarıyla maalesef bu hususta yeterli performansı gösteremiyorlar. Kullanılan araçların, frameworklerin güvenlik duyarlılıkların zayıf olması ya da varsayılan olarak bu tedbirleri desteklemiyor oluşları da işin cabası. Aşağıda özetle Proactive Controls maddelerini değerlendirecek ve Proactive Controls maddelerinin, OWASP Top 10 Kritik Zafiyetler Listesi'ndeki hangi derde deva olduğunu göreceğiz.

C1 - Verify for Security Early and Often

Arapların La-Edri, yani anonim olan güzel bir sözü var. Evvel Refik, Bad'el Tarik. Mealen, önce yoldaş, sonra yol demek. Buradaki yoldaşı pekala güvenlik farkındalığı olarak düşünebiliriz.

Pek çok örnekte, güvenlik testleri, development sürecinin çok dışında ele alınıp, tespit edilen sorunlar fixlenmesi gereken issuelar olarak geliştiricilere görev olarak atanıyor. Yazılım geliştirme süreçlerine dahil edilmeyen güvenlik prensipleri, maalesef scan-then-fix olarak özetleyeceğimiz, kendi kuyruğunu yiyen yılan misali, fasit bir daireye hapsediliyor.

Güvenliğin yazılım dizayn ve geliştirme aşamalarında, ürünün vazgeçilmez özelliklerinden biri olarak ele alınması elzemdir. Yazılım geliştirme esnasında, öyküleme yapılırken, güvenlik de senaryonun bir parçası haline getirilmelidir.

C2 - Parameterize Query

Enjeksiyon zafiyetleri özetle, kullanıcılardan alınan girdilerin, herhangi bir kontrole tabi olmadan, sorgulara, komut bloklarına eklenmesi ile oluşan zafiyetlerdir.

Yazılımlarımızın iletişim kurduğu altsistemlerin kendi anlam dizgelerinde özel anlamlara sahip olan kelimeler bu kullanıcı girdilerine enjekte edildiğinde,bu verilerin kullanıldığı sistemler tarafından bu girdilerin ne kadarının parametre, ne kadarının da kod olarak değerlendirileceği sistemler tarafından algılanamamakta ve girdi işlenmektedir. Girdilere zararlı kodlar enjekte edildiğinde ise istenmeyen sonuçlar ortaya çıkmaktadır:

"select * from users where id=".$_GET["id"];

	http://www.example.com?getUser?id=1
            select * from users where id=1

	http://www.example.com?getUser?id=1 or 1=1 --
            select * from users where id=1 or 1=1 --

Programlarımızın akışı için ihtiyaç duyduğumuz girdilerde bu tür zararlı parçaların etkisiz hale getirilmesi için bu zararlı girdilerin kod kontekstinin bir parçası olarak değil de, sadece parametre olarak değerlendirilmesi gerekmektedir. Bunun için de örneğin SQL sorgularımızı oluştururken, SQL cümleciğimiz ile, bu SQL cümlesinin parametre kontekstinde kullanacağımız parametrelerin ayrı ayrı belirtilmesi gereklidir.

PHP :

$stmt = $dbh->prepare("update users set email=:new_email where id=:user_id");
$stmt->bindParam(':new_email', $email);
$stmt->bindParam(':user_id', $id);

.NET :

string sql = "SELECT * FROM Customers WHERE CustomerId = @CustomerId";
SqlCommand command = new SqlCommand(sql);
command.Parameters.Add(new SqlParameter("@CustomerId", System.Data.SqlDbType.Int));
command.Parameters["@CustomerId"].Value = 1;

OWASP Proactive Controllerin ikinci maddesi olarak önerilen Parameterize Query, sadece SQL Injection'a karşı değil, SQL Injection'ın da dahil olduğu ve uzun yıllardır ilk sıradaki yerini koruyan Injection zafiyetlerine karşı yazılımlarımızı koruyacaktır.

C3: Encode Data

Bir sistemde anlam ifade eden karakterlere meta karakterler denilmektedir. Örneğin HTML sayfalarında <a></a> karakterleri bir link yaratır, <script></script> tagları bir script başlangıç ve bitişini ifade eder. Bu tarz anlam ifade eden karakterler, kelimeler bazen inputlar içerisine enjekte edilerek, sistemin farklı bir biçimde çalışmasına yol açabilir, daha da kötüsü bu yolla bir saldırı gerçekleştirilebilir.

Kullanıcı girdileri içerisine enjekte edilen bu tarz karakterleri zararsız formlarına dönüştürmek için Encoding mekanizması kullanılmaktadır.

Örneğin

http://www.example.com?link=main.html

$link = $_GET["link"];
echo '<a href="$link">Click me!</a>";

Eğer link adındaki Query string ile birlikte aşağıdaki gibi bir girdi sağlansa idi, oradaki kontekts ele geçirilecek ve oluşturulan çıktıda bir script çalıştırılabilecekti.

http://www.example.com?link=main.html" onclick="alert(1);
<a href="main.html" onclick="alert(1);">Click me!</a>

İşte sağlanan bu girdideki meta karakterlerin, encode edilerek normalize edilmesine, kullanıldığı kontekst içerisinde zararsız hale getirilmesine Encoding denilmektedir:

$link = htmlspecialchars($_GET["link"]); // Encode the input;

<a href="main.html&quot; onclick=&quot;alert(1);">click me!</a>

Encoding'i hem girdi işlemlerinde hem de çıktılarda kullanabiliriz. Girdi işlemlerinde encoding kullanarak, Command Injection, LDAP Injection gibi zafiyetlere karşı korunabilir; çıktıları encode ederek ise, Cross Site Scripting (XSS) zafiyetlerine karşı önlem almış oluruz.

DOM Based XSS için burada bir parantez açmakta fayda var.

DOM Based XSS 'e karşı aşağıdaki encoding mekanizmasını kullanabilirsiniz:

<script>document.body.innerHTML(document.location.href);</script>

yerine

<script>document.body.innerText(document.location.href);</script>

DOM Based XSS 'in detayları için, Netsparker blogunda Emre İyidoğan tarafından yazılan yazıyı okuyabilirsiniz.

C4: Validate All Inputs

Sisteme dışarıdan gönderilen ya da dışarıdan bir etkiye maruz kalan tüm veriler "güvensiz" olarak addedilmeli ve validasyon işlemine tabii tutulmalıdır.

Validasyon işlemi iki farklı şekilde yapılmalı. Hem biçimsel (syntax) hem de anlamsal (semantic) olarak.

Bu da nerden çıktı, dediğinizi duyar gibiyim.

Biçimsel olarak validasyona tabii tutmayı bir örnek üzerinden açıklayalım. Kullanıcıdan, bir kullanıcı id'si beklediğimizi varsayalım. Biçimsel olarak bu girdiyi denetlemek istersek, girdinin gerçekten de integer, yani tamsayı tipinde, ve örneğin 4 basamaklı olup olmadığını kontrol ederiz. Buna biçimsel (syntax) validasyon denilmektedir.

Semantik, yani anlamsal, olarak geçerliliği denetletmek ise, örneğin yukarıdaki işlemde kullanıcı id'sini, şifre sıfırlamak için istediğimizi varsayalım. Kullanıcının sağladığı kullanıcı id'si gerçekten de bu kullanıcıya ait olup olmadığını kontrol ederiz.

Farklı girdi noktalarından sağlanan tüm veriler için yukarıdaki kontrolleri yaparak, uygulamalarımızı daha güvenli bir hale getirebiliriz.

Şimdi filtrelemede kullanılan iki farklı yaklaşımı ele alalım.

Blacklist (Kara Liste) Oluşturmak

Adından da anlaşılacağı gibi, blacklist, filtreleme işleminde, neyi istemediğimiz üzerinden bir denetim yapmak anlamına gelmektedir.

Kapıdan içeri şu, şu, şu kişiler girmesin, demek gibi.

Oysa aynı niyete sahip başka kötü niyetli bir kişi girebilir. Uygulamalarımızı karalisteler ile güvenli hale getirmemiz, sonsuz bir hülyanın peşinden koşmak gibidir. Biz sonu gelmeyen karalisteler tanımladıkça, saldırganlar mutlaka bunu bypass edecek bir yol bulacaklardır.

Whitelist (Beyaz Liste) Oluşturmak

Validasyon listelerinde, neyin kötü olduğuna dair sonsuz listeler tanımlamak yerine, beklenen değerler ile ilgili kısa ve net bir liste tanımlamak, uygulamalarımızı daha güvenli kılacaktır. İşte böyle bir filtreleme işlemine whitelisting denilmektedir.

Örneğin aşağıdaki PHP kodumuz kullanıcıdan aldığı go parametresi ile web navigasyonuna devam edilmesini sağlamaktadır.

<?php
$file = "home";

if(!strpos($_GET["go"],"http://") && !strpos($_GET["go"],"file://")) {
    $file = $_GET["go"];
}
    include($file.".php");
?>

Yukarıdaki kod bloğu kullanıcıdan aldığı girdiyi doğrudan include fonksiyonuna gönderek, sistemden bir dosya çağrısında bulunuyor. Bu girdi için blacklist yöntemi ile bir takım kısıtlar da konmuş durumda, file:// ve http:// protokolleri görünürde, olası tüm atakların önünü almış gibi gözükse de, atak skalasına eklenecek yeni bir parametre ile bu kalkan düşecek ve uygulama savunmasız hale gelecektir. Örneğin, php://input payload'u ile.

php://input wrapper'i, POST bir isteğin gözdesinden aldığı PHP kodlarını çalıştırmaktadır. Diyelim ki bu yazıdan hemen sonra geliştirici tehlikeyi sezdi ve zararlı girdiler arasına php://input'u da ekledi. data:// wrapper'ı ne güne duruyor? Aşağıdaki gibi bir payload ile bir başka bir atak söz konusu olabilecekti:

data://text/plain, <?php system($_GET["cmd"]); ?>

Geliştiricinin her yeni atak parametresini bu listeye eklemesi elbette ki doğru bir yaklaşım değil. Geliştirici bu yeni payload'un farkına varıp, karalisteye aldığında, her şey için geç olabilir :) (Bu konuda ayrıntılı bilgi için Netsparker Türkiye blogunda yayınlanan LFI, RFI Güvenlik Zafiyetleri Bağlamında PHP Stream Wrapper'ları yazımıza müracaat edebilirsiniz.)

Oysa whitelist yöntemi ile, olası bütün tehlikeler aşağıdaki şekilde bertaraf edilebilirdi:

<?php
$file = "home";
$allowed_pages = array("home","contact","products","pictures");
	if(in_array($_GET["go"],$allowed_pages)) {
	$file = $_GET["go"];
}
	include($_GET["go"].".php");
?>

Validasyonlarla ilgili önemli bir nokta da şu: valide etmek, bu girdileri güvenli hale getirmekle eşanlamlı değildir. Özellikle de whitelist yaklaşımında, kullanıcı beklentimiz dışında bir girdi sağlıyorsa, bu girdileri, trim ederek, zararlı karakterleri replace ederek güvenli bir hale getirmekle mesul değiliz. Beklediğimiz şartlara uymayan tüm girdiler reddedilmelidir.

İkinci bir nokta olarak da, hususen web güvenliği bağlamında, hem istemci hem de sunucu tarafında bu validasyon işlemleri yapılmalıdır. İstemci tarafında validasyonların yapılmasının esas amacı, istemci tarafında kullanıcı deneyimini geliştirmektir. Böylece henüz istemci tarafında iken hatalı bir girdi konusunda kullanıcıyı uyarmak ve ekstra trafik ve bekleme sürelerinin önüne geçmek mümkün olacaktır.

İstemci tarafında validasyon denetimi yapılıp yapılmadığından bağımsız olarak, sunucu tarafında mutlaka ve mutlaka validasyon işlemi yapılmalıdır.

C5: Implement Identity and Authentication Controls

Authentication kısaca, bir kişi ya da girdinin kendisi olduğunu iddia ettiği kimliğin doğruluk değerinin sınandığı bir işlemdir. Authentication bu imkanı sunduktan sonra, yani kişinin kimliğinden emin olduktan sonra bu kimliğin uygulamalarımızdaki yetkilerini tespit etme işlemi ise, Authorization olarak yani yetkilendirme olarak tanımlanmaktadır.

Bu başlık oturum yönetimi, şifreleri güvenli bir biçimde saklama, güvenli şifre sıfırlama seçenekleri, iki adımlı giriş gibi pek çok altbaşlığı kapsamaktadır.

Bu başlıklara kısaca değinecek olursak,

2FA veya MFA (Multifactor Authentication)

2FA, kullanıcıların kendilerinin iddia ettikleri kişi olduklarını doğrulamak için aşağıdaki kombinasyonları kullanmalarını zorunlu kılar. Bu kombinasyonda aşağıdaki unsurlar kullanılabilir:

• Kullanıcının bildiği (Şifre ya da PIN)
• Kullanıcının sahip oldukları (Telefon, OTP, Token Generator)
• Bizzat kendisi olan (Biometrik tanımlama, parmak izi vb.)

Şifreleri Güvenli Bir Biçimde Saklamak

Uygulamalarımız, güvenli bir yetkilendirme sağlamak için kullanıcılara ait şifreleri de güvenli bir biçimde saklamalıdır. Şifreler salt metin olarak değil, güçlü kriptografik yöntemler ve tuzlama (salt) yöntemleri ile şifrelenerek saklanmalı, olası bir ele geçirilme durumunda, saldırgan tarafından tanınamaz ve kullanılamaz hale getirilmelidir. Ayrıntılar için OWASP Password Storage Cheat Sheet dökümanı incelenebilir.

Güvenli Şifre Sıfırlama Mekanizmaları

Kullanıcıların uygulama giriş bilgilerini unuttuğu durumları yönetebilmek için, uygulamalar şifre sıfırlama mekanizmaları sunmaktadır. Şifre sıfırlama mekanizmaları, önerilen bir yöntem olarak MFA yani çoklu faktör kullanarak şifre sıfırlama işlemlerini yapmalıdır.

Örneğin, kullanıcının bildiği ve sahip olduğu iki unsur, yani gizli soru ve beraberinde eposta adresine gönderilen bir sıfırlama linki, gibi.

Böylece şifre sıfırlama mekanizmaları bir servis dışı bırakma saldırı alanlarına dönüşmekten kurtarılabilir. Çünkü kullanıcının şifresi ancak, kendisinin sahip olduğu bir cihaz ya da eposta adresine gönderilen linkle birlikte sıfırlanacaktır.

Yine ek olarak şifre sıfırlama mekanizmaları Username Enumaration için sık kullanılan alanlardan biridir.

Bunun dışında, şifre sıfırlama mekanizmaları, oturumları müstakil bir biçimde yürütmeli, Session Puzzling zafiyetine mahal verilmemelidir.

Oturum Etkinleştirme ve Sonlandırma

HTTP protokolünün doğası itibariyle , oturumlar kullanıcıyı tanımlamanın en sık kullanılan yöntemidir. Dolayısıyla oturumları etkili ve güvenli bir biçimde yönetmek, uygulama güvenliğinin en önemli bileşenlerinden biridir.

Her yeni ve başarılı bir oturuma özgü, yeni bir oturum id'si üretilmelidir. Böylece uygulamalarımızı Session Fixation yani Oturum Sabitleme saldırılarına karşı koruyabiliriz.

Oturum sonlandırma için, uygulamanın yapısına özel bir geçerlilik süresi tanımlanmalı ve saldırganın istismar edebileceği aktif oturum süresi minimize edilmelidir.

Bu yukarıda da söylendiği gibi tamamen uygulama bağımlı bir parametredir. Bir bankacılık uygulaması için bu süre 5 dakika olabileceği gibi, bir blog uygulaması için daha uzun bir süre atanabilir.

Bu konuda daha ayrıntılı bilgi için, oturum yönetiminin web güvenliği açısından taşıdığı önemi ayrıntılı olarak analiz eden HTTP İşleyişi ve Güvenliği Açısından Cookie ve Session Yönetimi yazımızı okuyabilirsiniz.

Uygulamadaki Önemli Özellikler İçin Tekrar Kimlik Doğrulaması Yapmak

Uygulamalarımız önemli işlemler için, örneğin şifre değiştirme, para transferi, kullanıcı bilgileri değişikliği gibi işlemler için tekrar kullanıcı bilgilerinin doğrulanmasını, yani login'i gerektirmelidir.

Böylece uzun süren oturum istismarının ya da söz konusu uygulama bölümleri için CSRF gibi siteler arası oluşabilecek bir atağın önü alınmış olacaktır.

C6: Implement Access Controls

Authorization yani Erişim Kontrolü kısaca, bir kaynağa yönelen erişimlere izin verilen ya da bu erişimlerin engellendiği işlemlerdir.

Erişim Kontrolü aynı zamanda, uygulama güvenliğinin ana başlıklarından biridir. Aşağıdaki prensipleri uygulamalarımız için gözden geçirmek ve eksikliklerini gidermek, uygulamalarımızı daha güvenli bir hale getirecektir.

Tüm İstekleri Erişim Kontrol Noktalarına Yönlendirmek

Pek çok framework ve dilde, hususen belirtilmedikçe bir kaynak için yetki doğrulaması yapılmamaktadır. Bunun tersi ise, daha güvenlik merkezli bir yaklaşım olan tüm isteklerin önce doğrulandığı bir tasarımdır.

Tüm isteklerin üzerinden akacağı bir erişim yetki mekanizması implemente etmeyi düşünmez misiniz :)

Ters Mizaçlı Olmak ya da Varsayılan Olarak Deny

Eğer bir kaynak için hususen bir erişim kuralı tanımlamadıysanız, bunun uygulama tarafından varsayılan olarak "Deny" olarak kabul edilmesini zorlamalıyız.

Yukarıda değindiğimiz whitelist yaklaşımına benzer olarak, sadece bu kaynaklara kimin erişeceğini tanımlamalı, tanımlamadığımız diğer erişimler engellenmelidir.

En Az Yetki Prensibi

Sistem rol ve yetkililerini ayarlarken Goldilock and Three Bears (Goldilock ve Üç Ayı) hikayesinden esinle ilkeleştirilen karınca kararınca prensibini uygulamak yeterli olacaktır: genel ihtiyaçları karşılayacak en ideal/optimum yetki.

Kullanıcının ihtiyaç duymadığı kaynaklara erişimine olanak veren geniş yetkiler ve ihtiyaç duyduğu kaynak ve fonksiyonlara erişimini kısıtlayan yetkilerin her ikisi de optimum değildir.

Kullanıcıya Güvenme!

Uygulama içerisinde karar süreçlerini işletirken, kullanıcılardan sağlanan datalara güvenmek yerine, sunucu taraflı doğrulamalar ya da veriler kullanılmalı. Kullanıcının id'sinin, bakiyesinin, role'ünün ne olduğu bilgisini istemci tarafından edinmek yerine, bunu sunucu tarafında edinmek güvenli olan yaklaşımdır.

Yukarıda sayılan prensipler doğrultusunda başta Insecure Direct Object Reference başta olmak üzere bir dizi zafiyetin önü alınabilir.

C7: Protect Data

Datayı hem dolaşımda, hem de sunucu tarafında güvenli bir biçimde muhafaza etmeliyiz. Datanın aktarımındaki güvenliğini SSL gibi güvenli bir protokol kullanarak sağlayabiliriz. Datayı saklamak için ise, yukarıda da söz edildiği üzere, güçlü kriptografik anahtarlar ve salt (tuzlama) kullanılmalıdır. Daha da önemlisi, gerekmedikçe hiçbir data saklanmamalıdır. Hırsızlar, bizde olmayan bir şeyi çalamazlar :)

C8: Implement Logging and Intrusion Detection

Loglar yalnızca debugging ve hata gidermede değil, uygulama güvenlik ve hizmet kalitesini yükseltmek, adli işlemler, analiz ve planlama, saldırı tespit vb amacıyla, pek çok alanda kullanılabilir.

Optimum bir loglama için, loglanacak veriler ne çok az ne de haddinden fazla olmalı. Zaman damgası, istemci kimliği (örneğin, IP) gibi olmazsa olmaz bilgiler tutulmalı; hassas bilgilerin saklanmamasına dikkat edilmelidir.

Loglamalarda iki husus özellikle güvenlik perspektifinden dikkate alınmalıdır. Bunlardan ilki log flooding ile servis dışı bırakma saldırılarına karşı gerekli denetim ve bakım yapılmalı; ikinci olarak da Log Injection saldırılarına karşı loglamadan önce girdilere mutlaka encoding işlemi yapılmalıdır.

C9: Leverage Security Frameworks and Libraries

Hep söylenegeldiği üzere güvenlik bir ürün değil bir süreç. Fakat bu süreçte başarısı kanıtlanmış ürünleri kullanmanın avantajlarını da yok sayamayız. Bu sebeple geliştirme süreçlerinde kullanılan frameworklerdeki güvenlik özelliklerini kullanmak bize zaman kazandıracaktır.

Güvenlik farkındalığı giderek artıyor ve artık pek çok ürün entegre güvenlik özellikleri ile birlikte geliyor.

Netsparker'da SameSite Cookie attribute'ının implementasyonunu ya da tüm modern browserlar tarafından desteklenen Content-Security-Policy (CSP) önerirken, bu bilgilendirmeyi OWASP Proactive Controls 9. Madde ile sınıflandırıyoruz.

C10: Hata Yakalama ve İstisna Yönetimi

Hata yakalama ve istisna yönetimi güvenli kod geliştirmenin önemli bir parçası ve bu adımdaki hatalar, önemli güvenlik risklerine yol açabilir.

Bu risklerin en önemlisi, hassas bilgilerin ifşasıdır. Bu hassas bilgiler, kullanıcılarınıza ait bilgiler olabileceği gibi, sisteminiz hakkında saldırganın işini kolaylaştıracak, sisteminize özgü bilgiler de olabilir. Saldırgan bu yolla edindiği bilgilerle saldırısını özelleştirebilir ve daha kısa sürede sonuç alabilir. Örneğin hangi uygulama sunucusunu kullandığınız, hangi işletim sistemi üzerinde uygulamalarınızın çalıştığı, versiyon bilgileri, bu versiyonları bilinen buglar içerip içermediği gibi bilgiler, saldırganı kısa yoldan arzu ettiği sonuca götürebilecek türden bilgilerdir.

Hataları kontrol etmemek, sistem çalışmasında beklenmedik ve denetlenemeyen sonuçlara yol açabilir.

Yılanlar ve Merdivenler : Proactive Controls'u Anlamak

OWASP Snakes and Ladders, dilimize tercümesi ile Yılanlar ve Merdivenler oyunu, bir tür masa oyunu. Türevlerine farklı adlar ve maksatlarla Asya toplumlarında rastlamak mümkün. Özetle bu tarz oyunlar, erdemli ve kötü davranışları oyunculara öğretmek üzere kurgulanan masa oyunları. Bu oyunlar vasıtası ile iyilik ve kötülük gibi soyut kavramların, öğrencilerin zihinlerinde somutlaştırılması hedefleniyor.

Oyun tahtasında 100 adet kare bulunuyor. Bu karelerin bazılarında her biri OWASP Top 10 listesindeki zafiyetleri temsil eden yılanlar ve OWASP Proactive Controls'daki güvenli yazılım geliştirme maddelerini temsil eden merdivenler bulunuyor.

Ola ki attığınız zarda pozisyonunuz bu yılanlardan birinin ağzına denk gelen kareye düşerse, yılanın kuyruğunun ucu hangi karade ise, o karaye doğru geri gitmeniz gerekiyor. Varsayalım attığınız zarda 27 numaralı kareye, yani yılanın Cross Site Scripting (XSS) zafiyetini temsil ettiği kareye denk geldiniz. Sizi gerisin geri, 6 numaralı kareye gönderiyor.

Yine oyun tablosunda sizi ileriye, yüksek basamaklara taşıyan merdivenler var. Her bir merdiven OWASP Proactive Controls listesindeki tedbirlerden/kontrollerden birini temsil ediyor.

Oyuna devam ederken, 13 numaralı karedeki merdivene denk gelirseniz, bu merdiven OWASP Proactive Controls listesindeki 3. maddeyi, yani Encode Data maddesini temsil ediyor. Dolayısı ile 13 numaralı kareye gelerek, çıktı kontrolünün ehemmiyetini algılayıp, sisteme bu kontrolleri entegre etmek sizi merdivenin uç tarafındaki 33 numaralı kareye çıkarıyor. Böylece yol üzerindeki 27 numaralı karede bulunan Cross Site Scripting (XSS) zafiyetinden korunmuş oluyorsunuz.

Snakes and Ladders oyunu sayesinde hem Proactive Controls'lerin deva olduğu dertleri, hem de uygulama güvenliğini anlamak, üstelik daha eğlenceli bir şekilde mümkün.