<![CDATA[Latest posts for the topic "Bảo đảm toàn vẹn dữ liệu"]]> /hvaonline/posts/list/8.html JForum - http://www.jforum.net Bảo đảm toàn vẹn dữ liệu 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.]]> /hvaonline/posts/list/33310.html#204957 /hvaonline/posts/list/33310.html#204957 GMT Bảo đảm toàn vẹn dữ liệu /hvaonline/posts/list/33310.html#204973 /hvaonline/posts/list/33310.html#204973 GMT Bảo đảm toàn vẹn dữ liệu /hvaonline/posts/list/33310.html#204982 /hvaonline/posts/list/33310.html#204982 GMT Bảo đảm toàn vẹn dữ liệu /hvaonline/posts/list/33310.html#205027 /hvaonline/posts/list/33310.html#205027 GMT Bảo đảm toàn vẹn dữ liệu /hvaonline/posts/list/33310.html#205036 /hvaonline/posts/list/33310.html#205036 GMT Bảo đảm toàn vẹn dữ liệu /hvaonline/posts/list/33310.html#205048 /hvaonline/posts/list/33310.html#205048 GMT Bảo đảm toàn vẹn dữ liệu

beta14 wrote:
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ó phải bạn hỏi là: Không được thay đổi cấu trúc, dữ liệu từ phpMyAdmin ? Nếu đúng thì vấn đề của bạn là bất khả thi vì một khi đã vào được phpMyAdmin thì mọi cái đều có thể rồi. Cái chính là cái account đăng nhập vào phpMyAdmin là loại nào thôi. Còn nếu người chiếm quyền biết khá chi tiết về cái db đó thì mọi việc lại càng dễ dàng. Thân :) ]]>
/hvaonline/posts/list/33310.html#205099 /hvaonline/posts/list/33310.html#205099 GMT
Bảo đảm toàn vẹn dữ liệu /hvaonline/posts/list/33310.html#205115 /hvaonline/posts/list/33310.html#205115 GMT Bảo đảm toàn vẹn dữ liệu /hvaonline/posts/list/33310.html#205128 /hvaonline/posts/list/33310.html#205128 GMT Bảo đảm toàn vẹn dữ liệu /hvaonline/posts/list/33310.html#205453 /hvaonline/posts/list/33310.html#205453 GMT Bảo đảm toàn vẹn dữ liệu 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...   thành một vấn đề... như vậy có lẽ sẽ nhiều người comment hơn Thân wd.]]> /hvaonline/posts/list/33310.html#205472 /hvaonline/posts/list/33310.html#205472 GMT Bảo đảm toàn vẹn dữ liệu /hvaonline/posts/list/33310.html#205497 /hvaonline/posts/list/33310.html#205497 GMT Bảo đảm toàn vẹn dữ liệu

beta14 wrote:
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. 
----> 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.]]>
/hvaonline/posts/list/33310.html#205520 /hvaonline/posts/list/33310.html#205520 GMT
Bảo đảm toàn vẹn dữ liệu

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. 
Em tưởng bác nói ngọng, khắc phục cái dễ... Bác nên nói là: "khắc phục cái gốc, đừng khắc phục cái ngọn". Ôi tiếng Việt.]]>
/hvaonline/posts/list/33310.html#205626 /hvaonline/posts/list/33310.html#205626 GMT
Bảo đảm toàn vẹn dữ liệu

myquartz 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. 
Em tưởng bác nói ngọng, khắc phục cái dễ... Bác nên nói là: "khắc phục cái gốc, đừng khắc phục cái ngọn". Ôi tiếng Việt. 
Cám ơn bồ. Tôi hiểu là "rễ" ở đây chính là "gốc rễ" (root trong tiếng Anh). Tôi chưa hề nói ngọng bao giờ :P .]]>
/hvaonline/posts/list/33310.html#205665 /hvaonline/posts/list/33310.html#205665 GMT
Bảo đảm toàn vẹn dữ liệu

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ễ :| :| :| 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"]]>
/hvaonline/posts/list/33310.html#206351 /hvaonline/posts/list/33310.html#206351 GMT
Bảo đảm toàn vẹn dữ liệu

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ì.]]>
/hvaonline/posts/list/33310.html#206353 /hvaonline/posts/list/33310.html#206353 GMT
Bảo đảm toàn vẹn dữ liệu

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?]]>
/hvaonline/posts/list/33310.html#206525 /hvaonline/posts/list/33310.html#206525 GMT
Bảo đảm toàn vẹn dữ liệu /hvaonline/posts/list/33310.html#206530 /hvaonline/posts/list/33310.html#206530 GMT Bảo đảm toàn vẹn dữ liệu

