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


Monday, 26 February 2007

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.

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

Quản lý xác thực và phiên truy cập bao gồm tất cả các yếu tố quản lý xác thực người sử dụng và các phiên truy cập. Xác thực người dùng là một yếu tố quan trọng trong quy trình này, nhưng ngay cả những cơ chế xác thực mạnh nhất vẫn có thể bị mắc những lỗi liên quan đến các chức năng quản lý xác thực, bao gồm thay đổi password, quên password, nhớ password ở trình duyệt, cập nhật tài khỏan, và những hàm chức năng khác.

Xác thực người dùng trên ứng dụng web thường bao gồm sử dụng một username và password. Những phương pháp xác thực khác mạnh hơn bao gồm các giải pháp phần cứng hoặc mềm dựa trên các token mã hóa hoặc dùng phương pháp sinh trắc học (biometrics). Tuy nhiên những phương pháp này có phần hạn chế do giá thành cao. Một số lượng lớn lỗi ứng dụng trong các hàm quản lý tài khoản và phiên truy cập có thể dẫn đến mối nguy cơ lộ tài khỏan người sử dụng và thậm chí tài khỏan của người quản trị.

Ứng dụng web thường phải theo dõi và duy trì phiên truy cập của người dùng nhằm phân biệt các truy cập từ người dùng khác nhau. Giao thức HTTP không cung cấp khả năng này và do đó ứng dụng web phải tự tạo cơ chế này. Thường thì, môi trường phát triển ứng dụng cung cấp cơ chế quản lý phiên truy cập (thường là dưới hình thức cookie token), tuy nhiên, đa số các nhà lập trình nghiêng về phát triển cơ chế riêng của họ. Trong cả hai trường hợp, nếu token quản lý phiên truy cập không được bảo vệ, tin tặc có thể ăn cắp token truy cập tài khoản của người khác.

A4 Lỗi Cross Site Scripting (XSS)

Lỗi Cross-site scripting (thường được gọi tắt là XSS) xảy ra khi một ứng dụng web bị lợi dụng để gửi dữ liệu xấu (thường là đoạn mã script) đến trình duyệt của người sử dụng. Những lỗ hổng này rất phổ biến và xảy ra trong bất cứ phần nào của ứng dụng web có sử dụng dữ liệu từ người dùng trong các giá trị phản hồi mà không kiểm tra tính hợp lệ.

Một tin tặc có thể sử dụng lỗ hổng này để gửi các đoạn mã đến người dùng. Trình duyệt trong máy người dùng không thể biết được nên tin hay không tin đoạn mã nào, và sẽ thi hành đoạn script này. Bởi vì trình duyệt tin rằng đoạn mã đến từ một nguồn tin tưởng, đoạn mã script có thể truy cập đến cookies, session tokens, hoặc bất kỳ thông tin nhạy cảm nào được lưu lại trong trình duyệt có liên quan đến trang web đang truy cập. Những đoạn mã này còn có thể sửa đổi nội dung trang web.

Hậu quả của tấn công dạng XSS có thể rất nguy hiểm, bao gồm lộ session cookie, cho phép tin tặc chiếm quyền sở hữa tài khoản. Những hậu quả khác bao gồm: lộ các tập tin của người dùng, cài đặt các chương trình trojan, di chuyển người sử dụng đến trang web khác, sửa đổi nội dung trang web nhằm đánh lừa người dùng.

Sơ đồ 4.0 mô tả một ví dụ tấn công dạng cross site scripting với hậu quả là khách hàng bị lừa truy cập vào trang web giả mạo nhằm ăn cắp tài khoản khách hàng:

  1. Hacker phát hiện lỗ hổng cross-site-scripting trên trang web của một ngân hàng thật http://www.bank-that.com
  2. Hacker tạo một trang web trông giống ngân hàng thật tại địa chỉ http://www.bank-gia.com
  3. Hacker soạn một email giả từ nhân viên của ngân hàng gửi đến cho một khách hàng. Trong email, hacker soạn một nội dung yêu cầu khách hàng bấm vào một link trông giống như một link truy cập vào ngân hàng thật http://www.bank-that.com/dichvu.asp?url=http://www.bank-gia.com.
  4. Khách hàng nhận được email, tưởng là email từ phía ngân hàng thật, nên bấm vào link.
  5. Khi bấm vào link, thay vì truy cập vào ngân hàng thật, trình duyệt của khách hàng được chuyển tự động đến trang web ngân hàng giả do hacker tạo sẵn trông giống như ngân hàng thật http://bank-gia.com
  6. Khách hàng nhập thông tin đăng ký vào trang ngân hàng giả và thông tin này được chuyển đến hacker
