<![CDATA[Latest posts for the topic "How to anti attack flood SQL ?"]]> /hvaonline/posts/list/8.html JForum - http://www.jforum.net How to anti attack flood SQL ? /hvaonline/posts/list/15738.html#94034 /hvaonline/posts/list/15738.html#94034 GMT How to anti attack flood SQL ?

thanhlongcongtu wrote:
Em đang gặp vấn đề về Flood SQL mong các anh giúp đỡ. Cụ thể site em bị tấn công liên tục vào các file php & đã anti đc rồi Tiếp theo lại bị flood vào SQL với connection lên đến 437 / s. Hiện tại thì tình hình đã khả quan hơn.Nhưng như vậy ko có nghĩa là mình sẽ không bị attack nữa.Vậy nay em mong mọi người có thể đưa ra một giải pháp cho vấn đề attack flood vào SQL dạng này để em và các newbie cùng học hỏi. Chúc mọi người vui vẻ ! 
Làm sao có thể flood vào SQL trực tiếp được? Họ flood thế nào? SQL chạy bằng software gì? server chạy hệ điều hành nào? PS: tôi dời bài này vào "Thảo luận bảo mật" vì nó không phải là chủ đề thâm nhập.]]> /hvaonline/posts/list/15738.html#94041 /hvaonline/posts/list/15738.html#94041 GMT How to anti attack flood SQL ?

conmale wrote:
Làm sao có thể flood vào SQL trực tiếp được? Họ flood thế nào? SQL chạy bằng software gì? server chạy hệ điều hành nào? PS: tôi dời bài này vào "Thảo luận bảo mật" vì nó không phải là chủ đề thâm nhập. 
Đó là điều em muốn hỏi . Server : Unix SQL : Apache version 1.3.39 Em thấy nó có hiện tượng flood ,& chỉ những thứ liên quan tới database nhiều là bị chậm lại(Đứng luôn) trong khi hình ảnh & những thứ khác chạy bình thường(nhanh). Sau khi kiểm tra log thấy : connection có cái tới 437/s =>ddos Em kiểm tra tiếp thì thấy còn nhiều IP với mức độ connection rất lớn(không bình thường). Theo em họ đã dùng tool nào đó để flood vào database,hoặc tạo các connection có thể hợp lệ hoặc ko tạo nhiều request tới server. Với lại mấy ngày hôm nay bên server của em có một vài lỗi connfig em cũng chưa dám chắc rẳng mình bị ddos mà die.Vì thực sự những lần tưoớc bị ddos vào file php hoặc eating BW thì cũng ko tới nỗi nào. Em đưa ra câu hỏi này để mong anh giải thích giùm nguyên tắc ,cách phòng chống cho tất cả mọi người.Vì trước giờ hầu như em để ý mọi người chỉ quan tâm tới ddos một cách chung chung,hoặc cũng chỉ là "em muốn học ddos...". Em mong anh có thể bỏ chút thởi gian để nói rõ cho mọi người về vấn đề flood vào SQL (Theo em nghĩ) chứ không phải mong anh dạy em đi ddos hay xin tool. Cảm ơn anh rất nhiều khi quan tâm tới topic này. P/S :Các câu hỏi của anh thường là để đánh giá lại kiến thức của người hỏi .Đôi khi nghĩ nó phiền phức nhưng thật ra thì nó lại có ích nhiều cho mọi người lắm.Cảm ơn anh. Chúc mọi người vui vẻ ! ]]> /hvaonline/posts/list/15738.html#94230 /hvaonline/posts/list/15738.html#94230 GMT How to anti attack flood SQL ?

thanhlongcongtu wrote:
Đó là điều em muốn hỏi . Server : Unix SQL : Apache version 1.3.39 
Cái này là cái gì đây, tôi không hiểu rỏ !?

thanhlongcongtu wrote:
Em thấy nó có hiện tượng flood ,& chỉ những thứ liên quan tới database nhiều là bị chậm lại(Đứng luôn) trong khi hình ảnh & những thứ khác chạy bình thường(nhanh). Sau khi kiểm tra log thấy : connection có cái tới 437/s =>ddos Em kiểm tra tiếp thì thấy còn nhiều IP với mức độ connection rất lớn(không bình thường). Theo em họ đã dùng tool nào đó để flood vào database,hoặc tạo các connection có thể hợp lệ hoặc ko tạo nhiều request tới server. Với lại mấy ngày hôm nay bên server của em có một vài lỗi connfig em cũng chưa dám chắc rẳng mình bị ddos mà die.Vì thực sự những lần tưoớc bị ddos vào file php hoặc eating BW thì cũng ko tới nỗi nào. Em đưa ra câu hỏi này để mong anh giải thích giùm nguyên tắc ,cách phòng chống cho tất cả mọi người.Vì trước giờ hầu như em để ý mọi người chỉ quan tâm tới ddos một cách chung chung,hoặc cũng chỉ là "em muốn học ddos...". 
Tôi củng đang tìm hiểu ddos với dđiếc đây, bạn cho tôi xem log của Apache xem .

