Cwe tiêm html

Log4j phiên bản 2. 15. 0 chứa một bản sửa lỗi trước đó cho lỗ hổng, nhưng bản vá đó không vô hiệu hóa tra cứu JNDI do kẻ tấn công kiểm soát trong mọi tình huống. Để biết thêm thông tin, hãy xem phần

NIST (AV:N/AC:L/Au:N/C:P/I:P/A:P)
2 của tư vấn này

Ghi nhật ký dữ liệu không đáng tin cậy hoặc do người dùng kiểm soát bằng phiên bản Log4J dễ bị tổn thương có thể dẫn đến Thực thi mã từ xa (RCE) đối với ứng dụng của bạn. Điều này bao gồm dữ liệu không đáng tin cậy có trong các lỗi đã ghi, chẳng hạn như dấu vết ngoại lệ, lỗi xác thực và các vectơ không mong muốn khác của đầu vào do người dùng kiểm soát

Mọi phiên bản Log4J trước v2. 15. 0 bị ảnh hưởng đến vấn đề cụ thể này

Nhánh v1 của Log4J được coi là End Of Life (EOL) dễ bị tấn công bởi các vectơ RCE khác, vì vậy khuyến nghị vẫn là cập nhật lên 2. 16. 0 nếu có thể

Bản phát hành bảo mật

Các backport bổ sung của bản sửa lỗi này đã có sẵn trong phiên bản 2. 3. 1, 2. 12. 2 và 2. 12. 3

gói bị ảnh hưởng

Chỉ có gói

NIST (AV:N/AC:L/Au:N/C:P/I:P/A:P)
3 bị ảnh hưởng trực tiếp bởi lỗ hổng này.
NIST (AV:N/AC:L/Au:N/C:P/I:P/A:P)
4 nên được giữ cùng phiên bản với gói
NIST (AV:N/AC:L/Au:N/C:P/I:P/A:P)
3 để đảm bảo khả năng tương thích nếu được sử dụng

Đã cập nhật lời khuyên cho phiên bản 2. 16. 0

Nhóm Dịch vụ ghi nhật ký Apache đã cung cấp lời khuyên giảm thiểu được cập nhật khi phát hành phiên bản 2. 16. 0, tắt JNDI theo mặc định và loại bỏ hoàn toàn hỗ trợ tra cứu thư.
Ngay cả trong phiên bản 2. 15. 0, các tra cứu được sử dụng trong bố cục để cung cấp các phần thông tin ngữ cảnh cụ thể sẽ vẫn được giải quyết theo cách đệ quy, có thể kích hoạt tra cứu JNDI. Sự cố này đang được theo dõi là CVE-2021-45046. Thông tin thêm có sẵn trên Tư vấn bảo mật GitHub cho CVE-2021-45046.

Người dùng muốn tránh tra cứu JNDI do kẻ tấn công kiểm soát nhưng không thể nâng cấp lên 2. 16. 0 phải đảm bảo rằng không có tra cứu nào như vậy giải quyết dữ liệu do kẻ tấn công cung cấp và đảm bảo rằng lớp JndiLookup không được tải

Xin lưu ý rằng Log4J v1 là End Of Life (EOL) và sẽ không nhận được các bản vá lỗi cho sự cố này. Log4J v1 cũng dễ bị ảnh hưởng bởi các vectơ RCE khác và chúng tôi khuyên bạn nên chuyển sang Log4J 2. 16. 0 nếu có thể

Đã thêm cấu hình CPE____0

Đã thêm CVSS V2

NIST (AV:N/AC:L/Au:N/C:P/I:P/A:P)

Đã thêm CVSS V3. 1

NIST AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Đã thêm CWE

NIST CWE-89

Đã thay đổi loại tham chiếu

https://github.com/nukeviet/module-shops/commit/742c0e0f74364f7250c2a69f0a957d4e6317be68 No Types Assigned
https://github.com/nukeviet/module-shops/commit/742c0e0f74364f7250c2a69f0a957d4e6317be68 Patch, Third Party Advisory

Đã thay đổi loại tham chiếu