top10webvul-4
Sơ đồ 4.0: Lỗi Cross-Site-Scripting

A5 Lỗi tràn bộ đệm

Tin tặc sử dụng lỗi tràn bộ đệm nhằm ảnh hưởng đến dòng lệnh thực thi của ứng dụng web. Bằng cách gửi một đoạn mã được thiết kế đặc biệt đến ứng dụng, tin tặc có thể làm cho ứng dụng web thi hành bất kỳ đoạn mã nào, điều này tương đương với việc chiếm quyền làm chủ máy server. Mặc dù là một lỗi phổ biến, lỗi tràn bộ đệm là loại lỗi rất khó được phát hiện và ngay cả khi đã được phát hiện, lỗi này rất khó được lợi dụng do tin tặc cần một trình độ rất cao để có thể viết đoạn mã khai thác.

Sơ đồ 5.0 mô tả một cuộc tấn công tràn bộ đệm, hacker gửi đến ứng dụng web một truy cập với gói dữ liệu có độ dài vượt mức cho phép mà hàm xử lý của ứng dụng có thể xử lý. Thông thường, dữ liệu đầu vào được lưu trữ trên bộ nhớ đệm trước khi xử lý, dữ liệu vượt quá độ dài đăng ký sẽ được chèn lên các dữ liệu quan trọng khác trong bộ đệm, dẫn đến khả năng thi hành mã tùy ý cho hacker.

top10webvul-5
Sơ đồ 5.0: Lỗi tràn bộ nhớ đệm

A6 Lỗi Injection

Lỗi injection cho phép tin tặc lợi dụng lỗ hổng trong ứng dụng web làm phương tiện để gửi các đoạn mã nguy hiểm đến hệ thống. Những cuộc tấn công dạng này bao gồm các mã gọi hàm đến hệ điều hành, gọi các ứng dụng qua lệnh shell, và các hàm gọi đến cơ sở dữ liệu (SQL injection). Những đoạn mã nguy hiểm được viết bằng perl, python và ngôn ngữ khác có thể được chuyển đến và thực thi bởi ứng dụng web, hệ điều hành hoặc các ứng dụng khác.

Rất nhiều ứng dụng web sử dụng các hàm của hệ điều hành và các chương trình ngoài để thi hành các chức năng. Sendmail là một trong những chương trình ngoài được sử dụng nhiều nhất. Khi ứng dụng web sử dụng dữ liệu từ người dùng để tạo ra đoạn mã thực thi, dữ liệu từ người dùng cần được lọc kỹ lưỡng. Nếu không, tin tặc có thể kèm vào các ký tự đặc biệt, đoạn lệnh, và những thông tin xấu này có thể được chuyển đến hệ thống và các chương trình ngoài.

Một trong những dạng phổ biến nhất của lỗi injection là lỗi “sql injection”. Lỗi này xảy ra khi ứng dụng sử dụng những dữ liệu đầu vào không được kiểm tra làm tham số để xây dựng chuỗi lệnh SQL. Bằng cách sử dụng những đoạn mã SQL đặc biệt, hacker có thể gây ra những hậu quả nghiêm trọng như:

  • Vượt qua hệ thống xác thực login mà không cần sử dụng password hoặc username
  • Truy cập vào một phần hoặc tất cả các thông tin trong CSDL
  • Lấy được thông tin về cấu trúc của cơ sở dữ liệu
  • Sửa đổi hoặc xóa thông tin trong CSDL
  • Chạy các lệnh trong hệ điều hành trên máy chủ CSDL

Sơ đồ 6.0 mô tả một cuộc tấn công lợi dụng lỗ hổng Injection. Trong tấn công này, do ứng dụng bị mắc lỗi SQL injection và đồng thời CSDL cho phép chạy các lệnh hệ thống. Hacker có thể nhúng các lệnh vào chuỗi lệnh SQL và thi hành lệnh hệ thống trên máy chủ.

top10webvul-6
Sơ đồ 6.0: Tấn công injection

A7 Quy trình xử lý báo lỗi

