nghiÊn cỨu tỔng hỢp cÁc cÔng cỤ phÁt hiỆn lỖi phẦn …

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

LÊ THẾ HUY

NGHIÊN CỨU TỔNG HỢP CÁC CÔNG CỤ PHÁT HIỆN LỖI PHẦN

MỀM ĐỂ GIẢM CẢNH BÁO SAI

Ngành: Công nghệ thông tin

Chuyên ngành: Kỹ thuật phần mềm

Mã số: 8480103.01

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS. TS. TRƯƠNG ANH HOÀNG

Hà Nội - 2020

1

MỤC LỤC

DANH MỤC HÌNH ẢNH ............................................................................................. 3

DANH MỤC BẢNG BIỂU ........................................................................................... 4

DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT .................................................. 5

LỜI CẢM ƠN ................................................................................................................ 6

LỜI CAM ĐOAN .......................................................................................................... 7

Chương 1. GIỚI THIỆU ĐỀ TÀI VÀ CÁC CÔNG CỤ SỬ DỤNG PHÂN TÍCH

MÃ NGUỒN ................................................................................................................... 8

1.1. Giới thiệu đề tài ................................................................................................ 8

1.2. Các công cụ được sử dụng trong nghiên cứu ................................................ 8

1.2.1. Công cụ phân tích SonarQube ............................................................... 8

1.2.2. Công cụ phân tích HuntBugs ............................................................... 12

1.2.3. Công cụ phân tích PMD [6] ................................................................. 12

1.2.4. Công cụ phân tích IntelliJ IDE ............................................................ 14

1.2.5. Công cụ phân tích VCG [11] ................................................................ 18

1.2.6. Công cụ phân tích SpotBugs [8] .......................................................... 19

1.2.7. Công cụ phân tích Infer ....................................................................... 19

1.3. Đánh giá hiệu suất .......................................................................................... 21

1.4. Bộ thử nghiệm (Test Suite) ............................................................................ 21

1.5. Các lớp yếu điểm(CWE) ................................................................................ 22

Chương 2. PHƯƠNG PHÁP VA TIẾN HANH THỰC NGHIỆM ......................... 23

2.1. Phương pháp nghiên cứu .............................................................................. 23

2.1.1. Chiến lược nghiên cứu ......................................................................... 23

2.1.2. Phương pháp tạo dữ liệu ...................................................................... 23

2.1.3. Phân tích dữ liệu ................................................................................... 24

2.2. Tiến hành thử nghiệm ................................................................................... 24

2.2.1. Bộ dữ liệu kiểm thử Juliet phiên bản 1.3 ............................................ 24

2

2.2.2. Quá trình chạy công cụ ........................................................................ 28

2.2.3. Tổng hợp dữ liệu ................................................................................... 31

2.2.4. Viết công cụ phân tích dữ liệu ............................................................. 32

2.2.5. Thực hiện phân tích dữ liệu ................................................................. 33

Chương 3. KẾT QUẢ VA ĐÁNH GIÁ ...................................................................... 43

3.1. Kết quả ............................................................................................................ 43

3.1.1. Phân tích không theo tiêu chuẩn CWE ............................................... 43

3.1.2. Phân tích theo từng danh mục chuẩn CWE ....................................... 43

3.1.3. Phân tích tổ hợp công cụ không theo chuẩn CWE ............................. 45

3.1.4. Phân tích tổ hợp theo chuẩn CWE ...................................................... 45

3.2. Đánh giá .......................................................................................................... 48

3.2.1. Phân tích không theo chuẩn CWE ...................................................... 48

3.2.2. Phân tích theo chuẩn CWE .................................................................. 49

Chương 4: KẾT LUẬN ............................................................................................... 50

Tài liệu tham khảo ....................................................................................................... 51

3

DANH MỤC HÌNH ẢNH

Hình 1.1: 4 thành phần chính của SonarQube [1] ........................................................... 9

Hình 1.2: Các ngôn ngữ SonarQube hỗ trợ ................................................................... 10

Hình 1.3: Cách thức hoạt động của SonarQube ............................................................ 11

Hình 1.4: Lỗi NullPointer trước khi sửa ........................................................................ 15

Hình 1.5: Lỗi NullPointer sau khi sửa ........................................................................... 15

Hình 1.6: Mã nguồn không được sử dụng (mã “chết”) ................................................. 16

Hình 1.7: Mã nguồn trước khi xử lý chuỗi .................................................................... 16

Hình 1.8: Mã nguồn sau khi xử lý chuỗi ....................................................................... 16

Hình 1.9: Lỗi đặt vi pham quy tắc đặt tên biến ............................................................. 17

Hình 1.10: Vi phạm đặc điểm kỹ thuật EJB .................................................................. 17

Hình 1.11: Sau khi đã sửa vi phạm kỹ thuật EJB .......................................................... 18

Hình 2.1: Cấu trúc mã nguồn ........................................................................................ 25

Hình 2.2: Phương thức bad() ......................................................................................... 26

Hình 2.3: Lỗi SQL Ịnjection .......................................................................................... 26

Hình 2.4: Phương thức goodG2B() ............................................................................... 27

Hình 2.5: Phương thức goodB2G() ............................................................................... 27

Hình 2.6: Các tiêu chí của SonarQube .......................................................................... 28

Hình 2.7: Các tiêu chí của HuntBugs ............................................................................ 29

Hình 2.8: Các tiêu chí của PMD .................................................................................... 29

Hình 2.9: Các tiêu chí của IntelliJ IDE.......................................................................... 30

Hình 2.10: Các tiêu chí của VCG .................................................................................. 30

Hình 2.11: Các tiêu chí của SpotBugs ........................................................................... 31

Hình 2.12: Các tiêu chí của Infer ................................................................................... 31

Hình 2.13: Chuẩn hóa dữ liệu đầu vào .......................................................................... 32

4

Hình 2.14: Cú pháp lệnh trong Java. ............................................................................. 32

Hình 2.15: Tệp dữ liệu đầu vào của công cụ SonarQube .............................................. 33

Hình 2.16: Ví dụ xác thực và kiểm soát truy cập .......................................................... 34

Hình 2.17: Ví dụ chất lượng mã nguồn ......................................................................... 35

Hình 2.18: Ví dụ quản lý luồng kiểm soát..................................................................... 35

Hình 2.19: Ví dụ mã nguồn có lỗi không mã hóa thông tin mật khẩu .......................... 36

Hình 2.20: Ví dụ mã hóa và tính ngẫu nhiên ................................................................. 36

Hình 2.21: Ví dụ xử lý lỗi.............................................................................................. 37

Hình 2.22: Ví dụ xử lý tệp tin ........................................................................................ 37

Hình 2.23: Ví dụ lỗi rò rỉ thông tin ................................................................................ 38

Hình 2.24: Ví dụ khởi tạo và đóng tài nguyên .............................................................. 38

Hình 2.25: Ví dụ Injection ............................................................................................. 39

Hình 2.26: Ví dụ phần mềm độc hại.............................................................................. 40

Hình 2.27: Ví dụ phần mềm độc hại.............................................................................. 40

Hình 2.28: Mã nguồn gây ra lỗi NullPointer ................................................................. 41

Hình 2.29: Ví dụ xử lý con trỏ và tham chiếu ............................................................... 41

Hình 2.30: Ví dụ trùng bản ghi của SonarQube ............................................................ 42

Hình 2.31: Ví dụ trùng bản ghi của HuntBugs .............................................................. 42

DANH MỤC BẢNG BIỂU

Bảng 2.1: Bảng mẫu dữ liệu chuẩn hóa ......................................................................... 23

Bảng 3.1: Bảng dữ liệu phân tích đơn công cụ ............................................................. 43

Bảng 3.2: Bảng phân tích đơn công cụ theo chuẩn CWE ............................................. 43

Bảng 3.3: So sánh phân tích đơn công cụ và phân tích tổ hợp công cụ ........................ 49

5

Biểu đồ 3.1: Biểu đồ tính hiệu suất của từng công cụ ................................................... 43

DANH MỤC CÁC KÝ HIỆU VA CHỮ VIẾT TẮT

Từ viết tắt Thuật ngữ tiếng anh Thuật ngữ tiếng việt

API Application Programming Interface Giao diện lập trình ứng dụng

DFA Data Flow Analysis Phân tích luồng dữ liệu

CWE Common Weakness Enumeration Liệt kê điểm yếu chung

OWASP Open Web Application Security

Project

Là tổ chức phi lợi nhuận và

đưa ra chuẩn OWASP phục

vụ cho công việc pentest hiệu

quả và chi tiết

MISRA Motor Industry Software Reliability

Association

Hiệp hội Độ tin cậy Phần

mềm Công nghiệp Động cơ

AST Abstract Syntax Tree Cây cú pháp trừu tượng

6

LỜI CẢM ƠN

Trước tiên học viên xin dành lời cảm ơn chân thành và sâu sắc đến thầy giáo,

PGS. TS. Trương Anh Hoàng và PGS. TS. Nguyễn Đức Anh – Hai thầy đã hướng dẫn,

chỉ bảo nhiệt tình và tạo điều kiện tốt nhất từ khi bắt đầu thực hiện đến khi kết thúc

công việc của mình.

Học viên xin dành lời cảm ơn chân thành đến các thầy cô khoa công nghệ thông

tin, trường Đại học Công Nghệ, ĐHQGHN đã tận tình đào tạo, cung cấp cho các kiến

thức vô cùng quý và bổ ích trong suốt thời gian hai năm học tại trường. Các thầy cô

luôn đồng hành và tạo điều kiện cho tất cả học viên được nghiên cứu và học hỏi theo

nguyên vọng của bản thân.

Đồng thời học viên cũng dành lời cảm ơn chân thành đến gia đình, bạn bè, đồng

nghiệp luôn động viên và bên cạnh trong suốt thời gian qua.

7

LỜI CAM ĐOAN

Học viên xin cam đoan rằng luận văn thạc sĩ công nghệ thông tin “Nghiên cứu

tổng hợp công cụ phát hiện lỗi phần mềm để giảm cảnh báo sai” là công trình nghiên

cứu riêng của bản thân không sao chép của người khác. Trong toàn bộ nội dung của

luận văn, những điều đã trình bày hoặc là của chính cá nhân học viên hoặc là tổng hợp

từ nhiều nguồn tài liệu. Tất cả các nguồn tài liệu tham khảo đều có xuất xứ rõ ràng và

hợp pháp.

Học viên xin chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy định cho

lời cam đoan này.

Hà Nội, ngày ……tháng…..năm 2020

Học viên thực hiện

Lê Thế Huy

8

Chương 1. GIỚI THIỆU ĐỀ TAI VA CÁC CÔNG CỤ SỬ DỤNG PHÂN

TÍCH MÃ NGUỒN

1.1. Giới thiệu đề tài

Hiện nay, chất lượng sản phẩm công nghệ ngày càng được yêu cầu cao cả đối

với nhà phát triển và người sử dụng. Đối với người sử dụng họ muốn một sản phẩm

trơn tru hạn chế lỗi hết mức có thể và đặc biệt phải thật sự bảo mật để đảm bảo an toàn

thông tin của người sử dụng.

Còn đối với nhà phát triển, họ quan tâm đến sản phẩm của mình làm ra đã thực

sự tốt chưa, đã kiểm soát được các vấn đề phát sinh như bảo mật, hiệu suất,… Bên

cạnh đó là sản phẩm đó có dễ dàng bảo trì và phát triển thêm module có dễ dàng

không? Để có thể trả lời cho các vấn đề trên thì nhà phát triển đã đưa vào phân tích mã

nguồn tĩnh trong từng giai đoạn để có thể nắm được các phát sinh. Vậy họ phân tích

mã nguồn tĩnh như nào để biết rằng trong các mã nguồn của mình có các sơ hở về bảo

mật, mã nguồn của mình đã đảm bảo tăng hiệu suất xử lý chưa, mã nguồn đã đạt các

chuẩn theo quy ước để dễ dàng bảo trì cho sau này chưa? Hiện nay có rất nhiều công

cụ hỗ trợ phân tích mã nguồn tĩnh để giúp các nhà phát triển có câu trả lời cho những

vấn đề trên. Trong phạm vi nghiên cứu luận văn có đề cập đến một số công cụ phổ

biến sau: SonarQube, SpotBugs, PMD, IntelliJ IDE, VCG, HuntBugs, Infer. Trong

luận văn sẽ phân tích kết quả của các công cụ đưa ra trên một số tiêu chí và từ đó đưa

ra đánh giá công cụ nào hiện nay đáp ứng tốt nhất để có thể giải quyết được các vấn đề

nêu trên của nhà phát triển. Khi sử dụng các công cụ độc lập thì sẽ đưa ra kết quả như

nào và khi kết hợp các công cụ lại thì chất lượng kiểm tra sẽ có cải thiện nhiều hơn

không? Trong phạm vi nghiên cứu các câu hỏi trên sẽ được trả lời và sẽ đưa ra những

gợi ý cho những người phát triển khi xây dựng một phần mềm.

1.2. Các công cụ được sử dụng trong nghiên cứu

Trong nghiên cứu 7 công cụ sau được lựa chọn: SonarQube, HuntBugs, PMD,

IntelliJ IDE, VCG, Spotbugs, Infer là các công cụ mã nguồn mở dùng để phân tích mã

nguồn tĩnh – Tức là phân tích mã nguồn đang ở trạng thái không hoạt động để từ đó

đưa ra các lỗi để khắc phục trước khi đưa ứng dụng vào chạy thực tế. Các công cụ này

ngoài việc sử dụng các chức năng được cung cấp người dùng có thể tích hợp các

plugin do chính mình phát triển để cải thiện hiệu suất phát hiện lỗi và phù hợp với

từng dự án thực tế. Các công cụ trên đều đang được sử dụng bởi các doanh nghiệp

hoặc là những công cụ đã đã có những thành tích nhất định trong sự phát triển phần

mềm của các doanh nghiệp từ các năm trước đây. Sau đây luận văn sẽ giới thiệu và đi

vào chi tiết từng công cụ.

1.2.1. Công cụ phân tích SonarQube

SonarQube (trước đây là Sonar) là một nền tảng nguồn mở được phát triển bởi

SonarSource để kiểm tra chất lượng mã nguồn đó thực hiện các đánh giá một cách tự

động. SonarQube sử dụng phương pháp phân tích tĩnh (static analysis of code) để phát

