1. OWASP { Open Web Application Security Project} www.cihanozhan.com

4. OWASP Nedir? OWASP kar amacı gütmeyen global bir organizasyondur(hayır kurumu). Odak noktası web uygulama güvenliğidir. The Top Ten Most Critical Web Application Security Risks adında bir doküman yayınlar. Top 10 dökümanı teknoloji bağımsız bir website güvenlik risklerini yönetim rehberidir. Top 10 web uygulama geliştiricileri ve güvenlik uzmanları için güvenlik odağında bir rehberdir.

5. Top 10 Injection XSS : Cross-Site Scripting Broken Authentication and Session Management Insecure Direct Object References CSRF : Cross-Site Request Forgery Security Misconfiguration Insecure Cryptographic Storage Failure to Restrict URL Access Insufficient Transport Layer Protection Unvalidated Redirects and Forwards

6. SQL Injection {OWASP} www.cihanozhan.com

9. Temeller Trusted? Untrusted? http://www.ecommerce.com/product?id=1 = SELECT * FROM Products WHERE ID = 1

10. Güvenilmez Veri Bütünlüğü doğrulanamaz veriler Kötü niyetli olabilir. Veri çeşitli yük içerebilir: – SQL Injection – XSS : Cross-Site Scripting – Kötü Amaçlı Yazılım İçeren Binary Dosya Güvenilmez verinin kaynakları: – Kullanıcıdan Routing ya da QueryString vasıtasıyla Form’dan POST edilerek – Tarayıcıdan Cookie’lerde Request Header’ında – Diğer Yerler Harici servisler Kendi veritabanın!

11. Story? Sony hacked! 2011… – https://thehackernews.com/2011/06/sony-pictures-hacked-and-database.html https://thehackernews.com/2011/06/sony-pictures-hacked-and-database.html – https://www.troyhunt.com/brief-sony-password-analysis/ https://www.troyhunt.com/brief-sony-password-analysis/ Neler çalındı? – 1.000.000 kullanıcının kritik bilgileri Email adresleri, Parolalar, Ev Adresleri, Doğum Tarihleri vb…

12. Örnek Sorgular SELECT * FROM users WHERE username = 'cihanozhan' AND password = 'choqHizliBeYa'; username = "cihanozhan' OR 1=1; --" password = "blank " SELECT * FROM users WHERE username = 'cihanozhan' OR 1=1; --' AND password = 'blank';

13. Örnek Sorgular SELECT * FROM categories WHERE name = '${query}'; query = "q' OR 1=(SELECT COUNT(*) FROM AdminLogins); --" query = "q' UNION SELECT username, password FROM Users; --" query = "q'; DROP TABLE Customers; --" query = "q'; UPDATE Users SET admin=1 WHERE username='hacker'; --" query = "q'; INSERT INTO Orders(customer_id, product_id, paidAmount) VALUES(354, 729, 755.0); --"

14. Demo! Genel uygulama yapısını oluşturmak SQL Injection sorgusu ile sistemi manipüle etmek

15. Nasıl Korunuruz? (Parameterised Inline SQL) Demo demo demo…

16. Nasıl Korunuruz? (Stored Procedure) Demo demo demo…

17. WhiteList vs. BlackList

19. WhiteList vs. WhiteList BlackList: Engellenenler listesi WhiteList: Kabul edilecekler listesi

21. Nasıl Korunuruz? (WhiteList nasıl uygulanır?) Güvenilmeyen tüm veriler iyi bilinen değerler ile doğrulanmalıdır. WhiteList, güvenli olduğu iyi bilinen/belirlenmiş değerlerden oluşur. – Bu çok net/açık bir kontrol yöntemidir. – Güvenmediğimiz olası herşeyi filtreler. BlackList, güvenli olmadığı bilinen/belirlenmiş değerlerden oluşur. – Çok net olmayan ve üstü kapalı bir yöntem. – Listede olmayan herşeyin güvenli olduğunu öngörür.

22. Nasıl Korunuruz? (WhiteList yaklaşımları) Tür dönüşümü – Integer, Date, GUID vb… Regular Expressions – Email, Telefon No, Ad(Dikkatli ol!) Açıkça bilinen verilerin listesi – Renkler, Markalar, Ülkeler, Şehirler, Ürünler vb…

