Bugünün planı (3 saat)

Öğrenme çıktıları: ÖÇ.1 (zafiyetleri tanır ve sınıflandırır) · ÖÇ.5 (güvenli tasarım ilkeleriyle yazılım planı oluşturur)

Bu derse nasıl başlıyoruz

• Bu, dersin ilk haftası; önceki bir haftaya dayanmıyoruz.
• Varsayılan ön bilgi: C'de fonksiyon, dizi, işaretçi; terminalde cd, ls (PowerShell ya da Linux).
• Aşağıdaki "Bu haftanın kavramları" tablosu, bu haftanın terimlerini birer cümleyle tanımlamak yerine, her birinin hangi bölümde öğretileceğini gösterir.
• Dönem boyunca izleyeceğimiz kalıp: hatalı kod → saldırı → düzeltme.

Demolar nasıl çalışıyor?

• Tek kaynak, iki/üç ortam: Windows (Visual Studio 2022 Community ya da PowerShell), WSL ve Linux
• Derle: Windows .\build.ps1 · WSL/Linux ./build.sh — dersten önce bir kez derleyin
• Çalıştır: Windows .\demo.ps1 · WSL/Linux sh demo.sh
• Visual Studio: Dosya > Aç > Klasör → code → yapılandırma Windows (MSVC) → Derle > Tümünü Derle
• Bu hafta 4 demo: code/week-01 altında

⚠️ Etik: Bütün demolar yalnız kendi klasöründe çalışır, yönetici yetkisi istemez. Teknikleri yalnız kendi bilgisayarınızda deneyin.

Güvenli programlamanın beş kararı — şema

Ders nasıl yürüyor?

• Tek dönem projesi: C/C++ uygulaması + "sertifikasyondan geçecekmiş gibi" bir güvenlik kılavuzu
  • Vize kontrolü: 7. hafta gösterim · Final kontrolü: 15. hafta gösterim
• İki quiz: 8. hafta (1–6) · 16. hafta (9–14)
• Not: Vize = 0,6·Proje1 + 0,4·Quiz1 · Final = 0,7·Proje2 + 0,3·Quiz2
• Her hafta: hatalı kod → saldırı → düzeltme

⚠️ Etik: Teknikleri yalnız kendi bilgisayarınızda ve verilen demolar üzerinde deneyin.

Kasa benzetmesi

Tehdit · zafiyet · varlık — şema

Güvenliğin üç hedefi: CIA

+ Kimlik doğrulama · Yetkilendirme · İnkâr edilemezlik

Soru: Bankacılık uygulaması bakiyeyi şifresiz yazıyor → ? · Alıcı IBAN yolda değişiyor → ? · Bayram gecesi çöküyor → ?

CIA üçlüsü — şema

Sorunun cevabı: bakiye şifresiz → C; IBAN yolda değişiyor → I; bayram gecesi çöküyor → A.

CIA üçlüsü — tipik önlemler ve komşu kavramlar

+ Kimlik doğrulama: sen gerçekten o musun? · Yetkilendirme: bunu yapmaya iznin var mı? · İnkâr edilemezlik: bunu kim yaptı, sonradan inkâr edebilir mi?

Hata ≠ zafiyet, ama…

Güvenlik açıklarının çok büyük kısmı sıradan yazılım hatalarıdır.

Heartbleed (2014, CVE-2014-0160)

• İstemci: "Bana 64 KB geri yolla" — ama yalnız birkaç bayt gönderir
• Sunucu uzunluğu denetlemez → komşu belleği (parolalar, anahtarlar) geri yollar
• Tek bir eksik uzunluk denetimi → internetin önemli bir kısmı etkilendi

Saldırgan kim, neye erişebiliyor?

Bu dersin farkı: program saldırganın cihazında çalışıyorsa ne yaparız?

Beyaz kutu / MATE

• MATE (Man-At-The-End): programa sahip saldırgan.
• Kodu okur, belleği görür, değiştirir.
• Mobil/masaüstü uygulamanın gerçek durumu (bu dersin ana teması).

Saldırgan modelleri — şema

Saldırganlar — gerçek hayattan örnek

Her satırı kendi projenize uygulayın: sizin saldırganınız hangisi?

Saltzer ve Schroeder ilkeleri — şema

Katmanlı savunma

