10 lỗ hổng bảo mật web phổ biến nhất
Oliver Jones
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 này 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ừ nhiều 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 lên phần mềm.
- Khả năng khai thác –Cần làm gì để khai thác lỗ hổng bảo mật? Khả năng khai thác cao nhất khi cuộc tấn công chỉ cần trình duyệt web và thấp nhất là các công cụ và lập trình tiên tiến.
- Khả năng phát hiện – Việc phát hiện mối đe dọa dễ đến mức nào? Thông tin hiển thị trên có mức độ dễ phát hiện cao nhất. URLThông báo lỗi hoặc biểu mẫu, và cấp thấp nhất là mã nguồn.
- Tác động hoặc Thiệt hại –Mức độ thiệt hại sẽ xảy ra nếu lỗ hổng bảo mật bị lộ hoặc bị tấn công? Cao nhất là hệ thống bị hỏng hoàn toàn 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à các 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
Mô tả Chi tiết
Tiêm là một lỗ hổng bảo mật cho phép kẻ tấn công thay đổi chương trình phụ trợ SQL các câu lệnh bằng cách thao tác dữ liệu do người dùng cung cấp.
Việc tiêm nhiễm xảy ra khi dữ liệu đầ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 thi các lệnh ngoài ý 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ể tiêm 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).
- Quản trị Operacác thao tác có thể được thực thi trên cơ sở dữ liệu
Đối tượng dễ bị tổn thương
- Các trường đầu vào
- URLđang tương tác với cơ sở dữ liệu.
Ví dụ:
- SQL injection 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.
Thử nghiệm URL: 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
CHỌN * TỪ Người dùng Ở ĐÂU Tên người dùng = sjones VÀ Mật khẩu = 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.
Viết kịch bản trang web chéo
Mô tả Chi tiết
Cross Site Scripting còn được gọi ngắn gọn là XSS.
Lỗ hổng XSS nhắm vào 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 thay vì ở 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ó tới 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 quyền điều khiển cookie phiên, làm xấu trang web hoặc chuyển hướng người dùng đến một trang web độc hại và không mong muốn.
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 ý:
- Lợi dụng lỗ hổng bảo mật này, kẻ tấn công có thể đưa tập lệnh vào ứng dụng, đánh cắp cookie phiên, làm hỏng 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
- URLs
Các ví dụ
1. http://www.vulnerablesite.com/home?”<script>alert(“xss”)</script>
Khi chạy đoạn mã trên trên trình duyệt, hộp thông báo sẽ hiển thị nếu trang web có lỗ hổ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 <iframe> http://google.com chiều rộng = 500 chiều cao 500>
Đoạn script trên khi chạy, trình duyệt sẽ tải một khung vô hình trỏ tới http://google.com.
Cuộc tấn công có thể trở nên nghiêm trọng hơn 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 nhập Danh sách trắng
- Mã hóa đầu vào đầu ra
Xác thực bị hỏng và quản lý phiên
Mô tả Chi tiết
Các trang web thường tạo 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 nên có một cookie mới.
Nếu cookie không bị vô hiệu hóa, dữ liệu nhạy cảm sẽ tồn tại trong hệ thống. Ví dụ: người dùng sử dụng máy tính công cộng (Cyber Cafe), 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 sẽ bị xâm phạm.
Tương tự như vậy, một người dùng sử dụng máy tính công cộng, thay vì đăng xuất, anh ta lại đóng trình duyệt một cách đột ngột. Kẻ tấn công sử dụng cùng một hệ thống, khi duyệt cùng một trang web có lỗ hổ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ì mình muốn từ việc đánh cắp thông tin hồ sơ, thông tin thẻ tín dụng, v.v.
Cần thực hiện kiểm tra để tìm ra sức mạnh của việc 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 bị lộ trên URL có thể dẫn đến chứng ám ả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 này 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ể được kích hoạt cao bằng cách sử dụng cookie bị đánh cắp hoặc các phiên sử dụng XSS.
Các ví dụ
- Ứng dụng đặt vé máy bay hỗ trợ URL viết lại, đưa ID phiên vào URL:http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Bán vé đến Maldives) Một người dùng đã xác thực của trang web muốn cho bạn bè của mình biết về việc bán vé và gửi email. Bạn bè của họ nhận được ID phiên và có thể được sử dụng để thực hiện các sửa đổi trái phép hoặc sử dụng sai thông tin thẻ tín dụng đã lưu.
- Một ứng dụng dễ bị XSS tấn công, 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 thiết lập đúng. 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. Kẻ tấn công sử dụng cùng trình duyệt đó sau một thời gian và phiên được xác thực.
Khuyến nghị
- Mọi yêu cầu về 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.
- Tuyệt đối không để lộ bất kỳ thông tin đăng nhập nào. URLhoặc Nhật ký.
- Cũng cần nỗ lực mạnh mẽ để tránh các lỗi XSS có thể được sử dụng để đánh cắp ID phiên.
Tham chiếu đối tượng trực tiếp không an toàn
Mô tả Chi tiết
Lỗi này xảy ra khi nhà phát triển để lộ tham chiếu đến một đố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 ví dụ sau: 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 ý
- Lợi dụng lỗ hổng này, kẻ tấn công có thể truy cập vào các đối tượng nội bộ 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 tạp chí URL.
Ví dụ:
Thay đổi “userid” trong phần sau URL Điều này có thể khiến kẻ tấn công xem được thông tin của người dùng khác.
http://www.vulnerablesite.com/userid=123 Đã sửa đổi thành http://www.vulnerablesite.com/userid=124
Kẻ tấn công có thể xem thông tin của 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 URLs.
- Xác minh ủy quyền cho tất cả các đối tượng tham chiếu.
Cross Site Yêu cầu giả mạo
Mô tả Chi tiết
Giả mạo yêu cầu trang web chéo là một yêu cầu giả mạo đến từ trang web chéo.
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 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 đã 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 nào khác được tự động đưa vào, tới một ứng dụng web dễ bị tấn công.
Kẻ tấn công sẽ gửi một liên kết đến nạn nhân khi người dùng nhấp vào liên kết đó. URL Khi đăng nhập vào trang web gốc, dữ liệu sẽ bị đánh cắp từ trang web đó.
Hàm ý
- Lợi dụng lỗ hổng này để 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
- 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 trang web ngân hàng bằng thông tin đăng nhập hợp lệ. Anh ta nhận được email từ kẻ tấn công nói rằng "Vui lòng nhấp vào đây để quyên góp 1 đô la cho mục đích chính đáng".
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 rồi 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 được gửi qua trang web của ngân hàng nên máy chủ sẽ chuyển 1000 đô la cho kẻ tấn công.
Khuyến nghị
- Ủ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
Mô tả Chi tiết
Cấu hình bảo mật phải được xác định và triển khai cho ứng dụng, khung, 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 những thứ này được cấu hình đúng cách, 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 lỗi như vậy dẫn đến việc hệ thống bị xâm phạm hoàn toàn. Hãy giữ vững lập trường.ping Phần mềm được cập nhật thường xuyên cũng đảm bảo an ninh tốt.
Hàm ý
- Lợi dụng lỗ hổng này, kẻ tấn công có thể liệt kê thông tin phiên bản máy chủ ứng dụng và công nghệ cơ bản, thông tin cơ sở dữ liệu và lấy 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
- Trường nhập
Các ví dụ
- Bảng điều khiển dành cho quản trị viên 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 bị 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ị vô hiệu hóa trên máy chủ của bạn. Kẻ tấn công phát hiện 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ị
- Kiến trúc ứng dụng mạnh mẽ, cung cấp khả năng tách biệt 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
Mô tả Chi tiế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 của người dùng, thông tin hồ sơ, thông tin sức khỏe, thông tin thẻ tín dụng, v.v. nằm trong danh mục thông tin dữ liệu nhạy cảm trên trang web.
Dữ liệu này sẽ được lưu trữ trên cơ sở dữ liệu ứ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ị kẻ tấn công tấn công.
(*Băm là chuyển đổi các ký tự 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, cầ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 kém đó để 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 những ứng dụng ngân hàng, cơ sở dữ liệu mật khẩu sử dụng hàm băm không có muối * để lưu trữ mật khẩu của mọi người. Lỗ hổng SQL SQL cho phép kẻ tấn công lấy lại tệp mật khẩu. Tất cả các giá trị băm không có muối có thể bị ép buộc một cách nhanh chóng trong khi đó, mật khẩu có muối sẽ mất hàng nghìn năm.
(*Băm không muối – Muối là dữ liệu ngẫu nhiên được thêm vào dữ liệu gốc. Muối được thêm 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 mẽ phù hợp. Không tạo các thuật toán mã hóa 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 hạn chế được URL Truy Cập
Mô tả Chi tiết
Kiểm tra ứng dụng web URL Kiểm tra quyền truy cập trước khi hiển thị các liên kết và nút được bảo vệ. Ứng dụng cần thực hiện các kiểm tra quyền 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ó đặc quyền.
Bằng cách đ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 ý
- Lợi dụng lỗ hổng này, kẻ tấn công có thể truy cập trái phép vào hệ thống. URLKẻ tấn công có thể truy cập các trang nhạy cảm, gọi các hàm và xem thông tin bí mật mà không cần đăng nhập vào ứng dụng.
Đối tượng dễ bị tổn thương:
- URLs
Các ví dụ
- Kẻ tấn công nhận thấy URL Chỉ định vai trò là “/user/getaccounts”. Anh ấy 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 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ẽ.
- 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 những nội dung không mong muốn URLs.
Bảo vệ lớp vận chuyển không đủ
Mô tả Chi tiết
Nó xử lý việc 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 xuyên... transmit 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ã phiên được truyền qua mạng.
Bằng cách sử dụng các thuật toán yếu hoặc sử dụng 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 thông tin liên lạc bị lộ với những người dùng không đáng tin cậy, điều này có thể làm tổn hại đến ứng dụng web và/hoặc đánh 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 cắp thông tin xác thực hợp pháp của người dùng và giành quyền truy cập vào ứng dụng.
- Có thể đánh 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ỉ giám sát 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 cuộc tấn công Man-in-the-Middle.
Chuyển hướng và chuyển tiếp không được xác thực
Mô tả Chi tiế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ụ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, kẻ tấn công có thể lợi 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 thông tin xác thực URL được đính kèm với mã độc hại được mã hóa URLNgười dùng chỉ cần nhìn thấy phần chân thực trong tin nhắn mà kẻ tấn công gửi đi là có thể nhận ra. URL Có thể truy cập vào đó và có thể trở thành nạn nhân.
Các ví dụ
1.http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com
Đã sửa đổi thành
http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com
Khuyến nghị
- Đơn giản 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 tham số người dùng để 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.