23. Nasıl Korunuruz? (WhiteList) Demo demo demo…

24. Nasıl Korunuruz? (ORM, Framework) Framework ve ORM’nin güvenliğe katkısı nedir? Entity Framework? Demo, demo, demo…

25. Nasıl Korunuruz? (Stored Procedure Bi’ Mucize mi?) Demo, demo, demo…

26. Nasıl Korunuruz? (Özet) Veritabanı kullanıcısına sınırlı yetkiler vermek Veritabanına gelen veri filtrelenip temizlenmeli SQL için escape karakterleri kullanmak Prepared Statements –SET @sql = "SELECT * FROM Categories WHERE name = ?"; –PREPARE stmt FROM @sql; –EXECUTE stmt USING @query;

27. SQL Injection (Araç-Gereçler) Netsparker – https://www.netsparker.com.tr/ https://www.netsparker.com.tr/ BSQL Hacker – https://www.darknet.org.uk/2008/09/bsql-hacker-automated-sql-injection-framework/ https://www.darknet.org.uk/2008/09/bsql-hacker-automated-sql-injection-framework/ – https://labs.portcullis.co.uk/tools/bsql-hacker/ https://labs.portcullis.co.uk/tools/bsql-hacker/ SQLmap – https://github.com/sqlmapproject/sqlmap (TR) https://github.com/sqlmapproject/sqlmapTR SQLninja – http://sqlninja.sourceforge.net/ http://sqlninja.sourceforge.net/ Havij – https://www.darknet.org.uk/2010/09/havij-advanced-automated-sql-injection-tool/ https://www.darknet.org.uk/2010/09/havij-advanced-automated-sql-injection-tool/ Safe3 SQL Injector – https://sourceforge.net/projects/safe3si/ https://sourceforge.net/projects/safe3si/ SQLsus – http://sqlsus.sourceforge.net/ http://sqlsus.sourceforge.net/ Mole – https://sourceforge.net/projects/themole/files/ https://sourceforge.net/projects/themole/files/

28. SQL Injection (Araç-Gereçler) jSQL Injection – https://www.kitploit.com/2015/12/jsql-injection-v073-java-tool-for.html https://www.kitploit.com/2015/12/jsql-injection-v073-java-tool-for.html BBQSQL – https://www.kitploit.com/2016/10/bbqsql-blind-sql-injection-exploitation.html https://www.kitploit.com/2016/10/bbqsql-blind-sql-injection-exploitation.html NoSQLMap – https://www.kitploit.com/2016/02/nosqlmap-v06-automated-nosql-database.html https://www.kitploit.com/2016/02/nosqlmap-v06-automated-nosql-database.html Whitewidow – https://www.kitploit.com/2017/05/whitewidow-sql-vulnerability-scanner.html https://www.kitploit.com/2017/05/whitewidow-sql-vulnerability-scanner.html DSSS – https://www.kitploit.com/2017/08/dsss-damn-small-sqli-scanner.html https://www.kitploit.com/2017/08/dsss-damn-small-sqli-scanner.html Explo – https://www.kitploit.com/2017/05/explo-human-and-machine-readable-web.html https://www.kitploit.com/2017/05/explo-human-and-machine-readable-web.html Blind-SQL-Bitshifting – https://www.kitploit.com/2016/04/blind-sql-bitshifting-blind-sql.html https://www.kitploit.com/2016/04/blind-sql-bitshifting-blind-sql.html Leviathan – https://www.kitploit.com/2017/04/leviathan-wide-range-mass-audit-toolkit.html https://www.kitploit.com/2017/04/leviathan-wide-range-mass-audit-toolkit.html Blisqy – https://www.kitploit.com/2017/10/blisqy-exploit-time-based-blind-sql.html https://www.kitploit.com/2017/10/blisqy-exploit-time-based-blind-sql.html

29. XSS : Cross-Site Scripting {OWASP} www.cihanozhan.com

31. XSS XSS açıkları uygulama kullanıcıdan veri alıp, bunları herhangi bir kodlama ya da doğrulama işlemine tabi tutmadan sayfaya göndermesi ile oluşur. XSS saldırganın kurbanın tarayıcısında kullanıcı oturumları bilgilerin çalınmasına, web sitesinin tahrif edilmesine veya solucan yüklenmesine sebep olan betik çalıştırmasına izin verir.

