CTF Çözen Ama Bug Bulamayanların Yaptığı 9 Hata

Bu yazıda çoğu kişinin fark etmeden yaptığı 9 hatayı ele alıyoruz. Hazırsanız birlikte bakalım.

1-) Exploit Odaklı Bakıp Mantık Odaklı Bakmamak​

CTF çözmek hedefe götürmez; nasıl yürüneceğini öğretir.
CTF çözen birçok kişi gerçek sistemlere bakarken şu refleksle yaklaşıyor:
Burada hangi açık vardır ve nasıl exploit ederim?
Bu refleks CTF için doğru, ama real world için eksik bir yaklaşımdır.

CTF Bakış açısı şöyledir:
• Zaafiyet Kesin Vardır
• Beklenen şey o açığı bulup sömürmek
• Mantık zaten senaryoda gömülüdür
Yani payloadı deneyip bypass yapıp flag'i alırsın sorgulaman gerekmez.

Ancak gerçek hayatta işler böyle yürümez.
Gerçek uygulamada önce şu sorular sorulmalı:
• Bu feature neden var?
• Kullanıcı bu özelliği normalde nasıl kullanıyor?
• Yanlış / beklenmeyen kullanım mümkün mü?
• Backend gerçekten bunu kontrol ediyor mu?
CTF alışkanlığı olan biri bu soruları sormadan direkt payload’a giriyor.

2-) Hızlı Sonuç Beklentisi​

CTF refleksi şudur:
→ hızlı çöz, flag al, geç.

Gerçek hayatta ise bug’lar tekrar tekrar bakınca aynı yeri farklı açıdan kurcalayınca küçük tutarsızlıklar kovalanınca çıkar.

Birçok kişi 10–15 dakika bakıp “Burada bir şey yok” diyerek geçiyor.
Oysa real bug, ilk bakışta değil, ikinci–üçüncü bakışta yakalanır.

CTF hız kazandırır.
Bug Bounty sabır ister.
Hızlı olan flag alır.
Sabırlı olan report yazar.

3-) Frontend’e Fazla Güvenmek​

Gerçek sistemlerde frontend çoğu zaman yanıltıcıdır.
Butonun gizli olması, input’un disabled olması ya da “yetkin yok” yazması
backend’de gerçekten kontrol olduğu anlamına gelmez.

CTF alışkanlığı olan birçok kişi:
UI ne diyorsa ona inanır
"buradan olmaz” deyip geçer
Oysa real bug’lar genelde tam burada çıkar.

Frontend engelliyorsa, backend’i dene.
UI kapatıyorsa, request’i elle gönder.

4-) Tek Kullanıcıyla Test Yapmak​

CTF'lerde genelde tek rol vardır.
Bu da insanı fark etmeden “benim gördüğüm şey herkes için aynıdır” düşüncesine iter.
Gerçek sistemlerde ise aynı endpoint farklı kullanıcılar için bambaşka sonuçlar döndürebilir.
Özellikle kullanıcılar arası veri erişimi ve yetki farkları test edilmeden yapılan kontroller eksik kalır.


Gerçek hayatta:
aynı endpoint,
farklı kullanıcı,
farklı rol bambaşka sonuçlar döndürebilir.

Bir request’i başka bir user ile farklı yetkideki bir hesapla tekrar göndermeden test bitmiş sayılmaz. IDOR ve Privilege Escalation’ın çoğu burada çıkar.

5-) Request–Response’u Yeterince Kurcalamamak​

Birçok kişi request’i Burp’ta görür ama gerçekten dokunmaz. Oysa parametre silme, değer bozma ya da ekstra alan ekleme gibi küçük oynamalar ciddi sonuçlar doğurabilir.
Response tarafında dönen gereksiz alanlar ya da beklenmeyen bilgiler çoğu zaman bug’ın ilk sinyalidir.
Request–response’u kurcalamadan yapılan testler genelde yüzeyde kalır.

Birçok kişi request’i Burp’ta görür, ama gerçekten dokunmaz. Oysa bug’lar genelde burada saklanır:

• Parametreyi silince
• Ekstra parametre ekleyince
• Değeri bozunca
• Null / boş gönderince
Normal çalışıyor diye geçen request, anormal gönderildiğinde çöker.


Real bug:
düzgün giden akışta değil
bozulan akışta ortaya çıkar.

