Đề tài “Nghiên cứu sâu và trình bày về một kỹ thuật tấn công/phòng thủ hiện đại” nhằm mục tiêu giúp người học hiểu rõ cơ chế hoạt động, bản chất kỹ thuật của một phương pháp tấn công h
TỔNG QUAN VỀ LỖI VÀ LỖ HỔNG BẢO MẬT
Các khái niệm cơ bản
Trong lĩnh vực an ninh mạng, việc dùng đúng thuật ngữ đảm bảo mọi người—from nhà phát triển, kỹ sư bảo mật, nhà quản lý đến các bên liên quan—cùng có một sự hiểu biết chung về mức độ và bản chất của các nguy cơ Sự nhầm lẫn giữa các khái niệm này có thể dẫn đến đánh giá mức độ nghiêm trọng sai lệch, phân bổ nguồn lực không hợp lý và để lại những khoảng trống an ninh đáng ngại Phần này làm rõ năm khái niệm nền tảng: Bug, Vulnerability, Threat, Risk và Exploit, đồng thời chỉ ra cách chúng liên hệ với nhau trong chu trình quản trị an ninh mạng Bug là lỗi trong phần mềm hoặc hệ thống; Vulnerability là lỗ hổng bảo mật xuất hiện khi một yếu tố kỹ thuật hoặc cấu hình cho phép một kẻ xấu khai thác; Threat là mối đe dọa tiềm ẩn có thể tận dụng Vulnerability; Risk là mức độ có thể gây hại, kết hợp giữa Threat và Vulnerability; Exploit là hành động hoặc công cụ khai thác Vulnerability để đạt được lợi ích xấu Hiểu đúng năm khái niệm này giúp thiết kế chiến lược bảo mật hiệu quả, ưu tiên biện pháp giảm thiểu rủi ro và tăng khả năng phát hiện, ứng phó sự cố.
1.1.1 Phân biệt Bug, Vulnerability, Threat, Risk, Exploit
Hãy tưởng tượng hệ thống phần mềm của bạn như một ngôi nhà với kiến trúc được thiết kế để các thành phần hoạt động hài hòa, từ cơ sở dữ liệu đến giao diện người dùng và các dịch vụ phía máy chủ, để minh họa cách chúng tương tác và ảnh hưởng đến hiệu suất, độ ổn định cũng như trải nghiệm người dùng Phép ẩn dụ này giúp làm rõ các khái niệm về sự kết nối giữa các thành phần trong hệ thống và cách lỗi (bug) có thể phát sinh từ thiết kế, mã nguồn hoặc cấu hình, dẫn đến hoạt động không đúng hoặc bị gián đoạn Lỗi được hiểu như những chỗ yếu, vết nứt hoặc khe hở có thể gây rò rỉ và tác động xấu đến chất lượng sản phẩm, và gỡ lỗi (debug) là quá trình nhận diện, chẩn đoán và sửa chữa để vá các điểm yếu đó, tối ưu đường dây dữ liệu và nâng cao an toàn cho người dùng Khi bạn nhận diện và xử lý lỗi kịp thời, hệ thống phần mềm trở nên bền vững, dễ bảo trì và có hiệu suất cao hơn, đồng thời cải thiện trải nghiệm người dùng và tiềm năng tối ưu hóa SEO nhờ sự ổn định và đáng tin cậy của sản phẩm.
Định nghĩa: Lỗi (Bug) là một sai sót hoặc khiếm khuyết trong mã nguồn hoặc thiết kế của một chương trình máy tính, khiến phần mềm đưa ra kết quả không chính xác, không mong muốn hoặc hoạt động theo cách ngoài dự kiến Lỗi là thuật ngữ phổ biến trong ngành phát triển phần mềm và thường là nguyên nhân dẫn đến sự cố, gián đoạn chức năng và trải nghiệm người dùng bị ảnh hưởng.
Về bản chất, không phải mọi lỗi đều liên quan đến bảo mật thông tin; một số lỗi chỉ đơn giản gây phiền toái cho người dùng hoặc làm sai lệch chức năng, chứ không nhất thiết ảnh hưởng đến an toàn thông tin.
● Ví dụ trong đời thực:
○ Một nút bấm trên trang web không hoạt động khi được nhấp vào
○ Một ứng dụng tính toán cho ra kết quả sai (ví dụ: 2 + 2 = 5)
○ Giao diện người dùng bị hiển thị lệch lạc trên một số kích thước màn hình
Phép ẩn dụ ngôi nhà giúp hình dung các bug và lỗ hổng bảo mật như những khiếm khuyết của một căn nhà: một vết nứt trên tường có thể chỉ làm mất thẩm mỹ (lỗi giao diện) nhưng cũng có thể làm yếu kết cấu và đe dọa an toàn (lỗi nghiêm trọng hơn); một cánh cửa bị kẹt không đóng kín cho thấy lỗ hổng có thể bị khai thác để xâm nhập; một vòi nước rò rỉ nhắc nhở về lãng phí tài nguyên và nguy cơ phát sinh sự cố Các dấu hiệu này gợi ý sự cần thiết của việc nhận diện, đánh giá và khắc phục lỗ hổng bảo mật (vulnerability) để bảo vệ hệ thống và người dùng.
Lỗ hổng bảo mật (Vulnerability) là một loại lỗi (bug) hoặc một điểm yếu tồn tại trong thiết kế, triển khai, vận hành hoặc quản lý của một hệ thống, có thể bị khai thác để gây tổn hại đến Bí mật (Confidentiality), Toàn vẹn (Integrity) và Sẵn sàng (Availability) của hệ thống đó Đây là tập con của các lỗi có ảnh hưởng trực tiếp đến an ninh.
Trong bảo mật, mọi lỗ hổng bắt nguồn từ một lỗi, nhưng không phải mọi lỗi đều trở thành lỗ hổng có thể khai thác Điểm khác biệt mấu chốt là khả năng bị khai thác để thực hiện hành vi gây hại cho bảo mật hệ thống Do đó, quản lý lỗ hổng không chỉ là phát hiện lỗi mà còn phải đánh giá rủi ro dựa trên mức độ ảnh hưởng và khả năng khai thác, từ đó ưu tiên vá lỗi và tăng cường bảo mật cho tổ chức.
SQL Injection là lỗ hổng bảo mật xuất hiện khi dữ liệu đầu vào từ người dùng được xử lý mà không được làm sạch hoặc kiểm soát đúng cách, cho phép kẻ tấn công chèn và thực thi các lệnh SQL tùy ý trên cơ sở dữ liệu Lỗ hổng này có thể dẫn đến rò rỉ, sửa đổi hoặc phá hủy dữ liệu nhạy cảm và thậm chí chiếm quyền điều khiển hệ thống Để phòng chống SQL Injection, ứng dụng nên dùng tham số hóa truy vấn (prepared statements), kiểm tra và làm sạch dữ liệu đầu vào, áp dụng nguyên tắc cấp quyền tối thiểu và thường xuyên quét lỗ hổng bảo mật để cập nhật các biện pháp bảo vệ.
Cross-Site Scripting (XSS) là lỗ hổng bảo mật xuất phát từ việc không lọc sạch các đầu vào có chứa mã độc, cho phép kẻ tấn công chèn và thực thi mã script trên trang web Mã script độc hại được chạy trong trình duyệt của người dùng khác, từ đó có thể đánh cắp thông tin nhạy cảm, chiếm quyền quản lý phiên đăng nhập hoặc thực hiện các hành vi tấn công khác nhằm gây hại cho người dùng và hệ thống.
Những hệ thống thường được cài đặt với tài khoản quản trị và mật khẩu mặc định (ví dụ: admin/admin), và có thể không bắt buộc người dùng thay đổi khi lần đầu truy cập Việc duy trì mật khẩu mặc định tạo lỗ hổng bảo mật và có thể cho phép kẻ xấu truy cập trái phép vào quyền quản trị Để tăng cường an toàn cho hệ thống, thay đổi mật khẩu quản trị ngay khi có thể, sử dụng mật khẩu phức tạp, đổi mật khẩu định kỳ và kiểm soát quyền truy cập Các biện pháp này giúp giảm thiểu rủi ro từ mật khẩu mặc định và bảo vệ dữ liệu nhạy cảm.
Phép ẩn dụ ngôi nhà giúp hình dung lỗ hổng bảo mật như những khe hở có thể bị lợi dụng để xâm nhập Cánh cửa bị kẹt không phải là lỗ hổng nếu nó vẫn khóa được, nhưng nếu ổ khóa bị hỏng và có thể mở bằng bất kỳ chìa khóa nào, đó chính là một lỗ hổng Một cửa sổ ở tầng trệt không có chấn song cũng là một lỗ hổng tiềm ẩn cho kẻ xâm nhập Trong ngữ cảnh an ninh mạng, khái niệm mối đe dọa (Threat) mô tả các yếu tố có thể khai thác lỗ hổng để gây thiệt hại cho hệ thống.
Mối đe dọa (Threat) là bất kỳ tác nhân hoặc sự kiện tiềm tàng nào có khả năng gây hại cho một tài sản bằng cách khai thác một lỗ hổng Đây là khái niệm về cái gì hoặc ai có thể gây ra tấn công và cho thấy mối liên hệ giữa lỗ hổng và nguy cơ bảo mật đối với tài sản Hiểu rõ mối đe dọa giúp xác định biện pháp phòng ngừa và giảm thiểu rủi ro cho hệ thống, dữ liệu và hoạt động của tổ chức.
Bản chất của mối đe dọa là tồn tại độc lập với lỗ hổng bảo mật Điều này có nghĩa một mối đe dọa có thể tồn tại ngay cả khi hệ thống của bạn không có lỗ hổng nào Tuy nhiên, khi không có lỗ hổng thì mối đe dọa đó sẽ không thể gây hại.
● Phân loại: ○ Tác nhân con người (Human Threats):
■ Bên ngoài (External): Tin tặc (hacker), tội phạm mạng, các nhóm tấn công có chủ đích (APT)
■ Bên trong (Internal): Nhân viên bất mãn, nhân viên vô ý gây ra lỗi
○ Tự nhiên (Natural Threats): Lũ lụt, hỏa hoạn, động đất có thể phá hủy trung tâm dữ liệu
○ Môi trường (Environmental Threats): Mất điện, lỗi hệ thống điều hòa gây quá nhiệt
Phép ẩn dụ ngôi nhà ví mối đe dọa như những tên trộm đang lẩn khuất trong khu phố của bạn Sự tồn tại của chúng là một mối đe dọa, bất kể ngôi nhà của bạn có an toàn hay không, cho thấy rủi ro (risk) bạn phải đối mặt trong công tác bảo vệ và đảm bảo an ninh cho gia đình.
Rủi ro (Risk) là khả năng một mối đe dọa cụ thể sẽ khai thác một lỗ hổng cụ thể và gây ra tác động tiêu cực cho tổ chức Rủi ro là sự kết hợp giữa xác suất xảy ra và mức độ thiệt hại có thể phát sinh, thể hiện qua mức độ ảnh hưởng đến tài sản, dữ liệu và hoạt động kinh doanh Hiểu và đo lường rủi ro giúp doanh nghiệp nhận diện lỗ hổng, đánh giá mức độ nguy hiểm và ưu tiên các biện pháp kiểm soát nhằm giảm thiểu thiệt hại và bảo vệ mục tiêu kinh doanh.
● Công thức cơ bản: Risk = Threat x Vulnerability x Impact
○ Threat: Có tác nhân đe dọa nào đang nhắm đến lỗ hổng này không?
○ Vulnerability: Lỗ hổng có tồn tại và dễ khai thác không?
○ Impact: Nếu bị khai thác, thiệt hại về tài chính, danh tiếng, dữ liệu sẽ lớn đến mức nào?
Phân loại Lỗ hổng Bảo mật
Hiểu rõ nguồn gốc của lỗ hổng bảo mật giúp chúng ta không chỉ sửa chữa các vấn đề hiện tại mà còn ngăn chặn chúng tái diễn trong tương lai Các lỗ hổng có thể được phân loại theo nhiều cách, nhưng một trong những cách phổ biến và hữu ích nhất là dựa trên nguồn gốc của chúng: lỗi cấu hình, lỗi lập trình và lỗi thiết kế Việc nhận diện đúng nguồn gốc lỗ hổng cho phép áp dụng biện pháp khắc phục phù hợp, từ tối ưu hóa cấu hình hệ thống và rà soát mã nguồn đến cải tiến thiết kế và quy trình kiểm thử an toàn, từ đó nâng cao mức độ an toàn thông tin và giảm thiểu rủi ro bảo mật.
1.2.1 Lỗi cấu hình (Misconfiguration) Đây là một trong những loại lỗ hổng phổ biến và dễ phòng tránh nhất, nhưng lại thường xuyên xảy ra Lỗi cấu hình không bắt nguồn từ mã nguồn của ứng dụng, mà từ cách hệ thống, dịch vụ hoặc phần mềm được thiết lập và triển khai
○ Thường do con người gây ra trong quá trình cài đặt hoặc bảo trì
○ Có thể được phát hiện và khắc phục mà không cần thay đổi mã nguồn
○ Mật khẩu mặc định hoặc yếu: Để lại mật khẩu mặc định của nhà sản xuất trên các thiết bị (router, camera) hoặc cơ sở dữ liệu (root/password)
○ Dịch vụ không cần thiết được bật: Chạy các dịch vụ mạng không sử dụng đến (ví dụ: Telnet, FTP) làm tăng bề mặt tấn công
Quyền truy cập không hợp lý xảy ra khi cấp phát quyền ghi/đọc/thực thi quá mức cần thiết cho các tệp và thư mục Việc này có thể cho phép người dùng không liên quan xem và thao tác các tệp nhạy cảm, gây rò rỉ dữ liệu hoặc làm hỏng hệ thống Ví dụ, một thư mục lưu tệp cấu hình nhạy cảm được cấp quyền đọc cho mọi người (như chmod 777) sẽ dễ bị khai thác Để giảm thiểu rủi ro, hãy áp dụng nguyên tắc tối thiểu quyền truy cập, chỉ cấp quyền cần thiết cho từng người hoặc nhóm, và thường xuyên rà soát và điều chỉnh các quyền để bảo vệ an toàn dữ liệu và hạ tầng.
Vấn đề Cloud Storage bị lộ xuất phát từ cấu hình sai các dịch vụ lưu trữ đám mây như Amazon S3 bucket và Azure Blob Storage, gây ra khả năng truy cập công khai dữ liệu nhạy cảm Khi các bucket S3 hoặc container Azure Blob được để ở chế độ công khai hoặc thiếu kiểm soát truy cập, dữ liệu quan trọng có thể bị lộ dù không có sự xâm nhập từ bên ngoài Điều này làm tăng rủi ro rò rỉ dữ liệu, vi phạm quyền riêng tư và thiệt hại hình ảnh cho tổ chức Để khắc phục, cần rà soát và sửa các cấu hình lưu trữ đám mây, áp dụng nguyên tắc tối thiểu về quyền truy cập, bật mã hóa dữ liệu, cấp phát quyền bằng IAM và bảo mật bucket, đồng thời kích hoạt cảnh báo và ghi nhật ký truy cập để phát hiện sớm các lần truy cập trái phép.
Hiển thị thông báo lỗi chi tiết trong cấu hình máy chủ web có thể tiết lộ thông tin nhạy cảm về cấu trúc bên trong hệ thống, phiên bản phần mềm và đường dẫn tệp cho người dùng cuối; đây là rủi ro bảo mật lớn, nên vô hiệu hóa hoặc ẩn các thông báo lỗi gỡ rối ở môi trường sản xuất, thay vào đó chỉ hiển thị thông báo lỗi chung và ghi log chi tiết cho quản trị viên, đồng thời kiểm tra, cập nhật phần mềm định kỳ và áp dụng các biện pháp bảo mật để giảm thiểu nguy cơ bị khai thác.
1.2.2 Lỗi lập trình (Implementation Bugs) Đây là loại lỗ hổng "kinh điển" mà mọi người thường nghĩ đến, xuất phát trực tiếp từ những sai sót trong quá trình viết mã
○ Nằm trong mã nguồn của ứng dụng
○ Yêu cầu sửa đổi mã nguồn và triển khai lại phiên bản mới để khắc phục
○ Injection Flaws (Lỗi chèn mã):
SQL Injection là lỗ hổng bảo mật phát sinh khi dữ liệu đầu vào từ người dùng không được xác thực và làm sạch trước khi được nhúng vào câu lệnh SQL, cho phép kẻ tấn công thao túng cơ sở dữ liệu, xem trộm, sửa đổi hoặc chiếm quyền kiểm soát dữ liệu nhạy cảm Để giảm thiểu rủi ro, ứng dụng nên sử dụng câu lệnh tham số hóa (prepared statements) và gán tham số cho truy vấn, thực hiện xác thực và làm sạch dữ liệu ở mọi điểm tiếp xúc với người dùng, áp dụng nguyên tắc tối thiểu quyền truy cập và theo dõi đăng nhập để phát hiện hành vi bất thường.
■ Command Injection: Tương tự nhưng cho phép thực thi lệnh hệ điều hành
Cross-Site Scripting (XSS) là lỗ hổng bảo mật xuất hiện khi dữ liệu người dùng được hiển thị trên trang web mà không được mã hóa đúng cách trước khi hiển thị, tạo điều kiện cho kẻ tấn công chèn mã JavaScript độc hại Khi dữ liệu đầu vào chưa được xử lý an toàn, người dùng có thể bị đánh cắp thông tin, bị thay đổi nội dung trang hoặc thực thi hành vi trái ý muốn Để bảo vệ, cần mã hóa hoặc khử đặc biệt dữ liệu ở đầu ra, lọc và xác thực đầu vào, và áp dụng các biện pháp phòng chống XSS trên toàn bộ ứng dụng web nhằm tăng cường an toàn cho người dùng và hệ thống.
Buffer overflow xảy ra khi một lập trình viên không kiểm tra kích thước dữ liệu đầu vào trước khi sao chép vào một bộ đệm có kích thước cố định Hành động này khiến dữ liệu tràn ra ngoài, ghi đè lên các vùng nhớ liền kề và có thể dẫn đến thực thi mã tùy ý Đây là lỗi bảo mật nghiêm trọng trong phát triển phần mềm, và cần được ngăn ngừa bằng cách kiểm tra kích thước dữ liệu, dùng các hàm an toàn hơn và áp dụng các biện pháp quản lý bộ nhớ phù hợp.
Insecure Deserialization là lỗ hổng bảo mật xuất hiện khi dữ liệu được tuần tự hóa (serialized) từ các nguồn không đáng tin cậy sau đó được giải tuần tự hóa (deserialized) mà không có kiểm tra hay xác thực Quá trình giải tuần tự hóa thiếu kiểm soát có thể cho phép kẻ tấn công thực hiện các cuộc tấn công từ xa, thao tác trạng thái ứng dụng và thậm chí thực thi mã độc Để giảm thiểu rủi ro, cần xác thực nguồn dữ liệu nhập, hạn chế loại dữ liệu được giải deserialized, áp dụng kiểm tra và giám sát quá trình giải tuần tự hóa, đồng thời tăng cường bảo mật ở các phần mềm liên quan.
1.2.3 Lỗi thiết kế (Design Flaws) Đây là loại lỗ hổng nguy hiểm và khó khắc phục nhất Chúng không phải là lỗi trong một dòng mã cụ thể, mà là một khiếm khuyết trong chính logic, kiến trúc hoặc quy trình nghiệp vụ của hệ thống
○ Tồn tại ở cấp độ kiến trúc hệ thống
○ Việc vá lỗi thường rất tốn kém, đòi hỏi phải thiết kế lại một phần hoặc toàn bộ chức năng
○ Các công cụ quét tự động thường khó phát hiện ra loại lỗi này
○ Cơ chế xác thực không an toàn:
■ Quy trình "Quên mật khẩu" chỉ dựa vào thông tin dễ đoán như ngày sinh hoặc quê quán
■ Không có cơ chế chống đoán mật khẩu (rate limiting), cho phép kẻ tấn công thực hiện tấn công Brute-force không giới hạn
Kiểm soát truy cập bị lỗi (Broken Access Control) xảy ra khi hệ thống chỉ kiểm tra quyền truy cập ở phía giao diện người dùng (ví dụ ẩn nút quản trị) mà không xác thực lại ở phía máy chủ (server-side); do đó kẻ tấn công có thể bỏ qua giao diện và gửi trực tiếp yêu cầu tới API của máy chủ để truy cập các chức năng nhạy cảm, dẫn đến lỗ hổng bảo mật nghiêm trọng và có thể bị khai thác để thực hiện hành động vượt quyền.
Thiếu sót trong việc ghi nhật ký (logging) là lỗ hổng nghiêm trọng trong an ninh hệ thống vì hệ thống không ghi lại các sự kiện quan trọng như đăng nhập thất bại, thay đổi quyền truy cập và các hoạt động trên tài khoản người dùng Việc thiếu dữ liệu ghi nhận này khiến quá trình điều tra sự cố và phân tích chứng cứ số (forensics) sau một cuộc tấn công trở nên bất khả thi hoặc cực kỳ khó khăn, làm giảm khả năng xác định nguồn tấn công, phạm vi ảnh hưởng và thiệt hại thực tế Để bảo vệ an toàn thông tin và cải thiện khả năng ứng phó sự cố, cần triển khai ghi nhật ký đầy đủ và nhất quán, với định dạng chuẩn, thời gian đồng bộ, lưu trữ an toàn và quản lý quyền truy cập nghiêm ngặt, đồng thời thiết lập cảnh báo sớm và kiểm tra định kỳ các sự kiện nhạy cảm như đăng nhập thất bại và thay đổi quyền nhằm tối ưu hóa khả năng phục hồi và phân tích sau sự cố.
Việc sử dụng các thuật toán mã hóa yếu hoặc tự chế có thể làm suy yếu bảo mật hệ thống Thay vì chọn các thuật toán mã hóa mạnh và được kiểm chứng như AES hoặc RSA, một số nhà thiết kế tự sáng tạo ra thuật toán riêng và áp dụng nguyên tắc "security through obscurity" — một phương pháp vốn dễ bị bẻ gãy bởi các cuộc tấn công hiện đại Vì vậy, để đảm bảo an toàn cho dữ liệu và ứng dụng, nên ưu tiên các chuẩn mã hóa công khai, được kiểm chứng và có sự kiểm tra từ cộng đồng bảo mật.
1.2.4 Giới thiệu các danh mục lỗ hổng phổ biến Để giúp các tổ chức và nhà phát triển tập trung vào những vấn đề an ninh nghiêm trọng nhất, cộng đồng bảo mật đã tạo ra các danh sách và danh mục tiêu chuẩn a OWASP Top 10
● OWASP (Open Web Application Security Project) là một tổ chức phi lợi nhuận toàn cầu chuyên về cải thiện an ninh phần mềm
Hệ thống định danh và chấm điểm
Trong bối cảnh hàng ngàn lỗ hổng mới được phát hiện mỗi năm, việc có một hệ thống chuẩn hóa để định danh và đánh giá chúng là vô cùng cần thiết CVE và CVSS đóng vai trò hai trụ cột chính của hệ thống này, giúp nhận diện lỗ hổng một cách nhất quán và đánh giá mức độ nghiêm trọng dựa trên tiêu chí chuẩn Nhờ chuẩn hóa và phân loại này, các tổ chức có thể theo dõi, so sánh và ưu tiên khắc phục lỗ hổng bảo mật một cách hiệu quả, từ đó nâng cao khả năng bảo vệ hệ thống và giảm thiểu rủi ro cho môi trường CNTT.
1.3.1 CVE (Common Vulnerabilities and Exposures)
CVE là một hệ thống cung cấp mã định danh duy nhất cho mỗi lỗ hổng bảo mật được công bố công khai Hệ thống này được duy trì bởi MITRE Corporation với sự tài trợ của Chính phủ Hoa Kỳ.
Mục đích là tạo ra một tham chiếu chung duy nhất cho một lỗ hổng cụ thể, giúp các công cụ, cơ sở dữ liệu và chuyên gia bảo mật trên toàn thế giới có thể “nói chuyện” với nhau một cách chính xác Khi công cụ A và công cụ B cùng báo cáo về CVE-2023-12345, mọi người đều hiểu rằng họ đang nói về cùng một vấn đề.
● Cấu trúc: Mã CVE có định dạng CVE-YYYY-NNNN , trong đó:
○ CVE: Tiền tố cố định ○ YYYY: Năm lỗ hổng được công bố hoặc được gán mã
○ NNNN : Một số thứ tự có ít nhất 4 chữ số
● Ví dụ: CVE-2014-0160, còn được biết đến với tên gọi Heartbleed, là một lỗ hổng nghiêm trọng trong thư viện mã hóa OpenSSL
1.3.2 CVSS (Common Vulnerability Scoring System)
CVSS là một chuẩn mở và miễn phí trong ngành để đánh giá mức độ nghiêm trọng của lỗ hổng bảo mật, được ứng dụng rộng rãi để xác định mức độ nguy hiểm và ưu tiên các nỗ lực khắc phục một cách khách quan Chuẩn này cung cấp phương pháp tính điểm từ 0 đến 10, giúp các tổ chức đánh giá mức độ nghiêm trọng của lỗ hổng và điều phối các nguồn lực bảo mật một cách hiệu quả.
○ Cung cấp một điểm số thống nhất, không phụ thuộc vào nhà cung cấp hay sản phẩm
○ Giúp người quản trị hệ thống và đội ngũ an ninh nhanh chóng hiểu được mức độ nghiêm trọng của một lỗ hổng
● CVSS bao gồm ba nhóm chỉ số (Metric Groups): Base, Temporal, và Environmental
Base Score Metrics (Nhóm chỉ số cơ bản) là nhóm chỉ số quan trọng và được sử dụng rộng rãi nhất khi đánh giá lỗ hổng Nó tập trung vào các đặc tính vốn có và không đổi của một lỗ hổng, giúp xác định mức độ nghiêm trọng ngay từ ban đầu Các chỉ số trong nhóm này đo lường mức độ dễ khai thác, mức độ ảnh hưởng đối với hệ thống và người dùng, cũng như tính ổn định của các đặc tính này theo thời gian Nhờ Base Score Metrics, các tổ chức có căn cứ để đánh giá rủi ro và ưu tiên xử lý, từ đó lên kế hoạch phòng ngừa và ứng phó hiệu quả.
● Attack Vector (AV) - Vector tấn công: Kẻ tấn công cần ở vị trí nào để khai thác lỗ hổng?
○ Network (N): Có thể tấn công từ xa qua mạng (Internet) Đây là trường hợp nguy hiểm nhất
○ Adjacent (A): Kẻ tấn công phải ở trong cùng một mạng vật lý hoặc logic (ví dụ: cùng mạng LAN, cùng dải Bluetooth)
○ Local (L): Kẻ tấn công phải có quyền truy cập cục bộ vào hệ thống (ví dụ: qua bàn phím, hoặc đã có một phiên shell)
○ Physical (P): Kẻ tấn công phải có quyền truy cập vật lý vào thiết bị
- Độ phức tạp tấn công: Việc khai thác lỗ hổng có đòi hỏi những điều kiện phức tạp, nằm ngoài tầm kiểm soát của kẻ tấn công không?
○ Low (L): Không có điều kiện đặc biệt nào Kẻ tấn công có thể khai thác thành công mỗi khi thử
Mức độ High (H) mô tả các yêu cầu liên quan đến điều kiện đặc biệt, ví dụ như phải vượt qua một cuộc đua điều kiện (race condition) hoặc phải lừa người dùng thực hiện một chuỗi hành động phức tạp.
● Privileges Required (PR) - Đặc quyền yêu cầu: Kẻ tấn công cần có mức đặc quyền nào trước khi thực hiện tấn công?
○ None (N): Không cần bất kỳ đặc quyền nào Bất kỳ ai cũng có thể tấn công
○ Low (L): Cần có đặc quyền của một người dùng thông thường
○ High (H): Cần có đặc quyền của quản trị viên
● User Interaction (UI) - Tương tác người dùng: Cuộc tấn công có yêu cầu một người dùng (ngoài kẻ tấn công) tham gia không?
○ Required (R): Cần người dùng thực hiện một hành động, ví dụ như nhấp vào một liên kết độc hại, mở một tệp tin lạ
Scope (S) - Phạm vi ảnh hưởng đánh giá liệu việc khai thác lỗ hổng trong một thành phần phần mềm (component A) có thể ảnh hưởng đến các tài nguyên của một thành phần khác (component B) hay không Khả năng này phụ thuộc vào mức độ phụ thuộc giữa các thành phần và cách chúng tương tác, cũng như quyền truy cập và quản lý tài nguyên được cấp cho từng component Khi lỗ hổng ở component A cho phép truy cập, đọc hoặc chiếm dụng tài nguyên của component B, nguy cơ lây lan và ảnh hưởng đến bảo mật toàn hệ thống tăng lên Việc mô tả phạm vi ảnh hưởng giúp xác định biện pháp cô lập, kiểm soát truy cập và thiết kế biện pháp khôi phục sau sự cố, đồng thời tối ưu hóa an ninh cho cả hai component và hệ thống nói chung.
○ Unchanged (U): Chỉ ảnh hưởng trong phạm vi của chính thành phần bị tấn công
Changed (C) có thể dẫn đến ảnh hưởng ra ngoài phạm vi sandbox, ví dụ như một lỗ hổng trong sandbox của trình duyệt cho phép thực thi mã trên hệ điều hành Trường hợp này thường nguy hiểm hơn bởi kẻ tấn công có thể vượt qua lớp cô lập của trình duyệt và kiểm soát hệ thống người dùng, gây thiệt hại nghiêm trọng cho dữ liệu và hoạt động Vì vậy, vá lỗi kịp thời, tăng cường kiểm tra bảo mật và quản lý rủi ro là cần thiết để ngăn ngừa các cuộc tấn công khai thác lỗ hổng này.
● Impact Metrics (Nhóm chỉ số tác động): Đánh giá tác động đến bộ ba CIA ○ Confidentiality (C)
■ Mỗi chỉ số này có ba mức: High (H) - mất hoàn toàn, Low (L) - mất một phần, None (N) - không ảnh hưởng b Temporal Score Metrics (Nhóm chỉ số thời gian)
Nhóm này điều chỉnh điểm Base Score dựa trên các yếu tố thay đổi theo thời gian, như sự tồn tại của mã khai thác
● Exploit Code Maturity (E): Mức độ trưởng thành của mã khai thác
● Remediation Level (RL): Sự sẵn có của bản vá hoặc giải pháp khắc phục
● Report Confidence (RC): Mức độ tin cậy của báo cáo về lỗ hổng c Environmental Score Metrics (Nhóm chỉ số môi trường)
Nhóm này cho phép tổ chức tùy chỉnh điểm số dựa trên môi trường cụ thể của họ
● Modified Base Metrics: Điều chỉnh các chỉ số Base dựa trên các biện pháp kiểm soát an ninh hiện có
Security Requirements (CR, IR, AR) xác định mức độ quan trọng của tính bí mật, toàn vẹn và sẵn sàng đối với các tài sản bị ảnh hưởng trong môi trường của tổ chức Các yêu cầu CR (Confidentiality), IR (Integrity) và AR (Availability) giúp phân tích rủi ro và xác định biện pháp kiểm soát phù hợp như mã hóa, quản lý truy cập và sao lưu, đồng thời ưu tiên nguồn lực cho an toàn thông tin dựa trên mức độ nhạy cảm của tài sản Cách tính điểm và ý nghĩa của hệ thống này cho thấy mức độ ảnh hưởng và mức độ rủi ro tương ứng với từng tài sản, hỗ trợ quản trị viên đưa ra quyết định về thiết kế hệ thống, triển khai kiểm soát và đánh giá hiệu quả bảo mật trong tổ chức.
Điểm CVSS được tính toán bằng một công thức phức tạp dựa trên giá trị của các chỉ số trong hệ thống CVSS, nhằm phản ánh mức độ nguy hiểm của lỗ hổng bảo mật Quá trình này dựa trên nhiều thước đo như tác động và khả năng khai thác, được kết hợp để cho ra một điểm số duy nhất và so sánh được giữa các lỗ hổng Các tổ chức thường sử dụng máy tính trực tuyến của NVD (National Vulnerability Database) để tính toán điểm CVSS một cách nhanh chóng và chuẩn xác, hỗ trợ đánh giá mức độ ưu tiên vá lỗi và lập kế hoạch ứng phó an ninh thông minh.
○ 9.0 - 10.0: Critical (Cực kỳ nghiêm trọng)
Ví dụ: một lỗ hổng bảo mật cho phép tấn công từ xa (AV:N), không cần đặc quyền (PR:N) và không yêu cầu tương tác của người dùng (UI:N) có thể gây mất hoàn toàn tính bí mật, tính toàn vẹn và tính sẵn sàng (C:H, I:H, A:H) Khi được đánh giá, lỗ hổng này thường nhận điểm Base Score rất cao, thường là 10.0, và được xem là cực kỳ nghiêm trọng trong bảng đánh giá an ninh.
Các phương pháp tiếp cận
Để tìm ra lỗ hổng, các chuyên gia bảo mật sử dụng nhiều phương pháp và kỹ thuật khác nhau, được phân loại dựa trên mức độ thông tin cung cấp cho người kiểm thử (White Box, Black Box, Grey Box) hoặc theo cách thức phân tích hệ thống (tĩnh/động) Trong mục 1.4.1, White Box, Black Box, Grey Box được định nghĩa: người kiểm thử có toàn quyền truy cập vào mọi thông tin về hệ thống, bao gồm mã nguồn, tài liệu thiết kế, sơ đồ kiến trúc và cấu hình chi tiết.
● Phép ẩn dụ: Giống như một kỹ sư của nhà sản xuất đang kiểm tra sản phẩm với đầy đủ bản vẽ kỹ thuật
○ Độ bao phủ cao: Có thể kiểm tra mọi đường đi của mã nguồn, mọi logic nghiệp vụ
○ Hiệu quả: Dễ dàng xác định chính xác vị trí của lỗ hổng trong mã nguồn
○ Phát hiện sớm: Có thể thực hiện ngay từ giai đoạn phát triển
○ Tốn thời gian và chi phí: Đòi hỏi người kiểm thử có kỹ năng lập trình và phân tích mã nguồn cao
○ Yêu cầu truy cập sâu: Cần sự hợp tác chặt chẽ từ đội ngũ phát triển
○ Có thể bỏ qua các lỗ hổng ở cấp độ triển khai: Vì quá tập trung vào mã nguồn, có thể không thấy được các lỗi cấu hình khi triển khai thực tế b Black Box Testing (Kiểm thử hộp đen)
16 Định nghĩa: Người kiểm thử không có bất kỳ thông tin nào về cấu trúc bên trong của hệ thống Họ tương tác với ứng dụng giống như một người dùng cuối hoặc một kẻ tấn công từ bên ngoài
● Phép ẩn dụ: Giống như một kẻ trộm đang cố gắng đột nhập vào một ngôi nhà mà không hề biết sơ đồ bên trong
○ Mô phỏng thực tế: Tái tạo chính xác cách một kẻ tấn công bên ngoài sẽ tiếp cận hệ thống
○ Nhanh chóng: Có thể bắt đầu kiểm thử mà không cần chuẩn bị nhiều về mặt thông tin
○ Không thiên vị: Người kiểm thử không bị ảnh hưởng bởi những giả định của nhà phát triển
Độ bao phủ kiểm thử thấp khiến việc đảm bảo mọi chức năng và đường đi trong mã nguồn đã được kiểm tra trở nên rất khó khăn, dẫn tới nguy cơ bỏ sót nhiều lỗ hổng Khi kiểm thử không toàn diện, các lỗ hổng bảo mật có thể không bị phát hiện kịp thời, ảnh hưởng đến chất lượng, an toàn và sự tin tưởng vào phần mềm.
○ Khó xác định nguyên nhân gốc rễ: Khi tìm thấy một lỗ hổng, việc xác định chính xác đoạn mã gây ra nó có thể rất khó khăn
Trong kiểm thử bảo mật, False Positives (dương tính giả) là hiện tượng các công cụ quét hộp đen tự động báo cáo các lỗ hổng không thực sự tồn tại Grey Box Testing (Kiểm thử hộp xám) là sự kết hợp giữa White Box và Black Box, giúp kết hợp ưu điểm của cả hai phương pháp Người kiểm thử có một lượng thông tin hạn chế, ví dụ như tài khoản người dùng, một số tài liệu về API, hoặc sơ đồ kiến trúc ở mức cao.
Phép ẩn dụ này so sánh vai trò của người đánh giá bên ngoài với một "khách hàng bí mật" được phép vào bên trong cửa hàng để đánh giá toàn diện trải nghiệm mua sắm Người quan sát có những hiểu biết nhất định về quy trình phục vụ, bố trí cửa hàng và thái độ của nhân viên, nhưng không phải là nhân viên và không tham gia vào hoạt động vận hành hàng ngày Nhờ đó họ có thể nhận diện những điểm mạnh và điểm yếu mà nhân viên có thể bỏ qua, từ đó đưa ra đề xuất cải thiện như tối ưu hóa quy trình thanh toán, nâng cao chất lượng giao tiếp với khách hàng và sắp xếp mặt bằng hợp lý để tăng sự hài lòng của khách hàng Đây là cách diễn giải giúp hình dung tầm quan trọng của cái nhìn khách quan trong đánh giá dịch vụ và cải thiện hiệu quả kinh doanh.
○ Cân bằng: Cung cấp độ bao phủ tốt hơn Black Box nhưng không tốn nhiều thời gian như White Box
○ Hiệu quả: Tập trung vào các khu vực có rủi ro cao nhất dựa trên thông tin được cung cấp
○ Mô phỏng tấn công từ nội bộ: Rất hữu ích trong việc mô phỏng một kẻ tấn công đã có được một số quyền truy cập ban đầu
○ Không có được độ bao phủ toàn diện như White Box
○ Lượng thông tin hạn chế có thể không đủ để tìm ra các lỗ hổng phức tạp
1.4.2 Phân tích tĩnh (Static) và Phân tích động (Dynamic) Đây là hai kỹ thuật chính được sử dụng để phân tích một ứng dụng nhằm tìm kiếm lỗ hổng a Phân tích Tĩnh (Static Analysis)
● Định nghĩa: Là quá trình phân tích mã nguồn, mã bytecode hoặc mã nhị phân của một ứng dụng mà không cần phải thực thi nó
● Tên gọi khác: SAST (Static Application Security Testing)
Các công cụ SAST hoạt động như một trình kiểm tra ngữ pháp nâng cao cho mã nguồn, phân tích mã dựa trên tập hợp các quy tắc nhằm phát hiện các mẫu mã có nguy cơ gây lỗ hổng bảo mật Quá trình này giúp nhận diện những hành vi tiềm ẩn rủi ro như sử dụng hàm không an toàn hoặc thiếu kiểm tra và xác thực đầu vào, từ đó tối ưu hóa an ninh ứng dụng ngay từ giai đoạn viết mã.
○ Phát hiện sớm: Có thể tích hợp vào quy trình CI/CD và phát hiện lỗi ngay khi lập trình viên viết mã
○ Độ bao phủ 100%: Phân tích toàn bộ mã nguồn, bao gồm cả những phần ít được sử dụng
○ Chỉ ra vị trí chính xác: Báo cáo lỗi kèm theo tên tệp và số dòng, giúp lập trình viên sửa lỗi nhanh chóng
○ Tỷ lệ dương tính giả cao: Có thể báo cáo nhiều vấn đề không thực sự là lỗ hổng trong ngữ cảnh thực thi
Không hiểu ngữ cảnh thực thi khiến chúng ta không thể phát hiện các lỗi chỉ xuất hiện khi ứng dụng đang chạy, như lỗi logic xác thực hoặc lỗi cấu hình môi trường Phân tích Động (Dynamic Analysis) là phương pháp kiểm thử chạy trực tiếp ứng dụng trong môi trường thực tế để nhận diện các lỗi vận hành và đánh giá hành vi của hệ thống, từ đó phát hiện các vấn đề mà phân tích tĩnh có thể bỏ sót.
● Định nghĩa: Là quá trình kiểm thử ứng dụng khi nó đang ở trạng thái chạy
● Tên gọi khác: DAST (Dynamic Application Security Testing)
DAST (Dynamic Application Security Testing) là phương pháp kiểm thử bảo mật ứng dụng web hoạt động từ bên ngoài như kiểm thử hộp đen Các công cụ DAST gửi các payload độc hại và phân tích các phản hồi từ ứng dụng để xác định liệu ứng dụng có dễ bị tấn công hay không, từ đó giúp phát hiện lỗ hổng bảo mật và điểm yếu trong ứng dụng.
○ Tỷ lệ dương tính giả thấp: Khi DAST báo cáo một lỗ hổng, nó thường là một vấn đề thực sự có thể khai thác được
Phát hiện lỗi thời gian chạy là bước quan trọng trong bảo mật ứng dụng, giúp tìm các vấn đề mà SAST có thể bỏ qua như lỗi cấu hình máy chủ và lỗi logic Nó cũng phát hiện các lỗ hổng chỉ xuất hiện khi các thành phần hệ thống tương tác với nhau, cho phép khắc phục sớm trước khi khai thác Việc kết hợp kiểm tra thời gian chạy với các phương pháp bảo mật khác tăng cường khả năng phát hiện rủi ro và giảm thiểu tác động của sự cố vận hành.
○ Không phụ thuộc ngôn ngữ: Có thể kiểm tra bất kỳ ứng dụng nào, bất kể nó được viết bằng ngôn ngữ gì
Độ bao phủ kiểm thử thấp có nghĩa là chỉ những phần của ứng dụng mà hệ thống có thể nhận diện và tương tác được mới được kiểm tra; các chức năng không tiếp cận được sẽ bị bỏ qua và không có cơ hội được rà soát Nếu một chức năng không thể truy cập, nó sẽ không được kiểm tra, làm tăng nguy cơ bỏ sót lỗi ở các khu vực kém hiển thị hoặc thiếu đường dẫn người dùng Để cải thiện chất lượng và độ tin cậy của sản phẩm, cần mở rộng phạm vi kiểm thử và tăng khả năng nhận diện cũng như tương tác của hệ thống với toàn bộ chức năng của ứng dụng.
○ Không chỉ ra vị trí lỗi: Chỉ báo cáo "có lỗ hổng SQL Injection tại URL này", chứ không chỉ ra dòng mã cụ thể gây ra lỗi
○ Phát hiện muộn: Chỉ có thể thực hiện khi ứng dụng đã được xây dựng và triển khai trong môi trường kiểm thử
1.4.3 Phát hiện dựa trên chữ ký (Signature-based) và dựa trên bất thường (Anomaly- based) Đây là hai phương pháp cốt lõi được sử dụng bởi các Hệ thống Phát hiện và Ngăn chặn Xâm nhập (IDS/IPS), tường lửa và phần mềm chống virus a Phát hiện dựa trên chữ ký (Signature-based Detection)
Định nghĩa: Phương pháp này xác định các mối đe dọa bằng cách tìm kiếm các mẫu hoặc chữ ký cụ thể đã biết trong lưu lượng mạng và trong các tệp tin Đây là một kỹ thuật nhận diện mối đe dọa dựa trên chữ ký, cho phép phát hiện nhanh các biến thể của tấn công dựa trên cơ sở dữ liệu chữ ký được cập nhật thường xuyên Tuy vậy, hiệu quả của phương pháp phụ thuộc vào mức độ cập nhật của chữ ký và có thể bị hạn chế trước các mối đe dọa mới hoặc các biến thể chưa có chữ ký.
Hoạt động như một phần mềm chống virus truyền thống, hệ thống này duy trì một cơ sở dữ liệu chữ ký của phần mềm độc hại, mã khai thác và các hành vi tấn công được biết đến Dữ liệu đi qua hệ thống sẽ được so sánh với cơ sở dữ liệu chữ ký này, và khi có sự trùng khớp, một cảnh báo an ninh sẽ được phát ra nhằm ngăn chặn mối đe dọa kịp thời.
○ Chính xác và nhanh: Rất hiệu quả trong việc phát hiện các mối đe dọa đã biết
○ Ít dương tính giả: Vì nó tìm kiếm các mẫu rất cụ thể, nó hiếm khi báo động nhầm
Kết luận chương 1
Chương 1 đã trình bày những nội dung nền tảng giúp hiểu rõ bản chất của lỗi và lỗ hổng bảo mật trong hệ thống thông tin Trước hết, chương đã làm rõ các khái niệm cơ bản như lỗi (error), điểm yếu (weakness) và lỗ hổng bảo mật (vulnerability), qua đó nhấn mạnh mối liên hệ giữa chúng trong quá trình hình thành nguy cơ tấn công mạng Tiếp theo, việc phân loại lỗ hổng bảo mật theo các tiêu chí khác nhau — như nguồn gốc, phạm vi ảnh hưởng, hoặc mức độ nghiêm trọng — giúp định hướng phương pháp phòng ngừa và khắc phục phù hợp
Chương trình đã giới thiệu hệ thống định danh và chấm điểm lỗ hổng phổ biến như CVE (Common Vulnerabilities and Exposures), CVSS (Common Vulnerability Scoring System) và NVD (National Vulnerability Database), đóng vai trò chuẩn hóa trong việc đánh giá, so sánh và quản lý rủi ro bảo mật Các phương pháp tiếp cận trong phát hiện và xử lý lỗ hổng—bao gồm kiểm thử xâm nhập (Penetration Testing), quét lỗ hổng (Vulnerability Scanning) và phân tích mã nguồn—được xem là những hướng đi chủ chốt để tăng cường an toàn thông tin và quản trị an ninh mạng hiệu quả.
Chương 1 thiết lập nền tảng lý thuyết vững chắc cho quá trình nghiên cứu, nhận diện và ứng phó với lỗ hổng bảo mật trong các chương tiếp theo, đồng thời giúp người đọc hình thành tư duy hệ thống về mối quan hệ giữa con người, công nghệ và quy trình trong bảo mật mạng Việc nắm bắt các khái niệm và khung phân tích ở chương đầu cho phép nhận diện sớm lỗ hổng, đánh giá rủi ro và đề xuất biện pháp phòng ngừa một cách có hệ thống Bên cạnh đó, chương này nhấn mạnh vai trò của con người và quy trình vận hành trong bảo mật, từ đó xây dựng nền tảng cho các chiến lược bảo mật toàn diện và hiệu quả.
PHÂN TÍCH TĨNH VÀ RÀ SOÁT MÃ NGUỒN, PHÂN TÍCH ĐỘNG VÀ KIỂM THỬ THÂM NHẬP
Cách phát hiện lỗ hổng trực tiếp từ mã nguồn hoặc file nhị phân mà không cần thực thi
Phân tích Tĩnh (Static Analysis) là phương pháp phát hiện lỗ hổng trực tiếp từ mã nguồn hoặc file nhị phân mà không cần thực thi chương trình; phương pháp này còn được biết đến là Kiểm thử Bảo mật Ứng dụng Tĩnh (Static Application Security Testing - SAST), nhằm đánh giá an toàn của phần mềm từ giai đoạn phát triển.
2.1.1 Phân tích Tĩnh (Static Analysis - SAST)
Phân tích tĩnh là quá trình đánh giá và phân tích ứng dụng bằng cách kiểm tra trực tiếp mã nguồn, mã bytecode hoặc mã nhị phân mà không cần chạy chương trình, ở trạng thái tĩnh của mã Quá trình này giúp phát hiện lỗ hổng bảo mật, lỗi tiềm ẩn và cấu trúc hệ thống, từ đó đánh giá chất lượng và độ an toàn của phần mềm mà không thực thi mã Bằng cách phân tích các thành phần như luồng điều khiển, phụ thuộc thư viện và quá trình biên dịch, phân tích tĩnh cung cấp thông tin hữu ích cho công tác kiểm thử bảo mật và tối ưu hóa phần mềm.
• Đối với Mã Nguồn (Source Code)
Phương pháp này tập trung vào việc quét mã nguồn để tìm kiếm các mẫu mã hóa
(coding patterns), các lỗi lập trình, hoặc các điểm yếu tiềm tàng có thể dẫn đến lỗ hổng bảo mật
Bài viết tập trung vào việc phát hiện và khắc phục các vấn đề bảo mật phổ biến như Lỗi tràn bộ đệm (Buffer Overflow), Lỗi SQL Injection và Cross-Site Scripting (XSS), cùng với việc sử dụng các hàm hoặc thư viện không an toàn và các lỗi logic nghiệp vụ đơn giản Mục tiêu chính là phân tích và nhận diện các lỗ hổng thông qua Data Flow Analysis và Control Flow Analysis để tìm ra cách dữ liệu độc hại có thể đi từ nguồn (input) đến đích (sink), từ đó đề xuất biện pháp ngăn chặn và cải thiện an toàn hệ thống.
Các công cụ SAST phổ biến như SonarQube, Checkmarx, CodeSonar được sử dụng rộng rãi và thường được tích hợp vào quy trình phát triển CI/CD hoặc môi trường IDE, giúp tự động quét mã nguồn để phát hiện và khắc phục sớm các lỗ hổng bảo mật đồng thời cải thiện chất lượng mã.
• Đối với File Nhị Phân (Binary/Firmware)
Phân tích nhị phân tĩnh là phương pháp kiểm tra các tệp đã được biên dịch, firmware và các thư viện mà không cần mã nguồn, và nó đặc biệt hữu ích khi bạn không có quyền truy cập vào mã nguồn của các thành phần bên thứ ba (third-party components), giúp đánh giá an toàn, tính toàn vẹn và khả năng tương thích của phần mềm mà vẫn không tiếp xúc với mã nguồn gốc.
Mục tiêu chính là phát hiện lỗ hổng trong các thành phần của bên thứ ba do thiếu mã nguồn để tham chiếu, đồng thời tìm kiếm các lỗ hổng cấp độ thấp như Buffer Overflow và Command Injection nhằm đảm bảo an toàn cho hệ thống.
Injection trong mã máy (assembly code) là một khía cạnh quan trọng cần được theo dõi trong an ninh phần mềm Phân tích ngược (disassembly/decompilation) mã nhị phân sang mã hợp ngữ hoặc mã giả (pseudocode) giúp các nhà phân tích dễ đọc và hiểu hơn, ví dụ bằng các công cụ như IDA Pro Đồng thời, quá trình này cho phép phát hiện các bí mật được mã hóa cứng (hardcoded secrets) hoặc các thành phần độc hại bị chèn vào trong quá trình biên dịch, từ đó tăng cường khả năng bảo vệ hệ thống.
• Công cụ: Các công cụ phân tích nhị phân (ví dụ: IDA Pro, Ghidra, Binwalk, v.v.)
2.1.2 Ưu điểm phân tích tĩnh
Phát hiện sớm (Early Detection) cho phép nhận diện và khắc phục lỗ hổng ngay từ giai đoạn phát triển, giúp tiết kiệm chi phí và công sức so với việc phát hiện muộn.
Kiểm tra không cần thực thi cho toàn bộ mã nguồn hoặc file nhị phân cho phép phân tích và đánh giá phần mềm mà không yêu cầu môi trường chạy cụ thể Điều này rất hữu ích cho các thành phần không dễ thiết lập môi trường chạy, giúp tiết kiệm thời gian và tài nguyên đồng thời tăng cường khả năng xác định lỗi, đánh giá tính bảo mật và đảm bảo tính tương thích của hệ thống.
Kiểm tra toàn diện bắt buộc quét mọi đường dẫn có thể xuất hiện trong mã nguồn (theo lý thuyết), kể cả những phần ít được sử dụng trong quá trình kiểm thử động, nhằm đảm bảo không bỏ sót các đường dẫn tiềm ẩn và nâng cao hiệu quả của quá trình kiểm tra.
Rà soát mã nguồn thủ công (Manual Code Review)
Trong thời đại tự động hóa và trí tuệ nhân tạo, rà soát mã nguồn thủ công bởi con người vẫn là một trong những hoạt động hiệu quả nhất để phát hiện lỗ hổng bảo mật Các công cụ tự động rất mạnh ở việc nhận diện các mẫu lỗi đã biết và có thể tăng tốc quá trình kiểm tra, nhưng chúng thường không nắm được ngữ cảnh và ý đồ của mã nguồn, dễ bỏ sót các lỗ hổng phức tạp Vì thế, sự kết hợp giữa rà soát thủ công và công cụ tự động mang lại hiệu quả bảo mật cao hơn cho phần mềm và ứng dụng.
23 kinh doanh và các lỗi logic phức tạp Đây chính là nơi mà trí tuệ và kinh nghiệm của con người tỏa sáng
2.2.1 Tầm quan trọng và Quy trình a Tầm quan trọng của Rà soát thủ công
Phát hiện lỗi logic nghiệp vụ là ưu điểm nổi bật của rà soát thủ công trong quá trình đảm bảo an toàn hệ thống; trong khi một số công cụ SAST có thể kiểm tra mã nguồn nhưng vẫn có thể bỏ qua các lỗi phức tạp về luồng nghiệp vụ, như đoạn mã cho phép chuyển tiền, thì người rà soát có thể đặt các câu hỏi mang tính suy luận như: điều gì xảy ra nếu người dùng chuyển một số tiền âm, hay có cơ chế ngăn một người dùng thông thường phê duyệt một giao dịch yêu cầu quyền quản trị hay không, từ đó phát hiện các lỗ hổng mà chỉ con người mới hiểu được và có thể khắc phục kịp thời để đảm bảo an toàn và đúng đắn cho hệ thống.
Xác định lỗ hổng phức tạp: nhiều lỗ hổng không phải là lỗi trong một dòng mã duy nhất mà là kết quả của sự tương tác phức tạp giữa nhiều thành phần hệ thống Việc rà soát thủ công giúp người đánh giá nhìn thấy bức tranh toàn cảnh, từ đó phát hiện các chuỗi tấn công đa bước và các khe hở tiềm ẩn mà các công cụ tự động có thể bỏ qua.
Giảm thiểu dương tính giả (false positives) là thách thức thường gặp khi sử dụng các công cụ SAST, vì chúng tạo ra rất nhiều cảnh báo nhiễu không phản ánh đúng lỗ hổng thực sự Một reviewer có kinh nghiệm có thể nhanh chóng lọc bỏ những cảnh báo này, giúp tối ưu hóa quy trình bảo mật và cho phép đội ngũ phát triển tập trung vào các vấn đề an toàn thông tin thực sự, từ đó tăng hiệu quả rà soát mã và rút ngắn thời gian xử lý sự cố.
Chia sẻ kiến thức và xây dựng văn hóa an ninh là mục tiêu thiết yếu của quá trình rà soát mã Đây là cơ hội tuyệt vời để các nhà phát triển cấp cao truyền đạt kiến thức về lập trình an toàn cho các nhà phát triển cấp dưới, từ đó hình thành một văn hóa nơi mọi người đều có trách nhiệm với an ninh và không còn coi việc bảo mật là trách nhiệm của một bộ phận riêng biệt.
Trong nhiều ngành công nghiệp có quy định nghiêm ngặt như tài chính và y tế, rà soát mã nguồn bằng tay được xem là một yêu cầu bắt buộc để đảm bảo tuân thủ và chất lượng Một quy trình rà soát mã nguồn hiệu quả không phải là lướt qua mã một cách ngẫu nhiên mà là một quy trình có cấu trúc nhằm phát hiện sai sót, đảm bảo an ninh và tuân thủ chuẩn Bước 1: Chuẩn bị và Nắm bắt ngữ cảnh, xác định mục tiêu rà soát, phạm vi, tiêu chuẩn đánh giá và các yếu tố liên quan để tối ưu hóa hiệu suất kiểm tra.
● Mục tiêu: Hiểu ứng dụng đang làm gì, nó hoạt động như thế nào và các mối đe dọa tiềm tàng là gì
○ Đọc tài liệu kiến trúc, đặc tả yêu cầu
○ Trao đổi với đội ngũ phát triển để hiểu các luồng dữ liệu chính (data flows)
Để xây dựng một mô hình đe dọa (threat model) đơn giản, bắt đầu bằng việc xác định các tài sản quan trọng, các điểm đầu vào (entry points), các mức độ tin cậy (trust boundaries) và các tác nhân đe dọa tiềm tàng Việc xác định tài sản giúp nhận diện dữ liệu và dịch vụ cần bảo vệ nhất, trong khi các điểm đầu vào cho thấy nguồn dữ liệu và kênh giao tiếp có thể mang lại rủi ro; các mức độ tin cậy cho phép phân loại phạm vi an toàn và mức độ bảo vệ cho từng thành phần; còn các tác nhân đe dọa tiềm tàng là những yếu tố hoặc đối tượng có thể tác động đến hệ thống Mô hình đe dọa đơn giản này từ đó hỗ trợ đánh giá rủi ro và thiết kế các biện pháp bảo mật phù hợp, tối ưu hóa nguồn lực và nâng cao an toàn cho hệ thống.
Bước 2: Rà soát tổng quan (High-level Review)
● Mục tiêu: "Cảm nhận" về cấu trúc tổng thể của mã nguồn và xác định các khu vực có rủi ro cao
○ Xem xét cấu trúc dự án, các thư viện được sử dụng
○ Tập trung vào các file cấu hình (web.xml, pom.xml, package.json) để tìm các cài đặt không an toàn
○ Xác định các thành phần xử lý các chức năng nhạy cảm nhất:
■ Quản lý phiên (Session Management)
■ Xử lý đầu vào (Input Handling)
■ Ghi nhật ký và xử lý lỗi (Logging and Error Handling)
Bước 3: Rà soát chi tiết (Detailed Review)
● Mục tiêu: Đi sâu vào mã nguồn của các thành phần có rủi ro cao đã xác định ở bước 2
Theo dấu dữ liệu là phương pháp theo dõi một điểm đầu vào, ví dụ một tham số từ HTTP request, và đi theo đường đi của nó qua toàn bộ ứng dụng để xem dữ liệu được xác thực, xử lý và được sử dụng ở đâu; mục đích là xác định xem dữ liệu có đến một điểm cuối nguy hiểm (sink) như một câu lệnh SQL hay không, từ đó tối ưu hóa bảo mật bằng cách ngăn ngừa rò rỉ dữ liệu và đảm bảo việc kiểm soát đầu vào ở mọi lớp của hệ thống.
Khám phá các dấu hiệu mã nguồn có vấn đề (bad smells) bằng cách kết hợp kiến thức chuyên môn và kinh nghiệm thực tế để nhận diện các mẫu mã không an toàn; phần chi tiết về cách nhận diện và khắc phục các rủi ro bảo mật sẽ được trình bày ở phần sau.
○ Sử dụng checklist: Tham khảo các checklist uy tín như OWASP Code Review Guide để đảm bảo không bỏ sót các loại lỗ hổng phổ biến
Bước 4: Tổng hợp và Báo cáo
● Mục tiêu: Ghi lại các phát hiện một cách rõ ràng, dễ hiểu và có tính hành động
○ Với mỗi phát hiện, cần ghi rõ:
■ Tên lỗ hổng: Ví dụ: "SQL Injection"
■ Vị trí: Tên tệp và số dòng
■ Mô tả: Giải thích tại sao đây là một vấn đề
■ Tác động: Điều gì tồi tệ nhất có thể xảy ra nếu lỗ hổng này bị khai thác?
■ Mức độ nghiêm trọng: (ví dụ: Critical, High, Medium, Low)
■ Khuyến nghị khắc phục: Cung cấp đoạn mã ví dụ về cách sửa lỗi
Để quản lý lỗ hổng hiệu quả, hãy sử dụng các công cụ quản lý dự án như Jira để tạo các ticket cho từng lỗ hổng riêng biệt Việc này cho phép theo dõi tiến độ khắc phục một cách có tổ chức, gắn nhãn ưu tiên và gán trách nhiệm cho từng thành viên Nhờ hệ thống ticket, đội ngũ có thể cập nhật trạng thái, thời gian xử lý và kết quả khắc phục nhanh chóng, đồng thời báo cáo tình hình an toàn thông tin một cách rõ ràng cho các bên liên quan.
2.2.2 Tìm kiếm các "bad smell" trong code liên quan đến bảo mật
“Bad smells” là thuật ngữ mô tả những dấu hiệu trong mã nguồn cho thấy có thể tồn tại vấn đề bảo mật sâu xa; trong bối cảnh bảo mật, chúng là những mẫu mã thường dẫn đến lỗ hổng và cần được rà soát để ngăn ngừa nguy cơ bị khai thác Dưới đây là một số “mùi” phổ biến mà người review cần cảnh giác, trong đó ví dụ điển hình là bí mật được mã hóa cứng (Hardcoded Secrets), bởi chúng có thể rò rỉ thông tin nhạy cảm và làm yếu bảo mật của hệ thống.
● Mùi: Các chuỗi nhạy cảm như mật khẩu, khóa API, chuỗi kết nối cơ sở dữ liệu được viết thẳng vào trong mã nguồn
● Tại sao tệ? Bất kỳ ai có quyền truy cập vào mã nguồn (kể cả các phiên bản cũ trong lịch sử Git) đều có thể thấy được bí mật Việc thay đổi bí mật đòi hỏi phải sửa mã, build và triển khai lại toàn bộ ứng dụng
● Ví // String dụ BAD dbUrl = (Java): SMELL
"jdbc:mysql://localhost:3306/mydatabase"; String String username password = "Str0ngPassword123!"; "admin"; // Ouch! Connection connection DriverManager.getConnection(dbUrl, username, password);
● Cách khắc phục: Lưu trữ bí mật bên ngoài mã nguồn
○ Biến môi trường (Environment Variables): Đơn giản và phổ biến
○ Tệp cấu hình riêng biệt: Tệp này không được commit vào Git
○ Hệ thống quản lý bí mật (Secrets Management Systems): Giải pháp tốt nhất cho môi trường sản xuất (ví dụ: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault)
○ Ví dụ khắc phục (Java): // GOOD PRACTICE String password System.getenv("DB_PASSWORD"); Connection connection DriverManager.getConnection(dbUrl, username, b Nối chuỗi trong câu lệnh SQL (SQL Query String Concatenation)
● Mùi: Xây dựng câu lệnh SQL bằng cách nối chuỗi trực tiếp với dữ liệu đầu vào từ người dùng Đây là dấu hiệu kinh điển của lỗ hổng SQL Injection
SQL injection là một mối đe dọa bảo mật nghiêm trọng: kẻ tấn công có thể chèn các đoạn mã SQL độc hại vào đầu vào, làm thay đổi logic của câu lệnh truy vấn và cho phép chúng đọc, sửa hoặc xóa dữ liệu, thậm chí chiếm quyền kiểm soát máy chủ cơ sở dữ liệu, gây rò rỉ thông tin nhạy cảm và làm gián đoạn hoạt động hệ thống.
Example in Python demonstrates a highly vulnerable pattern: a get_user(username) function builds the SQL query by concatenating user input, resulting in a query like "SELECT * FROM users WHERE username = '" + username + "'" When an attacker provides a username such as ' OR '1'='1, the query can become "SELECT * FROM users WHERE username = '' OR '1'='1", which may always return a result This is a classic bad smell in code, signaling SQL injection risk and potential data leakage The safe fix is to use parameterized queries or prepared statements and to validate or sanitize inputs so that user data cannot alter the SQL logic.
● Cách khắc phục: Luôn luôn sử dụng Truy vấn tham số hóa (Parameterized Queries) hoặc Prepared Statements
○ Ví dụ khắc phục (Python): # GOOD PRACTICE def get_user(username): query "SELECT * FROM users WHERE username = %s" cursor.execute(query, (username,))
# Dữ liệu được gửi riêng biệt return cursor.fetchone() c Thiếu xác thực đầu vào (Lack of Input Validation)
● Mùi: Tin tưởng một cách mù quáng vào bất kỳ dữ liệu nào đến từ người dùng hoặc các hệ thống bên ngoài
● Tại sao tệ? Dữ liệu không được kiểm tra có thể gây ra vô số lỗ hổng: XSS (Cross- Site Scripting), Command Injection, Path Traversal, Buffer Overflow
● Nguyên tắc vàng: "Validate input, escape output" (Kiểm tra đầu vào, mã hóa đầu ra)
Phân tích ứng dụng tĩnh (Static Application Security Testing - SAST)
Rà soát thủ công rất mạnh mẽ nhưng tốn thời gian và khó mở rộng quy mô, nên các công cụ SAST ra đời để giải quyết bài toán này SAST tự động hóa quá trình phân tích mã nguồn, giúp phát hiện lỗ hổng bảo mật và điểm yếu tiềm ẩn từ sớm, rút ngắn chu trình phát triển và tăng hiệu suất làm việc của đội ngũ phát triển Bằng cách tích hợp vào CI/CD và quét toàn bộ codebase, SAST giảm thiểu rủi ro an ninh thông tin, hỗ trợ tuân thủ chuẩn bảo mật và cải thiện khả năng mở rộng của quy trình rà soát mã, từ đó mang lại sự an toàn cho ứng dụng và tối ưu chi phí phát hiện và sửa lỗi.
29 tìm các lỗ hổng tiềm ẩn, hoạt động như một cặp mắt máy móc không biết mệt mỏi, có thể quét hàng triệu dòng mã trong vài phút
2.3.1 Nguyên lý hoạt động của các công cụ SAST
Hầu hết các công cụ SAST hiện đại không chỉ đơn thuần thực hiện tìm kiếm văn bản (text search); chúng xây dựng một mô hình phức tạp của ứng dụng để hiểu được cấu trúc và luồng hoạt động của nó, từ đó có thể phát hiện rủi ro bảo mật ở từng thành phần và mối liên hệ giữa chúng Quá trình này thường bao gồm các bước như phân tích cú pháp mã nguồn, mô hình hóa kiến trúc và luồng dữ liệu, đánh giá các điểm yếu tiềm ẩn, và sinh báo cáo ưu tiên lỗ hổng kèm gợi ý khắc phục để nhà phát triển có thể hành động ngay.
1 Phân tích từ vựng (Lexical Analysis): Giai đoạn đầu tiên, mã nguồn được đọc và chia thành các đơn vị nhỏ nhất có ý nghĩa gọi là "tokens" Ví dụ, dòng mã x = a + b; sẽ được chia thành các token: x, =, a, +, b, ;
2 Phân tích cú pháp (Syntactic Analysis / Parsing): Các token được nhóm lại với nhau để xây dựng một cấu trúc dữ liệu dạng cây gọi là Cây Cú pháp Trừu tượng (Abstract Syntax Tree - AST) AST biểu diễn cấu trúc ngữ pháp của mã nguồn, loại bỏ các chi tiết không cần thiết như dấu chấm phẩy hay khoảng trắng, chỉ giữ lại bản chất của code
○ Ví dụ: AST cho x = a + b; sẽ có một nút gốc là "phép gán", nút này có hai con: nút
"biến x" và nút "phép cộng" Nút "phép cộng" lại có hai con là "biến a" và "biến b"
3 Phân tích ngữ nghĩa (Semantic Analysis): Giai đoạn này, công cụ SAST xây dựng các mô hình phức tạp hơn dựa trên AST để hiểu "ý nghĩa" của code Hai mô hình quan trọng nhất là:
○ Đồ thị Luồng điều khiển (Control Flow Graph - CFG): Biểu diễn tất cả các đường đi có thể có mà chương trình có thể thực thi
○ Đồ thị Luồng dữ liệu (Data Flow Graph - DFG): Theo dõi cách dữ liệu (giá trị của các biến) di chuyển và được biến đổi trong chương trình
4 Áp dụng Quy tắc (Rule Application): Cuối cùng, công cụ SAST sẽ áp dụng một bộ quy tắc bảo mật (ruleset) khổng lồ lên các mô hình đã được xây dựng Các quy tắc này định nghĩa các mẫu mã không an toàn Ví dụ, một quy tắc có thể là: "Tìm tất cả các đường đi trong đó dữ liệu từ một HTTP request (nguồn) chảy đến một hàm thực thi câu lệnh SQL (đích) mà không đi qua một hàm xác thực (bộ lọc)"
Phân tích thành phần phần mềm (Software Composition Analysis - SCA)
Phần mềm hiện đại không được xây dựng từ con số 0 mà được lắp ráp từ hàng trăm, thậm chí hàng nghìn thư viện mã nguồn mở (open-source dependencies) Việc tận dụng các thư viện này giúp tăng tốc độ phát triển đáng kể, nhưng đi kèm đó là rủi ro bảo mật lớn: bạn thừa hưởng mọi lỗ hổng có trong các thư viện bạn đang sử dụng Vì vậy quản lý phụ thuộc (dependency management) và đánh giá an ninh cho các thư viện mã nguồn mở là yếu tố thiết yếu để cân bằng giữa tốc độ phát triển và an toàn của phần mềm, đồng thời đòi hỏi cập nhật phiên bản đều đặn và kiểm tra bảo mật để bảo vệ hệ thống.
Vụ tấn công vào Equifax năm 2017 đã làm lộ dữ liệu của khoảng 147 triệu người và trở thành một trong những vụ rò rỉ dữ liệu lớn nhất lịch sử Nguyên nhân gốc rễ là lỗ hổng đã biết, CVE-2017-5638, trong thư viện mã nguồn mở Apache Struts mà Equifax không cập nhật kịp thời Lỗ hổng này cho phép kẻ tấn công khai thác từ xa và truy cập hệ thống mà không cần xác thực Vụ việc nhấn mạnh tầm quan trọng của việc quản lý vá lỗi và cập nhật phần mềm định kỳ, đặc biệt với các thư viện mã nguồn mở phổ biến như Apache Struts, nhằm giảm thiểu rủi ro rò rỉ dữ liệu và bảo vệ thông tin người dùng.
SCA là quá trình tự động hóa việc xác định và quản lý các thành phần mã nguồn mở trong một ứng dụng
Nguyên lý hoạt động của SCA:
1 Xây dựng Danh mục Vật liệu (Bill of Materials - BOM): Bước đầu tiên, công cụ SCA quét các tệp quản lý dependency của dự án (ví dụ: pom.xml cho Maven, build.gradle cho Gradle, package.json cho Node.js, requirements.txt cho Python) để tạo ra một danh sách đầy đủ tất cả các thư viện của bên thứ ba và phiên bản chính xác của chúng
2 Đối chiếu với Cơ sở dữ liệu Lỗ hổng: Công cụ sau đó sẽ đối chiếu danh sách này với nhiều cơ sở dữ liệu về lỗ hổng công khai và độc quyền, bao gồm:
○ National Vulnerability Database (NVD) - chứa danh sách các CVE
○ Các cơ sở dữ liệu của nhà cung cấp công cụ (ví dụ: Snyk Vulnerability Database, GitHub Advisory Database)
○ Các danh sách email bảo mật
3 Báo cáo và Khuyến nghị: Khi tìm thấy một sự trùng khớp, công cụ SCA sẽ báo cáo:
○ Thư viện nào bị ảnh hưởng
○ Phiên bản nào đang được sử dụng
○ Mã CVE của lỗ hổng
○ Điểm CVSS và mức độ nghiêm trọng
Quan trọng nhất, các công cụ SCA thường đề xuất phiên bản tối thiểu cần nâng cấp để vá lỗ hổng bảo mật, giúp hệ thống được bảo vệ khỏi các khai thác còn sót Ngoài việc phát hiện lỗ hổng, các công cụ SCA còn quản lý rủi ro về giấy phép (license risk) bằng cách đảm bảo giấy phép của các thư viện mã nguồn mở bạn đang sử dụng tương thích với chính sách của công ty và ngăn ngừa các nghĩa vụ pháp lý không mong muốn.
Kỹ thuật phát hiện lỗ hổng trên một hệ thống hoặc ứng dụng đang chạy
2.5.1 Quét lỗ hổng (Vulnerability Scanning)
- Quét Lỗ hổng (Vulnerability Scanning)
Kỹ thuật này sử dụng các công cụ tự động để quét từ bên ngoài hệ thống hoặc ứng dụng đang hoạt động, như một máy chủ web hoặc mạng, bằng cách gửi các yêu cầu hoặc probes đến mục tiêu và phân tích phản hồi để xác định các điểm yếu đã biết Quá trình này giúp nhận diện lỗ hổng từ xa và đánh giá mức độ bảo mật của hệ thống, đồng thời cung cấp căn cứ cho các biện pháp tăng cường an ninh và tối ưu hóa cấu hình hệ thống để giảm thiểu rủi ro.
Để tối ưu hóa an toàn thông tin và quản lý lỗ hổng, quy trình này gồm hai bước chính: so sánh phiên bản phần mềm của hệ điều hành, dịch vụ mạng và ứng dụng với cơ sở dữ liệu lỗ hổng đã biết (CVE) và kiểm tra các cấu hình sai (misconfigurations) cùng với các dịch vụ không cần thiết đang chạy, nhằm giảm bề mặt tấn công và tăng cường bảo mật hệ thống.
• Ví dụ Công cụ: Nessus, OpenVAS, Nmap (để khám phá và kiểm tra cơ bản)
+ Phân tích ứng dụng động (Dynanic Application Security Testing – DAST
DAST là một phương pháp kiểm thử bảo mật ứng dụng bằng cách giả lập các cuộc tấn công từ hacker khi ứng dụng đang chạy, nhằm kiểm tra hành vi của ứng dụng từ bên ngoài và đánh giá khả năng phòng thủ của hệ thống trong điều kiện thực tế Phương pháp này cho phép nhận diện lỗ hổng bảo mật, sai sót cấu hình và các yếu tố dễ bị khai thác khi ứng dụng vận hành, mà các công cụ kiểm thử tĩnh có thể bỏ qua Kết quả của DAST cung cấp thông tin ưu tiên khắc phục, giúp đội ngũ phát triển và bảo mật cải thiện an toàn ứng dụng và giảm thiểu rủi ro bị tấn công từ bên ngoài.
Cách thức kiểm thử bảo mật ứng dụng thường bắt đầu bằng việc sử dụng các công cụ gửi các đầu vào độc hại hoặc bất thường tới các giao diện của ứng dụng, chẳng hạn form nhập liệu, tham số URL và header HTTP Quá trình này phân tích phản hồi từ ứng dụng để nhận diện dấu hiệu của các lỗ hổng bảo mật phổ biến như SQL Injection, Cross-Site Scripting (XSS), hoặc Remote Code Execution, từ đó đánh giá mức độ rủi ro và đề xuất các biện pháp khắc phục.
Điểm mạnh nổi bật của phương pháp là khả năng phát hiện các lỗ hổng mà phân tích tĩnh (SAST) có thể bỏ sót, đặc biệt là những vấn đề liên quan đến môi trường hoạt động và cấu hình Nhờ khả năng này, các lỗ hổng về cách triển khai hệ thống, biến môi trường và tham số cấu hình được nhận diện và xử lý sớm, từ đó tăng cường bảo mật, giảm thiểu rủi ro khai thác và cải thiện hiệu quả quản lý an ninh ứng dụng.
• Ví dụ Công cụ: OWASP ZAP, Burp Suite, Acunetix
Fuzzing là kỹ thuật kiểm thử bảo mật tự động nhằm bơm vào đầu vào của một ứng dụng đang chạy một lượng lớn dữ liệu ngẫu nhiên, bất hợp lệ hoặc không mong muốn Quá trình này giúp phát hiện các sự cố như treo chương trình, rò rỉ bộ nhớ hoặc hành vi bất thường có thể chỉ ra lỗ hổng bảo mật, từ đó cải thiện an ninh cho phần mềm và hệ thống.
Phương pháp fuzz testing tạo ra dữ liệu rác (fuzz) và đưa nó vào các điểm đầu vào của ứng dụng, chẳng hạn như các hàm API, giao thức mạng và trình phân tích cú pháp tệp, nhằm đánh giá độ chịu đựng và khả năng xử lý lỗi của hệ thống Đồng thời theo dõi ứng dụng để xác định xem nó có bị crash hoặc có phản hồi bất thường hay không, từ đó phát hiện lỗ hổng và cải thiện ổn định, đáng tin cậy và an toàn của phần mềm.
Mục đích: Đặc biệt hiệu quả trong việc phát hiện các lỗi cấp thấp như tràn bộ đệm (Buffer Overflows) và các lỗi hỏng bộ nhớ khác
2.5.2 Phân tích ứng dụng động (Dynamic Application Security Testing - DAST): DAST là một phương pháp kiểm thử bảo mật ứng dụng bằng cách giả lập các cuộc tấn công của tin tặc khi ứng dụng đang chạy Nó kiểm tra hành vi của ứng dụng từ bên ngoài
Phương pháp kiểm thử bảo mật ứng dụng thường bắt đầu bằng việc sử dụng công cụ gửi các đầu vào độc hại hoặc bất thường tới các giao diện của ứng dụng, như form nhập liệu, tham số URL và header HTTP Tiếp theo, hệ thống phân tích phản hồi từ ứng dụng để nhận diện các dấu hiệu của lỗ hổng bảo mật, chẳng hạn SQL Injection, Cross-Site Scripting (XSS) hoặc Remote Code Execution Quá trình kết hợp giữa thử nghiệm đầu vào và phân tích phản hồi giúp xác định các điểm yếu an toàn của hệ thống và hỗ trợ quá trình vá lỗi, từ đó nâng cao bảo mật cho ứng dụng.
Điểm mạnh của giải pháp là khả năng phát hiện các lỗ hổng mà phân tích tĩnh (SAST) có thể bỏ sót, đặc biệt là các vấn đề liên quan đến môi trường hoạt động hoặc cấu hình hệ thống, từ đó nâng cao bảo mật cho ứng dụng và giảm thiểu rủi ro do các yếu tố thực thi ngoài ý muốn.
• Ví dụ Công cụ: OWASP ZAP, Burp Suite, Acunetix
Fuzzing là kỹ thuật kiểm thử tự động, bơm một lượng lớn dữ liệu ngẫu nhiên, bất hợp lệ hoặc không mong muốn vào đầu vào của một chương trình đang chạy nhằm tìm kiếm các lỗ hổng bảo mật và các lỗi khiến phần mềm bị treo hoặc crash Mục tiêu của fuzzing là khám phá các tình huống bất thường mà người kiểm thử thường không nghĩ tới, từ đó giúp cải thiện độ tin cậy và an toàn của hệ thống Quá trình này có thể được thực hiện bằng các công cụ fuzzing tự động hoặc bằng cách viết các bộ sinh dữ liệu tùy chỉnh, áp dụng cho cả API, giao diện người dùng và các hệ thống backend Các phương pháp fuzzing phổ biến bao gồm black-box, white-box và grey-box, tùy thuộc vào mức độ có sẵn thông tin về cấu trúc và hành vi của ứng dụng Kết quả của fuzzing là danh sách các lỗ hổng hoặc lỗi có tiềm năng, từ đó các nhà phát triển có thể vá lỗi và tăng cường bảo mật cho phần mềm.
33 sự cố (crashes), rò rỉ bộ nhớ, hoặc hành vi không mong muốn có thể chỉ ra một lỗ hổng bảo mật
Phương pháp fuzz testing (fuzzing) tạo dữ liệu fuzz (dữ liệu rác) và đưa nó vào các điểm đầu vào của ứng dụng, như hàm API, giao thức mạng và trình phân tích cú pháp tệp, nhằm kích hoạt các lỗi tiềm ẩn Sau đó, theo dõi ứng dụng để phát hiện lỗi hoặc phản hồi bất thường nhằm đánh giá độ ổn định và an toàn của hệ thống, từ đó cải thiện chất lượng phần mềm.
• Mục đích: Đặc biệt hiệu quả trong việc phát hiện các lỗi cấp thấp như tràn bộ đệm (Buffer Overflows) và các lỗi hỏng bộ nhớ khác
2.5.4 Phân tích ứng dụng tương tác (Interactive Application Security Testing - IAST) IAST là một phương pháp kết hợp sức mạnh của phân tích tĩnh (SAST) và phân tích động (DAST) bằng cách sử dụng các agent/sensor được đặt bên trong ứng dụng đang chạy
IAST (Interactive Application Security Testing) giám sát luồng dữ liệu và luồng điều khiển bên trong ứng dụng trong quá trình kiểm thử bằng các công cụ DAST, kiểm thử chức năng thủ công hoặc khi người dùng bình thường vận hành hệ thống Nó có thể xác định chính xác dòng mã nguồn nào đang bị ảnh hưởng bởi đầu vào độc hại trong thời gian real-time, từ đó cung cấp dữ liệu để nhanh chóng phát hiện và khắc phục lỗ hổng bảo mật.
• Điểm mạnh: o Độ chính xác cao hơn DAST và SAST đơn thuần o Giảm thiểu đáng kể lỗi dương tính giả (false positives)
• Ví dụ Công cụ: Contrast Security, HCL AppScan IAST.
KẾT LUẬN CHƯƠNG 2
Chương 2 giới thiệu hai chiến lược kiểm thử bảo mật chính: Phân tích Tĩnh (Static
Analysis) và Phân tích Động (Dynamic Analysis), cùng với các biến thể của chúng
Phân tích Tĩnh (SAST/SCA/Manual Review) giúp phát hiện sớm lỗi trong vòng đời phát triển theo mô hình Shift-Left bằng cách kiểm tra cấu trúc mã và các phụ thuộc, là phương pháp lý tưởng để nhận diện lỗi lập trình cũng như lỗ hổng trong thư viện bên ngoài.
Phân tích Động (DAST, Fuzzing, IAST) giúp phát hiện lỗi khi ứng dụng đang vận hành, đặc biệt hiệu quả với các lỗi cấu hình, lỗi triển khai và cách ứng dụng phản ứng với môi trường bên ngoài Để đạt mức bảo mật tối đa, các tổ chức nên kết hợp đồng bộ các phương pháp phân tích bảo mật—SAST, SCA, DAST và IAST—trong suốt vòng đời phát triển phần mềm (SDLC).
