Get in touch
or send us a question?
CONTACT

10 lỗ hổng bảo mật web phổ biến nhất

OWASP (Open Web Security Project – Dự án bảo mật web mở) là một tổ chức từ thiện phi lợi nhuận tập trung vào việc cải thiện tính bảo mật của phần mềm và ứng dụng web.

Tổ chức này công bố danh sách các lỗ hổng bảo mật web hàng đầu dựa trên dữ liệu từ nhiều tổ chức bảo mật khác nhau.

Các lỗ hổng bảo mật web được ưu tiên dựa trên khả năng khai thác, khả năng phát hiện và tác động đến phần mềm.

  • Khả năng khai thác – Cần những gì để khai thác lỗ hổng bảo mật? Khả năng khai thác cao nhất khi cuộc tấn công chỉ cần trình duyệt web và thấp nhất là lập trình và công cụ tiên tiến.
  • Khả năng phát hiện – Có dễ để phát hiện mối đe dọa không? Cao nhất là thông tin hiển thị trên URL, Biểu mẫu hoặc thông báo Lỗi và thấp nhất là mã nguồn.
  • Tác động hoặc thiệt hại – Sẽ gây ra bao nhiêu thiệt hại nếu lỗ hổng bảo mật bị lộ hoặc bị tấn công? Cao nhất là toàn bộ hệ thống bị sập và thấp nhất là không có gì cả.

Mục đích chính của OWASP Top 10 là giáo dục các nhà phát triển, nhà thiết kế, nhà quản lý, kiến ​​trúc sư và các tổ chức về các lỗ hổng bảo mật quan trọng nhất.

10 lỗ hổng bảo mật hàng đầu theo OWASP Top 10 là:

1. SQL Injection

Mô tả

Injection là lỗ hổng bảo mật cho phép kẻ tấn công thay đổi các câu lệnh SQL ở backend bằng cách thao túng dữ liệu do người dùng cung cấp.

Lỗi injection xảy ra khi dữ liệu đầu vào của người dùng được gửi đến trình thông dịch như một phần của lệnh hoặc truy vấn và lừa trình thông dịch thực hiện các lệnh không mong muốn và cấp quyền truy cập vào dữ liệu trái phép.

Lệnh SQL khi được thực thi bởi ứng dụng web cũng có thể hiển thị cơ sở dữ liệu phía sau.

Ảnh hưởng

  • Kẻ tấn công có thể đưa nội dung độc hại vào các trường dễ bị tấn công.
  • Dữ liệu nhạy cảm như Tên người dùng, Mật khẩu, v.v. có thể được đọc từ cơ sở dữ liệu.
  • Dữ liệu cơ sở dữ liệu có thể được sửa đổi (Chèn/Cập nhật/Xóa).
  • Các hoạt động quản trị có thể được thực hiện trên cơ sở dữ liệu

Các đối tượng dễ bị tấn công

  • White listing (liệt kê danh sách cho phép) các trường nhập liệu
  • URL tương tác với cơ sở dữ liệu.

Ví dụ

  • Thực hiện SQL injection vào Trang Đăng nhập

Đăng nhập vào ứng dụng mà không có thông tin xác thực hợp lệ.

Tên người dùng hợp lệ nhưng mật khẩu không có sẵn.

URL kiểm tra: http://demo.testfire.net/default.aspx

Tên người dùng: sjones

Mật khẩu: 1=1′ hoặc pass123

Truy vấn SQL được tạo và gửi đến Interpreter như bên dưới

SELECT * FROM Users WHERE User_Name = sjones AND Password = 1=1′ or pass123;

Đề xuất

  1. Danh sách trắng các trường nhập liệu
  2. Tránh hiển thị các thông báo lỗi chi tiết có lợi cho kẻ tấn công.

2. Cross Site Scripting (XSS)

Mô tả

Cross Site Scripting còn được gọi tắt là XSS.