• Katmanlı savunma (defense in depth): tek önlem değil, birçok önlem.
• Biri aşılırsa diğeri durdurur.
• "Güvenlik kabuğu" bu katmanların birleşimi.

Neden tek bir önlem yetmez?

➡️ Her katman bir öncekinin açığını kapatır; saldırgan hepsini aynı anda aşmalı

Güvenlik kabuğu: katmanların birleştiği yer

Hassas bir anahtar aynı anda birkaç katmanın içinde taşınır:

1. Diskte şifreli durur
2. Yalnız kullanılacağı an, yalnız gerektiği kadar çözülür
3. Çözüldüğü kod bölümü gizlenmiş ve bütünlüğü denetlenmiş
4. Süreçte hata ayıklayıcı denetimi çalışıyor

➡️ 3. haftada dört kabuklu bir tasarımı adım adım kuracağız

⚠️ Gizleme doğru kodun yerine geçmez

• Gizleme saldırganı yavaşlatır, hatayı düzeltmez
• Gizlenmiş bir taşma hâlâ bir taşmadır
• Dış katmanlar ancak iç katmanlar sağlamsa anlam kazanır

Sunucu, istemciye asla güvenmez. Gizlenmiş istemci bile sunucuya tutarsız veri gönderebilir.

Ödünleşim (trade-off)

• Her koruma bir bedel getirir: hız, karmaşıklık, maliyet.
• Güvenlik "sonsuz koruma" değil, dengeli koruma.
• Kalan riski açıkça yazarız.

Korumanın bedeli

➡️ Her önlem gerekçesiyle yazılır: şu varlığı, şu saldırgana karşı, şu maliyetle

Değerlendirici tabloyu tersten okur

1. Dize taraması → anahtar, URL, hata iletisi görünüyor mu?
2. Binary dosyayı açma → mantık okunuyor mu?
3. Hata ayıklayıcı bağlama → program fark ediyor mu?
4. Kodu değiştirme → bütünlük denetimi yakalıyor mu?
5. Bellek dökümü → sır bulunuyor mu?

Durdurulmadığı her adım raporda bir bulgu olur

Kendini dene (3 dk)

1. Çevrimdışı parola yöneticisi için saldırgan modeli nedir? Hangi katmanlar önemli?
2. "Sunucuda çalışıyor, gizlemeye gerek yok" — ne zaman doğru, ne zaman yanlış?
3. Yalnız gizleme kullanan bir oyunda hangi yol açık kalır?

Tehdit modelleme

• Tehdit modelleme: "neyi, kime karşı, nasıl koruyacağız?" sorusunu sistemli yanıtlamak.
• Varlıkları, tehditleri, önlemleri listeler.
• Bugün STRIDE ve saldırı ağaçlarıyla yapacağız.

Uygulama koruma planı: 7 adım

1. Kapsam — Neyi koruyoruz? Hangi binary, hangi sürüm, hangi özet?
2. Mimari ve arayüzler — Kim kiminle, hangi kanaldan konuşuyor?
3. Varlıklar — Nerede durur, ne zaman silinir, C mi I mı?
4. Tehditler — Saldırgan kim, varlığa hangi yoldan ulaşır?
5. Karşı önlemler — Hangi katman, hangi önlem?
6. Doğrulama — Çalıştığı nasıl kanıtlanıyor?
7. Kalan risk — Kabul edilenler ve nedenleri

→ Sertifikasyonda bu plan yüzlerce sayfalık bir güvenlik kılavuzudur. Siz projede 20–30 sayfalık sürümünü yazacaksınız.

Adım 1 detay: Kapsam

Soru: Neyi değerlendiriyoruz?

• Yalnız "sürüm 2.1" demek yetmez
• Hangi binary dosya, hangi kaynak kod, hangi özet (hash) değeri?
• Sertifikasyonda buna değerlendirme hedefi denir

Adım 2 detay: Mimari ve arayüzler

Soru: Bileşenler neler, nasıl konuşuyor?

• Bileşenler nelerdir?
• Birbirleriyle hangi kanaldan konuşuyorlar?
• Her kanalda kimlik nasıl doğrulanıyor?

Adım 3 detay: Varlıklar

Soru: Korunacak veri nerede, ne zaman?