6-) Her Şeyi Tool’a Bırakmak​

Araçlar hızlıdır ama düşünmez. Bir tool açık bulamadığında çoğu kişi orayı tamamen kapatır. Oysa birçok yetki ve mantık hatası otomasyonla yakalanamaz. Tool’lar destek olur ama bug’u bulan yine test eden kişidir.​

Araçlar tarar. Ama düşünmez.
Otomasyon: bağlamı anlamaz mantık hatasını fark etmez. Tool sonuç vermezse "burada açık yok” demek en büyük yanılgı.

!!! Tool yardımcıdır. Bug’u bulan beyin.

7-) State / Akış Takibi Yapmamak​

Gerçek uygulamalar çoğu zaman belirli adımlar ve durumlar üzerinden ilerler. Bu adımların sırası bozulduğunda ya da biri atlandığında sistem beklenmedik davranabilir.​

CTF alışkanlığı olan kişiler genelde akışı bozmayı denemez. Halbuki en kritik business logic açıkları tam burada ortaya çıkar.
Birçok uygulama: adım adım ilerlemen gereken, state tutan yarım bırakılabilen akışlara sahiptir.

CTF refleksiyle:
• Adımlar sırasıyla geçilir,
• Geri dönülmez,
• Akış bozulmaz.

Gerçek hayatta ise:
• Adım atlanabilir
• İşlem tekrarlanabilir
• Süreç yarım bırakılabilir

İşte business logic bug’lar tam burada doğar.

Client-side validation’a takılı kalmak​

Frontend’de yapılan kontroller çoğu zaman sadece kullanıcıyı yönlendirmek içindir.
JavaScript’in engellediği bir işlem backend’de serbest bırakılmış olabilir.
Bu yüzden client tarafında “olmaz” denilen her şey backend tarafında tekrar denenmelidir.

JavaScript “olmaz” diyorsa, backend’e sor. Format, length, zorunlu alan kontrolleri çoğu zaman sadece client tarafındadır.
+ Client engelliyorsa, request’i elle gönder.

9-) Sadece OWASP Top 10 kafasıyla bakmak​

OWASP Top 10 iyi bir başlangıçtır ama tek başına yeterli değildir.
Her uygulamanın kendine özgü iş mantığı ve edge case’leri vardır.
Checklist mantığıyla ilerlemek, uygulamaya özel açıkların gözden kaçmasına sebep olur.
Gerçek bug’lar çoğu zaman OWASP başlıklarının dışında çıkar.

!OWASP Top 10 önemlidir ama checklist değildir.!

Gerçek uygulamalar:
özel iş mantığına,
kendine özgü akışlara,
beklenmeyen edge case’lere sahiptir.

Sadece “burada XSS yok, SQLi yok” demek testin bittiği anlamına gelmez. Real bug’lar çoğu zaman OWASP dışında çıkar.


-------------------------------------------------------------------------
Buraya kadar okuduysan teşekkür ederim. Umarım anlatılanlar sana yeni bir bakış açısı kazandırmıştır.

Asıl mesele flag değil; yaklaşım.
Fikirlerini aşağıya bırak, birlikte yükselelim.

Kaan_2357' Alıntı:

Bu yazıda çoğu kişinin fark etmeden yaptığı 9 hatayı ele alıyoruz. Hazırsanız birlikte bakalım.

1-) Exploit Odaklı Bakıp Mantık Odaklı Bakmamak​

CTF çözmek hedefe götürmez; nasıl yürüneceğini öğretir.
CTF çözen birçok kişi gerçek sistemlere bakarken şu refleksle yaklaşıyor:
Burada hangi açık vardır ve nasıl exploit ederim?
Bu refleks CTF için doğru, ama real world için eksik bir yaklaşımdır.

CTF Bakış açısı şöyledir:
• Zaafiyet Kesin Vardır
• Beklenen şey o açığı bulup sömürmek
• Mantık zaten senaryoda gömülüdür
Yani payloadı deneyip bypass yapıp flag'i alırsın sorgulaman gerekmez.

Ancak gerçek hayatta işler böyle yürümez.
Gerçek uygulamada önce şu sorular sorulmalı:
• Bu feature neden var?
• Kullanıcı bu özelliği normalde nasıl kullanıyor?
• Yanlış / beklenmeyen kullanım mümkün mü?
• Backend gerçekten bunu kontrol ediyor mu?
CTF alışkanlığı olan biri bu soruları sormadan direkt payload’a giriyor.

2-) Hızlı Sonuç Beklentisi​

CTF refleksi şudur:
→ hızlı çöz, flag al, geç.

Gerçek hayatta ise bug’lar tekrar tekrar bakınca aynı yeri farklı açıdan kurcalayınca küçük tutarsızlıklar kovalanınca çıkar.

Birçok kişi 10–15 dakika bakıp “Burada bir şey yok” diyerek geçiyor.
Oysa real bug, ilk bakışta değil, ikinci–üçüncü bakışta yakalanır.

CTF hız kazandırır.
Bug Bounty sabır ister.
Hızlı olan flag alır.
Sabırlı olan report yazar.

3-) Frontend’e Fazla Güvenmek​

Gerçek sistemlerde frontend çoğu zaman yanıltıcıdır.
Butonun gizli olması, input’un disabled olması ya da “yetkin yok” yazması
backend’de gerçekten kontrol olduğu anlamına gelmez.

CTF alışkanlığı olan birçok kişi:
UI ne diyorsa ona inanır
"buradan olmaz” deyip geçer
Oysa real bug’lar genelde tam burada çıkar.

Frontend engelliyorsa, backend’i dene.
UI kapatıyorsa, request’i elle gönder.

4-) Tek Kullanıcıyla Test Yapmak​

CTF'lerde genelde tek rol vardır.
Bu da insanı fark etmeden “benim gördüğüm şey herkes için aynıdır” düşüncesine iter.
Gerçek sistemlerde ise aynı endpoint farklı kullanıcılar için bambaşka sonuçlar döndürebilir.
Özellikle kullanıcılar arası veri erişimi ve yetki farkları test edilmeden yapılan kontroller eksik kalır.


Gerçek hayatta:
aynı endpoint,
farklı kullanıcı,
farklı rol bambaşka sonuçlar döndürebilir.

Bir request’i başka bir user ile farklı yetkideki bir hesapla tekrar göndermeden test bitmiş sayılmaz. IDOR ve Privilege Escalation’ın çoğu burada çıkar.

5-) Request–Response’u Yeterince Kurcalamamak​

Birçok kişi request’i Burp’ta görür ama gerçekten dokunmaz. Oysa parametre silme, değer bozma ya da ekstra alan ekleme gibi küçük oynamalar ciddi sonuçlar doğurabilir.
Response tarafında dönen gereksiz alanlar ya da beklenmeyen bilgiler çoğu zaman bug’ın ilk sinyalidir.
Request–response’u kurcalamadan yapılan testler genelde yüzeyde kalır.

Birçok kişi request’i Burp’ta görür, ama gerçekten dokunmaz. Oysa bug’lar genelde burada saklanır:

• Parametreyi silince
• Ekstra parametre ekleyince
• Değeri bozunca
• Null / boş gönderince
Normal çalışıyor diye geçen request, anormal gönderildiğinde çöker.


Real bug:
düzgün giden akışta değil
bozulan akışta ortaya çıkar.

6-) Her Şeyi Tool’a Bırakmak​

Araçlar hızlıdır ama düşünmez. Bir tool açık bulamadığında çoğu kişi orayı tamamen kapatır. Oysa birçok yetki ve mantık hatası otomasyonla yakalanamaz. Tool’lar destek olur ama bug’u bulan yine test eden kişidir.​

Araçlar tarar. Ama düşünmez.
Otomasyon: bağlamı anlamaz mantık hatasını fark etmez. Tool sonuç vermezse "burada açık yok” demek en büyük yanılgı.

!!! Tool yardımcıdır. Bug’u bulan beyin.

7-) State / Akış Takibi Yapmamak​

Gerçek uygulamalar çoğu zaman belirli adımlar ve durumlar üzerinden ilerler. Bu adımların sırası bozulduğunda ya da biri atlandığında sistem beklenmedik davranabilir.​

CTF alışkanlığı olan kişiler genelde akışı bozmayı denemez. Halbuki en kritik business logic açıkları tam burada ortaya çıkar.
Birçok uygulama: adım adım ilerlemen gereken, state tutan yarım bırakılabilen akışlara sahiptir.

CTF refleksiyle:
• Adımlar sırasıyla geçilir,
• Geri dönülmez,
• Akış bozulmaz.