thanhlongcongtu wrote:
Em mong anh có thể bỏ chút thởi gian để nói rõ cho mọi người về vấn đề flood vào SQL (Theo em nghĩ) chứ không phải mong anh dạy em đi ddos hay xin tool. 
SQL ? :-( ]]> /hvaonline/posts/list/15738.html#94232 /hvaonline/posts/list/15738.html#94232 GMT Re: How to anti attack flood SQL ? /hvaonline/posts/list/15738.html#94241 /hvaonline/posts/list/15738.html#94241 GMT Re: How to anti attack flood SQL ? SQL : Apache version 1.3.39   cái này la webserver mà :-?? Còn về SQL thì nhớ rằng phải có ít nhất quyền admin mơi làm được. Có thể do server bi thôi, nếu dùng shared host thì bị chung :x]]> /hvaonline/posts/list/15738.html#94251 /hvaonline/posts/list/15738.html#94251 GMT How to anti attack flood SQL ?

thanhlongcongtu wrote:
P/S :Các câu hỏi của anh thường là để đánh giá lại kiến thức của người hỏi .Đôi khi nghĩ nó phiền phức nhưng thật ra thì nó lại có ích nhiều cho mọi người lắm.Cảm ơn anh.  
Sai. Tôi hỏi để xác định tình hình và biên độ vấn đề để có thể góp ý một cách chính xác. Tôi không đánh giá kiến thức ai cả, ngoại trừ một cá nhân nào đó có ý định đi vào cái "cõi" ấy. Riêng trở ngại của bồ, những thông tin bồ cung cấp cũng không đủ để giúp bồ cái gì cả. Server : Unix SQL : Apache version 1.3.39 - Unix nào? - SQL nào mà Apache version 1.3.39? Bồ nên xem lại server của mình và cung cấp chính xác thông tin. Nếu không, tôi không thể góp ý được gì cả.]]> /hvaonline/posts/list/15738.html#94260 /hvaonline/posts/list/15738.html#94260 GMT Re: How to anti attack flood SQL ? /hvaonline/posts/list/15738.html#94347 /hvaonline/posts/list/15738.html#94347 GMT Re: How to anti attack flood SQL ?

thanhlongcongtu wrote:
Xin lỗi vì em nói không rõ ràng. Thế này nhé : Site của em nằm trên host thuộc hostvn.net Chạy 1 forum vbb & 1 site nhạc xtremedia. cPanel Version 11.15.0-RELEASE cPanel Build 17802 Theme x3 Apache version 1.3.39 (Unix) PHP version 4.4.7 MySQL version 4.1.22-standard Architecture i686 Operating system Linux Em muốn hỏi là có hay không flood vào mySQL. Nếu có thì anti như thế nào. 
Có. Nếu cổng 3306 mặc định của mySQL mở toang thì có thể bị flood thẳng vào đó. Anti: chỉnh trong my.conf để nó listen trên 127.0.0.1 hoặc dùng firewall để cản access đến cổng 3306 từ bên ngoài vào.]]> /hvaonline/posts/list/15738.html#94351 /hvaonline/posts/list/15738.html#94351 GMT Re: How to anti attack flood SQL ? conmale nói.]]> /hvaonline/posts/list/15738.html#94358 /hvaonline/posts/list/15738.html#94358 GMT Re: How to anti attack flood SQL ?

thanhlongcongtu wrote:
Em đc server reply all.Chứ em làm gì có quyền root trên server mà xem ? 
và đây

conmale wrote:
Có. Nếu cổng 3306 mặc định của mySQL mở toang thì có thể bị flood thẳng vào đó. Anti: chỉnh trong my.conf để nó listen trên 127.0.0.1 hoặc dùng firewall để cản access đến cổng 3306 từ bên ngoài vào.  
Nếu có quyền root mới làm dc như conmale nói. Còn ko thì ngồi chơi sơi nước đi :D , vì ko tự mình config gì dc cả. Cấp bách quá thì mail cho thằng quản lý server bảo nó config lại.]]> /hvaonline/posts/list/15738.html#94403 /hvaonline/posts/list/15738.html#94403 GMT Re: How to anti attack flood SQL ? /hvaonline/posts/list/15738.html#94433 /hvaonline/posts/list/15738.html#94433 GMT Re: How to anti attack flood SQL ? /hvaonline/posts/list/15738.html#94518 /hvaonline/posts/list/15738.html#94518 GMT Re: How to anti attack flood SQL ? /hvaonline/posts/list/15738.html#111504 /hvaonline/posts/list/15738.html#111504 GMT Re: How to anti attack flood SQL ?

