Các cách phòng tránh Bug nguy hiểm

Bug nguy hiểm là gì ?

Bug rất phổ biến trong mọi phần mềm. Gần như bất cứ phần mềm nào cũng có bug ngay cả khi chúng ta phát triển phần mềm một cách cực kỳ tỉ mỉ thì nó vẫn sẽ có một số lỗi. Trong đa số trường hợp những lỗi này thường rất nhỏ và chỉ làm chúng ta đôi chút khó chịu. Nhưng đôi khi có những lỗi có thể gây ra thảm họa gây thiệt hại hàng tỷ đô la, đẩy công ty chủ quản vào tình trạng khó khăn, khiến lập trình viên vướng vào vòng lao ly. Vậy nên những con Bug đó không đơn thuần là Bug nguy hiểm mà nó là những con Bug cực kỳ nguy hiểm 

1, SQL Injection

Chúng ta không phải nói gì nhiều về cái lỗi thần thánh này,Lỗ hổng này rất nổi tiếng, từ developer đến hacker gần như ai cũng biết. Ngoài ra, còn có 1 số tool tấn công SQL Injection cho dân “ngoại đạo”, những người không biết gì về lập trình. Hay là việc Rất nhiều ông lớn từng bị dính – Sony, Microsoft UK. Mọi vụ lùm xùm liên quan tới “lộ dữ liệu người dùng” ít nhiều đều dính dáng tới SQL Injection.

Từ các lý do dễ tấn công, phổ biến, gây ra hậu quả nghiêm trọng, đó là lý do Inject nằm chễm chệ ở vị trí đầu bảng trong top 10 lỗ hổng bảo mật của OWASP

– Lỗi xảy ra như thế nào

Câu query bạn mong muốn sẽ là

$sql = “select * from users where username='”.$_POST[‘username’].”‘ and password='”.$_POST[‘password’].”‘”; //

Còn gì tuyệt vời hơn nếu người dùng nhập, ví dụ username là depzai1102, mật khẩu là matkhauManhVL 😀 

Nhưng có một vấn đề là nhiều thanh niên trẻ trâu đầu lâu không thích thế mà họ nhập username là depzai1102’ or 1– – và mật khẩu là nhập linh ta linh tinh đi kadslfjladsjfkldsfjladskfjaskldfjadsklf

Khi đó query mà bạn đang chờ sẽ là

$sql = “select * from users where username=’depzai1102’ or 1 limit 1– – and password=’kadslfjladsjfkldsfjladskfjaskldfjadsklf’

Câu query luôn đúng bởi — – là dùng để kết thúc 1 câu query, như // trong php đó

Và lúc này thì hệ thống của các bạn đã bị tụi trẻ trâu chiếm đóng một cách vi diệu =)))

– Sự nguy hiểm

user chạy ở đây là user connect tới database server (không phải user của web server)

• Thứ nhất là có thể truy xuất gần như là toàn bộ thông tin về cơ sở dữ liệu đang thao tác và có thể các database (do grant quyền)
• Thứ hai là có thể query insert, update, drop đến database hiện tại ví dụ có thanh niên chạy drop database database_name thì thôi xong (cái này phụ thuộc nhiều yếu tố mới thành công)
• Thứ 3 là có thể upload backdoor (cụ thể là php shell), phải phụ thuộc khá nhiều điều kiện user chạy là root (hoặc user có quyền với file), biết được cấu trúc website đang chạy (ví dụ biết được /var/www/domain.com), cái này mà được thì rất nguy hiểm

Cách phòng tránh: 

• Lọc dữ liệu từ người dùng: Cách phòng chống này tương tự như XSS. Ta sử dụng filter để lọc các kí tự đặc biệt (; ” ‘) hoặc các từ khoá (SELECT, UNION) do người dùng nhập vào. Nên sử dụng thư viện/function được cung cấp bởi framework. Viết lại từ đầu vừa tốn thời gian vừa dễ sơ sót.
• Không cộng chuỗi để tạo SQL: Sử dụng parameter thay vì cộng chuỗi. Nếu dữ liệu truyền vào không hợp pháp, SQL Engine sẽ tự động báo lỗi, ta không cần dùng code để check.
• Không hiển thị exception, message lỗi: Hacker dựa vào message lỗi để tìm ra cấu trúc database. Khi có lỗi, ta chỉ hiện thông báo lỗi chứ đừng hiển thị đầy đủ thông tin về lỗi, tránh hacker lợi dụng.
• Phân quyền rõ ràng trong DB: Nếu chỉ truy cập dữ liệu từ một số bảng, hãy tạo một account trong DB, gán quyền truy cập cho account đó chứ đừng dùng account root hay sa. Lúc này, dù hacker có inject được sql cũng không thể đọc dữ liệu từ các bảng chính, sửa hay xoá dữ liệu.
• Backup dữ liệu thường xuyên: Dữ liệu phải thường xuyên được backup để nếu có bị hacker xoá thì ta vẫn có thể khôi phục được.