Gerçek hayatta ise:
• Adım atlanabilir
• İşlem tekrarlanabilir
• Süreç yarım bırakılabilir

İşte business logic bug’lar tam burada doğar.

Client-side validation’a takılı kalmak​

Frontend’de yapılan kontroller çoğu zaman sadece kullanıcıyı yönlendirmek içindir.
JavaScript’in engellediği bir işlem backend’de serbest bırakılmış olabilir.
Bu yüzden client tarafında “olmaz” denilen her şey backend tarafında tekrar denenmelidir.

JavaScript “olmaz” diyorsa, backend’e sor. Format, length, zorunlu alan kontrolleri çoğu zaman sadece client tarafındadır.
+ Client engelliyorsa, request’i elle gönder.

9-) Sadece OWASP Top 10 kafasıyla bakmak​

OWASP Top 10 iyi bir başlangıçtır ama tek başına yeterli değildir.
Her uygulamanın kendine özgü iş mantığı ve edge case’leri vardır.
Checklist mantığıyla ilerlemek, uygulamaya özel açıkların gözden kaçmasına sebep olur.
Gerçek bug’lar çoğu zaman OWASP başlıklarının dışında çıkar.

!OWASP Top 10 önemlidir ama checklist değildir.!

Gerçek uygulamalar:
özel iş mantığına,
kendine özgü akışlara,
beklenmeyen edge case’lere sahiptir.

Sadece “burada XSS yok, SQLi yok” demek testin bittiği anlamına gelmez. Real bug’lar çoğu zaman OWASP dışında çıkar.


-------------------------------------------------------------------------
Buraya kadar okuduysan teşekkür ederim. Umarım anlatılanlar sana yeni bir bakış açısı kazandırmıştır.

Asıl mesele flag değil; yaklaşım.
Fikirlerini aşağıya bırak, birlikte yükselelim.

Genişletmek için tıkla ...

business logicler sqlden daha zevkli ama tek basina low priority getirir harmanlamak lazim ellerine saglik

berkayeacar00' Alıntı:

business logicler sqlden daha zevkli ama tek basina low priority getirir harmanlamak lazim ellerine saglik

Genişletmek için tıkla ...

Kesinlikle katılıyorum hocam Business logic tek başına bazen low görünebiliyor ama doğru yerde doğru primitive ile çok rahat high/criticala dönebiliyor.
Zaten tam anlatmak istediğim de buydu checklist değil, sistemi bir bütün olarak okumak. SQLi, XSS gibi klasikler hala altın değerinde ama çoğu gerçek vakada iş mantığı hatalarıyla zincirlenince asıl etki ortaya çıkıyor.
Teşekkürler yorum için

Güzeldi eyw hocam

Eline sağlık hocam, fakat CTF'nin hangi sistemin içinde gömülü olduğu da ayrı bir söz konusudur, geçen Whitelist yoluyla aldığım özel bir cybersecurity agent'in içinde gizli bir CTF buldum, tamamen kapalı container içindeki sistem den internal network analiz ile host makinesine ulaştım, tamamen random 3 tane flag yakaladım ve yapay zekayı kendi kendine çöktürdüm, model epey ileri bir sürüm fakat anlamadığım şey gizli flagler ne alaka mail attım iş teklifi geldi,

Diyebileceğim şey CTF her zaman "BURDA FLAG VAR, HEMEN YAKALAA" diye bağırmaktan ziyade, aslında real world dediğimiz yerlerdeki kimsenin bilmediği CTF'ler.

Kaan_2357' Alıntı:

Bu yazıda çoğu kişinin fark etmeden yaptığı 9 hatayı ele alıyoruz. Hazırsanız birlikte bakalım.

1-) Exploit Odaklı Bakıp Mantık Odaklı Bakmamak​

CTF çözmek hedefe götürmez; nasıl yürüneceğini öğretir.
CTF çözen birçok kişi gerçek sistemlere bakarken şu refleksle yaklaşıyor:
Burada hangi açık vardır ve nasıl exploit ederim?
Bu refleks CTF için doğru, ama real world için eksik bir yaklaşımdır.

CTF Bakış açısı şöyledir:
• Zaafiyet Kesin Vardır
• Beklenen şey o açığı bulup sömürmek
• Mantık zaten senaryoda gömülüdür
Yani payloadı deneyip bypass yapıp flag'i alırsın sorgulaman gerekmez.