Lỗ hổng XSS nhắm vào các tập lệnh nhúng trong một trang được thực thi ở phía máy khách tức là trình duyệt của người dùng chứ không phải ở phía máy chủ. Những lỗi này có thể xảy ra khi ứng dụng lấy dữ liệu không đáng tin cậy và gửi đến trình duyệt web mà không có xác thực phù hợp.

Kẻ tấn công có thể sử dụng XSS để thực thi các tập lệnh độc hại trên người dùng trong trường hợp này là trình duyệt nạn nhân. Vì trình duyệt không thể biết tập lệnh có đáng tin cậy hay không, nên tập lệnh sẽ được thực thi và kẻ tấn công có thể chiếm đoạt cookie phiên, làm hỏng trang web hoặc chuyển hướng người dùng đến các trang web không mong muốn và độc hại.

XSS là một cuộc tấn công cho phép kẻ tấn công thực thi các tập lệnh trên trình duyệt của nạn nhân.

Ảnh hưởng

  • Lợi dụng lỗ hổng bảo mật này, kẻ tấn công có thể chèn mã lệnh vào ứng dụng, đánh cắp cookie phiên, làm hỏng trang web và chạy phần mềm độc hại trên máy của nạn nhân.

Các đối tượng dễ bị tấn công

  • Các trường nhập liệu
  • Các URL

Ví dụ

1. http://www.vulnerablesite.com/home?”<script>alert(“xss”)</script>

Khi chạy đoạn mã trên trên trình duyệt, một thông báo sẽ hiển thị nếu trang web có lỗ hổng XSS.

Cuộc tấn công nghiêm trọng hơn có thể được thực hiện nếu kẻ tấn công muốn hiển thị hoặc lưu trữ session cookie.

2. http://demo.testfire.net/search.aspx?txtSearch <iframe> <src = http://google.com width = 500 height 500></iframe>

Khi chạy đoạn mã trên, trình duyệt sẽ tải một khung vô hình trỏ tới http://google.com.

Cuộc tấn công có thể trở nên nghiêm trọng hơn bằng cách chạy một tập lệnh độc hại trên trình duyệt.

Đề xuất

  1. White listing (liệt kê danh sách cho phép) các trường nhập liệu
  2. Mã hóa đầu vào đầu ra

3. Xác thực và quản lý session bị phá vỡ

Mô tả

Các trang web thường tạo session cookie và session ID cho mỗi session (phiên sử dụng) hợp lệ và các cookie này chứa dữ liệu nhạy cảm như tên người dùng, mật khẩu, v.v. Khi session kết thúc bằng cách đăng xuất hoặc đóng trình duyệt đột ngột, các cookie này sẽ bị vô hiệu hóa, nghĩa là đối với mỗi session sẽ có một cookie mới.

Nếu cookie không bị vô hiệu hóa, dữ liệu nhạy cảm sẽ tồn tại trong hệ thống. Ví dụ, người dùng sử dụng máy tính công cộng (Cyber ​​Cafe), cookie của trang web dễ bị tấn công sẽ nằm trên hệ thống và bị kẻ tấn công tiếp cận. Kẻ tấn công sử dụng cùng một máy tính công cộng sau một thời gian, dữ liệu nhạy cảm sẽ bị xâm phạm.

Tương tự như vậy, người dùng sử dụng máy tính công cộng, thay vì đăng xuất, họ đột ngột đóng trình duyệt. Kẻ tấn công sử dụng cùng một hệ thống, khi duyệt cùng một trang web dễ bị tấn công, phiên trước đó của nạn nhân sẽ được mở. Kẻ tấn công có thể làm bất cứ điều gì hắn muốn làm từ việc đánh cắp thông tin hồ sơ, thông tin thẻ tín dụng, v.v.

Cần phải kiểm tra để tìm ra sức mạnh của xác thực và quản lý phiên. Khóa, session token, cookie phải được triển khai đúng cách mà không làm ảnh hưởng đến mật khẩu.