• Korunacak her veri tek tek listelenir
• Nerede durur, ne zaman oluşur, ne zaman silinir?
• Gizlilik (C) mi, bütünlük (I) mü gerekir?

Adım 4 detay: Tehditler

Soru: Saldırgan kim, nasıl ulaşır?

• Saldırgan kim? (bkz. saldırgan modelleri)
• Her varlığa hangi yoldan ulaşabilir?
• STRIDE ve saldırı ağacı burada devreye girer

Adım 5 detay: Karşı önlemler

Soru: Hangi önlem, hangi katmanda?

• Her tehdit için bir önlem seçilir
• Önlem, yedi katmandan hangisine ait?
• Gerekçesiz önlem = yanlış yerde ya da gereksiz

Adım 6 detay: Doğrulama

Soru: Çalıştığı nasıl kanıtlanıyor?

• Her önlem için bir test yazılır
• Birim testi mi, atlatma denemesi mi?
• Testi olmayan önlem, değerlendirici gözünde yoktur

Adım 7 detay: Kalan risk

Soru: Neyi bilerek kabul ettik?

• Kapatılamayan ya da bilerek kabul edilen riskler
• Her biri için neden (ör. performans, kullanılabilirlik)
• Plan bitmez: ürün değiştikçe adım 1'e dönülür ve güncellenir

Koruma planı — şema

STRIDE

Veri akış diyagramını çiz → güven sınırını geçen her ok için altı harfi sor.

Örnek sistem

Bir mobil bankacılık uygulaması:

• kullanıcı girişi
• bakiye görüntüleme
• para transferi

Her STRIDE harfini bu sisteme uygulayalım.

S · Spoofing (sahtecilik)

• Tehdit: başkası gibi davranmak (sahte kullanıcı/sunucu).
• Örnek: sahte sunucu, çalınan oturum.
• Önlem: güçlü kimlik doğrulama, TLS + sertifika denetimi.

T · Tampering (kurcalama)

• Tehdit: veriyi/kodu izinsiz değiştirmek.
• Örnek: transfer tutarını değiştirmek.
• Önlem: bütünlük (MAC/imza), bütünlük denetimi (RASP).

R · Repudiation (inkâr)

• Tehdit: yaptığını inkâr etmek.
• Örnek: "ben o transferi yapmadım".
• Önlem: güvenli günlük, imza, denetim izi.

I · Information disclosure (bilgi sızması)

• Tehdit: gizli verinin sızması.
• Örnek: bakiye/parola sızıntısı.
• Önlem: şifreleme, en az yetki, sızıntısız hata iletisi.

D · Denial of service (hizmet reddi)

• Tehdit: hizmeti kullanılamaz kılmak.
• Örnek: aşırı istek, kaynak tüketimi.
• Önlem: hız sınırı, kaynak kotaları, girdi sınırı.

E · Elevation of privilege (yetki yükseltme)

• Tehdit: izinsiz yetki kazanmak.
• Örnek: normal kullanıcı yönetici olur.
• Önlem: en az yetki, yetki denetimi, güvenli varsayılan.

Bankacılık örneğinde STRIDE özeti

Kök · hedef

Saldırganın nihai amacı. Şimdi yolları bölelim.

Saldırı ağacı: "Ödeme anahtarını ele geçir"

HEDEF: Ödeme anahtarı — VEYA (biri yeter)

1. Veritabanını çöz — VE (hepsi gerekir): root yetkisi al + veritabanı anahtarını bul
2. Bellekten oku — VEYA: hata ayıklayıcı bağla | bellek dökümü al | fonksiyona kanca at
3. Trafiği dinle — VE: TLS'i kır + mesaj düzeyi şifrelemeyi kır

Saldırı ağacı — "Veritabanını çöz" dalı

VE düğümü (hepsi gerekir):

1. Root yetkisi al
2. VE veritabanı anahtarını bul

İkisi birden gerektiği için bu yol pahalıdır.

Bu, derinlemesine savunmanın çalıştığının kanıtıdır.

Saldırı ağacı — "Bellekten oku" dalı

VEYA düğümü (biri yeter): üç alternatif

1. Hata ayıklayıcı bağla
2. VEYA bellek dökümü al
3. VEYA fonksiyona kanca at

Üç alternatif = en zayıf nokta: bellekteki anahtar.

→ Bu hafta Demo 2 · 6. hafta çalışma zamanı koruması · 11. hafta whitebox