https://nukeviet.vn/vi/news/Tin-an-ninh/huong-dan-fix-loi-bao-mat-nukeviet-4-va-module-shops-612.html No Types Assigned
https://nukeviet.vn/vi/news/Tin-an-ninh/huong-dan-fix-loi-bao-mat-nukeviet-4-va-module-shops-612.html Patch, Vendor Advisory

Đã thay đổi loại tham chiếu

https://whitehub.net/submissions/1517 No Types Assigned
https://whitehub.net/submissions/1517 Exploit, Issue Tracking, Third Party Advisory

Đã thay đổi loại tham chiếu

NIST (AV:N/AC:L/Au:N/C:P/I:P/A:P)
0
NIST (AV:N/AC:L/Au:N/C:P/I:P/A:P)
1

Tiêm là một sự cố xảy ra do sự thiếu sót trong quá trình lọc các dữ liệu đầu vào không đáng tin cậy. Khi bạn truyền dữ liệu chưa được lọc tới Cơ sở dữ liệu (Ví dụ như truy cập SQL injection), truy cập trình duyệt (lỗ truy cập XSS), truy cập máy chủ LDAP (lỗ truy cập LDAP Injection) hoặc truy cập bất kỳ vị trí nào khác. Vấn đề là kẻ gian tấn công có thể chèn các đoạn mã độc để gây lộ dữ liệu và chiếm quyền kiểm tra trình duyệt của khách hàng

Hậu quả

Tiêm có thể dẫn đến mất dữ liệu, sự cố gián đoạn hoặc tiết lộ cho các tổ chức thứ 3, mất hết tài khoản hoặc từ chối truy cập. Đôi khi, tiêm dẫn tới việc sử dụng quyền kiểm soát

Cách phòng

Nguyên tắc cơ bản để chống lại Tiêm phải tách dữ liệu được gửi lên từ câu lệnh thực thi trực tiếp và truy vấn

  • Có cơ chế kiểm tra và bộ lọc dữ liệu bắt đầu như giới hạn kích thước, loại bỏ các ký tự đặc biệt,
  • Sử dụng thủ tục lưu trữ (Store thủ tục) trong cơ sở dữ liệu. Tạm hiểu là đưa câu truy vấn SQL vào trong thủ tục (gần giống hàm trong ngôn ngữ lập trình), dữ liệu được truyền vào thủ tục thông qua các tham số -> tách dữ liệu khỏi mã lệnh
  • Không hiển thị ngoại lệ hoặc thông báo lỗi để tránh kẻ tấn công có thể suy đoán kết quả
  • Thiết lập quyền sử dụng cho người dùng phù hợp
  • Chủ động sử dụng các công cụ dò tìm lỗ hổng bảo mật
  • Backup data thường xuyên

2. Xác thực bị hỏng

Khái niệm

Cwe tiêm html

Ngọc Long Chủ @LongCN

Theo dõi

314 10 10

Đã đăng vào ngày 11 tháng 2 năm 2021 1. 07 CH 14 phút đọc

2. 1k

0

0

Các lỗi hàng đầu về bảo mật web của OWASP (Phần 1)

Chúc mừng năm mới

  • Report
  • Add to series of me

1. Injection Error (Incode Error)

Khái niệm

Tiêm là một sự cố xảy ra do sự thiếu sót trong quá trình lọc các dữ liệu đầu vào không đáng tin cậy. Khi bạn truyền dữ liệu chưa được lọc tới Cơ sở dữ liệu (Ví dụ như truy cập SQL injection), truy cập trình duyệt (lỗ truy cập XSS), truy cập máy chủ LDAP (lỗ truy cập LDAP Injection) hoặc truy cập bất kỳ vị trí nào khác. Vấn đề là kẻ gian tấn công có thể chèn các đoạn mã độc để gây lộ dữ liệu và chiếm quyền kiểm tra trình duyệt của khách hàng

Hậu quả

