Tại sao mã hóa bảo mật java lại quan trọng?

Question

Tôi không hiểu tại sao mã hóa bảo mật java lại quan trọng. Ví dụ: tại sao điều quan trọng là phải khai báo các biến riêng tư? Tôi có nghĩa là tôi nhận được rằng nó sẽ làm cho nó không thể truy cập các biến đó từ bên ngoài lớp, nhưng tôi chỉ đơn giản có thể dịch ngược lớp để có được giá trị. Tương tự, việc xác định một lớp là cuối cùng sẽ làm cho nó không thể phân lớp lớp này. Khi nào phân lớp một lớp sẽ nguy hiểm cho an ninh? Một lần nữa nếu cần thiết, tôi có thể dịch ngược lớp gốc và thực hiện lại nó với bất kỳ mã độc nào mà tôi có thể muốn. Sự cố có xảy ra khi ứng dụng được "đáng tin cậy" bởi người dùng không? Và mọi người có thể lạm dụng lòng tin này bằng cách nào đó? Về cơ bản những gì tôi đang tìm kiếm là một ví dụ tốt là tại sao phải tuân thủ các nguyên tắc mã hóa an toàn.

Answer 1

Lập trình khó.

Nếu bạn xác định API nghiêm ngặt, không hiển thị các biến không được hiển thị (chúng tôi muốn gọi số này là encapsulation), bạn sẽ giúp người dùng API của mình, và do đó giúp lập trình dễ dàng hơn. Đây được coi là một điều tốt.

Lý do không chủ yếu là "bảo mật", như trong việc giữ bí mật mọi thứ, nhiều như rõ ràng, đơn giản và dễ hiểu. Là một phần thưởng, nó dễ dàng hơn nhiều để làm cho mọi thứ hoạt động chính xác nếu bạn có thể biết rằng người dùng API không thay đổi biến "của bạn" phía sau lưng bạn, tất nhiên là như vậy.

Answer 2

Đó là "an toàn" có nghĩa là một lớp làm việc nội bộ được ẩn cho bất cứ ai sử dụng nó.

Thuật ngữ bảo mật không được sử dụng như trong "bảo mật máy chủ" được sử dụng để dự định thực tế là người dùng của một lớp không phải lo lắng về cách lớp sẽ thực hiện tác vụ mà anh ta muốn.

Lấy ví dụ của bạn:

Phơi bày các biến của một lớp sẽ cho phép người dùng của lớp bí quyết của bạn của sự tồn tại của họ, đó là một cái gì đó bạn không muốn, ví dụ: bạn chỉ cần nhấn một nút để bật ánh sáng, bạn không cần phải bây giờ mà bên trong có đồng hoặc whater nó cần để thực hiện nhiệm vụ.

Answer 3

Chỉ cần thêm vào những gì người khác đã nói: Một số tính năng này cũng có thể được xem như một cách để nêu rõ ý định. Nếu tôi tạo thành viên private Tôi làm cho nó "không thể" để người khác truy cập nó (có thể, nhưng ngoài vấn đề ở đây), nhưng quan trọng hơn là tôi nói với người dùng rằng đây là chi tiết triển khai, rằng họ không nên dựa vào .

Answer 4

Có hai vấn đề ở đây.

Cách thứ nhất khi khai báo các biến là được bảo vệ hoặc riêng tư, chúng sẽ không trở thành một phần của API công khai của bạn. Các lớp khác có thể phụ thuộc vào lớp học của bạn trong tương lai và điều quan trọng là bạn được tự do thay đổi nhiều nhất có thể nếu bạn muốn bao gồm các tính năng mới, cải thiện hiệu suất, v.v. Nếu tất cả các giá trị của bạn công khai hơn tất cả nội bộ của bạn các giá trị và cơ chế là công khai. Thay đổi chúng có thể phá vỡ các lớp khác phụ thuộc vào bạn.

Thứ hai, là khi phơi bày biến, nó cho phép các lớp khác thay đổi giá trị của bạn. Nếu họ thay đổi giá trị nội bộ của bạn nếu có thể phá vỡ chương trình của bạn và tạo hành vi bất ngờ lạ. Nếu bạn tạo một hệ thống dựa trên hiệu suất chính xác của một lớp học của bạn, và các giá trị nội bộ được thay đổi, hơn bạn không còn có thể dựa vào hệ thống đó nữa. Phân lớp làm cho điều này phức tạp hơn. Hệ thống của bạn có thể dựa vào một lớp của một loại nhất định để thực hiện các hành động mong đợi.Bằng cách phân lớp, có thể tạo một lớp mới có cùng kiểu nhưng không thực hiện các hành động mong đợi.

Ví dụ: nếu bạn có một hình vuông lớp có hàm getArea được bảo vệ(), bạn dự kiến ​​sẽ trả về diện tích hình vuông. Tuy nhiên, một lớp mới có thể được thực hiện mà mở rộng hình vuông, nói rằng hình chữ nhật lớp mở rộng vuông. Bây giờ rectange có thể ghi đè getArea(), nhưng nó vẫn là loại hình vuông, có thể phá vỡ một cái gì đó mà phụ thuộc vào chức năng của hình vuông. Bằng cách làm cho lớp cuối cùng của bạn, bạn đang khẳng định rằng điều này không bao giờ có thể xảy ra trong hệ thống của bạn.

Loại "mã hóa bảo mật" này sẽ không ngăn người khác xem mã nguồn của bạn, nhưng nó giúp làm cho mã của bạn đáng tin cậy hơn và có thể sử dụng được trong tương lai.

Answer 5

