Là che khuất / che giấu các id cơ sở dữ liệu đối mặt với công chúng có thực sự là một thực tiễn tốt nhất của Google không?

Tôi đã nghe mọi người giảng bài ở đây và trên internet rằng đó là cách tốt nhất để che khuất các id cơ sở dữ liệu đối mặt công khai trong các ứng dụng web. Tôi cho rằng chúng chủ yếu có nghĩa là trong các hình thức và trong các url, nhưng tôi chưa bao giờ đọc bất cứ điều gì nhiều hơn một câu nói về chủ đề này.

EDIT : Tất nhiên, bây giờ khi tôi hỏi điều này, tôi tìm thấy một số tài nguyên về chủ đề này:

• /programming/2374538/obscuring-database-ids
• /programming/1895685/should-i-obscure-primary-key-values
• http://joshua.schachter.org/2007/01/autoincrement.html

Các liên kết này thỏa mãn một số sự tò mò của tôi, nhưng các bài đăng SO không có nhiều phiếu bầu và không nhất thiết tập trung vào chủ đề trong bối cảnh này vì vậy tôi không chắc nên làm gì và một số trong số họ cho rằng thứ ba liên kết là không có thật. Tôi sẽ để nguyên phần còn lại của bài viết của mình:

Tôi hiểu sự khác biệt giữa tối nghĩa và bảo mật, cũng như cách hai người có thể làm việc cùng nhau, nhưng tôi không thể tưởng tượng được tại sao điều này lại cần thiết.

Có bất kỳ sự thật nào về điều này, nó chỉ là hoang tưởng, hay nó hoàn toàn không có thật?

Tôi có thể nghĩ ra cách để làm điều đó, nhưng tất nhiên nó làm tăng thêm sự phức tạp cho mã ứng dụng. Trong hoàn cảnh nào điều này sẽ hữu ích? Nếu đây là điều mọi người thường xuyên làm, nó thường được triển khai như thế nào? Băm các định danh? Thứ gì khác? Có vẻ như rất nhiều công việc không bảo mật nhiều. Tôi không tìm kiếm giải pháp thực sự, tôi chỉ muốn biết một lý do tại sao mọi người sẽ làm điều này trong thế giới thực.

Đây thực sự được coi là một "thực tiễn tốt nhất" hay nó chỉ là một tối ưu hóa vi mô có giá trị nhỏ?

LƯU Ý : Tôi nghĩ rằng một vài người có thể đã hiểu sai: Tôi không cho rằng các id khó đoán sẽ là cơ chế bảo mật duy nhất , rõ ràng sẽ có các kiểm tra truy cập thông thường. Giả sử những cái đó được đặt đúng chỗ và chỉ cần biết id hoặc mã băm của bản ghi là không đủ để cấp quyền truy cập.

Tôi không nghĩ nó quan trọng, nhưng có một số tình huống có thể quan trọng tùy thuộc vào các quyết định khác của bạn.

Ví dụ: nếu bạn để lộ ID đơn hàng được tạo liên tục và bạn đã có một cuộc tấn công kỹ thuật xã hội với ai đó gọi hỗ trợ khách hàng và nói "này, tôi vừa chi 2000 đô la cho một máy tính mới và các bạn đã gửi cho tôi một số đơn đặt hàng của anh chàng khác một cáp 15 đô la, bây giờ tôi đã hết 2000 đô la ", bạn có thể dành nhiều thời gian để cố gắng kiểm tra vấn đề trước khi kết luận đó là không có thật hoặc bạn gửi cho kẻ giả mạo một máy tính mới.

Có những biến thể tương tự, ít tinh vi hơn, nhưng đáng xấu hổ về chủ đề; nếu kẻ xấu tăng ID đơn hàng, liên kết được gửi qua email đến biên nhận và nếu không có xác nhận bổ sung nào được thực hiện để xác minh rằng người nhấp vào liên kết có quyền xem ID đơn hàng, đột nhiên bạn vô tình tiết lộ thông tin khách hàng cá nhân đến nhầm người.

Trong những trường hợp như vậy, nếu các con số không tuần tự, sự phơi nhiễm sẽ được giảm nhẹ một chút vì đoán ít có khả năng mang lại kết quả thú vị. Mặt khác, bây giờ bạn cần một cách thuận tiện để tham chiếu ID đơn hàng trong các tương tác hỗ trợ khách hàng sẽ không dẫn đến các cuộc trò chuyện qua lại với các tương tác khách hàng dựa trên điện thoại trong khi đại diện của bạn cố gắng phân biệt giữa B, PD và T theo số thứ tự BPT2015D.

Tôi muốn nói rằng đây là một sự căng thẳng để gọi sự xáo trộn này là "thực tiễn tốt nhất", nhưng trong một số trường hợp nhất định, nó có thể làm giảm sự dễ dàng khai thác điểm yếu khác trong mã xác thực hoặc mã ủy quyền của bạn. Mặt khác, việc ai đó biết bạn đã viết bài đăng trên blog số 1 hay # 2559 không thực sự quan trọng. Nếu ID không phải là thông tin có giá trị, ngay cả với kiến ​​thức bổ sung, thì lập luận che giấu nó là một cách thực hành tốt nhất giữ trọng lượng ít hơn.