33. Hack News MySpace Hack – https://samy.pl/myspace/ – https://samy.pl/myspace/tech.html

34. Trusted vs. Untrusted http://www.cihanozhan.com/search?q=bombili Yukarıdaki URL’de dışarıdan alınan bombili verisi haricinde herşey trusted, bombili ise kullanıcıdan alındığı için untrusted veridir. Yani asla güvenilemez!

35. Hack Yapalım! Demo, demo, demo…

36. Output Encoding Concepts Arama alanı markup biçimlendirme için kullanılmaz, sadece veri alır. XSS saldırıları, uygulamanın bir XSS yükünün(payload) data context(veri bağlamı)’ten çıkmasına ve markup içeriğini değiştirmesine izin verdiği için mümkündür. Yani bu teknik bir gereksinimin sonucudur. XSS riskinin azaldığından emin olmak için metin kutusuna girilen verinin sayfada girildiği gibi görüntülendiğinden emin olunmalıdır. HTML markup tarayıcının kod alanında şöyle görünmelidir. – bombili – <i> bombili </i>

37. Encoding Types CSS HTML HTML attribute HTML from URL JavaScript LDAP distinguished name LDAP filter URL URL path XML XML attribute

38. Tarayıcı Çıktısı Nasıl Olmalı? Orijinal veri : bombili HTML Çıktısı: <i> bombili </i> JavaScript Çıktısı: \x3ci\x2ebombili\x3c\x2fi\x3e CSS Çıktısı: \00003Ci\00003Ebombili\00003C\00002Fi\00003E Not : Output Encoding işlemlerinde kendini kanıtlamış kütüphaneler kullanılmalı.

39. Output Encoding Demo, demo, demo… HTML Based Encoding JavaScript Based Encoding (AntiXss) – https://docs.microsoft.com/tr- tr/dotnet/api/system.web.security.antixss?view=netframework-4.8 https://docs.microsoft.com/tr- tr/dotnet/api/system.web.security.antixss?view=netframework-4.8

40. Kontrol Bazlı Encoding’i Anlamak Demo, demo, demo… ASP.NET Web Form Controls Encodings ASP.NET MVC Control Encodings

41. RegEx WhiteList İzin Verilen Değerler Regular Expression desenlerini bir WhiteList filtresi olarak kullanmak!

42. Request Validation Request Validation nedir?

44. Request Validation (Yöntemler) Application Level Page Level Control Level

45. Request Validation (Application Level) Demo, demo, demo…

46. Request Validation (Page Level) Demo, demo, demo…

47. Request Validation (Control Level) Demo, demo, demo…

48. TinyURL? Demo, demo, demo… https://tinyurl.com/y28zle9t Kısa URL’ler ile de hackleyebiliriz. Hiç sorun değil…

49. Native Browser Defence Tarayıcılarda doğal olarak gelen bir savunma mekanizmasıdır. – Tarayıcı özelinde NBD desteğini araştırmanızı öneririm. Google Chrome’da varsayılan olarak XSS savunması bulunmaktadır.

50. Hack News Apple

51. Broken Authentication & Session Management {OWASP} www.cihanozhan.com

53. Genel Bakış Session ID’nin URL üzerinden kullanıldığı yöntemlerde sık görülür. Parola sıfırlama sayfalarının doğrudan email ile yeni şifre göndermesi. Mail aktivasyonu yapılmadan kullanıcının onaylandığı sistemler Kullanıcının giriş yaptıktan sonra bir türlü çıkış yapamadığı sistemler.

54. Hack Yapalım! Demo, demo, demo…

55. Stateless Protokol Üzerinde Kalıcı Tanım HTTP durumsuz(stateless) bir protokoldür. – Önceki bağlantılar sonrakilerden tamamen bağımsızdır. – Aynı ve birden fazla yapılan istekte aynı kullanıcıyı benzersiz ve güvenli şekilde tanımlayacak şekilde yapılandırılmalıdır. – Bunu, kullanıcılar için isteklere göre benzersiz olacak bir veri parçasına dayayarak yaparız.