hiện lỗi, mã nguồn thừa không có tác dụng và lỗ hổng bảo mật trên 20 ngôn ngữ lập

9

trình. Là một nền tảng mã nguồn mở giúp nhà phát triển có thể kiểm tra chất lượng mã

nguồn của dự án.

SonarQube được viết bằng java nhưng hỗ trợ các ngôn ngữ khác nhau: PHP,

Ruby, Java (bao gồm cả Android), C#, JavaScript, TypeScript, C/C++, Kotlin, Go,

COBOL, PL/SQL, PL/I, ABAP, VB.NET, VB6, Python, RPG, Flex, Objective-C,

Swift, CSS, HTML, và XML và hỗ trợ các cơ sở dữ liệu để lưu trữ kết quả: MySql,

Postgresql.

SonarQube hỗ trợ trong dự án việc đánh giá mã nguồn theo các tiêu chuẩn của

từng ngôn ngữ có trong dự án. Bên cạnh đó có thể thực hiện những việc sau:

• Phát hiện lỗi: phát hiện mã nguồn không dùng đến, các mã nguồn bị trùng

lặp.

• Tính toán độ bao phủ của mã nguồn theo kiểm thử đơn vị (Unit test - Unit-

test coverage) – Đó là cách tính toán trong kiểm thử hộp trắng đảm bảo rằng

tất cả các trường hợp trong mã nguồn đều được đảm bảo chạy qua khi chạy

thực tế.

• Tính toán trong việc các mã nguồn được sử dụng mang tính tạm thời không

được tối ưu để sử dụng lại và dễ bảo trì mã nguồn của hệ thống (Technical

Debt) – Nghĩa là giải quyết vấn đề một cách nhanh chóng không theo quy

chuẩn chỉ quan tâm đến kết quả. Giả sử đúng ra một giá trị phải khai báo là

hằng số để sử dụng chung cho các trường hợp khác nhưng khi sử dụng lại

dùng luôn giá trị chứ không khai báo biến hằng số. Ví dụ đoạn mã nguồn như

sau: if (message == “Nhập thiếu thông tin”) {} thay vào đó có thể khai báo

một biến là hằng số trong một lớp java như là Constant.java: public static

final String MESSAGE = “Nhập thiếu thông tin”; Như vậy ở bất kỳ đâu cần

sử dụng biến MESSAGE đều có thể sử dụng và khi thay đổi giá trị chỉ cần

thay đổi ở một chỗ thay vì phải vào nhiều đoạn mã để thay đổi.

• So sánh chất lượng mã nguồn so với các lần kiểm tra trước.

• Phát hiện lỗ hổng bảo mật.

• Kiểm tra độ phức tạp của mã nguồn.

Sonar gồm 4 thành phần [1]:

Hình 1.1: 4 thành phần chính của SonarQube [1]

➢ Một máy chủ SonarQube bắt đầu với 3 tiến trình chính:

• Máy chủ web cung cấp giao diện người dùng sử dụng và quản lý các phiên

bản phân tích mã nguồn.

10

• Máy chủ tìm kiếm dựa trên Elasticsearch để sao lưu các tìm kiếm từ giao

diện người dùng.

• Máy chủ phụ trách xử lý các báo cáo phân tích mã nguồn và lưu chúng

vào cơ sở dữ liệu của SonarQube.

➢ Một cơ sở dữ liệu để lưu trữ:

• Cấu hình của SonarQube (bảo mật, cài đặt plugin,...).

• Ảnh chụp nhanh chất lượng của dự án, chế độ xem,...

➢ Nhiều plugin SonarQube được cài đặt trên máy chủ, có thể bao gồm ngôn

ngữ, SCM, tích hợp xác thực và quản trị.

➢ Một hoặc nhiều SonarScanners chạy trên máy chủ tích hợp liên tục và xây

dựng để phân tích dự án.

SonarQube Scanners là các plugin sẽ được chạy ở phía người dùng. Giúp thu

thập thông tin từ dự án, sinh các “thuộc tính" cho việc phân tích. Sau đó nó sẽ chạy bộ

phân tích SonarQube dựa trên các “thuộc tính” này. Tương ứng với mỗi công cụ quản

lý dựng (build management), sẽ có một Scanner tương ứng.

SonarQube Plugins bao gồm các plugin về ngôn ngữ lập trình, quản lý phiên

bản mã nguồn hoặc thậm chí là các plugin cho các công cụ phân tích mã nguồn khác

như PMD, FindBugs, jDepend, Android Lint, CheckStyle, WebDriver, ... Xem thêm

tại đây: https://docs.sonarqube.org/display/PLUG/Plugin+Library.

SonarQube hiện tại hỗ trợ cho 26 ngôn ngữ lập trình, do vậy sẽ có 26 plugin

tương ứng để phân tích mã nguồn cho loại ngôn ngữ đấy. Sau đây là hình ảnh minh

họa – hình 1.2:

Hình 1.2: Các ngôn ngữ SonarQube hỗ trợ

Một số kỹ thuật phân tích mã nguồn tĩnh bậc cao được sử dụng như: khớp mẫu

(pattern matching), phân tích luồng dữ liệu, thực thi tượng trưng. SonarQube công bố

các luật (rules) cho các ngôn ngữ này dựa theo các chuẩn nổi tiếng như CWE, SANS,

OWASP, MISRA, CERT. Các luật cho từng ngôn ngữ được định nghĩa ở trang

https://rules.sonarsource.com.

11

Cách thức hoạt động của SonarQube:

Hình 1.3: Cách thức hoạt động của SonarQube

• Sau khi các thông tin dự án được quét, thu thập, xử lý ở máy khách (client).

• SonarQube Scanner sẽ gửi những thông tin này ở dạng tệp nén lên máy chủ

(server) thông qua các API mà máy chủ cung cấp. Ngay khi máy chủ nhận

được yêu cầu xử lý này, việc đầu tiên là SonarQube sẽ nạp toàn bộ mã nguồn

và các tệp đi kèm nhờ plugin ngôn ngữ. Sau mã nguồn được nạp xong, các

bộ phân tích sẽ lần lượt quét qua mã nguồn và tạo ra chỉ số đo lường hoặc

phát hiện các vấn đề. Các bộ phân tích được chia làm hai loại là sensor và

decorator. Sensor là các bộ phân tích có thể tự tạo ra và cập nhật các chỉ số từ

mã nguồn. Decorator là các bộ phân tích sử dụng chỉ số từ các sensor để

phân tích sinh ra các chỉ số ở mức cao hơn.

• Trong toàn bộ quá trình, dữ liệu phân tích sẽ được lưu vào cơ sở dữ liệu ở

các bước: sau khi nhập bởi plugin ngôn ngữ, sau khi sensor phân tích, sau khi

decorator phân tích. Lúc này người dùng có thể kiểm tra kết quả phân tích

trên giao diện web.

Thay vì sử dụng trực tiếp các mã lỗi từ đã được định nghĩa sẵn từ các nguồn mở

như CWE, OWASP,... SonarQube đã tạo ra những mã lỗi của riêng mình bằng cách tự

tổng hợp lại từ nhiều nguồn khác nhau. Sau đó, các bộ lọc, bộ kiểm tra (luật) sẽ được

viết ra dựa trên các mã lỗi riêng như vậy. Các luật của Java được triển khai tại

org.sonar.java.checks.

Để kiểm tra các lỗi có trong một tệp dữ liệu, SonarQube sẽ có hai phương pháp

để thực hiện điều này [5]:

• Sử dụng cú pháp cây và API cơ bản (Using syntax trees and API basics):

Trước khi chạy bất kỳ quy tắc nào, SonarQube Java Analyzer phân tích tệp

12

Java đã cho và tạo ra cấu trúc dữ liệu tương đương: cú pháp cây (Syntax

Tree). Mỗi cấu trúc của ngôn ngữ Java có thể được biểu diễn bằng một thành

phần cụ thể cú pháp cây (Syntax Tree), chi tiết từng đặc điểm của nó. Mỗi

cấu trúc này được liên kết với một giao diện riêng mô tả rõ ràng tất cả các

đặc tính của nó. Khi tạo ra một luật, lớp IssuableSubscriptionVisitor sẽ được

thực thi, nó cung cấp các phương thức hữu ích để làm rõ các vấn đề cũng như

xác định chiến lược sẽ sử dụng khi phân tích một tệp. Nó dựa trên cơ chế

đăng ký (subscription mechanism), cho phép chỉ định loại cây mà luật này sẽ

phản ứng với. Các nút mà cần đảm bảo sẽ được duyệt được chỉ định bởi một

phương thức là nodesToVisit(). Từ đó SonarQube sẽ có được các thông tin

để bắt đầu xác định các lỗi có trong mã nguồn hay thực thi các luật.

• Sử dụng API (Using semantic API): Ngoài việc thực thi các luật dựa vào dữ

liệu được cung cấp bởi cú pháp cây (syntax tree), thì SonarQube cung cấp

càng nhiều thông tin hơn liên quan đến mã nguồn thông qua một mô hình

ngữ nghĩa của mã. Tuy nhiên mô hình này hiện chỉ hoạt động với mã nguồn

Java. Mô hình ngữ nghĩa này cung cấp thông tin liên quan đến từng ký hiệu

được thao tác. Ví dụ, đối với một phương thức, API ngữ nghĩa sẽ cung cấp

dữ liệu hữu ích như chủ sở hữu của phương thức, công dụng của nó, các loại

tham số và loại trả về của nó, ngoại lệ mà nó có thể ném,...

1.2.2. Công cụ phân tích HuntBugs

Công cụ phân tích mã Java bytecode dựa trên công cụ Procyon Compiler với

mục đích để thay thế FindBugs. Công cụ có thể chạy với maven, ant, gradle hoặc là

một plugin của Eclipse. Phiên bản mới nhất hiện nay là 0.0.11. Hiện tại dự án đã bị

hủy và không được hỗ trợ trong tương lai.

HuntBugs có một điểm yếu lớn là nó không thể quét được các lỗi mã nguồn

trong khi phát triển, chúng ta phải dựng hoặc đóng gói thì mới có thể quét được.

Việc tích hợp HuntBugs rất nhanh và dễ hiểu, việc quét các tệp lỗi và xuất ra

tệp báo cáo cũng rất nhanh, có thể xem kết quả ngay trên IDE tích hợp HuntBugs.

HuntBugs không như các công cụ khác và có hạn chế khi chỉ hỗ trợ quét lỗi dự án thực

hiện bằng ngôn ngữ Java.

Việc chạy công cụ HuntBugs giúp phát hiện một vài lỗi trong hệ thống nhưng

vẫn còn rất nhiều lỗi không bị phát hiện. Ngoài ra do hiện nay công cụ HuntBugs đã

không được hỗ trợ trong tương lai nên rất khó phát triển thêm.

1.2.3. Công cụ phân tích PMD [6]

PMD (Programming Mistake Detector) là một công cụ mã nguồn mở phân tích

mã nguồn tĩnh để tìm ra các vấn đề trong mã nguồn giúp cải thiện chất lượng mã

nguồn. PMD hỗ trợ các ngôn ngữ sau JavaScript, PLSQL, Apex, Python, Java.

PMD có thể phát hiện một số lỗi sau trong mã nguồn:

• Thân rỗng trong các khối lệnh try/catch/finally/switch và if/while.

• Mã nguồn không được sử dụng với các biến toàn cục, tham số, các hàm

mang tính chất đóng gói (private methods).

13

• Các biểu thức quá phức tạp, không cần thiết cho các câu lệnh điều kiện (if),

vòng lặp for và while.

• Tối ưu việc sử dụng String/String Buffer.

• Trùng lặp mã nguồn.

PMD plugins cho một số IDE sau: eclipse, NetBeans, IntelliJ, Maven,

JDeveloper, JBuilder, SonarQube. PMD plugins mới nhất có version 6.17.0.

Cách thức hoạt động:

1. Khi bắt đầu thực hiện chạy phân tích mã nguồn của dự án sẽ chạy vào lớp

chính (class main): net.sourceforge.pmd.PMD.

2. Truyền tham số cho dòng lệnh net.sourceforge.pmd.cli.PMDParameters.

Đồng thời tải tập tin bộ nhớ đệm (cache) để tăng cường việc phân tích.

3. Tải các bộ luật đã được định nghĩa sẵn hoặc do mình định nghĩa lại.

4. Xác định ngôn ngữ mình thực hiện phân tích. (Mỗi ngôn ngữ được hỗ trợ

một số bộ luật riêng hoặc giữa các ngôn ngữ có nhưng bộ luật trùng nhau).

5. Xác định các tệp (sử dụng thư mục nguồn đã cho, lọc theo phần mở rộng tệp

ngôn ngữ).

6. Chuẩn bị cho quá trình kết xuất kết quả.

7. Sắp xếp các tệp tin (file) theo tên.

8. Kiểm tra xem có thể sử dụng bộ nhớ đệm (cache) để thực việc phân tích (nếu

các quy tắc thay đổi thì việc làm trên sẽ không hợp lệ).

9. Chuẩn bị SourceCodeProcessor dựa trên cấu hình.

10. Phân tích các tệp tin (đơn luồng hoặc đa luồng) thực hiện trong

net.sourceforge.pmd.Processor.PMDRunnable:

Tạo luồng đầu vào

Gọi bộ xử lý mã nguồn net.sourceforge.pmd.SourceCodeProcessor:

• Xác định ngôn ngữ.

• Kiểm tra bộ nhớ đệm (cache) tệp đã được phân tích hay có sẵn.

• Phân tích mã nguồn. Kết quả là nút AST gốc.

• Luôn luôn chạy khách truy cập SymbolFacade. Nó xây dựng phạm vi,

tìm khai báo và tập quán.

• Chạy DFA (phân tích luồng dữ liệu – nếu có ít nhất một quy tắc yêu cầu)

để xây dựng biểu đồ luồng điều khiển và các nút luồng dữ liệu.

• Chạy TypeResolution (nếu có ít nhất một quy tắc yêu cầu).

• Chạy phân tích đa biến (nếu ít nhất một quy tắc yêu cầu).

• Thực hiện quy tắc luật:

✓ Trước tiên hãy chạy các quy tắc đã chọn cho cơ chế chuỗi quy tắc.

✓ Chạy tất cả các quy tắc khác và để chúng đi qua AST. Các quy tắc có

thể sử dụng bảng ký hiệu, thông tin độ phân giải và các nút DFA.

✓ Các quy tắc sẽ báo cáo các vấn đề được tìm thấy như vi phạm quy tắc

