Viblo Security

IV. Lỗ hổng XSS với CSP (Content security policy)

1. Content Security Policy (CSP) là gì?

Content Security Policy (CSP) là một tính năng bảo mật web cho phép người quản trị trang web định cấu hình các nguồn tài nguyên cho phép tải và sử dụng trên trang web đó. Điều này có thể giúp ngăn chặn các cuộc tấn công XSS bằng cách không cho phép tài nguyên không đáng tin cậy được tải và sử dụng trên t...

II. Phân tích, phòng chống các lỗ hổng Reflected XSS và Stored XSS (tiếp)

Ở phần trước, hàm htmlspecialchars() đã bảo vệ trang web trước các ký tự nhạy cảm trong lỗ hổng XSS như <, >, ", ... Nhưng liệu nó đã thực sự an toàn?

Xét tình huống một trang web cho phép người dùng để lại tên tác giả, lời chúc cùng link contact được gán trong tên tác giả. Mã nguồn như sau:

Trang web đã sử dụng hàm ht...

II. Phân tích, phòng chống các lỗ hổng Reflected XSS và Stored XSS (tiếp)

Như chúng ta thấy lỗ hổng xảy ra do kẻ tấn công có thể inject mã độc javascript, nếu thực sự không cần thiết, chúng ta có thể kiểm tra và block các dữ liệu nhập từ người dùng chứa các tags và attributes javascript độc hại. Ý tưởng là có thể tạo ra một blacklist các tags và attributes. Ví dụ:

l>

<...

I. Đặt vấn đề

1. Các lỗ hổng Client-side

Trải qua hành trình dài với các lỗ hổng Server-side, từ chủ đề này trở đi Viblo sẽ cùng các bạn khám phá và phân tích các lỗ hổng Client-side. Khác với các lỗ hổng server-side xuất hiện trong phần mềm hoặc hệ thống máy chủ, lỗ hổng Client-side thường xảy ra tại chính trình duyệt của người dùng dẫn đến kẻ tấn công có thể tiếp cận, truy cập dữ liệu không...

II. Phân tích và khai thác các lỗ hổng XXE injection (tiếp)

8. Tấn công XInclude khai thác lỗ hổng XXE

Một số trang web không trực tiếp nhận dữ liệu XML từ người dùng, mà nhúng các dữ liệu người dùng vào document XML. Điều này khiến kẻ tấn công không thể chỉnh sửa payload XML theo mong muốn.

Ví dụ khi dữ liệu do người dùng gửi được hệ thống kết hợp vào một SOAP backend request, sau đó được x...

II. Phân tích và khai thác các lỗ hổng XXE injection (tiếp)

6. Khai thác lỗ hổng XXE qua error message

Trong một số trường hợp khi chúng ta sử dụng sai cú pháp XML dẫn đến quá trình phân tích cú pháp dữ liệu gặp lỗi, lúc này hệ thống thường trả về các đoạn thông báo lỗi (error message), chúng có thể chứa một số thông tin nhạy cảm.

Bằng cách đưa luồng xử lý hệ thống đi vào trường hợp error, c...

II. Phân tích và khai thác các lỗ hổng XXE injection (tiếp)

5. Khai thác lỗ hổng Blind XXE injection bằng phương pháp truy xuất dữ liệu out-of-band

Ở các mục trước chúng ta đã được giới thiệu và nhận biết lỗ hổng Blind XXE injection. Tất nhiên kẻ tấn công sẽ không muốn chỉ dừng lại ở mức kiểm tra được vị trí xảy ra lỗ hổng XXE dạng blind. Họ luôn tìm kiếm cách truy xuất các dữ liệu nhạy cảm. ...

II. Phân tích và khai thác các lỗ hổng XXE injection (tiếp)

3. Lỗ hổng XXE injection dạng Blind và cách nhận biết

Cũng giống như các lỗ hổng khác, nhiều trường hợp trang web chứa quá trình phân tích cú pháp XML nhưng không trả về kết quả trong giao diện ứng dụng. Khi đó lỗ hổng XXE vẫn có thể xảy ra nhưng ở dạng blind, hay còn được gọi là Blind XXE injection.

Ví dụ đoạn code PHP sau:

II. Phân tích và khai thác các lỗ hổng XXE injection (tiếp)

2. Khai thác lỗ hổng XXE injection kết hợp lỗ hổng SSRF

Chúng ta đã biết về lỗ hổng SSRF giúp kẻ tấn công có thể truy xuất các dữ liệu nội bộ phía server. Trong một số trường hợp, ứng dụng chứa lỗ hổng XXE có thể kết hợp với phương pháp tấn công SSRF nhằm mở rộng phạm vi tấn công, khiến sự ảnh hưởng và mức độ tổn hại phía server tăng...

I. Đặt vấn đề

1. Các khái niệm cơ bản

a. XML là gì?

XML là viết tắt của eXtensible Markup Language. Khá giống với ngôn ngữ HTML, chúng ta có thể hiểu XML là một dạng ngôn ngữ đánh dấu, được tổ chức W3C phát triển với mục đích lưu trữ và vận chuyển dữ liệu.

Tuy nhiên, chúng ta cũng cần phân biệt giữa hai ngôn ngữ HTML và XML, với các tiêu chí chủ yếu sau:

