Messages posted by: vd_

a. Ờ cái này giống web2mail hồi xưa SV hay dùng để down 1 số thứ độc hại, vì vậy tui nghĩ cái rủi ro đầu tiên sẽ là một dạng by pass corporate policy.

Sau đó là nguy cơ DoS từ Gmail lên server chứa file, và nguy cơ tăng load của server Gmail do down file quá lớn hoặc user cố ý kêu Gmail down trúng tarpit

Nếu Gmail cho preview html của file down về thì sẽ có thể dính CSRF đối với site attached vào mail, hoặc bị XSS vào chính Gmail

b.1 Policy restriction trước tiên để hạn chế việc attach file remote: chỉ attach từ một số domain nhất định chẳng hạn (ví dụ Google Docs).
b.2 Nếu có preview html thì render html -> image rồi cho preview cho chắc ăn, hoặc phải sanitize trong trường hợp render trực tiếp.
b.3 Scan virus + pattern matching nội dung file sẽ attach để tránh các nội dung xấu
b.4 size limit & time limit cho việc download

Tạm thời tui nghĩ được nhiêu đó, mong anh em góp ý thêm.

Nhớ thời hồng hoang dial up xài web2mail quá đi thôi.

// Website url to open
$daurl = $_GET['url'];

// Get that website's content
$handle = fopen($daurl, "r");

giờ nếu tui để proxy.php?url=/etc/passwd thì fopen thành fopen('/etc/passwd',"r")

giải pháp:
- chỉnh httpd.conf để không cho access vào / (<Directory> </Directory> smilie

, cái này chắc host provider đã làm
- check $daurl và chỉ pass cho fopen() những gì bạn muốn access

Nguyên tắc: không bao giờ trust client's input

Thêm một trường hợp có thể dẫn đến hàng loạt time wait của httpd là khi httpd bận read quá nhiều file cache của web app tạo ra. Mấy cái CMS thay vì query db để sinh html trả về client khi client request thì nó tạo sẵn html trong 1 directory, mà nếu nhiều content quá thì directory đó sẽ chứa rất nhiều file cache, httpd đọc ra để serve cho client sẽ bị treo. Bạn thử ls 1 directory có khoảng 10k-20k file sẽ thấy vấn đề.

Nếu là SELECT, BENCHMARK, SeLect ... thì sao?

Tốt nhất là bạn nên sanitize các param đưa vào câu SQL thay vì kiểm soát toàn bộ url. Ví dụ chỗ nào cần là number only thì dùng regex để kiểm tra hoặc cast về integer.