(Rule Violations).

14

11. Kết xuất các vi phạm được tìm thấy thành định dạng mong muốn (XML,

văn bản, HTML).

12. Phân tích bộ nhớ đệm lưu trữ.

13. Tùy thuộc vào số lượng vi phạm được tìm thấy, thoát với mã 0 hoặc 4.

1.2.4. Công cụ phân tích IntelliJ IDE

IntelliJ IDEA là công cụ nhằm tạo ra những dự án lập trình cho điện thoại hoặc

cho với khả năng mã hóa sâu sắc và điều hướng nhanh phần mềm còn cung cấp cho

người dùng một danh sách các biểu tượng và ký hiệu phục vụ trong công việc lập trình

của người dùng.

IntelliJ IDEA thực hiện phân tích dòng dữ liệu đầu vào của người dùng, phần

mềm phân tích lưu lượng dữ liệu để đoán biểu tượng thể loại thời gian phần mềm thực

hiện phân tích kịch bản được đưa vào của người dùng với các để xuất khác nhau tự

động thêm các lớp phôi để phù hợp với chương trình mà bạn đang làm việc.

IntelliJ IDEA là một IDE Java để phát triển các phần mềm máy tính. Công cụ

được phát triển bởi JetBrains (trước đây gọi là IntelliJ), nó được cấp phép Apache 2

cho phiên bản cộng đồng, và một phiên bản thương mại độc quyền. Cả hai có thể được

sử dụng cho phát triển thương mại.

Những tính năng chính:

• Lập trình các dự án cho điện thoại, java,…

• So sánh tìm kiếm các đoạn mã trùng nhau.

• Phân tích dữ liệu.

• Tìm kiếm nhanh chóng.

• Ứng dụng rộng rãi.

Ở vai trò là một công cụ phân tích mã nguồn tĩnh thì IntelliJ IDE có rất nhiều

ưu điểm vượt trội đáng chú ý. IntelliJ IDE cung cấp cho người sử dụng bản sửa lỗi

nhanh và thông minh. Vì vậy chất lượng mã nguồn luôn được đảm bảo ngay từ đầu mà

không làm gián đoạn quá trình viết mã nguồn theo yêu cầu của hệ thống. Từ đó giúp

cho các lập trình viên làm việc hiệu quả và tiết kiệm thời gian. Với hơn 600 mã nguồn

kiểm tra tự động giúp người dùng dễ dàng phát hiện các điểm mâu thuẫn khác nhau.

IntelliJ IDE chia các lỗi mã nguồn thành các nhóm lỗi để có thể xử lý tùy theo mục

đích của các dự án khác nhau. Sau đây học viên sẽ giới thiệu các nhóm lỗi mà IntelliJ

IDE đang chia ra [9]:

• Tìm lỗi có thể xảy ra: IntelliJ IDE phân tích mã người dùng đang nhập và

có khả năng tìm và sửa các lỗi có thể xảy ra không phải là “lỗi biên dịch”

ngay tức thì. Đây là một ví dụ về tình huống như vậy:

15

Hình 1.4: Lỗi NullPointer trước khi sửa

Ở đây, điều kiện if đầu tiên có thể dẫn đến ngoại lệ NullPointer được ném vào

if thứ hai, vì không phải tất cả các tình huống đều được ở trạng thái tốt nhất.

Tại thời điểm này, thêm một xác nhận để tránh NullPointer bị ném trong thời

gian chạy ứng dụng.

Hình 1.5: Lỗi NullPointer sau khi sửa

• Định vị, xác định mã nguồn không được sử dụng: IntelliJ IDEA làm nổi

bật trong phần biên tập của cái gọi là mã “chết”. Đây là mã không bao giờ

được thực thi trong thời gian chạy ứng dụng. Có lẽ, bạn thậm chí không cần

phần mã này trong dự án của mình. Tùy thuộc vào tình huống, mã như vậy

có thể được coi là một lỗi hoặc như một phần thừa. Dù sao nó cũng làm giảm

hiệu suất ứng dụng và làm phức tạp quá trình bảo trì. Đây là một ví dụ. Cái

gọi là “điều kiện không đổi” - ví dụ như điều kiện không bao giờ được đáp

16

ứng hoặc luôn luôn là “đúng”. Trong trường hợp này, mã chịu trách nhiệm

không thể truy cập được và thực sự là mã không được sử dụng (mã “chết”).

Hình 1.6: Mã nguồn không được sử dụng (mã “chết”)

• Phát hiện các vấn đề hiệu suất: IntelliJ IDE gợi ý cho người dùng một cách

dễ dàng để giải quyết các vấn đề liên quan đến hiệu suất trong toàn bộ dự án.

IntelliJ IDE biết rất nhiều tình huống trong đó có một số mẫu được biết là

được thực hiện nhanh hơn bất kỳ mẫu nào khác. Vì vậy, nó có thể đề xuất

các giải pháp để tăng hiệu suất. Sau đây là một ví dụ về hoạt động của chuỗi:

Hình 1.7: Mã nguồn trước khi xử lý chuỗi

IntelliJ IDE gợi ý một số hành động để cải thiện hiệu suất của hoạt động chuỗi

này. Cách xử lý thứ 2 được chọn vì nó được biết là hoạt động nhanh hơn.

Hình 1.8: Mã nguồn sau khi xử lý chuỗi

• Cải thiện cấu trúc mã và khả năng bảo trì: IntelliJ IDE thực hiện phân tích

nhanh các phụ thuộc thông qua một dự án, module hoặc gói, phát hiện chúng

17

và giúp bạn kiểm soát các phụ thuộc thông qua việc chia nhỏ mã của bạn

thành các module, sử dụng các phụ thuộc theo chu kỳ tạm thời, đánh dấu lỗi.

IntelliJ IDE cũng tìm kiếm các bản sao cấu trúc, ngay cả các bản sao “mờ”.

• Tuân thủ các hướng dẫn và tiêu chuẩn mã hóa: IntelliJ IDE cho phép tìm

ra các điểm mâu thuẫn khác nhau liên quan đến nhiều hướng dẫn và tiêu

chuẩn mã hóa, từ các tiêu chuẩn Java phổ biến đến bất kỳ tiêu chuẩn cụ thể

nào của công ty. Tất cả những nơi, ví dụ, tìm thấy sự không nhất quán của

Javadoc, đều được đánh dấu trong trình chỉnh sửa khi đang di chuyển. Sau

đây là ví dụ:

Hình 1.9: Lỗi đặt vi pham quy tắc đặt tên biến

Trong trường hợp này, dự án đã xác định rằng tất cả các hằng số trong dự án

phải bắt đầu bằng ký hiệu “_”. Bóng đèn màu vàng báo động rằng hằng số

không phù hợp với tiêu chuẩn riêng mà dự án đặt cho các tên như vậy.

IntelliJ IDE có thể giúp giải quyết vấn đề. Chỉ cần nhấn Alt + Enter và chọn

để đổi tên biểu tượng. Tất cả các cách sử dụng của biểu tượng này trong mã

cũng sẽ được đổi tên.

• Tuân theo thông số kỹ thuật: IntelliJ IDE nêu bật tất cả các vi phạm đặc

điểm kỹ thuật, như EJB, JSP, JSF,…. Không giống như sự mâu thuẫn về

nguyên tắc, vi phạm thông số kỹ thuật dẫn đến việc không thể triển khai ứng

dụng trên máy chủ. Đó là lý do tại sao điều quan trọng là phải tìm những địa

điểm mã như vậy ngay lập tức. Đây là một ví dụ:

Hình 1.10: Vi phạm đặc điểm kỹ thuật EJB

Theo đặc điểm kỹ thuật của EJB, phương thức “create” sẽ đưa ra ngoại lệ

tương ứng. IntelliJ IDE nêu rõ vi phạm này và đề xuất cách khắc phục nhanh

chóng. Nếu chúng tôi không khắc phục, ứng dụng sẽ không thể triển khai ở

phía máy chủ.

18

Hình 1.11: Sau khi đã sửa vi phạm kỹ thuật EJB

1.2.5. Công cụ phân tích VCG [11]

VCG là một công cụ đánh giá bảo mật tự động sử dụng với các ngôn ngữ

C/C++, Java, C#, VB và PL/SQL. VCG có một vài tính năng hy vọng sẽ hữu ích cho

bất kỳ ai tiến hành đánh giá bảo mật.

Ngoài việc thực hiện một số kiểm tra phức tạp hơn, nó còn có một tệp cấu hình

cho mỗi ngôn ngữ về cơ bản cho phép bạn thêm bất kỳ chức năng xấu nào (hoặc văn

bản khác) mà bạn muốn tìm kiếm, chẳng hạn như trong danh sách chức năng bị cấm

của Microsoft, các hàm Java xử lý đầu vào của người dùng thực hiện ngay lập tức

(Execute Immediate) trong PL/SQL.

Bản thân ứng dụng xử lý các nội dung phức tạp (tràn bộ đệm, so sánh có dấu

hoặc chứa ký tự,...) vì vậy các tệp cấu hình được đề cập ở trên về cơ bản cung cấp

thêm một lớp kiểm tra bổ sung mà người dùng có thể muốn hoặc không và có thể sửa

đổi cho phù hợp.

Kết quả được xếp hạng theo mức độ nghiêm trọng để hỗ trợ người dùng trong

quá trình đánh giá.

Quá trình quét mã lỗi được thực hiện theo ba cách:

• Chỉ nhận xét - VCG cố gắng xác định bất kỳ nhận xét nào cho biết mã hỏng

hoặc chưa hoàn thành dựa trên danh sách khoảng 16 cụm từ thường xuất hiện

trong các nhận xét đó.

• Chỉ mã nguồn - VCG quét và báo cáo về các vấn đề bảo mật mã tiềm ẩn và

bất kỳ chức năng nguy hiểm nào,... từ tệp cấu hình nằm trong mã.

• Chỉ các chức năng nguy hiểm - VCG chỉ quét và báo cáo về bất kỳ chức

năng nguy hiểm nào,... từ tệp cấu hình được tìm thấy trong mã.

• Mã, chức năng nguy hiểm và nhận xét - Còn được gọi là quét toàn bộ trong

danh sách quét, đây là một quá trình quét kết hợp cả mã và chú thích bao

gồm tất cả những điều trên.

Tệp cấu hình tồn tại cho từng ngôn ngữ trong số sáu ngôn ngữ mà VCG quét.

Chúng cung cấp một lớp quét bổ sung để bổ sung cho các bản quét phức tạp được tích

hợp sẵn cho mỗi ngôn ngữ.

Phân tích mã trực quan sẽ được hiển thị khi quá trình quét kết thúc. Kết quả

được ghi vào ngăn kết quả theo thứ tự chúng đã được định vị. Kết quả có định dạng

sau:

• SEVERITY: Vấn đề về mã.

• Số dòng - Tên tệp.

• Mô tả.

19

1.2.6. Công cụ phân tích SpotBugs [8]

SpotBugs là một chương trình sử dụng phân tích tĩnh để tìm lỗi trong mã Java.

Nó tìm kiếm các trường hợp “mẫu lỗi” - các trường hợp mã có khả năng bị lỗi. Nó

cũng là người kế thừa tinh thần của FindBugs, tiếp tục phát triển từ thời điểm mà nó đã

khởi nghiệp với sự hỗ trợ của cộng đồng.

Để sử dụng SpotBugs, bạn cần có môi trường thời gian chạy tương thích với

Java phiên bản 1.8 trở lên. SpotBugs là nền tảng độc lập và được biết là chạy trên nền

tảng GNU/Linux, Windows và MacOS X. Phải có ít nhất 512 MB bộ nhớ để sử dụng

SpotBugs. Để phân tích các dự án rất lớn, nhiều bộ nhớ hơn có thể cần thiết.

SpotBugs được xây dựng bởi JDK8 và chạy trên JRE8 và các phiên bản mới

hơn. SpotBugs có thể quét mã bytecode (tệp lớp) được tạo bởi JDK 8 và các phiên bản

mới hơn. Tuy nhiên, hỗ trợ cho Java 11 và mới hơn vẫn đang thử nghiệm. Truy cập

trình theo dõi sự cố để tìm các sự cố đã biết. SpotBugs không hỗ trợ bytecode (tệp lớp)

được tạo bởi JDK lỗi thời như 10, 9, 7 và các phiên bản cũ hơn.

Một số lỗi mà SpotBugs tìm ra:

• BAD_PRACTICE: Vi phạm thực hành mã hóa được khuyến nghị và cần

thiết. Ví dụ bao gồm mã băm và các vấn đề bằng thành ngữ có thể sao chép,

ngoại lệ bị loại bỏ, các vấn đề có thể sắp xếp thứ tự và sử dụng sai finalize.

• Quốc tế hóa (I18N): Các lỗi mã liên quan đến quốc tế hóa và ngôn ngữ.

• MALICIOUS_CODE: Dễ bị tấn công từ các phần mềm độc hại. Được cài

cắm từ các sơ hở của phần mềm.

• Hiệu suất hoạt động (PERFORMANCE): phát hiện các mã lỗi làm cho

chương trình giảm hiệu suất: như thừa mã, mã trùng lặp, sử dụng các cấu trúc

dữ liệu làm tăng hiệu suất chương trình,… đều được phát hiện và cảnh bảo

cho người dùng.

1.2.7. Công cụ phân tích Infer

Infer là một công cụ mã nguồn mở được sử dụng bởi Amazon, Facebook,

Uber,… Chương trình có khả năng bắt lỗi trong mã nguồn thuộc ngôn ngữ

Java/C++/Objective-C.

Infer có thể bắt được một số lỗi:

• Gọi các con trỏ giá trị null.

• Lỗi sử dụng đối tượng giá trị null trong danh sách thuộc loại đầu vào là các

đối tượng (C++/Objective-C).

• Rò rỉ tài nguyên và bộ nhớ.

• Vòng lặp trả lại (A -> B và B -> A dẫn đến đối tượng không bị xóa kể cả khi

tất cả con trỏ ở bên ngoài đã bị hủy).

• An toàn luồng.

• Các biến khởi tạo nhưng không được sử dụng (Dead variable).

• Nhiều luồng đợi khóa ngược nhau dẫn đến treo (Deadlock).

20

Infer là công cụ tập trung vào lỗi hệ thống về null và dữ liệu, do đó nó không có

thông báo một số lỗi thông dụng hơn như:

• Lỗi trỏ ra ngoài mảng (Array bounds errors).

