API xuất hiện trong những ngày đầu của máy tính, trước cả máy tính cá nhân. Vào thời điểm đó, API thường được sử dụng làm thư viện cho các hệ điều hành. API hầu như làm việc độc lập đối với các hệ thống mà nó hoạt động, mặc dù đôi khi nó chuyển các thông báo giữa các máy tính lớn. Sau gần 30 năm, các API đã thoát ra khỏi môi trường riêng của chúng. Đến đầu những năm 2000, chúng đã trở thành một công nghệ quan trọng để tích hợp dữ liệu từ xa. API được coi là khớp nối giữa các thành phần phần mềm, giúp các phần mềm giao tiếp với nhau và tận dụng năng lực của nhau. Ví dụ, mỗi trải nghiệm trên máy tính đều là kết quả kết hợp của nhiều phần mềm: hệ điều hành, ứng dụng, dịch vụ web, phần mềm trên máy chủ… Nếu không sử dụng API, mỗi nhà sản xuất ứng dụng hay nhà thiết kế web đều sẽ phải thực hiện thêm rất nhiều công việc đồ sộ nằm ngoài trọng tâm của họ. API cho phép sản phẩm hoặc dịch vụ của giao tiếp với các sản phẩm và dịch vụ khác mà không cần biết chúng được triển khai như thế nào. Điều này có thể đơn giản hóa việc phát triển ứng dụng, tiết kiệm thời gian và tiền bạc. Khi đang thiết kế các công cụ và sản phẩm mới, hoặc quản lý các API hiện có, API cho phép linh hoạt, đơn giản hóa thiết kế, quản trị và sử dụng. API là một phần không thể thiếu đối với việc thiết kế và phát triển application. Nó được sử dụng trong bất cứ application thuộc bất cứ lĩnh vực nào: tài chính, bán hàng, quảng cáo, IoT…, Microservices đang là hướng phát triển application chủ đạo hiện nay và API là giải pháp phổ biến nhất để giao tiếp giữa các services. API được sử dụng để làm cầu nối giữa các services, cung cấp các dịch vụ và quan trọng nhất là truyền dữ liệu. Dữ liệu là thứ mà các hacker muốn lấy. Chính vì thế, cũng dễ hiểu khi API là mục tiêu tấn công hàng đầu của hacker. Nếu không được bảo mật đầy đủ, các thông tin này có thể bị lộ, từ đó hacker có thể đoán được logic hiện tại, các thông tin mật của khách hàng... và gây thiệt hại nặng nề. Và chẳng ai mong muốn mình bị hack cả. Chính vì thế bảo mật API nên là vấn đề được quan tâm đối với bất kì ứng dụng nào đang sở hữu và sử dụng API. Mục tiêu của việc nghiên cứu thực hiện đồ án tốt nghiệp với đề tài “Tìm hiểu kỹ thuật tấn công khai thác API và đề xuất biện pháp bảo vệ” là tìm hiểu các cách thức, kỹ thuật tấn công khai thác các lỗ hổng của Web API và đưa ra các biện pháp đảm bảo an toàn cho Web API trước các cuộc tấn công này. Nội dung đồ án gồm 4 chương: - Tổng quan về API - Một số tấn công đối với Web API - Giải pháp đảm bảo an toàn Web API - Xây dựng mô hình thực nghiệm tấn công khai thác Web API
Tổng quan về API
Tìm hiểu chung về API
API là tên viết tắt của từ Application Programming Interface, hay còn gọi là giao diện lập trình của ứng dụng API có khả năng cung cấp việc truy xuất đến một trong các hàm hay sử dụng Từ đó, nó có thể trao đổi được các dữ liệu giữa một số ứng dụng cụ thể API có thể sử dụng cho web-based system, operating system, database system, computer hardware và software library
API không phải là một ngôn ngữ lập trình, mà là các hàm hoặc thủ tục thường được viết bằng nhiều ngôn ngữ lập trình khác nhau.
Web API: Là một dạng phương thức được sử dụng để cho phép các ứng dụng khác nhau có thể giao tiếp được với nhau bằng cách trao đổi dữ liệu qua lại Dữ liệu này được Web API trả lại dưới dạng JSON hoặc XML thông qua các giao thức HTTP hoặc HTTPS Hệ thống API được sử dụng trong các hệ thống website, chẳng hạn:
Google, Facebook… Hầu hết các website đều cung cấp hệ thống API cho phép kết nối, lấy dữ liệu hoặc cập nhật cơ sở dữ liệu Đa số Web API được thiết kế theo tiêu chuẩn RESTful
API trên hệ điều hành: Windows hay Linux có rất nhiều API Họ cung cấp các tài liệu API là đặc tả các hàm, phương thức cũng như các giao thức kết nối Nó giúp lập trình viên có thể tạo ra các phần mềm ứng dụng có thể tương tác trực tiếp với hệ điều hành
API của thư viện phần mềm (framework): API mô tả và quy định các hành động mong muốn mà các thư viện cung cấp Một API có thể có nhiều cách triển khai khác nhau, giúp cho một chương trình viết bằng ngôn ngữ này có thể sử dụng được thư viện viết bằng ngôn ngữ khác
1.1.3 Tìm hiểu về Web API
Web API là một phương thức dùng để cho phép các ứng dụng khác nhau có thể giao tiếp, trao đổi dữ liệu qua lại Dữ liệu được Web API trả lại thường ở dạng JSON hoặc XML thông qua giao thức HTTP hoặc HTTPS
Web API hỗ trợ Restful đầy đủ các phương thức: Get/Post/Put/Delete dữ liệu
Nó giúp lập trình viên xây dựng các HTTP service một cách rất đơn giản và nhanh chóng Nó cũng có khả năng hỗ trợ đầy đủ các thành phần HTTP: URI, request/response headers, caching, versioning, content format
- Tự động hóa sản phẩm: Với web API, nhà phát triển sẽ tự động hóa quản lý công việc, cập nhật luồng công việc, giúp tăng năng suất và tạo hiệu quả công việc cao hơn
API cho phép tích hợp linh hoạt, liền mạch, dễ dàng lấy nội dung từ bất kỳ website hoặc ứng dụng nếu được cho phép, gia tăng trải nghiệm người dùng Hoạt động như một cổng giao tiếp, API giúp các công ty an toàn chia sẻ thông tin được chọn mà không lo ngại bị truy xuất trái phép.
- Cập nhật thông tin thời gian thực: API có chức năng thay đổi và cập nhật thay đổi theo thời gian thực Với công nghệ này, dữ liệu sẽ được truyền đi tốt hơn, thông tin chính xác hơn, dịch vụ cung cấp linh hoạt hơn
- Có tiêu chuẩn chung dễ sử dụng: Bất kỳ người dùng, công ty nào sử dụng cũng có thể điều chỉnh nội dung, dịch vụ mà họ sử dụng Hỗ trợ đầy đủ các thành phần MVC như: routing, controller, action result, filter, model binder, IoC container, dependency injection, unit test
1.1.3.2 Cách hoạt động Web API - Đầu tiên là xây dựng URL API để bên thứ ba có thể gửi request dữ liệu đến máy chủ cung cấp nội dung, dịch vụ thông qua giao thức HTTP hoặc HTTPS
3 - Tại web server cung cấp nội dung, các ứng dụng nguồn sẽ thực hiện kiểm tra xác thực nếu có và tìm đến tài nguyên thích hợp để tạo nội dung trả về kết quả
- Server trả về kết quả theo định dạng JSON hoặc XML thông qua giao thức HTTP/HTTPS
- Tại nơi yêu cầu ban đầu là ứng dụng web hoặc ứng dụng di động, dữ liệu JSON/XML sẽ được parse để lấy data Sau khi có được data thì thực hiện tiếp các hoạt động như lưu dữ liệu xuống Cơ sở dữ liệu, hiển thị dữ liệu…
1.1.3.3 Ưu và nhược điểm Web API
An toàn với Web API
1.2.1 Các nguy cơ bảo mật với Web API
Các công ty sử dụng API để phục vụ khách hàng của họ Cho dù người dùng đang sử dụng trình duyệt web hay ứng dụng dành cho thiết bị di động, thì có lẽ họ đang kết nối với một API Chúng giúp nâng cấp trải nghiệm người dùng, thêm sản phẩm mới và giao tiếp với các doanh nghiệp mới và thị trường mới dễ dàng hơn
Nhưng API cũng gây ra các vấn đề về bảo mật Khi người dùng cung cấp cho tin tặc một giao diện, chúng sẽ khiến giao diện đó làm những điều người dùng không ngờ tới
Một số dịch vụ yêu cầu tích hợp phần mềm, ứng dụng hoặc hệ thống do người dùng cuối thực hiện và API giúp kết nối này trở nên khả thi Tuy nhiên, sự phát triển công nghệ không ngừng cũng khiến các kênh này trở thành nơi dễ bị tin tặc tấn công.
1.2.1.1 Những rủi ro chính trong bảo mật API
Khi ngày càng có nhiều doanh nghiệp triển khai API, nguy cơ bị tấn công API cũng gia tăng theo Trên thực tế, số lượng API được sử dụng bởi các doanh nghiệp đang tăng nhanh chóng; gần một nửa số doanh nghiệp có từ 50-500 API được triển khai nội bộ hoặc công khai, thậm chí một số doanh nghiệp còn có hơn 1.000 API đang hoạt động Thực tế đó đã đặt ra những thách thức trong việc bảo mật dữ liệu
5 trong API Hiện nay, các lỗ hổng tồn tại trong API đang ngày càng tăng lên như các lỗ hổng về xác thực, phân quyền hay việc vô tình để lộ dữ liệu nhạy cảm
Tổ chức bảo mật nổi tiếng Gartner xác nhận bảo mật API là mối quan tâm hàng đầu của các doanh nghiệp hiện nay Theo dự đoán của Gartner, hơn 30,9 tỷ thiết bị IoT dự kiến sẽ được sử dụng trên toàn thế giới vào năm 2025 và con số này tiếp tục tăng lên hàng năm Sự gia tăng các thiết bị IoT, kéo theo các nguy cơ về bảo mật API Theo báo cáo thực trạng internet về hình thức tấn công API do Akamai Technologies thực hiện từ tháng 1/2020 đến tháng 6/2021, số cuộc tấn công có liên quan đến API có chiều hướng tăng dần, đặc biệt có thời điểm hệ thống của Akamai ghi nhận đến 113,8 triệu cuộc tấn công/ngày (hình 1.1) Con số này cao gấp 3 lần so với cùng kỳ năm 2020
Hình 1.1 Thống kê tấn công API
Ngoài ra, các doanh nghiệp lớn càng dễ bị ảnh hưởng bởi các rủi ro bảo mật liên quan đến các API bị lộ hoặc không được bảo vệ khi các doanh nghiệp đẩy nhanh quá trình chuyển đổi số Nguyên nhân do nhiều API được kết nối trực tiếp với cơ sở dữ liệu phụ trợ, nơi dữ liệu nhạy cảm được lưu trữ Do đó, tin tặc ngày càng nhắm mục tiêu vào các API như một phương thức để tấn công cơ sở hạ tầng nhằm đánh
6 cắp thông tin nhạy cảm Ngày nay, cứ 13 sự cố mạng thì có đến một sự cố được cho là có liên quan tới việc API không an toàn Có thể kể tới một số rủi ro bảo mật API như sau:
Các API bị lỗi thiết kế, cấu hình: có rất nhiều lựa chọn để truyền dữ liệu đến máy chủ web trong các yêu cầu HTTP (HyperText Transfer Protocol) Trong các trang web, các cách phổ biến nhất là thông qua các chuỗi truy vấn, JSON (JavaScript Object Notation) và nhiều yêu cầu POST Trong API, dữ liệu thường sẽ được truyền qua XML (Extensible Markup Language) hoặc JSON thay vì các forms Khi các header HTTP này bị cấu hình sai, sẽ tạo ra các lỗ hổng bảo mật nguy hiểm, là cơ hội cho các kẻ tấn công khai thác
Tấn công phần mềm độc hại: kẻ tấn công khai thác các lỗ hổng thông qua các cuộc tấn công xen giữa MITM (Man-in-the-Middle), tấn công từ chối dịch vụ phân tán DDoS (Distributed Denial of Service), tấn công SQL (Structured Query Language)… để đánh cắp các thông tin nhạy cảm hoặc thay đổi dữ liệu giao dịch
Không cập nhật phần mềm đầy đủ, thường xuyên: các phiên bản API cũ hơn, kém an toàn hơn khiến chúng dễ bị tấn công và bị đánh cắp dữ liệu hơn Các nghiên cứu đã chỉ ra rằng, 60% nạn nhân của vụ vi phạm dữ liệu đã bị tấn công vì một lỗ hổng đã biết có thể đã được vá bằng bản cập nhật phần mềm Lỗ hổng trong an ninh mạng là rủi ro nghiêm trọng nhất, đòi hỏi người dùng phải cập nhật phần mềm thường xuyên Khi một lỗ hổng bảo mật mới được xác định, các nhà phát triển sẽ phát hành bản cập nhật phần mềm để sửa chữa nó Trong thời gian gần đây, điều kiện làm việc từ xa cũng làm gia tăng đáng kể rủi ro an ninh mạng
1.2.1.2 Vấn đề phổ biến liên quan bảo mật API
Injection hay SQL Injection là một lỗi khá phổ biến Những kẻ tấn công lợi dụng lỗ hổng của việc kiểm tra dữ liệu đầu vào trong các ứng dụng web đến hệ thống quản lý cơ sở dữ liệu (DBMS) để khai thác các thông tin nhạy cảm
7 Cách khắc phục: Ràng buộc thật kỹ dữ liệu người dùng nhập vào Có thể dùng Regular Expression để loại bỏ đi các ký tự lạ hoặc các ký tự không phải là số hoặc dùng các hàm có sẵn để giảm thiểu lỗi
Các dạng request được để ở chế độ công khai thường rất dễ vướng phải vấn đề bị spam Ví dụ như sau: Chỉ cần người dùng có thể hoàn thành được username và password để đăng ký tài khoản Thì một vài người có thể sẽ viết một đoạn script để gửi request liên tiếp cho các server Server này cần phải xử lý hết được các request này và thực hiện đăng ký liên tục
Để ngăn chặn các cuộc tấn công giả mạo yêu cầu trang web, bạn có thể tăng độ phức tạp cho các yêu cầu này bằng cách thêm câu hỏi bảo mật, yêu cầu người dùng chờ trong giây lát rồi mới thực hiện thao tác tiếp theo hoặc sử dụng các biện pháp tăng cường tính bảo mật khác.
1.2.2 Các phương án bảo mật API
Kết luận chương 1
API đóng vai trò vô cùng quan trọng và phổ biến trong ngành công nghệ thông tin Trong phạm vi chương này, ta đã nhắc lại những nét khái quát về API, Web API
Có thể thấy rằng, có rất nhiều nguy cơ, rủi ro bảo mật với Web API từ cả trong và ngoài hệ thống Nhiều vấn đề liên quan đến bảo mật như Injection, Spam Request, Authentication Attacking Từ đó giúp các nhà phát triển hình thành các giải pháp bảo mật nhằm bảo vệ cho API được an toàn, tránh bị tấn công từ mọi phía
Như vậy, việc bảo đảm an toàn cho API rất quan trọng Bảo mật API cũng chính là bảo vệ cho dữ liệu của các tổ chức doanh nghiệp, dữ liệu cá nhân người dùng.
Một số tấn công đối với Web API
Kỹ thuật Injection
Tấn công Injection là một trong những mối đe dọa chính trong lĩnh vực an ninh mạng Tấn công này bao gồm việc chèn các câu lệnh độc hại vào các truy vấn SQL hoặc mã nguồn của ứng dụng Web API để lấy thông tin hoặc thực hiện các hành động trái phép Chiến thuật tấn công được thực hiện rất bài bản:
- Phát hiện: Kẻ tấn công sẽ phát hiện các lỗ hổng bảo mật trong hệ thống mạng bằng cách thực hiện các cuộc quét và kiểm tra của các ứng dụng web
- Xác định mục tiêu: Sau khi tìm thấy lỗ hổng bảo mật, kẻ tấn công sẽ xác định mục tiêu tiếp theo của họ, ví dụ như lấy thông tin đăng nhập của người dùng hoặc thực hiện các hành động độc hại trên máy chủ
- Chuẩn bị: Kẻ tấn công sẽ chuẩn bị các công cụ và kỹ thuật cần thiết để thực hiện tấn công Injection, bao gồm việc tìm kiếm các câu lệnh độc hại và phương pháp để chèn chúng vào các truy vấn SQL hoặc mã nguồn của ứng dụng web
- Thực hiện: Kẻ tấn công sẽ thực hiện việc chèn các câu lệnh độc hại vào các truy vấn SQL hoặc mã nguồn của ứng dụng web, nhằm lấy thông tin hoặc thực hiện các hành động trái phép
- Che giấu: Sau khi thực hiện tấn công, kẻ tấn công sẽ cố gắng che giấu các dấu vết của họ để tránh bị phát hiện
Việc phân tích các chiến thuật của tấn công Injection là rất quan trọng để phát hiện và ngăn chặn các cuộc tấn công này Các chuyên gia an ninh mạng thường sử dụng các công cụ phát hiện tấn công Injection và triển khai các biện pháp bảo vệ để giảm thiểu nguy cơ tấn công này
Kẻ tấn công sử dụng các kỹ thuật Exploit để thực hiện các cuộc tấn công Injection:
- SQL Injection: Kỹ thuật này liên quan đến việc đưa các lệnh SQL độc hại vào các trường nhập liệu của ứng dụng để có quyền truy cập vào cơ sở dữ liệu của nó Sau đó, những kẻ tấn công có thể lấy thông tin nhạy cảm hoặc thao túng dữ liệu trong cơ sở dữ liệu
11 - Cross-site scripting (XSS): Kẻ tấn công có thể chèn mã độc vào trường nhập liệu của trang web, sau đó mã này có thể thực thi trong trình duyệt web của nạn nhân Điều này cho phép kẻ tấn công đánh cắp tokens phiên, cài đặt phần mềm độc hại hoặc chuyển hướng người dùng đến các trang web độc hại
- Command Injection: Kẻ tấn công có thể đưa các lệnh độc hại vào các trường đầu vào của hệ thống, cho phép chúng thực thi các lệnh tùy ý trên hệ thống Điều này có thể cung cấp cho kẻ tấn công khả năng chạy mã tùy ý hoặc kiểm soát hệ thống
- File inclusion: Kẻ tấn công có thể đưa đường dẫn tệp độc hại vào trường nhập liệu của ứng dụng, sau đó có thể khiến ứng dụng tải và thực thi tệp độc hại Điều này có thể cho phép kẻ tấn công chạy mã tùy ý hoặc giành quyền truy cập vào các tệp nhạy cảm trên hệ thống
- Buffer overflow: Chiến thuật này liên quan đến việc đưa nhiều dữ liệu vào bộ đệm hơn mức nó có thể chứa, khiến nó tràn vào các vị trí bộ nhớ liền kề
Những kẻ tấn công có thể sử dụng chiến thuật này để ghi đè lên dữ liệu quan trọng hoặc thực thi mã tùy ý
- XML injection: Kẻ tấn công có thể đưa mã độc hại vào các tài liệu XML được ứng dụng web sử dụng, khiến ứng dụng hoạt động theo những cách ngoài ý muốn Điều này có thể cho phép kẻ tấn công truy cập dữ liệu nhạy cảm hoặc chiếm quyền kiểm soát ứng dụng
- LDAP injection: Tương tự như SQL injection, LDAP injection liên quan đến việc đưa mã độc vào các trường đầu vào của ứng dụng tương tác với máy chủ LDAP Những kẻ tấn công có thể sử dụng chiến thuật này để giành quyền truy cập trái phép vào các dịch vụ thư mục của mạng
- HTTP response splitting: Kẻ tấn công có thể đưa các ký tự độc hại vào header
HTTP, khiến máy chủ phản hồi bằng nhiều phản hồi thay vì một Điều này có thể cho phép kẻ tấn công đưa nội dung của chính chúng vào trang web hoặc đánh cắp dữ liệu nhạy cảm
12 - Code injection: Kẻ tấn công có thể đưa mã độc hại vào một ứng dụng hoặc hệ thống, khiến nó thực thi mã tùy ý Điều này có thể cho phép kẻ tấn công chiếm quyền kiểm soát hệ thống hoặc đánh cắp dữ liệu nhạy cảm
Kỹ thuật Attacking Authentication
Khi nói đến kiểm tra xác thực, sẽ thấy rằng nhiều lỗ hổng gây khó khăn cho các ứng dụng web trong nhiều thập kỷ đã được chuyển sang API: mật khẩu không hợp lệ và các yêu cầu về mật khẩu, thông tin xác thực mặc định, thông báo lỗi dài dòng và quy trình đặt lại mật khẩu không hợp lệ Ngoài ra, một số điểm yếu thường được tìm thấy trong API hơn nhiều so với các ứng dụng web truyền thống Xác thực API lỗi có nhiều dạng Có thể gặp phải tình trạng thiếu xác thực hoàn toàn, thiếu giới hạn cho các lần thử xác thực, việc sử dụng một tokens hoặc khóa duy nhất cho
25 tất cả các yêu cầu, tokens được tạo không đủ entropy và một số điểm yếu cấu hình Tokens web JSON (JWT) Phần này sẽ hướng dẫn về các cuộc tấn công xác thực cổ điển như tấn công brute-force và dò đoán mật khẩu, sau đó là các cuộc tấn công tokens dành riêng cho API, chẳng hạn như giả mạo tokens và tấn công JWT Nói chung, các cuộc tấn công này có chung mục tiêu là giành được quyền truy cập trái phép, cho dù điều này có nghĩa là chuyển từ trạng thái không có quyền truy cập sang trạng thái có quyền truy cập trái phép, giành quyền truy cập vào tài nguyên của người dùng khác hoặc chuyển từ trạng thái API hạn chế truy cập vào một trong những quyền truy cập đặc quyền
Loại tấn công này nhắm mục tiêu và cố gắng khai thác quy trình xác thực mà một API sử dụng để xác minh danh tính của người dùng, dịch vụ hoặc ứng dụng
Khai thác xác thực là một cuộc tấn công trong đó kẻ tấn công lợi dụng các giả định của tiến trình xác thực, chẳng hạn như mối quan hệ tin cậy hoặc tạo biến bí mật Không giống như Khai thác phi xác thực cho phép kẻ tấn công truy cập tài liệu mà không được xác thực, Khai thác xác thực cấp phép cho kẻ tấn công được chứng thực hợp lệ Nó không dựa vào các phiên xác thực trước đó như Khai thác các biến phiên, ID tài nguyên và thông tin xác thực đáng tin cậy khác Để thành công, kẻ tấn công thường kết hợp nhiều kỹ thuật tấn công.
Có một số kỹ thuật tấn công:
Tấn công Brute Force cho phép kẻ tấn công đoán tên người dùng, mật khẩu, số thẻ tín dụng hoặc khóa mật mã thông qua quá trình thử và sai tự động.
- Insufficient Authentication: Cho phép kẻ tấn công truy cập trang web chứa nội dung hoặc chức năng nhạy cảm mà không cần phải xác thực đúng cách
26 - Weak Password Recovery Validation: Cho phép kẻ tấn công truy cập trang web cung cấp cho chúng khả năng lấy, thay đổi hoặc khôi phục trái phép mật khẩu của người dùng khác
2.2.1 Tấn công xác thực cổ điển
Hình thức xác thực đơn giản nhất được sử dụng trong API: xác thực cơ bản Để xác thực bằng phương pháp này, người dùng cần nhập username, email hoặc password API RESTful không duy trì trạng thái, vì vậy nếu API sử dụng xác thực cơ bản trên API, thì username và password sẽ phải được cấp cho mọi yêu cầu Do đó, hệ thống thường chỉ sử dụng xác thực cơ bản như một phần của quy trình đăng ký Sau khi người dùng xác thực thành công, hệ thống sẽ cấp khóa API hoặc tokens
Hệ thống sẽ kiểm tra xem username và password có khớp với thông tin xác thực được lưu trữ hay không Nếu thông tin đăng nhập khớp, hệ thống sẽ đưa ra phản hồi thành công Nếu không khớp, API có thể đưa ra một trong nhiều phản hồi Hệ thống có thể chỉ gửi một phản hồi chung cho tất cả các lần thử xác thực không chính xác:
“Tên người dùng hoặc mật khẩu không chính xác” Điều này cho biết lượng thông tin ít nhất, nhưng đôi khi sẽ cùng cấp các thông tin cụ thể, hữu ích hơn Hệ thống có thể cho người dùng biết cụ thể rằng tên người dùng không tồn tại Sau đó, sẽ có hướng dẫn, gợi ý để người dùng đăng nhập đúng
2.2.1.1 Tấn công Password Brute-Force
Một trong những phương pháp đơn giản hơn để giành quyền truy cập vào API là thực hiện một cuộc tấn công brute-force Brute-force xác thực của API không khác mấy so với bất kỳ cuộc tấn công brute-force nào khác, ngoại trừ việc gửi yêu cầu tới một điểm cuối API, payload thường ở dạng JSON và các giá trị xác thực có thể được mã hóa base64 Các cuộc tấn công brute-force thường tốn thời gian nhưng nếu một API thiếu các biện pháp kiểm soát bảo mật để ngăn chặn các cuộc tấn công này thì kẻ tấn công sẽ dễ dành thực hiện thành công trong khoảng thời gian ngắn Dữ liệu dư thừa có thể tiết lộ các chi tiết kỹ thuật về tài khoản của người dùng, chẳng hạn như liệu người dùng có đang sử dụng xác thực đa yếu tố hay không, họ có mật khẩu mặc định hay không và tài khoản đã được kích hoạt hay chưa Nếu dữ liệu dư thừa
27 liên quan đến thông tin về người dùng, có thể cung cấp dữ liệu đó cho các công cụ có thể tạo danh sách mật khẩu lớn, được nhắm mục tiêu cho các cuộc tấn công brute- force Để thực sự thực hiện tấn công brute-force, có thể sử dụng các công cụ như brute force của Burp Suite hoặc Wfuzz Ví dụ sau sử dụng Wfuzz với một danh sách mật khẩu cũ phổ biến rockyou.txt: Để khám phá định dạng yêu cầu được sử dụng trong ví dụ này, kẻ tấn công đã cố gắng xác thực ứng dụng web bằng trình duyệt, sau đó ghi lại nỗ lực xác thực và sao chép cấu trúc của nó tại đây Trong trường hợp này, ứng dụng web đưa ra yêu cầu POST với tham số "email" và " mật khẩu" Cấu trúc của nội dung này sẽ thay đổi đối với từng API Trong ví dụ này, có thể thấy rằng kẻ tấn công đã chỉ định một email đã biết và sử dụng tham số FUZZ làm mật khẩu
- Tùy chọn -d cho phép làm mờ nội dung được gửi trong phần nội dung của yêu cầu POST
- Các dấu ngoặc nhọn theo sau chứa nội dung yêu cầu POST
- Tùy chọn hc ẩn phản hồi với một số mã phản hồi nhất định Điều này hữu ích nếu thường nhận được cùng một mã trạng thái, độ dài từ và số lượng ký tự trong nhiều yêu cầu Nếu biết phản hồi định dạng trông như thế nào, thì không cần phải xem hàng trăm hoặc hàng ngàn phản hồi tương tự
- Tùy chọn -hc giúp lọc ra những phản hồi không muốn xem Trong trường hợp đã thử nghiệm, yêu cầu không thành công điển hình dẫn đến mã trạng thái 405, nhưng điều này cũng có thể khác với từng API
- Tùy chọn -H cho phép thêm header vào yêu cầu Một số hệ thống API có thể đưa ra mã lỗi “Loại phương tiện không được hỗ trợ” HTTP 415 nếu không bao gồm header Content-Type:application/json khi gửi dữ liệu JSON trong phần nội dung yêu cầu
28 Khi request đã được gửi đi, có thể xem lại kết quả trong dòng lệnh Nếu tùy chọn -hc Wfuzz hoạt động hiệu quả, kết quả sẽ khá dễ đọc Mặt khác, mã trạng thái trong 200s và 300s là dấu hiệu tốt cho thấy đã có thông tin đăng nhập brute-force thành công
2.2.1.2 Đặt lại mật khẩu và xác thực đa yếu tố
Kết luận chương 2
Chương này đã đi sâu trình bày chi tiết một số kỹ thuật tấn công phổ biến như Injection, Attacking Authentication
Injection là lỗi phổ biến trong ứng dụng và API, dẫn đến nhiều lỗ hổng nghiêm trọng như SQL Injection, XML Injection Các lỗ hổng này thường khai thác dữ liệu trong quá trình xử lý hoặc sử dụng Để ngăn ngừa Injection, doanh nghiệp cần xác thực dữ liệu không đáng tin cậy và sử dụng danh sách chặn để từ chối đầu vào chứa ký tự nguy hiểm.
Tấn công Attacking Authentication phổ biến và rất nguy hiểm với hệ thống
Kẻ tấn công có thể tận dụng lỗ hổng trong API xác thực để xâm nhập vào hệ thống và truy cập vào các tài nguyên và chức năng không được phép Điều này có thể gây
45 ra sự xâm phạm vào dữ liệu quan trọng, thực hiện các hoạt động độc hại hoặc thậm chí kiểm soát toàn bộ hệ thống Nếu hệ thống không xử lý JWT một cách an toàn, kẻ tấn công có thể tìm ra các lỗi như lỗi xử lý phía máy chủ (server-side processing), lỗi xử lý phía máy khách (client-side processing) hoặc các lỗi khác liên quan đến việc xử lý và kiểm tra tính hợp lệ của JWT Kẻ tấn công có thể khai thác các lỗ hổng này để tấn công vào hệ thống
Giải pháp đảm bảo an toàn Web API
Thiết kế bảo mật API
An ninh là một phần không thể thiếu của bất kỳ dự án phát triển nào và cả cho các API Nó bắt đầu với việc thu thập các yêu cầu và tiến hành thông qua các giai đoạn thiết kế, phát triển, thử nghiệm, triển khai và giám sát Bảo mật mang lại rất nhiều thách thức trong thiết kế hệ thống Thật khó để xây dựng một hệ thống được bảo mật 100% Điều duy nhất có thể làm là khiến công việc của kẻ tấn công trở nên khó khăn hơn Trên thực tế, đây là triết lý được tuân theo trong khi thiết kế các thuật toán mật mã Sau đây thảo luận về một số thách thức chính trong thiết kế bảo mật
Để thiết kế bảo mật, cân bằng giữa bảo mật và sự thoải mái của người dùng là điều quan trọng Chính sách mật khẩu phức tạp yêu cầu mật khẩu dài và phức tạp, nhưng người dùng khó nhớ và thường phải ghi chép, dẫn đến giảm hiệu quả bảo mật Vì vậy, người dùng thường chọn mật khẩu ngắn và dễ nhớ, mục tiêu chính của kẻ tấn công muốn thực hiện brute-force.
Hiệu suất là một tiêu chí quan trọng khác Giả sử có một API được bảo mật bằng khóa và mỗi lệnh gọi API phải được ký điện tử Nếu khóa bị xâm phạm, kẻ tấn công có thể sử dụng khóa đó để truy cập API Làm thế nào để giảm thiểu tác động?
Có thể làm cho khóa chỉ hợp lệ trong một khoảng thời gian rất ngắn Vì vậy, bất cứ điều gì kẻ tấn công có thể làm với khóa bị đánh cắp đều bị giới hạn trong thời gian tồn tại của nó Trước tiên, mỗi ứng dụng khách phải kiểm tra thời hạn hiệu lực của khóa (trước khi thực hiện lệnh gọi API) và nếu nó đã hết hạn, hãy gọi đến máy chủ ủy quyền (nhà phát hành khóa) để tạo khóa mới Nếu làm cho thời gian tồn tại
47 quá ngắn, thì hầu như đối với mỗi lệnh gọi API, sẽ có một lệnh gọi đến máy chủ ủy quyền để tạo khóa mới Điều đó làm giảm hiệu suất - nhưng làm giảm đáng kể tác động của việc kẻ xâm nhập có được quyền truy cập vào khóa API Việc sử dụng TLS để bảo mật mức vận chuyển là một ví dụ điển hình khác TLS cung cấp khả năng bảo vệ dữ liệu trong quá trình chuyển tiếp Khi chuyển thông tin đăng nhập của mình cho Amazon hoặc eBay, những thông tin đăng nhập đó sẽ được chuyển qua kênh liên lạc bảo mật hoặc HTTP qua TLS, thực tế là HTTPS Không ai ở giữa có thể xem dữ liệu được truyền từ trình duyệt của đến máy chủ web (giả sử không có chỗ cho một cuộc tấn công trung gian) Nếu bất kỳ ai đăng nhập tất cả các tin nhắn vào và ra đến và đi từ máy chủ web của ngân hàng, thì thông tin đăng nhập của sẽ được ghi ở dạng văn bản thuần túy Trong một môi trường bảo mật cao, điều này có thể không được chấp nhận Sử dụng bảo mật cấp thông báo thay vì bảo mật cấp truyền tải là giải pháp Với bảo mật cấp thông báo, đúng như tên gọi của nó, thông báo được bảo vệ bởi chính nó và không dựa vào phương tiện vận chuyển cơ bản để bảo mật Vì điều này không phụ thuộc vào kênh truyền tải, nên thông điệp sẽ vẫn được bảo vệ, ngay cả sau khi nó rời khỏi kênh truyền tải Điều này một lần nữa đi kèm với chi phí hiệu suất cao Sử dụng bảo vệ cấp độ tin nhắn tốn kém hơn nhiều so với việc chỉ sử dụng TLS Không có định nghĩa rõ ràng về việc đưa ra lựa chọn giữa bảo mật và hiệu suất Luôn có sự thỏa hiệp và quyết định phải được đưa ra dựa trên bối cảnh
Một thiết kế bảo mật thích hợp nên quan tâm đến tất cả các liên kết truyền thông trong hệ thống Bất kỳ hệ thống nào cũng không mạnh hơn mắt xích yếu nhất của nó Con người là mắt xích yếu nhất của hệ thống phòng thủ CIA Mô hình hóa mối đe dọa là một trong những kỹ thuật xác định các liên kết yếu nhất trong thiết kế bảo mật
Phòng ngự có chiều sâu
Cách tiếp cận theo lớp được ưu tiên cho bất kỳ hệ thống nào được thắt chặt để bảo mật Điều này còn được gọi là phòng thủ theo chiều sâu Mã hóa lớp liên kết và lớp mạng và bảo mật luồng lưu lượng được đề xuất làm tuyến phòng thủ đầu tiên cho các cuộc tấn công thụ động và tuyến phòng thủ thứ hai là các ứng dụng hỗ trợ
Để bảo mật, các biện pháp bảo vệ nhiều lớp là tối quan trọng Chống tấn công chủ động bao gồm hệ thống tường lửa (tuyến phòng thủ thứ nhất) và môi trường máy tính (tuyến phòng thủ thứ hai) Ngăn chặn tấn công nội bộ nhờ an ninh vật lý và nhân sự (tuyến phòng thủ thứ nhất) cùng xác thực, ủy quyền và kiểm toán (tuyến phòng thủ thứ hai) Chống tấn công tiếp cận trực tiếp thông qua an ninh vật lý và nhân sự (tuyến phòng thủ thứ nhất) và biện pháp kỹ thuật giám sát (tuyến phòng thủ thứ hai) Thực hiện phân phối và phát triển phần mềm đáng tin cậy cùng áp dụng các biện pháp kiểm soát toàn vẹn trong thời gian chạy ngăn chặn tấn công đa kênh Số lượng và độ mạnh của từng lớp bảo vệ phụ thuộc vào nội dung cần bảo vệ và mức độ đe dọa liên quan.
Các cuộc tấn công nội bộ ít phức tạp hơn, nhưng hiệu quả cao Hầu hết các tổ chức dành phần lớn ngân sách bảo mật để bảo vệ hệ thống của họ khỏi những kẻ xâm nhập bên ngoài; nhưng khoảng 60% đến 80% các sự cố lạm dụng mạng bắt nguồn từ bên trong mạng, theo Viện An ninh Máy tính (CSI) ở San Francisco
Bất kể mức độ chức năng được cung cấp, hiệu quả của một bộ cơ chế bảo vệ phụ thuộc vào khả năng của hệ thống trong việc ngăn chặn vi phạm an ninh Trong hầu hết các trường hợp, việc xây dựng một hệ thống ở bất kỳ cấp độ chức năng nào ngăn chặn tất cả các hành động trái phép đã tỏ ra vô cùng khó khăn Đối với người dùng nâng cao, không khó để tìm ra ít nhất một cách để đánh sập hệ thống, ngăn cản những người dùng được ủy quyền khác truy cập hệ thống Các thử nghiệm thâm nhập liên quan đến một số lượng lớn các hệ thống có mục đích chung khác nhau đã chỉ ra rằng người dùng có thể xây dựng các chương trình để có được quyền truy cập trái phép vào thông tin được lưu trữ bên trong Ngay cả trong các hệ thống được thiết kế và triển khai với ưu tiên hàng đầu là bảo mật, các lỗi thiết kế và triển khai có thể tạo ra các cách để tránh các hạn chế truy cập dự kiến
Least Privilege nêu rõ rằng một thực thể chỉ nên có tập hợp các quyền cần thiết để thực hiện các hành động mà chúng được ủy quyền và không hơn thế nữa
49 Quyền có thể được thêm vào khi cần thiết và nên được thu hồi khi không còn sử dụng
Fail-Safe Defaults làm nổi bật tầm quan trọng của việc làm cho hệ thống an toàn theo mặc định Cấp độ truy cập mặc định của người dùng đối với bất kỳ tài nguyên nào trong hệ thống phải bị "từ chối" trừ khi họ được cấp "giấy phép" một cách rõ ràng Một thiết kế không an toàn sẽ không gây nguy hiểm cho hệ thống khi nó bị lỗi
Economy of Mechanism Economy of Mechanism làm nổi bật giá trị của sự đơn giản Thiết kế nên càng đơn giản càng tốt Tất cả các giao diện thành phần và tương tác giữa chúng phải đủ đơn giản để hiểu Nếu thiết kế và triển khai đơn giản, khả năng xảy ra lỗi sẽ thấp, đồng thời, nỗ lực kiểm thử sẽ ít hơn Một thiết kế và triển khai đơn giản, dễ hiểu cũng sẽ giúp dễ dàng sửa đổi và bảo trì mà không gây ra lỗi theo cấp số nhân
Hệ thống xác thực quyền truy cập toàn diện (Complete Mediation) liên tục xác minh quyền truy cập vào các tài nguyên, đảm bảo rằng chỉ những thực thể được phép mới có thể truy cập Mặc dù hầu hết các hệ thống áp dụng xác thực một lần tại điểm truy cập, lưu trữ ma trận quyền trong bộ nhớ cache để tăng hiệu suất, nhưng cách tiếp cận này tạo điều kiện cho những kẻ tấn công khai thác hệ thống Để giải quyết vấn đề này, các hệ thống lưu trữ quyền và vai trò người dùng trong bộ nhớ cache nhưng triển khai cơ chế xóa bộ nhớ cache khi quyền hoặc vai trò được cập nhật.
3.1.3 Tam giác bảo mật CIA
Tính bí mật, tính toàn vẹn và tính sẵn sàng (CIA), được biết đến rộng rãi là bộ ba bảo mật thông tin, là ba yếu tố chính được sử dụng trong đo điểm chuẩn bảo mật hệ thống thông tin Đây còn được gọi là bộ ba CIA hoặc bộ ba AIC Bộ ba CIA giúp
50 thiết kế một mô hình bảo mật và đánh giá sức mạnh của một mô hình bảo mật hiện có
Giải pháp đảm bảo an toàn OpenID Connect (OIDC)
OpenID Connect (OIDC) là một giao thức tiêu chuẩn mở cung cấp các dịch vụ xác thực và ủy quyền cho các ứng dụng web và di động OIDC được xây dựng trên nền tảng framework ủy quyền OAuth 2.0 và cung cấp lớp danh tính bổ sung trên OAuth 2.0
Với OIDC, người dùng có thể xác thực bằng cách sử dụng nhà cung cấp danh tính (IdP) ưa thích của họ, có thể là tài khoản mạng xã hội như Google, Facebook hoặc nhà cung cấp danh tính doanh nghiệp như Microsoft Active Directory Sau khi người dùng được xác thực, OIDC trả về một token ID chứa thông tin về người dùng, có thể được sử dụng bởi ứng dụng để xác định và ủy quyền người dùng
OIDC hỗ trợ nhiều luồng xác thực, bao gồm luồng mã ủy quyền, luồng tường thuật, luồng lai và luồng thông tin đăng nhập của khách hàng Các luồng này cho phép các ứng dụng nhận được các token với mức độ liên quan đến người dùng khác nhau, phụ thuộc vào trường hợp sử dụng cụ thể
OIDC được sử dụng rộng rãi trong các ứng dụng web và di động hiện đại do cung cấp phương thức xác thực và ủy quyền chuẩn hóa và an toàn Bằng cách sử dụng OIDC, các ứng dụng có thể ủy quyền cho người dùng truy cập tài nguyên mà không cần lưu trữ hoặc quản lý thông tin đăng nhập của họ Điều này giúp cải thiện bảo mật và tránh được các nguy cơ bảo mật liên quan đến việc quản lý mật khẩu.
3.2.1 Các bước cơ bản của giao thức
Hình 3.1 Mô hình giao thức OIDC
- Khi end-user click vào sign-in button trên trang web hoặc ứng dụng của bạn, browser/ứng dựng sẽ redirect end-user tới OpenID Provider(trang Google OAuth server)
- OpenID Provider tiến hành xác thực user
- Sau khi xác thực thành công OpenID Provider(Google OAuth Server) sẽ gửi code dùng một lần lại browser thông qua redirect uri
- Mã code mà browser nhận sẽ được chia sẽ tạm thời cho server
- Server gửi mã code đó tới Google OAuth Server Sau đó server có thể truy cập vào thông tin profile từ Google OAuth Server
3.2.2 Cấu tạo của ID token
Token ID là trái tim của OpenID Connect
ID Token là tiện ích bổ sung chính cho OAuth 2.0 để hỗ trợ OpenID Connect Đó là Token web JSON (JWT) vận chuyển thông tin người dùng được xác thực từ máy chủ ủy quyền đến ứng dụng khách Cấu trúc của token ID được xác định bởi đặc tả OpenID Connect Phần sau đây hiển thị token ID mẫu:
{ "iss":"https://auth.server.com", "sub":"prabath@apache.org",
"aud":"67jjuyuy7JHk12", "nonce":"88797jgjg32331",
"exp":1416283970, "iat":1416283970, "auth_time":1311280969, "acr":"urn:mace:incommon:iap:silver", "amr":"password",
- iss: Mã định danh của nhà phát hành token (máy chủ ủy quyền hoặc nhà cung cấp danh tính) ở định dạng URL HTTPS không có tham số truy vấn hoặc đoạn URL
- sub: Tổ chức phát hành token hoặc bên xác nhận phát hành token ID
- aud: Đối tượng của token Đây có thể là một mảng các số nhận dạng, nhưng nó phải có ID máy khách OAuth trong đó Đây là thuộc tính bắt buộc trong token ID
- nonce: Một tham số mới được giới thiệu bởi đặc tả OpenID Connect cho yêu cầu cấp phép ban đầu Tham số này được giới thiệu để giảm thiểu các cuộc tấn công lặp lại Máy chủ ủy quyền phải từ chối bất kỳ yêu cầu nào nếu nó tìm thấy hai yêu cầu có cùng giá trị nonce
Mỗi mã thông báo ID (token ID) đều có thời gian hết hạn, đây là đặc tính bắt buộc Người nhận token ID phải từ chối nếu token đã hết hạn.
- iat: Tham số iat trong token ID cho biết thời gian phát hành token ID theo tính toán của nhà phát hành token Đây là thuộc tính bắt buộc trong token ID
- auth_time: Thời gian mà người dùng cuối xác thực với máy chủ ủy quyền
Nếu người dùng đã được xác thực thì máy chủ ủy quyền sẽ không yêu cầu người dùng xác thực lại Đây là một tham số tùy chọn
- acr: Tham chiếu lớp ngữ cảnh xác thực Giá trị của tham số này phải được hiểu bởi cả máy chủ ủy quyền và ứng dụng khách Nó đưa ra một dấu hiệu về mức độ xác thực Đây là một tham số tùy chọn
- amr: Viết tắt của tham chiếu phương thức xác thực Nó cho biết cách máy chủ ủy quyền xác thực người dùng Ví dụ: nếu người dùng xác thực tại máy chủ
54 ủy quyền bằng tên người dùng/mật khẩu và mật khẩu một lần qua SMS, thì giá trị của tham số amr phải chỉ ra điều đó Đây là một tham số tùy chọn
- azp: Viết tắt của bên được ủy quyền Nó cần thiết khi có một đối tượng (aud) và giá trị của nó khác với ID ứng dụng khách OAuth Giá trị của azp phải được đặt thành ID máy khách OAuth Đây là một tham số tùy chọn
3.2.3 Yêu cầu thuộc tính người dùng
Kết luận chương 3
Chương này đã trình bày về các các thách thức, nguyên tắc, tam giác bảo mật khi thiết kế bảo mật cho một API Từ đó, đưa ra giải pháp đảm bảo an toàn OpenID Connect cho Web API OpenID Connect cung cấp một giải pháp phổ biến cho việc xác thực người dùng và chia sẻ thông tin danh tính an toàn OpenID Connect sử dụng mô hình phân tán trong đó người dùng xác thực thông qua một IdP (chẳng hạn như Google, Facebook, Azure AD) Điều này giúp giảm bớt gánh nặng quản lý xác thực và cho phép sử dụng lại thông tin danh tính từ IdP OpenID Connect có thể tích hợp với các ứng dụng và dịch vụ hiện có thông qua các thư viện và khung phát triển (framework) hỗ trợ Các nhà cung cấp như Okta, Auth0, Keycloak cung cấp giải pháp OpenID Connect nhằm đơn giản hóa việc triển khai và quản lý xác thực
Xây dựng mô hình thực nghiệm
Cài đặt module cho lab thử nghiệm
4.1.1 Các công cụ cần thiết
- Máy ảo Kali linux - Máy thật Window - Burpsuite
4.1.2 Hướng dẫn cài đặt công cụ
1 sudo apt-get install -y docker.io 2 sudo systemctl enable docker –now 3 sudo usermod -aG docker $USER 4 Khởi động lại kali
5 Sudo apt-get install docker-compose
Cài Foxy Proxy trên Firefox 1 Cài FoxyProxy trong Firefox
2 Cấu hình FoxyProxy Bấm vào Extension Foxy và chọn Options
3 Chọn Add Proxy và config như hình và Save
Hình 4.2 Cấu hình Burpsuite trên Foxy Proxy
Hình 4.3 Bật Burpsuite trên Foxy Proxy
4.1.3 Cài đặt, thiết lập môi trường Web API
1 Download project dvws-node trên git git clone https://github.com/snoopysecurity/dvws-node.git 2 Vào bên trong folder dvws là chạy lệnh: docker-compose up
3 Mở trình duyệt vào url localhost sẽ hiện trang chính của web
Hình 4.4 Giao diện đăng nhập Web API DVWS
Thử nghiệm tấn công
Hình 4.5 Mô hình thử nghiệm
• Trình duyệt chrome cài Foxy Proxy Mục tiêu: Thực hiện được các kỹ thuật tấn công Injection và JWT tới máy chủ DVWS
Kịch bản: Tạo một tài khoản mới để truy cập Web Từ đó thực hiện được các tấn công NoSQL Injection, tấn công leo thang đặc quyền qua JWT và tấn công Command Injection Thực hiện tấn công leo thang đặc quyền theo kỹ thuật khác là Mass Assignment
Bước 1: Tạo tài khoản DVWS và đăng nhập
Hình 4.6 Tạo tài khoản DVWS
Hình 4.7 Giao diện Web DVWS sau khi đăng nhập thành công
67 Bước 2: Chọn vào Notes Area để thêm một notes mới
Hình 4.8 Tạo một Note mới
Bước 3: Sau khi tạo thành công Quay trở lại trang chính và chọn vào Public Notes Search Ở note này, cho phép tìm các notes Public từ các tài khoản khác Sử dụng kỹ thuật NoSQL Injection để khai thác dữ liệu
Hình 4.9 Tìm kiếm note public
Bước 3: Bật Burp Suite và phân tích
Hình 4.10 Burpsuite bắt được request khi tìm kiếm note
• Chuột phải chọn Send to Repeater
Không tìm thấy thông tin nào của notes test
69 Input đầu vào là dạng text nên nghĩ ngay tới tấn công NoSQL Injection bằng cách chèn 1 số payload đặc biệt
Hình 4.12 Thực hiện tấn công NoSQL Injection
Response trả về dữ liệu các notes kể cả public hay secret
Hình 4.13 Response sau khi thực hiện tấn công NoSQL Injection Tấn công leo thang đặc quyền vào JWT
Trang Admin Area không thể vào khi tài khoản không có quyền admin
Hình 4.14 Menu lựa chọn trong web
Bước 1: Sử dụng Burp suite chặn bắt và phân tích thấy được xác thực bằng một token Đây là JWT
Hình 4.15 Burpsuite chặn bắt request khi vào trang Admin Area
Bước 2: Tìm secret key của JWT bằng script và payload có sẵn
Hình 4.16 Chạy script để tìm Secret Key
Tìm thấy được secret key: “access”
Bước 3: Phân tích JWT với secret key trên trang jwt.io
Hình 4.17 Phân tích JWT trên trang jwt.io
Bước 4: Thêm “user:admin” vào Payload, nhận được JWT mới
Hình 4.18 JWT sau khi thêm dữ liệu trong payload
Bước 5: Thay JWT vào Burp suite và xem kết quả
Hình 4.19 Thay JWT mới vào request
Hình 4.20 Trang Admin Area bị truy cập khi tấn công JWT
Đã vào được trang Admin Area với quyền Admin
Trong lúc thực hiện tấn công vào JWT, thấy có một API
/api/v2/sysinfo/uname với uname là một lệnh để hiển thị thông tin hệ thống
Thực hiện tấn công Command Injection bằng cách chèn thêm “;ls”
Hình 4.21 Kết quả sau khi thực hiện tấn công Command Injection Tấn công leo thang đặc quyền bằng Mass Assignment
Bước 1: Dùng Burpsuite chặn bắt request khi đăng nhập
Lúc login thấy có một api POST /api/v2/login.
Hình 4.22 Request khi đăng nhập
75 Response trả về có thông tin admin: false.
Hình 4.23 Response trả về khi đăng nhập
Bước 2: Tấn công Mass Assignment diễn ra khi tạo một tài khoản mới bằng cách thêm một trường dữ liệu &admin=true
Hình 4.24 Thực hiện tấn công Mass Assignment
Vào được trang Admin Area
Hình 4.25 Trang Admin Area sau khi tấn công Mass Assignment
Kết luận chương 4
Chương này tập trung vào xây dựng một hệ thống thử nghiệm để áp dụng các kỹ thuật tấn công tìm hiểu ở chương 2
Sau khi thử nghiệm, nhận thấy kỹ thuật tấn công như NoSQL Injection, Command Injection có mức nguy hiểm cao nhưng không là mối lo lớn với hệ thống
Các kỹ thuật này có thể bị ngăn chặn hoàn toàn khi nhà phát triển tập trung phân tích và lọc các đầu vào hợp lệ
Các kỹ thuật tấn công vào xác thực qua JWT, kỹ thuật Mass Assignment với mục đích leo thang đặc quyền, truy cập trái phép vào những trang, thông tin mà nhà phát triển không mong muốn Hai kỹ thuật này thì các nhà phát triển cần hết sức tập trung xây dựng các giải pháp để bảo vệ như sử dụng WAF, OpenID Connect
Tuy nhiên điểm hạn chế trong chương này là chưa tích hợp được giải pháp OpenID Connect từ chương 3 vào Web Vulnerable API DVWS Do Web DVWS đặc trưng với mục đích hỗ trợ thực nghiệm tấn công nên việc tích hợp OIDC vào là khá khó khăn và chưa thành công