Ừ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. 

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 ^^ 

@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.
 

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. 

.....
@conmale: giải pháp server thì cũng phải kết hợp với client chứ  

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ý .

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ồ đồ
 

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. 

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ỉ. 

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. 

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 

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ì?
 

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ỉ )
 

để lưu trữ sau đó dùng để xác nhận kèm theo coockie.  

Lọc đầu vào (từ người dùng) quan trọng hơn chứ (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 ...) 

boom_jt wrote:

Lọc đầu vào (từ người dùng) quan trọng hơn chứ (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á (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 ) 

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. 

hì hì, bồ cứ đưa đoạn mã bị sql inj, mình đảm bảo fix đc á

xss như đoạn bồ vừa nói là 1 trường hợp rất hay, (cũng filter đc chớ 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ì