• Chuyển đổi kiểu dữ liệu lỗi từ kiểu này sang kiểu khác (Cast exceptions).

• Dùng dữ liệu không ổn (Leaking of tainted data). Ví dụ int a=0, b=a+b.

• Nhiều luồng sửa vào cùng nguồn dữ liệu vào cùng lúc (Concurrency race

conditions).

Cách thức hoạt động [2, 7]:

• Phương pháp tìm lỗi của chương trình dựa trên hai lý thuyết về hệ thống

chương trình - Separation và Bi-abduction.

✓ Separation dựa vào việc phân tích chương trình thành các hoạt động con

xử lý trên dữ liệu và sau đó kết hợp lại tất cả các hoạt động con này thành

trạng thái để có thể xem xét cuối cùng.

✓ Bi-abduction là phương pháp tìm kiếm các phần cần thiết để thỏa mãn

các ước đoán mà chúng ta cần kiểm tra.

• Cấu trúc này cho phép chương trình phân tích các đoạn mã một cách độc lập

và ít tương tác với nhau, đồng nghĩa với việc khi một khu vực mã bị thay đổi,

chỉ có các ước đoán và trạng thái của khu vực đó trở đi bị ảnh hưởng, tăng

tốc độ kiểm tra mã. Điểm yếu của nó là ở chỗ phương pháp này chỉ có thể áp

dụng cho các loại lỗi thuộc về cấu trúc, chứ không thể sử dụng cho tất cả các

loại lỗi có thể được phát hiện (ví dụ truy cập ngoài kích cỡ của mảng, chuyển

đổi kiểu giá trị gây ngoại lệ).

• Trong hoạt động thực tế (khi sử dụng lên các mã C++/Java), hệ thống chạy

bằng câu lệnh tương ứng, lúc này các công cụ biên dịch của hệ thống (clang,

javac, ant, make,...) sẽ bị thay bằng biên dịch của Infer để chạy phân tích.

Infer có 2 giai đoạn thực hiện:

✓ Chiếm lấy (Capture): Ở bước này, mã của chương trình sẽ được tạo

thành các đồ thị và hoạt động như trên, sau đó dữ liệu đó được lưu lại

trên đĩa cứng. Thông thường dữ liệu này ở thư mục infer-out, nhưng có

thể chọn được một thư mục khác bằng lệnh option -o. Lý do để có bước

này là bởi vì Infer hỗ trợ việc chỉ kiểm tra khu vực bị thay đổi thay vì

toàn bộ chương trình, do đó, cần phải lưu trữ dữ liệu từ các bước trước.

✓ Phân tích (Analyze): Ở bước này, dữ liệu từ bước chiếm lấy (Capture) sẽ

được phân tích để tạo ra báo cáo cần thiết. Nếu chỉ chạy cho phần dữ liệu

bị thay đổi, Infer sẽ được chạy với option --reactive, đưa đến tốc độ

nhanh hơn. Dù là kiểm tra toàn bộ hay cục bộ, phân tích sẽ in ra thông tin

lỗi và cảnh báo ra bàn điều khiển (console - stdout) và tệp infer-

out/bugs.txt ngoài ra, infer cũng có report.csv mang thông tin trên dưới

dạng tệp excel, csv.

21

1.3. Đánh giá hiệu suất

Trong phạm vi nghiên cứu luận văn học viên thực hiện nghiên cứu với các chỉ số

đo hiệu suất vì đây là các chỉ số thường được sử dụng trong nghiên cứu trước đây. Các

chỉ số được định nghĩa như sau [3]:

TP (True Positive): Chỉ sổ này để thể hiện phát hiện chính xác lỗi trong mã

nguồn. Mã chứa lỗi được phát hiện và được đưa ra báo cáo chính xác.

TN (True Negative): Chỉ số này để thể hiện phát hiện đúng không có lỗi trong

mã nguồn. Không có bất kỳ một lỗi nào tồn tại trong mã nguồn và không lỗi nào được

báo cáo.

FN (False Negative): Chỉ số thể hiện có lỗi trong mã nguồn nhưng mã chứa lỗi

không được tìm ra và không được đưa vào báo cáo.

FP (False Positive): Chỉ số thể hiện phát hiện lỗi trong mã nguồn không chính

xác. Không có lỗi nào tồn tại trong mã, nhưng lỗi được báo cáo.

Recall (Độ bao phủ): Chỉ số thể hiện phần trăm lỗi được phát hiện trong tổng số

các mã lỗi được báo cáo. Công thức tính:

Recall = TP / (TP + FN)

Precision (Độ chính xác): Chỉ số thể hiện phần trăm mã lỗi được phát hiện đúng

là có lỗi thực sự. Tức là không phải trường hợp mã nguồn tìm ra là lỗi nhưng thực tế

mã nguồn không có lỗi. Công thức tính:

Precision = TP / (TP + FP)

Discrimination: Chỉ sổ thể hiện số lượng tệp chứa mã nguồn lỗi tìm đúng mã lỗi

(TP) không tồn tại bất kỳ một mã nguồn nào bị báo cáo sai lỗi (FP).

Discrimination Rate: Chỉ số thể hiện tỷ lệ phần trăm các trường hợp thử nghiệm

mà một công cụ phân tích phân biệt. Công cụ phân tích phân biệt một lỗi trong mã

nguồn nếu chỉ báo cáo một kết quả tích cực thực sự về nó (TP) - kết quả đó chính là

Discrimination, nhưng không có kết quả phát hiện lỗ hổng không chính xác (FP) trong

cùng một tệp mã nguồn đó. Được tính bằng công thức:

Discrimination Rate = Discrimination / (TP + FN)

1.4. Bộ thử nghiệm (Test Suite)

Để nghiên cứu 7 công cụ phân tích mã nguồn tĩnh, người đánh giá cần có phần

mềm cho các công cụ để phân tích. Có hai loại phần mềm để lựa chọn: tự nhiên và

nhân tạo. Phần mềm tự nhiên là phần mềm không được tạo ra để kiểm tra các công cụ

phân tích tĩnh. Các ứng dụng phần mềm nguồn mở, chẳng hạn như máy chủ web

Apache (httpd.apache.org) hoặc bộ OpenSSH (www.openssh.com) là những ví dụ về

phần mềm tự nhiên. Phần mềm nhân tạo chứa các sai sót có chủ đích và được tạo ra

đặc biệt để kiểm tra các công cụ phân tích mã nguồn tĩnh.

CAS (Center for Assured Software - là trung tâm cải thiện sự đảm bảo của phần

mềm được sử dụng, tăng mức độ tin cậy rằng phần mềm không có lỗi cố ý và không

chủ ý [3]) quyết định rằng lợi ích của việc sử dụng mã nhân tạo lớn hơn những bất lợi

và do đó tạo ra mã nhân tạo để nghiên cứu các công cụ phân tích tĩnh. CAS tạo mã

nguồn như một tập hợp các trường hợp thử nghiệm. Mỗi trường hợp thử nghiệm chứa

22

chính xác một lỗi có chủ đích và thường ít nhất một cấu trúc không sai sót tương tự

như lỗ hổng có chủ đích – Tức là mã nguồn không có một lỗi nào cả để đối lập và

phân biệt với mã nguồn có lỗi trong bộ dữ liệu kiểm thử. Các cấu trúc không sai sót

được sử dụng để xác định xem liệu các công cụ có thể phân biệt sai sót với không sai

sót hay không. Ví dụ: một trường hợp thử nghiệm minh họa một loại lỗ hổng tràn bộ

đệm. Mã lỗi trong trường hợp thử nghiệm chuyển cho hàm C strcpy một bộ đệm đích

nhỏ hơn chuỗi nguồn. Cấu trúc không sai sót chuyển một bộ đệm đích đủ lớn để

strcpy. Các trường hợp thử nghiệm do CAS tạo ra và được sử dụng để nghiên cứu các

công cụ phân tích tĩnh được gọi là bộ thử nghiệm Juliet. Chúng được công bố rộng rãi

thông qua Viện Tiêu chuẩn và Công nghệ Quốc gia (NIST) tại

http://samate.nist.gov/SRD/testsuite.php.

Bộ dữ liệu Juliet Testsuite phiên bản 1.3 được chọn để đưa vào thử nghiệm vì nó

không chỉ giới hạn ở 10 lỗ hổng hàng đầu không giống như tập dữ liệu kiểm tra mã

nguồn chuẩn OWASP (OWASP là viết tắt của Open Web Application Security Project

– là tổ chức phi lợi nhuận và đưa ra chuẩn OWASP phục vụ công việc pentest hiệu quả

và chi tiết). Ngoài ra, bộ thử nghiệm được thiết kế cho tất cả các điểm yếu và không

chỉ giới hạn ở các điểm yếu dựa trên web như OWASP. Một trong những mục tiêu để

phát triển bộ thử nghiệm Juliet là cho phép nghiên cứu thực nghiệm dựa trên các bộ

thử nghiệm lớn. Các nhà nghiên cứu đã bắt đầu sử dụng các phiên bản của bộ thử

nghiệm Juliet để đánh giá phân tích mã nguồn [4, 12]. Bộ thử nghiệm Juliet phiên bản

mới nhất (phiên bản 1.3) tổng hợp 64099 trường hợp thử nghiệm trong C/C++ và

28881 trường hợp thử nghiệm trong Java.

1.5. Các lớp yếu điểm(CWE)

CWE là viết tắt của Common Weakness Enumeration - bảng liệt kê yếu điểm

chung của phần mềm do cộng đồng phát triển. Mục đích là phục vụ như một tiêu

chuẩn chung cho những người làm việc với phần mềm. Sau đây sẽ là một vài ví dụ để

hiểu hơn về các lỗi được định nghĩa trong CWE:

Ví dụ 1: Tràn bộ đệm dựa trên ngăn xếp (CWE-121) và tràn bộ đệm dựa trên lớp

(CWE-122) đều được đặt trong lớp điểm yếu xử lý bộ đệm. Do đó, tất cả các trường

hợp thử nghiệm liên quan đến các mục 121 và 122 của CWE được ánh xạ tới lớp điểm

yếu xử lý bộ đệm.

Ví dụ 2: SQL Injection là một kỹ thuật chèn mã có thể phá hủy cơ sở dữ liệu. Có

câu lệnh sau để khi thực hiện yêu cầu đăng nhập từ một hệ thống website

SELECT * FROM Users WHERE UserId = 105; người tấn công có thể bổ sung câu

như sau để câu lệnh trên luôn luôn thực hiện Select * from users where userId = 105 or

1 = 1; kỹ thuật tấn công như trên được định nghĩa với mã là CWE-89 (SQL Injection).

23

Chương 2. PHƯƠNG PHÁP VA TIẾN HANH THỰC NGHIỆM

2.1. Phương pháp nghiên cứu

Trong phần này học viên sẽ tóm tắt phương pháp nghiên cứu. Trong đó bao gồm

chiến lược nghiên cứu, phương pháp tạo dữ liệu và phương pháp phân tích dữ liệu.

2.1.1. Chiến lược nghiên cứu

Trong luận văn sử dụng phương pháp nghiên cứu thực nghiệm cài đặt các công

cụ được đề cập đến ở chương 1: SonarQube, PMD, IntelliJ IDE, VCG, SpotBugs,

HuntBugs, Infer. Sử dụng bộ dữ liệu kiểm thử Juliet TestCase phiên bản 1.3 như trong

một nghiên cứu tương tự của ông Tosin và đồng nghiệp [10]. Trong nghiên cứu của

ông Tosin có sử dụng các công cụ FindSecBugs, FindBugs, Lapse++, Jlint,

Commercial, SonarQube và sử dụng các chỉ số TP, FP, FN, Recall, Precision,

Discrimination, Discrimination Rate để đo hiệu suất phát hiện lỗi của các công cụ trên

nhưng ông chỉ dừng lại việc đánh giá khả năng phát hiện lỗi của các công cụ. Nhưng

trong luận văn học viên sử dụng 7 công cụ khác để thực hiện đánh giá phát hiện lỗi của

các công cụ qua các chỉ số như ông Tosin dùng trong nghiên cứu thông qua bộ dữ liệu

kiểm thử Juliet Testsuite 1.3. Từ đó để thấy khả năng phát hiện lỗi của các công cụ,

những nhược điểm của các công cụ và để cải thiện chất lượng sản phẩm khi dùng các

công cụ trên để thực hiện phân tích lỗi phần mềm trước khi đưa vào sử dụng. Để cải

thiện việc phát hiện lỗi thì kết hợp các công cụ nào để tương thích với từng dự án. Sau

khi cài đặt và phân tích bộ dữ liệu kiểm thử kết quả của từng công cụ được lưu dưới

dạng csv. Các tệp dữ liệu kết quả sẽ được phân tích như phần 2.1.2 để đưa vào công cụ

do học viên tự viết để thực hiện tính toán các chỉ sổ TP, FP, FN, Recall, Precision,

Discrimination, Discrimination Rate trong trường hợp đơn công cụ và tổ hợp các công

cụ.

Trong luận văn sử dụng chính các công cụ họ dùng để nghiên cứu để có thể so

sánh được công cụ có cải tiến hơn trước không bằng cách thực hiện đúng như phương

pháp họ đang dùng để đưa ra kết quả như ngày hôm nay. Bên cạnh đó bổ sung thêm

các công cụ mới để có sự đánh giá khách quan và chính xác hơn lý thuyết đang được

sử dụng. Nghiên cứu các công cụ phân tích từ lịch sử ra đời, cách sử dụng, cách thức

hoạt động, ưu và nhược điểm của các công cụ.

2.1.2. Phương pháp tạo dữ liệu

Sử dụng các công cụ phân tích ứng dụng tĩnh được đề cập đến ở chương 1 để

phân tích thành các dữ liệu chuẩn lưu dưới dạng tệp .csv. Tất cả các tệp dữ liệu kết quả

sẽ có những định dạng khác nhau theo theo từng công cụ tùy chỉnh nhưng tất cả các

công cụ đều cho ra tệp kết quả có 3 trường sau là chung: đường dẫn tệp lỗi trong bộ dữ

liệu kiểm thử, lỗi từ dòng trong tệp, lỗi đến dòng trong tệp. Dựa vào điểm chung đó để

chuẩn hóa các tệp dữ liệu theo chuẩn sau – Bảng 2.1:

Đường dẫn tệp tin lỗi Lỗi từ dòng Lỗi đến dòng