Saldırı ağacı — "Trafiği dinle" dalı

VE düğümü (hepsi gerekir):

1. TLS'i kır
2. VE mesaj düzeyi şifrelemeyi kır

İki katmanı birden kırmak gerekir → pahalı yol.

Savunmacının hedefi: saldırganı mümkün olduğunca çok VE düğümüne zorlamak.

Saldırı ağacı — önlem eşlemesi

Saldırı ağacının yapraklarını doğrudan bir savunma katmanına bağlayalım:

Saldırı ağacı: en ucuz yol (animasyon)

Saldırı ağacı — uç durum: her düğüm VE

Veri akış diyagramı: beş sembol

➡️ Güven sınırını geçen her oku kırmızıya boyayın: incelemeye oradan başlayın

Veri akış diyagramı ve güven sınırı — şema

DFD ögesi -> STRIDE (animasyon)

STRIDE — uç durum: hepsi veri akışı

Risk puanı: olasılık × etki

• Olasılık: fiziksel erişim mi, internetten mi? Uzmanlık? Otomatikleşir mi?
• Etki: hangi varlık, kaç kullanıcı, parasal/hukuki sonuç?
• Daha ayrıntılı: CVSS (2. hafta), saldırı potansiyeli (13. hafta)

Risk matrisi (animasyon)

Risk matrisi — uç durum: hepsi kritik

Tehdide dört yanıt

1. Azalt — önlem ekle (en sık)
2. Ortadan kaldır — özelliği hiç yazma (en güçlü)
   "Parolayı hatırla" yoksa, diskteki parola tehdidi de yok
3. Aktar — kart verisini saklama, ödeme sağlayıcısına bırak
4. Kabul et — gerekçesiyle kalan risk listesine yaz

⚠️ Plana yazılmamış risk kabul edilmiş değil, gözden kaçmıştır

Adım 0–1: Uygulama ve kapsam

Kasa: C++ masaüstü parola kasası

• Ana parola → türetilen anahtar → kayıtlar tek dosyada şifreli
• Panoya kopyalama · isteğe bağlı bulut yedek · otomatik güncelleme

Kasa mimarisi — şema

Adım 5 (devam): T7 ve T9 önlemleri

T9 örneği önemli: her tehdide önlem eklemek gerekmez, bazen kabul etmek doğru karardır.

Adım 6–7: Doğrulama ve kalan risk

Kalan risk: kasa açıkken aynı kullanıcıyla çalışan zararlı · omuz sörfü · çok zayıf parola

⚠️ Testi olmayan önlem değerlendirici gözünde yoktur

Sık yapılan hatalar

• Varlık unutmak: anahtarlar, belirteçler, sayaçlar, yapılandırma, kodun kendisi
• Güven sınırını yanlış çizmek: kendi istemcinizi "güvenilir" saymak
• Önlemi tehditle eşleştirmemek: "TLS kullanıyoruz" — hangi tehdidi kapatıyor, hangisini kapatmıyor?
• Testsiz önlem: "siliyoruz" deyip derleyicinin silmeyi kaldırdığını fark etmemek (Demo 2)

Sır bellekten nasıl sızar — şema

Program boş sayfayla başlamaz

Çalıştıran kişiden devraldıkları:

• Ortam değişkenleri: PATH, LD_PRELOAD, IFS…
• Açık dosya tanıtıcıları, çalışma dizini, umask
• Kaynak sınırları, çökme dökümü ayarı

Program bunlara güvenirse, onları kontrol eden programı kontrol eder.
Kitap: Viega & Messier, Tarif 1.1–1.9

Demo 1 — PATH ile kandırma (CWE-426)

int status = system(COMMAND);  /* Linux: "date"  Windows: "hostname" */
                                /* WHICH ONE runs? */

.\demo.ps1 (Windows) · sh demo.sh (WSL / Linux)

STEP 2 - PATH="$PWD/fake:$PATH" ./bin/linux/report
Report date:
  !!! FAKE 'date' ran !!!
STEP 3 - ./bin/linux/report_secure  ->  Report date: Sat Sep 26 ...

PATH ile kandırma — şema

PATH araması — animasyon (saldırı)

PATH araması — uç durum: sahte dizin ortada

Düzeltme: üç kural