thanhlongcongtu wrote:
Dạ em thưa anh là Hostvn.net thuê trực tiếp server tại theplanet.com , còn bên đó có 2 người control server trực tiếp và em chat suốt ngày chứ có thấy đi suốt đâu nhỉ ^^ , em chơi khá thân với 2 anh ý nên gần như vấn đề gì em cũng hỏi được :D . 
Sử dụng quyền user thì lở mysql chết queo rồi thì cho nó chết queo luôn đi, chứ "đòi hỏi anti flood" làm gì . :-/ ]]> /hvaonline/posts/list/15738.html#111507 /hvaonline/posts/list/15738.html#111507 GMT How to anti attack flood SQL ? Code:
| 1003606 | database-user | localhost | database-name | Query | 991 | Locked | SELECT m.*, u.user_colour, g.group_colour, g.group_type FROM (phpbb_moderator_cache m) LEFT JOIN php |
| 1003700 | database-user | localhost | database-name | Query | 984 | Locked | SELECT u.*, s.*
FROM phpbb_users u
LEFT JOIN phpbb_sessions s ON (s.session_user_id = u.us |
| 1003932 | database-user | localhost | database-name | Query | 973 | Locked | SELECT u.*, s.*
FROM phpbb_users u
LEFT JOIN phpbb_sessions s ON (s.session_user_id = u.us |
| 1004065 | database-user | localhost | database-name | Query | 966 | Locked | SELECT u.*, s.*
FROM phpbb_users u
LEFT JOIN phpbb_sessions s ON (s.session_user_id = u.us |
| 1004324 | database-user | localhost | database-name | Query | 950 | Locked | SELECT u.*, s.*
FROM phpbb_users u
LEFT JOIN phpbb_sessions s ON (s.session_user_id = u.us |
| 1004368 | database-user | localhost | database-name | Query | 947 | Locked | SELECT u.*, s.*
FROM phpbb_sessions s, phpbb_users u
WHERE s.session_id = 'b8e7433567dce7f85 |
| 1004386 | database-user | localhost | database-name | Query | 947 | Locked | SELECT u.*, s.*
FROM phpbb_sessions s, phpbb_users u
WHERE s.session_id = 'cbfcf01f3bc9b61c3 |
| 1004420 | database-user | localhost | database-name | Query | 945 | Locked | SELECT u.*, s.*
FROM phpbb_users u
LEFT JOIN phpbb_sessions s ON (s.session_user_id = u.us |
| 1004695 | database-user | localhost | database-name | Query | 930 | Locked | SELECT u.*, s.*
FROM phpbb_users u
LEFT JOIN phpbb_sessions s ON (s.session_user_id = u.us |
| 1004926 | database-user | localhost | database-name | Query | 917 | Locked | SELECT u.*, s.*
FROM phpbb_sessions s, phpbb_users u
WHERE s.session_id = 'b8e7433567dce7f85 |
| 1004978 | database-user | localhost | database-name | Query | 914 | Locked | SELECT u.*, s.*
FROM phpbb_users u
LEFT JOIN phpbb_sessions s ON (s.session_user_id = u.us |
| 1005045 | database-user | localhost | database-name | Query | 910 | Locked | SELECT u.*, s.*
FROM phpbb_users u
LEFT JOIN phpbb_sessions s ON (s.session_user_id = u.us
| Họ yêu cầu mình phải cam kết khắc phục tình trạng này thì account mới được kích haọat lại. Xin hỏi làm thế nào để khắc phục tình trạng này? Giải pháp đến từ phía admin của server hay từ mình? Các firewall Script chạy qua website như InV-Firewall Script có tác dụng trong trường hợp này không?]]> /hvaonline/posts/list/15738.html#185378 /hvaonline/posts/list/15738.html#185378 GMT How to anti attack flood SQL ? /hvaonline/posts/list/15738.html#185430 /hvaonline/posts/list/15738.html#185430 GMT How to anti attack flood SQL ?

canh_nguyen wrote:
InV-Firewall nó như thế nào thế cậu ? 
Hosting Provider yêu cầu mình cài đặt thêm trình tường lửa vào, mình search thử thì http://sinhvienit.net/@forum/anti-ddos/7207-cai-dat-tuong-lua-inv-firewall-script-cho-dien-dan-ban-ipb-phpbb-vbulletin.html, có vấn đề gì sao bạn?
InV-Firewall Script là một firewall của tác giả Nguyen Tuan Dung, lập trình dành riêng cho hệ thống forum Invision Power Board [cũng có thể tích hợp và forum khác dễ dàng]. Tính năng của hệ thống tường lửa cho website này tập trung chính ở việc cản trở một phần các gói dữ liệu được gửi liên tục hay yêu cầu truy cập đến diễn đàn với số lượng lớn trong thời gian ngắn. 
Mình upload nó lên cho các bạn tham khảo đây Code:
http://www.mediafire.com/?mtlz2zmjz1y
]]> /hvaonline/posts/list/15738.html#185441 /hvaonline/posts/list/15738.html#185441 GMT How to anti attack flood SQL ? 1) Trực tiếp: Dạng này chỉ có thể xảy ra nếu cổng SQL mở và không có cơ chế bảo vệ (tường lửa). Dạng flood SQL trực tiếp này không cần phải có account để truy cập mà nó chỉ cần tạo SYN request liên tục khiến cho dịch vụ SQL này không còn "rảnh tay" mà phục vụ các truy vấn hợp lệ nữa. Biện pháp khắc phục loại này có 2 cách chính: a. Dùng tường lửa để cản truy cập từ bên ngoài vào. b. Điều chỉnh dịch vụ này cho nó lắng nghe trên loopback IP (127.0.0.1) và chỉ cho phép truy vấn xảy ra từ một số IP nhất định nào đó. 2) Gián tiếp: Dạng này có thể xảy ra cho bất cứ web applications nào tạo trang động (dynamic html). Tại sao nó có thể xảy ra? Trình duyệt <---> web server <---> php, asp, jsp <---> CSDL Nếu trình duyệt truy cập một url như /path/to/somewhere.php và trang somewhere.php này cần truy vấn CSDL để lấy thông tin rồi mới hình thành một trang html để trả về cho trình duyệt thì CSDL này có thể "bị" truy vấn một cách gián tiếp. Nếu 1000 người cùng "truy cập" somewhere.php thì sẽ có ít nhất 1000 truy vấn đến CSDL để lấy thông tin ---> SQL bị flood. Dạng này có nhiều cách để khắc phục nhưng khá phức tạp, tùy vào cách thiết kế của web application đó và cách thiết lập dịch vụ web cũng như cơ chế bảo vệ ở tầng thấp hơn (ví dụ như firewall thật sự). a. Cách giảm thiểu số lần truy cập: Cách này thường dựa vào quy định một IP chỉ được phép truy cập bao nhiêu lần trong một khoảng thời gian nào đó. Cách giới hạn truy cập này có thể thực hiện từ tầng thấp nhất (IP layer) đến tầng cao nhất (application layer - ngay trên code của php / asp / jsp....). Cách này lợi ở chỗ nó ấn định số lượng truy cập nên giảm thiểu số lượng truy vấn (gián tiếp) đến CSDL. InV-Firewall Script thuộc dạng "giảm thiểu số lần truy cập". b. Cách giảm thiểu số lần truy vấn đến CSDL: Cách này thường đòi hỏi thiết kế ngay trên web application và thường áp dụng caching. Caching thì có 2 dạng chính: b.1 Dạng caching bên ngoài: Caching bên ngoài là caching không ở biên độ web application mà ở biên độ một dịch vụ bên ngoài web application. Loại caching này thường trông cậy vào một dạng reverse proxy (apache, squid, application content filtering system.... ). Loại này đứng giữa trình duyệt và web application: Trình duyệt <---> forward proxy (nếu có - như VNPT của VN) <----> reverse proxy <----> web server <----> web app <----> CSDL. Hệ thống wiki nổi tiếng là một điển hình cho dạng này. Dùng reverse proxy để cache thông tin, đặc biệt là thông tin cho dymamic html dễ mà khó. Dễ ở chỗ nó có thể cache bất cứ thứ gì nhưng khó ở chỗ nếu dynamic html được tạo ra cho nhiều session khác nhau mà không kiểm soát kỹ thì bị lỗ hổng bảo mật. b.2 Dạng caching bên trong: Dạng này cache ở ngay tại web application. Ví dụ một trang nào đó được cache vào memory và được dùng để cung cấp cho trình duyệt. Nếu thông tin trên trang này không thay đổi thì web app dùng bản đã có sẵn trên memory để cung cấp cho trình duyệt thay vì phải truy vấn CSDL để tạo trang html cho mỗi truy cập. Riêng HVA sử dụng cả biện pháp "giảm thiểu số lần truy cập" (từ tầng IP lên đến tầng application) và dạng "caching bên trong". Một trang list.html chẳng hạn, nếu có ai đó post bài mới thì web application sẽ tạo một tập hợp có chứa các thông tin dành riêng cho "list.html" và lưu nó trong cache. Những truy cập vào "list.html" sẽ dùng thông tin trong cache để cung cấp thay vì phải truy vấn CSDL (biện pháp này được áp dụng trong bản jforum nguyên thủy nhưng khá rời rạc, bản HVA đang dùng đã được code lại chặt chẽ hơn). Tuy vậy, để bảo đảm vận tốc truy cập, cơ chế "giới hạn số lần truy cập" vẫn được áp dụng.]]> /hvaonline/posts/list/15738.html#185495 /hvaonline/posts/list/15738.html#185495 GMT How to anti attack flood SQL ?

jforum3000 wrote:

canh_nguyen wrote:
InV-Firewall nó như thế nào thế cậu ? 
Hosting Provider yêu cầu mình cài đặt thêm trình tường lửa vào, mình search thử thì http://sinhvienit.net/@forum/anti-ddos/7207-cai-dat-tuong-lua-inv-firewall-script-cho-dien-dan-ban-ipb-phpbb-vbulletin.html, có vấn đề gì sao bạn?
InV-Firewall Script là một firewall của tác giả Nguyen Tuan Dung, lập trình dành riêng cho hệ thống forum Invision Power Board [cũng có thể tích hợp và forum khác dễ dàng]. Tính năng của hệ thống tường lửa cho website này tập trung chính ở việc cản trở một phần các gói dữ liệu được gửi liên tục hay yêu cầu truy cập đến diễn đàn với số lượng lớn trong thời gian ngắn. 
Mình upload nó lên cho các bạn tham khảo đây Code:
http://www.mediafire.com/?mtlz2zmjz1y
 
À mình hỏi lại cho chắc thôi mà :D. Về những gì to hơn thì anh conmale đã nói, mình không chuyên nên không dám có ý kiến gì :) . Chỉ lạm bàn một chút về code Inv kia: Đầu tiên trong readme có hướng dẫn : Code:
Add below:
$firewall = ROOT_PATH.'firewall/firewall.php';
if( file_exists($firewall) ){ require_once($firewall); }
Đây là một cách copy variable, khi forum đang bị ddos thì mình cũng cần tiết kiệm bộ nhớ bằng cách tránh dùng cách copy variable. Nếu là mình mình sẽ dùng luôn : Code:
if( file_exists(ROOT_PATH.'firewall/firewall.php') ){ require_once(ROOT_PATH.'firewall/firewall.php'); }
Tiếp theo trong firewall.php Để ý có function check_bot() Nếu là một kẻ cố tình tấn công thì chắc người đó cũng không bỏ qua cách fake HTTP_USER_AGENT để qua mặt firewall này :D . Cách này dùng cả fwrite để ghi log các ip ra file, không hiểu ddos với cường độ lớn thì cái file này hoặc php engine như thế nào? ]]> /hvaonline/posts/list/15738.html#185539 /hvaonline/posts/list/15738.html#185539 GMT How to anti attack flood SQL ?

conmale wrote:
Thế nào là flood SQL? Flood SQL có 2 dạng:  
Hì, hình như anh chưa định nghĩa "flood SQL" là gì đã đi vào phân dạng nó rồi! Theo em hiểu, flood SQL là hình thức tấn công bằng cách gửi thật nhiều yêu cầu truy vấn SQL đến database server đến nỗi database server không thể response được các yêu cầu hợp lệ khác.

conmale wrote:
b.1 Dạng caching bên ngoài: Caching bên ngoài là caching không ở biên độ web application mà ở biên độ một dịch vụ bên ngoài web application. Loại caching này thường trông cậy vào một dạng reverse proxy (apache, squid, application content filtering system.... ). Loại này đứng giữa trình duyệt và web application: Trình duyệt <---> forward proxy (nếu có - như VNPT của VN) <----> reverse proxy <----> web server <----> web app <----> CSDL. Hệ thống wiki nổi tiếng là một điển hình cho dạng này. Dùng reverse proxy để cache thông tin, đặc biệt là thông tin cho dymamic html dễ mà khó. Dễ ở chỗ nó có thể cache bất cứ thứ gì nhưng khó ở chỗ nếu dynamic html được tạo ra cho nhiều session khác nhau mà không kiểm soát kỹ thì bị lỗ hổng bảo mật. 
Anh giải thích giúp em thuật ngữ "dynamic html" với. ]]> /hvaonline/posts/list/15738.html#185569 /hvaonline/posts/list/15738.html#185569 GMT How to anti attack flood SQL ?