Bảng 2.1: Bảng mẫu dữ liệu chuẩn hóa

24

Tất cả các tệp dữ liệu đều được chuẩn hóa để trở thành dữ liệu đầu vào cho các

bước phân tích tiếp theo.

2.1.3. Phân tích dữ liệu

Đưa các tệp dữ liệu chuẩn làm dữ liệu đầu vào phân tích theo các tiêu chí đã

được đề cập ở trên. Phân tích theo từng công cụ, phân tích bằng cách tổng hợp dữ liệu

từ các công cụ theo kiểu tổ hợp một công cụ kết hợp với các công cụ còn lại, kết hợp

hai công cụ, kết hợp ba công cụ,... từ đó đưa ra tổ hợp các công cụ nào sẽ cho kết quả

khả quan nhất. Tổng hợp so sánh các kết quả dưới dạng bảng.

Từ các kết quả phân tích để đưa ra đánh giá, gợi ý cho các nhà phát triển khi

thực hiện phân tích dự án cần sử dụng những công cụ nào sao cho phù hợp để đạt được

chất lượng và đảm bảo về mặt chi phí vận hành.

2.2. Tiến hành thử nghiệm

Là phần chính trong luận văn. Học viên sẽ tiến hành phân tích triển khai và

phân tích hạn chế đối với các công cụ phân tích tĩnh được tích hợp trong các IDE

nhằm tìm ra các lỗ hổng bảo mật cũng như những khuyết điểm trong mã nguồn theo

một số chuẩn chung.

Cấu trúc luận văn như sau. Phần 2.2 giải thích cách tiếp cận của học viên để

thực hiện nghiên cứu và cung cấp kết quả để từ đó đưa ra những kết luận đối với

những sự phát triển phần mềm sau này để đảm bảo được chất lượng sản phẩm, cũng

như mức độ an toàn và bảo mật của sản phẩm. Một phần luận văn thực hiện nghiên

cứu và chọn lọc các công cụ phân tích tĩnh như đã trình bày các kiến thức liên quan

của các công cụ trong chương 1. Trong phần 2.2.1, thực hiện nghiên cứu và chọn bộ

dữ liệu kiểm thử Juliet phiên bản 1.3 dành cho các ngôn ngữ java.

2.2.1. Bộ dữ liệu kiểm thử Juliet phiên bản 1.3

Cấu trúc của mã nguồn được chia thành các thư mục tên của mỗi thư mục là đại

diện cho các lớp điểm yếu (CWE). Dưới đây là hình ảnh đại diện một vài thư mục nằm

trong bộ mã nguồn.

25

Hình 2.1: Cấu trúc mã nguồn

Cấu trúc của một lớp trong mã nguồn. Trong bộ mã nguồn được thiết kế gồm

hai phương thức chính. Phương thức bad() và phương thức good(). Ý đồ của tác giả

khi đưa ra hai phương thức này để phục vụ tính một số tiêu chí để đánh giá và phân

tích hiệu suất. Để từ đó đưa ra được độ đo chuẩn xác của các công cụ phân tích tĩnh.

Các tiêu chí được tính như nào sẽ được phân tích rõ hơn ở phần triển khai phân tích

kết quả đầu ra do các công cụ thực hiện.

26

Phương thức bad():

Hình 2.2: Phương thức bad()

Phương thức bad() với các dòng mã nguồn được cài cắm có lỗi về SQL

Injection như trong hình 2.3.

Hình 2.3: Lỗi SQL Ịnjection

Khi các công cụ phân tích lỗi tìm ra các dòng lỗi nằm ở phương thức bad() như

vậy các dòng lỗi được phát hiện đúng.

Phương thức good() được định nghĩa với một số tên như sau: goodG2B(),

goodB2G(), goodG2B1(), goodG2B2(), goodB2G1(), goodB2G2(),...

27

Hình 2.4: Phương thức goodG2B()

Hình 2.5: Phương thức goodB2G()

Khi các công cụ tìm được các dòng lỗi và rơi vào một trong các phương thức

good() thì công cụ phát hiện chưa chính xác.

28

2.2.2. Quá trình chạy công cụ

2.2.2.1. Công cụ SonarQube

Bước 1: Tải SonarQube máy khách về trên máy tính và thực hiện tích hợp bộ

dữ liệu kiểm thử Juliet-Test-Suite vào công cụ để thực hiện phân tích. Trang tải

SonarQube https://www.sonarqube.org/. Do bộ dữ liệu kiểm thử lớn nên không thể

tích hợp và chạy trực tiếp bằng IDE nên phải tải máy chủ SonarQube về trên máy tính

và thực hiện cấu hình để phân tích bộ dữ liệu kiểm thử.

Bước 2: Cầu hình tệp tin sonar-project.properties trong bộ dữ liệu kiểm thử bao

gồm sonar.projectKey, sonarProjectName. Sau đó sử dụng sonar-scanner để quét bộ

dự liệu kiểm thử.

Bước 3: Khi chạy trên máy tính công cụ hoạt động như một trang web nên có

thể vào trực tiếp trang chủ của SonarQube và tích hợp dự án để thực hiện phân tích.

Bước 4: Truy cập vào máy tính cá nhân bằng đường dẫn http://localhost:9000.

Vào dự án để xem kết quả phân tích:

Hình 2.6: Các tiêu chí của SonarQube

Kết quả: SonarQube phát hiện ra 156801 dòng mã lỗi trong dự án. 772319 tổng

số dòng mã nguồn trong bộ dữ liệu kiểm thử được phân tích.

2.2.2.2. Công cụ HuntBugs

Bước 1: Sử dụng công cụ IntelliJ IDE để tích hợp bộ dữ liệu kiểm thử Juliet-

Test-Suite.

Bước 2: Tích hợp plugin HuntBugs vào dự án bằng cách sử dụng maven để

quản lý thư viện để tích hợp. Chạy lệnh sau để thực hiện phân tích dữ liệu:

mvn one.util:huntbugs-maven-plugin:huntbugs

Bước 3: Xem kết quả phân tích sẽ được đưa ra dưới dạng báo cáo và lưu trữ

trong thư mục target/huntbugs/report.csv của dự án.

29

Hình 2.7: Các tiêu chí của HuntBugs

Kết quả: HuntBugs phát hiện ra 8832 dòng mã lỗi trong dự án.

2.2.2.3. Công cụ phân tích PMD

Bước 1: Sử dụng công cụ Eclipse để tích hợp bộ dữ liệu kiểm thử Juliet-Test-

Suite.

Bước 2: Tải plugin PMD tích hợp vào Eclipse.

Bước 3: Chạy phân tích bộ dữ liệu và kết quả được lưu trong thư mục report

của dự án report/pmd-report.txt.

Chú ý: Nhược điểm đối với bộ dữ liệu lớn như Juliet-Test-Suite sẽ làm mất rất

nhiều thời gian phân tích và có thể dẫn đến treo công cụ. Vì vậy tôi đã chạy lại bộ dữ

liệu với command line của hệ điều hành với một số dòng lệnh cho trang chủ PMD

cung cấp:

.\pmd.bat -d D:\document\Web\PMD\src -f html -R rulesets/java/quickstart.xml

.report.csv\Desktop\DEV\Users\C:

Hình 2.8: Các tiêu chí của PMD

Kết quả: PMD phát hiện 250205 dòng mã lỗi trong dự án.

2.2.2.4. Công cụ phân tích IntelliJ IDE

Bước 1: Sử dụng công cụ IntelliJ IDE để tích hợp bộ dữ liệu kiểm thử Juliet-

Test-Suite.

Bước 2: Sử dụng chức phân tích có sẵn của công cụ Analyze/Inspect code để

phân tích dữ liệu bộ kiểm thử.

Bước 3: Sau khi phân tích kết quả sẽ được định nghĩa dưới dạng tệp tin .xml

nằm trong thư mục inspection-results-dir của dự án.

Bước 4: Chuyển tệp dữ liệu đầu ra từ định dạng xml sang định dạng csv.

30

Hình 2.9: Các tiêu chí của IntelliJ IDE

Kết quả: IntelliJ IDE phát hiện ra 583727 mã lỗi trong dự án.

2.2.2.5. Công cụ phân tích VCG

Bước 1: Sử dụng công cụ VisualCodeGrepper để tích hợp bộ dữ liệu kiểm thử

Juliet-Test-Suite. Tải công cụ trên trang: https://github.com/nccgroup/VCG.

Bước 2: Cấu hình định dạng tệp tin báo cáo và nơi lưu.

Bước 3: Thực hiện chạy phân tích mã nguồn với chức năng có sẵn trên IDE:

Scan/Scan code only (Ignore comments).

Hình 2.10: Các tiêu chí của VCG

Kết quả: VCG phát hiện ra 28735 mã lỗi trong dự án.

2.2.2.6. Công cụ phân tích SpotBugs

Bước 1: Sử dụng công cụ Eclipse ể tích hợp bộ dữ liệu kiểm thử Juliet-Test-

Suite.

Bước 2: Tải plugin SpotBugs tích hợp vào Eclipse. Sau đó chọn bộ dữ liệu

kiểm thử. Nhấn chuột phải chọn SpotBugs sau đó chọn find bug và thực hiện phân tích

mã nguồn.

Bước 3: Tệp kết quả được sinh ra dạng xml và nằm trong không gian làm việc

của IDE theo đường dẫn sau: .metadata\.plugins\com.github.spotbugs.plugin.eclipse\.

Sau đó chuyển tệp kết quả từ định dạng xml sang định dạng csv.

31

Hình 2.11: Các tiêu chí của SpotBugs

Kết quả: SpotBugs phát hiện ra 3331 mã lỗi trong dự án.

2.2.2.7. Công cụ phân tích Infer

Bước 1: Hiện tại infer không hỗ trợ chạy trên hệ điều hành window nên cài

máy ảo chạy hệ điều hành linux để thực hiện phân tích dữ liệu.

Bước 2: Tải infer bản 0.17.0.

Bước 3: Thực hiện phân tích dữ liệu bằng các lệnh trên linux.

Bước 4: Kết quả được phân tích ở một số định dạng như: json, tệp tin cơ sở dữ

liệu: ví dụ results.db. Chuyển kết quả định dạng từ json sang csv hoặc chuyển tệp tin

kết quả vào một hệ cơ sở dữ liệu SQLite sau đó xuất báo cáo định dạng csv.

Hình 2.12: Các tiêu chí của Infer

Kết quả: Infer phát hiện ra 5000 mã lỗi trong dự án.

2.2.3. Tổng hợp dữ liệu

Sau khi đã có các kết quả do công cụ phân tích như ở phần 2.2.2. Dựa vào các

kết quả đã có chuẩn hóa dữ liệu theo một số tiêu chí chung như sau: đường dẫn tệp dữ

liệu, lỗi tìm thấy từ dòng, lỗi tìm thấy đến dòng. Tất cả các tệp dữ liệu đầu vào được

chuẩn hóa lưu dưới định dạng mở rộng .csv. Định dạng tệp dữ liệu đầu vào như hình

2.13:

32

Hình 2.13: Chuẩn hóa dữ liệu đầu vào

2.2.4. Viết công cụ phân tích dữ liệu

Ngôn ngữ sử dụng: Java 8.

Thông tin dữ liệu đầu vào: Các tệp dữ liệu định dạng .csv được chuẩn hóa như

phần 2.2.3.

Dữ liệu đầu ra các tiêu chí đã được tính toán: TP, FP, FN, Recall, Precision,

Discrimination, Discrimination Rate.

Cách thực hiện phân tích dữ liệu và tính toán:

➢ Đọc từ tệp dữ liệu đầu vào kiểm tra dòng mã được xác định trong tệp dữ liệu

nằm trong các phương thức bad(), các phương thức good(), hay nằm ngoài

các phương thức trên.

➢ Quét toàn bộ mã nguồn của bộ kiểm thử. Đọc từng dòng mã nguồn của bộ dữ

liệu kiểm thử Juliet để xác định được một phương thức bắt đầu từ dòng nào

đến dòng nào và các dòng mã lỗi trong tệp dữ liệu ban đầu có nằm trong các

dòng đó không. Để thực hiện với việc trên tôi sử dụng cấu trúc dữ liệu Stack

với bài toàn dấu ngoặc đúng. Đây là bài toán đã xác định được quy luật đóng

mở ngoặc dấu của một cấu trúc mã. Như trong bộ dữ liệu kiểm thử Juliet đều

được viết bằng java nên dễ dàng tìm được quy luật dấu dành cho một phương

thức bất kỳ. Trong cú pháp câu lệnh của ngôn ngữ java đối với một phương

thức như sau:

Hình 2.14: Cú pháp lệnh trong Java.

33

➢ Trong cú pháp mã nguồn java khi dấu “{” được mở sẽ phải có dấu “}” đóng

tương ứng. Từ quy luật trên xác định được phạm vi của mã lỗi trong một

phương thức. Trong hình 2.13 có 7 lỗi được báo cáo trong tệp tin java

CWE113_HTTP_Response_Splitting__connect_tcp_addCookieServlet_01

tại lần lượt các dòng 49, 107, 128, 130, 153, 211, 223. Trong khi đó phương

thức bad() trong tệp tin trên bắt đầu từ dòng 35 đến dòng 112 như vậy chỉ có

2 lỗi được tìm đúng đó là lỗi ở dòng 49 và dòng 107. Từ đó chỉ số TP = 2 và

chỉ số FP = 5.

2.2.5. Thực hiện phân tích dữ liệu

Sử dụng công cụ đã tạo ra ở phần 2.2.4 để thực hiện phân tích và tính hiệu suất

phát hiện lỗi của các công cụ theo các chỉ số sau: TP, FP, Recall, Precision,

Discrimination, Discrimination Rate.

2.2.5.1. Phân tích đơn công cụ không theo chuẩn CWE

Input: tệp tin kết quả của các công cụ dạng csv đã được chuẩn hóa phần 2.2.3.

Output: là kết quả tính các chỉ số TP, FP, Recall, Precision, Discrimination,

Discrimination Rate.

Ví dụ: với tệp tin đầu vào của SonarQube

Hình 2.15: Tệp dữ liệu đầu vào của công cụ SonarQube

Hình 2.15 công cụ SonarQube đã quét và phân tích ra 11 dòng lỗi trong tệp tin

CWE113_HTTP_Response_Splitting__connect_tcp_addCookieServlet_02.java. Đưa

kết quả là đầu vào của công cụ đọc tệp tin java trên xác định phạm vi của phương thức

