masaüstü uygulamasının ayar dosyasında SQL parolasını açık olarak görmemek iyi başlangıç. Fakat uygulama parola veritabanına bağlanabiliyorsa, bağlantıyı kurduğu anda kullanabileceği değer elde ediyor demektir. Parolanın dosyada şifreli durması, aşamayı ortadan kaldırmıyor.
Geliştirici tarafında sık karşılaşılan cevap var: “Parolayı sadece gerektiğinde çözüyoruz, işlem bitince siliyoruz.” yaklaşım bellekte gereksiz veri bırakmayı azaltır. Buna rağmen, çözme işlemini gerçekleştiği anda gözlemleyebilen biri için yeterli koruma değildir.
yazıda aynı veriyi üç farklı tasarımla ele alacağız. İlk uygulama çözdüğü veriyi bellekte tutacak. İkincisi yalnızca işlem sırasında açıp kendi tamponunu temizleyecek. Üçüncü uygulamaya ise ortak SQL PFX parolası hiç verilmeyecek. Böylece bellek temizliği mimari çözüm arasındaki farkı, çalışan örnekler üzerinden konuşabileceğiz.
Laboratuvardaki bütün değerler sahtedir. SQL sunucusuna bağlanılmaz, PFX dosyası içe aktarılmaz gerçek sertifikayla imza atılmaz. Parola biçimindeki örnek veriler her hazırlamada yeniden üretilir.
Veriyi saklamak kullanmakHassas veriyi incelerken üç ayrı durumla karşılaşırız: diskte saklanan veri, ağ üzerinden taşınan veri uygulamanın işlediği. durumların korumaları birbirinin yerine geçmez.
Şekil 1: Uygulama veriyi kullanmak için çözer. Kullanım anında alınan kayıt, uygulama kendi tamponunu temizledikten sonra kalabilir. Örneğin DPAPI korunan dosya, uygun Windows bağlamı olmadan doğrudan okunmaya karşı koruma sağlar. HTTPS, istemci sunucu arasındaki trafiği korur. Uygulamanın kullanmak üzere çözdüğü parola ise korumaların başka aşamasındadır.
Windows DPAPI’nin kullanıcı kapsamı normalde veriyi ilgili Windows kimliğine bağlar. Makine kapsamı seçildiğinde kullanıcılar arasında aynı ayrım sağlanmaz. Dosyanın izinleri varsa ek entropy değerlendirmeye dahildir. kapsamların ayrıntıları CryptProtectData belgesinde açıklanır.
Buradan “DPAPI işe yaramıyor” sonucu çıkmaz. DPAPI’nin koruduğu şeyle, uygulama çalışırken beklediğimiz korumayı ayırmamız gerekir. Kullanıcı kapsamında şifrelenen verinin aynı kullanıcı bağlamında uygulama tarafından çözülebilmesi normaldir.
Sorun, son kullanıcının bilgisayarında kullanılan sırrın kullanıcıdan mutlaka gizli kalacağı varsayımıyla tasarım yapıldığında ortaya çıkar. Bütün kurulumlarda ortak kullanılan, geniş yetkili SQL hesabı buna iyi örnektir.
Çalışma zamanında ne gözlemledik?İncelemede iki farklı durumu ele aldık: bellekte kalan metinleri aramak çözme çağrısının dönüşünde ortaya çıkan veriyi gözlemlemek. İlki tarama anında erişilebilen alanları gösterir. İkincisi, verinin kullanıma açıldığı ana bakar.
Örneğimizde CryptUnprotectData çağrısının dönüşünü izledik. Uygulama saklanan veriyi çözdüğünde, SQL PFX parolası biçimindeki sahte değerlerin açık hâlini görebildik. Gözlemlediğimiz nokta, uygulamanın veriyi kullanmak üzere aldığı aşamaydı.
şifreleme algoritmasının kırılması anlamına gelmiyor. Uygulama kendi yetkisiyle veriyi çözüyor. Gözlem noktada gerçekleşiyor. Aynı şekilde TLS öncesindeki açık veriyi süreç içinde görmek, ağ üzerinde TLS’nin aşıldığını göstermez.
incelemede kullanılan bellek taramasının kapsamı sınırlıydı. Tarama kodu her bellek bölgesinin ilk 2 MB’ında, altı veya daha uzun yazdırılabilir ASCII dizilerini arıyordu. UTF-16 metinler, farklı veri biçimleri taranmayan alanlar gözden kaçabilir. nedenle taramada parola bulunamaması, parolanın süreçte hiç bulunmadığına dair yeterli kanıt değildir.
Yakalanan veri uygulamanın anki belleğini ayırmak gerekir. Çözme sırasında aldığımız kayıt, gözlem anındaki verinin ayrı kopyasıdır. Uygulama daha sonra tamponunu temizlese bile kayıt kalabilir. Kayıt, verinin anda görülebildiğini gösterir. Hedef süreçte hâlâ bulunduğunu tek başına göstermez.
Laboratuvarın düzeniÖrnekler C# hazırlanmış dört masaüstü uygulamasından oluşuyor. İlk iki uygulama aynı sahte veri biçimini kullanıyor. Üçüncü dördüncü uygulama birlikte çalışıyor.
UygulamaGösterdiği davranış01_ResidentSecrets.exeVeriyi çözer, açık tamponu alanda tutar çıkış işleminde temizlemez.02_TransientSecrets.exeVeriyi işlem sırasında çözer, kendi tamponunu finally içinde temizler.03_ApiClient.exeKullanıcı oturumuyla işlem ister. SQL veya PFX parolası almaz.04_LabService.exeÖrnek işlemi kendi sürecinde yapar, istemciye yalnızca sonucu döndürür.Veri içindeki LAB_SQL_ LAB_PFX_ önekleri ekran görüntüsünde örneği tanımayı kolaylaştırır. Bunları izleyen değerler çalışma sırasında rastgele üretilir. Tam parola kodda sabit olarak bulunmaz.
İlk iki uygulamanın “Demo verisini hazırla” düğmesi veriyi üretir DPAPI dosyaya yazar. hazırlama işlemi şifreleme olayı oluşturabilir. Kullanım anını karşılaştırırken hazırlama çözme olayını birbirine karıştırmamak gerekir.
İlk örnek: Çözülen veriyi bellekte bırakmakİlk uygulama dosyayı açtıktan sonra dönen bayt dizisini statik alanda saklar. Örnek işlemi diziyle yapar referansı korur. “Oturumu kapat” düğmesi alanı temizlemez.
Aldığımız kayıtta şifreleme çözme aşamalarını ayrı satırlarda gördük. CryptProtectData hazırlama işlemine, CryptUnprotectData ise saklanan verinin çözülmesine. Çözme çağrısında lab için üretilmiş LAB_SQL_ LAB_PFX_ değerlerini açık olarak görebildik.
Şekil 2: Örnek verinin açık hâli kriptografi çağrısında gözlemleniyor. kayıt tek başına verinin ne kadar süre bellekte kaldığını göstermez. davranışı oluşturan kodda retained alanına açık veri atanıyor. Ekran görüntüsünde 24 32. Satırlar arasında işlem çıkış düğmelerinin işleyicileri. Çıkış işleyicisi yalnızca mesaj yazıyor. retained alanına dokunmuyor. Daha aşağıdaki ayrı temizleme düğmesi ise ancak kullanıcı düğmeye basarsa çalışıyor.
Şekil 3: retained = vault.Open() açık veriyi saklıyor. Arayüzden çıkış yapmak alanı temizlemiyor. İlgili kodu metin olarak göster
private static byte[] retained;// İşlem düğmesindeki kod:retained = vault.Open();
SecretVault.SimulateUse(retained);
Buradaki vault.Open() DPAPI dosyayı çözer. SimulateUse() yalnızca sahte verinin baytlarını işleyen laboratuvar fonksiyonudur. Gerçek bağlantı açmaz.
Bellek taramasında veri bulunabilir. Ancak taramanın kapsamı nedeniyle bunun her çalıştırmada görünmesini garanti edemeyiz. Burada kullanım anındaki görünürlüğü çağrı kaydından, tamponun tutulmasını ise koddan ayırarak değerlendiriyoruz.
davranışın iyileştirilmesi gerekir. Gereksiz referansları kaldırmak sahip olunan tamponları temizlemek, verinin daha sonra bellek dökümünde veya hata incelemesinde görünme ihtimalini azaltabilir. Fakat sır uygulamanın kullanımına verilmeye devam ettiği sürece ikinci örnekteki sorun kalır.
İkinci örnek: “Anlık çözüp siliyoruz”İkinci uygulama açık veriyi uzun süre saklamaz. İşlem tamamlandığında, hata oluşsa bile sahip olduğu bayt dizisini temizler. Buna rağmen çözme çağrısındaki açık veri gözlemlenebilir.
Şekil 4: İkinci yakalamada SQL PFX biçimindeki sahte değerler çözme olayında görülebiliyor. Önceden alınan kayıt, hedefte sonradan yapılan temizlikten etkilenmiyor. İlgili kodda Open() veriyi çözüyor, UseBriefly() ise dönen diziyi yalnızca işlem boyunca kullanıyor. finally içindeki Array.Clear, uygulamanın sahip olduğu diziyi temizliyor. Açık verinin ortaya çıktığı çağrı temizlemeden önce gerçekleşiyor.
Şekil 5: ProtectedData.Unprotect veriyi açıyor. Array.Clear daha sonra diziyi temizliyor. Kullanım anındaki gözlemi geri almıyor. İlgili kodu metin olarak göster
byte[] plain = vault.Open(); try { SecretVault.SimulateUse(plain); } finally { Array.Clear(plain, 0, plain.Length); }sürüm ilkinden daha iyi bellek hijyeni uygular. Kodda özellikle bekleme yoktur. Sahte parola arayüze veya uygulama loguna yazılmaz, stringe dönüştürülmez.
Yine çözme çağrısı gerçekleşir. çağrıyı işlem başlamadan izlemeye aldığımızda, tampon temizlenmeden önceki veriyi görebildik. Hızlı bellek taramasıyla doğru ana denk gelmeye çalışmakla, çağrının dönüşünü gözlemlemek aynı yöntem değildir.
davranışı, aynı SecretVault kodunu kullanan ayrı test sürecinde doğruladık. Testte 194 baytlık örnek verinin CryptUnprotectData çağrısındaki açık hâlini kaydettik. SQL PFX işaretlerini gördük. İşlem döndüğünde uygulamanın sahip olduğu dizinin bütün baytlarının sıfır olduğunu kontrol ettik. Ham parola değerlerini doğrulama raporuna eklemedik.
ölçüm bütün bellek kopyalarının temizlendiğini iddia etmiyor. Doğruladığı şey daha dar: uygulamanın kendi tamponu temizlense bile çözme anındaki gözlem gerçekleşmişti.
yüzden “işlemden sonra sildik” cevabı, “ortak veritabanı parolasını son kullanıcıdan gizleyebiliyor muyuz?” sorusunu çözmez. Parolanın bellekte kalma süresi kısalmıştır. İstemciye verilmesi değişmemiştir.
SQL parolası neden daha farklı risk?Kullanıcının zaten görmeye yetkili olduğu ekran metniyle, bütün müşterilere erişebilen ortak veritabanı parolası aynı şekilde değerlendirilemez. İkinci durumda uygulamanın kendi ekranlarında koyduğu sınırların altında, daha geniş yetki bulunabilir.
Pentest değerlendirmesinde hesabın neye eriştiği, yetkilerinin kapsamı, veritabanına hangi ağlardan ulaşılabildiği hesabın kurulumlar arasında ılıp ılmadığı belirleyicidir. SQL biçiminde görünen her metin canlı hesap değildir. Sadece parola görüntüsünden bütün veritabanına erişim veya tam yetki sonucu çıkarılmaz.
Mimari izin veriyorsa ortak SQL hesabı masaüstü uygulamasından kaldırılmalıdır. Kullanıcı API’ye kendi kimliğiyle bağlanır. API her işlemde kullanıcının rolünü, ilgili kaydın sahibini kurum sınırını denetler. Veritabanı bağlantısı kontrollerin arkasında kurulur. Kullanıcıya SQL parolası gönderen API, sorunu yalnızca başka adıma taşır.
Microsoft’un public client açıklaması, masaüstüne dağıtılan uygulamaların uygulama sırlarını güvenilir biçimde saklayacağı varsayımına neden dayanılmaması gerektiğini anlatır.
Doğrudan veritabanı bağlantısının zorunlu olduğu eski sistemlerde ise kullanıcıya özgü Windows veya veritabanı kimliği, dar yetkiler veritabanı tarafında uygulanan erişim kuralları değerlendirilebilir. Kullanıcının kendi yetkisiyle sorgu çalıştırması tasarımın parçasıysa bunu yalnızca EXE içinde kontrol etmeye çalışmamak gerekir. Ortak geniş yetkili hesabı şifrelemek, yetki ayrımını oluşturmaz.
Üçüncü örnek: İstemciye sırrı vermemekÜçüncü uygulamanın koduna sır üreten veya çözen sınıf dahil edilmez. Buradaki değişiklik, parolanın istemciye verilmesini kaldırmaktır. Üretimde ayrım, kullanıcının denetimi dışındaki servis üzerinden kurulabilir.
Şekil 6: Üretim mimarisinde istemci yalnızca işlem ister. API yetkiyi denetler. Veritabanı erişimi veya imza işlemi sunucu tarafında yapılır. Lab istemcisi oturum alır kendi raporunu ister. Kodda SQL veya PFX parolasını almak için çağrı yoktur. Rapor isteği kullanıcı oturumuyla gönderilir.
Şekil 7: İstemci Protocol.Request rapor istiyor. SQL veya PFX parolası çözmüyor. İstemcideki rapor isteğini metin olarak göster
string response = Protocol.Request( "REPORT", sessionToken, "REPORT-MINE");Servis doğrulanmış Windows kimliğini, oturumu, işlem adını istenen örnek kaydı denetler. kontrollerden sonra kendi sürecindeki örnek işi yapar. Yanıtta yalnızca sabit örnek rapor bulunur. Parolayı döndüren işlem tanımlanmamıştır.
Şekil 8: Kontroller servis tarafında uygulanıyor. Örnek sır yalnızca servis işleminde kullanılıyor rapor yanıtına eklenmiyor. Labda “ raporu iste” düğmesi bulunur. isteğin servis tarafından reddedilmesi, arayüzde düğmenin gizlenmesinden farklıdır. Çıkış işleminde oturum servis tarafında kaldırılır. Eski tokenla yapılan sonraki istek reddedilir. Oturumların ayrıca iki dakikalık ömrü vardır.
labda kolay çalıştırılabilmesi için servis aynı bilgisayarda ayrı süreç olarak açılır iletişim named pipe üzerinden yapılır. düzen, istemciye neyin gönderildiğini göstermek içindir. Aynı kullanıcıyla çalışan yerel servis, makinenin yöneticisine veya aynı hesaptaki bütün süreçlere karşı uzak sunucu sınırı oluşturmaz. Lab protokolü üretime taşınacak hazır API değildir.
Gerçek çözümde servis kullanıcının denetimi dışındaki ortamda çalışır. Kullanıcı kimlik doğrulaması, güvenilir sunucu bağlantısı her istekte yetkilendirme gerekir. Masaüstü uygulamalarında uygun OAuth tasarımı için sistem tarayıcısı PKCE kullanan akışlar RFC 8252’ açıklanır. ele geçirilmiş masaüstü sürecini güvenilir hâle getirmez bütün token erişimini engellemez.
İstemcide artık hiç hassas veri olmadığı söylenemez. Kullanıcı oturumu erişebildiği rapor yine oradadır. Kazanım, son kullanıcı sürecinin ortak SQL veya PFX parolasını bilmemesidir. Kullanıcı oturumunun kapsamı, süresi iptali ayrıca yönetilir. JWT kullanan gerçek sistemlerde arayüzden çıkış yapmak veya refresh tokenı kaldırmak, verilmiş bütün access tokenları kendiliğinden anında geçersiz kılmaz. API’nin bunu nasıl uyguladığı ayrıca tasarlanmalıdır.
Sertifika parolası için ne değişiyor?“Sertifika parolası” derken hangi değerden bahsettiğimizi belirtmek gerekir. Sertifikanın herkese açık kısmı sır değildir. PFX dosyasının parolası, paketteki özel anahtar anahtarla işlem yapma yetkisi farklı şeylerdir.
Uygulama her açılışta PFX dosyasını parola içe aktarıyorsa, parolanın kullanılabildiği aşama vardır. PFX parolasını şifreli ayar dosyasına taşımak veya yalnızca içe aktarma sırasında çözmek aşamayı kaldırmaz. Labdaki PFX alanı yalnızca veri yaşam döngüsünü temsil. Gerçek PFX içe aktarma testi değildir.
Ortak kurumsal imza anahtarı söz konusuysa anahtarı istemcilere dağıtmak yerine sunucuda veya HSM’ tutmak değerlendirilebilir. Sunucu yalnızca izin verilen belge işlem türleri için imza üretmeli, talep eden kişinin yetkisini denetlemelidir. Her gelen veriyi imzalayan genel uç nokta, anahtar dışarı çıkmasa yanlış işlemlere imza atabilir.
İşlemin cihazda yapılması gerekiyorsa cihaza veya kullanıcıya özgü, mümkünse TPM içinde üretilen dışarı aktarılamayan anahtar tercih edilebilir. Böyle tasarımda uygulama PFX parolası taşıyarak anahtarı açmak yerine sağlayıcıya anahtarı kullanma isteği gönderir. TPM’nin taşınamaz anahtarlarının özel kısmının donanım dışında açığa çıkmaması Microsoft’un TPM belgesinde açıklanır.
Ancak anahtarın dışarı çıkarılamaması, kötüye kullanılamayacağı anlamına gelmez. Anahtarı kullanmaya yetkili sürecin ele geçirilmesi hâlinde yetkili işlemler suistimal edilebilir. Anahtar erişim izinleri, kullanım amacı, kullanıcı onayı gereken işlemler sunucu tarafındaki kabul kuralları önemini korur. Yazılımsal anahtara sadece “non-exportable” işareti koymayı TPM’ anahtar üretmekle eş tutmamak gerekir.
Uygulama incelendiğini fark edebilir ?Ortak sırrı istemciden kaldırmanın yanında, uygulamanın çalışma sırasında incelendiğine veya değiştirildiğine dair belirtileri değerlendirmek savunma katmanı olabilir. Frida gibi araçların süreç içine eklediği bileşenlere ait izler, beklenmeyen modüller kod bütünlüğündeki değişiklikler amaçla ele alınabilir. Hedef, hassas işlem başlamadan önce şüpheli durumu fark etmektir.
Debugger kontrolü Frida tespiti aynı şey değildir. Windows’taki IsDebuggerPresent, çağrıyı yapan sürecin kullanıcı modu debugger’ı altında çalışıp çalışmadığını bildirir. Sonucun olumsuz olması, süreçte çalışma zamanı incelemesi yapılmadığını kanıtlamaz. Fonksiyonun kapsamı Microsoft belgesinde açıklanır.
Yalnızca araç adına bakmak yerine birden fazla belirti birlikte değerlendirilebilir. Yüklenen modüllerin beklenen kaynaklardan gelmesi, kritik kodun bütünlüğü debugger durumu değerlendirmenin parçalarıdır. Antivirüs, erişilebilirlik veya performans izleme yazılımları uygulamayla etkileşime girebilir. Beklenmeyen her bileşeni saldırı saymak yanlış alarmlara yol açabilir.
Tespit sonrasında verilecek tepki tasarlanmalıdır. Riskli işlemi başlatmamak, ek kullanıcı doğrulaması istemek veya hassas veri içermeyen güvenlik kaydı oluşturmak düşünülebilir. Kullanıcının kaydedilmemiş verisini kaybettirecek ani kapanışlar yerine işlemle orantılı tepki tercih edilmelidir. Sunucu istemciden gelen “inceleme yok” mesajını tek başına güven kanıtı saymamalıdır.
kontrollerin kendisi kullanıcının denetimindeki süreçte çalışır. Değiştirilebilir veya devre dışı bırakılabilirler. Tespit, incelemenin maliyetini artırabilir fakat istemcide kullanılan ortak SQL parolasının gizliliğini garanti etmez. OWASP’ın mobil uygulamalar için hazırladığı MAS-R yaklaşımı korumaları temel güvenlik kontrollerini tamamlayan katman olarak ele. Aynı ayrımı masaüstü uygulamasında korumak gerekir.
yazıdaki laboratuvar, verinin kullanım anındaki görünürlüğünü karşılaştırıyor. Frida tespiti bütünlük kontrolleri örneklere eklenmedi. Bunları ayrı yazıda, tespit edilen durum verilen tepki üzerinden inceleyeceğiz.
Hangi önlem hangi sorunu çözüyor? ÖnlemSağladığı korumaÇözmediği noktaDPAPI doğru dosya izinleriSaklanan verinin korunmasıUygulamanın çözerek kullandığı anın gözlemlenmesiKısa bellek ömrü tampon temizliğiGereksiz kalıntıların azaltılmasıKullanım anında alınmış kopyaLog dump politikasının düzenlenmesiHassas verinin ikinci dosyalara yayılmasının azaltılmasıSırrın istemcide kullanılmasıFrida / debugger belirtileri bütünlük kontrolleriÇalışma zamanı müdahalesini fark etme incelemeyi zorlaştırmaİstemcide kullanılan sırrın gizliliğine kesin güvenceOrtak SQL hesabını uzak serviste tutmakOrtak sırrın istemciye dağıtılmasının kaldırılmasıAPI yetkilendirme hataları servis güvenliğiKullanıcıya özgü, sınırlı oturumBir oturumun etkisinin sınırlandırılmasıGeçerli oturumun kendi yetkileriyle kötüye kullanılmasıTPM veya HSM tabanlı anahtarUygun yapılandırmada özel anahtarın dışarı aktarılmasının engellenmesiYetkili anahtar kullanımının suistimaliBellek temizliği yine yapılmalıdır. Buradaki itiraz, onu bütün sorunun çözümü gibi sunmaya yöneliktir. Özellikle NET’te string referansını null yapmak, metnin bütün kopyalarını sıfırlamaz. Sabit metni ToCharArray() diziye çevirip diziyi temizlemek başlangıçtaki metni ortadan kaldırmaz.
NET Framework derlendiği için sahip olunan diziyi Array.Clear temizliyor. Uygun modern NET sürümlerinde kriptografik tamponlar için CryptographicOperations.ZeroMemory kullanılabilir. Hangi API seçilirse seçilsin, uygulamanın kontrol etmediği kopyalar daha önce gözlemlenen veri ayrıca düşünülmelidir. SecureString genel çözüm değildir. Microsoft yeni geliştirmelerde kullanılmasını önermiyor.
Pentest bulgusunu nasıl yazmalı?“Bellekte parola bulundu” gözlemdir. İyi bulgu bunun hangi güven sınırını etkilediğini açıklar. Ortak servis hesabının son kullanıcıya dağıtılması, çıkıştan sonra gereksiz kalıntı bırakılması bitmiş oturumun sunucuda geçerli kalması ayrı sorunlar olabilir.
Raporda verinin türü, uygulamanın hangi işlemi sırasında görüldüğü gözlem için gereken başlangıç yetkisi yer almalıdır. Yönetici yetkisiyle alınmış gözlemi standart kullanıcının erişimi gibi sunmamak gerekir. Aynı şekilde standart kullanıcının kendi istemcisinden, uygulamada kendisine tanınandan daha geniş hizmet yetkisi öğrenmesi “zaten kendi bilgisayarı” denilerek geçiştirilmemelidir.
SQL hesabında yetki ağ kapsamı değerlendirilir. PFX parolası için pakete erişim özel anahtarın kullanım amacı önemlidir. token için kullanıcı, kapsam geçerlilik süresine bakılır. Bulgunun önem derecesi görülen metne değil, koşulların oluşturduğu etkiye göre belirlenir.
Ekran görüntüsünde tam parola yerine maskeli örnek, işlem adı, zaman hedef PID yeterli olabilir. Labdaki değerler sahtir. Gerçek incelemede kaydedilen oturumlar dışa aktarılan dosyalar hassas veri içerebilir. Kanıt toplarken yeni sızıntı oluşturulmamalıdır.
laboratuvarda ikinci örneğin tamponu temizlendi, ancak kullanım anı yine gözlemlenebildi. Üçüncü örnekte değişen şey temizliğin hızı değildi: istemciye ortak servis parolası hiç verilmedi. Geliştirme sırasında verilecek temel karar budur. sırrı gerçekten son kullanıcının bilgisayarında kullanmak zorunda mıyız?
Sonraki yazısonraki yazının konusu “Uygulama İncelendiğini Fark Edebilir ? Frida Tespiti Çalışma Zamanı Bütünlüğü” olacak. Debugger kontrolünün neyi gösterdiğini, çalışma zamanı müdahalesine ait belirtileri yanlış alarm üretmeden nasıl tepki verilebileceğini ele alacağız.
