master doc

JAVA PROQRAMLAŞDIRMA

MÜHİTİNDƏ TƏHLÜKƏSİZ

PROQRAM TƏMİNATININ

HAZIRLANMA TEXNOLOGİYALARI

Qafqaz universiteti

Kompyuter Mühəndisliyi bölümü

Magistr Samir Həsənov

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ı

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

Java proqramlaşdırma dilinin buraxılışları

• Java Standard Edition

• Java Card texnologiyası

• Java Enterprise Edition

• Java Micro Edition

Java SE təhlükəsizliyi

• Platforma təhlükəsizliyi

• Kriptoqrafik imkanlar

• Təhlükəsiz kommunikasiya

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)

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)

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)

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ı

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.

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

İ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();

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

Veb və Java Veb Texnologiyaları

• İnternet anlayışı

• Hypertext Transfer Protocol (HTTP)

• Java Veb texnologiyalar

• Servlets

• Java Server Pages

• JSP Tag Library

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

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.

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>

<% } %>

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());

}

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

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

Ə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ə icraolunur. İ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

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ə

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

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.

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

XSS qorunma prinsipləri

• <script>...GÜVƏNİLMƏYƏN MƏLUMAT OLMAMALI BURADA...</script> script daxilində

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

2. < --> <

3. > --> >

4. " --> "

5. ' --> '

6. / --> /

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))%>”);

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 hesabnömrəsi yazaraq linkə keçir. Əgər düzgün yoxlama keçilməyibsə o zamanhü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

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.

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ə özhesab nömrəsini yazır, düzəltdiyi linki öz idarəsi altında olan hər hansı zərərli saytdaHTML <img> teqinin “src” atributu altında və ya digər iframe elementində saxlayır.

<imgsrc="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#" 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.

http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243

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>

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.

master doc

Software