Fellow lập trình sử dụng thực hành lập trình tồi tệ nhất

Tôi biết có vẻ kỳ lạ khi nói, nhưng một lập trình viên đồng nghiệp đang cố tình sử dụng một vài thực hành lập trình xấu trên mục đích! Tôi sẽ giải thích. Đầu tiên hãy để tôi nói rằng anh ấy là một người thông minh và phần lớn anh ấy viết mã dễ hiểu.

Ông được yêu cầu thực hiện cấp phép cho một dự án ứng dụng web được viết bằng Java. Vì là Java, nếu một người thực sự muốn, có lẽ người ta có thể hack mở các lọ và đọc tên của các lớp và phương thức được viết bên trong. Giải pháp của ông cho vấn đề này là gọi một cách khó hiểu các biến và phương thức tên không rõ ràng và đặt chúng bên trong các lớp đã bị tắc nghẽn thay vì tạo các lớp mới.

Lời biện minh của anh ta là nếu một hacker muốn loại bỏ một số lớp nhất định để vượt qua kiểm tra cấp phép (và do đó có được một bản sao miễn phí của sản phẩm), thì anh ta sẽ gặp khó khăn hơn rất nhiều nếu không biết rõ phương pháp nào thực hiện các nhiệm vụ cụ thể này. Chỉ sau khi anh ta làm xong, tôi mới đối mặt với anh ta về điều đó, gợi ý rằng có lẽ chúng ta có thể mua một số thư viện obfuscator để làm điều đó cho chúng ta, trong khi vẫn duy trì các thực hành lập trình tốt. Ông tuyên bố không có thời gian hoặc nguồn lực để tìm kiếm loại giải pháp đó.

..Which làm tôi khó xử. Tôi có tìm kiếm một thư viện obfuscator trong Java và sửa mã cũ của anh ấy (có thể hơi cảm động về việc sửa lại mã của anh ấy), hoặc tôi có để nó như vậy không, điều đó có làm tôi khó chịu không?

Bảo mật thông qua obfuscation là không bao giờ bảo mật tốt. Phải có cách tốt hơn để bảo vệ tài sản trí tuệ của bạn. Và đó là những gì bạn và đồng nghiệp của bạn nên đưa ra như một mối quan tâm chung với người quản lý của bạn. Nếu quản lý quyết định rằng họ không muốn dành thời gian hoặc tiền bạc cho việc bảo mật được cải thiện, thì cả hai bạn sẽ phải sống với quyết định đó (không phải là sản phẩm của bạn, đó là sản phẩm của công ty) và tốt hơn là không chi tiêu (lãng phí?) bất kỳ thời gian nào về chủ đề này.

Bản gốc: Sếp của bạn nói gì? Tìm hiểu - làm điều đó.

Tôi đã được yêu cầu xây dựng ở trên:

Trước hết, tôi nghĩ bạn có nhiều vấn đề nan giải:

• Bạn có nên "sửa" mã người khác không?
• Việc thực hiện (từ A) của những người khác có đủ tệ đến mức cần phải thay thế bằng một thứ khác không?
• Liệu một obfuscator (ở đây từ B) sẽ tốt hơn cho "cấp phép nhúng trong ứng dụng của chúng tôi"?

Trước hết, nhìn từ một trường hợp kinh doanh, vấn đề IS đã được giải quyết. A đã có và là - rất có thể - một giải pháp "đủ tốt" cho vấn đề. Công ty của bạn có thể hài lòng với nó về cơ bản chỉ cần bảo vệ đủ để nỗ lực có chủ ý là cần thiết để phá vỡ nó.

