Một số dạng tấn công khiếm khuyết thiết kế

Một phần của tài liệu Bài giảng an toàn ứng dụng web và cơ sở dữ liệu (Trang 55 - 58)

2.5.2.1. Lạm dụng lưu trình xử lý

Lƣu trình xử lý (workflow) thƣờng gồm một tập các bƣớc, hoặc yêu cầu theo một trật tự xác định trƣớc. Lƣu trình xử lý có thể bị làm dụng theo nhiều cách khác nhau, nhƣ nhập thẻ giảm giá (coupon) nhiều lần để đƣợc giảm giá nhiều hơn, thậm chí giá âm nếu website có lỗi. Kẻ tấn công có thể thử website rất kỹđể tìm ra lỗi trong lƣu trình xử lý và lạm dụng. Một số dạng lạm dụng lƣu trình xửlý thƣờng gặp:

- Đổi yêu cầu từ POST sang GET hoặc ngƣợc lại đểthay đổi cách xử lý; - Bỏqua các bƣớc xác thực hoặc kiểm tra tính hợp lệ của dữ liệu;

- Lặp đi lặp lại một bƣớc hoặc 1 tập các bƣớc xử lý; - Thực hiện các bƣớc không theo trật tự thiết kế;

- Thực hiện các hành động mà "ngƣời dùng thƣờng không làm vì chúng không có nghĩa".

2.5.2.2. Khai thác các lỗi trong chính sách và áp dụng

Các chính sách (policy) định nghĩa các tài sản (asset) cần đƣợc bảo vệ thế nào và các thủ tục (procedure) đƣợc thực thi thế nào. Thực tế, một website tuân thủ chặt chẽ các chính sách bảo mật vẫn có thể không an toàn do có lỗi trong chính sách và áp dụng chính sách (pratice). Việc khai thác các lỗi trong chính sách và áp dụng thƣờng không liên quan đến các lỗi kỹ thuật, lỗi lập trình, lỗi cấu hình, hoặc lỗi quản trị.

Một ví dụ điển hình về khai thác các lỗi trong chính sách là việc khai thác kẽ hở của chính sách giới hạn các giao dịch có giá trị lớn. Để hạn chế các hoạt động tội phạm và rửa tiền, chính phủ Mỹ yêu cầu tất cả các tổ chức tài chính ngân hàng phải lƣu lại các giao dịch có giá trị từ 10.000 USD trở lên để xem xét các hoạt động khả nghi. Để vƣợt qua việc bị giám sát và phát hiện, kẻ tội phạm có thể chỉ chuyển 9.800 USD (hoặc số tiền nhỏ hơn 10.000 USD) và chuyển nhiều lần từ các địa điểm khác nhau để tránh giới hạn trên.

Một trƣờng hợp khác về khai thác các lỗi trong chính sách là việc khai thác lỗ hổng trong chính sách bảo hành sản phẩm của hãng Apple (Mỹ). Năm 2008, một ngƣời đàn ông đã bị kết tội lừa đảo do lấy hơn 9000 máy Ipod Shuffles của hãng Apple. Cụ thể, Apple thực hiện chính sách cho phép khách hàng nhanh chóng đổi một máy Ipod bị lỗi lấy một máy mới trƣớc khi Apple nhận đƣợc và xử lý máy bị lỗi. Chính sách có đoạn ―You will be asked to provide a major credit card to secure the return of the defective accessory. If you do not return the defective accessory to Apple within 10 days of when we ship the replacement part, Apple will charge you for the replacement‖. Kịch bản lạm dụng chính sách của Apple để đánh cắp máy Ipod nhƣ sau:

55 - Kẻ lạm dụng sử dụng một thẻ tín dụng có hạn mức thấp và gửi yêu cầu đổi máy

Ipod lỗi và cung cấp thông tin thẻđểđảm bảo;

+ Hệ thống Apple kiểm tra thông tin thẻ và xác nhận thông tin hợp lệ (do hệ thống không kiểm tra hạn mức và thanh toán tại thời điểm này), nên yêu cầu đổi máy đƣợc duyệt.

+ Trong thời gian 10 ngày, máy lỗi không đƣợc gửi đến hãng, nhân viên Apple thực hiện trích tiền từ thẻ thì không thực hiện đƣợc do thẻ không còn tiền.

Kết quả, kẻ lạm dụng bán máy Ipod chiếm đoạt và thu đƣợc số tiền 75.000 USD.

2.5.2.3. Các mẫu thiết kế không an toàn

Các mẫu thiết kế không an toàn bao gồm một số vấn đề: các hành vi mơ hồ, không xác định và bất ngờ; kiểm tra cấp quyền không đầy đủ; lọc dữ liệu không đầy đủ; trộn lẫn dữ liệu và mã; chuẩn hóa sai và cú pháp đồng nghĩa; và tin tƣởng vào bên máy khách.

a. Các hành vi mơ hồ, không xác định và bất ngờ

Một ứng web là một hệ sinh thái gồm một tập các công nghệ, chuẩn & cài đặt và sự kết hợp giữa chúng có thể dẫn đến những kết quả không ngờ, ngay cả trong trƣờng hợp các công nghệđƣợc cài đặt theo các chuẩn. Ví dụ, với chuỗi truy vấn (query string) trên URL của trang web sau:

Kẻ tấn công có thể lạm dụng các tham số bằng cách lặp lại giá trị 1 tham số:

Khi tham số bị lặp, hệ thống có thể xử lý sai do giá trị thực sựđƣợc xửlý là mơ hồ, không xác định. Kẻ tấn công có thể sử dụng các kỹ thuật này nhƣ trong các URL mẫu sau để vƣợt qua các bộ lọc:

b.Kiểm tra cấp quyền không đầy đủ

Việc kiểm tra quyền truy nhập cần đƣợc thực hiện đầy đủ trên mỗi yêu cầu truy nhập. Nếu việc kiểm tra quyền truy nhập chỉ thực hiện một lần tại bƣớc đăng nhập, hoặc xác thực là không đủ và có thể bị lạm dụng. Chẳng hạn, kịch bản sau mô tả việc khai thác lỗi không kiểm tra quyền truy nhập trên mỗi yêu cầu truy nhập:

- Một ngƣời dùng A ban đầu đƣợc cấp quyền quản trị (administrator), đƣợc phép truy nhập vào tất cả các tài nguyên trong hệ thống.

56 - Việc xác định danh sách quyền truy nhập của ngƣời dùng đƣợc thực hiện một lần mỗi phiên khi ngƣời dùng đăng nhập, sau đó danh sách quyền các truy nhập đƣợc đƣa vào 1 bảng và việc kiểm tra đƣợc thực hiện trên bảng mỗi khi có yêu cầu truy nhập.

- Vì lý do nào đó, mà ngƣời dùng A bị hủy quyền quản trị và chuyển thành ngƣời dùng bình thƣờng với quyền truy nhập hạn chếhơn.

+ Với cơ chế kiểm tra nêu trên và nếu ngƣời dùng A vẫn đang ở phiên làm việc bắt đầu từ trƣớc khi anh ta bị hủy quyền quản trị, A vẫn có quyền quản trị cho đến khi anh ta kết thúc phiên làm việc.

c. Lọc dữ liệu không đầy đủ

Việc lọc dữ liệu đầu vào là bắt buộc và khuyến nghị sử dụng các bộ lọc dữ liệu do các hãng lớn phát triển và duy trì. Các bộ lọc do các cá nhân tựcài đặt thƣờng không đầy đủ, để lọt nhiều từ khóa, hoặc không lọc đƣợc các tấn công tinh vi. Chẳng hạn, một bộ lọc lọc bỏ tất cả các từ "script" vẫn để lọt chuỗi tấn công XSS sau:

Do sau khi lọc bỏ "script", chuỗi trên trở thành:

Chuỗi sau giải mã trở thành /?param="<<script src=/site/a.js> chứa mã JavaScript trỏđến file chứa mã script a.js.

Một điểm cần nhấn mạnh là việc lọc dữ liệu phải đƣợc thực hiện cả bên máy khách và bên máy chủ, do việc lọc dữ liệu bên khách chỉ giải quyết vấn đề hiệu năng, giảm tải cho máy chủ, không giải quyết đƣợc vấn đề an ninh.

d.Trộn lẫn dữ liệu và mã

Việc trộn lẫn dữ liệu và mã thƣờng bị lợi dụng để thực hiện tấn công. Điển hình là tấn công chèn mã SQL và XSS: mã tấn công đƣợc trộn lẫn với dữ liệu để chuyển cho máy chủ thực hiện. Có nhiều ngôn ngữ, hoặc công cụ bị tổn thƣơng khi xử lý dữ liệu trộn mã, nhƣ Apache Struts, XPath, LDAP và JSON.

e. Chuẩn hóa sai và cú pháp đồng nghĩa

Đểtăng hiệu quả các bộ lọc, dữ liệu cần đƣợc chuẩn hóa đầy đủ trƣớc khi đƣa vào các bộ lọc. Nhiều trƣờng hợp, các cụm từ, hoặc chuỗi đồng nghĩa về ngữ pháp nhƣng không cùng ngữ nghĩa trong ngữ cảnh đƣợc thực hiện. Chẳng hạn, sau đây là các ví dụ về các chuỗi cùng tham chiếu đến file /etc/hosts và các dạng tạo cặp từ khóa UNION SELECT:

f. Tin tƣởng vào bên máy khách

57 Tin tƣởng tuyệt đối vào bên máy khách là một trong các sai lầm cơ bản trong vấn đề đảm bảo an ninh của các website. Việc kiểm tra dữ liệu bằng JavaScript bên trình duyệt, hay máy khách chỉ có thể giúp giảm tải cho máy chủ, không đảm bảo dữ liệu luôn đƣợc kiểm tra đảm bảo vấn đề an ninh, do mã JavaScript bên trình duyệt có thể bị bỏ qua dễ dàng bằng cách tắt tính năng cho chạy JavaScript trên trình duyệt. Hơn nữa, các thành phần bí mật nhúng trong trang web có thể bị giải mã và lấy tƣơng đối dễ dàng. Do vậy, việc kiểm tra, hay lọc dữ dữ liệu phải đƣợc thực hiện trên máy chủ.

2.5.2.4. Các lỗi cài đặt hệ mã hóa

Việc cài đặt các hệ mã hóa có thể phát sinh một số lỗ hổng bảo mật do các yêu cầu đối với các tham số và bản thân thuật toán mã hóa không đƣợc đảm bảo chặt chẽ. Một trong các vấn đề thƣờng gặp nhất cài đặt các hệ mã hóa là không tạo đƣợc số ngẫu nhiên thực sự trong khi thuật toán mã hóa đòi hỏi sử dụng các số ngẫu nhiên. Sở dĩ có điều này là do hàm tạo số ngẫu nhiên cung cấp bới các thƣ viện ngôn ngữ lập trình chỉ là giả ngẫu nghiên (Psudo-radom). Hậu quả là, số không thực sự ngẫu nhiên sẽ dễ bị đoán, hoặc bị vét cạn nếu phạm vi giá trịkhông đủ lớn.

Một lỗi khác trong cài đặt các hệ mã hóa là sử dụng các phƣơng pháp, hoặc các giải thuật mã hóa cũ, yếu và chúng dễ dàng bị phá. Chẳng hạn phƣơng pháp mã hóa XOR không đƣợc khuyến kích sử dụng do phƣơng pháp nàyđơn giản, dễ bị phá.

Một phần của tài liệu Bài giảng an toàn ứng dụng web và cơ sở dữ liệu (Trang 55 - 58)

Tải bản đầy đủ (PDF)

(161 trang)