Viblo Security

I. Đặt vấn đề

1. Bối cảnh

Theo thời gian và nhu cầu, các dữ liệu hiển thị trên trang web không ngừng thay đổi. Ba yếu tố cơ bản nhất tạo nên một trang web là HTML, CSS, Javascript. Để thêm, sửa, xóa chức năng, dữ liệu, thay đổi bố cục giao diện dẫn đến lập trình viên cần chỉnh sửa toàn bộ source code - tiêu tốn tài nguyên, thời gian. Bởi vậy kỹ thuật template ra đời. Cách thức hoạt động cơ bả...

V. Phân tích, khai thác và ngăn chặn lỗ hổng CSRF với header Referer

1. Header Referer - ưu, nhược điểm

Trong các HTTP header có một header Referer ghi lại địa chỉ (địa chỉ nguồn) ngay trước khi browser truy cập tới địa chỉ hiện tại (địa chỉ đích). Thông thường, địa chỉ trước khi truy cập tới một chức năng nằm trong miền domain con của ứng dụng.

Ví dụ browser truy cập tới http://bank.example...

III. Phân tích, khai thác và ngăn chặn lỗ hổng CSRF với anti-CSRF token (tiếp)

4. Tấn công CSRF khi token không liên kết duy nhất với tài khoản

Về nguyên tắc, giá trị tham số CSRF token cần mang tính duy nhất và liên kết duy nhất với tài khoản. Một số chức năng thực tế có thể vi phạm nguyên tắc này, chẳng hạn, server lưu trữ session toàn bộ người dùng trong database để dễ quản lý (hoặc mục đí...

III. Phân tích, khai thác và ngăn chặn lỗ hổng CSRF với anti-CSRF token

1. Tạo payload tấn công CSRF

Chúng ta có thể tạo thủ công payload tấn công CSRF là một HTML form, kết hợp javascript tự động submit. Tuy nhiên, với các bạn sử dụng công cụ Burp Suite Professional có thể tận dụng trình tạo CSRF PoC tự động được tích hợp sẵn. Chúng ta cùng phân tích bài lab CSRF vulnerability with no defens...

I. Đặt vấn đề

1. Khái niệm lỗ hổng Cross-site request forgery (CSRF)

Lỗ hổng CSRF (Cross-site request forgery) còn được biết tới với tên One Click Attack hoặc Session Riding. Lỗ hổng cho phép kẻ tấn công đánh lừa browser của nạn nhân truy cập tới một endpoint (tại đây trang web đã xác thực danh tính nạn nhân) thực hiện các thao tác với mục đích xấu như: thay đổi địa chỉ email, mua bán sản phẩ...

V. Khai thác các lỗ hổng XSS (tiếp)

2. Khai thác XSS đánh cắp mật khẩu tự động điền (autofill)

Có phải các bạn đã từng gặp tình huống sau khi đăng nhập tài khoản ở một trang web nào đó và trình duyệt đã gợi ý việc lưu trữ mật khẩu?

Tính năng lưu trữ mật khẩu không chỉ giúp ích cho chúng ta tìm lại mật khẩu trong trường hợp bị quên sau thời gian dài, mà còn giúp chúng ta tự động điền (autofil...

V. Khai thác các lỗ hổng XSS

1. Khai thác XSS đánh cắp cookies người dùng

Việc đánh cắp cookies nạn nhân qua lỗ hổng XSS thường được kẻ tấn công sử dụng phổ biến. Với các ứng dụng web sử dụng cookies để duy trì phiên đăng nhập người dùng, kẻ tấn công có thể lợi dụng lỗ hổng XSS nhằm đánh cắp cookies nạn nhân gửi đến domain do họ sở hữu. Từ đó thay thế giá trị cookies nhằm mạo danh nạn nhân. T...

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