banner

[Rule] Rules  [Home] Main Forum  [Portal] Portal  
[Members] Member Listing  [Statistics] Statistics  [Search] Search  [Reading Room] Reading Room 
[Register] Register  
[Login] Loginhttp  | https  ]
 
Messages posted by: mfeng  XML
Profile for mfeng Messages posted by mfeng [ number of posts not being displayed on this page: 14 ]
 
Nên phân biệt URL và file path.
Unpack dll cũng tương tư như exe, chỉ chú ý thêm ở phần fix Relocation Table.
Topic phát triển nhanh quá! Mới từ xác thực bằng mật khẩu đã chuyển sang public key & out-of-band authentication rồi smilie

MrNothing wrote:

Xét protocol 4: lưu dãy H_user+ salt thì có đổ vỡ không? Như nhau thôi. ai có P thì cũng sinh ra được dãy H(P||salt). Ai có H(P||salt) thì cũng xác thực được client.
 


Khác chứ, người dùng thường có xu hướng dùng chung password cho nhiều hệ thống, một hệ thống để lộ pass của người dùng thì không được ảnh hưởng tới hệ kia smilie

StarGhost wrote:

Về mặt nguyên tắc, nắm được password của user không có nghĩa là chứng minh được đó là cái honest server, vì password là thứ dễ bị externalized nhất. Nói đến mutual authentication thì cách thức duy nhất được chấp nhận hiện nay là dùng public key cryptosystem.
 

Theo tớ thấy thì ngay cả cert dùng pub/privkey cũng có thể bị mất, có điều khó mất hơn password thôi: vì attacker sẽ phải nắm được "cái ta có" (là privkey) và "cái ta biết" (là passphrase).

Tóm lại chúng ta đang thảo luận về xác bằng mật khẩu sao cho an toàn, nghĩa là hệ thống hoạt động dựa trên một điểm tin cậy nào đó (ở đây là mật khẩu). Với pubkey cryptosystem, điểm tin cậy là pub/privkey là câu chuyện khác.

Protocol 3 có vấn đề là phải lưu password plain-text ở phía host. Cái này hơi bị nguy nếu host đổ vỡ.

Protocol tớ dùng như thế này:

Protocol 4.

Code:
Host lưu trong database H_usr = H(P || salt) & salt.


Code:
1. User gửi ID.
2. Host sinh nonce, gửi cho client. nonce || salt.
3. Client gửi lại X = H( H(P || salt) || nonce).
4. Host tính X1 = H(H_usr || nonce) và so sánh với X. Nếu giống nhau tiếp tục bước 5. Nếu sai chuyển sang bước 7.
5. Host gửi cho user một session_id. M = E(H_usr || nonce ,session_id).
6. User nhận được M, giải mã lấy ra session_id = D( H(P||salt) || nonce, M).
7. Host thông báo lỗi cho usr, yêu cầu làm lại.
Mục tiêu của quá trình authentication trên là để lấy session_id. Nên nếu 2 protocols trên mà gửi session_id dạng plain-text thì ai kiểm soát đường truyền có thể dùng tiếp session_id này trong khi client chưa logout.

Protocol 2: vẫn bị replay attack.

@starghost: tớ chưa hiểu ở protocol 3 mà không có mutual authentication thì sẽ bị nguy cơ gì? Bên client và server xác lập sự tin cậy dựa trên một share secret (là password). Giả sử rằng password này không để bên thứ ba biết, thì protocol 3 đã đảm bảo an toàn rồi.

PS: Web cũng dùng được chứ nhỉ? Tớ thấy AJAX có thể hỗ trợ cái này đấy chứ ?

Nếu host dùng Apache thì tham khảo về .htaccess.

Hoặc tạo một file mặc định như index.htm, index.html để trong thư mục đó.
Vấn đề choc_ nói nằm ở chỗ VN chưa có một cơ quan chính thức chuyên ngành có trách nhiệm đưa ra các tiêu chuẩn an toàn thông tin (một dạng tương tự của NIST). Văn bản ở trên xuất phát từ một cơ quan hành chính công thông thường, vì thế người tư vấn kĩ thuật thường khó có đủ năng lực và tầm nhìn để viết một tài liệu kĩ thuật đủ tốt.
Nên tham khảo các patterns trong OOP khi viết chức năng Undo, mã nguồn chương trình sẽ dễ quản lý và "đẹp" hơn, dễ bổ sung, nâng cấp hơn smilie

