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

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. 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. 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. Java proqramlaşdırma dilinin buraxılışları
• Java Standard Edition
• Java Card texnologiyası
• Java Enterprise Edition
• Java Micro Edition

5. Java SE təhlükəsizliyi
• Platforma təhlükəsizliyi
• Kriptoqrafik imkanlar
• Təhlükəsiz kommunikasiya

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. 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. 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. 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. 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. İ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. İ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. Ə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. Veb və Java Veb Texnologiyaları
• İnternet anlayışı
• Hypertext Transfer Protocol (HTTP)
• Java Veb texnologiyalar
• Servlets
• Java Server Pages
• JSP Tag Library

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. 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. 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. 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. 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. 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. Ə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. 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. 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. 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. 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. 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. ' --> &#x27;
6. / --> &#x2F;

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. 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. 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. 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. 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. 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.