10 điểm yếu bảo mật nghiêm trọng nhất trong ứng dụng web (phần 1)


top10webvul Theo thống kê gần đây của tổ chức uy tín Gartner Group, đến 75% các cuộc tấn công thành công hiện nay dựa trên các lỗ hổng trong ứng dụng web.

Với xu thế phát triển nhanh chóng của ngành thương mại điện tử hiện nay, rất nhiều doanh nghiệp hiện đang sử dụng ứng dụng web để cung cấp dịch vụ thương mại trực tuyến, kết nối khách hàng, đối tác và nhân viên một cách hiệu quả nhất. Tuy nhiên, ứng dụng web cũng đem đến những rủi ro đáng kể mới đến an toàn của hệ thống và dữ liệu. Đa số ứng dụng web có thể bị những lỗi mà các phương cách phòng chống mạng thông thường không bảo vệ được. Lỗi và lỗ hổng trong mã nguồn của ứng dụng web có thể gây ra những hậu quả nghiêm trọng như lộ dữ liệu nhạy cảm, gây tổn thương đến toàn hệ thống hạ tầng CNTT. Sự cố bảo mật trong ứng dụng web có thể ảnh hưởng đến danh tiếng của công ty, mất mát về mặt tài chính, ảnh hưởng đến uy tín với khách hàng và các vấn đề liên quan đến ràng buộc pháp lý.

Khi một tổ chức triển khai trực tuyến một ứng dụng web, điều này đồng nghĩa với việc cho phép bất kỳ ai có kết nối Internet truy cập vào ứng dụng qua giao thức HTTP. Những cuộc tấn công nằm trong những truy cập HTTP này có khả năng vượt qua tường lửa, hệ thống lọc tầng mạng, các lớp bảo vệ hệ thống, và cả hệ thống phát hiện xâm nhập. Những thiết bị trên không thể phát hiện được những cuộc tấn công này vì các mã tấn công đều nằm trong các gói giao thức HTTP hợp lệ. Ngay cả những trang Web có mức độ bảo mật cao sử dụng SSL cũng đều cho phép tất cả các dữ liệu đi qua mà không hề kiểm tra tính hợp lệ của những dữ liệu này. Điều này có nghĩa là bảo mật ứng dụng Web là một nhân tố quan trọng nằm trong hệ thống phòng thủ ngọai vi, cùng với tường lửa và các thiết bị bảo mật khác.

Với tầm quan trọng ngày càng tăng của việc bảo vệ bảo mật cho các trang web trực tuyến, dự án mở bảo mật ứng dụng web (OWASP) được thành lập nhằm giúp các tổ chức hiểu thêm và tăng cường bảo mật cho ứng dụng và các dịch vụ web. Tổ chức OWASP đã có các thống kê về các cuộc tấn công và thiết lập một danh sách các điểm yếu nghiêm trọng nhất. Trong phạm vi của bài viết này, chúng tôi muốn giới thiệu danh sách 10 điểm yếu nghiêm trọng nhất được chọn lọc bởi dự án OWASP. Hiểu được những điểm yếu này là một trong những bước đầu tiên trong việc triển khai các phương pháp phòng chống.

top10webvul-01
Sơ đồ 0.0: Các tấn công qua cổng 80 (giao thức HTTP) không được phát hiện bởi tường lửa mạng

Danh sách 10 lỗ hổng hàng đầu:

Bảng thống kê dưới đây tóm tắt những lỗ hổng nghiêm trọng nhất của ứng dụng Web hiện nay. Mỗi lỗ hổng sẽ được bàn cụ thể thêm trong các phần kế tiếp.

Những lỗ hổng hàng đầu trong ứng dụng Web

Điểm yếu

Tóm tắt

A1

Dữ liệu đầu vào không được kiểm tra

Thông tin và dữ liệu từ các truy cập HTTP không được kiểm tra trước khi được sử dụng bởi ứng dụng web. Tin tặc có thể tận dụng những lỗi này nhằm tấn công các lớp ứng dụng phía sau thông qua ứng dụng web.

A2

Lỗi kiểm soát truy cập nguồn tài nguyên

Những giới hạn về quyền truy cập tài nguyên của người sử dụng không được thi hành đúng. Tin tặc có thể tận dụng những lỗi này nhằm truy cập vào tài khoản của người khác, xem các tập tin nhạy cảm, hoặc thi hành những chức năng không cho phép.

A3

Lỗi liên quan đến quá trình quản lý xác thực và phiên truy cập.