bad() từ dòng 35 đến dòng 117. Kiểm tra tệp tin kết quả như hình 2.15 để tính ra các

chỉ số TP, FP, Recall, Precision, Discrimination, Discrimination Rate. Như vậy có 2

dòng lỗi nằm trong phương thức bad() là dòng 48 và dòng 112. Từ đó TP = 2, cứ như

vậy tính với các tệp tin khác được tìm ra là có lỗi và tìm ra được giá trị của TP đến khi

đọc hết tệp dữ liệu đầu vào. Tiếp theo là chỉ số FP như kết quả trong hình 2.15 thì có 9

dòng không nằm trong phương thức bad() như vậy công cụ phân tích lỗi không đúng.

Từ đó giá trị FP = 9, cứ làm như vậy đọc hết tệp tin kết quả để tính ra giá trị FP cuối

cùng. Tiếp theo tính chỉ số FN, cần hai giá trị sau là tổng các tệp tin trong bộ dữ liệu

kiểm thử và số tệp tin được tìm ra là có lỗi. Vì FN được định nghĩa như sau: FN - Chỉ

số thể hiện có lỗi trong mã nguồn nhưng mã chứa lỗi không được tìm ra và không

được đưa vào báo cáo. (Định nghĩa trong phần 1.3). Cụ thể tổng số tệp tin chứa mã

nguồn lỗi trong bộ dữ liệu kiểm thử là 46196, số lượng tệp tin được quét ra là có lỗi

đối với công cụ SonarQube là 28875. Từ đó FN = 46196 – 28875. Từ một số dữ liệu

đã được tính toán thì tính được các chỉ số sau: Recall = TP / (TP + FN); Precision = TP

34

/ (TP + FP). Tính chỉ số Discrimination quét toàn bộ tệp tin trên nếu cả 11 lỗi tìm được

đều được tính là TP thì được giá trị Discrimination = 1, tương tự quét và phân tích các

tệp tin java khác được tìm ra là có lỗi và đưa ra kết quả cuối cùng của Discrimination.

Sau khi tính được Discrimination thì giá trị của Discrimination Rate = Discrimination /

(TP + FN). Trong nghiên cứu đo hiệu suất phát hiện lỗi của các công cụ tập trung và

hướng đến phân tích 2 chỉ số sau: Recall (Độ bao phủ mã nguồn), Precision (Hiệu suất

tìm lỗi chính xác).

2.2.5.2. Phân tích đơn công cụ theo chuẩn CWE

Trong nghiên cứu học viên sử dụng 12 chuẩn CWE để tính hiệu suất phát hiện

lỗi của các công cụ:

Xác thực và kiểm soát truy cập (Authentication and Access Control): người

tấn công có thể dành quyền truy cập vào hệ thống nếu không có cơ chế xác thực và

kiểm soát truy cập thích hợp. Kiểm tra lớp điểm yếu này để biết rằng mã nguồn có

đang ngăn chặn truy cập trái phép vào hệ thống không. Một số lớp CWE được sử dụng

trong nghiên cứu: CWE-15, CWE-222, CWE-223, CWE-247, CWE-256, CWE-259,

CWE-272, CWE-284, CWE-491, CWE-500, CWE-549, CWE-566, CWE-582, CWE-

605, CWE-607, CWE-643, CWE-620. Đặc điểm của bộ dữ liệu kiểm thử chứa các thư

mục và tệp tin mang nhưng lỗi và lớp điểm yếu đã được định nghĩa. Ví dụ: thư mục

sau CWE15_External_Control_of_System_or_Configuration_Setting tương ứng với

lớp CWE-15 thuộc lỗi xác thực và kiểm soát truy cập. Giả sử có tệp dữ liệu đầu vào là

kết quả chuẩn hóa của công cụ SonarQube phân thích như sau:

Hình 2.16: Ví dụ xác thực và kiểm soát truy cập

Quét trong tệp tin đầu vào hình 2.16 có các lớp tương ứng nằm trong dữ liệu

đường dẫn tệp java bị lỗi hay không. Ví dụ đường dẫn của tệp tin java chứa lỗi

CWE15_External_Control_of_System_or_Configuration_Setting/CWE15_External_C

ontrol_of_System_or_Configuration_Setting__connect_tcp_01.java có chứa thông tin

lớp là CWE15. Như vậy sẽ lấy tất cả các thư mục có chứa CWE15 và phân tích các tệp

java để tính ra chỉ số TP, FP, Recall, Precision, Discrimination, Discrimination Rate –

Thực hiện như phần tích đơn công cụ không theo chuẩn CWE 2.2.5.1.

Chất lượng mã nguồn (Code quality): Chất lượng mã nguồn là một vấn đề vô

cùng quan trọng trong phát triển phần mềm. Chất lượng mã nguồn có thể quyết định

đến hiệu suất của phần mềm cũng như khả năng mở rộng các chức năng của sản phẩm.

Chất lượng mã nguồn tùy vào từng dự án sẽ có những quy định và luật riêng nhưng

đều hướng đến mục đích nâng cao chất lượng sản phẩm dễ bảo trì, dễ phát triển, hạn

chế tối đa lỗi. Một số lớp CWE được sử dụng trong nghiên cứu: CWE-398, CWE-477,


35

563, CWE-570, CWE-571, CWE-579, CWE-581, CWE-585, CWE-597, CWE-676,

CWE-685, CWE-688. Ví dụ:

Hình 2.17: Ví dụ chất lượng mã nguồn



CWE398_Poor_Code_Quality/CWE398_Poor_Code_Quality__empty_block_01.java

có chứa thông tin lớp là CWE398. Như vậy sẽ lấy tất cả các thư mục có chứa CWE398

và phân tích các tệp java để tính ra chỉ số TP, FP, Recall, Precision, Discrimination,

Discrimination Rate – Thực hiện như phần tích đơn công cụ không theo chuẩn CWE

2.2.5.1.

Quản lý luồng kiểm soát (Control Flow Management): Quản lý luồng điều

khiển giải quyết các vấn đề về thời gian và đồng bộ hóa có thể gây ra kết quả không

mong muốn khi mã được thực thi. Sau đây là một ví dụ về quản lý luồng kiểm soát –

truy xuất môi trường chạy java hiện tại Runtime.getRuntime().exit(1) câu lệnh thực

hiện thoát khỏi môi trường chạy một cách bất thường. Đây là một lỗi trong quá trình

lập trình cần phải chú ý. Một số lớp CWE được sử dụng trong nghiên cứu: CWE-364,



CWE-832, CWE-833, CWE-835. Ví dụ:

Hình 2.18: Ví dụ quản lý luồng kiểm soát



CWE382_Use_of_System_Exit/CWE382_Use_of_System_Exit__Servlet_Runtime_0

1.java có chứa thông tin lớp là CWE382. Như vậy sẽ lấy tất cả các thư mục có chứa

CWE382 và phân tích các tệp java để tính ra chỉ số TP, FP, Recall, Precision,

Discrimination, Discrimination Rate – Thực hiện như phần tích đơn công cụ không

theo chuẩn CWE 2.2.5.1.

36

Mã hóa và tính ngẫu nhiên (Encryption and Randomness): Mã hóa được sử

dụng để cung cấp tính bảo mật của dữ liệu. Tuy nhiên, nếu sử dụng thuật toán mã hóa

yếu hoặc sai, kẻ tấn công có thể chuyển đổi bản mã thành văn bản thuần túy ban đầu

của nó. Một ví dụ sẽ là việc sử dụng bộ tạo số ngẫu nhiên giả (PRNG – Bộ sinh số giả

ngẫu nghiên) yếu. Việc sử dụng PRNG yếu có thể cho phép kẻ tấn công đoán số tiếp

theo được tạo ra. Ví dụ khi một yêu cầu lấy thông tin người dùng và mật khẩu để đăng

nhập nhưng khi trả kết quả về cho máy chủ xử lý thì các thông tin trên chỉ là thông tin

dạng chữ bình thường mà không được mã hóa để che giấu thông tin.

Hình 2.19: Ví dụ mã nguồn có lỗi không mã hóa thông tin mật khẩu

Một số lớp CWE được sử dụng trong nghiên cứu: CWE-315, CWE-366, CWE-


CWE-666, CWE-667, CWE-674, CWE-698, CWE-764. Ví dụ:

Hình 2.20: Ví dụ mã hóa và tính ngẫu nhiên



CWE315_Plaintext_Storage_in_Cookie/CWE315_Plaintext_Storage_in_Cookie__Ser

vlet_01.java có chứa thông tin lớp là CWE315. Như vậy sẽ lấy tất cả các thư mục có

chứa CWE315 và phân tích các tệp java để tính ra chỉ số TP, FP, Recall, Precision,



Xử lý lỗi (Error Handing): Xử lý lỗi đề cập đến việc dự đoán, phát hiện và

giải quyết các lỗi lập trình ứng dụng. Xử lý lỗi được sử dụng khi một chương trình

hoạt động không mong muốn. Tuy nhiên, nếu một chương trình không xử lý lỗi đúng

cách, nó có thể dẫn đến những hậu quả không mong muốn. Một ví dụ sẽ là giá trị trả

về không được kiểm tra. Nếu một lập trình viên cố gắng cấp phát bộ nhớ và không

kiểm tra được quy trình cấp phát có thành công hay không, thì lỗi phân đoạn có thể

xảy ra nếu bộ nhớ không được cấp phát đúng cách. Một số lớp CWE được sử dụng

trong nghiên cứu: CWE-248, CWE-252, CWE-253, CWE-273, CWE-390, CWE-391,

CWE-396, CWE-397, CWE-440, CWE-584, CWE-600, CWE-617. Ví dụ:

37

Hình 2.21: Ví dụ xử lý lỗi



CWE396_Catch_Generic_Exception/CWE396_Catch_Generic_Exception__Exception

_01.java có chứa thông tin lớp là CWE396. Như vậy sẽ lấy tất cả các thư mục có chứa




Xử lý tệp tin (File Handing): Xử lý tệp liên quan đến việc đọc và ghi vào tệp.

Một ví dụ sẽ là đọc từ một tệp do người dùng cung cấp trên đĩa cứng. Thật không may,

đối thủ đôi khi có thể cung cấp các đường dẫn tương đối có chứa dấu chấm và dấu

gạch chéo. Kẻ tấn công có thể sử dụng phương pháp này để đọc hoặc ghi vào tệp ở vị

trí khác trên đĩa cứng so với dự kiến của nhà phát triển. Một số lớp CWE được sử

dụng trong nghiên cứu: CWE-23, CWE-36, CWE-377, CWE-378, CWE-379, CWE-

675. Ví dụ:

Hình 2.22: Ví dụ xử lý tệp tin



CWE23_Relative_Path_Traversal/CWE23_Relative_Path_Traversal__connect_tcp_01

.java có chứa thông tin lớp là CWE23. Như vậy sẽ lấy tất cả các thư mục có chứa




Lỗi rò rỉ thông tin (Information Leaks): Lỗi rò rỉ thông tin có thể khiến

người dùng cung cấp dữ liệu ngoài ý muốn. Sự cố này xảy ra khi hệ thống quên xóa

38

một khối bộ nhớ trước khi sử dụng nó để xây dựng một thông báo được gửi đến một

bên không đáng tin cậy. Ví dụ, các nhà phát triển thường sử dụng thông báo lỗi để

thông báo cho người dùng rằng đã xảy ra lỗi. Thật không may, nếu thông tin nhạy cảm

được cung cấp trong thông báo lỗi, kẻ thù có thể sử dụng nó để khởi động các cuộc tấn

công trong tương lai vào hệ thống. Một số lớp CWE được sử dụng trong nghiên cứu:


535, CWE-539, CWE-591, CWE-598, CWE-614, CWE-615. Ví dụ:

Hình 2.23: Ví dụ lỗi rò rỉ thông tin



CWE534_Info_Exposure_Debug_Log/CWE534_Info_Exposure_Debug_Log__Servle

t_01.java có chứa thông tin lớp là CWE534. Như vậy sẽ lấy tất cả các thư mục có chứa




Khởi tạo và đóng tài nguyên (Initialization and Shutdown): Việc khởi tạo và

đóng tài nguyên thường xảy ra trong mã nguồn. Ví dụ, trong C/C++ nếu bộ nhớ được

cấp phát trên heap thì nó phải được phân bổ sau khi sử dụng. Nếu bộ nhớ không được

phân bổ, nó có thể gây rò rỉ bộ nhớ và ảnh hưởng đến hiệu suất hệ thống. Ví dụ trong

java khi thực hiện đọc ghi tệp tin có đoạn mã nguồn sau: BufferedReader

readerBuffered = null; Sau khi thực hiện đọc ghi xong nếu readerBuffered != null thì

phải thực hiện đóng trong khối lệnh finally. Như vậy tài nguyên được sử dụng luôn

luôn được đóng khi sử dụng xong và tránh bị tranh chấp tài nguyên với các tác vụ

khác. Một số lớp CWE được sử dụng trong nghiên cứu: CWE-400, CWE-401, CWE-



775, CWE-789. Ví dụ:

Hình 2.24: Ví dụ khởi tạo và đóng tài nguyên

39



CWE404_Improper_Resource_Shutdown/CWE404_Improper_Resource_Shutdown__

console_InputStreamReader_01.java có chứa thông tin lớp là CWE404. Như vậy sẽ

lấy tất cả các thư mục có chứa CWE404 và phân tích các tệp java để tính ra chỉ số TP,

FP, Recall, Precision, Discrimination, Discrimination Rate – Thực hiện như phần tích

đơn công cụ không theo chuẩn CWE 2.2.5.1.

Injection: Là một cách tấn công khai thác lỗ hổng từ chính mã nguồn của dựa

án. Việc chèn mã có thể xảy ra khi người dùng nhập không được xác thực đúng cách.

Một trong những loại lỗi tiêm phổ biến nhất là tập lệnh chéo trang (XSS). Kẻ tấn công

có thể đặt các chuỗi truy vấn vào trường đầu vào có thể khiến dữ liệu không mong

muốn được hiển thị. Điều này thường có thể được ngăn chặn bằng cách sử dụng xác

thực đầu vào thích hợp hoặc mã hóa dữ liệu. Hay một ví dụ khác là SQL Injection là

một lỗi câu lệnh truy vấn thao tác với cơ sở dữ liệu bị khai thác như ví dụ 2 trong phần

1.5. Một số lớp CWE được sử dụng trong nghiên cứu: CWE-78, CWE-80, CWE-81,