Tiêm có thể dẫn đến mất dữ liệu, sự cố gián đoạn hoặc tiết lộ cho các tổ chức thứ 3, mất hết tài khoản hoặc từ chối truy cập. Đôi khi, tiêm dẫn tới việc sử dụng quyền kiểm soát

Cách phòng

Nguyên tắc cơ bản để chống lại Tiêm phải tách dữ liệu được gửi lên từ câu lệnh thực thi trực tiếp và truy vấn

  • Có cơ chế kiểm tra và bộ lọc dữ liệu bắt đầu như giới hạn kích thước, loại bỏ các ký tự đặc biệt,
  • Sử dụng thủ tục lưu trữ (Store thủ tục) trong cơ sở dữ liệu. Tạm hiểu là đưa câu truy vấn SQL vào trong thủ tục (gần giống hàm trong ngôn ngữ lập trình), dữ liệu được truyền vào thủ tục thông qua các tham số -> tách dữ liệu khỏi mã lệnh
  • Không hiển thị ngoại lệ hoặc thông báo lỗi để tránh kẻ tấn công có thể suy đoán kết quả
  • Thiết lập quyền sử dụng cho người dùng phù hợp
  • Chủ động sử dụng các công cụ dò tìm lỗ hổng bảo mật
  • Backup data thường xuyên

2. Xác thực bị hỏng

Khái niệm

Đây là lỗi liên quan đến vấn đề xác minh người dùng, quản lý phiên bản được khai thác không đúng cách, cơ chế quản lý yếu tố -> cho phép Hacker có thể bẻ khóa mật khẩu, khóa, mã thông báo phiên hoặc lợi dụng để thực hiện

Kẻ tấn công dễ dàng tìm kiếm hàng tỷ phú tên người dùng và mật khẩu phổ biến, một danh sách các tài khoản quản trị mặc định, các công cụ brute force tự động (tấn công vét cạn), hoặc các bộ công cụ tấn công từ điển. Đây là điều kiện cần để thực hiện các cuộc tấn công nhằm vào lỗ hổng này Với việc có quyền truy cập vào một vài tài khoản, hoặc chỉ cần 1 tài khoản quản trị là đủ để Hacker có thể gây hại cho cả hệ thống. Sói phụ thuộc vào tính chất của hệ thống, mà nó cho phép Hacker tiến hành nhiều hành vi phạm pháp như rửa tiền, ăn cắp tài sản, danh tính, tiết lộ thông tin nhạy cảm,

Vì vậy, một hệ thống như thế nào sẽ có nguy cơ đối mặt với lỗ hổng này?

  • Ứng dụng cho phép hacker tiến hành các cuộc tấn công vét cạn Brute Force hoặc các kiểu tấn công tự động khác. Các bạn có thể hiểu đơn giản là ứng dụng Web của chúng ta cho phép yêu cầu liên tục nhiều API từ cùng một IP hoặc cố gắng truy cập vào một tài khoản nhiều lần mà không có cơ chế quản lý ví dụ như khóa tài khoản đó
  • Cho phép người dùng đặt các mật khẩu yếu, không đạt tiêu chuẩn. Không có cơ chế bắt buộc thay đổi mật khẩu mặc định chẳng hạn như "Password1" hay "admin/admin"
  • Cơ chế khôi phục mật khẩu (trường hợp người dùng quên mật khẩu) yếu hoặc không hoàn toàn, thực sự cơ chế trả lời câu hỏi mà bạn hay thấy nếu sử dụng Yahoo từ 7-8 năm trước, đây thực sự là một giải pháp
  • Lưu trữ Mật khẩu ở dạng Plaintext (bản rõ) không mã hóa, hoặc sử dụng các thuật toán mã hóa hay các mã băm đơn giản, dễ dàng bị bẻ khóa
  • Thiếu hoặc cơ chế xác thực 2 lớp không hiệu quả
  • Hiển thị trực tiếp ID phiên hoặc các thông số quan trọng trong Tham số của URL
  • Không có cơ chế luân phiên thay đổi ID phiên sau khi đăng nhập thành công
  • Việc cài đặt thời gian tồn tại của ID phiên không đúng

Hậu quả