Có một đối số tiềm năng thứ hai, đó là định danh cơ sở dữ liệu của bạn có thể đưa bạn đến một triển khai cơ sở dữ liệu cụ thể (hoặc ví dụ) và khi công ty của bạn được mua hoặc chọn một đối thủ cạnh tranh và bây giờ bạn phải hợp nhất hai hệ thống cũ hoặc Giám đốc điều hành đi uống với đại diện từ DynoCoreBase và họ quyết định rằng bây giờ bạn sẽ chuyển tất cả dữ liệu của mình sang DynoCoreBase phiên bản 13h và nó muốn tất cả các khóa chính là hướng dẫn và bạn phải tạo một loại lớp ánh xạ để dịch ID cũ sang mới ID để các URL cũ không bị hỏng, nhưng liệu các kịch bản này có quan trọng với bạn hay không phụ thuộc nhiều vào bản chất doanh nghiệp của bạn (và sự liên quan của khách hàng với các ID đó) so với bất kỳ thông lệ tốt nhất chung nào.

Đây là quan điểm của tôi về nó:

Mặc dù "bảo mật thông qua che khuất" rõ ràng là không đủ, nhưng tối nghĩa có thể hỗ trợ bảo mật, dù chỉ là một chút. Bạn phải quyết định xem một chút bảo mật psuedo đó có xứng đáng với nỗ lực bổ sung cần có để triển khai một cái gì đó như thế này trong ứng dụng của bạn hay không.

Có một lý do khác ngoài bảo mật mà tôi có thể nghĩ ra để thực hiện điều này:

Riêng tư

Giả sử chúng ta đang xử lý id người dùng trong url. Nếu id người dùng của Joe là 100và id người dùng của Bob là 101, có lẽ rõ ràng tài khoản của Joe đã được tạo trước tiên. Mặc dù điều này có thể không quan trọng trong hầu hết các ứng dụng, nhưng nó có thể quan trọng đối với một số người. Đây là một ví dụ về quyền riêng tư nghiêm ngặt thông qua che khuất, vì vậy trừ khi bạn có một hệ thống rất khó hiểu về id người dùng, có thể dễ dàng hòa tan và tìm hiểu xem người dùng có id 3Js9kW3hTs7sa120có tài khoản lâu hơn người dùng có id hay không Q8Hs73kks0hEg.

Từ liên kết tôi đã tham khảo:

Đầu tiên là đưa ra URL cho một số đối tượng, bạn có thể tìm ra các URL cho các đối tượng được tạo ra xung quanh nó. Điều này cho thấy số lượng đối tượng trong cơ sở dữ liệu của bạn cho các đối thủ cạnh tranh hoặc những người khác mà bạn có thể không muốn có thông tin này (như đã được minh chứng bởi các đồng minh đoán mức sản xuất xe tăng của Đức bằng cách xem các số sê-ri.)

Việc sử dụng id tăng tự động sẽ hiển thị công khai số lượng đối tượng trong cơ sở dữ liệu và có thể hiển thị những đối tượng nào được tạo trước và đối tượng nào mới hơn. Thông tin này có thể cho đi một thực tế rằng một doanh nghiệp là mới, hoặc thậm chí không hoạt động tốt. Ví dụ: giả sử bạn đặt một cuốn sách và id đơn hàng của bạn là 1. Có thể rõ ràng là đơn đặt hàng của bạn là đơn hàng đầu tiên trong hệ thống, có thể không đáng tin cậy. Giả sử bạn quay lại và đặt hàng khác và id đơn hàng của bạn là 9. Điều này cho biết thông tin chỉ có 7 đơn hàng được đặt trong khung thời gian giữa hai đơn hàng của bạn. Đây có thể là thông tin có giá trị cho các đối thủ cạnh tranh. Trong trường hợp này, id tăng tự động số có lẽ tốt hơn là bị xáo trộn.

Từ "tối nghĩa" có lẽ hơi sai lệch ở đây, và, có thể khiến mọi người nghĩ "che giấu" hoặc "che giấu một phần".

Đề xuất là bạn không bao giờ bao gồm bất kỳ khóa cơ sở dữ liệu được tạo nội bộ nào như một phần của URL công khai nếu các bản ghi cơ sở dữ liệu này chứa bất kỳ dữ liệu nhạy cảm nào.

Nó quá dễ để chơi với các số trong URL và truy cập các bản ghi khác.

Tôi sẽ đi ngược lại dòng chính, và nói với bạn rằng sử dụng một định danh dài, ngẫu nhiên theo ý kiến ​​của tôi là một hình thức bảo mật khá tốt.

Nó phải được làm rõ cho bất cứ ai có quyền truy cập vào dữ liệu đó rằng nó nhạy cảm như mật khẩu. Và tất nhiên nó có nhược điểm là nếu đi vào tự nhiên thì có thể khó thay đổi hơn.