theory wrote:

conmale wrote:
Thế nào là flood SQL? Flood SQL có 2 dạng:  
Hì, hình như anh chưa định nghĩa "flood SQL" là gì đã đi vào phân dạng nó rồi! Theo em hiểu, flood SQL là hình thức tấn công bằng cách gửi thật nhiều yêu cầu truy vấn SQL đến database server đến nỗi database server không thể response được các yêu cầu hợp lệ khác.  
Flood SQL có hai dạng thì phải tách ra 2 dạng và định nghĩa 2 dạng đó chớ sao em? Sao em lại tách 1 dòng đó ra rồi cho rằng anh chưa định nghĩa mà lại phân loại? Không biết nó là loại gì thì làm sao định nghĩa? :P .

theory wrote:

conmale wrote:
b.1 Dạng caching bên ngoài: Caching bên ngoài là caching không ở biên độ web application mà ở biên độ một dịch vụ bên ngoài web application. Loại caching này thường trông cậy vào một dạng reverse proxy (apache, squid, application content filtering system.... ). Loại này đứng giữa trình duyệt và web application: Trình duyệt <---> forward proxy (nếu có - như VNPT của VN) <----> reverse proxy <----> web server <----> web app <----> CSDL. Hệ thống wiki nổi tiếng là một điển hình cho dạng này. Dùng reverse proxy để cache thông tin, đặc biệt là thông tin cho dymamic html dễ mà khó. Dễ ở chỗ nó có thể cache bất cứ thứ gì nhưng khó ở chỗ nếu dynamic html được tạo ra cho nhiều session khác nhau mà không kiểm soát kỹ thì bị lỗ hổng bảo mật. 
Anh giải thích giúp em thuật ngữ "dynamic html" với.  
Dynamic html là html động. Nó là dạng html được web application xây dựng và cung cấp cho trình duyệt khi trình duyệt truy cập đến url nào đó. Trong khi đó, static html (html tĩnh) là dạng html đã được chuẩn bị sẵn trước và nội dung không hề thay đổi (bất kể ai truy cập đến).]]> /hvaonline/posts/list/15738.html#185646 /hvaonline/posts/list/15738.html#185646 GMT How to anti attack flood SQL ?