56. URL Bazlı Kalıcı Session (Insecure) Nasıl çalışır? – Oturuma özgü bir ID oluşturulur. – Bu kimlik daha sonra URL’e döndürülür. – Tarayıcı tarafından takip edilen tüm istekler, URL’deki kimliği içerir. Buradaki sorun nedir? – URL’ler sosyal medya ve email gibi araçlarla paylaşılır. – URL’ler proxy ve web serverlar tarafından loglanır. – URL’ler tarayıcı geçmişinden geri alınabilir/okunabilir.

57. Cookie Bazlı Kalıcı Session (Secure) Nasıl çalışır? – Oturuma benzersiz bir ID oluşturulur. – Bu ID daha sonra cookie’ye döndürülür. – Tarayıcı tarafından takip edilen tüm istekler çerezleri sunucuya gönderir. Buradaki sorun nedir? – Tarayıcı cookie desteğinin aktif olması gerekir. Bu ayar kullanıcı tarafından değiştirilebilir.

58. Oturumun Kalıcılığını Garantilemek UseUri – Cihaz desteğinden bağımsız olarak daima URL kullanın. UseCookies(default) – Cihaz desteğinden bağımsız olarak daima cookie kullanın. UseDeviceProfile – ASP.NET cookie’nin tarayıcıda desteklenip desteklenmediğini belirler ve değilse URL’ye geri döner. AutoDetect – ASP.NET cookie’nin tarayıcıda etkin olup olmadığını belirler ve değilse URL’ye geri döner.

59. URL Bazlı Session Ayarı Demo, demo, demo…

60. Riskleri Azaltmak (Session ve Forms Zaman Aşımları) Timeout’lar güvenliği hem sağlar hem de risk oluşturur. Varsayılan session timeout 20 dakikadır. Varsayılan forms timeout 30 dakikadır. – Visual Studio, forms timeout’u varsayılan olarak 2 gün olarak belirler!

61. Sliding Forms Timeout Varsayılan forms timeout sliding’dır. Form zaman aşımı 30 dakikadır.

62. Fixed Forms Timeout Süre halen 30 dakika, ama form ile session timeout paraleldir.

63. Timeout Yöntemini Değiştirmek Default olan sliding timeout’u değiştirmek için: MS : https://docs.microsoft.com/tr- tr/dotnet/api/system.web.security.formsauthentication.slidingexpiration?view=netframework-4.8https://docs.microsoft.com/tr- tr/dotnet/api/system.web.security.formsauthentication.slidingexpiration?view=netframework-4.8

64. Diğer Broken Authentication Desenleri Kimlik bilgileri her zaman şifreli olarak güvenli bir şekilde saklanmalıdır. Minimum şifre sağlamlık kriterlerini uygulamak Asla şifreyi email ile gönderme(parola sıfırlama gibi). Session ID’lerini cookie’de saklamak XSS risklerine karşı koruma yöntemlerini uygulamak Hassas verileri asla güvenli olmayan bir bağlantıdan göndermemek.

65. Insecure Direct Object References {OWASP} www.cihanozhan.com

66. Direct Object References (Güvensiz Doğrudan Nesne Başvurusu) Doğrudan Nesne Referanslama; geliştirici dosya, dizin, veritabanı kaydı gibi bir bilgiyi URL veya form parametresi olarak alıp bunu uygulamaya referans olarak tanımladığı zaman oluşur. Böylece saldırgan referansı manipule ederek yetkisi olmayan nesnelere erişebilir. Bir doğrudan nesne referansı, geliştiricinin URL olarak veya parametre yoluyla, dosya, dizin, veritabanı kaydı veya anahtar gibi, iç uygulama nesnesine ait bir referansı açığa çıkardığı zaman meydana gelir. Saldırgan, eğer erişim kontrol denetimi yoksa, izinsiz diğer nesnelere erişmek için doğrudan nesne referanslarını kullanabilir.

67. Direct Object References (Örnek?) İnternet bankacılık uygulamalarında, birincil anahtar(primary key) olarak hesap numarasını kullanmak oldukça yaygındır. Bu sebeple İnternet arayüzünde doğrudan hesap numarası kullanılabilmektedir. Geliştiriciler, SQL saldırılarını engellemek için parametreli sorgulama kullanmış olsalar dahi eğer hesabı görmeye yetkili kullanıcı veya hesap sahibi için hiçbir fazladan denetim yoksa, hesap numarası parametresiyle oynayan saldırgan, bütün hesapları görebilir veya değiştirebilir.