beta14 wrote:

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? 
Bạn mang chuyện "dẫn gái vào khách sạn" ở đây là khập khiễng rồi. Việc bạn muốn nêu ra là trong tình huống bạn dùng share hosting và dùng chung CSDL nên có thể bị thâm nhập hoàn toàn khác với tình huống bạn "dẫn gái vào khách sạn". Nếu cần so sánh, bạn nên so sánh với hoàn cảnh bạn thuê chung một cửa hàng và dùng chung kho chứa hàng với những người khác. Trong tình huống ấy, bạn ngại rằng có người nào đó vào kho chứa hàng và chôm hàng của bạn thì có lý. Với hoàn cảnh dùng chung kho chứa hàng như trên, bạn đang tìm cách khóa từng bao hàng lại bằng các ổ khóa riêng của mình (khóa các database tables) nhưng chủ nhà hàng và kho hàng có chiếc chìa khóa vạn năng nên muốn mở cái gì ra cũng được. Bởi thế, bạn lay hoay làm một việc vô ích. Đi sát vào ví dụ trên CSDL của bạn, bạn bảo:
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ì.  
Điều bạn cần hiểu là chức năng của CSDL (A) là cái gì và chức năng của ứng dụng nào đó (B) truy vấn vào CSDL để lấy dữ liệu là gì. Khi một thông tin nào đó được thay đổi trên cơ sở dữ liệu (A) nhưng ứng dụng (B) không hề biết và ứng dụng (B) chỉ có thể đọc và sử dụng dữ liệu có sẵn trên (A) để thực thi một công tác nào đó thì (A) cung cấp cái gì, (B) sẽ dùng cái nấy. Nếu user_auth bị thay đổi và (B) đọc thông tin đã thay đổi này thì nó sẽ thực hiện công tác y hệt như những gì (A) đã cung câp (với thông tin đã thay đổi). Bởi thế, việc quan trọng là làm sao không cho ai đó hoặc một cơ chế nào đó vào AUTH để thay đổi giá trị user_auth chớ không phải là việc làm gì nếu user_auth đã bị thay đổi. Nếu bạn muốn tạo một lớp kiểm nghiệm chặt chẽ, bạn không thể đơn thuần buộc (B) dùng những gì nó truy vấn và lấy được từ (A) cho giá trị user_auth mà bạn nên buộc (B) phải kiểm chứng nhiều dữ kiện khác trước khi thực thi authorisation. Ví dụ, ngoài giá trị user_auth lấy được, bạn có thể xét xem user_id ấy thuộc những group nào, đã được áp dụng giá trị "1" từ khi nào, đã được ai chấp nhận... những thông tin này thuộc về những bảng khác trong CSDL và càng nhiều dữ kiện được dùng để kiểm chứng thì tính bảo mật của nó càng cao. Nếu chỉ dựa vào một dữ kiện "user_auth" để đi đến quyết định thực thi authorisation thì logic và tính bảo mật của ứng dụng (B) quá kém. Ngay cả áp dụng nhiều dữ kiện khác để kiểm nghiệm giá trị xác thực của user_id ấy đi chăng nữa, nếu ai đó đã có thể có quyền truy cập vào CSDL và thực thi các SQL statements thì rào cản này bị phá vỡ. Cách chặt chẽ hơn một tí là giá trị user_auth không phải là 1, 2 hoặc 1 INT đơn giản nào đó mà có thể là một chuỗi hash. Chuỗi hash này được tạo ra từ tổng hợp các dữ kiện quyết định user_id này có chủ quyền nào đó. Khi (B) query user_auth và lấy được chuỗi hash, B phải thu thập các dữ kiện cần thiết để tạo ra một chuỗi hash khác rồi so sánh với giá trị lấy được từ CSDL (A). Nếu hai giá trị hash này trùng khít thì user_id ấy mới được authorised. Một kẻ nào đó thâm nhập nếu không nắm được logic tạo hash từ các dữ kiện cần thiết thì hắn khó lòng tạo ra một hash tương thích để nâng chủ quyền cho user_id được. Tất nhiên, những ứng dụng nào hoàn toàn thuộc về (B) chớ không thuộc về (A). (A) chỉ là CSDL và nó chỉ chứa dữ liệu không hơn không kém. PS: không nên tỏ thái độ hằn học khi ai đó góp ý cho mình. Đặc biệt khi mình chưa có đủ tầm nhìn để hiểu sự việc một cách bao quát.]]>
/hvaonline/posts/list/33310.html#206541 /hvaonline/posts/list/33310.html#206541 GMT
Bảo đảm toàn vẹn dữ liệu /hvaonline/posts/list/33310.html#208472 /hvaonline/posts/list/33310.html#208472 GMT Bảo đảm toàn vẹn dữ liệu /hvaonline/posts/list/33310.html#208473 /hvaonline/posts/list/33310.html#208473 GMT Bảo đảm toàn vẹn dữ liệu

stylish_man wrote:
Ah không "chú" comale chứ.( Nên tôn trọng và học hỏi kinh nghiệm từ những người "lớn tuổi" :) ) 
Tuổi tác gì đây bồ? Nếu quan trọng chuyện tuổi tác mà đưa "chú" và "lớn tuổi" vào ngoặc kép thì phản tác dụng rồi.]]>
/hvaonline/posts/list/33310.html#208477 /hvaonline/posts/list/33310.html#208477 GMT
Bảo đảm toàn vẹn dữ liệu /hvaonline/posts/list/33310.html#208485 /hvaonline/posts/list/33310.html#208485 GMT