conmale wrote:
Flood SQL có hai dạng thì phải tách ra 2 dạng và định nghĩa 2 dạng đó chớ sao em? Sao em lại tách 1 dòng đó ra rồi cho rằng anh chưa định nghĩa mà lại phân loại? Không biết nó là loại gì thì làm sao định nghĩa? :P .  
Thì ra anh phân dạng flood SQL rồi mới định nghĩa từng dạng của nó. Sao anh không đưa ra một định nghĩa chung cho tất cả các dạng flood SQL? Theo em, flood SQL là hình thức tấn công bằng cách gửi thật nhiều yêu cầu truy vấn SQL đến database server đến nỗi database server không thể response được các yêu cầu hợp lệ khác. Anh thấy định nghĩa của em về flood SQL như thế nào?

conmale wrote:
b.1 Dạng caching bên ngoài: Caching bên ngoài là caching không ở biên độ web application mà ở biên độ một dịch vụ bên ngoài web application. Loại caching này thường trông cậy vào một dạng reverse proxy (apache, squid, application content filtering system.... ). Loại này đứng giữa trình duyệt và web application: Trình duyệt <---> forward proxy (nếu có - như VNPT của VN) <----> reverse proxy <----> web server <----> web app <----> CSDL. Hệ thống wiki nổi tiếng là một điển hình cho dạng này. Dùng reverse proxy để cache thông tin, đặc biệt là thông tin cho dymamic html dễ mà khó. Dễ ở chỗ nó có thể cache bất cứ thứ gì nhưng khó ở chỗ nếu dynamic html được tạo ra cho nhiều session khác nhau mà không kiểm soát kỹ thì bị lỗ hổng bảo mật.  
Cám ơn anh, em đã hiểu thuật ngữ "dynamic html" rồi. Như vậy, dù là dynamic html hay static html, cái mà người dùng nhận được cũng đều là html, hiểu theo nghĩa là chỉ có thể đọc thông tin nhận được mà không thể thay đổi. Người dùng không thể thay đổi tức là không tác động ngược lại server nhằm làm thay đổi "thái độ làm việc" của hệ thống thì sao gọi là "lỗ hổng bảo mật" được? Anh có thể đơn cử một vài lỗ hổng có thể có của việc "không kiểm soát kỹ việc tạo ra dynamic html cho từng session khác nhau"?]]> /hvaonline/posts/list/15738.html#185670 /hvaonline/posts/list/15738.html#185670 GMT How to anti attack flood SQL ?

