Luận văn 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

................................................................................ 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 VÀ TIẾN HÀNH 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Ả VÀ ĐÁ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 VÀ 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 ĐỀ TÀI VÀ 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 ... 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, CWE-478, CWE-480, CWE-481, CWE-482, CWE-484, CWE-486, CWE-561, CWE- 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 Quét trong tệp tin đầu vào hình 2.17 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 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-366, CWE-367, CWE-382, CWE-383, CWE-479, CWE-483, CWE-572, CWE- 606, CWE-609, CWE-666, CWE-667, CWE-674, CWE-698, CWE-764, CWE-765, CWE-832, CWE-833, CWE-835. Ví dụ: Hình 2.18: Ví dụ quản lý luồng kiểm soát Quét trong tệp tin đầu vào hình 2.18 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 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- 367, CWE-382, CWE-383, CWE-479, CWE-483, CWE-572, CWE-606, CWE-609, 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 Quét trong tệp tin đầu vào hình 2.20 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 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, 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ý 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 Quét trong tệp tin đầu vào hình 2.21 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 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 CWE396 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ý 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 Quét trong tệp tin đầu vào hình 2.22 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 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 CWE23 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. 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: CWE-209, CWE-226, CWE-244, CWE-499, CWE-526, CWE-533, CWE-534, CWE- 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 Quét trong tệp tin đầu vào hình 2.23 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 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 CWE534 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. 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- 404, CWE-415, CWE-416, CWE-457, CWE-459, CWE-568, CWE-580, CWE-586, CWE-590, CWE-665, CWE-672, CWE-761, CWE-762, CWE-772, CWE-773, CWE- 775, CWE-789. Ví dụ: Hình 2.24: Ví dụ khởi tạo và đóng tài nguyên 39 Quét trong tệp tin đầu vào hình 2.24 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 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 Quét trong tệp tin đầu vào hình 2.25 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 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 CWE89 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. 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 Quét trong tệp tin đầu vào hình 2.26 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 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, CWE-191, CWE-193, CWE-194, CWE-195, CWE-196, CWE-197, CWE-369, CWE- 681. Ví dụ: Hình 2.27: Ví dụ phần mềm độc hại 41 Quét trong tệp tin đầu vào hình 2.27 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 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ó chứa CWE190 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ý 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 Quét trong tệp tin đầu vào hình 2.29 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ụ 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ó chứa CWE476 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. 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Ả VÀ ĐÁ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): • Độ bao phủ: IntelliJ IDE cao nhất với 99% và thấp nhất là Infer, SpotBugs, 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): • Độ bao phủ: IntelliJ IDE cao nhất với 99% và thấp nhất là Infer, SpotBugs, 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): • Độ bao phủ: IntelliJ IDE cao nhất với 93% và thấp nhất là Infer, SpotBugs, 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): • Độ bao phủ: IntelliJ IDE cao nhất với 95% và thấp nhất là Infer, SpotBugs, 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): • Độ bao phủ: IntelliJ IDE cao nhất với 100% và thấp nhất là Infer, SpotBugs, 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 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 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 • Độ 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: 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. • Độ 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: HunBugs, SpotBugs, Infer. Mã hóa và tính ngẫu nhiên (Encryption and Randomness): • Độ 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 0% là tổ hợp của các công cụ sau: 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: 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. • Độ 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: HunBugs, SpotBugs, Infer. Xử lý lỗi (Error Handling): • Độ 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 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ủ 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ủ 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ủ 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ủ 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): • Độ 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ủ thấp nhất là 0% với tổ hợp công cụ sau: HuntBugs + SpotBugs + 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ủ 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ủ 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): • Độ 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. 48 • Độ bao phủ thấp nhất là 0% với tổ hợp công cụ sau: HuntBugs + SpotBugs + 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