10 lỗ hổng bảo mật web phổ biến nhất

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 có dễ dàng không? Cao nhất là thông tin hiển thị trên URL, Form 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 –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ả

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 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.

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

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ị

1. Danh sách trắng các trường đầu vào
2. 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ả

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
• URL

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ị

1. Các trường nhập Danh sách trắng
2. Mã hóa đầu vào đầu ra

Xác thực bị hỏng và quản lý phiên

Mô 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 hiển thị trên URL có thể dẫn đến cuộc 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 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ụ

1. Ứng dụng đặt vé máy bay hỗ trợ viết lại URL, đưa session ID 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.
2. 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.
3. 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ị

1. 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.
2. Không bao giờ tiết lộ bất kỳ thông tin xác thực nào trong URL hoặc Nhật ký.
3. 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ả

Nó xảy ra khi nhà phát triển hiển thị 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 dưới dạng 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 URL.

Ví dụ:

Việc thay đổi “userid” trong URL sau 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ị:

1. Thực hiện kiểm tra kiểm soát truy cập.
2. Tránh để lộ các tham chiếu đối tượng trong URL.
3. 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ả

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.

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 ý

• 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ị

1. Ủ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.
2. 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ả

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 sai sót như vậy dẫn đến sự thỏa hiệp toàn bộ hệ thống. Luôn cập nhật phần mềm cũng là một biện pháp bảo mật 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ụ

1. 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.
2. 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ị

1. 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.
2. Thay đổi tên người dùng và mật khẩu mặc định.
3. 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ả

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ị

1. Đả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.
2. Đả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ế quyền truy cập URL

Mô 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 truy cập các trang này.

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 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ụ

1. Kẻ tấn công nhận thấy URL chỉ ra vai trò là “/user/getaccounts”. Anh ấy sửa đổi thành “/admin/getaccounts”.
2. 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ị

1. Thực hiện kiểm tra kiểm soát truy cập mạnh mẽ.
2. Chính sách xác thực và ủy quyền phải dựa trên vai trò.
3. Hạn chế quyền truy cập vào các URL không mong muốn.

Bảo vệ lớp vận chuyển không đủ

Mô tả

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 truyền thông tin nhạy cảm như thông tin 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 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ị

1. Bật HTTP an toàn và chỉ thực thi chuyển thông tin xác thực qua HTTPS.
2. Đả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ả

Ứ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 URL tới người dùng có chứa URL chính hãng được gắn thêm 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 đã gửi của kẻ tấn công có thể duyệt nó 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ị

1. Đơ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.
2. 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.