Không có gì bí mật khi các doanh nghiệp ngày càng sử dụng nhiều ứng dụng web trong thời đại ngày nay. Các ứng dụng web giúp sắp xếp hợp lý các hoạt động của công ty, nâng cao hiệu quả và do đó tiết kiệm chi phí cho các tác vụ mà nếu không sẽ phải thực hiện thủ công. Các ứng dụng web dễ gặp rủi ro và bị tấn công mạng mặc dù chúng ngày càng phổ biến. Bài viết này sẽ cung cấp thông tin chi tiết
Không có gì bí mật khi các doanh nghiệp ngày càng sử dụng nhiều ứng dụng web trong thời đại ngày nay. Ứng dụng web giúp sắp xếp hợp lý các hoạt động của công ty, nâng cao hiệu quả và do đó tiết kiệm chi phí cho các tác vụ mà nếu không sẽ phải thực hiện thủ công.
Ứng dụng web dễ gặp rủi ro và tấn công mạng mặc dù chúng ngày càng phổ biến. Bài viết này sẽ cung cấp thông tin chi tiết về các cuộc tấn công đáng kể mà ứng dụng web dễ bị tấn công. Sau đó, bạn sẽ khám phá cách kết hợp proxy ngược để giảm thiểu các mối đe dọa.
Nhưng trước khi đi sâu vào khía cạnh bảo mật, chúng ta hãy xem xét kiến trúc của một ứng dụng web thông thường.
Trong hầu hết các trường hợp, ứng dụng web bao gồm máy chủ web và trang web. Máy chủ web chấp nhận yêu cầu từ máy khách (trình duyệt web của bạn), máy chủ web xử lý và trả về phản hồi cho máy khách.
Trong khi phía máy chủ được mã hóa bằng các ngôn ngữ lập trình động như PHP, Python, ASP.NET, v.v. thì phía máy khách được mã hóa bằng HTML, CSS và JavaScript. Giao tiếp giữa máy khách và máy chủ diễn ra thông qua giao thức HTTP.
Bạn có thể tham khảo bài viết này để biết thêm thông tin về cấu trúc của các ứng dụng web. Hình bên dưới cho thấy một giao tiếp máy khách-máy chủ điển hình.
Mọi giao tiếp dường như đều đơn giản trong sơ đồ trên, với các yêu cầu được truyền qua lại giữa máy khách và máy chủ. Tuy nhiên, không phải lúc nào cũng như vậy.
Thật không may, các ứng dụng web sử dụng thiết kế trên dễ bị tấn công mạng bởi những kẻ bên ngoài giữa máy khách và máy chủ.
Hãy cùng xem qua một số số liệu thống kê thú vị nhất về các cuộc tấn công mạng trước khi đi sâu vào bản chất của các cuộc tấn công này.
Theo dữ liệu về lỗ hổng ứng dụng web của Positive Technologies từ năm 2018, ngành Tài chính và Ngân hàng chiếm 28% trong tổng số các ứng dụng web bị tấn công. Dữ liệu cũng chỉ ra rằng 14% các cuộc tấn công mạng nhắm vào các ứng dụng trực tuyến trong ngành Viễn thông và Sản xuất, với 11% nhắm vào các ứng dụng vận tải.
Các ngành công nghiệp khác phải đối mặt với rủi ro bao gồm các tổ chức chính phủ (11%), CNTT, Thương mại điện tử và phương tiện truyền thông đại chúng.
Về các loại tấn công, một báo cáo khác, F5 , nêu rằng các cuộc tấn công xuyên trang (từ 4% đến 54%) và tấn công tiêm SQL (SQLi) (từ 15% đến 76%) đang gia tăng.
Chúng ta có thể đi đến kết luận từ những số liệu thống kê này rằng cần có một số biện pháp nghiêm ngặt để bảo vệ các ứng dụng web khỏi các lỗ hổng. Một số lỗi bảo mật xảy ra do các vấn đề trong mã hóa, trong khi các lý do khác có thể là do cơ sở hạ tầng không đầy đủ mà ứng dụng web sử dụng. Đây là lúc Tường lửa ứng dụng web (WAF) xuất hiện, có thể giảm thiểu các lỗ hổng bằng cách lọc các gói tin, chặn lưu lượng HTTP và ghi nhật ký trái phép.
Chúng ta sẽ khám phá sâu hơn bên dưới. Trước đó, chúng ta sẽ xem qua tổng quan ngắn gọn về các mối đe dọa an ninh quan trọng.
SQLi - SQL injection là một lỗ hổng bảo mật web cho phép kẻ tấn công thao túng các truy vấn SQL mà ứng dụng thực hiện với cơ sở dữ liệu. Bằng cách đó, chúng có thể truy cập vào thông tin có giá trị tiềm ẩn mà không ai có thể dễ dàng tiếp cận.
Một ví dụ đơn giản và quen thuộc nhất là lợi dụng dữ liệu đầu vào chưa được khử trùng của người dùng để tạo lợi thế cho tin tặc. Giả sử có một hộp văn bản yêu cầu ID người dùng. Sau đó, dựa trên ID người dùng, truy vấn sẽ lấy tất cả thông tin thuộc về người dùng đó.
Vì vậy, giả sử trong hộp văn bản nếu người dùng đã nhập thông tin sau:
ID người dùng: 228 hoặc 1=1
Khi đó truy vấn kết quả sẽ như sau:
CHỌN * TỪ Người dùng NƠI UserId = 228 HOẶC 1=1;
Sau đó, nó sẽ lấy toàn bộ dữ liệu trong bảng của người dùng, bao gồm cả mật khẩu nếu bảng chứa dữ liệu mật khẩu.
Để biết thêm thông tin về SQLi, bạn có thể tham khảo tại đây .
XSS xảy ra khi người dùng chèn một tập lệnh độc hại chủ yếu vào javascript thông qua các trường nhập liệu chưa được khử trùng. Thông thường, kẻ tấn công sẽ gửi tập lệnh độc hại này đến người dùng mà người dùng này sẽ không bị nghi ngờ. Trình duyệt của người dùng cuối không biết rằng tập lệnh này có hại và sẽ thực thi tập lệnh.
Kết quả là, tập lệnh độc hại này có thể truy cập tất cả dữ liệu liên quan đến cookie, mã thông báo phiên hoặc bất kỳ thông tin nhạy cảm nào khác. Hơn nữa, các tập lệnh này có thể viết lại HTML của trang web.
Giả sử người dùng phải đăng nhập vào ứng dụng web bằng thông tin đăng nhập. Trong trường hợp đó, thuật toán độc quyền của trang web sẽ tạo ID phiên duy nhất cho toàn bộ giao tiếp giữa người dùng và máy chủ web cho phiên đó.
Nếu các nhà phát triển web không mã hóa dữ liệu an toàn truyền qua lại giữa người dùng và máy chủ web, thì khả năng cao là kẻ xâm nhập sẽ đánh cắp dữ liệu đó và đóng vai trò là người dùng. Tình huống này chủ yếu xảy ra khi bạn đăng nhập vào internet bằng WiFi công cộng tại các quán cà phê.
Bạn có thể tham khảo bài viết này để biết thêm chi tiết.
WAF là lớp bảo vệ lớp 7 trong mô hình OSI có thể được đặt tại điểm vào máy chủ đích, như thể hiện trong sơ đồ bên dưới. Nó bảo vệ mạng nội bộ của máy chủ khỏi các cuộc tấn công và ẩn cấu trúc mạng của máy chủ.
Để WAF hoạt động, bạn nên tạo các cấu hình bổ sung trong máy chủ. Giống như tường lửa, WAF lọc lưu lượng HTTP đến và đi có vẻ nguy hiểm đối với mạng nội bộ của máy chủ nếu chúng không đáp ứng các quy tắc mà bạn đặt trên WAF.
WAF cũng là một loại proxy ngược mà chúng ta sẽ thảo luận ở phần tiếp theo.
Nhiệm vụ của máy chủ proxy là ẩn địa chỉ IP của bạn và thay thế bằng địa chỉ IP của máy chủ proxy. Vâng, proxy ngược cũng làm như vậy và tăng cường bảo mật của máy chủ web bằng cách ẩn nó cũng như cấu trúc mạng nội bộ của máy chủ.
Máy khách chỉ biết địa chỉ của máy chủ proxy và do đó máy chủ thực sự bị ẩn khỏi máy khách.
Lý tưởng nhất là bạn có thể sử dụng proxy ngược làm Tường lửa ứng dụng web (WAF) mà chúng tôi đã thảo luận ở trên. Bạn có thể triển khai WAF trên các ứng dụng web trên các thiết bị có proxy ngược được cấu hình. Do đó, phạm vi của WAF trong việc tăng cường bảo mật trở nên rộng hơn. Kẻ tấn công cũng không thể thấy vị trí thực tế của máy chủ web.
Bạn có thể tham khảo bài viết này để biết thêm thông tin cơ bản về proxy ngược. Trong phần tiếp theo, chúng ta sẽ xem xét việc sử dụng proxy ngược để giảm thiểu rủi ro ứng dụng. Tuy nhiên, trước đó, chúng tôi sẽ cung cấp cho bạn tổng quan về những gì proxy ngược thực hiện.
Tất cả các proxy ngược đều thực hiện tất cả các hoạt động cơ bản sau:
Vì mục tiêu của chúng ta là khắc phục các cuộc tấn công mạng đã đề cập trước đó nên proxy ngược cần thực hiện các chức năng bổ sung bên cạnh các bước đã đề cập ở trên.
Khi một máy khách gửi yêu cầu đến máy chủ, proxy ngược sẽ khử trùng đầu vào bằng cách so sánh với cơ sở dữ liệu chữ ký của nó. Các lập trình viên phát triển các chữ ký này bằng các biểu thức chính quy tiên tiến. Quyết định cho phép yêu cầu với đầu vào của người dùng của proxy ngược sẽ chỉ dựa trên phương pháp lọc danh sách chặn và lọc danh sách trắng.
Bộ lọc danh sách đen lưu trữ các yêu cầu có hại đã biết. Sau đó, nó so sánh từng yêu cầu với các mục trong danh sách. Nếu phát hiện ra sự trùng khớp, nó sẽ từ chối yêu cầu. Các biến thể khác nhau của cùng một cuộc tấn công phải được ghi lại riêng trong danh sách. Bạn sẽ có thể ngăn chặn chỉ các cuộc tấn công đã biết bằng cách sử dụng danh sách đen. Tính toàn diện của danh sách đen giúp tăng hiệu quả của nó.
Bộ lọc danh sách trắng sẽ thu thập toàn bộ tập hợp các yêu cầu hợp lệ cho một trang web cụ thể. Do đó, danh sách trắng ngăn chặn các cuộc tấn công bằng cách chỉ cho phép các yêu cầu đã biết đến máy chủ. Mặt khác, quá trình xây dựng danh sách trắng tốn nhiều thời gian và đòi hỏi phải biết về toàn bộ phạm vi các yêu cầu hợp lệ mà người dùng có thể gửi đến máy chủ.
Hơn nữa, việc tạo tất cả các yêu cầu hợp lệ tới hàng trăm nghìn nhà cung cấp cơ sở dữ liệu ngoài kia trong trường hợp bị tấn công SQL có thể trở nên quá sức.
Bất kỳ sửa đổi nào đối với ứng dụng web được bảo mật đều cần phải cập nhật danh sách trắng. Do đó, việc duy trì danh sách trắng sẽ làm tăng gánh nặng hành chính.
Trước khi gửi phản hồi từ máy chủ trở lại máy khách, proxy ngược sẽ xác thực phản hồi đó. Một danh sách đen thường được sử dụng để thực hiện việc này. Bộ lọc danh sách đen có thể ẩn các phản hồi đã biết khỏi máy khách không cần xem chúng. Thông báo lỗi là một ví dụ về loại dữ liệu này; proxy ngược có thể thay thế lỗi bằng thông báo lỗi chung không chứa dữ liệu nhạy cảm.
Proxy ngược cũng có thể ghi lại yêu cầu để kiểm tra sau. Cách tiếp cận tốt nhất là cấu hình ghi nhật ký chỉ cho các yêu cầu mà proxy ngược đã chặn ban đầu. Bạn nên kiểm tra cẩn thận các bản ghi trong suốt các giai đoạn đầu tiên của quá trình cài đặt. Điều này rất cần thiết để xác minh rằng proxy ngược không chặn bất kỳ yêu cầu chính hãng nào.
Trong bài viết này, chúng tôi hy vọng bạn hiểu được các lỗ hổng trong ứng dụng web và cách bạn có thể sử dụng proxy ngược để giải quyết các mối đe dọa này. Thật vậy, proxy ngược sẽ không loại bỏ tất cả các lỗ hổng có thể liên quan đến ứng dụng web.
Tuy nhiên, đây sẽ là một chiến lược tuyệt vời để giảm thiểu hầu hết các mối đe dọa mà bạn gặp phải trong ứng dụng web. Vì vậy, cuối cùng, chúng tôi hy vọng bạn sẽ áp dụng các khái niệm đã học trong bài viết này nếu bạn gặp phải các vấn đề về bảo mật trong ứng dụng web của mình.