Nhưng nó có một vài lợi thế so với cặp tên người dùng và mật khẩu thông thường. Đầu tiên, người dùng không có lựa chọn nào khác, vì vậy bạn có thể chắc chắn rằng về cơ bản là không thể đoán được. Không có điểm nào trong việc thiết kế một trang web hoàn toàn an toàn khi quản trị viên chọn tên của nó làm mật khẩu. Thứ hai, mỗi mục có một định danh khác nhau, vì vậy nếu một mục có quyền truy cập vào một mục, điều này không giúp ích gì cho mục kia.

Tất nhiên, càng có nhiều lớp bảo mật thì càng tốt. Nhưng riêng phương pháp này có thể an toàn hơn một vài thông tin đăng nhập.

Có hai khía cạnh này: tính khả dụng và bảo mật.

ID bảo mật, che khuất là khá vô nghĩa; Điều quan trọng là ID không bao giờ phải là 'chìa khóa' duy nhất cho bất kỳ tài nguyên ngoài công cộng nào. Điều này có nghĩa là nếu bạn muốn cung cấp cho người dùng được chọn quyền truy cập vào một trang nhất định, chỉ cần yêu cầu ID của trang trong URL là không đủ, bạn phải thực hiện một cơ chế bảo mật thực tế như đăng nhập tên người dùng / mật khẩu hoặc xác thực khóa công khai / riêng tư, cũng như ủy quyền thích hợp (nghĩa là hệ thống phải có khả năng phán đoán theo từng trường hợp cho dù người dùng X có được phép truy cập tài nguyên Y và hành động tương ứng hay không).

Khả năng sử dụng, lời khuyên chung là hãy giấu các khóa nhân tạo: chúng không có ý nghĩa gì với người dùng và bằng cách tiết lộ chúng theo những cách rõ ràng, bạn giới thiệu một sự phụ thuộc thêm, một điều đặc biệt khó xử lý vì nó tồn tại bên ngoài vương quốc của phần mềm - mọi người sẽ viết ra, e-mail, fax, in, đánh dấu, v.v., những ID đó và nếu bạn thay đổi chúng, bạn sẽ nhận được một số vé hỗ trợ gây phiền nhiễu.

Không , bạn hoàn toàn, tích cực không muốn cho phép truy cập vào các tài nguyên tùy ý chỉ bằng cách biết id nội bộ của chúng. Đây là internet, bất kỳ sự hiện diện độc hại, tội phạm hoặc trẻ con đơn giản nào bạn có thể tưởng tượng để tồn tại, thực sự tồn tại và sớm hay muộn chúng sẽ đến trang web của bạn. Trừ khi mọi thứ bạn có thể phục vụ là hoàn toàn công khai cho mọi người (và nếu bạn thậm chí có một khách hàng, điều đó được đảm bảo không phải là trường hợp đó), bạn phải hạn chế quyền truy cập vào những người thực sự được ủy quyền để có nó.

Giải pháp thông thường là sử dụng mã thông báo ủy quyền của một số loại được lưu trữ trong phiên được mã hóa và kiểm tra xem có xác minh xem có thứ gì được cho là hiển thị cho người dùng được xác thực hay không trước khi gửi đi. Đây có thể là một trình quản lý bảo mật thực tế, chẳng hạn như một trình quản lý đi kèm với JDK hoặc bất kỳ thành phần nào khác thực hiện cùng vai trò, miễn là nó hoạt động ổn định. (Có nên để lộ ID nội bộ cho người đã được xác thực hay không cũng là một câu hỏi thú vị với nhiều ưu và nhược điểm khác nhau, nhưng nó ít cần thiết hơn về bảo mật.)

Giá trị của việc này rất khó tính cho đến khi bạn thực sự bị tấn công bởi một người có nghĩa là kinh doanh. Sau đó, đó thường là sự khác biệt giữa việc ra khỏi doanh nghiệp và chỉ cần nhún nhường một kịch bản nhảm nhí khác.

Rõ ràng nó phụ thuộc vào mức độ nhạy cảm của dữ liệu nhưng đối với bảo mật trung bình, mức tối thiểu tôi sẽ làm là bao gồm ID và giá trị tổng kiểm tra.

Tạo tổng kiểm tra bằng cách thêm muối (tức là một tập hợp các ký tự ngẫu nhiên) trước và sau ID và thực hiện MD5 trên giá trị.

Trên mỗi trang đọc giá trị ID, nó sẽ tạo ra giá trị tổng kiểm tra và so sánh nó với giá trị được thông qua, từ chối yêu cầu nếu nó không khớp.

Nếu một hacker tiềm năng có thể có đủ các kết hợp hợp lệ thì họ có thể xử lý giá trị Salt bằng vũ lực, vì vậy nếu bạn có thể thêm một lớp bảo mật khác như kiểm tra ID người dùng cũng sẽ giúp ích.