Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Java proqramlaşdirma mühitində təhlükəsiz proqram təminatinin hazirlanma texnologiyalari

542 views

Published on

Java proqramlaşdirma mühitində təhlükəsiz proqram təminatinin hazirlanma texnologiyalari

Published in: Software
  • Be the first to comment

  • Be the first to like this

Java proqramlaşdirma mühitində təhlükəsiz proqram təminatinin hazirlanma texnologiyalari

  1. 1. JAVAPROQRAMLAŞDIRMAMÜHİTİNDƏ TƏHLÜKƏSİZ PROQRAM TƏMİNATININ HAZIRLANMATEXNOLOGİYALARI Irkan Əhmədov Bakı Dövlət Universiteti Komputer Mühəndisliyi
  2. 2. Kompyuter təhlükəsizliyi anlayışı • Təhlükəsizlik anlayışının mənaları • Uğurlu hücumların əsas səbəbi nədir? • Proqram təminatının təhlükəsizlik dizaynı
  3. 3. Java proqramlaşdırma dili • Sun Microsystems (James Gosling) • Java 1.0 1995-ci ildə buraxılmışdır • Hazırda Oracle şirkətinin məhsuludur • Sadə, obyekt yönümlü • Təhlükəsiz • Kross platform proqramlaşdırma • Yüksək performans • Multithreading dəstəyi
  4. 4. Java proqramlaşdırma dilinin buraxılışları • Java Standard Edition • Java Card texnologiyası • Java Enterprise Edition • Java Micro Edition
  5. 5. Java SE təhlükəsizliyi • Platforma təhlükəsizliyi • Kriptoqrafik imkanlar • Təhlükəsiz kommunikasiya
  6. 6. Java platforması təhlükəsizliyi Java kompilyatoru və Java Virtual Maşını tərəfindən həyata keçirilən təhlükəsizlik: • Ciddi tipləşdirilmə qaydaları (strong typing) • Avtomatik yaddaş idarəsi (Garbage collection, etc) • Baytkod yoxlanılması (Bytecode verification) • Sinifin təhlükəsiz yüklənməsi (Secure class loading)
  7. 7. Java kriptoqrafiya dəstəyi Təhlükəsiz şifrələmə və xeşləmə üçün kompleks APİ: • Rəqəmsal imza (Signature.getInstance(...)) • Mesaj digest (MessageDigest.getInstance("SHA-256")) • Şifrlər (asimmetrik, simmetrik, blok, axın) • Mesaj Autentikasiya Kodu (MAC) • Açar generasiyası (KeyGenerator)
  8. 8. Java təhlükəsiz kommunikasiya dəstəyi Məlumat mübadiləsinin tamlığını qoruyan APİ: • TLS (Transport Layer Security) • SSL (Secure Socket Layer) • SASL (Simple Application and Security Layer)
  9. 9. Java SE təhlükəsiz kodlaşdırma nümunələri • Məxfi məlumatla işləmək prinsipləri • Məxfi məlumatın loqlanması və saxlanılması • İnyeksiya hücumlarında qorunma metodları • İcra olunan məlumatların yoxlanılması metodları
  10. 10. Məxfi məlumatla işləmək prinsipləri • Məxfi məlumatı istisnaların (exceptions) daxilində yerləşdirməyin. Exception obyektləri məxfi məlumatı ötürə bilərlər. Misal üçün, əgər metod daxili konfiqurasiya faylını oxumaq üçün “java.io.FileİnputStream” sinifinin konstruktoruna müraciət edirsə və göstərilən fayl tapılmırsa, o zaman axtarılan faylın fayl sistemində yolunu əks edən “java.io.FileNotFoundException” atılır. Bu exceptionun metodu çağıran şəxsə göndərilməsi artıq fayl sistemin strukturunu gösrmək kimi təhlükəsizlik boşluğu yaradır. • Yüksək həssas məlumatı loqlamayın. Bank kart nömrələri kimi məlumatlar yüksək həssas məlumat sayılır. Belə məlumat lazım olduğundan artıq saxlanıla bilməz və hər hansı bir şəxs tərəfindən, proqram administratoru olduqda belə, görülə bilməz. Misal üçün, heç bir loq faylında kart nömrələri göstərilməməli, göstərilsə belə yalnız mask olunmuş halda (1234 **** **** 4321) göstərilməli və heç bir axtarış zamanı bu məlumatlar icra olunmamalıdırlar. Bəzi keçid məlumatları simvol massivi (char[]) kimi dəyişə bilən verilənlər strukturunda saxlanılmalı və məlumat yerinə yetiriləndən sonra təmizlənməlidirlər.
  11. 11. İnyeksiya hücumları və qorunma • Məlumatı düzgün formatlayın. İnyeksiya hücumları əsasən mətn daxilindəki xüsusi simvollardan istifadə etmək, düzgün olmayan azad etmə simvollarında (escape characters) və ya hər hansı xüsusi simvolları silmək yolu ilə həyata keçirilir. Daxil olan mətn məlumatının xüsusi formada olacağını nəzərə alaraq bir başa icra etmək səhv fikir sayıla bilər və böyük təhlükəsizlik boşluqları yarada bilər. Yoxlamadan əvvəl mütləq mətnin parçalanması və kanonizasiyası yerinə yetirilməlidir. Əgər mümkündürsə, düzgün olmayan məlumatı düzəltməkdənsə bir başa mətnin daxilində kəsib tullayın. • Dinamik SQL-dən çəkinin. Yaxşı məlumdur ki, təhlükəli kodla generasiya olunmuş dinamik SQL sorğuları əmr inyeksiyaları ilə nəticələnir. Bu, adətən daxil olan məlumatlara səhv dirnaq işarəsi (“) qoymaqla baş verir. Dinamik SQL-dən çəkinin. Java proqramlaşdırma mühitində Java Database Connectivity (JDBC) ilə işləyən zaman “java.sql.Statement” əvəzinə “java.sql.PreparedStatement” və ya “java.sql.CallableStatement” interfeyslərindən istifadə edin.
  12. 12. İnyeksiya hücumları və qorunma Təhlükəsli dinamik SQL nümunəsi Connection connection = getConnection(); String query = "select * from users u where u.name = '" + name + "' order by u.id"; Statement statement = connection.createStatement(); ResultSet resultSet = statement.executeQuery(query); Düzgün SQL sorğusu Connection connection = getConnection(); final String query = "select * from users u where u.name = ? order by u.id"; PreparedStatement preparedStatement = connection.prepareStatement(query); preparedStatement.setString(1, name); ResultSet resultSet = preparedStatement.executeQuery();
  13. 13. Əmr inyeksiyası Etibarsız məlumatın CMD-yə düzməsinin qarşısını alın. Əgər sizin proqram istifadəçini sorğusundan asılı olaraq yeni proseslər yaradırsa, o zaman etibarsız və səhv məlumatın CMD (Command Line) düşməməsinə diqqət yetirin. Bu halda davranış platformadan asılı, az sənədləşdirilmiş, nəticələri isə çox təhlükəli və maraqlı ola bilər. Zərərli məlumat hər hansı arqumentin digər opsiya kimi icra olunmasına gətirib çıxara bilər. Misal üçün, Windows əməliyyat sistemində olan “/” papka keçid simvolu. Hər hansı prosesə ötürülən məlumat şifrələnmiş şəkildə (məs. Base64) müvəqqəti faylda saxlanılmalı və ya keçid kanal vasitəsilə ötürülməlidir.
  14. 14. Veb və Java Veb Texnologiyaları • İnternet anlayışı • Hypertext Transfer Protocol (HTTP) • Java Veb texnologiyalar • Servlets • Java Server Pages • JSP Tag Library
  15. 15. Java Veb Texnologiyalarının təhlükəsizlik prinsipləri • Security in depth • Pozitiv təhlükəsizlik modeli istifadə edin • Xəta edərkən təhlükəsiz edin
  16. 16. Security in depth prinsipi • Məqsəd odur ki, bir neçə səviyyə təhlükəsizlik ümumi veb tətbiqin təhlükəsiz olmasına cavab verə bilər. Əgər hər hansı hücum bu səviyyələrdən birinin iş prinsipini pozarsa digər səviyyələr lazım olduğu qədər təhlükəsizlik təqdim edəcəkdir. Misal üçün, şirkət daxili proqram təminatinin təhlükəsizliyini tamamilə brandmauerə (fayrvol) etibar etmək düzgün seçim deyil, çünki fayrvol bəzi hallarda hücumçu tərəfindən iqnor edilə bilər. Fayrvol ilə yanaşı digər təhlükəsizlik metodları da əlavə olunmalıdır. • Bundan fərqli olaraq istifadəçi adı və şifrə autentikasiya sisteminə bir də smart kart autentikasiya əlavə edə bilərsiniz ki, bu da təhlükəsizlik üçün əlavə səviyyə deməkdir.
  17. 17. Pozitiv təhlükəsizlik modeli • “Pozitiv” təhlükəsizlik (həmdə “ağ siyahı”) yalnız icazə veriləni buraxır və digər hər şeyi rədd edir. “Neqativ” (“qara siyahi”) modeli isə icazə verilməyəndən başqa bütün əməliyyatları buraxır. Pozitiv təhlükəsizlik modelinin istifadəsinin üstünlükləri ondan ibarətdir ki, proqramçının hazırda nəzərə almadığı hücumların artıq qarşısı alınmış olur. Digər halda isə, neqativ model ilə hər hücumun qarşısını almaq yorucu və riskli iş ola bilər. Nümunə: <% if (accessController.isAuthorizedForFunction( ADMIN_FUNCTION ) ) { %> <a href="/doAdminFunction">ADMIN</a> <% } else { %> <a href="/doNormalFunction">NORMAL</a> <% } %>
  18. 18. Təhlükəsiz xəta prinsipi • Proqramçı kimi bilməlisiniz ki, hər təhlükəsizlik mexanizm tətbiq etməyin 3 üsulu var: 1. Əməliyyata icazə vermək 2. Əməliyyatı blok etmək 3. Xəta (Exception) • Ümumi olaraq siz kodunu elə yazmalısnız ki, hər hansı atılan xəta əməliyyatın blok edilməsi bəndi ilə eyni yolu bölüşsün. Misal üçün, isAuthorized(), isAuthenticated() və validate() kimi metodlar xəta baş verdikdə hər biri “false” qaytarmalıdırlar. Yanlış kod: boolean isAdmin = true; try { codeWhichMayFail(); isAdmin = isUserInRole("Administrator"); } catch (Exception ex) { log.write(ex.toString()); } Düzgün kod: boolean isAdmin = false; try { codeWhichMayFail(); isAdmin = isUserInRole("Administrator"); } catch (Exception ex) { log.write(ex.toString()); }
  19. 19. Geniş yayılmış veb proqram hücumları • İnyeksiya • Natamam autentikasiya və sessiya idarəsi • Cross-Site Scripting (XSS) • Obyektlərə birbaşa etibarsız müraciətlər • Saytlar arası sorğu saxtakarlığı (Cross-Site Request Forgery (CSRF))
  20. 20. SQL İnyeksiya • SQL inyeksiya ən təhlükəli veb hücumlardan biridir. Çox böyük qüsurdur, belə ki, SQL inyeksiya hücumçuya proqramın istifadə etdiyi sql sorğularını dəyişməklə verilənlər bazasında məlumatı oxumaq, dəyişmək və ya silmək şəraiti yaradır. • Əsas müdafiə mexanizmləri: 1. Prepared Statement istifadə edin (Parametrləşdirilmiş sorğular) 2. Prosedur dilindən istifadə edin 3. İstifadəçinin daxil etdiyi məlumatları təmizləyin
  21. 21. Əmr inyeksiyası • Əmr inyeksiya hücumu host kompyuter əməliyyat sistemində zərərli proqrm vasitəsilə ixtiyari əmrləri icra etməyə deyilir. Bu hücum istifadəçidən gələn hər hansı zərərli əlumatın birbaşa “shell”-ə ötürülməsiylə baş verir. Bu zaman ötürülən əmrlər veb tətqbiqin privilegiyaları ilə icra olunur. İnput məlumatlarının validasiyasına lazımınca diqqət ayrılmadığından bu tip hücumlar çox geniş yayılmışdır. • Nümunə: Runtime runtime = Runtime.getRuntime(); Process process = runtime.exec("cat " + file); process.waitFor(); log.info(String.format("Successfully executed command. Command: %s", command) Normalda bu əmrin nəticəsi adı keçən faylın məzmunu olmalıdır: $ cat Story.txt Some text... Amma əgər biz fayl adından sonar nöqtəli vergül və başqa əmr əlavə etsək: $ cat "Story.txt; ls" Some text... Story.txt doubFree.c nullpointer.c unstosig.c www* a.out* format.c strlen.c
  22. 22. Natamam autentikasiya və sessiya idarəsi Baş vermə səbəbləri: 1. İstifadəçi autentikasiya məlumatları şifrələmə və ya xeşləmə istifadə olunmadan açıq şəkildə bazada saxlanıldıqda 2. Zəif hesab idarəçiliyi sitemində istifadəçilərin şifrələri ehtimal oluna bilər və ya dəyişdirilə bilər 3. Sessiya İD-lər URL vasitəsilə ifşa olunduqda 4. Sessiyanın vaxtı bitmədikdə və ya logout zamanı sessiya düzgün ləğv edilmədikdə 5. Loqin zamanı sessiya İD-ləri düzgün generasiya olunmadıqda 6. Şifrələr, sessiya id-lər və digər həssas məlumatlar şifrələnməmiş şəbəkə üzərindən göndərildikdə
  23. 23. Natamam autentikasiya və sessiya idarəsi Qarşısını almaq üçün prinsiplər. • Autentikasiya ümumi qaydaları: 1. Şifrənin uzunluğu 2. Şifrənin mürəkkəbliyi 3. Təhlükəsiz şifrə bərpası mexanizmi reallaşdırmaq 4. Şifrələri verilənlər bazasında təhlükəsiz formada saxlayın 5. Həssas funksionallıqları yerinə yetirərkən yenidən autentikasiya tələb edin 6. Multifaktor autentikasiya təmin edin (OTP) 7. Autentikasiya zamanı düzgün xəta mesajları göstərin
  24. 24. XSS hücumları • Stored XSS. Stored XSS (daimi, saxlanılmış XSS) o zaman baş verir ki, əgəgr hər hansı skript server tərəfdə verilənlər bazasında və ya hər hansı saxlama metodu ilə saxlanılıbsa. Və adi istifadəçilər bu məlumatı düzgün təmizlənmədən birbaşa brauzerdə görürlər. HTML5 kimi texnologiyaların köməyi ilə hücumçu XSS skriptlərini serverə göndərmədən birbaşa klientin brauzerindəki lokal verilənlər bazasında saxlaya bilər. • Reflected XSS. İstifadəçi tərəfindən daxil olunan məlumat təmizlənmədən və zərəsizləşdirilmədən, http sorğunun bir hissəsi olursa və bu məlumat brauzer tərəfindən render olunursa bu zaman reflected xss baş vermə riski var. Belə hallar adətən nəticəsi tapılmayan axtarış zamanı, hər hansı xəta mesajı göstərmə zamanı baş verir. • DOM-based XSS. İlk dəfə öz məqaləsində bu qüsur haqqında məlumat vermiş Amit Kleyn dediyi kimi “DOM-based XSS zamanı həm zərəli məlumat həm də o məlumatı emal edən faktor ikisi də brauzerdə yerləşir”. Misal üçün, zərəli məlumatın oxunduğu mənbə həmin səhifənin URL-i ola bilər və bu məlumatı düzgün şəkildə emal etməyən funksiya isə həmin səhifə daxilində yerləşən hər hansı biri ola bilər. • Server XSS. Server XSS serverdən qayıdan hər hansı HTTP cavabın daxilində zərərli skript olanda baş verir. • Klient XSS. Klient XSS istifadəçi tərəfindən daxil olan məlumatın təhlükəli javascript funksiyası ilə dokument object modeli yeniləməyə çalışması zamanı baş verir.
  25. 25. XSS hücum nümunələri • Nümunə 1: <% String eid = request.getParameter("eid"); %> ... Employee ID: <%= eid %> • Nümunə 2: <% Statement stmt = connection.createStatement(); ResultSet rs = stmt.executeQuery("select * from emp where id="+eid); if (rs != null) { rs.next(); String name = rs.getString("name"); } %> Employee Name: <%= name %>
  26. 26. XSS qorunma prinsipləri • <script>...GÜVƏNİLMƏYƏN MƏLUMAT OLMAMALI BURADA...</script> script daxilində • <!--... GÜVƏNİLMƏYƏN MƏLUMAT OLMAMALI BURADA...--> HTML komment • <div ... GÜVƏNİLMƏYƏN MƏLUMAT OLMAMALI BURADA...=test /> atribut adi yerində • <GÜVƏNİLMƏYƏN MƏLUMAT OLMAMALI BURADA... href="/test" /> tag adı yerinə Təhlükəsizlik təmin etmək üçün növbəti simvolları hökmən HTML səhifədən təmizləməyi unutmayın: 1. & --> &amp; 2. < --> &lt; 3. > --> &gt; 4. " --> &quot; 5. ' --> ' 6. / --> /
  27. 27. DOM-Based XSS qorunması Təhlükəli nümunə: <script> var x = ‘<%= xss %>’; var d = document.createElement(‘div’); d.innerHTML = x; document.body.appendChild(d); </script> Təhlükəli metodlar: element.innerHTML = “<HTML> Tags and markup”; element.outerHTML = “<HTML> Tags and markup”; document.write(“<HTML> Tags and markup”); document.writeln(“<HTML> Tags and markup”); Qorunmanın əsas prinsipləri: • HTML encode etmək • Bütün güvənilməz məlumatın javascript escape olunması Nümunə: element.innerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(u ntrustedData))%>”; element.outerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(u ntrustedData))%>”; document.write(“<%=Encoder.encodeForJS(Encoder.enc odeForHTML(untrustedData))%>”); document.writeln(“<%=Encoder.encodeForJS(Encoder.e ncodeForHTML(untrustedData))%>”);
  28. 28. Obyektlərə birbaşa etibarsız müraciət hücumu • Nümunə hücum ssenarisi Veb proqram yoxlama keçməyən hesab nömrəsi parametrini bazaya sorğu şəklində göndərir və hesab haqqında məlumat alır: String query = "SELECT * FROM accts WHERE account = ?"; PreparedStatement pstmt = connection.prepareStatement(query); pstmt.setString( 1, request.getParameter("acct")); ResultSet results = pstmt.executeQuery Hücumçu sadəcə brauzerdə “acct” dəyişən parametrinə müxtəlif hesab nömrəsi yazaraq linkə keçir. Əgər düzgün yoxlama keçilməyibsə o zaman hücumçu istənilən hesab nömrəsinin məlumatlarına belə baxa bilər. http://example.com/app/accountInfo?acct=digərHesabNömrəsi
  29. 29. OBEM qarşısının alınması • Hər istifadəçi və ya aktiv sessiya üçün dolayı obyektə müraciət seçin. Bu metod hücumçuya məhdudlaşdırılmış məlumata birbaşa müraciətinin qarşısını alacaq. Misal üçün, hər hansı məlumatın verilənlər bazadakı açar sözünü işlətmək əvəzinə, hazırki istifadəçinin görə biləcəyi məlumatların listi açıla bilər və hər element açar söz ilə yox 1,2,3 və s. rəqəmlə işarələnə bilər. İstifadəçinin seçdiyi məlumatdan asılı olaraq serverdə sessiyada saxlanılan funksiya vasitəsilə göndərilən simvo (1,2,3 və s.) real məlumat açar sözünə çevrilir. Bu zaman istifadəçiyə göstərdiyiniz məlumatları random və ya Java GUİD istifadə etməklə təmin edə bilərsiniz. • Hüquqların yoxlanılması. Güvənilməyən mənbədən gələn hər hansı obyektə birbaşa əlaqə sorğusu serverdə hüquq yoxlanılması keçməlidir. Yoxlama zamanı istifadəçinin birbaşa müraciət etdiyi məlumatı görmək hüququ olub-olmadığı yoxlanılacaq və uyğun cavab göstəriləcəkdir.
  30. 30. Cross-site request forgery (CSRF) • Hücum ssenarisi Veb proqram istifadəçinin ciddi əməliyyatını heç bir gizli məlumat və ya token istifadə etmədən yerinə yetirir. Misal üçün: http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243 • Belə boşluq görən hücumçu saxta link düzəldərək “destinationAccount” hissəsinə öz hesab nömrəsini yazır, düzəltdiyi linki öz idarəsi altında olan hər hansı zərərli saytda HTML <img> teqinin “src” atributu altında və ya digər iframe elementində saxlayır. <img src="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackers Acct#" width="0" height="0" /> Əgər zərərçəkən hücumçunun link qoyduğu saytlara daxil olarkən “example.com” saytında aktiv sessiyası olarsa o zaman CSRF hücumu uğurla nəticələnir.
  31. 31. CSRF Qorunma • Gizli tokenlərin HTML form daxilində “hidden field”-lər ilə göndərilməsidir. Bu zaman token HTTP sorğunun daxilində olduğundan onu yolda dəişmək daha da çətinləşəcək. • Unikal token URL özünə də birbaşa əlavə oluna bilər. Lakin bu yol məsləhət görülmür, belə ki, açıq şəkildə URL-də görünən token təhlükəsizlik riski yarada bilər. • Ciddi əməliyyat keçirməzdən əvvəl istifadəçinin yenidən autentikasiya keçməsi və ya Captcha yoxlaması keçməsi də CSRF hücmularına qarşı qoruya bilər. • Sinxron token mexanizmi. Bu zaman hər istifadəçi sessiyasın uyğun serverdə unikal random token generasiya olunur və istifadəçinin bütün ciddi əməliyyat keçirə biləcək formlarına “hidden field”-lərə əlavə olunur. İstifadəçi hər hansı əməliyyat keçirdikdə bu token də HTTP sorğu daxilində serverə göndərilir, serverdə istifadəçinin real tokeni ilə müqayisə olunur və doğru olduğu zaman əməliyyat yerinə yetirilir. Token maksimum dərəcədə random və təhlükəsiz olması üçün “java.security.SecureRandom” sinifindən istifadə edə bilərsiniz. Alternativ yol kimi 256-bit BASE64 kodlaşdırılmış xeşlərdən istifadə edə bilərsiniz. <form action="/transfer.do" method="post"> <input type="hidden" name="CSRFToken" value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWE... wYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZ... MGYwMGEwOA=="> </form>
  32. 32. CSRF Qorunma • CSRF hücumlarının qarşısını almaq üçün token istifadə etmək alınmırsa digər texnikalardan istifadə edə bilərsiniz. Ən məşhur üsullar: 1. CAPTCHA 2. Re-autentikasiya 3. Birdəfəlik şifrə (OTP) Saydığım metodlar ən yüksək müdafiə mexanizmi sayılır, əsasən daha onlayn bankçılıq və s. ciddi veb proqramlarda istifadə olunur.

×