Ancak gerçek hayatta işler böyle yürümez.
Gerçek uygulamada önce şu sorular sorulmalı:
• Bu feature neden var?
• Kullanıcı bu özelliği normalde nasıl kullanıyor?
• Yanlış / beklenmeyen kullanım mümkün mü?
• Backend gerçekten bunu kontrol ediyor mu?
CTF alışkanlığı olan biri bu soruları sormadan direkt payload’a giriyor.

2-) Hızlı Sonuç Beklentisi​

CTF refleksi şudur:
→ hızlı çöz, flag al, geç.

Gerçek hayatta ise bug’lar tekrar tekrar bakınca aynı yeri farklı açıdan kurcalayınca küçük tutarsızlıklar kovalanınca çıkar.

Birçok kişi 10–15 dakika bakıp “Burada bir şey yok” diyerek geçiyor.
Oysa real bug, ilk bakışta değil, ikinci–üçüncü bakışta yakalanır.

CTF hız kazandırır.
Bug Bounty sabır ister.
Hızlı olan flag alır.
Sabırlı olan report yazar.

3-) Frontend’e Fazla Güvenmek​

Gerçek sistemlerde frontend çoğu zaman yanıltıcıdır.
Butonun gizli olması, input’un disabled olması ya da “yetkin yok” yazması
backend’de gerçekten kontrol olduğu anlamına gelmez.

CTF alışkanlığı olan birçok kişi:
UI ne diyorsa ona inanır
"buradan olmaz” deyip geçer
Oysa real bug’lar genelde tam burada çıkar.

Frontend engelliyorsa, backend’i dene.
UI kapatıyorsa, request’i elle gönder.

4-) Tek Kullanıcıyla Test Yapmak​

CTF'lerde genelde tek rol vardır.
Bu da insanı fark etmeden “benim gördüğüm şey herkes için aynıdır” düşüncesine iter.
Gerçek sistemlerde ise aynı endpoint farklı kullanıcılar için bambaşka sonuçlar döndürebilir.
Özellikle kullanıcılar arası veri erişimi ve yetki farkları test edilmeden yapılan kontroller eksik kalır.


Gerçek hayatta:
aynı endpoint,
farklı kullanıcı,
farklı rol bambaşka sonuçlar döndürebilir.

Bir request’i başka bir user ile farklı yetkideki bir hesapla tekrar göndermeden test bitmiş sayılmaz. IDOR ve Privilege Escalation’ın çoğu burada çıkar.

5-) Request–Response’u Yeterince Kurcalamamak​

Birçok kişi request’i Burp’ta görür ama gerçekten dokunmaz. Oysa parametre silme, değer bozma ya da ekstra alan ekleme gibi küçük oynamalar ciddi sonuçlar doğurabilir.
Response tarafında dönen gereksiz alanlar ya da beklenmeyen bilgiler çoğu zaman bug’ın ilk sinyalidir.
Request–response’u kurcalamadan yapılan testler genelde yüzeyde kalır.

Birçok kişi request’i Burp’ta görür, ama gerçekten dokunmaz. Oysa bug’lar genelde burada saklanır:

• Parametreyi silince
• Ekstra parametre ekleyince
• Değeri bozunca
• Null / boş gönderince
Normal çalışıyor diye geçen request, anormal gönderildiğinde çöker.


Real bug:
düzgün giden akışta değil
bozulan akışta ortaya çıkar.

6-) Her Şeyi Tool’a Bırakmak​

Araçlar hızlıdır ama düşünmez. Bir tool açık bulamadığında çoğu kişi orayı tamamen kapatır. Oysa birçok yetki ve mantık hatası otomasyonla yakalanamaz. Tool’lar destek olur ama bug’u bulan yine test eden kişidir.​

Araçlar tarar. Ama düşünmez.
Otomasyon: bağlamı anlamaz mantık hatasını fark etmez. Tool sonuç vermezse "burada açık yok” demek en büyük yanılgı.

!!! Tool yardımcıdır. Bug’u bulan beyin.

7-) State / Akış Takibi Yapmamak​

Gerçek uygulamalar çoğu zaman belirli adımlar ve durumlar üzerinden ilerler. Bu adımların sırası bozulduğunda ya da biri atlandığında sistem beklenmedik davranabilir.​