Java là một lang thang object-oriented programming và một trong những khái niệm chính trong lập trình hướng đối tượng là encapsulation. Ý tưởng đằng sau việc đóng gói là "giấu đi" các chi tiết thực hiện như biến nội bộ giữ trạng thái của đối tượng và hoạt động bên trong như thuật toán và chỉ cung cấp giao diện mà các đối tượng khác có thể sử dụng để thực hiện chức năng với đối tượng.

Sử dụng khái niệm đó, người ta muốn ẩn trạng thái nội bộ bằng cách sử dụng các biến số private để ngăn các đối tượng khác ảnh hưởng trực tiếp đến trạng thái bên trong. Trong Java, thường thấy các getters và setters (ví dụ: getColor và setColor) để làm việc với các đối tượng.

Ngoài ra, đóng gói cũng có thể tăng cường độ mạnh của mã.

Ví dụ: bằng cách hạn chế quyền truy cập vào trạng thái nội bộ, có thể thực hiện một số kiểm tra độ chính xác trước khi đối tượng bị thay đổi.

Ví dụ: giả sử có một đối tượng Score có giá trị percent giữa 0 và 100. Bằng cách cung cấp phương thức setPercent(int) xác nhận rằng giá trị được chỉ định nằm trong phạm vi cho phép, nó sẽ ngăn không cho đối tượng Score bị đặt ở trạng thái không được chấp nhận.

Vì vậy, cố gắng điều khiển trực tiếp trạng thái bên trong bằng cách viết một câu lệnh như score.percent = 150 có thể được ngăn chặn, nếu phương pháp setPercent gây ra lỗi hoặc ném Exception nếu giá trị được chỉ định không được chấp nhận.

Answer 6

chỉ cần tưởng tượng nếu đối tượng của bạn có thuộc tính nội bộ không phải là riêng tư (ẩn) và mã của bạn truy cập thuộc tính này xảy ra trong môi trường đa luồng, do đó, N chủ đề sẽ bắt đầu truy cập đồng thời, 5 chủ đề muốn thay đổi tài sản, 4 để đọc. Không có cách nào bạn đảm bảo mọi thứ sẽ chạy gọn gàng, không phải luồng nào sẽ biết dữ liệu nào được giữ trong thời điểm này và nó đã thay đổi thành công thuộc tính của đối tượng đó chưa.

Bạn sẽ phải lập trình đoạn mã đặc biệt sẽ chịu trách nhiệm xử lý truy cập đồng bộ và vẫn không được bảo đảm mã của bạn sẽ hoạt động ngay từ khi bạn vẫn phải kiểm tra phần còn lại của 680 lớp trong chương trình của bạn để truy cập trực tiếp.

Nói tóm lại, bạn đang ở trong một vấn đề lớn, và gỡ lỗi là một cơn ác mộng kể từ khi bạn không biết khi nào dữ liệu được chagned, mà thread đã làm điều đó, từ nơi nó happend, vv

Chỉ cần một kịch bản về những gì đang xảy ra nếu bạn không gói gọn ...

Điều tốt, mã của bạn chạy nhanh hơn 1%, có ít tải hơn, bạn có thể đạt được hiệu suất không đáng kể mà bạn sẽ phải trả với các sự cố hệ thống và cơ hội nhỏ để gỡ lỗi thành công.

Answer 7

Thuật ngữ "mã hóa an toàn" dùng để chỉ phần mềm cố gắng tránh các lỗ hổng bảo mật, cho dù bằng ngôn ngữ C, Java, Ruby, lắp ráp hay bất kỳ thứ gì khác. Có lẽ phần trung tâm nhất trong số đó, sau khi chọn một hệ thống ngôn ngữ an toàn, là giữ cho các thực hành lập trình tốt. Nếu một chương trình không rõ ràng, thì bạn có ít cơ hội đáng tin cậy.

Đối với Java có hai hướng dẫn đáng chú ý:

• Secure Coding Guidelines for the Java Programming Language, version 2.0. Cập nhật cách đây hai năm, và có nhu cầu cập nhật.
• The CERT Sun Microsystems Secure Coding Standard for Java. Một wiki mới được hỗ trợ bởi cả CERT và Sun có thể được cập nhật với bất kỳ điều gì bạn cảm thấy là quan trọng. Điều này có tầm nhìn rộng hơn nhiều so với hướng dẫn của Sun. Ví dụ, hướng dẫn Sun không thực sự quan tâm đến tràn số nguyên bởi vì tất cả các giới hạn mảng đều được kiểm tra, nhưng wiki thực hiện vì nó vẫn có thể gây ra lỗi chương trình.

Trong Java, có hai chế độ mã hóa an toàn riêng biệt.

Trong một tài khoản, bạn đang xử lý mã có thể không có tất cả các đặc quyền mà mã của bạn thực hiện. Ví dụ nếu bạn đang viết một thư viện hoặc ký mã, bạn cần phải làm điều này. Bạn không nên sử dụng mã độc để tận dụng các quyền của mình theo các cách không mong muốn. Cái này khó!

Thông thường, bạn đang xử lý các chương trình chỉ xử lý dữ liệu không đáng tin cậy. Ví dụ, các máy chủ web (nghĩ XSS và SQL injection) và các chương trình ứng dụng máy tính để bàn xử lý các tệp tin không đáng tin cậy (thường là vấn đề với mã C có tràn bộ đệm - chính hãng C++ là tốt hơn). Trong một số trường hợp, từ chối dịch vụ (DoS) có thể là một vấn đề nghiêm trọng.

Có một số trùng lặp. Ví dụ, phiên dịch chạy với quyền hạn của mã thông dịch viên và có thể khá "mạnh".