Messages posted by: beta14

Theo hiểu biết sơ qua thì mình thấy có những kiểu làm auto game như sau:
I) Theo hành động thực: Tức giả lập các động tác của máy như có người ngồi thật là nhấn chuột, nhấn phím, vân vân...
II) Quản lý bộ nhớ: Mọi thao tác của chương trình trong máy tính đều cần phải lưu vào bộ nhớ máy tính. Mỗi hành động, thao tác của nhân vật trong game đều có liên hệ với bộ nhớ. Khi có sự can thiệp vào bộ nhớ thì đồ hoạ tương tác của nhân vật trong game sẽ đổi theo tương ứng.
III) Can thiệp mạng: Game online đều phải trao đổi dữ liệu giữa máy người chơi và máy chủ. Đây là tầng cuối trong trao đổi thông tin giữa người dùng với game và máy chủ.

Kiểu (I) về dễ lại vừa khó nhưng hiệu quả lại không cao vì thường chỉ có thể giả lập thao tác cho 1 cửa sổ.
Kiểu (II) là kiểu thông dụng nhất, hiệu quả cao nhất nhưng phải bỏ nhiều chất xám hơn nếu game tự tạo môi trường virtual machine để chạy game nhằm mục đích bảo mật.
Kiểu (III) chỉ dễ với nhưng game nửa mùa, bảo mật kém. Đa số các dữ liệu trao đổi đều được mã hoá nên cũng không nhiều người lựa chọn.

Tóm lại kiến thức cần có:
- Am kiểu API của HĐH về hook, quản lý bộ nhớ, đa số là Windows API, game Linux hay MacOS chỉ đếm trên đầu ngón tay. Có một thông tin thú vị là bộ tài liệu Win32 API do Microsoft phát hành khi in hết ra nặng tới 363 kilograms.
- Vì vậy, ngôn ngữ thì chắc chắn phải là những ngôn ngữ do Microsoft phát triển và hỗ trợ: C, C++, Visual Basic, C#... Nói chung là nó có khả năng giao tiếp được với Win32 API.

P.S: Những vấn đề này mà hỏi bác conmalele thì chỉ nhận được cái gì đó có vẻ kiểu như những guru master tu hành bên Ấn Độ giảng đạo về điều thần bí nào đó mà sau đó người hỏi phải tự xử smilie

Cách của bạn nguyenbinh07 hay vậy mà bạn tmd còn ý kiến gì nữa? Hay là do không hiểu cái tut bạn nguyenbinh07 đã hướng dẫn?

Cách này mình thấy rất hay, hình như nó thuộc kiểu Social engineering hacking phải không ta.

conmale wrote:

beta14 wrote:

conmale wrote:

----> khắc phục cái rễ, đừng khắc phục cái ngọn. Khắc phục bảo mật cho 1 và 2.

Trả lời kiểu đánh đố này thì chẳng khác nào khi muốn quan hệ tình dục với phụ nữ nào đó thì nên check rồi xử virus HIV có trong máu chứ dùng BCS thì có mà bị lòi rễ Bác này chắc chưa hiểu đạo lý sống: "Sống chung với lũ" là như thế nào hoặc như người Nhật: "Sống chung với động đất"

Tôi chẳng đánh đố, tôi chẳng trả lời mà tôi chỉ khuyên bạn. Việc bạn so sánh điều tôi khuyên bạn với chuyện quan hệ tình dục hay đạo lý 'sống chung với lũ' gì gì đó hoàn toàn lạc đề.

Bạn đưa ra vấn đề như thể làm thế nào để đừng cho thằng ăn trộm chôm đồ của mình sau khi nó đã vào được trong nhà và cầm trong tay một chùm chìa khóa có thể mở tất cả các tủ vậy. Đây là chuyện buồn cười. Bạn nên nghĩ đến chuyện làm sao không cho thằng ăn trộm vào nhà chớ đừng nghĩ đến chuyện nó đã vào nhà rồi thì làm gì.

Có lẽ bạn đang tạo ra một chuỗi truyện cười, hay do bạn cố tình không hiểu? Hơn 95% các doanh nghiệp là nhỏ và vừa, cũng gần bằng đó số người dân phải sống nhà thuê chứ không phải nhà riêng của họ, ngay cả khi bạn dẫn gái vào thuê phòng trong khách sạn thì căn phòng đó cũng chưa hẳn đã là của riêng bạn để giữ kín dữ liệu nhảy cảm của mình. Không biết với những ví dụ như vậy thì bạn có hình dung được cái case mà tôi muốn bàn đến?

myquartz wrote:

