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:
- Cách tạo và sử dụng nội dung theo hướng dữ liệu để xây dựng liên kết
- Dữ liệu cấu trúc, Structured data cho SEO
- Bảo mật wordpress cho người mới bắt đầu
- Mã hóa mật mã: các khái niệm cơ bản
- Mật độ cụm từ khóa là gì và tại sao nó lại quan trọng?
- cách nhận biết website bị hack
- Các plugin quét lỗi hổng bảo mật tốt nhất wordpress
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 Authentication
Tá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:
- Ứng dụng của chúng ta trao đổi thông tin dưới dạng bản rõ (Plain text)
- Cơ chế sinh khoá yếu, không đủ an toàn. Việc lựa chọn kích thước khoá cũng như thuật toán sinh phù hợp là điều vô cùng quan trọng
- Ứng dụng phía người dùng không xác thực các chứng chỉ khi trao đổi thông tin với Server
- Phương pháp đề phòng lỗ hỏng
- Định mức nhạy cảm các dữ liệu được lưu trữ tùy theo các tính chất luật pháp& pháp luật. Từ đó lựa chọn cơ chế kiểm soát phù hợp cho từng mức độ
- Lọc và loại bỏ những thông tin nhạy cảm không cần thiết, hạn chế rủi ro mất mát có thể xảy ra
- Đảm bảo sử dụng những thuật toán mã hoá, sinh khoá tiêu chuẩn, an toàn ở thời điểm hiện tại
- Không lưu những thông tin nhạy cảm tại Cache
Broken Access Control
Tá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 Misconfiguration
Thô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 :
- Ứng dụng được mở và vận hành khi đang trong chế độ debug.
- Directory listing
- Sử dụng phần mềm lỗi thời (WordPress plugin, PhpMyAdmin cũ)
- Cài đặt các dịch vụ không cần thiết.
- Không thay đổi default keyhoặc mật khẩu
- Trả về lỗi xử lý thông tin cho kẻ tấn công lợi dụng để tấn công, chẳng hạn như stack traces.
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 Deserialization
Deserialization 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:
- Ghi dữ liệu cấu trúc phức tạp, vào tập tin hoặc cơ sở dữ liệu.
- Gửi dữ liệu cấu trúc phức tạp, qua mạng internet, giữa các thành phần trong ứng dụng.
- Điều quan trọng, thự hiện tuần tự đối tượng, trạng thái của đối tượng cũng được duy trì. Có nghĩa là các thuộc tính và phương thức của đối tượng được giữ nguyên giá trị, cùng với các giá trị của chúng.
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ận
Chắ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.