68. Hacked Citibank – https://www.theregister.co.uk/2011/06/14/citigroup_website_hack_simple/ https://www.theregister.co.uk/2011/06/14/citigroup_website_hack_simple/ Avustralya Vergilendirme Ofisi – Avustralya Vergilendirme Ofisi GST’nin başlangıç yardımcı sitesinin başına 2000 yılında geldi; kayıtlı fakat kötü niyetli olan bir kullanıcı, URL içinde verilen(şirket vergi tanıtıcısı olan) ABN’yi basitçe değiştirdi. Kullanıcı, sistemden yaklaşık 17,000 şirkete ait tüm bilgilere el koydu ve sonra saldırısının ayrıntılarını 17,000 şirketin her birine e-posta ile gönderdi.

69. Basit Anlamda Bir referans izinsiz bir şekilde başka bir kayda atıfta bulunacak şekilde manipüle edilebilirse, doğrudan bir nesne referans riski mevcuttur. http://www.deeplab.co/account/492488120 http://www.darkfactory.co/account/492488120 http://bank.com/account?id=482398 http://www.cihanozhan.com/fileApp?file=7 http://paysomething.com/cihanozhan Bunlar, manuel olarak veya otomatik bir komut dosyası tarafından basitçe sorgulanabilir veya numaralandırılabilir.

70. Demo! Demo, demo, demo…

71. Korunmak Indeksleme, dolaylı referans haritası veya onaylanması kolay diğer dolaylı metotlar kullanılarak kullanıcılara doğrudan nesne referanslarını açığa vurmaktan kaçınmaktır. Eğer doğrudan nesne referansı kullanılması şart ise, kullanıcının referansı kullanmadan önce kimlik doğrulamadan geçtiğinden emin olunmalıdır. – Kullanıcılara mümkünse özel nesne referanslarını açıklamadan kaçının, örneğin birincil anahtarlar veya dosya adları gibi… – Bütün referans gösterilen nesnelerde kimlik doğrulamasını doğrula.

72. Korunmak http://bank.com/account?id=3ka83USD73YShydfo02A2Fajhfj329age324g http://bank.com/account?id=3ka83USD73YShydfo02A2Fajhfj329age324g http://site.com/profile?id=5438f54hsfht6DAF64D57G6Dkd Sayısal ve string tipler numaralandırma zafiyetine açıktır. GUID’lendirilmelidir.

73. CSRF : Cross Site Request Forgery {OWASP} www.cihanozhan.com

76. CSRF (Siteler Arası İstek Sahteciliği) Bu saldırıya açıklık ayrıca “Session Riding “, “One-Click Attacks“, “Cross Site Reference Forgery“, “Hostile Linking and Automation Attack” gibi birkaç başka isim ile de bilinir. Baş harflerinin kısaltması olan XSRF de sıklıkla kullanılır. OWASP ve MITRE, Cross Site Request Forgery(siteler ötesi istek sahteciliği) ve CSRF terimlerinin her ikisini de standartlaştırmıştır.

77. Sebep? Cookie, her istekle birlikte domaine gönderilirse zafiyet ihtimali artar. İsteğin zararlı bir yük ile birlikte(sorgu dizesi parametreleri veya POST data) Mağdurun tarayıcısı, talebi bildirmek için kandırılır.

78. Anlamak CSRF saldırıları işe yarıyor, çünkü tahmin edilebilirler. Saldırı yalnızca meşru olanla aynı yapıya bağlı bir isteği yeniden yapılandırıyor(path ve parametreler). Bu riski azaltmak için, CSRF token aracılığıyla rastgelelik ekleyebiliriz. Token, hem formun bulunduğu meşru sayfa hem de bir cookie aracılığıyla tarayıcıda bilinen rastgele bir veridir.

79. Yanlışlar Domainler arası istekleri kısıtlamak için yönlendirici denetimi uygulamak – Yardımcı olabilir ama bu konuda değil. HTTP GET’leri riskli sayfalarda disable hale getirmek – Bazı saldırı vektörlerini(image kaynağı istekleri gibi) hafifletmeye yardımcı olur, ancak saldırgan hala POST istekleri oluşturabilir. Veri kaydeden IP adresinin, sayfayı yükleyenle aynı olduğunu doğrulamak. – Sonuç değişmiyor, halen kurbanın tarayıcısındayız…