Mình đoán rằng mong muốn của bạn là bạn bị cướp quyền admin của MySQL, nhưng các file code không bị làm sao (có thể bị xem nhưng không thể thay đổi).
Và bạn muốn đảm bảo rằng DB của bạn phải toàn vẹn, mới cho phép truy cập.
Cái này nói chung là không quá khó, nhưng sẽ tốn thêm công và tất nhiên hệ thống sẽ chậm đi. Ví dụ bạn có thể áp dụng chữ ký điện tử vào DB, có thêm 1 cột chứa digital signature của các field còn lại. Trong code có mã kiểm tra chữ ký + public key để check có hợp lệ hay không, để biết bản ghi đó có bị thay đổi hay ko hợp lệ...
Việc tạo chữ ký thì là offline, private key bạn giữ tại client, mỗi khi có update row thì phải thực hiện việc ký lại các field đó tại client và update lại cột chữ ký.
Như vậy, nếu có ai đó thay đổi dữ liệu, chữ ký ko match thì ko còn vào được nữa. Tất nhiên code không bị thay đổi nên attacker không thể bypass việc check đó.
Việc này chỉ chống được có thế, chứ nếu attacker drop luôn các bảng của bạn, hệ thống ko xài được nữa, thì ... nói chung hậu quả có thể vẫn đáng kể.
Cách này người ta thường áp dụng cho 1 số giao dịch tài chính ngân hàng, để đảm bảo toàn vẹn của dữ liệu giao dịch sinh ra trong hệ thống (nghĩa là hacker không thể sinh ra giao dịch giả mạo, tác giả sinh GD là ai thì sẽ có chữ ký tương ứng xác nhận)

Đúng quá. Đây là cái mình đang muốn thảo luận nhưng có tính chất cây nhà lá vườn hơn chứ không có ý định phải làm cả 1 hệ thống đồ sộ như Paypal, MoneyBookers...

conmale wrote:

----> khắc phục cái rễ, đừng khắc phục cái ngọn. Khắc phục bảo mật cho 1 và 2.

Trả lời kiểu đánh đố này thì chẳng khác nào khi muốn quan hệ tình dục với phụ nữ nào đó thì nên check rồi xử virus HIV có trong máu chứ dùng BCS thì có mà bị lòi rễ smilie

Bác này chắc chưa hiểu đạo lý sống: "Sống chung với lũ" là như thế nào hoặc như người Nhật: "Sống chung với động đất"

Theo tôi tìm hiểu thì các dịch vụ upload ảnh dùng static server để lưu file. Cái này hình như là một phần lỗi cấu hình mặc định của Apache 1.x, 2.x đã sửa rồi. Có làm kiểu: *.php.gif hay chèn mã php vào file ảnh cũng chẳng khai thác được gì.

Hết cao thủ rồi sao? Không dám múa rìu qua mắt thợ.

Mọi người đang nói đi đâu vậy? Tôi đang bàn đến cái khó về cơ sở hạ tầng, không phải ai cũng có server, VPS riêng nên mới bị local attack. Hoặc nếu có server riêng, nhưng có thể bị sơ hở ở chỗ nào khác trên server như: 1 server có nhiều site, site X nào đó bị lỗ hổng...

Giải pháp bạn đưa ra khá flexible , nhưng bạn lại chưa hiểu vấn đề chính mà tôi muốn đưa ra. Thay đổi user_auth chỉ là 1 ví dụ nhỏ, như bạn đã nêu, tính toàn vẹn phải được giữ để nếu có bị thay đổi username hoặc password thì cũng không thể chiếm được tài khoản cấp cao.

Ví dụ như tôi thấy forum hva có tài khoản tên là quanlytruong. Nếu ngày nào đó MySQL bị lỗi có thể bị khai thác. Với cấu trúc database của JForum thì hoàn toàn có thể chiến tài khoản cấp cao đó để phá hoại forum. Vậy người modify JFroum cho HVA có đảm bảo được tính toàn vẹn đó không?

Cách này mình cũng đã nghĩ đến, nhưng nó khá thiển cận và không bao quát nếu: site có nhiều admin, ngoài ra còn có super mod và mod...

Chào mọi người.

Mình đang tập làm 1 module bảo mật cho dữ liệu chứa trong MySQL và chạy bằng PHP.

Dữ liệu:
1) Có bảng chứa tài khoản người dùng: USERS bao gồm: user_id, user_name, user_pass, user_auth...
2) Bảng AUTH chứ danh sách cấp bậc của USERS: auth_id, auth_type, user_id,....

Vấn đề đặt ra là:
1) Có người xâm nhập vào MySQL như bị local attack
2) Người này sửa user_auth của user nào đó thành 1, tức thành Quản trị

Giải pháp nào cho:
1) Có thể bị mất database, bị sửa MySQL trái phép từ ngoài.
2) Tuy nhiên, nếu sửa lại user_auth thành Quản trị thì cũng không được gì.

Ở trường hợp này, tính toàn vẹn của dữ liệu trong bảng đã không hợp lệ. Vậy có giải pháp nào để đảm bảo tính toán vẹn đó?

Thân chào.