Quy trình xử lý báo lỗi có thể gây ra nhiều vấn đề bảo mật cho một trang web. Vấn đề thông thường nhất là khi các thông báo lỗi có chứa các thông tin nhạy cảm như stack traces, thông tin cơ sở dữ liệu, và các mã lỗi được thông báo cho người dùng. Những lỗi này cung cấp các thông tin về hệ thống, ứng dụng ở mức độ thấp và thông tin này phải được bảo mật. Sử dụng những thông tin này, hacker có thể dò tìm ra những lỗi khác của ứng dụng.

Đối với các thông báo lỗi SQL, hacker có thể dò được:

  • Tên và phiên bản phầm mềm cơ sở dữ liệu
  • Tên cơ sở dữ liệu
  • Tên bảng và các cột trong bảng

Nếu trang web bị mắc lỗi SQL Injection, các thông tin trên sẽ giúp cho hacker khai thác sâu hơn lỗi này và lấy được toàn bộ các thông tin trong cơ sở dữ liệu.

top10webvul-7
Hình 7.0: Thông báo lỗi SQL lộ thông tin

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

Đa số các ứng dụng web cần lưu trữ dữ liệu nhạy cảm, trong cơ sở dữ liệu hoặc trong một tập tin nào đó trong hệ thống. Thông tin nhạy cảm bao gồm: mật khẩu, số thẻ tín dụng, thông tin tài khoản, hoặc các thông tin cần bảo vệ khác. Các cơ chế mã hóa thường được sử dụng để bảo vệ những thông tin này. Mặc dù sử dụng các hàm mã hóa không khó cho các lập trình viên, tuy nhiên, lập trình viên vẫn thường mắc những lỗi cơ bản khi áp dụng vào ứng dụng web do không hiểu rõ hết các đặc điểm mã hóa. Những lỗi thông thường bao gồm:

  • Không mã hóa dữ liệu quan trọng như khóa, certificates và mật khẩu
  • Lưu trữ các khóa bảo mật trong bộ nhớ bằng các cơ chế không an toàn
  • Cơ chế tạo số ngẫu nhiên không đảm bảo
  • Sử dụng sai thuật toán
  • Tạo một thuật toán mã hóa không đảm bảo

Hậu quả của những điểm yếu này có thể rất nghiêm trọng đến an toàn của một trang web, cho phép hacker lấy được toàn bộ các thông tin quan trọng được lưu trữ.

A9 Từ chối dịch vụ

Ứng dụng web rất dễ bị tổn thương do các cuộc tấn công từ chối dịch vụ (DoS). Tấn công từ chối dịch vụ vào ứng dụng web được định nghĩa là các tấn công làm tê liệt ứng dụng, làm cho các truy cập hợp lệ không thể được tiến hành.

Đa số máy chủ web chỉ có thể xử lý hỗ trợ một số lượng nhất định người sử dụng trong điều kiện bình thường. Một tin tặc có thể tạo ra nhiều truy cập đồng thời từ một máy để tấn công ứng dụng. Sử dụng load balancing sẽ gây khó khăn cho các cuộc tấn công kiểu này, tuy nhiên không thể ngăn ngừa hoàn toàn nếu có quá nhiều truy cập cùng lúc.

Một dạng khác của tấn công DoS ứng dụng web dựa trên các lỗi trong chức năng của ứng dụng. Ví dụ một ứng dụng sử dụng cơ chế khóa tài khoản trong 1 tiếng hoặc hơn nếu nhận được quá 3 lần mật khẩu sai. Hacker có thể lợi dụng điểm yếu này, gửi đến quá 3 lần sai mật khẩu của một tài khoản hợp lệ, hậu quả là người dùng của tài khoản này không thể truy cập được trong 1 tiếng hoặc hơn.

Trong một cuộc tấn công từ chối dịch vụ điển hình vào ứng dụng web, hackers sẽ tìm cách chiếm gần hết nguồn tài nguyên hệ thống trên máy chủ hoặc ứng dụng, hậu quả là người sử dụng hợp lệ không thể truy cập vào ứng dụng. Tài nguyên hệ thống bao gồm: băng thông, số lượng truy cập đồng thời cơ sở dữ liệu, dung lượng trống ổ cứng, CPU, dung lượng bộ nhớ RAM, threads, và các nguồn tài nguyên khác liên quan đến ứng dụng.

