Sự tương tác giữa Web server với Application và PHP

[thienthan36]

Em đang chuẩn bị lập trình web !
Nghiên cứu cũng hơi lâu (gần 1 năm)! Nhưng cách tương tác giữa ứng dụng mình viết bằng php với PHP Engenier, và webserver vẫn chưa hiểu hết bản chất
Cách php sử lí với file, sử lí các varible như $_POST, $_SESSION, $_, ... và sử lí với code như thế nào! nói chung là cơ chế của trình PHP engenier làm việc.

[mr47]

Thường thì php được cài như một module của trình chủ web.
Sau khi trình chủ web nhận được request và phân tích đó là request đến một ứng dụng php thì nó sẽ gọi php engine để giải quyết.
$_POST và $_GET và $_COOKIE là các biến được tạo bằng dữ liệu lấy từ chuỗi HTTP request.
PHP engine đọc code php từ đầu đến cuối và process. Thế thôi!

Mình nghĩ mấy kiến thức này bạn nên hiểu ngay từ đầu.

[thienthan36]

Vậy thì liệu mình dùng PHP enginer để hạn chế các request giống như mình dùng PHP đẻ tạo nên bức tường lửa được không. đây có phải là một phải pháp an toàn khi bị mình hạn chế các cuộc tấn công từ mạng.

Mình đưa topic này mục là muốn mọi người tìm hiều các cơ chế mà server làm việc với các request và ứng dụng của mình tương tác với server.
Nếu như PHP enginer đọc hết code của ứng dụng thì không có điều gì để nói. Nhưng thế trong quá trinh code thì memory sẽ bị "đầy" và dẫn đến die(). Nhưng nếu mình điều khiển được quá trình biên dịch thì sẽ tránh được điều này. bằng các die() các request không thích hợp bởi firewall

Điều này chỉ hạn chế mà thôi!
Nhưng nếu mình tự tạo một cơ chế phát sinh mã bảo vệ bằng htaccess dùng php enginer để phát sinh trong quá trình chạy liệu có ổn không nhỉ

[mr47]

mình không hiểu ý bạn? Hoàn toàn không hiểu?
Tại sao lại phải hạn chế request? Không hiểu sao bạn lại đi làm điều ngược đời thế.

Muốn chống DoS thì dùng cách mà nhiều website vẫn dùng: sự dụng link "click vào đây". Bởi vì bot không thể nhận và lưu trữ cookie, nên cứ check và setcookie để xác định. Nếu không có cookie thì cứ "click vào đây mãi".

Còn chuyện memory bị đầy thì mình chịu thôi, bạn dùng PHP để code cái gì mà bị đầy ghê vậy :D Xử lý các file XML nặng 1 GB hả :D

[thienthan36]

bằng cách này thì bot có thể qua mặt bằng cách send cookies dạng header đến server. thì nó vẫn qua cơ chế trên như thường ! Không ổn !
bằng cách hạn chế request thì mình có biết được số lần request và memory được sử dụng của hệ thống cho các request và lọc các request này.
cần thiết thì die() ngay request đó.
Mình trí óc nông cạn nên chỉ nghĩ ra phương pháp này thôi. Cookies không an toàn. dù đã hạn chế nó rất nhiều !

[mr47]

Vậy thì check referer! bot thì không có referer, nếu không có referer thì cứ bảo nó "click here"! Nếu là người dùng bt thì sau khi click lần đầu, referer sẽ tồn tại và cho qua.


bằng cách hạn chế request thì mình có biết được số lần request và memory được sử dụng của hệ thống cho các request và lọc các request này.
:-?? Bạn đang nói về cái gì thế?

[thienthan36]

Mình đang nói về BOT

Cách sử dụng request của mình hơi mới lạ một chút
cách này chỉ hạn chế DDOS mà thôi

[mr47]

Thì mình đã nói rồi đấy, check referer!
Còn cách sử dụn request của bạn mới lạ chỗ nào vậy :D

[thienthan36]

Nếu dùng refer thì cũng không được vì nếu dùng nó thì người BOT có thể gửi một request kèm theo refer chung trong URL thì check refer cũng không ổn.
Em định dùng Request để chống lại request của bot, DOS
Vấn đề là cơ chế lọc request của Firewall, Rất khó để lọc dữ liệu ra được, kiểm tra đâu là request thật, đâu là ảo

không biết em là thế này liệu được không vậy. Tức em dùng biến
cookies hay session trong đó có một cơ chế mã hóa để xác định, đây là request của em. liệu có ổn không nhỉ.
Vấn đề đâu đầu là nếu user send nhiều request dạng http://ids.com/index.php để làm cho server treo
Cái này chịu, chưa tìm ra phương pháp giải quyết. nếu user gửi request dạng refer hay post thì đều chặng được bằng cách sử dụng bộ lọc , mã hóa & giải mã