Hacker phải chiếm quyền truy cập 1 vài tài khoản hoặc chỉ cần 1 tài khoản quản trị để xâm nhập vào hệ thống

Dựa vào đích của hệ thống mà Broken Authentication có thể cho phép chuyển tiền, tiết lộ thông tin cảm ứng có độ bảo mật cao

Cách phòng

  • Triển khai cơ chế xác thực 2 lớp Chống lại các cuộc tấn công tự động như Brute Force
  • Kiểm tra mức độ an toàn của Mật khẩu, không cho phép người dùng đặt các mật khẩu này quá đơn giản, chỉ đơn giản là toàn số hoặc toàn chữ. Bạn cũng có thể kiểm tra mật khẩu do người dùng đặt trong top 10000 mật khẩu tệ nhất
    NIST (AV:N/AC:L/Au:N/C:P/I:P/A:P)
    6 và không cho phép cài đặt các mật khẩu này
  • Bảo đảm việc đăng ký, khôi phục tài khoản, đăng nhập thất bại (có thể làm sai Mật khẩu, Tên người dùng) hoặc đường dẫn URL sẽ sử dụng các thông báo giống nhau trả về cho người dùng cho mọi kết quả. Không giới hạn khi người dùng đăng nhập không thành công do sai mật khẩu. Nếu Máy chủ trả về thông báo "Bạn nhập sai mật khẩu". Kẻ tấn công có thể dựa vào đó để biết rằng tên người dùng được gửi lên tồn tại và chỉ cần rút sạch mật khẩu để truy cập khi thành công. Thay vào đó, Máy chủ sẽ trả về thông báo "Tên người dùng hoặc Mật khẩu không hợp lệ", kẻ tấn công sẽ không thể loại bỏ bất kỳ trường hợp nào, việc rút cạn sẽ trở nên phức tạp hơn rất nhiều
  • Giới hạn số lần hoặc yêu cầu thời gian chờ đợi sau một số lần đăng nhập không thành công. Có thể là khóa tài khoản (cách Facebook đang áp dụng), hoặc sau 2-3' mới có thể tiếp tục thực hiện đăng nhập, cơ chế này cũng khá phổ biến như khi mở khóa iPhone, thiết bị của bạn sẽ bị vô hiệu hóa
  • Có cơ chế sinh, quản lý và lưu trữ ID phiên đảm bảo an toàn, với mức độ khó và xáo trộn cao, đặt thời gian hết hạn cũng như tự hủy sau khi Đăng xuất

3. Lỗi truy cập XSS (Cross Site Scripting)

Khái niệm

Lỗi truy cập XSS (Cross-site Scripting) là một lỗi truy cập rất phổ biến. Kẻ tấn công đã chèn đoạn mã đoạn mã vào ứng dụng web. Khi bắt đầu vào trang này không được lọc, chúng sẽ được thực thi mã độc trên trình duyệt của người dùng. Kẻ tấn công có thể lấy được cookie của người dùng trên hệ thống hoặc lừa đảo người dùng đến các trang web độc hại

=> Cơ chế. Hacker sẽ nhập vào ô Input code script, sau đó server sẽ lưu vào cơ sở dữ liệu và khi người dùng gửi yêu cầu lên server thì server sẽ tải dữ liệu từ database ra để xử lý và code script đó được thực thi và hacker có thể lấy cookie đã lấy được

Hậu quả

Đoạn script được thực thi tại giao diện người dùng khiến cho hacker có thể thực hiện các nhiệm vụ. đánh cắp thông tin đăng nhập, phiên hoặc gửi phần mềm độc hại cho nạn nhân

Cách phòng

  • Sử dụng các framework mà XSS tự động phát hiện như ( Ruby on Rails, ReactJS, Laravel )
  • Có một cách đơn giản bảo mật web là không trả lại thẻ HTML cho người dùng. Điều này còn giúp chống lại HTML Injection – Một cuộc tấn công tương tự mà hacker tấn công vào nội dung HTML – không gây ảnh hưởng nghiêm trọng nhưng khá rắc rối cho người dùng. Thông thường cách giải quyết đơn giản chỉ là Mã hóa (chuyển đổi sang định dạng dữ liệu khác) tất cả các thẻ HTML