Điều này có nghĩa là ngay cả khi bạn không thích nó (và, tin tôi đi, bạn sẽ thấy tồi tệ hơn rất nhiều trong sự nghiệp của mình ) nó làm những gì cần thiết. Do đó, khi vấn đề đã được giải quyết, bạn không nên "chỉ làm" mà phải thuyết phục người chịu trách nhiệm phân công công việc của bạn về lâu dàigiá của việc thực hiện này sẽ đủ cao để đảm bảo phục hồi và chọn một obfuscator chứng khoán. Điều này sẽ đòi hỏi khá nhiều sự chuẩn bị từ bạn, và cũng lưu ý rằng các obfuscators cũng có nhược điểm mà bạn cần biết (các câu trả lời khác cũng bao gồm điều này). Ví dụ, dấu vết ngăn xếp không thể sử dụng ngay lập tức, vv Tất cả phụ thuộc vào tầm quan trọng của việc tránh vi phạm bản quyền. Lưu ý rằng khó phá vỡ nhất là những cái yêu cầu khóa phần cứng để chạy và rất có thể đắt hơn so với khách hàng của bạn muốn.

Do đó, quyết định này không phải do bạn đưa ra, vì công ty của bạn cần sử dụng các nguồn lực bổ sung để đến B. Do đó, bạn cần đưa mối quan tâm của mình đến người chịu trách nhiệm, giải thích điều này và bất kỳ mối quan tâm lâu dài nào khác đủ để anh ấy hiểu tại sao bạn xem xét nó thấp hơn đề nghị của bạn. Sau đó, để anh ta đưa ra quyết định, và bất kể nó là gì, hãy tôn trọng nó và cư xử phù hợp một cách chuyên nghiệp. Lưu ý rằng tác giả ban đầu rất có thể sẽ phải duy trì nó bằng mọi cách khi anh ta viết nó và nếu anh ta rời đi hoặc không muốn nữa, thì bạn có thể đưa ra vấn đề một lần nữa.

Nói cách khác: ông chủ của bạn nói gì? Tìm hiểu - làm điều đó.

Cũng lưu ý rằng điều này sẽ khác nếu bạn nêu ra vấn đề sớm hơn để số tiền lãng phí cho thời gian thực hiện A nhỏ hơn. Nói cách khác, khi lựa chọn giữa A và B được đưa ra.

Cuối cùng, tôi muốn bình luận câu hỏi của bạn về "chỉ sửa mã người khác". Đây không phải là một sửa chữa nhỏ đối với mã hiện tại (mà tôi thấy tốt và được khuyến khích, đặc biệt là với các thử nghiệm tại chỗ). Đó là một sự phục hồi và thực hiện lại đột phá, và ngay cả trong các đội có quyền sở hữu mã chung, đây sẽ không phải là điều có thể chấp nhận được - ít nhất là đối với tôi - mà không có sự chấp thuận trước.

Hy vọng điều này làm rõ quan điểm của tôi.

Tôi có tìm kiếm một thư viện obfuscator trong Java và sửa mã cũ của anh ấy (có thể hơi cảm động về việc sửa lại mã của anh ấy), hoặc tôi có để nó như vậy không, điều đó có làm tôi khó chịu không?

Không , quay lại phía sau ai đó và thay đổi mã mà họ chịu trách nhiệm sẽ là một hành vi phạm tội tồi tệ hơn so với việc viết mã nghi vấn để bắt đầu.

Bạn đã đưa nó lên với lập trình viên, bước tiếp theo của bạn là giữ mũi của bạn ra khỏi nó hoặc đưa nó lên với quản lý và sau đó giữ mũi của bạn ra khỏi nó.

Đã có đánh giá mã chính thức dưới bất kỳ hình thức nào - hoặc là cuộc đối đầu mà bạn đã có "đánh giá mã" không chính thức? Tôi sẽ nói rằng vì đây là một chủ đề tế nhị và quan trọng như bảo mật và cấp phép, bạn cần phải nâng cao chuỗi này lên. Bạn đã thực hiện phần đầu tiên - đối đầu với lập trình viên. Tuy nhiên, bây giờ anh ấy không nghe, bạn có thể / nên đưa nó lên. Nếu bạn không, bạn có thể là một phần của vấn đề.

Tôi sẽ nói với anh ta rằng bạn sẽ làm điều đó - điều này CÓ THỂ thay đổi suy nghĩ của anh ta. Nếu không, hãy viết một email rất chính xác, nhưng chính xác và ngắn gọn về tình huống cho sếp của bạn, và lập trình viên CC. Trong email, yêu cầu một cuộc họp giữa ba bạn và / hoặc bất kỳ bên tham gia nào khác.

