daipt
Well-known member
Bất cứ khi nào bạn xây dựng một hệ thống xong xui và hệ thống đang chạy ngon lành đều bị phá hoại vào ngày đẹp trời nào đó.!? Vì lý do bla, bla,… gì đó họ sẵn sàng dùng mọi cách phá hoại dự án kỳ công của bạn chính vì thế xây dựng code an toàn từ lúc xuất xưởng là cần thiết, hãy áp dụng thói quen này để đảm bảo rằng các ứng dụng của bạn là an toàn mức cao nhất có thể nhé.
Đây là quy tắc cơ bản trong lập trình và nó cũng có 4 bước cơ bản, bạn làm theo thì chắc chắn sẽ K.O.
Bảo vệ post form (validate trong file xử lý)
– Attacker có thể dễ dàng fake 1 post form của bạn ở đâu đó rồi gửi vào file PHP xử lý của bạn vì mục đích nào đó. Do các ứng dụng web là phi trạng thái (stateless), nên không có cách nào để chắc chắn tuyệt đối là dữ liệu đã được gửi lên từ nơi mà bạn muốn nó đến từ đó. Mọi thứ từ các địa chỉ IP cho đến tên máy chủ, cuối cùng rồi đều có thể bị fake.
– Tuy nhiên một kỹ thuật mà bạn có thể sử dụng là thẻ bài sử dụng một lần (single-use token), nó không làm cho việc fake post form của bạn bất khả thi nhưng nó trở thành một điều rắc rối kinh khủng cho người fake.!? Vì token thay đổi mỗi khi mẫu được đưa xuống client, attacker cần phải lấy một form đang gửi, lấy token, và đặt nó vào phiên bản post fake đó. Kỹ thuật này rất hại não vì khó có khả năng một ai đó lập ra một fake post form lâu dài để gửi các yêu cầu không mong muốn đến ứng dụng của bạn.
Bảo vệ hệ thống file (ghi logs khi phát sinh tải file mà mình giới hạn)
– Vấn đề đặt ra là có những file quan trọng mà bạn không muốn bất kỳ ai cũng có quyền lấy xuống mà giới hạn lấy xuống. Chính vì vậy tốt nhất là thiết kế ứng dụng sử dụng một cơ sở dữ liệu và các tên file được tạo ra và giấu kín. Tuy nhiên, không phải lúc nào cũng có thể làm thế.
Ví dụ về một thủ tục kiểm tra hợp lệ tên tệp tin. Nó sử dụng các biểu thức chính quy để đảm bảo rằng chỉ các ký tự hợp lệ là được sử dụng trong tên tệp tin và đặc biệt kiểm tra các ký tự chấm chấm: ...
Bảo vệ cơ sở dữ liệu (Chống lại sự tấn công SQL INJECTION)
– Vấn đề đặt ra là attacker có thể vượt qua rào validate trong front end hoặc fake post form thành công và truyền dc những giá trị không mong muốn vào file PHP để xử lý nếu ta không chặn dc những giá trị này thì 0.O sẽ có những câu lệnh SQL ko chính quy thâm nhập vào những câu SQL chính quy của bạn phá hỏng database của bạn tồi tệ hơn là tạo ra những người dùng siêu quyền hạn để đánh cắp thông tin, bla bla….
– Chúng ta có thể khắc phục dc việc này bằng nhiều cách đơn giản như
– Vấn đề đặt ra là chúng ta 1 hệ thống có nhiều server khác nhau để duy trì 1 hệ thống site vậy làm sao để đảm bảo được các session trong giao dịch dùng để xử lý, có thể hoạt động trên các server khác trong cùng hệ thống.!?
Để làm được điều này chúng ta cần xử lý sao cho tất cả các máy chủ đều sử dụng chung một hệ thống quản lý session .
Hoặc đơn giản là sử dụng chung một session storage .
Mặc định trong php sẽ sử dụng file session handle các file chứa session sẽ nằm trong /tmp của mỗi server .
Điều này có thể gợi ý cho chúng ta việc share chung 1 vùng lưu trữ (ví dụ dùng NFS để share chung /tmp giữa các máy chủ).
Tuy nhiên cách này lại ảnh hưởng đến tốc độ truy xuất (vì phải qua mạng – sau đó là đến việc máy host session sẽ quá tải diskio).
Một hướng khác là sử dụng một db mysql chung để lưu session , thực tế thì cách này tạm được .
Để làm như vậy chúng ta cần override lại các hàm xử lý session của php
session_set_save_handler("open", "close", "read", "write", "destroy", "gc");
Sử dụng hàm session_set_save_handler để trỏ các call back function cần thiết , như vậy chúng ta cần viết lại 6 hàm open, close , read ,write ,destroy , gc .
Chạy thử . kết quả : openread writeclose …
Như vậy chúng ta thấy thứ tự của một quá trình đọc session .
Việc tiếp theo là implement mấy hàm trên vào mysql , memcached , file , hay bất kỳ một storage nào có thể dùng chung được là xong .
với file (cái này chỉ là làm lại những gì php đã làm )
Dùng memcache hay mysql cũng khá nhanh , mysql thì chạy bàng memory storage engine , bật query cache tướng đối lớn cho nhanh , có thể replication ra nhiều server để đẩy performed lên cao nữa nếu tải lớn .
Bảo vệ chống lại các sơ hở của ứng dụng lệnh xuyên các trang (Cross-Site Scripting – XSS)
– Vấn đề đặt ra là người dùng sẽ nhập nội dung và hệ thống của bạn sẽ hiển thị nội dung đó lên. Nếu nội dung người dùng nhập là script có chứa mã độc phát tán virus,… thì sao.!?
– Để tự bảo vệ bạn chống lại các tấn công XSS, hãy lọc đầu vào của bạn thông qua hàm htmlentities() bất cứ khi nào giá trị của một biến được in đến đầu ra. Hãy nhớ làm theo thói quen đầu tiên về kiểm tra hợp lệ dữ liệu đầu vào bằng các giá trị trong danh sách trắng trong ứng dụng web của bạn đối với tên, địa chỉ email, số điện thoại, và thông tin về hoá đơn thanh toán.
Bảo vệ chống lại các giả mạo yêu cầu xuyên các trang (Cross-Site Request Forgeries – CSRF)
– Một vấn đề là chúng ta phải thật cẩn trọng với người dùng đã là member chính thức vì lúc đó họ đã có dc quyền hạng trong site và họ có thể upload, post,… thoải mái nếu họ lợi dụng quyền này để tấn công bằng cách upload file image nhưng đó thực sự không phải là file image thì sao.!?
Các cuộc tấn công CSRF thường được thực hiện dưới dạng các thẻ <img> vì trình duyệt gọi URL một cách không ý thức để lấy hình ảnh. Tuy nhiên, nguồn hình ảnh dễ dàng có thể chỉ là URL của một trang web trên cùng một site, thực hiện các việc xử lý nào đó dựa trên các tham số chuyển cho nó. Khi thẻ <img> này được đặt trong một cuộc tấn công XSS — cũng là các tấn công phổ biến nhất được ghi chép lại — người sử dụng dễ dàng có thể làm một việc gì đó với quyền ưu tiên được cấp mà không biết mình đã làm — như vậy, có thể giả mạo.
– Lúc đó ngoài việc áp dụng các cách bảo vệ bên trên trước XSS thì chúng ta cần xác minh các form gửi lên chặc hợn. Ngoài ra, sử dụng biến hiển $_POST thay vì $_REQUEST và kiểm tra kỹ lưỡng các file được up lên nếu là hình ảnh ngoài kiểm tra file_upload,… thì cần kiểm tra size ảnh để chắc chắn đó là một hình ảnh thông qua hàm getimagesize() trong php.
- Kiểm tra hợp lệ đầu vào (validate ngoài form)
- Bảo vệ post form (validate trong file xử lý)
- Bảo vệ hệ thống file (ghi logs khi phát sinh tải file mà mình giới hạn)
- Bảo vệ cơ sở dữ liệu (Chống lại sự tấn công SQL INJECTION)
- Bảo vệ dữ liệu phiên làm việc (đảm bảo hệ thống luôn chạy tốt)
- Bảo vệ chống lại các sơ hở của ứng dụng lệnh xuyên các trang (Cross-Site Scripting – XSS)
- Bảo vệ chống lại các giả mạo yêu cầu xuyên các trang (Cross-Site Request Forgeries – CSRF)
Đây là quy tắc cơ bản trong lập trình và nó cũng có 4 bước cơ bản, bạn làm theo thì chắc chắn sẽ K.O.
- Lập ra danh sách hợp lệ(while list) vs bất hợp lệ (black list)
- Luôn luôn kiểm tra hợp lệ trong black list.
- Kiểm tra kiểu dữ liệu đúng. ví dụ như là các số, chuỗi,…
- Trong quá trình xử lý danh sách bất hợp lệ cần dùng hàm thoát để giảm tải quá trình xử lý.
Bảo vệ post form (validate trong file xử lý)
– Attacker có thể dễ dàng fake 1 post form của bạn ở đâu đó rồi gửi vào file PHP xử lý của bạn vì mục đích nào đó. Do các ứng dụng web là phi trạng thái (stateless), nên không có cách nào để chắc chắn tuyệt đối là dữ liệu đã được gửi lên từ nơi mà bạn muốn nó đến từ đó. Mọi thứ từ các địa chỉ IP cho đến tên máy chủ, cuối cùng rồi đều có thể bị fake.
– Tuy nhiên một kỹ thuật mà bạn có thể sử dụng là thẻ bài sử dụng một lần (single-use token), nó không làm cho việc fake post form của bạn bất khả thi nhưng nó trở thành một điều rắc rối kinh khủng cho người fake.!? Vì token thay đổi mỗi khi mẫu được đưa xuống client, attacker cần phải lấy một form đang gửi, lấy token, và đặt nó vào phiên bản post fake đó. Kỹ thuật này rất hại não vì khó có khả năng một ai đó lập ra một fake post form lâu dài để gửi các yêu cầu không mong muốn đến ứng dụng của bạn.
Bảo vệ hệ thống file (ghi logs khi phát sinh tải file mà mình giới hạn)
– Vấn đề đặt ra là có những file quan trọng mà bạn không muốn bất kỳ ai cũng có quyền lấy xuống mà giới hạn lấy xuống. Chính vì vậy tốt nhất là thiết kế ứng dụng sử dụng một cơ sở dữ liệu và các tên file được tạo ra và giấu kín. Tuy nhiên, không phải lúc nào cũng có thể làm thế.
Ví dụ về một thủ tục kiểm tra hợp lệ tên tệp tin. Nó sử dụng các biểu thức chính quy để đảm bảo rằng chỉ các ký tự hợp lệ là được sử dụng trong tên tệp tin và đặc biệt kiểm tra các ký tự chấm chấm: ...
Bảo vệ cơ sở dữ liệu (Chống lại sự tấn công SQL INJECTION)
– Vấn đề đặt ra là attacker có thể vượt qua rào validate trong front end hoặc fake post form thành công và truyền dc những giá trị không mong muốn vào file PHP để xử lý nếu ta không chặn dc những giá trị này thì 0.O sẽ có những câu lệnh SQL ko chính quy thâm nhập vào những câu SQL chính quy của bạn phá hỏng database của bạn tồi tệ hơn là tạo ra những người dùng siêu quyền hạn để đánh cắp thông tin, bla bla….
– Chúng ta có thể khắc phục dc việc này bằng nhiều cách đơn giản như
- dùng hàm mysql_real_escape_string(). Hàm này làm sạch đầu vào của bạn, sao cho nó không còn bao gồm các ký tự không hợp lệ.
- Kiểm tra xem định dạng chuỗi: email, username, password… đều có một định dạng nhất định, do đó có thể viết các biểu thức chính qui (Regular Expression) cho mỗi định dạng này.
– Vấn đề đặt ra là chúng ta 1 hệ thống có nhiều server khác nhau để duy trì 1 hệ thống site vậy làm sao để đảm bảo được các session trong giao dịch dùng để xử lý, có thể hoạt động trên các server khác trong cùng hệ thống.!?
Để làm được điều này chúng ta cần xử lý sao cho tất cả các máy chủ đều sử dụng chung một hệ thống quản lý session .
Hoặc đơn giản là sử dụng chung một session storage .
Mặc định trong php sẽ sử dụng file session handle các file chứa session sẽ nằm trong /tmp của mỗi server .
Điều này có thể gợi ý cho chúng ta việc share chung 1 vùng lưu trữ (ví dụ dùng NFS để share chung /tmp giữa các máy chủ).
Tuy nhiên cách này lại ảnh hưởng đến tốc độ truy xuất (vì phải qua mạng – sau đó là đến việc máy host session sẽ quá tải diskio).
Một hướng khác là sử dụng một db mysql chung để lưu session , thực tế thì cách này tạm được .
Để làm như vậy chúng ta cần override lại các hàm xử lý session của php
session_set_save_handler("open", "close", "read", "write", "destroy", "gc");
Sử dụng hàm session_set_save_handler để trỏ các call back function cần thiết , như vậy chúng ta cần viết lại 6 hàm open, close , read ,write ,destroy , gc .
Chạy thử . kết quả : openread writeclose …
Như vậy chúng ta thấy thứ tự của một quá trình đọc session .
Việc tiếp theo là implement mấy hàm trên vào mysql , memcached , file , hay bất kỳ một storage nào có thể dùng chung được là xong .
với file (cái này chỉ là làm lại những gì php đã làm )
Dùng memcache hay mysql cũng khá nhanh , mysql thì chạy bàng memory storage engine , bật query cache tướng đối lớn cho nhanh , có thể replication ra nhiều server để đẩy performed lên cao nữa nếu tải lớn .
Bảo vệ chống lại các sơ hở của ứng dụng lệnh xuyên các trang (Cross-Site Scripting – XSS)
– Vấn đề đặt ra là người dùng sẽ nhập nội dung và hệ thống của bạn sẽ hiển thị nội dung đó lên. Nếu nội dung người dùng nhập là script có chứa mã độc phát tán virus,… thì sao.!?
– Để tự bảo vệ bạn chống lại các tấn công XSS, hãy lọc đầu vào của bạn thông qua hàm htmlentities() bất cứ khi nào giá trị của một biến được in đến đầu ra. Hãy nhớ làm theo thói quen đầu tiên về kiểm tra hợp lệ dữ liệu đầu vào bằng các giá trị trong danh sách trắng trong ứng dụng web của bạn đối với tên, địa chỉ email, số điện thoại, và thông tin về hoá đơn thanh toán.
Bảo vệ chống lại các giả mạo yêu cầu xuyên các trang (Cross-Site Request Forgeries – CSRF)
– Một vấn đề là chúng ta phải thật cẩn trọng với người dùng đã là member chính thức vì lúc đó họ đã có dc quyền hạng trong site và họ có thể upload, post,… thoải mái nếu họ lợi dụng quyền này để tấn công bằng cách upload file image nhưng đó thực sự không phải là file image thì sao.!?
Các cuộc tấn công CSRF thường được thực hiện dưới dạng các thẻ <img> vì trình duyệt gọi URL một cách không ý thức để lấy hình ảnh. Tuy nhiên, nguồn hình ảnh dễ dàng có thể chỉ là URL của một trang web trên cùng một site, thực hiện các việc xử lý nào đó dựa trên các tham số chuyển cho nó. Khi thẻ <img> này được đặt trong một cuộc tấn công XSS — cũng là các tấn công phổ biến nhất được ghi chép lại — người sử dụng dễ dàng có thể làm một việc gì đó với quyền ưu tiên được cấp mà không biết mình đã làm — như vậy, có thể giả mạo.
– Lúc đó ngoài việc áp dụng các cách bảo vệ bên trên trước XSS thì chúng ta cần xác minh các form gửi lên chặc hợn. Ngoài ra, sử dụng biến hiển $_POST thay vì $_REQUEST và kiểm tra kỹ lưỡng các file được up lên nếu là hình ảnh ngoài kiểm tra file_upload,… thì cần kiểm tra size ảnh để chắc chắn đó là một hình ảnh thông qua hàm getimagesize() trong php.