Bài viết được sự cho phép của tác giả Võ Doãn Thành
1. Cuộc trò truyện với ông anh
Nói về security thì có vô vàng các vấn đề mà có thể gặp phải trong quá trình phát triển ứng dụng hoặc xây dựng cơ sở hạ tầng.
Ứng dụng của bạn càng có nhiều lớp bảo vệ thì “có thể” việc giúp an toàn thông tin cho người dùng càng cao và tăng độ tin cậy của người dùng với ứng dụng.
Mình nói “có thể” tức việc hiểu và tận dùng các lớp bảo mật chỉ giúp ứng dụng có thêm nhiều lớp chắn không có nghĩa là an toàn được 100%.
Vì giờ các pháp sư hacker rất là chuyên nghiệp.
Hổm mình có nói chuyện với ông anh làm chung. Ảnh thì chuyên làm về security. Ảnh kể cho mình nghe 1 tràng ý như thế này.
- Mục đích việc hiểu về security (cả về lý thuyết và phướng án phòng chống) không phải là để em có thể chống lại các cuộc tấn công (attacks) mà là giúp em phát hiện ra mình có đang bị tấn công hay không.
- Càng nhiều lớp bảo vệ giống như em có nhiều bức tường thành để bảo vệ cung điện. Nhưng vấn đề nếu 1 trong các bức tường của em mà chỉ cần có khe nức mà em không phát hiện thì rất dễ bị kẻ địch họ thổi khí độc vào và hạ bệ các binh lính và không cần đập phá thành làm gì.
- Hacker giờ xịn xò lắm. Họ sẽ không cần phải đánh sập server của em hoặc chiếm quyền kiểm soát gì cả. Đơn giản là họ tới và lấy những thức cần thôi. Ví dụ 10% doanh thu mỗi tháng của ứng dụng.
Bạn có cảm thấy rùng mình khi nghe câu chuyện trên không? Có khi ứng dụng đang bị hack mà do chẳng có chuyện gì xảy ra nên chúng ta cứ cho mình đang an toàn.
Có rất nhiều bài học về security nhưng mình nghĩ 4 vấn đề dưới đây khá là phổ biến mà ít được chú ý. Security thì cần cho tất cả mọi người kể cả developers nữa nha.
2. SQL Injection (SQLi)
Vấn đề và cách hoạt động:
SQLi là một loại tấn công mạng khai thác lỗ hổng trong cách một ứng dụng web tương tác với database.
Kẻ tấn công có thể chèn mã SQL độc hại vào các nơi như form đăng nhập, thanh search hoặc bất kỳ trường nào chấp nhận dữ liệu từ người dùng.
Mã chèn này sẽ lừa database của ứng dụng thực thi các hành động không mong muốn, có thể dẫn đến sự xâm nhập.
Vấn đề này thường xảy ra khi chúng ta query thẳng trực tiếp data của người dùng vào database.
Ví dụ:
Với form đăng nhập thì ta cần thông tin như username và password để xác minh danh tính người dùng.
Với user bình thường sẽ là
SELECT * FROM users WHERE username='abc123' AND password='anything';
Còn đối với hacker sẽ gửi username là “admin’–“
SELECT * FROM users WHERE username='admin'--' AND password='anything';
Lúc này câu SQL bên trên nó chỉ thực hiện tới “SELECT * FROM users WHERE username=’admin'” vì từ khúc “–” nó hiểu là đang comment.
Rất dễ dàng bị chiếm user admin hoặc thay đổi dữ liệu không mong muốn.
Giải pháp:
Parameterized Queries: Sử dụng các truy vấn có tham số để tách biệt đầu vào của người dùng khỏi câu lệnh SQL.
Input Validation: Xác thực tất cả đầu vào của người dùng để đảm bảo chúng khớp với định dạng mong đợi và không chứa các ký tự độc hại.
Giờ đa số chúng ta đều dùng ORM thì các vấn đề này có thể giảm thiểu. Chỉ trường hợp mình dùng thẳng raw query thôi.
// Prepare the SQL statement with placeholders for username and password PREPARED_STATEMENT = "SELECT * FROM users WHERE username = ? AND password = ?"; // Bind user input to the prepared statement parameters username_param = username password_param = password // Execute the prepared statement with the bound parameters results = database_connection.execute(PREPARED_STATEMENT, username_param, password_param)
3. Cross-Site Scripting (XSS)
Vấn đề và cách hoạt động:
XSS là một lỗ hổng bảo mật web cho phép kẻ tấn công chèn các đoạn mã độc hại vào các trang web đáng tin cậy.
Các đoạn mã này sau đó được thực thi trong trình duyệt web của nạn nhân khi họ truy cập vào trang web bị lỗ hổng.
Kẻ tấn công có thể sử dụng XSS để đánh cắp thông tin nhạy cảm, chuyển hướng người dùng đến các trang web độc hại hoặc làm gián đoạn chức năng của trang web.
Ví dụ:
Ví dụ kinh điển mà chúng ta có thể thấy đó là việc comment trên các forum. Hacker sẽ comment 1 nội dung gì đó mà không phải là text.
Nó là 1 đoạn mã javascript để đọc các nội dung cookies xong sau đó gửi sang 1 web khác.
Hacker sẽ đánh cắp các thông tin của người dùng. Vì khi người dùng load comments tiếp theo vô tình load lên đoạn comment chứ đoạn script của hacker.
Giải pháp:
Input Validation and Sanitization: Xác thực tất cả dữ liệu đầu vào từ người dùng để đảm bảo nó phù hợp với các định dạng mong đợi và loại bỏ bất kỳ ký tự độc hại tiềm ẩn nào. Bạn cũng có thể làm sạch dữ liệu đầu vào bằng cách chuyển đổi các ký tự đặc biệt thành các dạng vô hại (ví dụ: < trở thành <).
Output Encoding: Trước khi hiển thị dữ liệu đầu vào của người dùng trên trang web, hãy mã hóa nó một cách thích hợp để ngăn nó bị diễn giải như mã. Điều này bao gồm việc chuyển đổi các ký tự đặc biệt thành các thực thể HTML hiển thị dưới dạng văn bản, không thực thi như mã.
Content Security Policy (CSP): Triển khai CSP định nghĩa các nguồn cho phép cho các đoạn mã và tài nguyên khác. Điều này hạn chế trình duyệt thực thi bất kỳ đoạn mã nào không đến từ các nguồn được phê duyệt.
4. Denial-of-Service (DoS) Attack
Vấn đề và cách hoạt động:
DoS attack nhằm mục đích làm gián đoạn hoạt động bình thường của một trang web, máy chủ hoặc mạng bằng cách áp đảo nó với một lượng lớn lưu lượng truy cập.
Lưu lượng truy cập quá mức này ngăn cản người dùng hợp pháp truy cập vào tài nguyên bị tấn công.
Các cuộc tấn công DoS thường được sử dụng để tống tiền hoặc đơn giản là gây rối loạn và hỗn loạn.
Ví dụ:
Với vấn đề này thì dễ dàng hình dung nhất. Đó là bạn có 1 website nhưng hacker không muốn nó hoạt động bình thường hoặc công ty đối thủ không muốn khách hàng có thể mua hàng từ công ty của bạn.
Hacker sẽ tạo các script để gọi tạo ra các requests liên tục tới các server mà website bạn đang có. Lúc sẽ các server sẽ trì trệ hoặc tệ có thể down. Do phải handle 1 lượng requests lớn từ hacker.
Trải nghiệm người dùng sẽ tệ đi và có thể ảnh hưởng lớn tới doanh thu.
Giải pháp:
Traffic Filtering: Triển khai các tường lửa và giải pháp bảo mật mạng để lọc lưu lượng đáng ngờ và chặn các mẫu tấn công đã biết.
Rate Limiting: Hạn chế số lượng yêu cầu mà một địa chỉ IP đơn lẻ có thể gửi trong một khung thời gian cụ thể. Điều này có thể giúp ngăn chặn một nguồn duy nhất làm quá tải hệ thống.
Resource Scaling: Cân nhắc mở rộng hạ tầng (ví dụ: sử dụng các dịch vụ dựa trên cloud) để xử lý các đột biến lưu lượng không mong đợi.
DDoS Protection Services: Nhiều nhà cung cấp dịch vụ bảo mật cung cấp các dịch vụ bảo vệ DDoS giúp nhận diện và giảm thiểu các cuộc tấn công DDoS. (Mình dùng Cloudflare nha.)
Incident Response Plan: Có sẵn một kế hoạch để phản ứng hiệu quả với các cuộc tấn công DoS, bao gồm xác định nguồn tấn công, giảm thiểu tác động và khôi phục hoạt động bình thường.
Xem thêm các việc làm ASP.NET Core trên TopDev
5. Cross-Site Request Forgery (CSRF)
Vấn đề và cách hoạt động:
CSRF, còn được gọi là XSRF hoặc Sea Surf, là một lỗ hổng bảo mật web cho phép kẻ tấn công lừa trình duyệt của người dùng đã xác thực thực hiện các hành động trái phép trên một trang web đáng tin cậy.
Kẻ tấn công lợi dụng phiên làm việc đáng tin cậy của người dùng với trang web để thực hiện các hành động thay mặt cho nạn nhân.
Ví dụ:
Gần đây chúng ta được cảnh báo khá là nhiều về việc giả mạo các trang web của ngân hàng. Hacker sẽ gửi 1 tin nhắn nhìn thì rất giống như nội dung được gửi từ ngân hàng thiệt.
Sau khi nạn nhân click vào link giả mạo thì giao diện và cách thức rất là giống như trang web thật. Sau đó nạn nhân đăng nhập ở trang giả mạo thì hacker đã có đầy đủ thông tin username và password của nạn nhân.
Sau đó hacker có thể vào trang web thiệt của ngân hàng để làm các hành động như đánh cắp tiền.
Giải pháp:
Token CSRF: Tạo các token duy nhất cho mỗi form trên trang web và nhúng chúng dưới dạng các trường ẩn. Server sẽ xác thực các token này trước khi xử lý các form gửi đi. Điều này đảm bảo rằng chỉ có các form hợp lệ do người dùng gửi mới được xử lý, ngay cả khi kẻ tấn công lừa người dùng nhấp vào liên kết độc hại.
Double Submit Cookies: Áp dụng cookie với các biện pháp bảo mật bổ sung như cờ HttpOnly và thuộc tính SameSite. Những tính năng này có thể giúp ngăn cookie bị gửi trong các yêu cầu cross-site do kẻ tấn công khởi xướng.
User Education: Giúp người dùng hiểu về các rủi ro khi nhấp vào các liên kết đáng ngờ hoặc truy cập các trang web không đáng tin cậy.
6. Kết luận
Giờ chúng ta hiểu được tầm quan trọng của việc hiểu về security. Nó giúp chúng ta tránh được những rủi ro như mất cắp dữ liệu, chiếm quyền kiểm soát hoặc tệ nhất là mất tiền.
Bất cứ ai từ developers tới người dùng để phải nhận thức rõ về việc tự bảo vệ bản thân trước những tấn công mạng.
Hãy cập nhật thêm những kiến thức về an ninh mạng sẽ giúp bạn tránh những mất mát không mong muốn.
7. Câu hỏi mở rộng
Thường thì mình thấy các websites đa số sẽ lưu token vào localStorage để tiện cho mục đích sử dụng.
Vậy rủi ro khi dùng localStorage có hay không? Nếu là bạn thì bạn có dùng localStorage không hay dùng phương pháp nào giúp bảo vệ token cho người dùng?
Bài viết gốc được đăng tải tại LinkedIn Thanh Vo
Xem thêm:
