Chào mọi người,
vừa rồi mình vừa nhận một comment trên blog là file proxy.php của mình làm lộ toàn bộ local files.

Xem comment ở đây: http://rongchaua.net/blog/html5-audio-tag-cross-domain

Xử lý:
- Thay đổi proxy.php thành proxy.txt
- Thay đổi thông tin trên file config của Wordpress và password administrator.
- Đang tiến hàng quyét virus trên host.
- và nên làm gì tiếp theo???

Câu hỏi:
- File proxy.php ở đây http://rongchaua.net/Web/Tmp/proxy.php mình đã đổi thành http://rongchaua.net/Web/Tmp/proxy.txt . Mình muốn hỏi là với cấu trúc code như trên thì làm thế nào có thể view được local files của mình?
- Các bước tiếp theo nên làm gì???

Cám ơn. 

RemoveHandler .php
php_flag engine off
Options -Includes -Indexes
 

PS: nếu được, nên chạy php-fpm để isolate giữa công tác parse + run php và công tác i/o files trên apache thì vững hơn.
 

Bác cho em hỏi

conmale wrote:

RemoveHandler .php
php_flag engine off
Options -Includes -Indexes
 

Nếu ở directory bị mất kiểm soát được/bị override ngược lại thì việc thiết lập trên có hiệu quả không bác? ví dụ:
AddHandler .php
php_flag engine on
Options +Includes +Indexes
 

conmale wrote:

PS: nếu được, nên chạy php-fpm để isolate giữa công tác parse + run php và công tác i/o files trên apache thì vững hơn.
 

Em vào trang http://php-fpm.org thấy không được bác ạ. Bác cho em ý niệm về việc isolate này hoặc hint cho em chỗ vọc được không? 

PHP-FPM (FastCGI Process Manager) is an alternative PHP FastCGI implementation with some additional features useful for sites of any size, especially busier sites.

These features include:

Adaptive process spawning (NEW!)
Basic statistics (ala Apache's mod_status) (NEW!)
Advanced process management with graceful stop/start
Ability to start workers with different uid/gid/chroot/environment and different php.ini (replaces safe_mode)
Stdout & stderr logging
Emergency restart in case of accidental opcode cache destruction
Accelerated upload support
Support for a "slowlog"
Enhancements to FastCGI, such as fastcgi_finish_request() - a special function to finish request & flush all data while continuing to do something time-consuming (video converting, stats processing, etc.)


... and much more.

It was not designed with virtual hosting in mind (large amounts of pools) however it can be adapted for any usage model. 

Bồ nên đọc thêm ở đây:
http://httpd.apache.org/docs/2.2/howto/htaccess.html
 

AllowOverride None 

bồ xem trong php-fpm.org thì ngay trang đầu nó có những thông tin sau:

What is PHP-FPM?

Ability to start workers with different uid/gid/chroot/environment and different php.ini (replaces safe_mode) 

 

nên chạy php-fpm để isolate giữa công tác parse + run php và công tác i/o files trên apache thì vững hơn.  

Ability to start workers with different uid/gid/chroot/environment and different php.ini (replaces safe_mode) 

conmale wrote:

Bồ nên đọc thêm ở đây:
http://httpd.apache.org/docs/2.2/howto/htaccess.html
 

Cảm ơn bác,

Vậy là phải thiết lập

AllowOverride None 

và edit trong httpd.conf; Em muốn hỏi bác thêm là có cách nào chỉ enable cho .htaccess cấu hình với rewrite_url (mod_rewrite) ở directory mà không cho phép override các thứ khác ngoài rewrite không.
 

AllowOverride None 

conmale wrote:

bồ xem trong php-fpm.org thì ngay trang đầu nó có những thông tin sau:

What is PHP-FPM?

Ability to start workers with different uid/gid/chroot/environment and different php.ini (replaces safe_mode) 

 

Xin lỗi bác, lúc em vào là nó bị 'không truy cập được'.
Nhưng em vẫn chưa hiểu rõ đoạn

conmale wrote:

nên chạy php-fpm để isolate giữa công tác parse + run php và công tác i/o files trên apache thì vững hơn.  

và đoạn bôi của bác

Ability to start workers with different uid/gid/chroot/environment and different php.ini (replaces safe_mode) 

thì có khác gì với chroot cho apache khi có delicated server cho 1 site hông.
 

- Và gữa php-fpm, suhosin hay một implementation nào đó có chức năng củng cố bảo mật thì cái nào "ngon" nhất (theo bác). Performance kèm theo có bị ảnh hưởng gì không, hay đó là cái phải đánh đổi.
 

php_admin_value[open_basedir] = /home/someone/public_html/
php_admin_value[doc_root] = /home/someone/public_html/
php_admin_value[upload_tmp_dir] = /home/someone/public_html/tmp
php_admin_value[upload_max_filesize] = 8M
php_flag[cgi.force_wwwect] = 1

Làm như vậy, mọi ý định "remote include" đều không thể thực hiện được.

Tất nhiên, nếu webmaster mà tự ý upload một cái proxy.php củ chuối nào đó đầy lỗ hổng thì có trời mới cứu được vì đây không phải là lỗi của php hoặc php-fpm hoặc apache mà do chính người quản trị.
 

$handle = fopen($daurl, "r");
$buffer = fgets($handle, 4096);
echo $buffer;

Chào bác. Cảm ơn bác đã phân tích chi tiết. Em đã rõ cái "isolation" nhờ php-fpm mà bác nói, nhưng trở lại vấn đề file "proxy.php" (vấn đề theo bác là "có trời mới cứu được").
Code:

$handle = fopen($daurl, "r");
$buffer = fgets($handle, 4096);
echo $buffer;

Nếu webmaster đã "isolate" open_basedir, doc_root, upload_tmp, cấm .htaccess, php-fpm, cấm eval() của php... thì với lỗi không kiểm soát fopen, file_get_contents.... này của proxy.php sẽ gây tổn hại gì cho hệ thống? (cứ cho là thông tin db sẽ bị mất, nhưng db đó không chấp nhận remote connection thì làm sao, nếu là mã nguồn có bị lộ thì hệ thống cũng đâu bị ảnh hưởng gì?) 

Nên nhớ, source (open) được bày trên Internet hoàn toàn có tính chất khác với source của một trang web đang hoạt động mà lại được bày ra do tắc trách.