Quá trình xác thực và quản lý phiên truy cập không được bảo vệ tốt có thể dẫn đến việc thông tin tài khoản bị mất cắp.

A4

Lỗi Cross Site Scripting (XSS)

Ứng dụng web có thể được sử dụng như một cơ chế để chuyên chở tấn công đến trình duyệt của người sử dụng. Một cuộc tấn công thành công có thể sẽ làm lộ token của người dùng, tấn công máy đầu cuối, hoặc giả nội dung nhằm đánh lừa người sử dụng.

A5

Lỗi tràn bộ đệm

Một số module của ứng dụng Web khi được phát triển bằng những ngôn ngữ không kiểm tra dữ liệu đầu vào có thể bị crashed, và trong một số trường hợp, có thể bị lợi dụng để chiếm đoạt quyển kiểm soát của một process hoặc toàn bộ máy chủ. Những module này có thể bao gồm CGI, thư viện, drivers, và những module của máy chủ.

A6

Lỗi Injection

Ứng dụng web có thể sử dụng các dữ liệu đầu vào làm tham số cho các hàm gọi vào hệ thống. Nếu tin tặc nhúng các mã nguy hiểm trong dữ liệu đầu vào, hệ thống có thể chạy các đoạn mã nguy hiểm này.

A7

Quy trình quản lý báo lỗi

Những lỗi thông thường không được xử lý phù hợp. Nếu một tin tặc gây ra một lỗi mà ứng dụng không xử lý, họ có thể xem được thông tin về hệ thống, lợi dụng tấn công từ chối dịch vụ, làm cơ chế bảo mật thất bại, hoặc crash máy chủ.

A8

Lưu trữ thiếu an toàn

Những ứng dụng web hay sử dụng các hàm giải thuật mã hóa nhằm bảo vệ an toàn cho dữ liệu. Tuy nhiên những hàm này và các mã nguồn có thể có nhiều lỗi do lập trình viên bất cẩn, dẫn đến việc lộ thông tin quan trọng.

A9

Tứ chối dịch vụ

Tin tặc có thể tấn công làm tê liệt ứng dụng web, không cho phép người dùng truy cập ứng dụng.

A10

Quản lý cấu hình thiếu an toàn

Cầu hình an toàn cho máy chủ là một yếu tố quan trọng trong quy trình bảo vệ bảo mật cho ứng dụng web.

A1. Dữ liệu đầu vào không được kiểm tra tính hợp lệ

Ứng dụng Web sử dụng dữ liệu đầu vào trong các truy cập HTTP (hoặc trong các tập tin) nhằm xác định kết quả phản hồi. Tin tặc có thể sửa đổi bất kỳ phần nào của một truy xuất HTTP, bao gồm URL, querystring, headers, cookies, form fields, và thậm chí field ẩn (hidden fields), nhằm vượt qua các cơ chế bảo mật. Các tấn công phổ biến dạng này bao gồm:

  • Chạy lệnh hệ thống tùy chọn
  • Cross site scripting
  • Lỗi tràn bộ đệm
  • Tấn công Format string
  • SQL injection
  • Cookie poisoning
  • Sửa đổi field ẩn

Một số Web site bảo vệ chống lại loại tấn công này bằng cách thiết lập bộ lọc dữ liệu đầu vào. Vấn đề nan giải là có rất nhiều cách để mã hóa (encode) dữ liệu, và những phương cách mã hóa này không giống như các cách mã hóa thông thường khác ở chỗ là nó dễ dàng được giải mã. Tuy vậy, những nhà lập trình viên thường quên giải mã tất cả các tham số trước khi sử dụng chúng. Tham số cần phải được chuyển đổi đến dạng đơn giản nhất trước khi được kiểm tra, nếu không, dữ liệu xấu đầu vào có thể được mã hóa ẩn và vượt qua tầng bảo vệ của các module kiểm tra dữ liệu.

Một số lượng lớn ứng dụng chỉ sử dụng các cơ chế lọc phía trình duyệt để kiểm tra dữ liệu đầu vào. Các cơ chế kiểm tra phía trình duyệt rất dễ dàng được vượt qua, và ứng dụng web xem như không được bảo vệ bởi cơ chế này. Tin tặc có thể tạo ra các truy xuất HTTP không thông qua trình duyệt bằng cách sử dụng các công cụ như telnet, truy xuất thẳng đến cổng 80 của máy chủ web. Kiểm tra dữ liệu ở phía máy trình duyệt có lợi điểm về hiệu suất và tính dễ sử dụng, tuy nhiên cơ chế này không cung cấp bất cứ lợi điểm gì về bảo mật. Kiểm tra dữ liệu ở phía server đóng vai trò thiết yếu trong việc ngăn cản những cuộc tấn công dạng sửa đổi tham số đầu vào. Khi các cơ chế bảo vệ ở server đã được thiết lập, cơ chế bảo vệ phía trình duyệt có thể được sử dụng nhằm giảm bớt dung lượng các dữ liệu không hợp lệ đến máy chủ.