Sơ đồ 9.0 mô tả một cuộc tấn công từ chối dịch vụ ứng dụng web điển hình. Trong tấn công này, hacker lợi dụng vào điểu yếu của ứng dụng cho phép truy cập đến cơ sở dữ liệu (CSDL) từ bất kỳ kết nối nào, ngay cả những truy cập không được xác thực. Giả định là ứng dụng chỉ có thể xử lý tối đa 1000 truy cập cùng lúc đến CSDL, hacker sẽ gửi đến ứng dụng hơn 1000 kết nối đồng thời, tạo ra hơn 1000 truy cập đến CSDL, hậu quả là ứng dụng bị tê liệt, không thể đáp ứng các truy cập hợp lệ từ người sử dụng.

top10webvul-8
Sơ đồ 9: Tấn công DOS

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

Cấu hình của máy chủ và các phần mềm hỗ trợ dịch vụ web là một yếu tố quan trọng trong vấn đề bảo mật của ứng dụng. Máy chủ cung cấp nền tảng phục vụ cho việc cung cấp nội dung và các dịch vụ mà ứng dụng web cần sử dụng, bao gồm lưu trữ, dịch vụ directory, emai. Do là nền tảng cung cấp các chức năng cấp thấm cơ bản cho ứng dụng. Những vấn đề về cấu hình của máy chủ có thể dẫn đến vấn đề bảo mật của ứng dụng.

Trong đại đa số các công ty, nhóm phát triển ứng dụng web thường tách biệt với nhóm hỗ trợ triển khai trang web trên máy chủ. Vì vậy, có sự không thống nhất và thiếu sự liên lạc về phương hướng bảo mật giữa hai nhóm này. Điều này có thể dẫn đến những điểm yếu nghiêm trọng trên ứng dụng được tạo ra từ các lỗ hổng ở máy chủ.

Theo các thống kê hiện nay, các lỗ hổng liên quan đến cấu hình máy chủ bao gồm:

  • Các phần mềm và hệ điều hành trên máy chủ không được cập nhật với bản vá lỗi bảo mật mới nhất.Lỗi trên phần mềm web hosting máy chủ cho phép liệt kê bất kỳ thư mục (hoặc tập tin) nào trong hệ thống.
  • Những tập tin mặc định, tập tin tạo ra để test như script, tập tin cấu hình không được xóa đi trong thư mục của trang web. Những tập tin này thường có độ bảo mật yếu và có thể chứa những thông tin quan trọng.
  • Không phân đúng quyền cho các thư mục và tập tin trong trang web.
  • Những chức năng quản lý và debug được triển khai không cần thiết.
  • Phần mềm web server đăng quá nhiều thông tin trong trang báo lỗi.
  • Cấu hình SSL và các hàm mã hóa không đúng.

Kết luận

Vấn đề bảo mật ứng dụng Web nêu trên không phải là một vấn đề mới. Thực tế là phần lớn các vấn đề trên đã được hiểu rõ trong nhiều thập kỷ qua. Tuy nhiên do nhiều lý do, khá nhiều dự án phát triển phần mềm vẫn còn mắc phải những lỗ hổng này và đe dọa không chỉ đến độ an toàn cho khách hàng, mà còn ảnh hưởng chung đến an toàn của hệ thống Internet. Do tính chất phức tạp của ứng dụng, hiện nay không có một giải pháp tuyệt đối cho vấn đề này. Tuy nhiên các giải pháp sau được đề nghị để giảm thiểu các rủi ro liên quan đến bảo mật của ứng dụng web:

  • Các tiêu chí về bảo mật phải được đặt ra ngay từ lúc thiết kế ứng dụng nhằm phát triển các module bảo vệ ngay từ giai đoạn đầu của quá trình phát triển ứng dụng.
  • Một văn bản chính thức thiết lập chính sách bảo mật ứng dụng nên được xây dựng nhằm cung cấp một chuẩn tối thiểu về bảo mật cho toàn ứng dụng.
  • Thường xuyên cập nhật kiến thức bảo mật cho lập trình viên.
  • Sử dụng dịch vụ đánh giá bảo mật của một công ty ngoài để kiểm tra tính bảo mật của ứng dụng.
  • Sử dụng các công cụ dò và phát hiện lỗi của ứng dụng (xem thêm trong phần tham khảo công cụ)
  • Cập nhật các phần mềm máy chủ web với các phiên bản vá lỗi bảo mật mới nhất.
  • Sử dụng các thiết bị tường lửa ứng dụng web để bảo vệ ứng dụng ở mức ngoại vi.
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