CWE-83, CWE-89, CWE-90, CWE-113, CWE-129, CWE-134, CWE-426, CWE-427,

CWE-470, CWE-601, CWE-643. Ví dụ:

Hình 2.25: Ví dụ Injection



CWE89_SQL_Injection/s01/CWE89_SQL_Injection__connect_tcp_executeBatch_01.

java có chứa thông tin lớp là CWE89. Như vậy sẽ lấy tất cả các thư mục có chứa




Phần mềm độc hại (Malicious Logic): Phần mềm độc hại được phát triển có

chủ đích để tấn công các hệ thống. Đây là một lỗi về an toàn bảo mật thông tin. Một số

kiểu phần mềm độc hại:

• Trojan Horse: là một kiểu tấn công giả mạo một tệp tin hợp pháp hoặc một

chương trình hữu ích, nhưng lại có một số chức năng không mong muốn. Ví

dụ mã nguồn giả mạo (fake codec): Việc tải xuống từ trang web này thông

báo cho người dùng rằng sẽ cho phép bạn xem video hay miễn phí trực

tuyến, nhưng khi người dùng chọn video xem sẽ bị tấn công từ phần mềm

độc hại đã được gài vào hệ thống qua những mã nguồn giả mạo.

40

• Rabbit/Bacterium: Là một kiểu tấn công tự tái tạo liên tục để làm cạn kiệt tài

nguyên hệ thống.

• Logic bomb: Là một kiểu tấn công có chủ đích, khi người tấn công sử dụng

một đoạn mã được cố ý chèn vào một hệ thống phần mềm sẽ thiết lập một

chức năng độc hại khi đáp ứng các điều kiện cụ thể. Ví dụ: một lập trình viên

có thể ẩn một đoạn mã bắt đầu xóa tệp (chẳng hạn như trình kích hoạt cơ sở

dữ liệu lương), nếu họ bị chấm dứt hợp đồng với công ty.

• Trapdoor/Backdoor: Là một kiểu tấn công cho phép truy cập hệ thống trái

phép thông qua một số phần mềm, phương tiện, chức năng không được cấp

phép.

Một số lớp CWE được sử dụng trong nghiên cứu: CWE-111, CWE-114, CWE-

321, CWE-325, CWE-506, CWE-510, CWE-511, CWE-546. Ví dụ:

Hình 2.26: Ví dụ phần mềm độc hại



CWE114_Process_Control/CWE114_Process_Control__basic_01.java có chứa thông

tin lớp là CWE114. Như vậy sẽ lấy tất cả các thư mục có chứa CWE114 và phân tích

các tệp java để tính ra chỉ số TP, FP, Recall, Precision, Discrimination, Discrimination

Rate – Thực hiện như phần tích đơn công cụ không theo chuẩn CWE 2.2.5.1.

Xử lý số (Number Handling): Xử lý số là các lỗi xoay quanh vấn đề về xử lý

số bao gồm tính toán không chính xác cũng như lưu trữ và chuyển đổi số. Một ví dụ là

tràn số nguyên. Trên hệ thống 32 bit, giá trị lớn nhất của số nguyên có dấu là

2.147.483.647. Nếu giá trị này được tăng lên một, giá trị mới của nó sẽ là một số âm

chứ không phải là 2.147.483.648 như mong đợi do giới hạn về số lượng bit được sử

dụng để lưu trữ số. Một số lớp CWE được sử dụng trong nghiên cứu: CWE-190,


681. Ví dụ:

Hình 2.27: Ví dụ phần mềm độc hại

41



CWE190_Integer_Overflow/s01/CWE190_Integer_Overflow__byte_console_readLin

e_add_01.java có chứa thông tin lớp là CWE190. Như vậy sẽ lấy tất cả các thư mục có




Xử lý con trỏ và tham chiếu (Pointer and Reference Handling): Con trỏ

thường được sử dụng trong mã nguồn để tham chiếu đến một khối bộ nhớ mà không

cần phải tham chiếu trực tiếp đến khối bộ nhớ. Một trong những lỗi con trỏ phổ biến

nhất là tham chiếu đến con trỏ NULL. Điều này xảy ra khi con trỏ được mong đợi để

trỏ đến một khối bộ nhớ, nhưng thay vào đó nó trỏ đến giá trị NULL. Điều này có thể

gây ra một ngoại lệ và dẫn đến sự cố hệ thống. Ví dụ con trỏ NULL gây lỗi hệ thống:

Hình 2.28: Mã nguồn gây ra lỗi NullPointer

Mã nguồn trong hình 2.28 khi thực hiện sẽ gây ra lỗi NullPoiter và làm cho hệ

thống không tiếp tục hoạt động để sửa lỗi trên thay vì dùng một dấu & hãy dùng hai

dấu && để câu lệnh trở thành điều kiện đồng thời nếu một điều kiện không thỏa mãn

sẽ không kiểm tra điều kiện tiếp theo. Một số lớp CWE được sử dụng trong nghiên

cứu: CWE-395, CWE-467, CWE-468, CWE-469, CWE-475, CWE-476, CWE-562,

CWE-587, CWE-588, CWE-690, CWE-843. Ví dụ:

Hình 2.29: Ví dụ xử lý con trỏ và tham chiếu


đường dẫn tệp java bị lỗi hay không. Ví dụ lớp đường dẫn của tệp tin java chứa lỗi

CWE476_NULL_Pointer_Dereference/CWE476_NULL_Pointer_Dereference__binar

y_if_01.java có chứa thông tin lớp là CWE476. Như vậy sẽ lấy tất cả các thư mục có




42

2.2.5.3. Phân tích tổ hợp các công cụ không theo chuẩn CWE

Tính tổ hợp chập 2, chập 3, chập 4 tệp dữ liệu của các công cụ lại với nhau để

tính TP, FP, Recall, Precision, Discrimination, Discrimination Rate từ đó đưa ra kết

quả khi thực hiện phân tích lỗi từng công cụ so với kết hợp nhiều công cụ sẽ cải thiện

như nào. Giả sử tổ hợp chập 2 tệp dữ liệu của các công cụ: SonarQube và HuntBugs

thì hai tệp dữ liệu của hai công cụ này kết hợp lại với nhau thành một tệp dữ liệu mới

từ đó phân tích tệp dữ liệu tổng hợp để tính ra các chỉ số.

Khi tổng hợp nhiều tệp tin sẽ xảy ra trường hợp một bản ghi có cùng đường dẫn

đến tệp tin lỗi, cùng lỗi từ dòng, cùng lỗi đến dòng. Chuyển đổi các bản ghi vào thành

một đối tượng trong java có ba thuộc tính sau: path, fromLine, toLine sau đó đưa các

đối tượng vào một cấu trúc dữ liệu giải thuật đó là Set từ đó sẽ lọc được các bản ghi

trùng nhau theo cả ba tiêu chí chuẩn hóa. Sau đó đưa danh sách Set đi phân tích duyệt

từng phần tử rồi đi so sánh với bộ dữ liệu kiểm thử để tính ra các chỉ số TP, FP,

Recall, Precision, Discrimination, Discrimination Rate – Thực hiện như phần tích đơn

công cụ không theo chuẩn CWE 2.2.5.1.

Ví dụ tổ hợp 2 tệp tin kết quả từ công cụ SonarQube và HuntBugs:

Hình 2.30: Ví dụ trùng bản ghi của SonarQube

Hình 2.31: Ví dụ trùng bản ghi của HuntBugs

Theo hình 2.30 và hình 2.31 khi kết hợp kết quả của 2 công cụ này sẽ có bản

ghi trùng nhau là bản ghi số 45416 và 8257 khi kết hợp 2 tệp tin kết quả sẽ loại bỏ một

bản ghi để tính các chỉ số được chính xác.

2.2.5.4. Phân tích tổ hợp công cụ theo chuẩn CWE

Tính tổ hợp như trên theo từng danh mục của tiêu chuẩn CWE thực hiện như

các phần 2.2.5.1. Phân tích đơn công cụ không theo chuẩn CWE, 2.2.5.2. Phân tích

đơn công cụ theo chuẩn CWE, 2.2.5.3. Phân tích tổ hợp các công cụ không theo chuẩn

CWE.

43

Chương 3. KẾT QUẢ VA ĐÁNH GIÁ

3.1. Kết quả

Từ các thực nghiệm ở chương 2, học viên đã tổng hợp và đưa ra một số kết quả

như sau:

3.1.1. Phân tích không theo tiêu chuẩn CWE

Bảng 3.1: Bảng dữ liệu phân tích đơn công cụ

Biểu đồ 3.1: Biểu đồ tính hiệu suất của từng công cụ

Dựa vào bảng tổng hợp số liệu bảng 3.1 và biểu đồ 3.1 công cụ có độ chính xác

cao nhất là SonarQube với 60% và công cụ có độ chính xác thấp nhất là HuntBugs

47%. Về độ bao phủ mã nguồn công cụ IntelliJ IDE đang chiếm 86% và thấp nhất là

SpotBugs 1%. Bước đầu đánh giá thì SonarQube và IntelliJ IDE đang khẳng định về

độ chính xác và độ bao phủ mã nguồn vượt trội hơn so với các công cụ khác.

3.1.2. Phân tích theo từng danh mục chuẩn CWE

Bảng 3.2: Bảng phân tích đơn công cụ theo chuẩn CWE

Từ bảng 3.2 kết quả đo hiệu suất của các công cụ phân theo lớp yếu điểm CWE

chi tiết như sau:

Xác thực và kiểm soát truy cập (Authentication and Access Control):

• Độ bao phủ: IntelliJ IDE cao nhất với 53% và thấp nhất là SpotBugs 0%.

• Độ chính xác: Infer cao nhất với 100% và thấp nhất là SpotBugs là 0%.

44

Chất lượng mã nguồn (Code quality):

• Độ bao phủ: IntelliJ IDE cao nhất với 99% và thấp nhất là Infer, SpotBugs,

VCG, HuntBugs là 0%.

• Độ chính xác: IntelliJ IDE cao nhất với 72% và thấp nhất là Infer, SpotBug,

VCG, HuntBugs là 0%.

Quản lý luồng kiểm soát (Control Flow Management):


HuntBugs là 0%.

• Độ chính xác: IntelliJ IDE cao nhất với 53% và thấp nhất là Infer, SpotBugs,

HuntBugs là 0%.

Mã hóa và tính ngẫu nhiên (Encryption and Randomness):


HuntBugs là 0%.

• Độ chính xác: VCG cao nhất với 83% và thấp nhất là Infer, SpotBugs,

HuntBugs là 0%.

Xử lý lỗi (Error Handling):

• Độ bao phủ: PMD, IntelliJ IDE cao nhất với 100% và thấp nhất là Infer,

SpotBugs, VCG, HuntBugs là 0%.

• Độ chính xác: PMD cao nhất với 72% và thấp nhất là Infer, SpotBugs, VCG,

HuntBugs là 0%.

Xử lý tệp tin (File Handling):

• Độ bao phủ: IntelliJ IDE cao nhất với 94% và thấp nhất là Infer, SpotBugs là

0%.

• Độ chính xác: VCG cao nhất với 61% và thấp nhất là Infer, SpotBugs là 0%.

Lỗi rò rỉ thông tin (Information Leaks):


HuntBugs là 0%.

• Độ chính xác: SonarQube cao nhất với 56% và thấp nhất là Infer, SpotBugs,

HuntBugs là 0%.

Khởi tạo và đóng tài nguyên (Initialization and Shutdown):


HuntBugs là 0%.

• Độ chính xác: SonarQube cao nhất với 89% và thấp nhất là Infer, SpotBugs,

HuntBugs là 0%.

Injection:

• Độ bao phủ: IntelliJ IDE cao nhất với 95% và thấp nhất là Infer là 0%.

• Độ chính xác: SonarQube cao nhất với 66% và thấp nhất là Infer là 0%.

Phần mềm độc hại (Malicious Logic):

• Độ bao phủ: IntelliJ IDE cao nhất với 100% và thấp nhất là Infer, SpotBugs

là 0%.

45

• Độ chính xác: HuntBugs cao nhất với 100% và thấp nhất là Infer, SpotBugs

là 0%.

Xử lý số (Number Handling):

• Độ bao phủ: IntelliJ IDE cao nhất với 60% và thấp nhất là SpotBugs,

HuntBugs là 0%.

• Độ chính xác: SonarQube cao nhất với 54% và thấp nhất là SpotBugs,

HuntBugs là 0%.

Xử lý con trỏ và tham chiếu (Pointer and Reference Handling):


HuntBugs là 0%.

• Độ chính xác: PMD cao nhất với 60% và thấp nhất là Infer, SpotBugs,

HuntBugs là 0%.

Kết luận 1: Độ bảo phủ mã nguồn tốt nhất qua phân tích theo các lớp yếu điểm

CWE là IntelliJ IDE, độ đo hiệu suất phát hiện lỗi chính xác nhất với tần số xuất hiện

nhiều ở các yếu điểm CWE là SonarQube.

3.1.3. Phân tích tổ hợp công cụ không theo chuẩn CWE

Độ bao phủ cao nhất là 97% với tổ hợp các công cụ sau: SonarQube, IntelliJ

IDE.

Độ bao phủ thấp nhất là 4% với tổ hợp công cụ SpotBugs + Infer.

Độ chính xác cao nhất là 60% với tổ hợp công cụ SonarQube + SpotBugs.

Độ chính xác thấp nhất là 34% với tổ hợp công cụ SpotBugs + Infer.

3.1.4. Phân tích tổ hợp theo chuẩn CWE

Xác thực và kiểm soát truy cập (Authentication and Access Control):

• Độ bao phủ có hiệu suất cao nhất đạt 100% là tổ hợp của các công cụ sau:

SonarQube, IntelliJ IDE, PMD.

• Độ bao phủ có hiệu suất thấp nhất với 4% là HuntBugs + SpotBugs.

• Độ chính xác có hiệu suất cao nhất với 100% là SpotBugs + Infer.

• Độ chính xác có hiệu suất thấp nhất với 54% là HuntBugs + PMD.

Chất lượng mã nguồn (Code quality):



• Độ bao phủ có hiệu suất thấp nhất với 0% là tổ hợp của các công cụ sau:

VCG, SpotBugs, Infer.

• Độ chính xác có hiệu suất cao nhất đạt 84% là HuntBugs + PMD + SpotBugs

