OWASP hay Dự án Bảo mật Web Mở là một tổ chức từ thiện phi lợi nhuận tập trung vào việc cải thiện tính bảo mật của phần mềm và ứng dụng web.
Tổ chức công bố danh sách các lỗ hổng bảo mật web hàng đầu dựa trên dữ liệu từ các tổ chức bảo mật khác nhau.
Các lỗ hổng bảo mật web được ưu tiên tùy thuộc vào khả năng khai thác, khả năng phát hiện và tác động đến phần mềm.
- Khả năng khai thác -
Cần những gì để khai thác lỗ hổng bảo mật? Khả năng khai thác cao nhất khi tấn công chỉ cần trình duyệt web và thấp nhất là lập trình và công cụ tiên tiến.
- Khả năng phát hiện -
Làm thế nào để dễ dàng phát hiện ra mối đe dọa? Cao nhất là thông tin hiển thị trên URL, Biểu mẫu hoặc Thông báo lỗi và thấp nhất là mã nguồn.
- Tác động hoặc Thiệt hại -
Bao nhiêu thiệt hại sẽ được thực hiện nếu lỗ hổng bảo mật bị lộ hoặc bị tấn công? Cao nhất là sự cố toàn bộ hệ thống và thấp nhất là không có gì cả.
Mục đích chính của OWASP Top 10 là giáo dục các nhà phát triển, nhà thiết kế, nhà quản lý, kiến trúc sư và tổ chức về các lỗ hổng bảo mật quan trọng nhất.
10 lỗ hổng bảo mật hàng đầu theo OWASP Top 10 là:
- SQL Injection
- Cross Site Scripting
- Xác thực bị hỏng và quản lý phiên
- Tham chiếu đối tượng trực tiếp không an toàn
- Yêu cầu chéo trang web giả mạo
- Cấu hình sai bảo mật
- Lưu trữ mật mã không an toàn
- Không thể hạn chế quyền truy cập URL
- Bảo vệ lớp truyền tải không đủ
- Chuyển hướng và Chuyển tiếp chưa được kiểm chứng
SQL Injection
Sự miêu tả
Injection là một lỗ hổng bảo mật cho phép kẻ tấn công thay đổi các câu lệnh SQL phụ trợ bằng cách thao túng dữ liệu do người dùng cung cấp.
Injection xảy ra khi đầu vào của người dùng được gửi đến trình thông dịch như một phần của lệnh hoặc truy vấn và lừa trình thông dịch thực hiện các lệnh không mong muốn và cấp quyền truy cập vào dữ liệu trái phép.
Lệnh SQL khi được ứng dụng web thực thi cũng có thể hiển thị cơ sở dữ liệu phía sau.
Hàm ý
- Kẻ tấn công có thể đưa nội dung độc hại vào các trường dễ bị tấn công.
- Dữ liệu nhạy cảm như Tên người dùng, Mật khẩu, v.v. có thể được đọc từ cơ sở dữ liệu.
- Dữ liệu cơ sở dữ liệu có thể được sửa đổi (Chèn / Cập nhật / Xóa).
- Các hoạt động quản trị có thể được thực hiện trên cơ sở dữ liệu
Đối tượng dễ bị tổn thương
- Các trường đầu vào
- URL tương tác với cơ sở dữ liệu.
Ví dụ:
- Đưa vào SQL trên Trang đăng nhập
Đăng nhập vào một ứng dụng mà không có thông tin xác thực hợp lệ.
Tên người dùng hợp lệ có sẵn và mật khẩu không có sẵn.
URL kiểm tra: http://demo.testfire.net/default.aspx
Tên người dùng: sjones
Mật khẩu: 1 = 1 'hoặc pass123
Truy vấn SQL được tạo và gửi tới Trình thông dịch như bên dưới
SELECT * FROM Users WHERE User_Name = sjones AND Password = 1 = 1 'hoặc pass123;
khuyến nghị
- Danh sách trắng các trường đầu vào
- Tránh hiển thị các thông báo lỗi chi tiết hữu ích cho kẻ tấn công.
Cross Site Scripting
Sự miêu tả
Cross Site Scripting còn được gọi ngắn gọn là XSS.
Các lỗ hổng XSS nhắm mục tiêu các tập lệnh được nhúng trong một trang được thực thi ở phía máy khách, tức là trình duyệt của người dùng chứ không phải ở phía máy chủ. Những sai sót này có thể xảy ra khi ứng dụng lấy dữ liệu không đáng tin cậy và gửi đến trình duyệt web mà không được xác thực thích hợp.
Những kẻ tấn công có thể sử dụng XSS để thực thi các tập lệnh độc hại trên người dùng trong trường hợp này là trình duyệt nạn nhân. Vì trình duyệt không thể biết liệu tập lệnh có đáng tin cậy hay không, nên tập lệnh sẽ được thực thi và kẻ tấn công có thể chiếm đoạt cookie phiên, hủy giao diện trang web hoặc chuyển hướng người dùng đến một trang web không mong muốn và độc hại.
XSS là một cuộc tấn công cho phép kẻ tấn công thực thi các tập lệnh trên trình duyệt của nạn nhân.
Hàm ý:
- Khi sử dụng lỗ hổng bảo mật này, kẻ tấn công có thể đưa các tập lệnh vào ứng dụng, có thể đánh cắp cookie phiên, phá hoại trang web và có thể chạy phần mềm độc hại trên máy của nạn nhân.
Đối tượng dễ bị tổn thương
- Các trường đầu vào
- URL
Các ví dụ
1. http://www.vulnerablesite.com/home?" < script > alert("xss") script >
Tập lệnh trên khi chạy trên trình duyệt, một hộp thông báo sẽ hiển thị nếu trang web dễ bị tấn công XSS.
Cuộc tấn công nghiêm trọng hơn có thể được thực hiện nếu kẻ tấn công muốn hiển thị hoặc lưu trữ cookie phiên.
2. http://demo.testfire.net/search.aspx?txtSearch
Đoạn script trên khi chạy, trình duyệt sẽ tải một khung vô hình trỏ đến http://google.com .
Cuộc tấn công có thể trở nên nghiêm trọng bằng cách chạy một tập lệnh độc hại trên trình duyệt.
khuyến nghị
- Các trường đầu vào của Danh sách trắng
- Mã hóa đầu ra đầu vào
Xác thực bị hỏng và quản lý phiên
Sự miêu tả
Các trang web thường tạo một cookie phiên và ID phiên cho mỗi phiên hợp lệ và những cookie này chứa dữ liệu nhạy cảm như tên người dùng, mật khẩu, v.v. Khi phiên kết thúc do đăng xuất hoặc trình duyệt bị đóng đột ngột, những cookie này sẽ bị vô hiệu hóa tức là đối với mỗi phiên sẽ có một cookie mới.
Nếu cookie không bị vô hiệu, dữ liệu nhạy cảm sẽ tồn tại trong hệ thống. Ví dụ, một người dùng sử dụng máy tính công cộng (Cyber Cafe), các cookie của trang web dễ bị tấn công sẽ nằm trên hệ thống và bị kẻ tấn công tiếp xúc. Kẻ tấn công sử dụng cùng một máy tính công cộng sau một thời gian, dữ liệu nhạy cảm bị xâm phạm.
Theo cách tương tự, một người dùng sử dụng máy tính công cộng, thay vì đăng xuất, anh ta đóng trình duyệt đột ngột. Kẻ tấn công sử dụng cùng một hệ thống, khi duyệt qua cùng một trang web dễ bị tấn công, phiên trước của nạn nhân sẽ được mở. Kẻ tấn công có thể làm bất cứ điều gì hắn muốn từ đánh cắp thông tin hồ sơ, thông tin thẻ tín dụng, v.v.
Kiểm tra nên được thực hiện để tìm ra sức mạnh của xác thực và quản lý phiên. Khóa, mã thông báo phiên, cookie phải được triển khai đúng cách mà không ảnh hưởng đến mật khẩu.
Đối tượng dễ bị tổn thương
- ID phiên hiển thị trên URL có thể dẫn đến tấn công cố định phiên.
- ID phiên giống nhau trước và sau khi đăng xuất và đăng nhập.
- Thời gian chờ của phiên không được triển khai chính xác.
- Ứng dụng đang chỉ định cùng một ID phiên cho mỗi phiên mới.
- Các phần đã xác thực của ứng dụng được bảo vệ bằng SSL và mật khẩu được lưu trữ ở định dạng băm hoặc mã hóa.
- Phiên có thể được sử dụng lại bởi người dùng có đặc quyền thấp.
Hàm ý
- Lợi dụng lỗ hổng này, kẻ tấn công có thể chiếm quyền điều khiển phiên, truy cập trái phép vào hệ thống cho phép tiết lộ và sửa đổi thông tin trái phép.
- Các phiên có thể tăng cao bằng cách sử dụng cookie bị đánh cắp hoặc phiên sử dụng XSS.
Các ví dụ
- Ứng dụng đặt vé máy bay hỗ trợ ghi lại URL, đưa ID phiên vào URL:
http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Bán vé đi Maldives)
Một người dùng đã được xác thực của trang web muốn cho bạn bè của mình biết về việc mua bán và gửi một email. Bạn bè nhận được ID phiên và có thể được sử dụng để sửa đổi trái phép hoặc sử dụng sai các chi tiết thẻ tín dụng đã lưu.
- Một ứng dụng dễ bị tấn công bởi XSS, theo đó kẻ tấn công có thể truy cập ID phiên và có thể được sử dụng để chiếm quyền điều khiển phiên.
- Thời gian chờ của ứ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 và đóng trình duyệt thay vì đăng xuất và bỏ đi. Một thời gian sau, kẻ tấn công sử dụng cùng một trình duyệt và phiên này được xác thực.
khuyến nghị
- Tất cả các yêu cầu xác thực và quản lý phiên phải được xác định theo Tiêu chuẩn xác minh bảo mật ứng dụng OWASP.
- Không bao giờ để lộ bất kỳ thông tin đăng nhập nào trong URL hoặc Nhật ký.
- Cũng cần nỗ lực mạnh mẽ để tránh các lỗ hổng XSS có thể được sử dụng để lấy cắp các ID phiên.
Tham chiếu đối tượng trực tiếp không an toàn
Sự miêu tả
Nó xảy ra khi nhà phát triển để lộ tham chiếu đến đối tượng triển khai nội bộ, chẳng hạn như tệp, thư mục hoặc khóa cơ sở dữ liệu như trong URL hoặc dưới dạng tham số FORM. Kẻ tấn công có thể sử dụng thông tin này để truy cập các đối tượng khác và có thể tạo ra một cuộc tấn công trong tương lai để truy cập dữ liệu trái phép.
Hàm ý
- Sử dụng lỗ hổng này, kẻ tấn công có thể truy cập vào các đối tượng bên trong trái phép, có thể sửa đổi dữ liệu hoặc xâm phạm ứng dụng.
Đối tượng dễ bị tổn thương
- Trong URL.
Ví dụ:
Thay đổi "userid" trong URL sau có thể khiến kẻ tấn công xem thông tin của người dùng khác.
http://www.vulnerablesite.com/userid=123 Được sửa đổi thành http://www.vulnerablesite.com/userid=124
Kẻ tấn công có thể xem thông tin người khác bằng cách thay đổi giá trị id người dùng.
Khuyến nghị:
- Thực hiện kiểm tra kiểm soát truy cập.
- Tránh để lộ các tham chiếu đối tượng trong URL.
- Xác minh ủy quyền cho tất cả các đối tượng tham chiếu.
Yêu cầu chéo trang web giả mạo
Sự miêu tả
Yêu cầu chéo trang web giả mạo là một yêu cầu giả mạo đến từ trang web chéo.
Cuộc tấn công CSRF là cuộc tấn công xảy ra khi một trang web, email hoặc chương trình độc hại khiến trình duyệt của người dùng thực hiện một hành động không mong muốn trên một trang web đáng tin cậy mà người dùng hiện đang được xác thực.
Một cuộc tấn công CSRF buộc trình duyệt của nạn nhân đã đăng nhập gửi một yêu cầu HTTP giả mạo, bao gồm cookie phiên của nạn nhân và bất kỳ thông tin xác thực tự động nào khác, đến một ứng dụng web dễ bị tấn công.
Một liên kết sẽ được kẻ tấn công gửi đến nạn nhân khi người dùng nhấp vào URL khi đăng nhập vào trang web gốc, dữ liệu sẽ bị đánh cắp khỏi trang web.
Hàm ý
- Sử dụng lỗ hổng này làm kẻ tấn công có thể thay đổi thông tin hồ sơ người dùng, thay đổi trạng thái, tạo người dùng mới thay mặt quản trị viên, v.v.
Đối tượng dễ bị tổn thương
- Trang hồ sơ người dùng
- Các biểu mẫu tài khoản người dùng
- Trang giao dịch kinh doanh
Các ví dụ
Nạn nhân đã đăng nhập vào một trang web ngân hàng bằng thông tin xác thực hợp lệ. Anh ta nhận được thư từ một kẻ tấn công nói rằng "Hãy nhấp vào đây để quyên góp $ 1 để gây ra."
Khi nạn nhân nhấp vào nó, một yêu cầu hợp lệ sẽ được tạo để quyên góp $ 1 cho một tài khoản cụ thể.
http://www.vulnerablebank.com/transfer.do?account=cause&amount=1
Kẻ tấn công nắm bắt yêu cầu này và tạo yêu cầu bên dưới và nhúng vào nút có nội dung "Tôi ủng hộ Nguyên nhân".
http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000
Vì phiên được xác thực và yêu cầu đến qua trang web ngân hàng, máy chủ sẽ chuyển $ 1000 đô la cho kẻ tấn công.
sự giới thiệu
- Ủy quyền sự hiện diện của người dùng trong khi thực hiện các hành động nhạy cảm.
- Triển khai các cơ chế như CAPTCHA, Xác thực lại và Mã thông báo yêu cầu duy nhất.
Cấu hình sai bảo mật
Sự miêu tả
Cấu hình Bảo mật phải được xác định và triển khai cho ứng dụng, khuôn khổ, máy chủ ứng dụng, máy chủ web, máy chủ cơ sở dữ liệu và nền tảng. Nếu chúng được định cấu hình đúng, kẻ tấn công có thể có quyền truy cập trái phép vào dữ liệu hoặc chức năng nhạy cảm.
Đôi khi những sai sót như vậy dẫn đến sự thỏa hiệp hoàn toàn hệ thống. Giữ phần mềm được cập nhật cũng là bảo mật tốt.
Hàm ý
- Sử dụng lỗ hổng này, kẻ tấn công có thể liệt kê công nghệ cơ bản và thông tin phiên bản máy chủ ứng dụng, thông tin cơ sở dữ liệu và thu thập thông tin về ứng dụng để thực hiện thêm một số cuộc tấn công.
Đối tượng dễ bị tổn thương
- URL
- Trường biểu mẫu
- Các trường đầu vào
Các ví dụ
- Bảng điều khiển quản trị máy chủ ứng dụng được cài đặt tự động và không bị xóa. Tài khoản mặc định không được thay đổi. Kẻ tấn công có thể đăng nhập bằng mật khẩu mặc định và có thể truy cập trái phép.
- Danh sách Thư mục không bị tắt trên máy chủ của bạn. Kẻ tấn công phát hiện ra và có thể chỉ cần liệt kê các thư mục để tìm bất kỳ tệp nào.
khuyến nghị
- Một kiến trúc ứng dụng mạnh mẽ cung cấp khả năng phân tách và bảo mật tốt giữa các thành phần.
- Thay đổi tên người dùng và mật khẩu mặc định.
- Vô hiệu hóa danh sách thư mục và thực hiện kiểm tra kiểm soát truy cập.
Lưu trữ mật mã không an toàn
Sự miêu tả
Lưu trữ mật mã không an toàn là một lỗ hổng phổ biến tồn tại khi dữ liệu nhạy cảm không được lưu trữ an toàn.
Thông tin đăng nhập người dùng, thông tin hồ sơ, chi tiết sức khỏe, thông tin thẻ tín dụng, v.v. nằm dưới thông tin dữ liệu nhạy cảm trên một trang web.
Dữ liệu này sẽ được lưu trữ trên cơ sở dữ liệu của ứng dụng. Khi dữ liệu này được lưu trữ không đúng cách bằng cách không sử dụng mã hóa hoặc băm *, nó sẽ dễ bị những kẻ tấn công tấn công.
(* Hashing là sự biến đổi các ký tự trong chuỗi thành các chuỗi ngắn hơn có độ dài cố định hoặc một khóa. Để giải mã chuỗi, nên có sẵn thuật toán được sử dụng để tạo khóa)
Hàm ý
- Bằng cách sử dụng lỗ hổng này, kẻ tấn công có thể đánh cắp, sửa đổi dữ liệu được bảo vệ yếu như vậy để thực hiện hành vi trộm cắp danh tính, gian lận thẻ tín dụng hoặc các tội phạm khác.
Đối tượng dễ bị tổn thương
- Cơ sở dữ liệu ứng dụng.
Các ví dụ
Trong một trong các ứng dụng ngân hàng, cơ sở dữ liệu mật khẩu sử dụng các hàm băm không có muối * để lưu trữ mật khẩu của mọi người. Một lỗ hổng SQL injection cho phép kẻ tấn công truy xuất tệp mật khẩu. Tất cả các hàm băm không ướp muối có thể bị cưỡng bức ngay lập tức trong khi mật khẩu có muối sẽ mất hàng nghìn năm.
(* Hàm băm không có muối - Salt là dữ liệu ngẫu nhiên được nối vào dữ liệu gốc. Salt được nối vào mật khẩu trước khi băm)
khuyến nghị
- Đảm bảo các thuật toán tiêu chuẩn mạnh phù hợp. Không tạo các thuật toán mật mã riêng. Chỉ sử dụng các thuật toán công khai đã được phê duyệt như AES, mật mã khóa công khai RSA và SHA-256, v.v.
- Đảm bảo các bản sao lưu ngoại vi được mã hóa, nhưng các khóa được quản lý và sao lưu riêng biệt.
Không thể hạn chế quyền truy cập URL
Sự miêu tả
Các ứng dụng web kiểm tra quyền truy cập URL trước khi hiển thị các liên kết và nút được bảo vệ. Các ứng dụng cần thực hiện kiểm tra kiểm soát truy cập tương tự mỗi khi các trang này được truy cập.
Trong hầu hết các ứng dụng, các trang, vị trí và tài nguyên đặc quyền không được hiển thị cho người dùng đặc quyền.
Bằng một suy đoán thông minh, kẻ tấn công có thể truy cập các trang đặc quyền. Kẻ tấn công có thể truy cập các trang nhạy cảm, gọi các chức năng và xem thông tin bí mật.
Hàm ý
- Việc sử dụng lỗ hổng bảo mật này, kẻ tấn công có thể truy cập vào các URL trái phép mà không cần đăng nhập vào ứng dụng và khai thác lỗ hổng. Kẻ tấn công có thể truy cập các trang nhạy cảm, gọi các chức năng và xem thông tin bí mật.
Đối tượng dễ bị tổn thương:
- URL
Các ví dụ
- Kẻ tấn công nhận thấy URL chỉ ra vai trò là "/ user / getaccounts." Anh ta sửa đổi thành "/ admin / getaccounts".
- Kẻ tấn công có thể thêm vai trò vào URL.
http://www.vulnerablsite.com có thể được sửa đổi thành http://www.vulnerablesite.com/admin
khuyến nghị
- Thực hiện kiểm tra kiểm soát truy cập mạnh mẽ.
- Các chính sách xác thực và ủy quyền phải dựa trên vai trò.
- Hạn chế quyền truy cập vào các URL không mong muốn.
Bảo vệ lớp truyền tải không đủ
Sự miêu tả
Giao dịch trao đổi thông tin giữa người dùng (máy khách) và máy chủ (ứng dụng). Các ứng dụng thường truyền thông tin nhạy cảm như chi tiết xác thực, thông tin thẻ tín dụng và mã thông báo phiên qua mạng.
Bằng cách sử dụng các thuật toán yếu hoặc sử dụng các chứng chỉ đã hết hạn hoặc không hợp lệ hoặc không sử dụng SSL có thể cho phép người dùng không tin cậy giao tiếp với nhau, điều này có thể ảnh hưởng đến ứng dụng web và lấy cắp thông tin nhạy cảm.
Hàm ý
- Lợi dụng lỗ hổng bảo mật web này, kẻ tấn công có thể đánh hơi thông tin đăng nhập của người dùng hợp pháp và giành quyền truy cập vào ứng dụng.
- Có thể ăn cắp thông tin thẻ tín dụng.
Đối tượng dễ bị tổn thương
- Dữ liệu được gửi qua mạng.
khuyến nghị
- Bật HTTP an toàn và chỉ thực thi chuyển thông tin xác thực qua HTTPS.
- Đảm bảo chứng chỉ của bạn hợp lệ và không hết hạn.
Ví dụ:
1. Một ứng dụng không sử dụng SSL, kẻ tấn công sẽ chỉ theo dõi lưu lượng mạng và quan sát cookie phiên nạn nhân đã được xác thực. Kẻ tấn công có thể đánh cắp cookie đó và thực hiện tấn công Man-in-the-Middle.
Chuyển hướng và Chuyển tiếp chưa được kiểm chứng
Sự miêu tả
Ứng dụng web sử dụng một số phương pháp để chuyển hướng và chuyển tiếp người dùng đến các trang khác cho một mục đích đã định.
Nếu không có xác thực thích hợp trong khi chuyển hướng đến các trang khác, những kẻ tấn công có thể sử dụng điều này và có thể chuyển hướng nạn nhân đến các trang web lừa đảo hoặc phần mềm độc hại hoặc sử dụng chuyển tiếp để truy cập các trang trái phép.
Hàm ý
- Kẻ tấn công có thể gửi một URL cho người dùng có chứa URL chính hãng được nối với URL độc hại được mã hóa. Người dùng chỉ cần nhìn thấy phần chính hãng của URL mà kẻ tấn công đã gửi có thể duyệt qua nó và có thể trở thành nạn nhân.
Các ví dụ
1. http://www.vulnerablesite.com/login.aspx?redirectURL=ownite.com
Đã sửa đổi thành
http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com
khuyến nghị
- Chỉ cần tránh sử dụng chuyển hướng và chuyển tiếp trong ứng dụng. Nếu được sử dụng, không liên quan đến việc sử dụng các tham số người dùng trong việc tính toán điểm đến.
- Nếu không thể tránh được các tham số đích, hãy đảm bảo rằng giá trị được cung cấp là hợp lệ và được ủy quyền cho người dùng.
Bài viết này được đóng góp bởi Prasanthi Eati