0

AN TOÀN ỨNG DỤNG WEB VÀ CSDL đề TÀI BROKEN ACCESS CONTROL

21 2 0
  • AN TOÀN ỨNG DỤNG WEB VÀ CSDL đề TÀI BROKEN ACCESS CONTROL

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Tài liệu liên quan

Thông tin tài liệu

Ngày đăng: 25/11/2021, 19:15

HỌC VIỆN CƠNG NGHỆ BƯU CHÍNH VIỄN THƠNG KHOA CƠNG NGHỆ THÔNG TIN I -□□&□□ - BÁO CÁO BÀI TẬP LỚN MƠN: AN TỒN ỨNG DỤNG WEB VÀ CSDL ĐỀ TÀI: BROKEN ACCESS CONTROL Nhóm lớp: 01 GIẢNG VIÊN: Nguyễn Quốc Dũng NHÓM THỰC HIỆN: NHÓM Nguyễn Bá Đạt B18DCAT049 Vũ Lâm Thạch B18DCAT097 Dương Văn Chung B18DCAT029 Đặng Quốc Việt B18DCAT261 Hán Nam Long B18DCAT138 I MỤC LỤC II.Cấu trúc Broken Access Control Khái niệm Broken Access Control Điểm yếu bảo mật 3 Các yếu tố tác động Các lỗ hổng xảy III Các cách thức công Broken Access Control Bỏ qua kiểm tra kiểm soát quyền truy cập cách sửa đổi URL Khai thác từ APIs web chưa phân quyền .6 Nâng cao đặc quyền 10 Cấu hình sai CORS cho phép truy cập API trái phép .11 Tấn công mã thông báo web JSON (JWT) .12 II Cấu trúc Broken Access Control Khái niệm Broken Access Control - Kiểm soát truy cập nhằm mục đích kiểm sốt người dùng ủy quyền phép hay khơng phép làm ứng dụng để thiết lập quyền kiểm soát truy cập cách hợp lí, ứng dụng phải đảm bảo nghiêm túc thực kiểm tra ủy quyền xác thực hợp lệ để xác định người dùng đặc quyền, Đơn giản hóa lỗ hổng cho phép kẻ công bỏ qua ủy quyền (authorization) thực tác vụ thể người dùng có đặc quyền, chẳng hạn quản trị viên (admin) - Các lỗi phân quyền thường thiếu phát lỗi tự động cách thức kiểm thử hàm kiểm thử chưa hiệu khiến cho hệ thống bị rò rỉ - Điểm yếu bảo mật Các điểm yếu kiểm soát truy cập xảy phổ biến thiếu khả tự động phát lỗi khả kiểm tra chức hiệu nhà phát triển ứng dụng - Tính phát kiểm sốt truy cập thường khơng thích hợp với kiểm tra động tĩnh tự động Kiểm tra thủ công cách tốt để phát Broken Access Control, bao gồm phương pháp HTTP (GET vs PUT, v.v.), điều khiển, tham chiếu đối tượng trực tiếp, v.v - Các yếu tố tác động Tác động kĩ thuật kẻ cơng đóng vai trị người dùng quản trị viên, người dùng sử dụng chức đặc quyền, tạo, truy cập, cập nhật xóa ghi Tác động kinh doanh phụ thuộc vào nhu cầu bảo vệ ứng dụng liệu Các lỗ hổng xảy Yahoo! Mục Tiêu ưa thích tin tặc mạng internet Năm 2014, Yahoo tiết lộ họ phải chịu công Internet ảnh hưởng đến 500 triệu tài khoản không cần phải bàn cãi nhiều khơng bị Hack mà tài khoản cịn bị sử dụng để tiếp tục lừa người thân chủ Các thơng tin tên, ngày sinh, điện thoại bị đánh cắp gây nên sốt thời điểm Bất chấp cho việc Yahoo! Khẳng định việc lộ thông tin không ảnh hưởng đến tài khoản ngân hàng người dùng Yahoo! Đã giảm lao dốc Trước năm 2012, nhóm Hacker “Peace” rao bán 200 triệu thông tin người dùng kèm theo mật với giá 1900 USD internet Điều tồi tệ xảy với Yahoo lần họ lại bị công khiến 32 triệu tài khoản bị ảnh hưởng, kẻ cơng sử dụng phương thức cũ trước đó, Hacker tạo cookie độc hại internet và đăng nhập mà không cần mật Yahoo Cái kết đáng buồn Yahoo! Từ công ty định giá tỷ phải bán với giá 4,5 triệu đô vào năm 2017 cho Verizon Tháng 12 năm 2018, Yahoo tiếp tục thừa nhận khứ họ để tất tỷ tài khoản vào tay Hacker Đây coi công lớn lịch sử internet Microsoft xuất lỗ hổng bảo mật HiveNightmare vừa khám phá chuyên gia bảo mật Hai chuyên gia với tài khoản Twitter Jonas L @GosiTheDog phát Windows 10 Windows 11 có lỗ hổng bảo mật cho phép tài khoản cấp thấp truy cập file chứa liệu quan trọng Dựa vào đó, hacker thực kiểu cơng leo thang đặc quyền (LPE) để chiếm quyền kiểm sốt tồn máy tính Cụ thể, tài khoản khơng phải quản trị viên máy tính Windows 10, Windows 11 truy cập vào Trình quản lý tài khoản bảo mật Windows (SAM) Những tệp registry quan trọng khác SYSTEM SECURITY bị truy cập hacker khai thác thành công lỗ hổng III Các cách thức công Broken Access Control Bỏ qua kiểm tra kiểm soát quyền truy cập cách sửa đổi URL Các lỗ hổng phổ biến ID khơng an tồn : Thơng thường, ID sử dụng URL để xác định liệu mà người dùng muốn nhận Giả sử đăng nhập vào trang web ID người dùng 1337 Khi tơi vào trang hồ sơ riêng mình, URL trông này: https://example.com/profile?id=1337 Nhưng thay ID ID người dùng khác sao? https://example.com/profile?id=42 Nếu webserver cấu hình khơng đúng, tơi truy cập trang khác, ví dụ , tơi nhận trang hồ sơ người dùng khác, với tất liệu nhạy cảm họ Forced browsing người dùng cố gắng truy cập tài nguyên không ứng dụng tham chiếu, có sẵn  Ví dụ: ứng dụng web có trang quản trị, khơng có liên kết đến trang quản trị phần khác trang web, người dùng thơng thường khơng tìm thấy trang quản trị cách nhấp vào xung quanh Nhưng trực tiếp chỉnh sửa URL, ví dụ: truy cập , họ truy cập trang quản trị  https://example.com/admin Thư mục : Khi trang web lưu trữ liệu tệp khác nhau, máy chủ yêu cầu tên tệp làm tham số u cầu Ví dụ có ứng dụng web để đọc tiểu thuyết ngắn, URL trơng giống sau: https://example.com/novels?file=novel1.txt Ở phía máy chủ, có thư mục lưu trữ tất tiểu thuyết máy chủ tìm kiếm tên tệp cho thư mục Chẳng hạn, kẻ cơng lạm dụng hành vi cách truy cập URL https://example.com/novels?file= / / / / / /etc/passwd Mẫu lặp lại /-s cuối đến thư mục gốc kẻ cơng truy cập tệp từ Giai pháp : Trong hầu hết ví dụ trên, kẻ cơng sửa đổi URL, ứng dụng web đại, điều khơng hoạt động Ngày nay, hầu hết ứng dụng web sử dụng API phía máy chủ số mã javascript phía máy khách để giao tiếp với API Khi mã javascript gửi yêu cầu đến API, bạn khơng thấy điều URL Nói chung, yêu cầu giống với yêu cầu mà trình duyệt bạn gửi đến máy chủ bạn điều hướng đến URL Chúng yêu cầu HTTP, khác chút Rất may, hầu hết trình duyệt đại trang bị số công cụ dành cho nhà phát triển, thực hữu ích Với công cụ dành cho nhà phát triển, bạn kiểm tra u cầu mà trình duyệt bạn gửi, gửi Trong số trình duyệt (ví dụ: Firefox) có tùy chọn Chỉnh sửa Resend hữu ích Bạn làm điều tương tự ví dụ trên, thay sử dụng URL, bạn phải sử dụng công cụ phát triển để kiểm tra yêu cầu bạn thấy số thông số đáng ngờ, sửa đổi chúng gửi lại yêu cầu Khai thác từ APIs web chưa phân quyền API gì? API viết tắt Application Programming Interface phương thức trung gian kết nối ứng dụng thư viện khác Nó cung cấp khả truy xuất đến tập hàm hay dùng, từ trao đổi liệu ứng dụng Đặc điểm bật API API sử dụng mã nguồn mở, dùng với client hỗ trợ XML, JSON API có khả đáp ứng đầy đủ thành phần HTTP: URI, request/response headers, caching, versioning, content forma… Bạn sử dụng host nằm phần ứng dụng IIS Mơ hình web API dùng để hỗ trợ MVC như: unit test, injection, ioc container, model binder, action result, filter, routing, controller Ngồi ra, hỗ trợ RESTful đầy đủ phương thức như: GET, POST, PUT, DELETE liệu Các lỗ hổng API Các lỗ hổng xác thực tiếp quản tài khoản   Nhiều API khơng kiểm tra trạng thái xác thực có yêu cầu đến từ người dùng hãng Những kẻ công khai thác lỗ hổng theo nhiều cách khác nhau, chiếm quyền điều khiển phiên tài khoản, để bắt chước lệnh gọi API hãng Tội phạm mạng thực công nhồi thông tin xác thực để chiếm đoạt tài khoản người dùng   Thiếu mã hóa mạnh   Nhiều API thiếu mã hóa mạnh mẽ máy khách máy chủ API Những kẻ công khai thác lỗ hổng thông qua công MITM (man-inthe-middle) Theo đó, kẻ cơng chặn giao dịch API khơng mã hóa bảo vệ để đánh cắp thông tin nhạy cảm thay đổi liệu giao dịch Ngoài ra, việc sử dụng phổ biến thiết bị di động, hệ thống đám mây kiến trúc tiểu dịch vụ (Microservice) làm cho vấn đề bảo mật API trở nên phức tạp   Lỗ hổng logic kinh doanh   Các API dễ bị lạm dụng logic nghiệp vụ Đây lý cần phải có giải pháp quản lý chuyên dụng cần áp dụng phương pháp phát tốt ứng dụng web ứng dụng di động nhằm phát nhiều lỗi dương tính giả âm tính giả   Bảo mật điểm cuối   Hầu hết thiết bị IoT cơng cụ microservice lập trình để giao tiếp với máy chủ thông qua kênh API Các thiết bị tự xác thực máy chủ API chứng ứng dụng khách Khi tin tặc cố gắng giành quyền kiểm soát API từ điểm cuối IoT thành cơng, chúng dễ dàng xếp lại thứ tự API, dẫn đến vi phạm liệu Một số giải pháp bảo vệ API khỏi rủi ro bảo mật Các mối đe dọa lỗ hổng API đa dạng, bao gồm cấy mã độc, công giao thức, chuyển hướng không hợp lệ công bot Theo Radware, 1/3 số cơng chống lại API nhằm mục đích gây trạng thái từ chối dịch vụ (DoS) Bất chấp lỗ hổng bảo mật mà API gây nhiều DN có xu hướng cấp quyền truy cập API vào liệu nhạy cảm mà không kiểm tra API để phát hoạt động độc hại   Một số bước đơn giản mà bạn triển khai để giảm thiểu rủi ro bảo mật API   Thống kế hoạch bảo mật toàn hệ thống   Nếu nội tổ chức, công ty bạn gặp vấn đề liên quan đến bảo mật API, có khả biện pháp triển khai không phù hợp thiếu quán   Để giải vấn đề này, bên liên quan nên thảo luận việc làm để cộng tác tốt nhằm đề xuất triển khai sáng kiến bảo mật API phù hợp với tình hình thực tế Để làm sở cho họp này, nhóm nên tham khảo NIST Cybersecurity Framework Đây công cụ tuyệt vời để phát triển hiểu biết chung rủi ro an ninh mạng tồn tổ chức Nó giúp bên có nhận thức API sử dụng toàn tổ chức để xác định lỗ hổng tiềm ẩn quy trình liên quan, từ cải thiện chiến lược bảo mật API   Đưa vấn đề tìm cách tháo gỡ   Để cải thiện tình trạng bảo mật API tổ chức, điều quan trọng phải đưa vấn đề tồn tìm phương án giải tối ưu Hãy xem xét tổng thể API mà tổ chức bạn sử dụng, môi trường kinh doanh, quản trị, đánh giá rủi ro, chiến lược quản lý rủi ro, kiểm soát truy cập, kiện tình bất thường, giám sát bảo mật liên tục, quy trình phát hiện, v.v Hãy đảm bảo khơng có rủi ro bị bỏ sót   Thiết lập quy trình bảo mật API xuyên suốt bền vững   Ngoài việc thực hai bước trên, tổ chức, doanh nghiệp cần cân nhắc triển khai giải pháp hỗ trợ giám sát chương trình bảo mật API liên tục, qua tạo quy trình bảo mật API tồn diện mạnh mẽ, đồng thời hỗ trợ khả phát triển thích ứng số lượng API rộng thay đổi   Khả hiển thị kiểm kê tập trung tất API, chế độ xem chi tiết mẫu lưu lượng API, giám sát API truyền liệu nhạy cảm, đánh giá phù hợp đặc điểm kỹ thuật API liên tục, có chương trình xác thực, kiểm sốt truy cập chỗ chạy phân tích rủi ro tự động dựa tiêu chí xác định trước truy cập API, vị trí chúng cách chúng sử dụng… chìa khóa để xây dựng quy trình bảo mật API đủ linh hoạt để theo kịp thay đổi   Khi tổ chức, doanh nghiệp tiếp tục mở rộng việc sử dụng API để thúc đẩy hoạt động kinh doanh, điều quan trọng cần phải xem xét đường mà tội phạm mạng thực để cơng liệu quan trọng mình, từ xây dựng chiến lược hệ thống phịng thủ phù hợp Mã hóa API – API Encryption Dữ liệu API phải bảo vệ khỏi xem (và truy cập trái phép khác) thông qua mã hóa Tùy thuộc vào giao thức API cụ thể mà bạn làm việc với và cách thức triển khai, bạn sử dụng phương pháp sau để mã hóa API: HTTP: Nên thực để bảo vệ yêu cầu chuyển tiếp, để tin nhắn bảo mật mã hóa TLS JSON WEB TOKEN: Đối với liệu phản hồi JSON, mã thông báo web JSON (JWT) tiêu chuẩn mở xác định cách để truyền thơng tin cách an tồn dạng đối tượng JSON bên JWT ký cách sử dụng bí mật (với thuật tốn HMAC) cặp khóa cơng khai / riêng RSA PASSWORD HASH: Điều cần thiết để bảo vệ hệ thống (hoặc giảm thiểu thiệt hại), có thỏa hiệp nỗ lực hack Các thuật toán băm bao gồm MD5, SHA, PBKDF2,… Tấn công vào điểm cuối API phương thức phổ biến để ứng dụng hài hịa thơng qua API Việc bảo vệ chống lại kiểu công triển khai bảo mật cấp ứng dụng, sử dụng kỹ thuật sau:  Ross-site scripting – Các tập lệnh độc hại đẩy vào tham số yêu cầu  Code injection – Nạp code vào dịch vụ, chẳng hạn SQL (SQL injection) XQuery, để mở giao diện cho người dùng kiểm sốt  Business logic  – Cho phép kẻ cơng phá vỡ quy tắc kinh doanh  Parameter pollution attacks – Khai thác liệu gửi yêu cầu API cách sửa đổi tham số yêu cầu API  Input Validation – Áp dụng xác thực đầu vào nghiêm ngặt người dùng Nâng cao đặc quyền Sự leo thang đặc quyền xảy người dùng có quyền truy cập vào nhiều tài nguyên chức mức họ phép việc nâng cấp thay đổi phải ứng dụng ngăn chặn Điều thường lỗ hổng ứng dụng gây Kết ứng dụng thực hành động với nhiều đặc quyền so với dự định nhà phát triển quản trị viên hệ thống Mức độ leo thang phụ thuộc vào đặc quyền mà kẻ công phép sở hữu đặc quyền nhận khai thác thành cơng Ví dụ: lỗi lập trình cho phép người dùng có thêm đặc quyền sau xác thực thành công giới hạn mức độ leo thang, người dùng ủy quyền để giữ số đặc quyền Tương tự vậy, kẻ công từ xa giành đặc quyền người quản trị mà khơng cần xác thực có mức độ leo thang lớn  leo thang theo chiều dọc khi truy cập tài nguyên cấp cho tài khoản đặc quyền ví dụ: có đặc quyền quản trị cho ứng dụng leo thang theo chiều ngang khi truy cập tài nguyên cấp cho tài khoản định cấu hình tương tự ví dụ: ứng dụng ngân hàng trực tuyến, truy cập thông tin liên quan đến người dùng khác Tấn công Trong phần ứng dụng nơi người dùng tạo thơng tin sở liệu (ví dụ: tốn, thêm liên hệ gửi tin nhắn), nhận thơng tin (sao kê tài khoản, chi tiết đơn đặt hàng, v.v.) xóa thông tin (thả người dùng, tin nhắn, v.v.), cần phải ghi lại chức đó. Người thử nghiệm nên cố gắng truy cập chức với tư cách người dùng khác để xác minh xem truy cập vào chức mà vai trò / đặc quyền người dùng khơng cho phép hay khơng (nhưng cho phép với tư cách người dùng khác) Ví dụ : Thao túng nhóm người dùng Ví dụ: HTTP POST sau cho phép người dùng thuộc về grp001thứ tự truy cập # 0001: POST /user/viewOrder.jsp HTTP/1.1 Host: www.example.com groupID=grp001&orderID=0001 Xác minh xem người dùng không thuộc quyền sở hữu grp001có thể sửa đổi giá trị tham số groupIDvà orderIDcó quyền truy cập vào liệu đặc quyền hay khơng Cấu hình sai CORS cho phép truy cập API trái phép Hồn cảnh đời Từng có tiêu chuẩn SOP - Same-origin Policy giới hạn việc chia sẻ thông tin ứng dụng domain giúp tăng mức độ bảo mật cho website Tuy nhiên với phát triển ứng dụng web đặc biệt kiến trúc microservice - chia nhỏ ứng dụng lớn thành nhiều phần nhỏ độc lập, lượng thông tin lúc cần chia sẻ nhiều trang với Do để tăng múc độ bảo mật việc di chuyển thông tin domain khác nhau, tiêu chuẩn CORS - Cross-origin resource sharing đời 10 Khái niệm chung CORS hay chia sẻ tài nguyên đa nguồn chế cho phép trình duyệt web thực yêu cầu với miền khác qua việc sử dụng API HttpRequest cách có kiểm sốt qua việc kiểm tra nguồn gốc, miền khởi tạo yêu cầu, giao thức sử dụng trình duyệt server để xác định cho phép truy cập Có nhiều key HTTP headers liên quan đến CORS trường sau có ảnh hưởng lớn để bảo mật thôn tin  Access-Control-Allow-Origin: Phân loại domain truy cập vào resource domain  Access-Control-Allow-Credentials: định trình duyệt (true) (false) gửi cookies với request 11  Access-Control-Allow-Methods định phương thức HTTP (GET, PUT, ) truy cập vào tài nguyên Những sai lầm cấu hình cách thức khia thác 1/ Đặt giá trị * - giá trị mặc định cho trường Access-Control-Allow-Origin Đây sai lầm phổ biến Việc cấu cho phép domain gửi request đến resources Giải pháp Cấu hình CORS cẩn thận Chỉ tin tưởng domain đáng tin cậy Không sử dụng giá trị null cho origin header Áp dụng việc xác thực với domain nội Nếu sử dụng cookie TLS để tăng tính bảo mật Đừng tin thứ người dùng gửi lên, kể header Tấn công mã thông báo web JSON (JWT) Khái niệm chung JWT - Json Web Token chuẩn mở định nghĩa dạng truyền thông tin rút gọn bảo mật thông tin dạng đối tượng JSON Thông tin xác thực chữ ký số, ký thuật tốn bí mật ( với thuật tốn HMAC ) với cặp mã cơng khai / bí mật với RSA JWT thường sử dụng với mục đích phổ biến: 12 1/ Authorization - Ủy quyền: Một người dùng đăng nhập, yêu cầu gửi lên máy chủ bao gồm JWT, cho phép người dùng truy cập tài nguyên sử dụng dịch vụ từ máy chủ Single Sign On - Đăng nhập lần tính phổ biến có tính ứng dụng từ JWT, nhỏ gọn dễ dàng việc truyền qua lại miền khác 2/ Trao đổi thông tin: JWT giúp việc trao đổi thơng tin trở nên an toàn hiệu Do việc JWT sử dụng chữ ký số giúp xác thực người gửi tính trọn vẹn nội dung thơn điệp gửi Cấu trúc Gồm phần: header, payload, signature theo dạng xxx.yyy.zzz Header: thường gồm phần: loại token thuật tốn sử dụng để kí số HMAC, RSA, …  Payload: chứa claims - biểu thức thực thể (ví dụ: user, ) số metadata phụ trợ Có loại claims phổ biến - Reverse Claim: Đây tập hợp xác nhận quyền sở hữu xác định trước, không bắt buộc khuyến nghị, để cung cấp tập hợp xác nhận quyền sở hữu hữu ích, tương tác Một số số là: Iss (nhà phát hành), exp (thời gian hết hạn), sub (chủ đề), aud (khán giả) - Public Claims: claim công nhận sử dụng rộng rãi - Private Claims: claim tự định nghĩa, xác nhận quyền sở hữu để chia sẻ thông tin bên đăng ký trước Signature: Chữ ký JWT chuỗi mã hóa header, payload, chuỗi bí mật theo nguyên tắc 13 Ba phần mã hóa riêng Base64Url nối với dấu chấm để tạo JWT Ví dụ JWT Lỗ hổng bảo mật phổ biến Không xác thực chữ kí số Nhiều thư viện JWT cung cấp phương thức để giải mã phương thức khác để xác thực  decode(): Chỉ giải mã token từ đoạn mã hóa base64url khơng xác thực chữ ký số  verify(): Giải mã token xác thực chữ ký số  Một số lập trình viên lẫn lộn phương thức Nếu chữ ký số không xác thực, ứng dụng chấp nhận token (dựa cấu trúc) Lập Trình viên tắt tính xác thực chữ ký để kiểm tra trình phát triển quên không bật lại Rất nhiều sai lầm khác dẫn tới việc truy cập trái phép hay leo thang đặc quyền Ví dụ, đoạn token khơng xác thực 14 Kẻ cơng gửi token với chữ ký tùy ý để leo thang đặc quyền Lỗ hổng None-Algorithm Chuẩn JWT cho phép nhiều loại thuật tốn khác để tạo chữ kí số RSA, HMAC, Elliptic Curve, None Việc không sử dụng thuật tốn nghĩa token khơng ký Khi đó, kẻ cơng bỏ qua việc kiểm tra chữ ký cách thay đổi thuật tốn có thành khơng hủy chữ kí Ví dụ ta có đoạn token Sau mã hóa kí, token chuyển thành dạng sau (chữ kí in đậm) 15 Nếu giá trị trường “alg” none, kẻ cơng thay giá trị thuật tốn cho phép sau loại bỏ chữ ký Giờ đây, token sau bị chỉnh sửa ứng dụng chấp nhận Sự nhầm lẫn thuật toán(Algorithm confusion) Trong JWT chấp nhận thuật tốn mã hóa đối xứng mã hóa bất đối xứng Tùy thuộc vào loại mã hóa, bạn cần sử dụng shared secret cặp khóa public-private Thuật tốn Chìa khóa dùng để ký Khóa sử dụng để xác minh Khơng đối xứng (RSA) Private key Public key Đối xứng (HMAC) Shared secret Shared secret Khi ứng dụng sử dụng mã hóa bất đối xứng, cơng khai khóa cơng khai giữ bí mật khóa riêng tư. Điều cho phép ứng dụng ký mã thơng báo khóa riêng xác minh mã thơng báo khóa cơng khai nó. Lỗ hổng nhầm lẫn thuật tốn phát sinh ứng dụng khơng kiểm tra xem thuật tốn mã thơng báo nhận có khớp với thuật tốn mong đợi hay không Trong nhiều thư viện JWT, phương pháp để xác minh chữ ký là: 16  verify(token, secret) - mã thông báo ký với HMAC  verify(token, publicKey) - mã thông báo ký RSA tương tự Thật không may, số thư viện, phương pháp tự khơng kiểm tra xem mã thơng báo nhận có ký hay khơng cách sử dụng thuật toán mong đợi ứng dụng. Đó lý trường hợp HMAC, phương pháp coi đối số thứ hai bí mật chia sẻ trường hợp RSA khóa cơng khai Nếu khóa cơng khai truy cập ứng dụng, kẻ cơng giả mạo mã thông báo độc hại cách: Thay đổi thuật toán mã thơng báo thành HMAC Giả mạo trọng tải để có kết mong muốn Ký mã độc hại khóa cơng khai tìm thấy ứng dụng Gửi JWT trở lại ứng dụng Ứng dụng mong đợi mã hóa RSA, kẻ cơng cung cấp HMAC thay thế, verify() phương pháp coi khóa cơng khai bí mật chia sẻ HMAC sử dụng mã hóa đối xứng thay bất đối xứng. Điều có nghĩa mã thơng báo ký khóa cơng khai khơng bí mật ứng dụng sau xác minh khóa công khai Để tránh lỗ hổng này, ứng dụng phải kiểm tra xem thuật tốn mã thơng báo nhận có phải thuật tốn mong đợi hay không trước chuyển mã thông báo cho verify() phương thức Ngắn gọn là: máy chủ mong đợi token ký RSA, thực chất lại nhận token ký với HMAC, máy chủ nghĩ khóa cơng khai thực khóa bí mật HMAC Using trivial secrets Đơn giản người lập trình chọn jwt secret dễ đốn khơng đủ mạnh mẽ giúp cho hacker bẻ khóa cách dễ dàng kid parameter injections Kid ? (Key Identifier) - Chứa id khóa sử dụng để mã hóa - ứng dụng sử dụng để biết khóa sử dụng xác minh chữ kí 17 - Điều cho phép người gửi báo hiệu thay đổi khóa cho người nhận { "alg": "HS256", "typ": "JWT", "kid": "key1" } { "name": "John Doe", "user_name": "john.doe", "is_admin": false } Tấn công : key |Paramater Nếu paramater đưa vào, mở cách để bỏ qua chữ ký chí công RCE, SQLi LFI Nếu tham số kid dễ bị chèn lệnh, sửa đổi sau dẫn đến thực thi mã từ xa: { "alg": "HS256", "typ": "JWT", "kid": "key1|/usr/bin/uname" } { "name": "John Doe", "user_name": "john.doe", "is_admin": false } 18 kid parameter injection + directory traversal = signature bypass: Nếu ứng dụng sử dụng kid tham số để truy xuất khóa từ hệ thống tệp, ứng dụng dễ bị truyền qua thư mục . Sau đó, kẻ cơng buộc ứng dụng sử dụng tệp có giá trị mà kẻ cơng dự đốn làm khóa để xác minh. Điều thực cách sử dụng tệp tĩnh ứng dụng. Biết giá trị tệp chính, kẻ cơng tạo mã thơng báo độc hại ký cách sử dụng khóa biết Kẻ cơng cố gắng chèn /dev/null làm nguồn khóa để buộc ứng dụng sử dụng khóa trống: Nếu truyền qua thư mục /dev/null thành công, kẻ công ký mã thơng báo độc hại cách sử dụng chuỗi trống.  kid parameter injection + SQL injection = signature bypass Nếu ứng dụng sử dụng “kid” tham số để truy xuất khóa từ sở liệu, dễ bị chèn sql . Nếu thành cơng, kẻ cơng kiểm sốt giá trị trả về “kid” tham số từ truy vấn SQL sử dụng để ký mã thơng báo độc hại Một lần sử dụng mã thơng báo ví dụ, giả sử ứng dụng sử dụng truy vấn SQL dễ bị cơng sau để lấy khóa JWT thơng qua “kid” tham số: Sau đó, kẻ cơng đưa một “UNION SELECT” câu lệnh vào “kid” tham số để kiểm sốt giá trị khóa: 19 Nếu SQL injection thành công, ứng dụng sử dụng truy vấn sau để truy xuất khóa chữ ký: Truy vấn trở lại “aaa” vào “kid” tham số, cho phép kẻ công để ký mã thông báo độc hại đơn giản với “aaa”.  Để tránh công công tiêm khác, ứng dụng phải làm giá trị của “kid”tham số trước sử dụng Giai pháp cho mã thơng báo JWT Xóa mã thơng báo lưu trữ khỏi phía máy khách đăng xuất Khi đăng xuất từ phía khách hàng, cách dễ xóa mã thơng báo khỏi lưu trữ trình duyệt Nhưng, Điều xảy bạn muốn hủy mã thông báo Node server Vấn đề với gói JWT khơng cung cấp phương pháp hay cách thức để phá hủy mã thơng báo Vì vậy, để hủy mã thơng báo máy chủ, bạn sử dụng gói jwt-redis thay JWT Thư viện (jwt-redis) lặp lại hồn toàn toàn chức thư viện jsonwebtoken, với bổ sung quan trọng Jwt-redis cho phép bạn lưu trữ nhãn mã thông báo redis để xác minh tính hợp lệ làm cho mã thơng báo khơng hợp lệ Để hủy mã thơng báo jwt-redis, có phương thức hủy hoạt động theo cách này: 20 1) Cài đặt jwt-redis từ npm 21 ... LỤC II.Cấu trúc Broken Access Control Khái niệm Broken Access Control Điểm yếu bảo mật 3 Các yếu tố tác động Các lỗ hổng xảy III Các cách thức công Broken Access Control Bỏ qua...  Ví dụ: ứng dụng web có trang quản trị, khơng có liên kết đến trang quản trị phần khác trang web, người dùng thơng thường khơng tìm thấy trang quản trị cách nhấp vào xung quanh Nhưng trực tiếp... APIs web chưa phân quyền .6 Nâng cao đặc quyền 10 Cấu hình sai CORS cho phép truy cập API trái phép .11 Tấn công mã thông báo web JSON (JWT) .12 II Cấu trúc Broken Access Control
- Xem thêm -

Xem thêm: AN TOÀN ỨNG DỤNG WEB VÀ CSDL đề TÀI BROKEN ACCESS CONTROL , AN TOÀN ỨNG DỤNG WEB VÀ CSDL đề TÀI BROKEN ACCESS CONTROL

Mục lục

Xem thêm