Luôn luôn đáp ứng những điều này - nhưng theo một cách chính trị và thân thiện.

Nếu bạn có thể tìm thấy một obfuscator có thể làm xáo trộn chữ ký của các lớp (tên phương thức, v.v.), tốt, đề xuất mua và sử dụng nó.

Cho đến khi, bạn có thể phải sống với nó. Tôi thừa nhận đã làm điều gì đó tương tự trong một dự án Grails gần đây - kiểm tra giấy phép được cố tình nhúng vào phương thức đăng nhập đã lớn, do đó, sẽ rất khó để thay thế phương thức bỏ qua kiểm tra.

Anh ta có thể chứng minh rằng một vụ hack như vậy là khả thi, hay đó chỉ là một tình huống giả định mà anh ta lo lắng? Anh ta có thể đưa ra một bản demo trực tiếp của tác phẩm này không? Anh nên thử. Nghiêm túc. Nếu nó hoạt động, nó nên được trình bày cho quản lý, và sau đó đề nghị nhận một obfuscator.

Nếu một obfuscator không đủ an toàn, bạn đã xem xét các cách khác để bảo mật JAR, có thể là một cái gì đó như mã hóa nó, hoặc biên dịch nó thành mã gốc?

RE: làm lại mã của mình: Có phải chỉ là vấn đề đổi tên? Nhiều IDE có các công cụ tái cấu trúc có thể thực hiện việc này khá dễ dàng.

Bất kể IP của bạn có giá trị như thế nào, điều thông minh sẽ không làm xáo trộn mã của bạn với hy vọng gây nhầm lẫn cho tin tặc. Ngoài thực tế là nó sẽ là một cơn ác mộng để tiếp tục tiến lên, nó không thực sự giải quyết bất kỳ vấn đề nào. Nó chỉ làm cho nó khó hơn nhưng không phải là không thể. Vì vậy, nó không thực sự là một giải pháp và tác dụng phụ là xấu. Nó giống như uống thuốc không có tác dụng và có tác dụng phụ xấu.

Vấn đề của bạn là làm thế nào để bảo mật IP của bạn. Tìm một giải pháp cho điều đó: obfuscators, máy chủ cấp phép, v.v.

Tôi gặp phải một vấn đề tương tự khi một nhà phát triển khác đặt tên cho thói quen mã hóa / giải mã của chúng tôi str__copyvà str__delete(chú ý dấu gạch dưới thứ hai). Đó là sự khập khiễng và có thể đã được thực hiện tốt hơn, vì vậy chúng tôi đã đợi cho đến khi có một câu chuyện trong đó việc cập nhật giấy phép là cần thiết. Ban quản lý không gặp vấn đề gì với số giờ làm thêm vì chúng tôi mô tả nó là "dọn dẹp để lần sau chúng tôi đi cấp phép, sẽ mất ít thời gian hơn và sẽ an toàn hơn". Vấn đề được giải quyết, không có cảm xúc tổn thương.

Suy nghĩ đầu tiên của tôi là bảo trì mã đó. Nếu mã đã bị xáo trộn và anh ta tiếp tục, chúc may mắn tìm cách xử lý mã đó. Sau đó, bạn sẽ là hacker cố gắng giải mã mã.

Thay vào đó, tôi khuyên bạn nên làm sạch mã và sử dụng một obfuscator làm tất cả công việc khó khăn. Về lâu dài, bạn sẽ có nhiều mã có thể quản lý được và bạn để lại tất cả sự phức tạp điên rồ cho bất cứ ai muốn hack giấy phép của bạn.

Hãy nhớ rằng không có obfuscater nào là hoàn hảo, và một hacker rất kiên quyết có thể đảo ngược mọi thứ, nhưng ít nhất đó sẽ chỉ là anh ta. Cộng với obfuscaters thêm phức tạp hơn nhiều so với một chàng trai có thể có thể.