theory wrote:

conmale wrote:
Flood SQL có hai dạng thì phải tách ra 2 dạng và định nghĩa 2 dạng đó chớ sao em? Sao em lại tách 1 dòng đó ra rồi cho rằng anh chưa định nghĩa mà lại phân loại? Không biết nó là loại gì thì làm sao định nghĩa? :P .  
Thì ra anh phân dạng flood SQL rồi mới định nghĩa từng dạng của nó. Sao anh không đưa ra một định nghĩa chung cho tất cả các dạng flood SQL? Theo em, flood SQL là hình thức tấn công bằng cách gửi thật nhiều yêu cầu truy vấn SQL đến database server đến nỗi database server không thể response được các yêu cầu hợp lệ khác. Anh thấy định nghĩa của em về flood SQL như thế nào?  
Định nghĩa này tốt đó. :P

theory wrote:

conmale wrote:
b.1 Dạng caching bên ngoài: Caching bên ngoài là caching không ở biên độ web application mà ở biên độ một dịch vụ bên ngoài web application. Loại caching này thường trông cậy vào một dạng reverse proxy (apache, squid, application content filtering system.... ). Loại này đứng giữa trình duyệt và web application: Trình duyệt <---> forward proxy (nếu có - như VNPT của VN) <----> reverse proxy <----> web server <----> web app <----> CSDL. Hệ thống wiki nổi tiếng là một điển hình cho dạng này. Dùng reverse proxy để cache thông tin, đặc biệt là thông tin cho dymamic html dễ mà khó. Dễ ở chỗ nó có thể cache bất cứ thứ gì nhưng khó ở chỗ nếu dynamic html được tạo ra cho nhiều session khác nhau mà không kiểm soát kỹ thì bị lỗ hổng bảo mật.  
Cám ơn anh, em đã hiểu thuật ngữ "dynamic html" rồi. Như vậy, dù là dynamic html hay static html, cái mà người dùng nhận được cũng đều là html, hiểu theo nghĩa là chỉ có thể đọc thông tin nhận được mà không thể thay đổi. Người dùng không thể thay đổi tức là không tác động ngược lại server nhằm làm thay đổi "thái độ làm việc" của hệ thống thì sao gọi là "lỗ hổng bảo mật" được? Anh có thể đơn cử một vài lỗ hổng có thể có của việc "không kiểm soát kỹ việc tạo ra dynamic html cho từng session khác nhau"? 
Một trang web chỉ cung cấp static html thường không duy trì session (xuất truy cập) để nhận diện ai là ai cả. Tất cả mọi truy cập từ client đến server chỉ đơn thuần là request / response. Client gởi request, server trả response ---> xong. Lần kết tiếp, cũng client ấy gởi request và server vẫn tiếp tục trả lời mà không cần biết có phải client đó cũng là một client vừa gởi request cách đây vài giây hoặc vài phút. Trái lại, một trang web cung cấp dynamic html có khả năng ấn định session để nhận diện ai là ai. Bản thân HTTP là một "stateless" protocol, bởi thế, để tạo cho chúng "stateful" (giả) thì phải cần một cái gì đó để nhận diện và cookie là phương tiện phổ biến nhất. Bởi lẽ dynamic html được tạo ra có thể kèm theo khả năng "nhận diện", quyền truy cập và sử dụng trang web ấy cũng xuất hiện. Từ đó, cơ chế "nhận diện" và "quyền truy cập" khiến cho lỗ hổng cũng hình thành. Nếu một ai đó bị đánh cắp (A) trọn bộ header gởi từ trình duyệt đến server (cho mục đích nhận diện và xác định quyền truy cập) thì kẻ đánh cắp được (B) có thể giả mạo mình y hệt như người bị đánh cắp. Server có thể kiểm soát ở giới hạn nào đó hiểm hoạ này nhưng hầu hết các trang web hiện tại không làm việc ấy. Đối với caching, nếu squid (hoặc bất cứ một ứng dụng caching nào khác) cache luôn cả thông tin liên quan đến việc "nhận diện" và "gán quyền" (đã nói ở trên) thì kẻ thứ nhì có thể truy cập vào tài nguyên của service y hệt như kẻ thứ nhất. Đây chính là lỗ hổng. Khía cạnh bảo mật này có thể khai triển ra nhiều điểm lý thú và đó là lý do tại sao cho đến ngày nay, XSS vẫn được ưa chuộng và vẫn lan tràn trên các ứng dụng web.]]> /hvaonline/posts/list/15738.html#185681 /hvaonline/posts/list/15738.html#185681 GMT How to anti attack flood SQL ?