Các đối tượng dễ bị tấn công

  • Session ID được tiết lộ trên URL có thể dẫn đến tấn công session cố định.
  • Session ID giống nhau trước và sau khi đăng xuất và đăng nhập.
  • Thời gian session timeoout không được triển khai đúng cách.
  • Ứng dụng đang gán cùng một session ID cho mỗi phiên mới.
  • Các phần đã xác thực của ứng dụng được bảo vệ bằng SSL và mật khẩu được lưu trữ ở định dạng băm hoặc mã hóa.
  • Session có thể được sử dụng lại bởi người dùng có quyền thấp.

Ảnh hưởng

  • Bằng cách lợi dụng lỗ hổng này, kẻ tấn công có thể chiếm quyền điều khiển phiên làm việc, truy cập trái phép vào hệ thống, từ đó tiết lộ và sửa đổi thông tin trái phép.
  • Các session có thể bị chiếm đoạt bằng cách sử dụng cookie/session bị đánh cắp, sử dụng XSS.

Ví dụ

  1. Ứng dụng đặt vé máy bay hỗ trợ URL rewriting, đưa session ID vào URL: http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Bán vé đến Maldives). Một người dùng đã xác thực của trang web muốn cho bạn bè của mình biết về việc bán vé và gửi email. Bạn bè của họ nhận được session ID và có thể sử dụng để thực hiện các sửa đổi trái phép hoặc sử dụng nhầm thông tin thẻ tín dụng đã lưu.
  2. Ứng dụng dễ bị tấn công bởi XSS, qua đó kẻ tấn công có thể truy cập session ID và sử dụng nó để chiếm quyền điều khiển session.
  3. Thời gian timeout của ứng dụng không được thiết lập đúng. Người dùng sử dụng máy tính công cộng và đóng trình duyệt thay vì đăng xuất và bỏ đi. Kẻ tấn công sử dụng cùng trình duyệt đó sau một thời gian và session được xác thực.

Đề xuất

  1. Mọi yêu cầu về xác thực và quản lý phiên phải được xác định theo Tiêu chuẩn xác minh bảo mật ứng dụng OWASP.
  2. Không bao giờ tiết lộ bất kỳ thông tin xác thực nào trong URL hoặc Log.
  3. Cần phải nỗ lực hết sức để tránh các lỗ hổng XSS có thể được sử dụng để đánh cắp session ID.

4. Tham chiếu đối tượng trực tiếp không an toàn (Insecure Direct Object Reference)

Mô tả

Tham chiếu đối tượng trực tiếp không an toàn xảy ra khi một nhà phát triển làm lộ một tham chiếu đến một đối tượng triển khai nội bộ, chẳng hạn như tệp, thư mục hoặc khóa cơ sở dữ liệu như trong URL hoặc dưới dạng tham số FORM. Kẻ tấn công có thể sử dụng thông tin này để truy cập các đối tượng khác và có thể tạo ra một cuộc tấn công trong tương lai để truy cập dữ liệu trái phép.

Ảnh hưởng

  • Bằng cách sử dụng lỗ hổng này, kẻ tấn công có thể truy cập vào các đối tượng nội bộ trái phép, có thể sửa đổi dữ liệu hoặc xâm phạm ứng dụng.

Các đối tượng dễ bị tấn công

  • Trong URL.

Ví dụ

Việc thay đổi “userid” trong URL sau có thể khiến kẻ tấn công xem được thông tin của người dùng khác.

http://www.vulnerablesite.com/userid=123 

được sửa đổi thành http://www.vulnerablesite.com/userid=124

Kẻ tấn công có thể xem thông tin của người khác bằng cách thay đổi giá trị ID người dùng.

Đề xuất

  1. Thực hiện kiểm tra kiểm soát truy cập.
  2. Tránh hiển thị tham chiếu đối tượng trong URL.
  3. Xác minh quyền hạn cho tất cả các đối tượng tham chiếu.