char *const args[]     = { "date", NULL };
char *const clean_env[] = { "PATH=/usr/bin:/bin", "LANG=C", NULL };
posix_spawn(&pid, "/bin/date", NULL, NULL, args, clean_env);

1. Mutlak yol → PATH araması yok
2. Kabuk yok (posix_spawn / execve) → özel karakter, IFS yok
3. Temiz ortam → bilinen, küçük bir ortam

Windows: CreateProcessW + System32\hostname.exe + yalnız SystemRoot

En iyisi: başka programa hiç gerek bırakma → strftime(), GetComputerNameW()

Programın devraldığı durum — şema

Hepsi bir arada: secure_startup()

int main(int argc, char **argv)
{
    sanitize_file_descriptors();   /* 1. descriptors  */
    sanitize_environment();        /* 2. environment  */
    umask(077);                    /* 3. permissions  */
    disable_core_dump();           /* 4. dump         */
    drop_privileges();             /* 5. privilege    */
    /* ... the actual work ... */
}

Sıra önemli: başka hiçbir şey yapmadan önce

Güvenli başlatma boru hattı (animasyon)

Güvenli başlatma — uç durum: hepsi tehlikeli

Demo 2 — Bellekte kalan parola (CWE-14)

char password[64];
n = file_read(fd, password, sizeof(password) - 1);
key = derive_key(password, n);
memset(password, 0, sizeof(password));         /* version 2 */
explicit_bzero(password, sizeof(password));    /* version 3, Linux */
SecureZeroMemory(password, sizeof(password));  /* version 3, Windows */

Never wipes     -> password FOUND in the dump
memset (-O2)    -> password FOUND in the dump      ← !!!
explicit_bzero  -> password not found in the dump

Parola bellekte (animasyon)

Parola bellekte — uç durum: gerçek silme

Süreç belleği

C dizinin sonunu denetlemez. name[16]'ya 17. bayt → arkadaki değişkenin üzerine.

Yapının bellekteki hali

struct session { char name[16]; int admin; };

 offset: 0 ............................ 15 | 16  17  18  19
        [ a  l  i  c  e \0  .  .  .  .  . ][ 00  00  00  00 ]   admin = 0

 "AAAAAAAAAAAAAAAAB" (17 characters) copied in:
        [ A  A  A  A  A  A  A  A  A  A  A ][ 42  00  00  00 ]   admin = 66 (!)
                                              'B'  '\0'

Az anlamlı bayt önce (little-endian): en düşük bayt en düşük adreste.

Süreç belleği (animasyon)

Süreç belleği — uç durum: hepsi öbekte

Bellekteki yapı ve taşma — şema

Arabellek taşması nedir?

Bir diziye ayrılan boyuttan fazla veri yazmak → taşan baytlar komşu değişkenlerin üzerine

C neden bu kadar kolay taşar?

1. Dizi boyutunu bilmez
2. Fonksiyona yalnız başlangıç adresi gider
3. Dize (string) = '\0' ile biten dizi; strcpy hedefi sormaz
4. Derleyici sınır denetimi eklemez

CWE-787 "sınırlar dışına yazma": CWE Top 25'in hep ilk sıralarında

Yığın çerçevesi (animasyon)

Yığın çerçevesi — uç durum: dönüş adresi eziliyor

Heartbleed (2014): hiçbir şey yazılmadı

• İstemci: "1 bayt gönderiyorum, 64 KB diye bildiriyorum"
• Sunucu: bildirilen uzunluğu denetlemeden 64 KB geri yolladı
• Sızan: parolalar, oturumlar, hatta sunucunun özel anahtarı
• CVE-2014-0160 · CWE-125 · Düzeltme: tek bir uzunluk denetimi

➡️ Sınır dışı okuma da yazma kadar tehlikeli; üstelik çökmez, iz bırakmaz

C++: boyutu tür taşır — ama dikkat

void greet_user(const std::string &name) {
    if (name.size() > 15) throw std::invalid_argument("name too long");
    std::cout << "Hello " << name << '\n';
}

• vector::operator[] sınır denetlemez → at() denetler
• c_str() ile alınan işaretçiye yazmak → C'nin bütün sorunları geri gelir

Demo 3 — Taşmayla yetki yükseltme (CWE-121)

.\demo.ps1 (Windows) · sh demo.sh (WSL / Linux)

