10 rủi ro bảo mật ứng dụng web hàng đầu năm 2022
|
Show
Danh sách OWASP TOP 10 năm 2021 đã được công bố. Danh sách này chỉ ra rằng broken access control là rủi ro bảo mật ứng dụng web nghiêm trọng nhất hiện nay. 1. Danh sách này được tổng hợp như thế nào?“Chúng tôi lấy dữ liệu từ các tổ chức đang kiểm tra các nhà cung cấp thương mại, các bên triển khai chương trình bug bounty và các tổ chức đóng góp dữ liệu thử nghiệm nội bộ. Một khi có dữ liệu, chúng tôi sẽ tiến hành phân tích cơ bản xem danh sách điểm yếu chung CWEs (Common Weakness Enumerations) dẫn đến rủi ro nào”, OWASP giải thích. “Danh sách TOP 10 được định hướng theo dữ liệu một cách khách quan. Chúng tôi đã chọn tám trong số mười danh mục từ dữ liệu được đóng góp và hai danh mục từ TOP 10 cuộc khảo sát cộng đồng ở mức độ cao”. 2. OWASP Top 10 2021: Điều gì đã thay đổi trong 4 năm qua?Theo OWASP, có ba danh mục mới trong phiên bản mới nhất của danh sách TOP 10 OWASP. Đó là insecure design (thiết kế không bảo mật), software and data integrity failures (lỗi toàn vẹn phần mềm và dữ liệu) và security logging and monitoring failures (lỗi ghi nhật ký bảo mật và giám sát). “Một danh mục mới cho năm 2021 tập trung vào các rủi ro liên quan đến các sai sót trong thiết kế và cấu trúc đã kêu gọi sử dụng nhiều hơn các chi tiết thiết kế an toàn và các kiến trúc tham chiếu”, OWASP nói thêm. Danh mục lỗi toàn vẹn phần mềm và dữ liệu bao gồm các lỗi liên quan đến cập nhật phần mềm (không đủ xác minh tính toàn vẹn), dữ liệu quan trọng và CI / CD pipelines (không an toàn). Theo dõi và ghi nhật ký bảo mật là hoạt động rất quan trọng để phát hiện, báo cáo và phản hồi các vi phạm hiện có. Một số danh mục khác đã được đổi tên (để tập trung vào nguyên nhân gốc rễ) và thay đổi. Một số đã được hợp nhất. Danh sách cuối cùng như sau:
OWASP giải thích chi tiết từng danh mục kèm theo các ví dụ về kịch bản tấn công, tài liệu tham khảo, danh sách các CWEs và các bí quyết ngăn chặn lỗ hổng. Dự án cũng tư vấn cho các tổ chức về cách sử dụng nó làm cơ sở để bắt đầu một chương trình bảo mật ứng dụng. “Một nửa danh mục trong danh sách mới đã xuất hiện trong danh sách từ năm 2003 dưới một vài hình thức. Vì vậy 18 năm phát triển, thử nghiệm và học hỏi công nghệ vẫn chưa đủ để khắc phục những sai sót này. Điều này có nghĩa là chúng ta cần thay đổi cách tiếp cận của mình đối với việc bảo mật ứng dụng”, Sean Wright, kỹ sư bảo mật ứng dụng tại Immersive Labs chia sẻ. “Tôi nhận thấy rằng phương pháp tiếp cận của chúng ta cho đến nay đang thiếu sự tham gia của “những người đứng sau màn hình”. Chúng ta cần trao quyền cho các nhà phát triển để đưa bảo mật vào thiết kế và code. Bên cạnh đó, cần trang bị cho các thành viên trong nhóm kiến thức mới về công nghệ nhằm tạo ra các ứng dụng an toàn hơn. Hành động này mang lại cho con người và công nghệ cơ hội tốt nhất để làm việc cùng nhau nếu chúng ta muốn giảm tác động cũng như sự lây lan của các lỗ hổng bảo mật đang lặp đi lặp lại. Sự kết hợp giữa công nghệ và con người sẽ giúp chúng ta nâng cao bảo mật cho ứng dụng và hy vọng có thể giải quyết một số vấn đề có ảnh hưởng lớn nhất trong hai thập kỷ qua. Sau khi chúng tôi thực hiện từng bước để đạt được điều này, tôi tin rằng chúng ta sẽ ít phải thấy những điều tương tự trong danh sách OWASP TOP 10 trong tương lai ”. Open Web Application Security Project (OWASP) là một tổ chức bao gồm các chuyên gia bảo mật hàng đầu thế giới, chuyên cung cấp các thông tin về những ứng dụng và rủi ro đặt ra một cách trực tiếp, khách quan và thực tế nhất. Từ năm 2013 đến nay, cứ 4 năm 1 lần, OWASP lại công bố danh sách Top 10 các rủi ro bảo mật ứng dụng lớn nhất, được gọi là OWASP Top 10. Danh sách này được coi là chuẩn AppSec và được cộng đồng an ninh mạng tin tưởng. Danh
sách bao gồm thông tin mới nhất về các lỗ hổng, các mối đe dọa và cuộc tấn công cũng như những thủ thuật để phát hiện và khắc phục. Các thành viên dự án lập ra danh sách này dựa trên việc phân tích tỉ lệ xuất hiện và mức độ nghiêm trọng của từng mối đe dọa. OWASP Top 10 năm 2017 được phát hành công khai, dựa trên cuộc thăm dò, kiểm tra hơn 2,3 triệu lỗ hổng tác động đến 50000 ứng dụng, bao gồm 2 bản cập nhật lỗ hổng quy mô lớn và cập nhật các kịch bản tấn công mới. Có thể bạn quan
tâm: Và sau đây là danh sách Top 10 của năm 2017. Lỗ hổng Injection (Lỗi chèn mã độc)Lỗi tiêm cho phép kẻ tấn công chuyển tiếp mã độc thông qua một ứng dụng đến một hệ thống khác. Các cuộc tấn công này bao gồm các cuộc gọi đến hệ điều hành thông qua các lệnh gọi hệ thống, sử dụng các chương trình bên ngoài thông qua các lệnh shell, cũng như các lệnh gọi đến cơ sở dữ liệu phụ trợ thông qua SQL (tức là SQL injection). Toàn bộ tập lệnh được viết bằng Perl, Python và các ngôn ngữ khác có thể được đưa vào các ứng dụng được thiết kế kém và thực thi. Bất cứ khi nào một ứng dụng sử dụng trình thông dịch thuộc bất kỳ loại nào đều có nguy cơ tạo ra một lỗ hổng bảo mật.Nhiều ứng dụng web sử dụng các tính năng của hệ điều hành và các chương trình bên ngoài để thực hiện các chức năng của chúng. Sendmail có lẽ là chương trình bên ngoài được gọi thường xuyên nhất, nhưng nhiều chương trình khác cũng được sử dụng. Khi một ứng dụng web chuyển thông tin từ một yêu cầu HTTP qua như một phần của yêu cầu bên ngoài, nó phải được kiểm tra cẩn thận. Nếu không, kẻ tấn công có thể đưa các ký tự (meta) đặc biệt, lệnh độc hại hoặc công cụ sửa đổi lệnh vào thông tin và ứng dụng web sẽ chuyển một cách mù quáng những điều này cho hệ thống bên ngoài để thực thi. SQL injection là một dạng tiêm nguy hiểm và phổ biến đặc biệt. Để khai thác lỗ hổng SQL injection, kẻ tấn công phải tìm một tham số mà ứng dụng web chuyển qua cơ sở dữ liệu. Bằng cách cẩn thận nhúng các lệnh SQL độc hại vào nội dung của tham số, kẻ tấn công có thể lừa ứng dụng web chuyển tiếp một truy vấn độc hại đến cơ sở dữ liệu. Xem thêm Kiểm tra lỗ hổng bảo mật Weak Transport Layer Security Các cuộc tấn công này không khó để thực hiện và ngày càng có nhiều công cụ quét các lỗ hổng này. Hậu quả là đặc biệt nghiêm trọng, vì kẻ tấn công có thể lấy, làm hỏng hoặc phá hủy nội dung cơ sở dữ liệu.Các lỗ hổng tiêm có thể rất dễ phát hiện và khai thác, nhưng chúng cũng có thể cực kỳ khó hiểu. Hậu quả của một cuộc tấn công tiêm thành công cũng có thể kéo theo toàn bộ phạm vi mức độ nghiêm trọng, từ mức độ nhỏ đến sự xâm phạm hoặc phá hủy hệ thống hoàn toàn. Broken AuthenticationTác nhân đe dọa / Vectơ tấn công Những kẻ tấn công có quyền truy cập vào hàng trăm triệu tổ hợp tên người dùng và mật khẩu hợp lệ để nhồi nhét thông tin xác thực, danh sách tài khoản quản trị mặc định, vũ phu tự động và các công cụ tấn công từ điển. Các cuộc tấn công quản lý phiên được hiểu rõ, đặc biệt là liên quan đến mã thông báo phiên chưa hết hạn. Điểm yếu về bảo mật Sự phổ biến của xác thực bị hỏng là phổ biến do thiết kế và triển khai hầu hết các kiểm soát nhận dạng và truy cập. Quản lý phiên là nền tảng của xác thực và kiểm soát truy cập, và có mặt trong tất cả các ứng dụng trạng thái.Những kẻ tấn công có thể phát hiện xác thực bị hỏng bằng cách sử dụng các phương tiện thủ công và khai thác chúng bằng các công cụ tự động với danh sách mật khẩu và tấn công từ điển. Tác động Những kẻ tấn công chỉ có quyền truy cập vào một vài tài khoản hoặc chỉ một tài khoản quản trị để xâm nhập hệ thống. Tùy thuộc vào miền của ứng dụng, điều này có thể cho phép rửa tiền, gian lận an sinh xã hội và đánh cắp danh tính hoặc tiết lộ thông tin nhạy cảm cao được bảo vệ hợp pháp. Các tình huống tấn công mẫu Tình huống # 1: Nhồi nhét thông tin xác thực, sử dụng danh sách các mật khẩu đã biết, là một cuộc tấn công phổ biến. Nếu ứng dụng không triển khai các biện pháp bảo vệ tự động đe dọa hoặc nhồi nhét thông tin xác thực, ứng dụng có thể được sử dụng như một tiên tri mật khẩu để xác định xem thông tin xác thực có hợp lệ hay không. Tình huống # 2: Hầu hết các cuộc tấn công xác thực xảy ra do việc tiếp tục sử dụng mật khẩu như một yếu tố duy nhất. Từng được coi là phương pháp hay nhất, các yêu cầu về độ phức tạp và xoay vòng mật khẩu được xem là khuyến khích người dùng sử dụng và sử dụng lại các mật khẩu yếu. Theo NIST 800-63, các tổ chức nên dừng các phương pháp này và sử dụng xác thực đa yếu tố. Tình huống # 3: Thời gian chờ của phiên ứng dụng không được đặt đúng cách. Người dùng sử dụng máy tính công cộng để truy cập ứng dụng. Thay vì chọn “đăng xuất”, người dùng chỉ cần đóng tab trình duyệt và bỏ đi. Một giờ sau kẻ tấn công sử dụng cùng một trình duyệt và người dùng vẫn được xác thực. Xem thêm Kiểm tra lỗ hổng bảo mật Client-side Resource Manipulation Lỗ hổng XSS (Cross Site Scripting)Nó được xem là khá phổ biến trong các dạng nó hỏng thường gặp hiện nay. Những người có ý định tấn công sẽ thêm vào những đoạn code JavaScript thông qua các ứng dụng website. Khi chúng đã lọt qua và tiến hành thực hiện các vai trò của mình kích hoạt những đoạn Mã đã ngay trên chính trình duyệt website. Họ sẽ dễ dàng Đánh Cắp cookies trên hệ thống và chuyển hướng mọi người đến những website chứa các đoạn Mã độc hại Xem thêm Kiểm tra lỗ hổng bảo mật Cross-Site Request Forgery (CSRF) Nguy cơ tiềm ẩn các mối nguy hại:
Broken Access ControlTác nhân đe dọa / Vectơ tấn công Khai thác quyền kiểm soát truy cập là một kỹ năng cốt lõi của những kẻ tấn công. Các công cụ SAST và DAST có thể phát hiện sự vắng mặt của kiểm soát truy cập nhưng không thể xác minh xem nó có hoạt động hay không khi nó có mặt. Kiểm soát truy cập có thể được phát hiện bằng cách sử dụng các phương tiện thủ công hoặc có thể thông qua tự động hóa nếu không có kiểm soát truy cập trong một số khuôn khổ nhất định. Điểm yếu về bảo mật Các điểm yếu của kiểm soát truy cập là phổ biến do thiếu khả năng phát hiện tự động và thiếu kiểm tra chức năng hiệu quả bởi các nhà phát triển ứng dụng.Tính năng phát hiện kiểm soát truy cập thường không thích hợp với kiểm tra động hoặc tĩnh tự động. Kiểm tra thủ công là cách tốt nhất để phát hiện kiểm soát truy cập bị thiếu hoặc không hiệu quả, bao gồm phương pháp HTTP (GET vs PUT, v.v.), bộ điều khiển, tham chiếu đối tượng trực tiếp, v.v. Tác động Tác động kỹ thuật là những kẻ tấn công đóng vai trò là người dùng hoặc quản trị viên, hoặc người dùng sử dụng các chức năng đặc quyền, hoặc tạo, truy cập, cập nhật hoặc xóa mọi bản ghi.Tác động kinh doanh phụ thuộc vào nhu cầu bảo vệ của ứng dụng và dữ liệu. Các tình huống tấn công mẫu Tình huống # 1: Ứng dụng sử dụng dữ liệu chưa được xác minh trong lệnh gọi SQL đang truy cập thông tin tài khoản:pstmt.setString (1, request.getParameter (“acct”));Kết quả ResultSet = pstmt.executeQuery ();Kẻ tấn công chỉ cần sửa đổi tham số ‘acct’ trong trình duyệt để gửi bất kỳ số tài khoản nào chúng muốn. Nếu không được xác minh đúng cách, kẻ tấn công có thể truy cập vào tài khoản của bất kỳ người dùng nào. Xem thêm Kiểm tra lỗ hổng Bypassing Authentication Schema Tình huống # 2: Kẻ tấn công chỉ cần buộc duyệt các URL mục tiêu. Quyền quản trị được yêu cầu để truy cập vào trang quản trị.http://example.com/app/getappInfohttp://example.com/app/admin_getappInfoNếu người dùng chưa được xác thực có thể truy cập vào một trong hai trang, đó là một lỗ hổng. Nếu một người không phải quản trị viên có thể truy cập vào trang quản trị, đây là một thiếu sót. Sensitive Data Exposure (Rò rỉ dữ liệu)Tác nhân đe dọa / Vectơ tấn công Thay vì tấn công trực tiếp vào tiền điện tử, những kẻ tấn công ăn cắp khóa, thực hiện các cuộc tấn công trung gian hoặc lấy cắp dữ liệu văn bản rõ ràng khỏi máy chủ, khi đang chuyển tiếp hoặc từ máy khách của người dùng, ví dụ: trình duyệt. Một cuộc tấn công thủ công thường được yêu cầu. Cơ sở dữ liệu mật khẩu đã truy xuất trước đây có thể bị cưỡng bức bởi Đơn vị xử lý đồ họa (GPU). Xem thêm Testing security – Network Infrastructure Configuration Điểm yếu về bảo mật Trong vài năm qua, đây là cuộc tấn công có tác động phổ biến nhất. Lỗ hổng phổ biến nhất chỉ đơn giản là không mã hóa dữ liệu nhạy cảm. Khi tiền điện tử được sử dụng, việc tạo và quản lý khóa yếu cũng như thuật toán yếu, việc sử dụng giao thức và mật mã là phổ biến, đặc biệt là đối với các kỹ thuật lưu trữ băm mật khẩu yếu. Đối với dữ liệu đang truyền, các điểm yếu phía máy chủ chủ yếu là dễ phát hiện, nhưng lại khó cho dữ liệu ở trạng thái nghỉ. Tác động Lỗi thường xuyên làm ảnh hưởng đến tất cả dữ liệu đáng lẽ phải được bảo vệ. Thông thường, thông tin này bao gồm dữ liệu thông tin cá nhân nhạy cảm (PII) như hồ sơ sức khỏe, thông tin đăng nhập, dữ liệu cá nhân và thẻ tín dụng, thường yêu cầu bảo vệ theo quy định của luật hoặc quy định như GDPR của EU hoặc luật về quyền riêng tư của địa phương. Các tình huống tấn công mẫu Tình huống 1: Một ứng dụng mã hóa số thẻ tín dụng trong cơ sở dữ liệu bằng cách sử dụng mã hóa cơ sở dữ liệu tự động. Tuy nhiên, dữ liệu này sẽ tự động được giải mã khi được truy xuất, cho phép một lỗ hổng SQL injection truy xuất số thẻ tín dụng ở dạng văn bản rõ ràng. Tình huống 2: Một trang web không sử dụng hoặc thực thi TLS cho tất cả các trang hoặc hỗ trợ mã hóa yếu. Kẻ tấn công giám sát lưu lượng mạng (ví dụ: tại một mạng không dây không an toàn), hạ cấp các kết nối từ HTTPS xuống HTTP, chặn các yêu cầu và đánh cắp cookie phiên của người dùng. Sau đó, kẻ tấn công phát lại cookie này và chiếm quyền điều khiển phiên (đã xác thực) của người dùng, truy cập hoặc sửa đổi dữ liệu riêng tư của người dùng. Thay vì những điều trên, chúng có thể thay đổi tất cả dữ liệu được vận chuyển, ví dụ: người nhận chuyển tiền. Tình huống 3: Cơ sở dữ liệu mật khẩu sử dụng hàm băm đơn giản hoặc đơn giản để lưu trữ mật khẩu của mọi người. Một lỗ hổng tải lên tệp cho phép kẻ tấn công lấy cơ sở dữ liệu mật khẩu. Tất cả các hàm băm không ướp muối có thể được hiển thị với một bảng cầu vồng được tính toán trướcbăm. Các hàm băm được tạo bởi các hàm băm đơn giản hoặc nhanh có thể bị giải mã bởi GPU, ngay cả khi chúng đã được ướp muối.  XML External Entities (XXE)XML External Entities ( còn được gọi là XXE) là lỗ hổng bảo mật cho phép kẻ tấn công can thiệp vào quá trình xử lý dữ liệu XML của ứng dụng. Nó thường cho phép kẻ tấn công xem các tệp trên hệ thống tệp của máy chủ ứng dụng và tương tác với bất kỳ hệ thống back-end hoặc bên ngoài thứ ba nào mà ứng dụng có thể truy cập được. Trong một số tình huống, kẻ tấn công có thể leo thang cuộc tấn công XXE để xâm nhập máy chủ bên dưới hoặc cơ sở hạ tầng phụ trợ khác, bằng cách tận dụng lỗ hổng XXE để thực hiện các cuộc tấn công giả mạo yêu cầu phía máy chủ (SSRF). Xem thêm Kiểm tra lỗ hổng Directory Traversal File Include Security MisconfigurationThông thường, chú sẽ được cấu hình không chính xác. Vài trường hợp cấu hình sai như sau :
Phương pháp đề phòng lỗ hỏng: Có một quá trình “xây dựng và triển khai” tốt (tốt nhất là tự động). Trước khi khi tiến hành triển khai, cần có một bước chuẩn bị cho quá trình Audit nhưng bảo mật trên server. Insecure DeserializationDeserialization là quá trình khôi phục luồng bytes này để tạo thành một phiên bản copy với đầy đủ các chức năng, ở trong trạng thái chính xác quá trình này được tuần tự hóa. Sau đó, logic của trang web có thể tương tác trực tiếp với trang web này, như bao đối tượng khác. Serialization (tuần tự hoá) là quá trình chuyển đổi cấu trúc một cách phức tạp, chẳng chẳng hạng như thuộc tính và phương thức, thành một dạng dữ liệu “phẳng hơn” có thể gởi qua dữ liệu byte tuần tự. Và có thể sắp xếp lại:
Using Components with Known Vulnerabilities (Sử dụng các thành phần có lỗ hổng đã biết)Tác nhân đe dọa / Vectơ tấn công Mặc dù có thể dễ dàng tìm thấy các khai thác đã được viết sẵn cho nhiều lỗ hổng đã biết, nhưng các lỗ hổng khác đòi hỏi nỗ lực tập trung để phát triển một khai thác tùy chỉnh. Điểm yếu về bảo mật Sự phổ biến của vấn đề này là rất rộng rãi. Các mô hình phát triển nặng về thành phần có thể dẫn đến việc các nhóm phát triển thậm chí không hiểu họ sử dụng thành phần nào trong ứng dụng hoặc API của mình, khiến chúng không được cập nhật nhiều hơn.Một số máy quét chẳng hạn như reti.js giúp phát hiện, nhưng việc xác định khả năng khai thác đòi hỏi nỗ lực bổ sung. Tác động Trong khi một số lỗ hổng đã biết chỉ dẫn đến các tác động nhỏ, một số lỗ hổng lớn nhất cho đến nay đã dựa vào việc khai thác các lỗ hổng đã biết trong các thành phần. Tùy thuộc vào tài sản bạn đang bảo vệ, có lẽ rủi ro này nên đứng đầu danh sách. Xem thêm Kiểm tra lỗ hổng bảo mật Incubated Vulnerability Các tình huống tấn công mẫu Tình huống số 1: Các thành phần thường chạy với các đặc quyền giống như chính ứng dụng đó, vì vậy sai sót trong bất kỳ thành phần nào có thể dẫn đến tác động nghiêm trọng. Những sai sót như vậy có thể là tình cờ (ví dụ: lỗi mã hóa) hoặc cố ý (ví dụ: cửa hậu trong thành phần). Một số ví dụ về lỗ hổng thành phần có thể khai thác được phát hiện là:* CVE-2017-5638, một lỗ hổng thực thi mã từ xa Struts 2 cho phép thực thi mã tùy ý trên máy chủ, đã bị đổ lỗi cho các vi phạm đáng kể.* Mặc dù Internet vạn vật (IoT) thường khó hoặc không thể vá, nhưng tầm quan trọng của việc vá chúng có thể rất lớn (ví dụ: thiết bị y sinh).Có các công cụ tự động để giúp những kẻ tấn công tìm thấy các hệ thống chưa được vá hoặc cấu hình sai. Ví dụ: công cụ tìm kiếm Shodan IoT có thể giúp bạn tìm các thiết bị vẫn còn mắc phải lỗ hổng Heartbleed đã được vá vào tháng 4 năm 2014. Insufficient Logging & Monitoring (Ghi nhật ký và giám sát không đầy đủ)Tác nhân đe dọa / Vectơ tấn công Khai thác không đủ ghi chép và giám sát là nền tảng của hầu hết các sự cố lớn.Những kẻ tấn công dựa vào việc thiếu giám sát và phản ứng kịp thời để đạt được mục tiêu của chúng mà không bị phát hiện. Điểm yếu về bảo mật Vấn đề này được đưa vào Top 10 dựa trên một cuộc khảo sát trong ngành.Một chiến lược để xác định xem bạn có đủ giám sát hay không là kiểm tra các bản ghi sau khi kiểm tra thâm nhập. Các hành động của người thử nghiệm phải được ghi lại đầy đủ để hiểu họ có thể đã gây ra những thiệt hại nào. Tác động Hầu hết các cuộc tấn công thành công đều bắt đầu bằng việc thăm dò lỗ hổng. Việc cho phép tiếp tục các đầu dò như vậy có thể nâng cao khả năng khai thác thành công lên gần 100%.Trong năm 2016, việc xác định một vi phạm mất trung bình 191 ngày – khoảng thời gian khá dài để có thể gây ra thiệt hại. Các tình huống tấn công mẫu Tình huống 1: Một phần mềm diễn đàn dự án mã nguồn mở do một nhóm nhỏ điều hành đã bị tấn công bằng cách sử dụng một lỗ hổng trong phần mềm của nó. Những kẻ tấn công đã quản lý để xóa sạch kho mã nguồn nội bộ có chứa phiên bản tiếp theo và tất cả nội dung diễn đàn. Mặc dù nguồn có thể được khôi phục, nhưng việc thiếu theo dõi, ghi nhật ký hoặc cảnh báo đã dẫn đến một vụ vi phạm tồi tệ hơn nhiều. Dự án phần mềm diễn đàn không còn hoạt động do sự cố này. Tình huống 2: Kẻ tấn công sử dụng cách quét người dùng sử dụng mật khẩu chung. Họ có thể tiếp quản tất cả các tài khoản bằng mật khẩu này. Đối với tất cả những người dùng khác, quá trình quét này chỉ để lại một lần đăng nhập sai. Sau một số ngày, điều này có thể được lặp lại với một mật khẩu khác. Tình huống 3: Một nhà bán lẻ lớn của Hoa Kỳ được báo cáo có một hộp cát phân tích phần mềm độc hại nội bộ phân tích các tệp đính kèm. Phần mềm hộp cát đã phát hiện ra phần mềm không mong muốn tiềm ẩn, nhưng không ai phản hồi với phát hiện này. Hộp cát đã đưa ra cảnh báo một thời gian trước khi phát hiện vi phạm do gian lận thẻ giao dịch của một ngân hàng bên ngoài. Kết luậnChắc chắn các website sẽ không thể nào thoát khỏi những lỗ hổng bảo mật, thông thường các lập trình viên mới vào nghề, Kinh nghiệm còn non kém sẽ mắc các lỗi này và để có một cách hợp lý để phòng ngừa nó thì cần phải có một sự đồng lòng cũng như là thống nhất trong quá trình kiểm tra hay lập trình. Bạn đừng lo lắng Chúng tôi sẽ cập nhật bài viết sau để khắc phục tình huống này. Xem thêm 20+ Công cụ phân tích lỗ hổng bảo mật kali linux Khi thuận tiện và truy cập từ xa đã trở nên quan trọng đối với nhân viên và người tiêu dùng trên toàn cầu, các ứng dụng web đã thấy sự gia tăng tương tự về nhu cầu.Các ứng dụng web cung cấp chức năng tương tự như các ứng dụng máy tính để bàn hoặc gốc, nhưng với sự tiện lợi của khả năng truy cập trình duyệt.Họ cũng dễ dàng cung cấp trên các nền tảng, tăng khả năng của tổ chức để xây dựng một cơ sở người dùng lớn hơn.Thật không may, các ứng dụng web cũng giới thiệu các cổng cho những kẻ tấn công vi phạm cơ sở dữ liệu và hệ thống khách hàng. Do rủi ro bảo mật bẩm sinh đi kèm với các ứng dụng dựa trên trình duyệt-& NBSP;Cũng như những tiến bộ trong các phương thức xây dựng và triển khai - các nhà phát triển hiện có trách nhiệm lớn hơn trong việc đảm bảo mã của các ứng dụng web mới mà họ phát hành.Nhiều nhà phát triển trước đây đã hoạt động trên cơ sở bảo mật của người Hồi giáo theo cơ sở tối nghĩa: họ tin rằng tin tặc sẽ đào đủ sâu để khai thác các lỗ hổng trong mã.Điều này đã được chứng minh là một sai lầm.Bây giờ, điều cần thiết là các nhà phát triển thay đổi suy nghĩ của họ và chịu trách nhiệm đảm bảo các ứng dụng trước khi họ phát hành chúng. Dự án bảo mật ứng dụng web mở (OWASP) là một tổ chức phi lợi nhuận của ngành dành riêng để thúc đẩy bảo mật trên web.Cứ sau vài năm, họ tạo ra một danh sách cập nhật của 10 lỗ hổng ứng dụng web hàng đầu. Năm 2021, danh sách này bao gồm:
Để phân tích chuyên sâu về các lỗ hổng này và cách khắc phục chúng, hãy xem phân tích của chúng tôi về Top 10 OWASP Chín thực tiễn tốt nhất để đảm bảo ứng dụng web của bạn
1. Sản xuất bảo mật còn lại trong SDLCShift Left Security thay thế các quy trình và công cụ bảo mật kế thừa được thiết kế cho phương pháp giải phóng thác bằng cách di chuyển bảo mật càng sớm càng tốt trong vòng đời phát triển phần mềm (SDLC).Các phương pháp sau sẽ tạo điều kiện cho sự thay đổi này:
2. Xác thực tiêm và đầu vàoTiêm là một gia đình các phương pháp tấn công trong đó mã độc hại được chèn vào trình duyệt hoặc các hình thức nhập khác.Hai ví dụ về tiêm là tiêm SQL và kịch bản chéo trang, sử dụng mã SQL độc hại và tập lệnh độc hại trong các mặt tiền trang web, tương ứng.Để bảo vệ chống lại các cuộc tấn công tiêm, nên sử dụng các phương pháp xác thực đầu vào để đảm bảo chỉ có thể nhập dữ liệu được định dạng đúng, do đó chặn bất kỳ mã độc nào vào hệ thống. 3. Quản lý xác thực người dùngVới các lỗi nhận dạng và xác thực của người dùng ở vị trí thứ bảy trong danh sách Top 10 của OWASP 2021, xác thực người dùng là một khía cạnh quan trọng của bảo mật dựa trên web.Quản lý xác thực người dùng giúp tăng cường tên người dùng và mật khẩu và cung cấp cho quản trị viên bảo mật nhiều tùy chọn để đảm bảo chỉ các bên được phê duyệt đang truy cập ứng dụng của họ.Một phương pháp như vậy là xác thực đa yếu tố, yêu cầu người dùng chứng minh họ là ai bằng cách sử dụng ít nhất hai loại xác thực. 4. Mã hóa dữ liệuNhững thất bại liên quan đến mật mã (hoặc thiếu nó) có thể dẫn đến các vi phạm thông tin nhạy cảm, tạo ra mật mã số hai trên Top 10. mã hóa dữ liệu, cả khi nghỉ ngơi và vận chuyển, là một sự bảo vệ chính trong trường hợp vi phạm.Bản thân các thuật toán mã hóa thường có trong các gói nguồn mở và đã được viết bởi các chuyên gia mật mã.Trong thực tế, mã hóa có nghĩa là thực thi các điều khiển và tiêu chuẩn xung quanh mã hóa, chẳng hạn như mã hóa tất cả lưu lượng truy cập bên trong và bên ngoài, sử dụng các thuật toán mã hóa được cập nhật và thực thi mã hóa. 5. Tìm và sửa lỗi cấu hình saiCác cấu hình sai - như không thực hiện nguyên tắc truy cập đặc quyền tối thiểu - giúp các bên thứ ba dễ dàng truy cập dữ liệu nhạy cảm hơn.Hầu hết các cấu hình sai được giới thiệu bởi lỗi thủ công, vì vậy sử dụng cơ sở hạ tầng làm mã (IAC) và tự động hóa có thể giúp ngăn chặn chúng.Ngoài ra, các công cụ quét như SNYK IAC có thể phát hiện và khắc phục các cấu hình sai trước khi chúng đến môi trường sản xuất. 6. Ghi nhật ký & Kiểm toán & NBSP;Điều này giải quyết số chín trong danh sách Top 10 của OWASP: lỗi ghi nhật ký và giám sát bảo mật.Có rất ít dữ liệu trực tiếp để hiển thị cách nhật ký và kiểm toán có thể ngăn chặn các vi phạm, nhưng việc phát hiện và giải quyết các vi phạm vẫn không thể phân biệt được.Danh mục này bao gồm các sự kiện ghi nhật ký như đăng nhập và giao dịch đáng chú ý, giám sát nhật ký cho hoạt động bất thường và tạo cảnh báo tự động hoặc các bước khắc phục tự động trong trường hợp hành vi bất thường được phát hiện. 7. Tường lửa ứng dụng webTường lửa ứng dụng web (WAF) nằm giữa máy khách và máy chủ web và đóng vai trò là proxy cho lưu lượng truy cập giữa chúng.Bằng cách thiết lập các quy tắc trong WAF, bạn có thể bảo vệ một ứng dụng web hoặc bộ ứng dụng web chống lại các cuộc tấn công thông thường như tiêm. 8. Kiểm tra bảo mật trong CI/CD của bạnChờ đợi để chạy các thử nghiệm bảo mật cho đến khi kết thúc các đường ống CI/CD, hoặc tệ hơn, khi các ứng dụng web đang chạy trong môi trường trực tiếp, dẫn đến khắc phục tốn kém và tốn thời gian.Bạn sẽ tiết kiệm thời gian, tiền bạc và sự thất vọng của nhóm bạn bằng cách tích hợp kiểm tra bảo mật vào CI/CD của bạn.Các công cụ tự động hóa làm cho điều này có thể với sự gián đoạn tối thiểu cho quy trình làm việc của nhà phát triển. Thực hiện các quy trình ủy quyền ngăn chặn sự leo thang đặc quyền, một cuộc tấn công trong đó người dùng có được quyền truy cập vào một ứng dụng sau đó thay đổi đặc quyền hoặc vai trò của họ để mở rộng quyền truy cập.Tăng đặc quyền có thể được phát hiện thông qua kiểm tra thâm nhập, được giảm thiểu bằng cách chạy các ứng dụng với quyền truy cập ít đặc quyền nhất và được ngăn chặn bằng cách cấu hình các khóa xác thực đúng. Hãy để thảo luận ngắn gọn về các công cụ có sẵn để giúp các nhà phát triển đánh giá và khắc phục bảo mật ứng dụng web. SASTCác công cụ kiểm tra bảo mật ứng dụng tĩnh (SAST) như mã quét mã SNYK đối với các thực tiễn tốt nhất được xác định trước để xác định các mẫu mã có vấn đề.SAST phụ thuộc vào ngôn ngữ lập trình cụ thể mà bạn sử dụng.Đối với một số ví dụ về các đoạn trích được quét bởi SNYK, SAST, hãy xem đoạn mã mã của chúng tôi. DastKiểm tra bảo mật ứng dụng động (DAST) quét các ứng dụng trong thời gian chạy và độc lập với ngôn ngữ. Để biết thêm thông tin về sự khác biệt giữa SAST và DAST, hãy đọc bài đăng trên blog của chúng tôi. SCACác công cụ phân tích thành phần phần mềm (SCA), chẳng hạn như nguồn mở SNYK, quét các phụ thuộc mã của bên thứ ba trong các ứng dụng web.Vì phát triển ứng dụng hiện đại được đặc trưng bởi việc sử dụng nặng các thư viện nguồn mở, SCA là một công cụ hiệu quả trong nhóm bảo mật của kho vũ khí. Pen-testingKiểm tra thâm nhập, một chức năng của tin tặc đạo đức, tìm cách khám phá và giải quyết bất kỳ vectơ tấn công nào có thể được sử dụng để vi phạm ứng dụng web.Kiểm tra bút thường xuyên là một yêu cầu đối với một số quy định, bao gồm DSS PCI và được khuyến nghị mạnh mẽ cho tất cả các ứng dụng web. Sự cố chấpTự bảo vệ ứng dụng thời gian chạy (RASP) là một công nghệ được xây dựng thành các ứng dụng và giám sát hành vi của họ đối với những gì ứng dụng nên hoặc không nên làm.Nó hoạt động như một bổ sung cho các công nghệ chu vi như WAF, nhưng nó có thể không phát hiện ra một số phương thức tấn công dựa trên xác thực hoặc ủy quyền.RASP nên được sử dụng cùng với các công cụ khác như SAST và SCA để có hiệu quả hoàn toàn. Làm thế nào SNYK có thể giúp bạn xây dựng các ứng dụng web an toànNền tảng bảo mật của nhà phát triển SNYK, tập hợp nguồn mở SNYK, mã SNYK, thùng chứa SNYK và các công cụ SNYK IAC trong một nền tảng duy nhất.Các nhà phát triển ứng dụng web có thể sử dụng SNYK trong các quy trình công việc hiện tại của họ để quét mã và các thành phần nguồn mở cho các lỗ hổng hoặc cấu hình sai.Cơ sở dữ liệu tình báo lỗ hổng toàn diện của chúng tôi được quản lý bởi các chuyên gia bảo mật của SNYK và là toàn diện nhất trên thị trường. & NBSP; Để tìm hiểu thêm về ứng dụng web, hãy xem các bài viết này: Bảo mật ứng dụng được giải thích - Công cụ & Xu hướng cho 2022 & NBSP; Kiểm tra bảo mật ứng dụng - Câu hỏi hàng đầu được trả lời |Snyk Đánh giá bảo mật ứng dụng: 5 bước chính |Snyk Câu hỏi thường gặp về bảo mật ứng dụng webBảo mật ứng dụng web là gì?Bảo mật ứng dụng web là một tập hợp các công cụ và điều khiển được thiết kế để bảo vệ các ứng dụng web và các tài sản liên quan.Khái niệm này bao gồm một tập hợp các quy trình để khám phá và khắc phục các lỗ hổng trong các ứng dụng web.Nó cũng bao gồm các thực tiễn phát triển an toàn và kết hợp bảo mật từ thiết kế đến thực hiện. Tại sao bảo mật ứng dụng web lại quan trọng?Bảo mật ứng dụng web rất quan trọng vì hai lý do: một, các ứng dụng web là một cách để những kẻ tấn công có quyền truy cập vào thông tin nhạy cảm trong cơ sở dữ liệu của bạn.Hai, chúng cũng là một cách để các cuộc tấn công giai đoạn chống lại người dùng ứng dụng. Ba rủi ro bảo mật ứng dụng phổ biến nhất là gì?Ba rủi ro bảo mật ứng dụng phổ biến nhất là kiểm soát truy cập bị hỏng, lỗi mật mã và tiêm (bao gồm SQL Incer và Scripting chéo trang), theo Top 10 của OWASP 2021. Làm thế nào để bạn bảo mật một ứng dụng web?Đảm bảo một ứng dụng web bắt đầu ở giai đoạn phát triển sớm nhất, trong đó mô hình hóa và mô hình đe dọa an toàn được sử dụng để đảm bảo một ứng dụng được xây dựng với bảo mật.Trong quá trình xây dựng, các nhà phát triển nên sử dụng các công cụ quét để phát hiện bất kỳ lỗ hổng và cấu hình sai nào.Khi một chu kỳ phát hành hoàn tất, nên tiến hành thử nghiệm thâm nhập để khám phá bất kỳ lỗ hổng nào trước đây không bị phát hiện. OWASP 10 rủi ro bảo mật ứng dụng web hàng đầu là gì?Chúng tôi chia nhỏ từng mục, mức rủi ro của nó, cách kiểm tra cho chúng và cách giải quyết từng mục ... Mũi tiêm..... Thiết kế không an toàn..... Cấu hình sai bảo mật..... Các thành phần dễ bị tổn thương và lỗi thời..... Kiểm soát truy cập bị hỏng..... Cấu hình sai bảo mật..... Kịch bản chéo trang..... Hút thuốc không an toàn .. Rủi ro bảo mật trong ứng dụng web là gì?Ba rủi ro bảo mật ứng dụng phổ biến nhất là kiểm soát truy cập bị hỏng, lỗi mật mã và tiêm (bao gồm SQL Incer và Scripting chéo trang), theo Top 10 của OWASP 2021.broken access control, cryptographic failures, and injection (including SQL injection and cross-site scripting), according to the 2021 OWASP Top 10.
Điều nào sau đây không có trong 10 rủi ro bảo mật ứng dụng web của OWASP?Câu 75: Điều nào sau đây không có trong 10 rủi ro bảo mật ứng dụng web hàng đầu của OWASP?Giải thích: Phơi nhiễm dữ liệu nhạy cảm, các thực thể bên ngoài XML và quá trình giảm dần không an toàn đều được đưa vào danh sách top 10 của OWASP.Không tuân thủ không có trong danh sách.Noncompliance is not on the list.
Điều nào sau đây đại diện cho mười rủi ro ứng dụng web hàng đầu?Top 10 rủi ro bảo mật ứng dụng web.. Kiểm soát truy cập bị hỏng..... Thất bại mật mã..... Mũi tiêm..... Thiết kế không an toàn..... Cấu hình sai bảo mật..... Các thành phần dễ bị tổn thương và lỗi thời..... Xác định và xác thực thất bại..... Lỗi ghi nhật ký và giám sát bảo mật .. |