Ví dụ: trừu tượng hóa các hành động vẽ một vật thể thành một giao diện, mỗi hành động cụ thể cần được triển khai rõ sau. Mỗi khi thực hiện vẽ vật thể nào đó, tạo một đối tượng hành động tương ứng cho vào stack. Khi cần undo thì truy xuất stack này và thực hiện "ngược" lại hành động đó. Để thực hiện "ngược" được dễ dàng bạn cần tổ chức dữ liệu (bản vẽ, dữ liệu của các hành động..) cho tốt.
Góp ý một tẹo smilie
- Bạn (và công ty) cần đề ra các quy định (policies) về an toàn thông tin cho công ty. Các trường hợp mang laptop cá nhân vào và truy câp trái phép ... nếu bị phát hiện sẽ chịu trách nhiệm nào đó.

- Do không nói rõ "vùng giới hạn" ở đây là cái gì, nên không thể góp ý cụ thể được. Tuy nhiên triển khai access control dựa trên MAC và IP không phải là giải pháp vững chắc. Bạn nên xem xét tới một số cơ chế khác như resource sharing (Samba, AD), authentication proxy, firewall...
Tớ thấy trên CentOS, /usr/bin/crontab vẫn được user bình thường sử dụng vì có có bit SUID, owner của file là root. smilie
Tớ dịch trên CentOS, gcc-4.x thì đúng có hiện tượng trên, chương trình bị lặp không thoát được.

Disassemble bằng gdb thấy có đoạn này:
Code:
mov 0xfffffffc(%ebp),%eax ;lấy giá trị n từ bộ nhớ ra thanh ghi eax.
.... ; thực hiện đọc 1 byte từ str & copy sang buffer.
addl $0x1, 0xfffffffc(%ebp) ; tăng giá trị nằm trong vùng nhớ n lên 1 & so sánh
cmp $0x64, 0xfffffffc(%ebp)
jle ...

Stack của hàm weird_print ở đây nó thế này:
buffer[0-100]: từ [ebp-0x68] đến [ebp-0x05];
n: bắt đầu từ [ebp-0x04].

Khi ghi vào byte thứ 100 (ebp-0x04), vùng nhớ này trùng với địa chỉ của n nên giá trị n bị ghi đè.

Tuy nhiên, điều lý thú lại như thế này, tớ viết thêm 2 dòng code in địa chỉ của n & buffer[100]:
Code:
void weird_print(char *str)
{
char buffer[100];
int n=0;
printf("Address of n:%p\n",&n);
printf("Address of buffer[100]:%p\n",&buffer[100]);
for (n=0; n<=100;n++)
buffer[n]=str[n];
printf("%s\n", buffer);
}


Thì đoạn code kiểm tra điều kiện <=100 nó lại như sau:
Code:
mov 0xffffff98(%ebp), eax
....
[color=red]add $0x1, %eax
mov %eax, 0xffffff98(%ebp)
mov 0xffffff98(%ebp), %eax[/color]
cmp $0x64, %eax
jle ....

Stack map có thứ tự như sau:
n: [ebp-68];
buffer[0-100]: [ebp-64]

Vì thứ tự biến bị thay đổi trên stack, n đứng dưới buffer nên n không thể bị ghi đè. Nếu giả sử stack vẫn như cũ thì cũng không bị ghi đè bới hai dòng code màu đỏ ở trên. Vì thế chương trình không bị loop nữa smilie.
Mặc định /root đặt quyền 750, nên với user thường không có quyền x(execute), không thể đọc file nằm trong /root được.
Nếu biết rõ format của chuỗi "Date Time", bạn có thể phân tách ("parse") ra CTime được. Vd, 29/11/2008: tách chuỗi làm 3 thành phần theo token "/", trong đó thành phần đầu tiên là ngày, tiếp theo là tháng và cuối cùng là năm.
Tài liệu lập trình C với My SQL, xem http://dev.mysql.com/doc/refman/5.0/en/c.html.

http://www.ucl.ac.uk/is/mysql/c/ truy vấn dữ liệu từ MySQL.

Có một số thư viện C++ đóng gói các hàm API của MySQL cho dễ dùng hơn, ví dụ: http://tangentsoft.net/mysql++/
Tài liệu về crack WPA TKIP xem http://dl.aircrack-ng.org/breakingwepandwpa.pdf
 
Go to Page:  First Page Page 1 3 4 5 Page 6 Last Page

Powered by JForum - Extended by HVAOnline
 hvaonline.net  |  hvaforum.net  |  hvazone.net  |  hvanews.net  |  vnhacker.org
1999 - 2013 © v2012|0504|218|