Taşma — animasyon (17 bayt, admin ayarlanıyor)

Taşma — uç durum: struct'ın ötesine geçiyor (40 bayt, ASan)

Düzeltme: doğrula, sonra sınırlı kopyala

/* Allow-list: 1-15 characters, letter/digit/_/- */
static int name_is_valid(const char *s)
{
    size_t n = strnlen(s, 16);
    if (n == 0 || n >= 16) return 0;
    for (size_t i = 0; i < n; i++) {
        unsigned char c = (unsigned char)s[i];
        if (!isalnum(c) && c != '_' && c != '-') return 0;
    }
    return 1;
}
struct session s = { .admin = 0 };             /* secure default */
snprintf(s.name, sizeof(s.name), "%s", argv[1]);   /* a copy that knows the size */

Canary, NX, ASLR (4. hafta) sömürmeyi zorlaştırır, hatayı düzeltmez.

Tamsayılar: -1 ne zaman dev olur?

int işaretli · size_t işaretsiz · negatifler ikiye tümleyen

int    -1  =  0xFFFFFFFFFFFFFFFF
size_t     =  18 446 744 073 709 551 615

if (length > 16) return -1;   /* -1 PASSES this check */
memcpy(dest, source, length); /* int -> size_t */

Demo 4 — İşaretli uzunluk (CWE-195)

STEP 0  GCC -Wall -Wextra: silent · -Wsign-conversion: warning
        MSVC (C): silent · same code as C++: C4365
STEP 1  copy 8     -> Copied: SAMPLE-R
STEP 2  copy 100   -> Rejected
STEP 3  copy -1    -> Linux: SIGSEGV (139) · Windows: 0xC0000409
STEP 4  ASan        -> negative-size-param: (size=-1)
STEP 5  copy_secure -1 / 12abc -> Rejected

Kural: boyutlar size_t · alt ve üst sınır · strtol · uyarıları aç

İşaretli uzunluk hatası — şema

İşaretli uzunluk taraması (animasyon)

İşaretli uzunluk — uç durum: hepsi negatif

Dinamik belleğin yaşam döngüsü

Ayır → doğrula → kullan → sırrı sil → bir kez serbest bırak → işaretçiyi unut

Belleğin ömrü ve CWE'ler — şema

Bellek hataları turu (animasyon)

Bellek hataları — uç durum: hepsi UAF

Korunan kod bölümleme: TCB'yi küçült

Güvenilir hesaplama tabanı (TCB): "hatalıysa güvenlik çöker" dediğimiz kodun tamamı

• 200.000 satırlık uygulama, 2.000 satırlık korunan çekirdek
• İnceleme, gizleme, bütünlük denetimi yalnız çekirdeğe → maliyet de yalnız orada

Bellekte örtme — kod örneği

typedef struct {
    uint8_t mask[32];     /* generated randomly at start-up */
    uint8_t masked[32];   /* key XOR mask */
} MaskedKey;

static void unmask_key(const MaskedKey *o, uint8_t temp[32])
{
    for (size_t i = 0; i < 32; i++)
        temp[i] = o->masked[i] ^ o->mask[i];
}

Bellekte anahtarın kendisi değil, iki anlamsız parça durur; birleştirme yalnız kullanım anında.

Açıklık penceresi — şema

Değişiklik yönetimi: yedi adım

1. Temel çizgi → 2. Değişiklik talebi → 3. Sınıflandırma → 4. Onay ve planlama → 5. Geliştirme ve test → 6. Yayın → 7. Doğrulama

• 3 ile 4 arasında güvenlik etki analizi: hangi varlık, arayüz, tehdit, önlem?
• Yalnız değişen kısmın incelenmesi = delta değerlendirme (13. hafta)
• Depo: korumalı dallar · en az bir gözden geçiren · imzalı etiket · MFA

Değişiklik yönetimi — şema

Haftanın araç kutusu — şema

Proje: bu hafta yapılacaklar

1. Takım (bireysel ya da en çok 4 kişi) ve konu
2. GitHub deposu + proje planı (iş paketleri, takvim) → onaylat
3. Güvenlik kılavuzu taslağı:
   • S0 kapak ve sürüm geçmişi · S2 ürün genel bakışı
   • S3 mimari ve arayüz tablosu
   • S4 saldırgan modeli · STRIDE · saldırı ağacı