• Độ chính xác có hiệu suất thấp nhất đạt 0% là tổ hợp của các công cụ sau:

Huntbugs, VCG, SpotBug, Infer.

Quản lý luồng kiểm soát (Control Flow Management):

• Độ bao phủ có hiệu suất cao nhất đạt 100% là tổ hợp các công cụ sau:

SonarQube, IntelliJ IDE.

46


HunBugs, SpotBugs, Infer.

• Độ chính xác có hiệu suất cao nhất đạt 53% là tổ hơp của các công cụ sau:

SonarQube + IntelliJ IDE, PMD + IntelliJ IDE.



Mã hóa và tính ngẫu nhiên (Encryption and Randomness):





• Độ chính xác có hiệu suất cao nhất đạt 53% là tổ hợp của các công cụ sau:

HuntBugs + PMD, HuntBugs + IntelliJ IDE, HuntBugs + VCG, PMD +

VCG, PMD + SpotBugs, PMD + Infer, IntelliJ IDE + VCG, IntelliJ IDE +

SpotBugs, IntelliJ IDE + Infer, VCG + SpotBugs, VCG + Infer.



Xử lý lỗi (Error Handling):



• Độ bao phủ có hiệu suất thấp nhất với 0% là tổ hợp các công cụ sau:

HuntBugs + VCG + Infer, HuntBugs + SpotBugs + Infer, HuntBugs + VCG

+ SpotBugs.

• Độ chính xác có hiệu suất cao nhất đạt 72% là các tôt hợp sau: HuntBugs +

PMD, PMD + VCG, PMD + SpotBugs, PMD + Infer, IntelliJ IDE + VCG,

IntelliJ IDE + SpotBugs, IntelliJ IDE + Infer.

• Độ chính xác có hiệu suất thấp nhất đạt 0% là các tổ hợp sau: HuntBugs +

VCG + SpotBugs, HuntBugs + VCG + Infer, HuntBugs + SpotBugs + Infer,

IntelliJ IDE + VCG +SpotBugs, VCG + SpotBugs + Infer.

Xử lý tệp tin (File Handling):



• Độ bao phủ thấp nhất là 0% với tổ hợp công cụ SpotBugs + Infer.

• Độ chính xác cao nhất là 61% với tổ hợp công cụ sau: IntelliJ IDE + VCG

+SpotBugs, VCG + SpotBugs + Infer.

• Độ chính xác thấp nhất là 0% với tổ hợp công cụ SpotBugs + Infer.

Lỗi rò rỉ thông tin (Information Leaks):



• Độ bao phủ thấp nhất là 0% với tổ hợp công cụ sau: HuntBugs + SpotBugs +

Infer.

47

• Độ chính xác cao nhất là 65% với tổ hợp công cụ HuntBugs + PMD +

IntelliJ IDE + Infer.

• Độ chính xác thấp nhất là 0% với tổ hợp công cụ sau: HuntBugs + SpotBugs

+ Infer

Khởi tạo và đóng tài nguyên (Initialization and Shutdown):


SonarQube, IntelliJ IDE , PMD.


Infer

• Độ chính xác cao nhất là 88% với tổ hợp công cụ sau: SonarQube +

HuntBugs, SonarQube + SpotBugs, SonarQube + Infer.

• Độ chính xác thấp nhất là 0% với tổ hợp công cụ sau: HuntBugs + SpotBugs,

HuntBugs + Infer, SpotBugs + Infer

Injection:



• Độ bao phủ thấp nhất là 2% với tổ hợp công cụ SpotBugs + Infer.

• Độ chính xác cao nhất là 66% với tổ hợp công cụ SonarQube + Infer.

• Độ chính xác thấp nhất là 1% với tổ hợp công cụ SonarQube +Huntbugs +

IntelliJ IDE + VCG.

Phần mềm độc hại (Malicious Logic):

• Độ bao phủ có hiệu suất cao nhất đạt 100% là các tổ hợp sau: SonarQube +

IntelliJ IDE, HuntBugs + IntelliJ IDE, PMD + IntelliJ IDE, IntelliJ IDE +

VCG, IntelliJ IDE + Infer.

• Độ bao phủ thấp nhất là 0% với tổ hợp công cụ HuntBugs + SpotBugs.

• Độ chính xác cao nhất là 71% với tổ hợp công cụ SonarQube + HuntBugs.

• Độ chính xác thấp nhất là 1% với tổ hợp công cụ SonarQube +Huntbugs +

VCG + SpotBugs.

Xử lý số (Number Handling):

• Độ bao phủ có hiệu suất cao nhất đạt 100% là các tổ hợp sau: SonarQube +

IntelliJ IDE, HuntBugs + IntelliJ IDE, PMD + IntelliJ IDE, IntelliJ IDE +

VCG, IntelliJ IDE + Infer.

• Độ bao phủ thấp nhất là 0% với tổ hợp công cụ HuntBugs + SpotBugs

• Độ chính xác cao nhất là 54% với tổ hợp công cụ sau: SonarQube +

HuntBugs, SonarQube + SpotBugs.

• Độ chính xác thấp nhất là 0% với tổ hợp công cụ HuntBugs + SpotBugs.

Xử lý con trỏ và tham chiếu (Pointer and Reference Handling):



48


Infer

• Độ chính xác cao nhất là 63% với tổ hợp công cụ sau: HuntBugs + PMD,

PMD + SpotBugs, PMD + Infer.

• Độ chính xác thấp nhất là 0% với tổ hợp công cụ sau: HuntBugs + SpotBugs

+ Infer.

Kết luận 2: Từ kết quả thí nghiệm tổ hợp các công cụ để phân tích đã cho thấy

sự kết hợp của SonarQube + PMD, PMD + IntelliJ IDE, SonarQube + IntelliJ IDE

mang lại các kết quả phân tích hiệu suất khá cao. Trong đó rất nhiều sự kết hợp mang

lại hiệu quả nhưng lại là sự kết hợp của nhiều công cụ. Do đó học viên tìm kiếm sự kết

hợp ít công cụ và đạt hiệu quả trên như tổ hợp hai công cụ như đã đề cập ở trên.

3.2. Đánh giá

3.2.1. Phân tích không theo chuẩn CWE

Khi thực hiện phân tích đơn công cụ thì cho kết quả:

• Độ bao phủ cao nhất là 86% thuộc về IntelliJ IDE.

• Độ chính xác cao nhất là 60% thuộc về SonarQube.

Khi thực hiện phân tích tổ hợp từ các công cụ thì cho kết quả:

• Độ bao phủ cao nhất là 97% thuộc về IntelliJ IDE và SonarQube.

• Độ chính xác cao nhất là 60% thuộc về SonarQube và SpotBugs.

Kết luận: Sự kết hợp hai công cụ IntelliJ IDE và SonarQube đã cho kết quả khả

quan hơn rất nhiều về độ bao phủ của mã nguồn.

49

3.2.2. Phân tích theo chuẩn CWE

Danh mục Đơn: độ

chính xác

Tổ hợp: độ

chính xác

Đơn: độ

bao phủ

Tổ hợp: độ

bao phủ

Xác thực và kiểm soát truy

cập 100% 100% 53% 97%

Chất lượng mã nguồn 72% 84% 99% 100%

Quản lý luồng kiểm soát 53% 53% 99% 100%

Mã hóa và tính ngẫu nhiên 83% 53% 99% 100%

Xử lý lỗi 72% 72% 100% 100%

Xử lý tệp tin 61% 61% 94% 100%

Lỗi rò rỉ thông tin 56% 65% 93% 100%

Khởi tạo và đóng tài

nguyên 89% 88% 95% 100%

Injection 66% 66% 95% 100%

Phần mềm độc hại 100% 71% 100% 100%

Xử lý số 54% 54% 60% 100%

Xử lý con trỏ và tham

chiếu 60% 63% 100% 100%

Bảng 3.3: So sánh phân tích đơn công cụ và phân tích tổ hợp công cụ

Các giá trị trong bảng đều tính ở hiệu suất đạt cao nhất của hai tiêu chí độ bao

phủ mã nguồn và độ chính xác của việc phân tích lỗi.

Từ bảng kết quả bảng 3.3 cho thấy kết quả phát hiện lỗi đo theo hai tiêu chí độ

bao phủ mã nguồn và độ chính xác của phát hiện lỗi đã tăng lên đáng kể khi thực hiện

phương pháp tổ hợp công cụ để thực phân tích và kiểm thử chất lượng sản phẩm. Như

vậy việc kết hợp các công cụ để phân tích mã nguồn hoàn toàn khả thi và nên được áp

dụng.

50

Chương 4: KẾT LUẬN

Học viên nhận thấy rằng việc sử dụng một công cụ phân tích là không đủ để

phát hiện lỗi trong phần mềm, bao gồm toàn bộ các điểm yếu bảo mật ở giai đoạn triển

khai. Rõ ràng là các nhà phát triển phải đánh đổi một số yêu cầu của họ. Ví dụ: hỗ trợ

ngôn ngữ đầy đủ có thể không được bao gồm bởi một công cụ duy nhất và một công

cụ duy nhất bao gồm nhiều ngôn ngữ có thể có hiệu suất thấp trong nhiều ngôn ngữ.

Việc tích hợp vào các dự án và nâng cấp lên các phiên bản tương ứng đối với

mỗi yêu cầu dự án không dễ dàng hay phần nào đó bị lỗi đòi hỏi phải cần những người

có kinh nghiệm để có thể tích hợp lại và triển khai để phù hợp với các dự án.

Cũng cần cảnh báo rằng có một khoản chi phí cho việc triển khai các công cụ

không hiệu quả. Nếu không có lợi ích từ công cụ, các nhà phát triển sẽ không sử dụng

nó và điều này cũng có thể ảnh hưởng đến khả năng áp dụng công cụ mới trong tương

lai. Điều rất quan trọng là phải cho các nhà phát triển nhận thức sớm về điểm mạnh và

điểm yếu của các công cụ để họ có thể có kỳ vọng thực tế. Rõ ràng là các công cụ

phân tích mã nguồn tĩnh ngày nay vẫn cần nhiều cải tiến để trở nên tốt hơn với việc bắt

các lỗi triển khai. Tuy nhiên, sẽ rất hữu ích khi các nhà phát triển là một phần của việc

ra quyết định để họ biết khả năng của các công cụ.

Việc sử dụng một công cụ cho dự án không thực sự hiệu quả rất nhiều lỗ hổng,

lỗi vẫn không bị phát hiện. Nhưng khi kết hợp hai rồi nhiều công cụ thì với các sản

phẩm thương mại sẽ tốn một khoản chi phí để có thể mua bản quyền và dùng được

toàn bộ chức năng của công cụ. Nhưng khi có đủ tài chính để mua sản phẩm sẽ phải bỏ

ra một lượng chi phí để thuê nghiên cứu triển khai và tích hợp trên dự án. Thật không

dễ dàng và cũng rất tốn kém để có một sản phẩm đạt chất lượng.

Qua nghiên cứu học viên thấy mỗi công cụ có một điểm mạnh riêng trong phát

hiện lỗi bảo mật của dự án. Nhưng chưa có công cụ nào là có thể tìm được tất cả các

lỗi mà các công cụ khác tìm được. Các lỗi tìm được nó là sự tổng hợp để có thể phát

hiện lỗi nhiều nhất. Vì thế không thể một công cụ sử dụng cho một dự án đòi hỏi mức

độ phát hiện lỗi cực cao nên cần phải đánh giá mức độ của dự án để có sự tổng hợp các

công cụ. Hay có thể nghiên cứu tạo ra một công cụ khác là sự tổng hợp của tất cả các

công cụ.

Từ kết quả nghiên cứu trong 7 công cụ khi đứng độc lập thì SonarQube luôn

khẳng định mình là một công cụ rất mạnh và đến khi tính toán tổ hợp giữa các công cụ

để hạn chế hết mức các lỗi có thể xảy ra thì SonarQube kết hợp với IntelliJ IDE cho

một kết quả tốt hơn so với sự tích hợp khác của các công cụ.

Qua nghiên cứu học viên tích lũy thêm cho một về kiến thức phân tích mã

nguồn dự án. Từ đó biết thế mạnh và điểm hạn chế của các công cụ để có thể áp dụng

vào dự án của bản thân hạn chế tối đa sự xâm nhập của các tin tặc hoặc những người

có ý đồ xấu. Thêm một cách để bảo vệ sản phẩm của mình.

51

Tài liệu tham khảo

Tiếng Anh

[1] "Architecture and Integration", available at:

https://docs.sonarqube.org/latest/architecture/architecture-integration/.

[2] Calcagno Cristiano, Dino Distefano, Peter O’Hearn, Hongseok Yang,

"Compositional Shape Analysis by means of Bi-Abduction", available at:

http://www0.cs.ucl.ac.uk/staff/p.ohearn/papers/popl09.pdf.

[3] Center for Assured Software National Secur Agency, "CAS 2012 Static Analysis

Tool Study Methodology", 9800 Savage Road on Fort George G. Meade, MD 20755-

6738, 2012.

[4] G. Diaz and J. R. Bermejo, "Static analysis of source code security: Assessment of

tools against SAMATE tests, Information and Software Technology", 2013, Vol. 55.

[5] "Plugin Library", available at: https://docs.sonarqube.org/display/PLUG.

[6] "PMD Documentation", available at: https://pmd.github.io/.

[7] "Separation logic and bi-abduction", available at:

https://fbinfer.com/docs/separation-logic-and-bi-abduction.

[8] "SpotBugs Documentation Release 4.2.0", available at:

https://readthedocs.org/projects/spotbugs/downloads/pdf/latest/.

[9] "Static Code Analysis", available at:

https://www.jetbrains.com/idea/docs/StaticCodeAnalysis.pdf (2000 – 2007).

[10] Tosin D aniel O ye toyan 1(B), Bisera Milosheska2, Mari Grini2, and Daniela

Soares Cruzes, "Myths and Facts About Static Application Security Testing Tools: An

Action Research at Telenor Digital", Department of Software Engineering, Safety and

Security, SINTEF Digital, Trondheim, Norway, in 17 May 2018.

[11] "VCG", available at: https://github.com/nccgroup/VCG.

[12] L. M. R. Velicheti [et al.], "Towards modeling the behavior of static code analysis

tools", in: Proceedings of the 9th Annual Cyber and Information Security Research

Conference, 2014.

nghiÊn cỨu tỔng hỢp cÁc cÔng cỤ phÁt hiỆn lỖi phẦn …

Documents