Bài viết & Thông báo
Cập nhật bài viết và thông báo mới nhất từ khoa An toàn Thông tin
6 kết quả#Application Security
blogsLỗ hổng IDOR không chỉ là lỗi kiểm tra id, mà là thất bại của tư duy phân quyền theo tài nguyên
IDOR không chỉ là lỗi đổi một ID trong URL mà là biểu hiện trực tiếp của Broken Access Control khi hệ thống truy xuất tài nguyên dựa trên object reference do client cung cấp nhưng không ràng buộc quyền thực tế của caller trên resource đó. Muốn xử lý tận gốc, ứng dụng phải chuyển từ tư duy kiểm tra chức năng đơn thuần sang authorization theo tài nguyên, kết hợp ownership, tenant boundary, ACL, kế thừa quyền, kiểm soát ở tầng service, repository và database để chặn truy cập trái phép một cách nhất quán.
blogsZero trust architecture dưới góc nhìn của một appsec engineer
Nếu nhìn từ góc độ của một AppSec engineer, Zero Trust Architecture không chỉ là câu chuyện của hạ tầng mạng hay sản phẩm bảo mật. Đây là một cách thiết kế hệ thống sao cho mọi truy cập đều phải đi qua các giả định tin cậy rõ ràng, các điểm kiểm soát có chủ đích, và các quyết định truy cập có thể kiểm chứng. Giá trị lớn nhất của Zero Trust nằm ở chỗ nó buộc kiến trúc phải trả lời được ai đang truy cập, từ đâu, bằng thiết bị nào, tới tài nguyên gì, với mức rủi ro nào, và trong ngữ cảnh nào thì được phép đi tiếp. Với AppSec designer, đây chính là cách chuyển bảo mật từ tầng khẩu hiệu sang tầng kiến trúc và cơ chế thực thi.
blogsCùng xem, khi AI tham gia viết code, năng lực thiết kế mới quyết định hệ thống an toàn đến đâu (Opaque ID Design)
AI đang giúp lập trình viên tạo API nhanh hơn, nhưng cũng đang làm lộ rõ khoảng cách giữa viết được mã và hiểu được hệ thống mình đang xây. Một ví dụ điển hình là việc nhiều ứng dụng vẫn công khai primary key của cơ sở dữ liệu ra ngoài endpoint, từ đó mở đường cho lỗi tham chiếu đối tượng trực tiếp không an toàn (Insecure Direct Object Reference, IDOR). Định danh mờ (Opaque ID) là một quyết định thiết kế hữu ích để giảm khả năng suy diễn và enumeration, nhưng giá trị thật của nó chỉ xuất hiện khi người làm hiểu đúng bản chất, tránh các anti pattern, và đặt nó trong bức tranh tổng thể của authorization, validation, logging, transaction, cache, và kiểm soát rủi ro toàn hệ thống. Trong thời đại AI, lợi thế không còn nằm ở tốc độ sinh mã, mà nằm ở chiều sâu nhận thức về hậu quả thiết kế.
blogsKiến thức cơ bản về mật mã học cho kỹ sư phần mềm và kỹ sư an toàn ứng dụng
Mật mã học (cryptography) nên được xem như một công cụ giảm thiểu ở mức kiến trúc (architectural mitigation tool), có nhiệm vụ bảo vệ tính bí mật (confidentiality), tính toàn vẹn (integrity), tính xác thực (authenticity) và trách nhiệm giải trình (accountability) khi được đặt đúng vị trí trong hệ thống và được quản lý xuyên suốt toàn bộ vòng đời của nó.
blogsThreat Modeling : đưa tư duy đối kháng vào thiết kế phần mềm từ sớm
Threat Modeling giúp đội phát triển đưa bảo mật vào đúng thời điểm, ngay khi hệ thống còn đang được mô hình hóa và thiết kế. Bằng cách nhìn hệ thống từ góc độ tài sản, ranh giới tin cậy, entry point, risk và misuse case, nhóm có thể phát hiện sớm các đường lạm dụng, ưu tiên đúng rủi ro và chuyển các quyết định bảo mật thành kiểm soát thực tế trước khi chi phí sửa đổi trở nên quá lớn.
Hướng nghiệpLĩnh vực Bảo Mật Ứng Dụng (Application Security) là gì?
AppSec là một quá trình bảo vệ ứng dụng từ khi còn đang thiết kế, đang viết mã, đang kiểm thử, cho đến khi đã đưa vào vận hành. Nó giúp ngăn truy cập trái phép, giảm rủi ro rò rỉ dữ liệu, bảo vệ mã nguồn và chức năng nghiệp vụ, đồng thời giảm thiểu hậu quả kinh doanh nếu có sự cố. AppSec không phải việc của riêng đội bảo mật, mà là trách nhiệm chung của tổ chức, đặc biệt là đội phát triển phần mềm. Muốn ứng dụng an toàn, phải đưa bảo mật vào từ sớm, kiểm tra liên tục, và duy trì giám sát sau triển khai. Đó là lý do AppSec hiện nay được xem là một phần bắt buộc của phát triển phần mềm hiện đại.