Sınıf alıştırması (15 dk)

Öğrenci not sistemi: öğretim üyesi not girer, öğrenci görür, veri sunucuda.

1. Veri akış diyagramı + güven sınırları
2. Her STRIDE harfinden bir tehdit
3. "Notumu 45'ten 85'e çıkar" saldırı ağacı — en ucuz yol hangisi?

Uçtan uca: Kasa'nın savunmasını tamamlamak

Bölüm 4'te "Kasa"nın tehdit tablosunda iki madde vardı; bu haftanın geri kalanı onları somut kodla kapatıyor:

Güvenlik bir his değil, süreçtir: varlığı tanı, tehdidi modelle, katmanla koru, kalan riski yaz. Bu çerçeveyi dönem boyunca kullanacağız.

Kendi başına çalış (not verilmez)

1. PATH tuzağı: ls (Linux) / whoami (Windows) ile tekrarla, tam yolla düzelt
2. Demo 2'de MOD optimize → MOD korumasiz: memset şimdi çalışıyor mu?
3. Demo 3'te 16, 17, 18, 19, 20 karakter: admin değerleri tablosu
4. struct session'a balance ekle: taşmayla 1000'in üstüne çıkar, sonra engelle
5. Kendi projenin STRIDE tablosu (≥ 8 tehdit + önlem)
6. Heartbleed raporunu oku: hangi denetim eksikti? Hangi CWE?

Ayrıntı ve ipuçları: ders sitesi → Hafta 1 → "Kendi başına çalış"

Kendini sınama

1. Varlık, tehdit, zafiyet farkı?
2. Alıcı IBAN'ın yolda değişmesi CIA'nın hangisi?
3. Beyaz kutu saldırganı neyi farklı yapar?
4. STRIDE "E" hangi demo?
5. VE / VEYA düğümü — savunma için hangisi iyi?
6. system("date") neden tehlikeli? Üç düzeltme?
7. memset neden kayboldu?
8. ASan 17 karakteri neden yakalamadı?
9. -1 memcpy'ye gidince ne olur?
10. Derinlemesine savunma — mobil ödeme mimarisinden örnek?

Kendini sınama (devam)

1. Bir veri akışına neden S sorulmaz?
2. Tehdide dört yanıt nedir? "Ortadan kaldırma"ya örnek verin
3. setuid programda neden önce grup bırakılır?
4. strncpy neden güvenli strcpy değildir?
5. Heartbleed neden hiçbir şey çökmeden veri sızdırdı?

Kendini sınama — cevaplar (devam 1–5)

1. Veri akışına S sorulmaz: akışın kimliği yoktur (sahtecilik uçlara/varlıklara sorulur).
2. Azalt · kaldır · aktar · kabul et. "Kaldırma" örneği: "parolayı hatırla" özelliğini hiç sunmamak.
3. setuid'de önce grup bırakılır; kullanıcı önce bırakılırsa grubu değiştirecek yetki kalmaz.
4. strncpy uzun kaynakta sonuna sonlandırıcı koymaz → sonlandırılmamış dize.
5. Heartbleed yalnız okudu; okunan bellek sürecin kendi geçerli belleğiydi → çökmeden sızdı.

Kendini sınama (devam)

6. Kanarya taşmayı fark edince ne yapar? Neden hâlâ sorun?
7. free(p); p = NULL; neyi önler, neyi önlemez?
8. mlock neyi önler, neyi önlemez?
9. "Şifre çözme kâhini" nedir? Bir karşı önlem?
10. Benzersiz sürüm kimliğinin üç bileşeni?

Kendini sınama — cevaplar (devam 6–10)

6. Kanarya bozulunca programı sonlandırır (hizmet reddi); bitişik değişkene taşmayı görmez.
7. free(p); p=NULL; çift bırakma/UAF'ı önler; takma adları (aynı adrese başka işaretçi) korumaz.
8. mlock belleğin takasa yazılmasını önler; okunmasını ve silinmemiş sırrı önlemez.
9. Şifre çözme kâhini: anahtarsız çözdürme imkânı. Karşı önlem: bağlam/bütünlük denetimi, çağrı sınırı, cihaza bağlama.
10. Benzersiz sürüm: anlamsal sürüm + git kimliği + binary SHA-256.