Messages posted by: vivashadow

Hic, sôi nổi quá, đọc mờ mắt!
Xin có ý kiến, cái này không ổn.

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  smilie

gamma95 wrote:

@secmask: tui có nói đến cụm từ "nhanh tay" , 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

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.

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.

nolateforbegin wrote:

dù gắn modem vô vẫn được cấp IP

cấp là dc cấp động bằng DHCP?

nolateforbegin wrote:

em đã thử ping, thử gõ 192.168.1.1 cho nó phi vô modem nhưng cũng không được?

khả năng đã tự đặt IP tĩnh, nhưng set sai mạng và gateway.
bạn hãy post kq ifconfig -a lên đây
PS tránh dùng từ quá "hình tượng"

destop.ini bình thường máy nào cũng có độ 50 cái, nó nằm trong các special folder của win, chứa thông tin display và behavior cho folder đó.
Nếu số lượng desktop.ini lên đến hàng trăm thì mới nghĩ đến bị virus, thường là con redolf, khi này thì thường xuất hiện kèm hàng trăm file folder.htt, thư mục nào cũng có.
Chắc đây chỉ là một lỗi nhỏ do win hiểu lầm và mở destop.ini thôi, bạn xóa hết destop.ini là phá hỏng luôn cấu trúc thư mục của win đó, có thể phải cài lại win.

Diệt bằng AV không dc thì dùng http://www.majorgeeks.com/download3155.html tạo log và post lên đây.

Trước hết bạn thử dùng traceroute -I đi đã, và nói rõ thêm đang dùng máy ở nhà hay cty, cấu trúc mạng, gateway là máy hay router hay ASDL modem, modem hiệu gì, ISP là gì.
À bạn còn ping ra ngoài được không.

Đơn giản là do ISP (hoặc Router nằm sau gateway) không trả lời, hoặc gateway(mygateway1.ar7) không gởi tiếp gói tin tracing (UDP port 33434-33534 hoặc ICMP type 8).

Được.
Với ReadyBoost của Vistra, kết quả nhanh hơn hay không tùy USB có ReadyBoost ready hay không, và vẫn còn đang bàn cãi.

Đúng vậy đơn giản nhất là phải có đánh dấu kết thúc file, khá hơn là gởi thông tin meta (size, checksum,...).
Nhưng nếu muốn chương trình hoạt động tốt, bảo đảm toàn vẹn thông tin (truyền file phải cần), bạn phải xây dựng cơ chế thông điệp hồi đáp 2 chiều, nói đơn giản là bạn tự tạo ra một protocol riêng cho mình. 1 cơ chế cho phép reconnect tự động và tiếp tục công việc bỏ dở. (VD: Chia nhỏ tập tin theo gói tương ứng buffer chẳng hạn, đánh số tt để cho phép gởi lại đoạn buffer đó chứ kô gởi lại từ đầu,...)
...
Tối ưu đến mức nào đó nó sẽ thành giao thức FTP,...Cho nên nếu mục đích của bạn là tìm hiểu, luyện coding hoặc làm các ứng dụng nhỏ cá nhân thì dc, nhưng nếu muốn tốc độ ổn định thì nên nghĩ đến việc sử dụng các giao thức sẵn có.
Good luck!

boom_jt wrote:

...
5 cái hình thông thường (min) 5 kết nối (có thể nhiều hơn 5 nếu browser tạo ra nhiều kết nối để tải 1 file)
bạn có thể làm thử với việc đọc log, sẽ thấy liền

Còn tùy chế độ kết nối là Persistent hay không chứ !! Nếu Persistent thì request=5 nhưng số connection min có thể nhỏ hơn 5, 5 cái ảnh bình thường ở chế độ persistent chỉ chiếm khoảng 1-2 kết nối.

ken_shin wrote:

chà nếu giải thích như bạn thì có vẻ ko xài tướng lửa dc (hay mình hiểu sai nhỉ)
với firewall mình đặt giới hạn ko quá 10 kết nối trong 2 giây nếu vượt bị lock 900s nếu gặp bài viết khoảng 20 cái hình (mất ít nhất là 20 kết nối ) thì ip đó bị lock chắc rùi còn gì nhưng mình chưa thấy ai bị lock như vậy cả >> thông thường 1 diễn dàn có rất nhiều hình mà

Điều trên cũng giải thích tại sao Rule FW không bị vi phạm không ai bị lock, vì 10 kết nối là con số khá lớn. Quá kết nối thì deny create thêm thôi chớ sao lock 900s nhỉ, có lẽ người set rule cũng chỉ muốn tạo giới hạn phòng hờ thôi.

ASP.NET -> Edit Configuration ->authentication -> Authen mode = None
hoặc thêm (/sửa) <authentication mode="None" /> trong web.config
Good luck!

Nếu sửa regedit thất bại. Thử cài lại mấy driver ACPI compliant hoặc có chữ ACPI. vì nếu driver hư nó tưởng nhầm máy bạn xài nguồn AT.

Bạn đã cài Firewall rồi thì chắc ổn rồi, đóng mấy cổng linh tinh của SNMP và NETBIOS/TCP để ẩn mình.
Với arp sniffing: Có thể set mac tĩnh cho gateway bằng arp -s để chống sniff chiều đi ra, nhưng có thể bị phá chiều vào làm không nhận được gói tin trở về, để tránh bạn có thể đổi IP (nếu đã ẩn mình dc (mức IP) và mấy nhóc kia không vào dc modem).

114v wrote:

Mò mãi cũng đã nắm được 30%