Chúng ta cùng xét một ví dụ về ngôn...

II. Phân tích và khai thác các lỗ hổng Server-side request forgery (tiếp)

9. Lỗ hổng SSRF trong open redirection (chuyển hướng)

Trong một số trường hợp các chức năng chuyển hướng cũng có thể gây ra lỗ hổng SSRF. Chẳng hạn ứng dụng web gọi tới API thực hiện chuyển hướng người dùng tới một trang web khác, có URL như sau:

/product/nextProduct?currentProductId=6&path=http://evil-user.net

Trang ...

II. Phân tích và khai thác các lỗ hổng Server-side request forgery (tiếp)

8. Lỗ hổng SSRF dạng Blind

Cũng giống với các dạng lỗ hổng blind khác, lỗ hổng Blind SSRF xảy ra khi giao diện không trả về bất kỳ thông tin nào về kết quả cuộc tấn công SSRF, nhưng payload của chúng ta vẫn được thực thi trong server back-end. Trong trường hợp giao diện trang web không trả về kết quả, cách thông dụng nh...

II. Phân tích và khai thác các lỗ hổng Server-side request forgery (tiếp)

6. SSRF và bypass white-based input filters (tiếp)

6.2. Cài đặt cơ chế ngăn chặn white list dựa theo host (tiếp)

Cuối cùng, chúng ta hãy cùng đào sâu hơn một cách bypass cơ chế filter bằng cách kết hợp các kỹ thuật trên qua bài lab sau:

Phân tích lab SSRF with whitelist-based input filter

Miêu tả: Chức năng stock che...

II. Phân tích và khai thác các lỗ hổng Server-side request forgery (tiếp)

5. Kiểm tra lỗ hổng SSRF

SSRF thường xuất hiện ở các chức năng có quá trình trao đổi dữ liệu với một trang web khác. Và chúng ta cũng cần có một phương pháp để kiểm tra khả năng xảy ra của lỗ hổng SSRF. Một trong những phương pháp kiểm tra phổ biến và đơn giản nhất chính là kỹ thuật out-of-band (OAST). Trong bài viết nà...

II. Phân tích và khai thác các lỗ hổng Server-side request forgery (tiếp)

3. Lỗ hổng SSRF truy cập hệ thống back-end khác

Bên cạnh việc tận dụng lỗ hổng SSRF truy cập vào server local, chúng ta cũng có thể truy cập vào các hệ thống back-end khác. Các hệ thống này thường không thể truy cập trực tiếp từ public server, để tấn công được các server này chúng ta cần biết chính xác domain hoặc địa c...

I. Đặt vấn đề

1. Giới thiệu

Server-side request forgery (thường được gọi là SSRF) là một dạng tấn công trong đó kẻ tấn công lợi dụng một tính năng của server public nhằm truy xuất trái phép dữ liệu từ một trang web chỉ định khác, thường là các trang web back-end ở chính server đó. Để các bạn có thể hình dung rõ hơn về dạng lỗ hổng này, chúng ta cùng xét ví dụ sau:

Trong quá trình trao đổi dữ...

VI. Demo ngăn chặn lỗ hổng SQL injection

1. Ngôn ngữ PHP

Xem xét đoạn code PHP với cơ sở dữ liệu MySQL xử lý input chứa lỗ hổng SQL injection sau:

_POST['username']; _POST['password'];

username' AND password='$password'";

mysql_query($query);

• Sử dụng hàm htmlspecialchars()

Hàm htmlspecialchars() sẽ chuyển các ký tự đặc biệt như &, <, >, ", ', và / thành các ký tự HTML. Cài đặt như sau:...

IV. Tối ưu hóa Blind SQL injection

Trong các phương pháp khai thác lỗ hổng Blind SQL injection đã xét ở trên, chúng ta cần kiểm tra rất nhiều trường hợp (hầu như là cần thử qua hết tất cả trường hợp về ký tự) để xác định chính xác từng ký tự của dữ liệu cần truy xuất, làm mất rất nhiều thời gian cũng như lãng phí tài nguyên. Hơn nữa, việc gửi liên tục nhiều request cùng lúc tới hệ thống có thể...

II. Phân tích và khai thác các lỗ hổng SQL Injection (tiếp)

8. Second-order SQL injection

Các trường hợp ở trên chúng ta đang xét có thể được chia thành dạng First-order SQL injection - nghĩa là hệ thống sẽ trực tiếp thực thi script của chúng ta dẫn tới hậu quả dò rỉ dữ liệu ngay lập tức sau đó (trả về dữ liệu nhạy cảm trong giao diện, kẻ tấn công có thể phán đoán chính xác các ký tự của dữ l...

II. Phân tích và khai thác các lỗ hổng SQL Injection (tiếp)

6. Blind SQL injection (tiếp)

6.4. Khai thác lỗ hổng Blind SQL injection bằng out-of-band (OAST) techniques

Phương pháp tấn công lỗ hổng Blind SQL injection bằng kỹ thuật Out-of-band có thể còn xa lạ với nhiều bạn. Trước hết các bạn cần hiểu về dịch vụ phân giải tên miền DNS (có thể đọc lại các bài viết về chủ đề OS command injectio...