4. Kiểm soát truy cập bị hỏng

Khái niệm

Đây là lỗi phổ biến về việc phân quyền trong hệ thống. Các lỗi phân quyền thường do thiếu đi các bộ phát hiện lỗi tự động hoặc cách thức kiểm tra hoặc các chức năng kiểm tra không hiệu quả khiến cho hệ thống bị rò rỉ

Hậu quả

Về mặt kỹ thuật thì các hacker có thể truy cập và có các quyền như người dùng hoặc quản trị viên, hoặc người dùng hiểu biết về các chức năng của hệ thống cũng có thể gọi và thực thi các chức năng này (Ví dụ:. Thêm, sửa, xóa các bản ghi)

Cách phòng

  • Giới hạn quyền truy cập API và bộ điều khiển để giảm thiểu thiệt hại
  • Thực hiện các cơ chế kiểm soát quyền truy cập và thực hiện nó trên toàn bộ ứng dụng
  • Mã thông báo JWT nên vô hiệu hóa trên máy chủ khi đăng xuất
  • Nên cài đặt các quy tắc trong Model để quản lý các thao tác với cơ sở dữ liệu

5. Tiếp xúc dữ liệu nhạy cảm

Khái niệm

This error thuộc về khía cạnh tiền điện tử và tài nguyên. Dữ liệu cảm ứng phải được mã hóa mọi lúc, bao gồm cả khi gửi đi và khi lưu trữ – không được phép có ngoại lệ. Thông tin thẻ tín hiệu và mật khẩu người dùng không bao giờ được gửi đi hoặc được lưu trữ không được mã hóa. Rõ ràng thuật toán mã hóa và băm không phải là một cách bảo mật yếu. Ngoài ra, các tiêu chuẩn an ninh web đề nghị sử dụng AES (256 bit trở lên) và RSA (2048 bit trở lên)

Cần phải nói rằng ID phiên và dữ liệu nhạy cảm không nên được truyền trong các URL và cookie nhạy cảm nên có cờ an toàn

Hậu quả

Để lộ thông tin nhạy cảm sẽ gây ảnh hưởng nghiêm trọng đến cá nhân đó

Cách ngăn chặn các cuộc tấn công

  • Sử dụng HTTPS có chứng chỉ phù hợp và PFS (Perfect Forward Secrecy). Không nhận được bất cứ thông tin gì trên các kết nối không phải là HTTPS. Có cờ an toàn trên cookie
  • Bạn cần hạn chế các dữ liệu cảm ứng có khả năng lộ của mình. Nếu bạn không cần những cảm ứng dữ liệu này, hãy hủy bỏ nó. Dữ liệu bạn không có không thể bị đánh cắp
  • Không bao giờ lưu trữ thông tin thẻ tín dụng, nếu không muốn phải đối phó với việc giám sát PCI. Vui lòng đăng ký một bộ xử lý thanh toán như Stripe hoặc Braintree
  • Nếu bạn có dữ liệu nhạy cảm mà bạn thực sự cần, hãy lưu trữ mã hóa của nó và đảm bảo rằng tất cả các mật khẩu đều được sử dụng hàm Hash để bảo vệ. Đối với Hash, nên sử dụng bcrypt. Nếu bạn không sử dụng mã hóa bcrypt, hãy tìm hiểu về mã Salt để ngăn chặn cuộc tấn công bảng cầu vồng
  • Không lưu trữ các khóa mã hóa bên cạnh dữ liệu được bảo vệ. Cái này giống như khóa xe mà ổ cắm luôn ở đó. Bảo vệ bản sao lưu của bạn bằng mã hóa và đảm bảo các khóa của bạn là riêng tư

Kết quả

Trên đây là 1 số tìm hiểu của mình về một số lỗ truy cập về bảo mật web của OWASP. Cảm ơn mọi người đã tham khảo bài viết của mình. Cùng đón xem phần 2 của bài viết tại