5. Giả mạo yêu cầu trang web chéo (Cross Site Request Forgery)

Mô tả

Yêu cầu giả mạo giữa các trang web là yêu cầu giả mạo đến từ nhiều trang web.

Tấn công CSRF là cuộc tấn công xảy ra khi một trang web, email hoặc chương trình độc hại khiến trình duyệt của người dùng thực hiện hành động không mong muốn trên một trang web đáng tin cậy mà người dùng hiện đã xác thực.

Cuộc tấn công CSRF buộc trình duyệt của nạn nhân đã đăng nhập phải gửi yêu cầu HTTP giả mạo, bao gồm session cookie của nạn nhân và bất kỳ thông tin xác thực nào khác được tự động đưa vào, đến một ứng dụng web dễ bị tấn công.

Kẻ tấn công sẽ gửi một liên kết tới nạn nhân khi người dùng nhấp vào URL để đăng nhập vào trang web gốc, dữ liệu từ trang web đó sẽ bị đánh cắp.

Ảnh hưởng

  • Kẻ tấn công có thể lợi dụng lỗ hổng này để thay đổi thông tin hồ sơ người dùng, thay đổi trạng thái, tạo người dùng mới thay mặt quản trị viên, v.v.

Các đối tượng dễ bị tấn công

  • Trang Hồ sơ người dùng
  • Biểu mẫu tài khoản người dùng
  • Trang giao dịch kinh doanh

Ví dụ

Nạn nhân đăng nhập vào trang web ngân hàng bằng thông tin đăng nhập hợp lệ. Anh ta nhận được email từ kẻ tấn công nói rằng “Vui lòng nhấp vào đây để quyên góp 1 đô la cho mục đích chính đáng”.

Khi nạn nhân nhấp vào đó, một yêu cầu hợp lệ sẽ được tạo để quyên góp 1 đô la vào một tài khoản cụ thể.

http://www.vulnerablebank.com/transfer.do?account= Cause&amount=1

Kẻ tấn công nắm bắt được yêu cầu này và tạo yêu cầu bên dưới và nhúng vào một nút có nội dung “Tôi quyên góp”.

http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000

Vì phiên giao dịch đã được xác thực và yêu cầu được gửi qua trang web ngân hàng nên máy chủ sẽ chuyển 1000 đô la cho kẻ tấn công.

Đề xuất

  1. Yêu cầu người dùng phải có mặt khi thực hiện các hành động nhạy cảm.
  2. Triển khai các cơ chế như CAPTCHA, Xác thực lại và Mã thông báo yêu cầu duy nhất.

6. Cấu hình bảo mật sai

Mô tả

Cấu hình bảo mật phải được xác định và triển khai cho ứng dụng, khung, máy chủ ứng dụng, máy chủ web, máy chủ cơ sở dữ liệu và nền tảng. Nếu được cấu hình đúng, kẻ tấn công có thể truy cập trái phép vào dữ liệu hoặc chức năng nhạy cảm.

Đôi khi những lỗi như vậy dẫn đến sự xâm phạm toàn bộ hệ thống. Việc cập nhật phần mềm cũng là một biện pháp bảo mật tốt.

Ảnh hưởng

  • Bằng cách lợi dụng lỗ hổng này, kẻ tấn công có thể liệt kê công nghệ cơ bản và thông tin phiên bản máy chủ ứng dụng, thông tin cơ sở dữ liệu và thu thập thông tin về ứng dụng để thực hiện thêm một số cuộc tấn công.

Các đối tượng dễ bị tấn công

  • URL
  • Các trường biểu mẫu (form)
  • Các trường nhập liệu

Ví dụ

  1. Bảng điều khiển admin server của ứng dụng được cài đặt tự động và không bị xóa. Tài khoản mặc định không bị thay đổi. Kẻ tấn công có thể đăng nhập bằng mật khẩu mặc định và có thể truy cập trái phép.
  2. Chức năng liệt kê đường dẫn (Directory Listing) không bị vô hiệu hóa trên máy chủ của bạn. Kẻ tấn công phát hiện và có thể chỉ cần liệt kê các đường dẫn để tìm bất kỳ tệp nào.

