KIỂM THỬ XÂM NHẬP
3.2 Top 10 lỗ hổng OWASP
OWASP (Open Web Application Security Project}}] là một tổ chức phi lợi nhuận
toàn cầu tập trung vào việc cung cấp thông tin, tài liệu và công cụ liên quan đến bảo mật ứng dụng web. OWASP tập trung vào việc nâng cao nhận thức về bảo
mật ứng dụng web và tạo ra các tiêu chuẩn, hướng dẫn và tài liệu phát triển an
Thttp: / /owasp.org
21
Chương 3. Cơ sở lý thuyết
toàn và miễn phí cho cộng đồng.
OWASP Top 10 là một danh sách (Hình:|3.2) những rủi ro bảo mật ứng dụng web phổ biến và nguy hiểm nhất được OWASP công bố. Danh sách này cung cấp cái nhìn tổng quan về những lỗ hổng bảo mật phổ biến và cần được chú ý. OWASP Top 10 được cập nhật định kỳ để phản ánh các mối đe dọa mới và xu hướng phát triển. OWASP Top 10 như một “tài liệu nâng cao nhận thức” và nó được khuyến nghị tất cả các công ty nên kết hợp báo cáo này vào các quy trình của họ để giảm thiểu rủi ro bảo mật.
2017 2021
A01:2021-Broken Access Control A02:2021-Cryptographic Failures
àA03:2021-Injection
__.(New} A04:2021-Insecure Design
“<== A05:2021-Security Misconfiguration
A01:2017-Injection
A02:2017-Broken Authentication
A03:2017-Sensitive Data Exposure
.A04:2017-XML External Entities (XXE)
A05:2017-Broken Access Control
A06:2017-Security Misconfiguration _—— A06:2021-Vulnerable and Outdated Components
.A07:2017-Cross-Site Scripting (XSS) : di A07:2021-Identification and Authentication Failures
_A08:2017-Insecure Deserialization = § re {New} A08:2021-Software and Data Integrity Failures
A09:2017-Using Components with Known Vulnerabilities _ A09:2021-Security Logging and Monitoring Failures*
A10:2017-Insufficient Logging & Monitoring |) (New) A10:2021-Server-Side Request Forgery (SSRF)*
* From the Survey
HINH 3.2: OWASP Top 10 nam 2017 va 2021
Dưới đây là các rủi ro bảo mật được báo cáo trong OWASP Top 10 công bố năm
2021:
3.21 Broken Access Control
Đứng dau trong danh sách OWASP Top 10 là lỗ hổng Broken Access Control. Nó xảy ra khi hệ thống không kiểm soát và quản lý việc truy cập vào các tài nguyên
nhạy cảm và chức năng của ứng dụng một cách chính xác.
Với lỗ hổng Broken Access Control, tin tặc có thể xâm nhập và thực hiện các hoạt động không được ủy quyền như xem, chỉnh sửa, xóa thông tin hoặc truy cập vào các tinh năng quan trọng mà không có quyển truy cập. Điều này có thể dẫn đến việc tiết lộ các thông tin nhạy cảm, thay đổi dữ liệu, hoặc lợi dụng các chức năng quản lý để chiếm quyền điều khiển hệ thống.
TNguồn anh: https:/ /owasp.org/www-project-top-ten/
22
Chương 3. Cơ sở lý thuyết
Ví dụ, giả sử một ứng dụng web có tính năng xem và sửa thông tin người dùng.
Người dùng A chỉ có quyển xem thông tin của riêng mình. Tuy nhiên, do tổn tại
lỗ hổng Broken Access Control, một tin tặc (người dùng A) có thể thay đổi tham
số truy vấn để đánh lừa hệ thống rằng mình là người dùng B từ đó truy cập thông tin người dùng khác. Điều này cho phép tin tặc xem, chỉnh sửa hoặc xóa thông tin của những người dùng khác mà không có quyền truy cập.
Để khắc phục lỗ hổng Broken Access Control, cần thực hiện kiểm tra và xác thực quyền truy cập của người dùng đối với các tài nguyên và chức năng quan trọng.
Hệ thống nên áp dụng các kiểm soát truy cập chặt chẽ, đảm bảo rằng người dùng chỉ có thể truy cập và thao tác trên các tài nguyên mà họ được ủy quyền.
3.2.2. Cryptographic Failures
Lỗ hổng Cryptographic Failures liên quan đến việc sử dung mã hóa và các thuật
toán mật mã một cách không chính xác hoặc không an toàn trong ứng dụng web.
Khi các phương pháp mã hóa không được thực hiện đúng cách, thông tin nhạy
cảm có thể bị tiết lộ hoặc bị tấn công.
Có một số ví dụ về Cryptographic Failures mà ta có kể đến. Một ví dụ đầu tiên
là sử dụng thuật toán mã hóa yêu. Một thuật toán mã hóa yêu có thể dé dang bị phá vỡ bởi các tin tặc thông qua các phương pháp phân tích va tấn công mật mã. Nếu ứng dụng web sử dụng một thuật toán mã hóa yếu như MD5 hay DES, thì thông tin được mã hóa có thể bị phá vỡ và tiết lộ.
Một ví dụ khác là quản lý và bảo mật các khóa mã hóa một cách không an toàn.
Nếu khóa bí mật hoặc khóa công khai được lưu trữ hoặc truyền tải một cách không an toàn, tin tặc có thể thu thập được khóa và sử dụng chúng để giải mã
hoặc tạo ra chữ ký giả mạo.
Ngoài ra, Cryptographic Failures cũng có thể xảy ra khi không thực hiện đúng
các quy trình và phương pháp sử dụng mật mã. Ví dụ, việc sử dụng cách sử dụng
mật mã không an toàn như việc lưu trữ mật khẩu người dùng dưới dạng văn bản
23
Chương 3. Cơ sở lý thuyết
không được mã hóa hoặc sử dụng các thư viện mật mã cũ, không cập nhật.
Để khắc phục lỗ hổng Cryptographic Failures, can thực hiện các biện pháp bảo mật mật mã chính xác và an toàn. Điều này bao gồm sử dụng các thuật toán
mã hóa mạnh, lưu trữ và truyền tải khóa mật mã một cách an toàn, và tuân thủ các quy trình và phương pháp sử dụng mật mã được khuyến nghị và chấp nhận trong cộng đồng bảo mật.
3.2.3 Injection
Lỗ hổng Injection là một rủi ro bảo mật phổ biến và nguy hiểm trong ứng dụng
web, với lỗ hổng này, tin tặc có thể chèn và thực thi mã độc hại hoặc các lệnh không được kiểm soát vào các thành phần của ứng dụng. Điều này thường xảy ra khi dữ liệu đầu vào không được xử lý hoặc kiểm tra đúng cách trước khi sử dung trong các truy vân SQL, lệnh command shell, biểu thức XPath, hoặc các ngôn ngữ truy vấn khác.
Ví dụ cụ thể về lỗ hổng Injection là SQL Injection. Khi một ứng dung web không kiểm tra hoặc sử dung đữ liệu đầu vào không an toàn khi thực thi truy vấn SQL, tin tặc có thể chèn ma SQL độc hai để thực hiện các hành động không mong muốn như truy xuất, thay đổi hoặc xóa dữ liệu trong cơ sở dữ liệu. Ví dụ ở tính năng đăng nhập của một trang web có sử dụng dữ liệu đầu vào lấy từ người dùng và không hề thông qua bat kỳ quá trình lọc đầu vào hoặc xử lý các kỹ tự đặc biệt để đưa vào một đoạn truy van SQL bang cách ghép chuỗi như sau:
String q = "Select u_id from User where "
+ "u name = '" + u name + "' + "and password = '" + password + "';";
Nếu người dùng truyén vào u_name="viet" va password="Aa@123456" thì câu truy vấn thu được sẽ là:
String q = "Select u_id from User where "
+ "u name = 'viet' and password = 'Aa@123456';";
24
Chương 3. Cơ sở lý thuyết
Nhưng nếu người dùng truyền vào u_name="admin' OR 1=1;-- -" va password="Aa@" thì câu truy van bây giờ sẽ trở thành:
String q = "select u_id from User where "
+ "u_name = 'admin' OR 1=1;-- -' "
+ "and password = 'Aa@';";
Lúc nay câu điều kiện của truy van sẽ là luôn đúng, có nghĩa là tin tặc có thể dé
đàng đăng nhập với tài khoản admin với lỗ hổng SQL Injection.
Injection cũng có thể xảy ra trong các ngôn ngữ và công cụ khác như Command
Injection, XML Injection, LDAP Injection, hoặc là các lỗ hổng XSS (Cross-Site
Scripting) cho phép tin tặc chèn mã JavaScript độc hại vào các trang web.
Để phòng ngừa lỗ hổng Injection, cần thực hiện các biện pháp bảo mật như
sử dụng cách nhập liệu an toàn như Prepared Statements hoặc Parameterized
Queries, kiểm tra và xử lý dữ liệu đầu vào một cách cẩn thận, hạn chế quyền truy
cập cơ sở đữ liệu, và cập nhật thường xuyên các phiên bản phần mềm và thư viện
sử dụng.
3.2.4 Insecure Design
Thiết kế không an toàn (Insecure Design) là một trong những mối nguy bảo mat
phổ biến trong lĩnh vực ứng dụng web. Nó không chi dé cập đến một lỗ hổng cụ
thể mà thực tế là một van dé toàn điện trong việc thiết kế hệ thống.
Thiết kế không an toàn có thể tạo ra các điểm yếu trong hệ thống, mở ra cơ hội
cho các cuộc tấn công xâm nhập. Nó có thể bao gồm việc không xác thực và phân
quyền đúng cách, sử dụng các thuật toán mã hóa yếu, lưu trữ thông tin nhạy cảm
một cách không an toàn hoặc không tuân thủ các yêu cầu bảo mật cơ bản.
Ví dụ, nếu một ứng dụng web không thực hiện kiểm tra xác thực đúng cách,
người dùng có thể thực hiện các hoạt động không được phép, truy cập vào thông
tin nhạy cảm hoặc thay đổi đữ liệu trong hệ thống. Hoặc nếu một ứng dung web
lưu trữ mật khẩu dưới dang văn bản không được mã hóa, tin tặc có thé dé dang
25
Chương 3. Cơ sở lý thuyết
đánh cắp thông tin này và sử dụng nó để xâm nhập vào tài khoản của người dùng.
Những vấn dé trong thiết kế rất khó để khắc phục hoặc mất rất nhiều nguồn lực để khắc phục nó. Vậy nên muốn hạn chế Insecure Design ta cần áp dụng các phương pháp thiết kế an toàn, sử dụng nguyên tắc bảo mật trong quá trình phát triển. Dưới đây là một số phương pháp và quy trình phát triển sản phấp để tránh thiết kế không an toàn:
1 Use Case
Description
Threat Security Mitigation Requirements
Analysis
3
Data Flow &
Process Flow
Diagram
4 Generation
Botnet
Threats Identification
HINH 3.3: Threat Modeling
© Threat modeling: Day là quy trình (Hình: xác định và đánh giá các
mối đe dọa tiềm tàng đối với hệ thống. Bằng cách xác định các mối đe dọa
trước, ta có thể áp dụng các biện pháp bảo mật phù hợp từ giai đoạn thiết kế.
® Kiến trúc bảo mật: Thiết kế kiến trúc hệ thống bảo mật da tang, bao gồm
các thành phần như tường lửa, phân quyền, xác thực và kiểm soát truy cập.
26
Chương 3. Cơ sở lý thuyết
Điều này giúp giảm thiểu tối đa bề mặt tấn công trong tương lai.
DevSecOps
Plan Deploy
(PRE-PRODUCTION) (PRODUCTION)
Threat modeling, l Access and configuration management, change impact analysis chaos engineering, pen testing
Build Operate
(PRE-PRODUCTION) Pre-production Production (PRODUCTION)
Log collection, RASP,
Pre-commit hooks,
Patching, WAF
software composition analysis, SAST, code review,
container security, vulnerability
scanning, DAST
Test Monitor
(PRE-PRODUCTION) (PRODUCTION)
DAST SIEM, vulnerability monitoring,
access control
HÌNH 3.4: Quy trình vòng đời sản phẩm trong DevSecOps
¢ Sử dụng quy trình phát triển an toàn: Ap dụng các quy trình phát triển
an toàn như Secure SDLC (Secure Software Development Lifecycle) hoặc
DevSecOps (Hinh: (3.4). Quy trình nay tích hợp các hoạt động bảo mật vào quy trình phát triển, bao gồm kiểm tra mã nguồn, kiểm thử bảo mật và đánh giá rủi ro liên tục suốt vòng đời của sản phẩm giúp phát hiện và khắc phục các lỗ hổng sớm hơn và ít tốn chỉ phí hơn.
¢ Đào tạo và nhận thức bảo mật: Dam bảo rằng nhân viên và thành viên của
nhóm phát triển được đào tạo về các nguy cơ bảo mật và các phương pháp phòng ngừa. Tăng cường nhận thức về bảo mật sẽ giúp mọi người nhận thức về tầm quan trọng của thiết kế an toàn và áp dụng các phương pháp
phù hợp.
TNguôồn anh: https:/ /www.atlassian.com/devops/devops-tools/devsecops-tools
27
Chương 3. Cơ sở lý thuyết
3.2.5 Security Misconfiguration
Lỗ hổng Security Misconfiguration (cau hình sai) là một trong những rủi ro quan
trọng trong lĩnh vực bảo mật ứng dụng web. Nó xuất hiện khi cau hình hệ thống,
máy chủ, ứng dụng web, hoặc các thành phần khác của một hệ thống không được thực hiện một cách an toàn và chính xác. Điều này có thể dẫn đến việc để lộ thông tin nhạy cảm, truy cập trái phép vào dữ liệu hoặc hệ thống, hoặc mở ra cánh cửa cho các cuộc tấn công khác.
Các lỗ hổng Security Misconfiguration có thể xảy ra trong nhiều khía cạnh của một ứng dụng web, bao gồm cau hình máy chủ, câu hình ứng dụng, cấu hình cơ
sở dữ liệu, và câu hình bảo mật. Dưới đây là một số ví dụ:
e Một tổ chức sử dụng một ứng dụng web mã nguồn mở. Ứng dụng nay sử
dụng một khóa bí mật được đặt mặc định trong tệp cầu hình. Khi triển khai ứng dụng này, khóa bí mật không được thay thế mà lại được sử dụng mặc định như trong câu hình. Điều này khiến tin tặc biết được khóa bí mật đang
sử dụng, từ đó tái tạo lại được một phiên đăng nhập hợp lệ và có thể truy
cập trái phép ứng dụng này.
e Giả sử ứng dụng web cho phép người dùng đưa đữ liệu đầu vào với dang
dit liệu XML. Nếu ứng dụng không kiểm tra và hạn chế các XML external entity, kẻ tan công có thể chèn và khiến máy chủ thực thi những XML ex- ternal entity mà tin tặc muốn. Điều này dẫn đến tin tặc có thể khai thác đọc tệp tùy ý, giả mạo yêu cầu phía máy chủ (Server-Side Request Forgery) và tấn công từ chối dịch vụ.
Để ngăn chặn lỗ hổng Security Misconfiguration, ta có thể thực hiện các biện
pháp sau:
* Cấu hình an toàn: Kiểm tra và cấu hình hệ thống, máy chủ và các thành
phần khác theo các hướng dẫn và hạn chế bảo mật của nhà cung cấp. Loại
bỏ hoặc tắt các tính năng không cần thiết và mặc định không an toàn.
¢ Kiểm tra và sửa lỗi cấu hình mặc định: Đảm bảo rằng cấu hình mặc định
của các thành phần, khung (frameworks) và thư viện được sử dụng trong ứng dụng web đã được điều chỉnh và cấu hình an toàn.
28
Chương 3. Cơ sở lý thuyết
* Cập nhật và bảo trì: Theo dõi và áp dung các bản vá bảo mật mới nhất cho
hệ điều hành, phần mềm máy chủ, các thành phần và khung sử dụng trong
ứng dụng web.
© Xóa thông tin debug (thông tin trong lúc chạy ở chế độ sửa lỗi): Loại bỏ các
thông tin debug hoặc chế độ xem xét của ứng dung web trước khi triển khai
nó vào môi trường thực tế.
e Chỉ cung cấp quyền hạn cần thiết: Đảm bảo rằng các quyền va khả năng
truy cập của người dùng và các thành phần khác được thiết lập chính xác
và hạn chế. Hạn chế quyền truy cập đến các chức năng quản trị và các tài
nguyên nhạy cảm.
® Kiểm tra và xác minh bảo mật: Thực hiện kiểm tra bảo mật thường xuyên
để xác định các cầu hình không an toàn và điều chỉnh chúng một cách kịp
thời.
3.2.6 Vulnerable and Outdated Components
Vulnerable and Outdated Components (Các thành phan dé tổn thương và đã lỗi thời) là mối nguy bảo mật phát sinh khi ứng dụng sử dụng các thành phần bên thứ ba (thư viện, khung, trình cắm (plugin), mô-đun, ...) có lỗ hổng đã được công
bồ hoặc đã lỗi thời. Việc sử dung các thành phan này có thể tạo điểm yếu cho ứng dụng, cho phép kẻ tấn công tìm thấy và khai thác các lỗ hổng đã được biết đến
để thâm nhập vào hệ thống.
Ví dụ, nếu một ứng dụng web sử dụng một phiên bản cũ của một plugin phổ biến, phiên bản đó có một lỗ hổng bảo mật đã được công bó. Kẻ tấn công có thể tìm ra và tận dụng lỗ hổng này để tấn công và xâm nhập vào hệ thống. Như vậy, việc sử dụng thành phần lỗi thời hoặc có lỗ hổng có thể tao ra một mồi nguy rủi
ro đáng kể cho ứng dụng.
Để giảm thiểu mối nguy Vulnerable and Outdated Components, có một số biện
pháp sau:
© Theo dõi các cập nhật bảo mật: Thường xuyên cập nhật các thành phần bên
thứ ba của ứng dụng, bao gồm các khung, thư viện, plugin và mô-đun. Đảm
29
Chương 3. Cơ sở lý thuyết
bảo rằng bạn theo đõi các thông báo về lỗ hổng bảo mật va cập nhật ngay
khi có các bản vá bảo mật được phát hành.
¢ Sử dụng công cụ quản lý thành phan: Sử dụng các công cu quản lý thành
phan (component management tools) để theo déi và kiểm soát việc sử dụng các thành phần bên thứ ba trong ứng dụng. Công cụ này giúp xác định các thành phần có lỗ hổng hoặc đã lỗi thời và cung cấp khả năng tự động cập
nhật.
© Đánh giá rủi ro: Tiến hành kiểm tra và đánh giá rủi ro cho các thành phan
bên thứ ba được sử dụng trong ứng dụng. Điều này giúp xác định và ưu tiên các thành phần có lỗ hổng hoặc có nguy cơ cao để xử lý trước.
se Xây dựng chính sách quản lý thành phan: Xác định và áp dung các quy định
và quy trình cho việc sử dụng thành phần bên thứ ba trong ứng dụng. Đảm bảo rằng các thành phần được kiểm tra và cập nhật định kỳ, và có các quy trình để đảm bảo sự kiểm soát và tuân thủ.
Bằng cách áp dụng các biện pháp trên, người phát triển và quản lý ứng dụng có thể giảm thiểu rủi ro từ lỗ hổng Vulnerable and Outdated Components, bảo vệ ứng dung va dit liệu khỏi các cuộc tấn công dựa trên các thành phan đã biết.
3.2.7 Identification and Authentication Failures
Identification and Authentication Failures (Lỗi xác định va xác thực) là một lỗ hổng bảo mật phát sinh khi quá trình xác định và xác thực người dùng không được thực hiện đúng cách hoặc không đủ mạnh, dẫn đến việc kẻ tan công có thể
giả mạo hoặc xâm nhập vào tài khoản người dùng hợp pháp.
Một số ví dụ về lỗ hổng Identification and Authentication Failures bao gồm:
se Weak or Default Credentials (Mật khẩu yếu hoặc mặc định): Sử dụng mật
khẩu yếu hoặc mặc định như "123456" hoặc "admin" cho các tài khoản người dùng hoặc tài khoản quản trị của hệ thống, tạo điều kiện thuận lợi cho kẻ tấn công đoán được mật khẩu và xâm nhập vào hệ thống.
® Brute Force Attacks (Tan công dò mật khẩu): Kẻ tan công thử một loạt các
mật khẩu khác nhau cho một tài khoản người dùng nhằm tìm ra mật khẩu
30