80. Native Browser Defence CSRF riski, Cross-Origin Resource Sharing(CORS) kullanılarak fix’lenebilir. – Farklı tarayıcılar, istenmeyen CORS taleplerine karşı çeşitli seviyelerde savunma sağlar. Diğer yerel tarayıcı savunma sistemlerinde(yani, XSS) olduğu gibi, asla güvenilmemeleri gerekir. – Konu her zaman CSRF için en sonunda anti-forgery token anlamına gelen güvenli kod yazmaya geri dönüyor.

81. Security Misconfiguration {OWASP} www.cihanozhan.com

82. Nedir ve Neden? Gereksiz servis ya da eklentilerin kurulması ve sonrasında unutulmasından kaynaklanan açıktır. OWASP’a göre en çok bulunan açık çeşididir. Bu sistemlerin güncel olmaması, default parolalar ile kalması güvenlik tehditlerini oluşturur. Çözüm olarak ihtiyaç duyulmayan servisler kaldırılmalı, default parolalar değiştirilmelidir. Aynı zamanda sistem güncel tutulmalıdır.

83. Risk in ELMAH https://elmah.github.io/ - inurl:elmah.axd "error log for" - inurl:elmah.axd aspxauth

84. Web.config’in Hassas Alanlarını Şifrelemek C:\Windows>cd Microsoft.NET C:\Windows\Microsoft.NET>cd Framework C:\Windows\Microsoft.NET>Framework>cd v4.0.30319 C:\Windows\Microsoft.NET\v4.0.30319>aspnet_regiis -site "projectName" -app "/" -pe "connectionStrings"

85. Insecure Cryptographic Storage {OWASP} www.cihanozhan.com

86. Nedir? Bu konu genellikle parola depolama hakkındadır. 3 çeşit ortak-genel parola depolama mekanizması vardır: – Plain Text – Encrypted – Hashed

87. Hashing != Encryption Birlikte ya da birbiri yerine kullanılsa da bunlar birbirinden farklıdır. Encryption çift yönlü(geri dönüşümlü) bir süreçtir. – Parola depolaması için, genellikle hem şifrelemek hem de şifresini çözmek için tek bir özel anahtar bulunur(simetrik şifreleme). Hashing tek yönlü(geri dönüşümsüz) bir süreçtir. – Hash’in şifreli metni geri dönüştürülemez.

88. Hashing Bir hash anahtarsız, tek yönlü, deterministik bir algoritmadır. – Aynı algoritma aynı parolada her kullanıldığında aynı sonucu üretir. – Bir account oluşturulduğunda, şifre hash’lenir ve saklanır. – Bir kullanıcı oturum açtığında, verilen parola şifrelenir ve veritabanındaki ile karşılaştırılır. – Parola asla ‘un-hashed’ yapılamaz. Hashing algoritması kırılmaz, veri kırılabilir. – Brute Force ile kırılmak istenen parola ile üretilen parolanın hash’leri karşılaştırılarak kırılmaya çalışılır. Hash değil, veri kırılır(doğru tahmin üretilerek). – Bu saldırı saniyede milyarlarca deneme yapacak şekilde yapabilir. Yani mümkün!

89. Hashcat (Tool) https://hashcat.net/hashcat/

90. Salt ve Brute Force Saldırıları Hash’li bir parolayı kırmak kolaydır. Sadece Google’la… Salt bir parola şifrelenmeden önce kendisine eklenebilen dizedir. – Yani, aynı parolaya eşsiz salt’lar uygulandığında şifre çıktısı farklı olur. – Salt, şifreli parola ile birlikte veritabanında depolanır, böylece kullanıcı oturum açtığında işlem tekrarlanabilir. Salted Hashes’leri Brute Force’lamak – Salt, bir hash’i kırmayı zorlaştırır, ancak bu sadece bir zaman meselesidir. – Eğer hash’ler hızlı oluşturulduysa, hızlı şekilde de kırılabilir.