Đề xuất

  1. Kiến trúc ứng dụng mạnh mẽ, cung cấp khả năng tách biệt và bảo mật tốt giữa các thành phần.
  2. Thay đổi tên người dùng và mật khẩu mặc định.
  3. Vô hiệu hóa chức năng liệt kê đường dẫn và thực hiện kiểm tra quyền truy cập.

7. Lưu trữ mật mã không an toàn

Mô tả

Lưu trữ mật mã không an toàn là một lỗ hổng phổ biến tồn tại khi dữ liệu nhạy cảm không được lưu trữ an toàn.

Thông tin đăng nhập của người dùng, thông tin hồ sơ, thông tin sức khỏe, thông tin thẻ tín dụng, v.v. nằm trong danh mục thông tin dữ liệu nhạy cảm trên trang web.

Dữ liệu này sẽ được lưu trữ trên cơ sở dữ liệu ứng dụng. Khi dữ liệu này được lưu trữ không đúng cách bằng cách như không sử dụng mã hóa hoặc băm*, nó sẽ dễ bị tấn công.

(*Băm là việc biến đổi các ký tự chuỗi thành các chuỗi ngắn hơn có độ dài cố định hoặc một khóa. Để giải mã chuỗi, thuật toán được sử dụng để tạo khóa phải có sẵn)

Ảnh hưởng

  • Bằng cách lợi dụng lỗ hổng này, kẻ tấn công có thể đánh cắp, sửa đổi dữ liệu được bảo vệ yếu để thực hiện hành vi trộm cắp danh tính, gian lận thẻ tín dụng hoặc các tội ác khác.

Các đối tượng dễ bị tấn công

  • Cơ sở dữ liệu ứng dụng.

Ví dụ

Trong một ứng dụng ngân hàng, cơ sở dữ liệu mật khẩu sử dụng các hàm băm không muối (unsalted hashes)* để lưu trữ mật khẩu của mọi người. Một lỗ hổng SQL injection cho phép kẻ tấn công lấy lại tệp mật khẩu. Tất cả các hàm băm không muối có thể bị tấn công bằng cách lừa dối cưỡng chế trong thời gian ngắn trong khi mật khẩu đã muối sẽ mất hàng nghìn năm.

(*Băm không muối – Muối là dữ liệu ngẫu nhiên được thêm vào dữ liệu gốc. Muối được thêm vào mật khẩu trước khi băm)

Đề xuất

  1. Đảm bảo các thuật toán chuẩn mạnh phù hợp. Không tạo thuật toán mã hóa riêng. Chỉ sử dụng các thuật toán công khai được chấp thuận như AES, mật mã khóa công khai RSA và SHA-256, v.v.
  2. Đảm bảo các bản sao lưu ngoài trang web được mã hóa, nhưng các khóa được quản lý và sao lưu riêng biệt.

8. Thất bại hạn chế quyền truy cập URL

Mô tả

Các ứng dụng web kiểm tra quyền truy cập URL trước khi hiển thị các liên kết và nút được bảo vệ. Các ứng dụng cần thực hiện các kiểm tra kiểm soát truy cập tương tự mỗi khi truy cập các trang này.

Trong hầu hết các ứng dụng, các trang, vị trí và tài nguyên được cấp quyền không được hiển thị cho người dùng được cấp quyền.

Bằng cách đoán thông minh, kẻ tấn công có thể truy cập các trang đặc quyền. Kẻ tấn công có thể truy cập các trang nhạy cảm, gọi các chức năng và xem thông tin bí mật.

