Top 10 lỗ hổng OWASP

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

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/

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

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';";

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

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

Data Flow &

Process Flow

Diagram

4 Generation

Botnet

Threats Identification

HINH 3.3: Threat Modeling

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.

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

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

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.

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:

thứ ba của ứng dụng, bao gồm các khung, thư viện, plugin và mô-đun. Đảm

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.

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

Quá trình tìm kiếm lỗ hổng bảo mật