conmale wrote:
Định nghĩa này tốt đó. :P  
Cám ơn anh đã dành thời gian giải đáp những thắc mắc của em! Chúc anh nhiều sức khỏe!]]> /hvaonline/posts/list/15738.html#185757 /hvaonline/posts/list/15738.html#185757 GMT How to anti attack flood SQL ? /hvaonline/posts/list/15738.html#185765 /hvaonline/posts/list/15738.html#185765 GMT How to anti attack flood SQL ?

myquartz wrote:
Hi! Theo tớ Comale sử dụng thuật ngữ "dynamic html" và "static html" .. .chưa hợp lắm. Dynamic HTML dễ nhầm với DHTML (viết tắt), là 1 khái niệm với ý nghĩa khác: http://en.wikipedia.org/wiki/DHTML Cái này ngược với Static HTML, cũng như thế. Với 2 cái ý nghĩa tương tự như là Comale nói, thì nên được gọi là Dynamic Web Page, và Static Web Page. Xem http://en.wikipedia.org/wiki/Dynamic_web_page Bài này nói về khái niệm, vì thế nên có ý kiến vậy. 
"dynamic html" != Dynamic HTML "dynamic html" != DHTML :P Khác chỗ nào, thấy không?]]> /hvaonline/posts/list/15738.html#185770 /hvaonline/posts/list/15738.html#185770 GMT How to anti attack flood SQL ? /hvaonline/posts/list/15738.html#185812 /hvaonline/posts/list/15738.html#185812 GMT How to anti attack flood SQL ?