2, XSS

XSS (Cross Site Scripting) là một lỗi bảo mật cho phép hacker nhúng mã độc (javascript) vào một trang web khác. Hacker có thể lợi dụng mã độc này để deface trang web, cài keylog, chiếm quyền điều khiển của người dùng, dụ dỗ người dùng tải virus về máy. 

Đây là một trong những lỗi bảo mật thường gặp nhất trên các trang Web. Các hệ thống từ lớn đến nhỏ như Facebook, Twitter, một số forum Việt Nam, … đều từng dính phải lỗi này. Do mức độ phổ biến và độ nguy hiểm của nó, XSS luôn được vinh dự được nằm trong top 10 lỗi bảo mật nghiêm trọng nhất trên OWASP (Open Web Application Security Project).

XSS gồm 3 loại tấn công sau

1.Reflected XSS

Có nhiều hướng để khai thác thông qua lỗi Reflected XSS, một trong những cách được biết đến nhiều nhất là chiếm phiên làm việc (session) của người dùng, từ đó có thể truy cập được dữ liệu và chiếm được quyền của họ trên website.

2.Stored XSS

Khác với Reflected tấn công trực tiếp vào một số nạn nhân mà hacker nhắm đến, Stored XSS hướng đến nhiều nạn nhân hơn. Lỗi này xảy ra khi ứng dụng web không kiểm tra kỹ các dữ liệu đầu vào trước khi lưu vào cơ sở dữ liệu.

3.DOM Based XSS

DOM Based XSS là kỹ thuật khai thác XSS dựa trên việc thay đổi cấu trúc DOM của tài liệu, cụ thể là HTML.

Các cách phòng tránh:

• Encoding Không được tin tưởng bất kỳ thứ gì người dùng nhập vào!! Hãy sử dụng hàm encode có sẵn trong ngôn ngữ/framework để chuyển các ký tự < > thành &lt; %gt;.
• Validation/Sanitize Một cách chống XSS khác là validation: loại bỏ hoàn toàn các kí tự khả nghi trong input của người dùng, hoặc thông báo lỗi nếu trong input có các kí tự này.Ngoài ra, nếu muốn cho phép người dùng nhập vào HTML, hãy sử dụng các thư viện sanitize. Các thư viện này sẽ lọc các thẻ HTML, CSS, JS nguy hiểm để chống XSS.
• CSP (Content Security Policy) Để sử dụng CSP, server chỉ cần thêm header Content-Security-Policy vào mỗi response. Nội dung header chứa những  domain mà ta tin tưởng.

3, Degrade Bug (Regression bug)

Không phải nói nhiều về cái lỗi thần thánh này, gần như Dev mới 96.69 đều mắc phải nó -_- thậm chí các Dev có kinh nghiệm cũng có thể mắc

Lỗi xảy ra khi phát triển một chức năng mới hoặc fix bug chức năng cũ nhưng lại phát sinh lỗi ở một chức năng khác liên quan

Ví dụ: phát triển chức năng Edit User nhưng lại gây ra lỗi cho phần Add User đã phát triển xong trước đó

Cách phòng tránh:

• Mỗi khi fix bug hoặc làm các feature mới thì cần note lại mức độ ảnh hưởng của task đó tới các chức năng cũ 
• Sau khi làm xong thì sẽ test lại toàn bộ các chức năng cũ bị ảnh hưởng mà đã note trước đó. 
• Tester khi test cần đọc note và test lại theo những note của dev hoặc nếu phát hiện Task đó có ảnh hưởng tới những chức năng khác mà nằm ngoài Note thì cần báo với dev để kịp thời xử lý

Trên đây là 3 loại Bug nguy hiểm mà tôi muốn chia sẻ tới các bạn. Trong mỗi loại bug đều có những ví dụ thực tế để mọi người dễ hình dung. Mong mọi người góp ý để mình fix lại. Văn vẻ có phần lủng củng mong mọi người thông cảm ạ 😀