Sơ đồ 1.0 mô tả phương cách phổ biến của hacker hiện nay sử dụng để tấn công ứng dụng web. Trước tiên, hacker thiết lập một proxy đứng giữa trình duyệt và máy chủ ứng dụng web. Proxy này có khả năng chặn các gói dữ liệu trước khi chuyển đến máy chủ, do đó cho phép hacker sửa đổi dữ liệu truy cập và chèn các mã tấn công trước khi gửi đến ứng dụng web.

Những cuộc tấn công dạng này đang có xu hướng ngày càng phổ biến hơn do số lượng các công cụ hỗ trợ các chức năng tạo tham số bất kỳ, tạo mã tấn công, tấn công brute force đang ngày càng tăng. Hậu quả cuộc việc sử dụng các tham số không được kiểm tra không nên được xem nhẹ. Một số lượng lớn các cuộc tấn công sẽ gây khó khăn cho nhà lập trình web nếu họ không có một hệ thống tập trung kiểm tra tính hợp lệ của tất cả các truy xuất HTTP.

Các công cụ proxy dùng cho mục đích đánh giá bảo mật ứng dụng web:

top10webvul-2
Sơ đồ 1.0: Sử dụng local proxy để thay đổi tham số

A2 Lỗi kiểm soát truy cập nguồn tài nguyên

Kiểm soát truy cập tài nguyên (authorization), là cơ chế mà ứng dụng web cho phép truy cập đến nội dung, tính năng ứng dụng cho một số người sử dụng và từ chối truy cập cho một số người sử dụng khác. Những kiểm tra này được thực hiện sau quá trình xác thực, và quản lý các quyền truy cập mà người sử dụng được phép. Kiểm soát truy cập bề ngoài tưởng chừng là một vấn đề đơn giản nhưng thực tế là một vấn đề rất khó được thi hành đầy đủ. Một mô hình quản lý truy cập tài nguyên cho ứng dụng web cần được thiết kế theo sát các nội dung và hàm chức năng của một web site cung cấp.

top10webvul-3

Sơ đồ 2.0: mô tả một mô hình quản lý kiểm soát truy cập nguồn tài nguyên trung tâm

Để mô tả rõ hơn về lỗi bảo mật này, chúng tôi đưa ra một ví dụ về một dạng tấn công vào trang web portal cho một công ty cung cấp dịch vụ trực tuyến cho các thuê bao điện thoại di động. Thường thì loại web portal này cung cấp cho người sở hữu thuê bao một tài khoản trên trang web và cung cấp các dịch vụ sau:

  • Cho phép mỗi người sử dụng được phép gửi 5 tin nhắn không tốn tiền đến các thuê bao cùng mạng.
  • Cho phép người sử dụng được upload sổ địa chỉ cá nhân lên trang web và dowload khi có nhu cầu.
  • Cho phép người sử dụng được xem lịch sử cuộc gọi của máy thuê bao

Nếu cơ chế kiểm soát quyền sử dụng dịch vụ trên bị lỗi, hacker có thể có các tấn công sau:

  • Sửa đổi các tham số về số lượng giới hạn tin nhắn và có thể gửi hơn 5 tin nhắn cho phép không tốn tiền mỗi ngày.
  • Truy cập vào sổ địa chỉ của thuê bao khác.
  • Xem được lịch sử cuộc gọi của các thuê bao khác.

Những nhà lập trình viên thường không đánh giá được mức độ khó khăn trong việc xây dựng một cơ chế quản lý kiểm soát truy cập dữ liệu. Đa số những chức năng này không đựơc thiết kế từ lúc đầu mà được xây dựng kèm theo tùy tính năng của ứng dụng. Vì vậy, các chức năng kiểm soát được xây dựng ở khắp các module khác nhau trong mã nguồn. Khi ứng dụng được phát triển xong và đưa và triển khai, các mã kiểm soát này sẽ trở nên không thống nhất và gây ra nhiều lỗ hổng nghiêm trọng khó phát hiện được.

Theo vietshield.com

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s