Em muốn hỏi là sau khi mình tạo 1 thư mục bằng cách checkout, vậy giờ mình sẽ chỉnh sửa và viết trong thư mục đó hay là thư mục gốc của code. Trong thư mục checkout thường có .svn ẩn, vậy khi xuất bản mình phải xóa bằng tay những thư mục đó?

Chỉnh sửa và viết trong thư mục checkout. Khi xuất bản dùng chức năng export hoặc xóa tay (sau khi copy ra chỗ khác nếu kô sẽ mất thiết lập kết nối của checkout)

Code:

<html>
<body onload="alert((0.1234*300));alert((0.00005*300))"/>
</html>

Lạc đề rồi, session hijack mà.

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)

http://www.codeproject.com/KB/aspnet/IISTimer.aspx

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

Đoạn code có 1 số điểm yếu, trên phần if với GET thì kiểm tra độ dài input, phần else cho POST thì bỏ qua.
2 dòng check slash lại bỏ qua với $to
Code:

$to=strip_tags($_POST['to']);
$msg=strip_tags(stripslashes($_POST['msg']));
$subj=strip_tags(stripslashes($_POST['subj']));

Ngôn ngữ có auto type casting mềm dẻo quá thường dễ mắc lỗi hơn, nếu ngôn ngữ khác thì $num theo mong muốn sẽ không thể chứa chuỗi, $num++ sẽ bung lỗi.

Điểm yếu chung: asynchronous nên chậm, kích thước dữ liệu mang theo khiêm tốn, authoritative yếu (SMTP), một chiều (push đi-SMTP hoặc pull về POP-IMAP), thông tin không dc mã hóa.

Khắc phục:
Để hạn chế spammer, ngày nay open relay bị hạn chế (đưa vào black list); dùng SPMT-Auth để xác thực client.
Để hạn chế mất cắp ttin, hiện nay các server mail thường dùng TSL, hoặc SSL để bvệ an toàn ttin.

lion_king_lovely_1985 wrote:

Nguy cơ là khả năng lây lan virus khó kiểm soát và dễ dàng hơn với sử dụng webmail thông qua Browser!

Nguy cơ là dễ bị truy suất dữ liệu bất hợp pháp theo nhiều cách đơn giản hơn việc thông qua web browser!

Nguy cơ là dễ bị nhúng các mã lệnh hoặc trojan độc!

Và một số nguy cơ khác mà LKL do ít sử dụng, cũng như ngâm cứu về Mail nên chưa đi sâu hơn được!!!

Webmail chỉ là hình thức web app của mail client thôi, nó vẫn dùng các giao thức trên để gởi và nhận mail. Web mail có ưu điểm chính là giảm gánh nặng quản lý nội dung và lọc spam thay cho end-user, và cho phép dùng ở bất cứ đâu. Nhưng account mail có POP vẫn thường có giá trị hơn 1 account webmail (only).

lion_king_lovely_1985 wrote:

Có 2 điều:

Thứ 2: Cái câu bạn hỏi ấy! Nó dường như bao gồm hết 1 cơ số ko nhỏ kỹ thuật mạng rồi! ( Đấy là hiểu theo cách có đầu có đuôi. Còn nếu chỉ là truyền tay, làm và chạy thì cũng ko đến nỗi như tớ nói.)
Để tìm hiểu cái này, bạn cần phải tìm hiểu các điều sau mà mỗi từ khóa trong câu tớ viết cậu đều có thể tìm thấy trong Google.com ( ko bao gồm phần trong ngoặc đơn ). Ko ai đủ thời gian ngồi chỉ cho cậu từng chi tiết đâu. Đúng là chẳng bik bắt đầu từ đâu.

- Cách tự mình thiết đặt một server tại nhà ( Để có thể run được bộ Server game và server web )

- Cách cài đặt game Offline ( Offline ở đây ko phải là game stand alone mà là phương pháp cài các game online thành offline. Như Võ Lâm Offline chẳng hạn)

- Cách thiết lập websever ( Dành cho việc cung cấp, quản lý tài khoản...)

- Khi bạn đã run được game server và webserver, thì chỉ còn mỗi việc các client xác thực truy cập vào server của bạn nữa là bạn đã hoàn thiện 1 server game!

- Cách quản lý và xác thực giữa các client và server ( Tránh tình trạng bị nhòm ngó)

- Và quan trọng nhất vẫn là học cách quản lý!!!

Thân LKL!!!

Yêu cầu ở đây là mở cafe game internet mà đâu phải dựng game server đâu!
@hunghugo: Không phải là khó nhưng để hiểu rõ và quản lí tốt, bạn nên làm từng bước một thôi, nếu slượng trên 4 máy thì phải mua thêm switch/hub có số cổng tương đương
-Trước tiên là cắm dây mạng từ hub<>ADSL Router và hub <>các máy
-Chọn một máy cài đặt win, driver, game, chat soft và cấu hình cho hoàn chỉnh.(sẽ dùng để ghost ra toàn bộ các máy)
-Trên máy này Run->ipconfig /all chụp hình rồi đưa lên đây, sẽ có hướng dẫn tiếp.

VM_STI.EXE
File này thường nằm trong bộ setup driver của webcam chuẩn USB. Thường có size 40960 (thường nhất), 53248 bytes, 49152 bytes, 45056 bytes, 61440 bytes, 37552 bytes.
Hay chiếm CPU vô cớ. Một số virus hay mạo danh nó, đặc biệt là khi nằm trong \windows hoặc \windows\system32
File của bạn có kích thước 40960 byte nên chắc cũng ok.

Phía client có thể làm chủ cookie, bạn có thể dùng các trình quản lý cookie smilie

https://addons.mozilla.org/en-US/firefox/search?q=cookie&status=4
https://addons.mozilla.org/en-US/firefox/addon/3255