Ảnh hưởng

  • Sử dụng lỗ hổng này, kẻ tấn công có thể truy cập vào các URL trái phép mà không cần đăng nhập vào ứng dụng và khai thác lỗ hổng. Kẻ tấn công có thể truy cập các trang nhạy cảm, gọi các chức năng và xem thông tin bí mật.

Các đối tượng dễ bị tấn công:

  • URL

Ví dụ

  1. Kẻ tấn công nhận thấy URL biểu thị vai trò (role) là “/user/getaccounts”. Kẻ tấn công sửa đổi thành “/admin/getaccounts”.
  2. Kẻ tấn công có thể thêm vai trò (role) vào URL.

http://www.vulnerablsite.com có ​​thể được sửa đổi thành http://www.vulnerablesite.com/admin

Đề xuất

  1. Thực hiện kiểm tra quyền truy cập chặt chẽ.
  2. Chính sách xác thực và ủy quyền phải dựa trên vai trò.
  3. Hạn chế truy cập vào các URL không mong muốn.

Thiếu sót bảo vệ lớp vận chuyển

Mô tả

Xử lý việc trao đổi thông tin giữa người dùng (máy khách) và máy chủ (ứng dụng). Các ứng dụng thường xuyên truyền thông tin nhạy cảm như thông tin xác thực, thông tin thẻ tín dụng và session token qua mạng.

Việc sử dụng các thuật toán yếu hoặc sử dụng chứng chỉ đã hết hạn hoặc không hợp lệ hoặc không sử dụng SSL có thể khiến thông tin liên lạc bị lộ với người dùng không đáng tin cậy, điều này có thể gây nguy hiểm cho ứng dụng web hoặc đánh cắp thông tin nhạy cảm.

Ảnh hưởng

  • Bằng cách lợi dụng lỗ hổng bảo mật web này, kẻ tấn công có thể đánh cắp thông tin đăng nhập hợp lệ của người dùng và truy cập vào ứng dụng.
  • Có thể đánh cắp thông tin thẻ tín dụng.

Các đối tượng dễ bị tấn công

  • Dữ liệu được gửi qua mạng.

Ví dụ

1. Một ứng dụng không sử dụng SSL, kẻ tấn công sẽ chỉ theo dõi lưu lượng mạng và quan sát cookie phiên nạn nhân đã xác thực. Kẻ tấn công có thể đánh cắp cookie đó và thực hiện tấn công Man-in-the-Middle.

Đề xuất

  1. Bật HTTP an toàn và chỉ thực hiện chuyển giao thông tin xác thực qua HTTPS.
  2. Đảm bảo chứng chỉ của bạn còn hiệu lực và chưa hết hạn.

Chuyển hướng và chuyển tiếp không xác thực

Mô tả

Ứng dụng web sử dụng một số phương pháp để chuyển hướng và đưa người dùng đến các trang khác cho mục đích đã định.

Nếu không có xác thực phù hợp khi chuyển hướng đến các trang khác, kẻ tấn công có thể lợi dụng điều này và chuyển hướng nạn nhân đến các trang web lừa đảo hoặc chứa phần mềm độc hại hoặc sử dụng lệnh chuyển tiếp để truy cập vào các trang trái phép.

Ảnh hưởng

  • Kẻ tấn công có thể gửi URL đến người dùng có chứa URL chính hãng được thêm vào URL độc hại được mã hóa. Người dùng chỉ cần nhìn thấy phần chính hãng của URL mà kẻ tấn công gửi có thể duyệt qua và có thể trở thành nạn nhân.

Ví dụ

1. http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com

được sửa đổi thành

http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com

Đề xuất

  1. Chỉ cần tránh sử dụng chuyển hướng và chuyển tiếp trong ứng dụng. Nếu sử dụng, không liên quan đến việc sử dụng tham số người dùng khi tính toán đích.
  2. Nếu không thể tránh được các tham số đích, hãy đảm bảo rằng giá trị được cung cấp là hợp lệ và được người dùng ủy quyền.

Bài viết gốc: https://www.guru99.com/web-security-vulnerabilities.html