Web Tarayıcılarının Evrimi

1,083 views

Published on

Web Tarayıcılarının Evrimi, IstSec 2009 sunumu.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,083
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Tarayıcı bu destekleri manual koyduğunda her zaman feature listesine ekleyebilir ya da buna desteği var mı diyen kişilere evet diyebilir. Ama yazılımı çalıştırmadan önce doğru ayarları yapamazsanız aslında günveli açıklarını bulmaycak.
  • XSS için <net sparker> gibi generic bir injection kullanıp daha sonradan ekstra analiz yapma
  • Web Tarayıcılarının Evrimi

    1. 1.
    2. 2.
    3. 3. WEB GÜVENLİĞİtarayicilarinin EVRİMİ<br />Ferruh Mavitunaferruh@mavitunasecurity.com<br />
    4. 4. Kimdir?<br />Türkiye’ de Polis ve Askeri Kuvvetler için çalıştı<br />Amerika, Kanada, İngiltere, İskoçya, İrlanda, Almanya, Japonya ve Türkiye’ de bir çok firma için güvenlik ve penetration testing hizmeti verdi<br />Web uygulaması güvenliği konusunda dünyaca kabul gören bir çok araç, araştırma yayınladı ve bir çoğuna da katkıda bulundu<br />Netsparker’ ın geliştiricisi ve Mavituna Security’ nin kurucusu<br />
    5. 5. Giriş<br />Web uygulaması güvenliği tarayıcısı nedir?<br />Tarayıcıların Sorunları<br />Bu sorunların nedenleri<br />Çözümleri<br />
    6. 6. Sorun1 – Tarayıcıların Üşengeçliği<br />Tarayıcılar basit bir şekilde bazı açıkları gözardı etti<br />Gruplu Blind SQL Injection’ lar<br />Vakit tabanlı Blind SQL Injection’ lar<br />Blacklist ile filtrelenmiş XSS’ ler<br />
    7. 7. SQL Örneği<br />SELECT * FROM Users WHERE NOT (active=0 OR expired=0) AND (username=$USER)<br />
    8. 8. Sorun 2 – “False Positive” ler<br />False Positive’ lerin Kabulü<br />CSRF gibi otomatik olarak yapması zor işleri yapmaya yeterli temel olmadan yapmaya çalışmaları<br />Zararları<br />Vakit kaybı<br />Güvenlik uzmanı olmayanların araca güvensizliği (IDS Sendromu)<br />Otomatik entegrasyonu engel olması (Rapor, WAF vs. entegrasyonu)<br />
    9. 9. Sorun 3 – Exploitation<br />Vulnerability Assessment vs. Penetration Testing <br />Olmamasının Zararları<br />Geliştiricilerin güvenlik açıklarını yeterince ciddiye almaması<br />Gerçek etkiyi analiz edememe<br />Post-exploitation analizlerinin yapılamaması<br />
    10. 10. Sorun 4 – Post Exploitation<br />SQL Injection’ dan sonra<br />Database kullanıcısının haklarının analizi<br />Privilige Escalation<br />LFI’ dan sonra<br />Config, şifre vs. içeren dosyaların analizi<br />File Upload<br />Privilige Escalation vs...<br />Command Execution<br />Local Network’ sızma<br />
    11. 11. Neden?<br />Neden son 8 senede uygulama güvenliği ciddi bir ilerleme gösterirken black-box scanner’ lar bundan nasiplerini alamadılar?<br />
    12. 12. Neden 1 - Kullanıcı İkilemi<br />Kullanıcı yazılımı güvenlik açığı bulmak için kullanır<br />Yazılım güvenlik açığı bulmaz<br />Ama aslında güvenlik açığı vardır <br />Kullanıcı hiç bir zaman açıktan haberdar olmaz ve hiç bir zaman yazılımı suçla(ya)maz<br />
    13. 13. Neden 2 – Gizli Tekel<br />Markette az oyuncunun olması ve market fragmantasyonunun yüksek olması her oyuncuya kendi köşesinde yeterli olacak kadar mali getiri sağladı<br />Birbirlerini teknik zorlamak yerine çift tıklamanın patentini almak gibi “injection” işleminin patentini alıp bir birbilerini dava etmeyi seçtiller.<br />
    14. 14. Neden 3 - Vizyon<br />Yazılımların bir çoğu otomasyonu kendi görüşlerinde limitlediler, bir çok yazılım açık açık şunları söyledi:<br />False Positive’ ler engellenemez<br />Otomatik tarayıcılar hiç bir zaman manual testing yerini tutmayacak<br />Bu her ne kadar doğru olsa da buradaki çizgiyi yanlış çektiler. Bir çok güvenlik açığı otomatik olarak manual’ e göre daha verimli tespit edilebilir. <br />
    15. 15. Neden 3.5 – Otomasyona Yaklaşım<br />Otomasyon’ da hile yapmak çok kolaydır,<br />“Bu işlem çok komplike, bunu kullanıcıya bırakalım, yazılım bunu verimli şekilde bilemez.” demeniz yeterli.<br />Bundan nasibini alan bazı konular<br />URL Rewrite<br />Authentication<br />Özelleştirilmiş 404 sayfaları<br />Hatta size diskinizi kontrol edip belli bir dosyayı aramanızı söyleyen bir tarayıcı var. Kendisi tespit etmek yerine siz testin başarılı olup olmadığını test sisteminin C: sine erişerek test ediyorsunuz! Tabii erişim hakkınız varsa...<br />
    16. 16. Neden 3.5 – Otomasyona Yaklaşım<br />Bir çok seçim ve ayarı kullanıcıya bırakmak neden kötü?<br />Vakit kaybı<br />Deneyimsiz kullanıcıların ayarları bilmemesi veya doğru şekilde yapamıyor olması<br />Bazen ayarları doğru yapabilmeniz için sitede olabilecek güvenlik açıklarını sizin tahmin etmeniz gerekli! Bu da gene deneyimsiz kullanıcıları kötü bir yerde bırakıyor<br />
    17. 17. Neden 4 – Feedback Yetersizliği<br />Bir çok kişi testlerdeki hataları tüm detayları tarayıcı firmalara raporlayamıyor. Başlıca nedenleri:<br />NDA (Non Disclosure Aggreements)<br />“Top Secret” Hükümet ve Ticari Testler<br />Henüz yayınlanmamış projeler<br />Dışarıdan erişilmeyen projeler <br />Son olarak verimli bir raporlama gerçekten vakit gerektiren bir iş.<br />
    18. 18. Üşengeçlik Çözümü<br />Tarayıcılar gruplu SQL Injection’ ları bulamıyor ya da bazı XSS’ leri kaçırıyor demiştik<br />Çözüm<br />Geniş test sistemleri, test matriksleri ve test otomasyonu. Tüm gerçekçi olasılıkları kapsadığından emin olmak<br />Daha zeki saldırılar, mesela XSS için...<br />
    19. 19. False Positive Çözümü<br />“eğer exploit edebiliyorsanız false positive değildir” <br />Otomatik exploitation<br />SQL Injection<br />XSS<br />LFI vs.<br />
    20. 20. Netsparker – XSS Demosu<br />XSS Demo<br />
    21. 21. Exploitation Çözümü<br />SQL Injection & LFI Tespit <br />ve <br />Exploitation Demosu<br />
    22. 22. Sorular?<br />
    23. 23. Teşekkürler...<br />Ferruh Mavitunaferruh@mavitunasecurity.com<br />

    ×