91. Salt ve Brute Force Saldırıları (Salted Hashes’leri Brute Force’lamak) Salt, bir hash’i kırmayı zorlaştırır, ancak bu sadece bir zaman meselesidir. Eğer hash’ler hızlı oluşturulduysa, hızlı şekilde de kırılabilir. Modern GPU’lar hash hesaplamalarında oldukça verimlidir. http://project-rainbowcrack.com/table.htm http://md5-database.org/sha1/P@ssw0rd

92. Hash Implementation NuGet – BCrypt.NET – Zetetic.Security

93. Diğer Hususlar Yavaş hashing parola güvenliğini savunmak için daha iyidir. Web sunucular hashing konusunda CPU ile daha yavaştır. – Ama saldırganlar GPU ile daha hızlı iş yapar. Hashing algoritmasını daha sonra değiştirip/yükseltmek mümkündür. Hashing gereksinimleri proje ihtiyacına göre belirlenir. Her işe uygun tek hashing yöntemi yoktur.

94. Symmetric & Asymmetric Encryption Simetrik şifreleme encryption ve decryption için tek bir private key içerir. – Anahtarların hiçbir zaman harici olarak dağıtılması gerekmeyen bir uygulama içindeki verileri şifrelemek için sıkça kullanılır. Asimetrik şifreleme public ve private key’e sahiptir. – Public Key Encryption diye isimlendirilebilir. – SSL’de asimetrik şifreleme kullanılır. Hashing’in aksine encryption geri dönüştürülebilir ve veri elde edinilebilir. – Encryption çift yönlüdür. – Hashig encryption değildir.

95. Failure to Restrict URL Access {OWASP} www.cihanozhan.com

96. ASP.NET’de Erişim Kontrolleri Web.config içerisinde location elemanını kullanarak (X)X Principal Permission’ları kullanarak sınıflardaki metotlarda…(X, X)X MVC kontrol sınıflarında authorize attribute ile… MVC kontrol action’larında authorize attribute ile… ASP.NET identity ve role özellikleriyle…

97. Insufficient Transport Layer Protection {OWASP} www.cihanozhan.com

98. Nedir? İki endpoint arasında akan trafik güvenliğinin uygun şekilde sağlanamaması sonuncu ortaya çıkar. https://www.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities_- _Insufficient_Transport_Layer_Protection

99. Çözüm Tüm tarayıcıların güvenli bağlantıya zorlanması için HSTS uygulanmasını sağla. Sunucudaki SSL konfigürasyonunun uygun şekilde yapıldığından emin ol : – Tüm zayıf SSL/TLS protokollerini devre dışı bırak(SSLv2 gibi). – Tüm zayıf export algoritmalarını devre dışı bırak(DES, RC4-40, DHE-RSA-Export gibi) – Session key size’ının minimum 128 bit olduğundan emin ol. – Minimum 2048 bitlik SSL sertifikası kullandığından emin ol. – MD5 hash algoritmasını kriptografi için kullanma! – RC4 algoritmasını kullanma! – Ananim anahtar oluşturma algoritmalarını devre dışı bırak. – Şifreleme gerktirmeyen algoritmaları devre dışı bırak(NULL, eNULL). HTTP Strict Transport Security(HSTS)’e zorla. Tüm HTTP isteklerini HTTPS’e yönlendir.

100. Unvalidated Redirects and Forwards {OWASP} www.cihanozhan.com

101. Nedir? Temelde redirect işleminde uzak bir uygulamaya erişim gerçekleştirilirken, forwarding işleminde local uygulamanın bir dosyasına erişim söz konusudur. Doğrulanmamış yönlendirmeler, mağdurun hedef sitedeki güvenini kötüye kullandıkları için saldırganlar için yararlıdır. Şüphe uyandırabilecek bir URL: –http://kotucocuklar.com/siyah_kotu_cocuk.exe Ama şu güvenli bir yol olurdu: –http://iyicocuklar.com/redirect?url=

102. Tespit Parametrelerin yaptığı yönlendirme için bir WhiteList oluşturulup oluşturulmadığı incelenebilir. Sadece WhiteList içerisindeki bağlantılara yönlendirme gerçekleştirilebilmelidir. Crawler ile HTTP Response kodları incelenip redirect yapılan bölümler tespit edilebilir(Örn: HTTP Response 302, [300 … 307]).