Tôi rất đồng ý với câu trả lời rằng bạn nên hỏi sếp về vấn đề này và làm theo những gì anh ấy nói.

Tuy nhiên, một phụ lục rất quan trọng cho những câu trả lời này là bạn nên ghi lại những lo lắng của mình về cả bảo mật và khả năng bảo trì. Cho dù bạn có thay đổi mã hay không, điều quan trọng là mọi người biết bạn quan tâm đến vấn đề gì và tại sao. Điều này rất quan trọng cả về mặt chủ động (sếp của bạn không thể đưa ra quyết định mà anh ta thậm chí không biết cần phải đưa ra) và phòng thủ (nếu / khi tin tặc chọc vào hệ thống cấp phép được bảo mật kém, họ không thể đổ lỗi cho bạn vì họ sai lầm.)

"Đừng là chuyên gia cao cấp nhất để biết về một vấn đề".

Nói cách khác, nói với sếp của bạn và đi từ đó. Nếu bạn giữ im lặng và bạn là đỉnh của cột totum về bí mật đó, khi bạn gặp khó khăn, bạn sẽ phải chịu trách nhiệm. Nói với sếp của bạn thông qua và để anh ta quyết định một cách để tiếp cận nó. Bằng cách đó bạn được giảm bớt gánh nặng của sự lựa chọn.

Đừng chỉ nói với sếp của bạn, bởi vì nhiều người quản lý có thể không phải là kỹ thuật, nhưng hãy làm những gì chúng ta luôn làm: đưa ra vấn đề và giải pháp khả thi với những ưu điểm / nhược điểm cho từng giải pháp đó. Sau đó để cho họ quyết định và đã bỏ qua. Đó là lý do tại sao các nhà quản lý / lãnh đạo được trả nhiều tiền!

Sự thật đơn giản là cho đủ thời gian và tài nguyên, mọi thứ đều có thể bị bẻ khóa. Đây là một chức năng đơn giản về mức độ phổ biến của ứng dụng của bạn. Càng phổ biến, nó càng thu hút được nhiều hacker lành nghề và dành nhiều thời gian hơn để phá vỡ nó. Mã obfuscation chỉ cung cấp điều đó - một phương tiện để tăng thời gian cần thiết để phá vỡ nó, tương tự như mật mã. Vì vậy, nếu mã của bạn bị xáo trộn, nó đòi hỏi kẻ tấn công phải có kỹ năng và dành thời gian cho nó nếu không anh ta sẽ tuyệt vọng và bỏ cuộc. Bạn phải tự hỏi liệu ứng dụng của bạn có đáng để gặp rắc rối ở cả hai đầu không.

Thật sự đáng kinh ngạc khi nó khó trở thành mã bẻ khóa. Bạn có thể dễ dàng biến một chương trình 10 dòng C đơn giản trong một tổ hợp 100 dòng thông qua obfuscation. Nếu bạn thử gỡ lỗi nó, bạn sẽ nhảy xung quanh một cách vô nghĩa trong mã và có thể thực sự bực bội khi bước qua nó. Cuối cùng nó sẽ vỡ nhưng nó trở nên thực sự khó khăn và vì không có gì thực sự là không thể. Mã obfuscation làm giảm số lượng người có thể phá vỡ nó.

Chắc chắn có nhiều cách tốt hơn, như cố gắng gây nhầm lẫn cho trình gỡ lỗi không phải là cracker, nhưng đây là một cách rẻ tiền và hiệu quả. Tuy nhiên, việc đặt tên một cách vụng về không hoàn toàn cắt nó. Bạn phải thay đổi các hàm gọi luồng điều khiển không thực sự làm gì cho mã tổng thể của bạn nhưng tăng kích thước và độ phức tạp của nó: gọi các hàm giả có giá trị trả về không được sử dụng ở bất cứ đâu, từ các hàm bên trong thực sự làm gì đó. Bạn đã có thể thấy làm thế nào điều này có thể thực sự gây nhầm lẫn.

Bạn có một cái gì đó mà kẻ tấn công không. Mã nguồn gốc. Tìm cách tổ chức nó tốt hơn cho chính mình.