CTF alışkanlığı olan kişiler genelde akışı bozmayı denemez. Halbuki en kritik business logic açıkları tam burada ortaya çıkar.
Birçok uygulama: adım adım ilerlemen gereken, state tutan yarım bırakılabilen akışlara sahiptir.

CTF refleksiyle:
• Adımlar sırasıyla geçilir,
• Geri dönülmez,
• Akış bozulmaz.

Gerçek hayatta ise:
• Adım atlanabilir
• İşlem tekrarlanabilir
• Süreç yarım bırakılabilir

İşte business logic bug’lar tam burada doğar.

Client-side validation’a takılı kalmak​

Frontend’de yapılan kontroller çoğu zaman sadece kullanıcıyı yönlendirmek içindir.
JavaScript’in engellediği bir işlem backend’de serbest bırakılmış olabilir.
Bu yüzden client tarafında “olmaz” denilen her şey backend tarafında tekrar denenmelidir.

JavaScript “olmaz” diyorsa, backend’e sor. Format, length, zorunlu alan kontrolleri çoğu zaman sadece client tarafındadır.
+ Client engelliyorsa, request’i elle gönder.

9-) Sadece OWASP Top 10 kafasıyla bakmak​

OWASP Top 10 iyi bir başlangıçtır ama tek başına yeterli değildir.
Her uygulamanın kendine özgü iş mantığı ve edge case’leri vardır.
Checklist mantığıyla ilerlemek, uygulamaya özel açıkların gözden kaçmasına sebep olur.
Gerçek bug’lar çoğu zaman OWASP başlıklarının dışında çıkar.

!OWASP Top 10 önemlidir ama checklist değildir.!

Gerçek uygulamalar:
özel iş mantığına,
kendine özgü akışlara,
beklenmeyen edge case’lere sahiptir.

Sadece “burada XSS yok, SQLi yok” demek testin bittiği anlamına gelmez. Real bug’lar çoğu zaman OWASP dışında çıkar.


-------------------------------------------------------------------------
Buraya kadar okuduysan teşekkür ederim. Umarım anlatılanlar sana yeni bir bakış açısı kazandırmıştır.

Asıl mesele flag değil; yaklaşım.
Fikirlerini aşağıya bırak, birlikte yükselelim.

Genişletmek için tıkla ...

Oldukça ufuk açan bir yazı tebrik ederim hocam. Elinize sağlık

3gi3' Alıntı:

Eline sağlık hocam, fakat CTF'nin hangi sistemin içinde gömülü olduğu da ayrı bir söz konusudur, geçen Whitelist yoluyla aldığım özel bir cybersecurity agent'in içinde gizli bir CTF buldum, tamamen kapalı container içindeki sistem den internal network analiz ile host makinesine ulaştım, tamamen random 3 tane flag yakaladım ve yapay zekayı kendi kendine çöktürdüm, model epey ileri bir sürüm fakat anlamadığım şey gizli flagler ne alaka mail attım iş teklifi geldi,

Diyebileceğim şey CTF her zaman "BURDA FLAG VAR, HEMEN YAKALAA" diye bağırmaktan ziyade, aslında real world dediğimiz yerlerdeki kimsenin bilmediği CTF'ler.

Genişletmek için tıkla ...

Teşekkür ederim hocam, güzel örnek olmuş.
Aslında tam olarak vurgulamak istediğim noktaya değiniyorsunuz: CTF her zaman “FLAG BURADA GEL AL” diye bağırmaz, bazı senaryolar gerçek hayata çok yakın tasarlanabiliyor. Benim derdim CTF leri küçümsemek değil aksine çok şey kazandırıyorlar. Ancak birçok kişinin her sistemde kesin flag vardır varsayımıyla hızlı payload denemeye geçmesi real world de yanıltıcı olabiliyor.
Real world’de fark yaratan şey payload ezberlemekten ziyade uygulamayı ve altyapıyı bütün olarak analiz etmek, akışları bozmak ve sistemin varsayımlarını sorgulamak. Yani mesele “CTF vs Bug Bounty” değil CTF den gelen refleksleri gerçek sistem bakış açısıyla birleştirebilmek.
Bahsettiğiniz örnek de bunu güzel gösteriyor, bu arada iş teklifi kısmı da senaryonun gerçek rewardu olmuş tebrikler.