conmale wrote:
Đối với caching, nếu squid (hoặc bất cứ một ứng dụng caching nào khác) cache luôn cả thông tin liên quan đến việc "nhận diện" và "gán quyền" (đã nói ở trên) thì kẻ thứ nhì có thể truy cập vào tài nguyên của service y hệt như kẻ thứ nhất. Đây chính là lỗ hổng. Khía cạnh bảo mật này có thể khai triển ra nhiều điểm lý thú và đó là lý do tại sao cho đến ngày nay, XSS vẫn được ưa chuộng và vẫn lan tràn trên các ứng dụng web. 
Anh có thể khai mở một ít để em có cơ sở khai triển tiếp?]]> /hvaonline/posts/list/15738.html#185858 /hvaonline/posts/list/15738.html#185858 GMT How to anti attack flood SQL ?

theory wrote:

conmale wrote:
Đối với caching, nếu squid (hoặc bất cứ một ứng dụng caching nào khác) cache luôn cả thông tin liên quan đến việc "nhận diện" và "gán quyền" (đã nói ở trên) thì kẻ thứ nhì có thể truy cập vào tài nguyên của service y hệt như kẻ thứ nhất. Đây chính là lỗ hổng. Khía cạnh bảo mật này có thể khai triển ra nhiều điểm lý thú và đó là lý do tại sao cho đến ngày nay, XSS vẫn được ưa chuộng và vẫn lan tràn trên các ứng dụng web. 
Anh có thể khai mở một ít để em có cơ sở khai triển tiếp? 
Thử đọc kỹ đoạn ở trên và tìm các từ khóa chính, tìm các trọng điểm của nó xem có gì để... khai triển không?]]> /hvaonline/posts/list/15738.html#185863 /hvaonline/posts/list/15738.html#185863 GMT How to anti attack flood SQL ?

conmale wrote:
Thử đọc kỹ đoạn ở trên và tìm các từ khóa chính, tìm các trọng điểm của nó xem có gì để... khai triển không?  
Em thử tô màu cam cho các từ khóa chính trong đoạn anh đề cập:

conmale wrote:
Trái lại, một trang web cung cấp dynamic html có khả năng ấn định session để nhận diện ai là ai. Bản thân HTTP là một "stateless" protocol, bởi thế, để tạo cho chúng "stateful" (giả) thì phải cần một cái gì đó để nhận diện và cookie là phương tiện phổ biến nhất. Bởi lẽ dynamic html được tạo ra có thể kèm theo khả năng "nhận diện", quyền truy cập và sử dụng trang web ấy cũng xuất hiện. Từ đó, cơ chế "nhận diện" và "quyền truy cập" khiến cho lỗ hổng cũng hình thành. Nếu một ai đó bị đánh cắp (A) trọn bộ header gởi từ trình duyệt đến server (cho mục đích nhận diện và xác định quyền truy cập) thì kẻ đánh cắp được (B) có thể giả mạo mình y hệt như người bị đánh cắp. Server có thể kiểm soát ở giới hạn nào đó hiểm hoạ này nhưng hầu hết các trang web hiện tại không làm việc ấy. Đối với caching, nếu squid (hoặc bất cứ một ứng dụng caching nào khác) cache luôn cả thông tin liên quan đến việc "nhận diện" và "gán quyền" (đã nói ở trên) thì kẻ thứ nhì có thể truy cập vào tài nguyên của service y hệt như kẻ thứ nhất. Đây chính là lỗ hổng. Khía cạnh bảo mật này có thể khai triển ra nhiều điểm lý thú và đó là lý do tại sao cho đến ngày nay, XSS vẫn được ưa chuộng và vẫn lan tràn trên các ứng dụng web. 
Đứng ở vai trò của người xây dựng chế độ phòng thủ cho application, em đang tự hỏi "Liệu web application có thể nhận diện và gán quyền người dùng không nếu không có thông tin về nhận diện và gán quyền?". Câu trả lời, theo em, là có thể. Tại một thời điểm, một người dùng chỉ dùng máy tính có địa chỉ IP duy nhất để truy cập web application. Do đó, tại một thời điểm, không thể có chuyện một máy tính do người dùng và attacker cùng ngồi. Lỗ hổng bảo mật này có thể được vá lại nhờ lưu lại IP của máy tính mà người dùng sử dụng truy cập vào web application.]]> /hvaonline/posts/list/15738.html#185902 /hvaonline/posts/list/15738.html#185902 GMT