Mã hóa mã JavaScript trực tuyến
|
Bài đăng trên blog này nhằm mục đích cung cấp hướng dẫn chi tiết và toàn diện nhất về mã hóa JavaScript vào năm 2022 Show
Quen thuộc với JavaScript và npm là một lợi thế, nhưng không cần thiết phải làm theo hướng dẫn này Hãy đi sâu vào nó Chương 1. Làm xáo trộn mã là gì?Nói một cách đơn giản, xáo trộn mã là một kỹ thuật được sử dụng để chuyển đổi mã đơn giản, dễ đọc thành một phiên bản mới khó hiểu và kỹ sư đảo ngược có chủ ý—cho cả con người và máy móc. Hãy nghĩ về obfuscation như thế này. bạn gọi điện cho một người bạn để hẹn uống cà phê sau (bạn có nhớ đó là chuyện khi nào không?) Một câu trả lời có thể sẽ giống như “Xin chào. Xin lỗi, hôm nay không làm được, tôi phải trông lũ trẻ. Cùng giờ ngày mai?” Nhưng hãy tưởng tượng rằng bạn của bạn quyết định làm điều này khó hiểu hơn một chút, đánh bạn bằng một câu nói nồng nhiệt “Chào ngày mai. Tôi xin gửi đến bạn lời xin lỗi chân thành nhất nhưng, than ôi, tôi không thể làm điều đó vào ngày hôm nay. Haply tom'rrow, bình đẳng thời gian? . lời xin lỗi chân thành tôi cung cấp cho bạn. tạm biệt bạn tốt. ” Vâng, đó là một cửa miệng. Nếu bạn xem xét kỹ hơn câu trả lời kiểu Shakespearean của bạn mình, thì rõ ràng là toàn bộ sự việc phức tạp một cách không cần thiết. Phải mất nhiều thời gian hơn để giải mã ý nghĩa của thông điệp và có một số dư thừa. Ngoài ra, bạn của bạn đã thêm một số chi tiết không liên quan. Chắc chắn, bạn có thể giải mã điều vô nghĩa này một lần. Nhưng bạn sẽ tiếp tục gọi cho bạn của mình nếu điều này trở thành một điều vĩnh viễn chứ? Một ví dụ ngớ ngẩn như thế này có vẻ như, nó bao gồm lý do giống như một số kỹ thuật được sử dụng trong mã hóa. Trong chương tiếp theo, chúng ta sẽ thấy các ví dụ thực tế về việc làm xáo trộn mã và hy vọng bạn sẽ thấy sự giống nhau Mặc dù (may mắn thay) không có nhiều ví dụ thực tế về việc làm xáo trộn mã trong cuộc trò chuyện của con người, nhưng việc làm xáo trộn mã đã có từ lâu — có những đề cập đến "làm xáo trộn mã" trong các cuốn sách có từ năm 1972 Obfuscation đã được sử dụng trong một số ngôn ngữ lập trình khác nhau, đáng chú ý là trong C/C++ (thậm chí còn có một cuộc cạnh tranh để làm xáo trộn mã C) và Perl. Nhưng có một ngôn ngữ mà việc che giấu đã trở nên phổ biến rộng rãi giữa các nhà phát triển cũng như chủ sở hữu doanh nghiệp. JavaScript chương 2. Mã hóa JavaScriptTại sao làm xáo trộn mã JavaScript?JavaScript đã nhanh chóng trở thành ngôn ngữ của web. Nó hỗ trợ gần như mọi trang web tồn tại và sự gia tăng của các khung JavaScript đa nền tảng như React Native và Ionic cho phép các nhà phát triển tạo ứng dụng dành cho thiết bị di động và máy tính để bàn bằng cơ sở mã JS được chia sẻ Với mỗi công ty trong danh sách Fortune 500 sử dụng JavaScript để phát triển ứng dụng của họ, ngày nay chúng ta thấy JS cung cấp năng lượng cho các ứng dụng quan trọng trong các lĩnh vực khác nhau như ngân hàng di động, thương mại điện tử và dịch vụ phát trực tuyến Điều này đưa chúng ta đến câu hỏi chính là “tại sao lại làm xáo trộn mã JavaScript?”. JavaScript là một ngôn ngữ được diễn giải—vì vậy, JavaScript phía máy khách yêu cầu một trình thông dịch trong trình duyệt để đọc, diễn giải và chạy nó. Điều này cũng có nghĩa là bất kỳ ai cũng có thể sử dụng trình gỡ lỗi trình duyệt để dễ dàng xem qua mã JS và đọc hoặc sửa đổi mã đó theo ý muốn Trong ví dụ dưới đây, bạn có thể thấy ai đó dễ dàng truy cập logic mã đằng sau bàn phím ảo nơi khách hàng của ngân hàng nhập mật khẩu của họ Với khả năng truy cập dễ dàng vào mã JavaScript phía máy khách, kẻ tấn công gần như dễ dàng lợi dụng điểm yếu bảo mật này và nhắm mục tiêu vào bất kỳ mã không được bảo vệ nào Tất cả điều này có vẻ tầm thường khi chúng ta đang nói về một ứng dụng web đơn giản. Nhưng các công ty—đáng chú ý là doanh nghiệp và Fortune 500—thường lưu trữ logic kinh doanh quan trọng ở phía máy khách của ứng dụng của họ Nếu bạn hiểu kiến thức cơ bản về bảo mật ứng dụng, bạn sẽ biết rằng mã bí mật phải luôn được giữ trên các môi trường thực thi đáng tin cậy như máy chủ phụ trợ. Nhưng đây là một trong những trường hợp mà thực hành được ưu tiên hơn lý thuyết. Khi các công ty lưu trữ logic quan trọng này ở phía máy khách, họ thường làm điều đó vì họ không thể giữ mã này ở phía máy chủ một cách khả thi. Một lý do phổ biến cho điều này là khi không có phụ trợ ngay từ đầu, như trong trường hợp của một số ứng dụng di động. Một ví dụ khác là khi có một số mã liên quan đến trải nghiệm người dùng (như thuật toán phân tích) phải chạy ở phía máy khách. Tuy nhiên, lý do phổ biến nhất là hiệu suất. Các cuộc gọi máy chủ cần có thời gian và khi bạn có một dịch vụ mà hiệu suất là yếu tố quan trọng—chẳng hạn như nền tảng phát trực tuyến hoặc trò chơi HTML5—việc lưu trữ tất cả JavaScript trên máy chủ không phải là một tùy chọn Dù thế nào đi chăng nữa, các công ty thường không muốn tiết lộ logic độc quyền của họ. Và họ chắc chắn không bao giờ muốn tiết lộ bí mật mã. Đặc biệt là khi các đối thủ cạnh tranh của họ có thể thiết kế ngược mã và sao chép các thuật toán độc quyền Bên cạnh hành vi trộm cắp tài sản trí tuệ, JavaScript phía máy khách cũng có thể là mục tiêu của các cuộc tấn công tinh vi hơn như lạm dụng tự động, vi phạm bản quyền, gian lận và đánh cắp dữ liệu (tìm hiểu thêm về những điều này tại đây) Không có gì ngạc nhiên khi các tiêu chuẩn bảo mật thông tin như ISO 27001 đưa ra các tuyên bố như “Mã nguồn chương trình có thể dễ bị tấn công nếu không được bảo vệ đầy đủ và có thể cung cấp cho kẻ tấn công một phương tiện tốt để xâm phạm hệ thống theo cách thức bí mật. Nếu mã nguồn là trung tâm của sự thành công trong kinh doanh thì việc mất nó cũng có thể phá hủy giá trị kinh doanh một cách nhanh chóng. ” Và OWASP (Dự án bảo mật ứng dụng web mở) củng cố rõ ràng đề xuất này trong hướng dẫn 10 rủi ro bảo mật hàng đầu trên thiết bị di động của họ “Để ngăn chặn kỹ thuật đảo ngược hiệu quả, bạn phải sử dụng một công cụ che giấu. ” JavaScript Obfuscation là gì?Mã hóa mã JavaScript là một loạt các phép biến đổi mã để biến mã JS đơn giản, dễ đọc thành một phiên bản sửa đổi cực kỳ khó hiểu và kỹ sư đảo ngược Không giống như mã hóa, nơi bạn phải cung cấp mật khẩu được sử dụng để giải mã, không có khóa giải mã trong mã hóa JavaScript. Trên thực tế, nếu bạn mã hóa JavaScript ở phía máy khách, đó sẽ là một nỗ lực vô nghĩa—nếu chúng tôi có khóa giải mã mà chúng tôi cần cung cấp cho trình duyệt, khóa đó có thể bị xâm phạm và mã có thể dễ dàng truy cập Vì vậy, với khả năng làm xáo trộn, trình duyệt có thể truy cập, đọc và diễn giải mã JavaScript bị xáo trộn dễ dàng như mã gốc, không bị xáo trộn. Và mặc dù mã bị xáo trộn trông hoàn toàn khác, nhưng nó sẽ tạo ra chính xác cùng một đầu ra trong trình duyệt Mã hóa JavaScript thường bị nhầm lẫn với các kỹ thuật khác như thu nhỏ, tối ưu hóa và nén. Hãy nhanh chóng xem xét sự khác biệt giữa chúng Trình rút gọn mã loại bỏ các ký tự không cần thiết trong mã (khoảng trắng, dòng mới, số nhận dạng nhỏ hơn, v.v. ) giảm thiểu kích thước của mã—nhưng chúng không bảo vệ mã nguồn Trình tối ưu hóa mã chủ yếu được sử dụng để cải thiện hiệu suất mã (tốc độ và mức sử dụng bộ nhớ của ứng dụng). Đôi khi, chúng cũng có thể vô tình làm cho mã khó đọc hơn, nhưng điều này không mang lại sự bảo vệ nào (như chúng ta sẽ thấy ở phần sau) Cuối cùng, trình nén mã và trình đóng gói giảm kích thước mã bằng kỹ thuật mã hóa và đóng gói nhưng chúng cũng không bảo vệ mã nguồn Một quan niệm sai lầm phổ biến khác là nếu bạn đã sử dụng SAST hoặc DAST để tìm các lỗ hổng trong mã JavaScript của mình và khắc phục chúng, thì điều này sẽ giải quyết được tất cả các vấn đề về mã của bạn. Mặc dù SAST/DAST rất hữu ích để khắc phục các lỗ hổng, nhưng nó không ngăn được việc giả mạo mã và kỹ thuật đảo ngược, vì không cần phải có lỗ hổng để thực hiện điều đó. Do đó, nên sử dụng SAST và DAST cùng với bảo vệ mã nguồn JavaScript Mục tiêu & kỹ thuật làm xáo trộn JavaScriptBây giờ, chúng ta đã rõ ràng JS obfuscation là gì trên phạm vi rộng hơn, hãy tìm hiểu thêm một chút về kỹ thuật và xem xét cụ thể nó làm gì với mã nguồn Vì mục tiêu chính của việc làm xáo trộn là ẩn JavaScript và các phần của mã có thể bị kẻ tấn công hoặc đối thủ cạnh tranh nhắm mục tiêu, nên dễ hiểu rằng bạn muốn làm xáo trộn bất kỳ dữ liệu nào trong mã. Vì vậy, bằng cách che giấu những thứ như biến, đối tượng và chuỗi, bạn sẽ khiến mọi người khó hiểu loại dữ liệu nào nằm trong mã hơn phụ lục. chỉ dựa vào che giấu để bảo vệ dữ liệu nhạy cảm trong mã của bạn là một cách làm không tốt và đó là lý do tại sao bạn có thể sẽ nghe ai đó nói rằng “che khuất không phải là bảo mật”. Tùy thuộc vào trường hợp sử dụng của bạn, bạn phải luôn sử dụng kỹ thuật che giấu dữ liệu bên cạnh các biện pháp bảo mật tốt. Hãy nghĩ về nó như thế này. nếu bạn muốn giữ an toàn một đống tiền mặt, có lẽ bạn nên cất nó vào két sắt. Nhưng thay vì để chiếc két hoàn toàn lộ thiên trước hiên nhà, có lẽ bạn cũng nên giấu nó ở đâu đó để giảm thiểu khả năng ai đó tìm thấy và cố gắng phá nó Nhưng che giấu dữ liệu chỉ là một trong nhiều khía cạnh của việc che giấu JS. Làm xáo trộn mạnh cũng sẽ làm xáo trộn bố cục và luồng điều khiển chương trình, cũng như bao gồm một số kỹ thuật tối ưu hóa. Thông thường, nó sẽ nhắm mục tiêu
Các kỹ thuật che giấu JavaScript phổ biến nhất là sắp xếp lại, mã hóa, tách, đổi tên và kỹ thuật che giấu logic. Hiểu sâu từng kỹ thuật nằm ngoài phạm vi của hướng dẫn này, nhưng tên của chúng đã khá dễ hiểu. Nếu bạn muốn tìm hiểu thêm về từng kỹ thuật có thể, hãy xem tài liệu này Tuy nhiên, che giấu luồng điều khiển đáng được giải thích sâu hơn, vì nó là một kỹ thuật đặc biệt hữu ích. Nó làm cho chương trình khó theo dõi hơn đáng kể bằng cách loại bỏ các cấu trúc điều kiện tự nhiên giúp mã dễ đọc hơn Từ góc độ kỹ thuật, nó chia tách tất cả các khối cơ bản của mã nguồn — chẳng hạn như thân hàm, vòng lặp và các nhánh có điều kiện — và đặt tất cả chúng bên trong một vòng lặp vô hạn duy nhất bằng câu lệnh switch điều khiển luồng chương trình Nó cũng có thể bao gồm các bản sao (các bản sao tương đương về mặt ngữ nghĩa của các khối cơ bản có thể được thực thi thay thế cho các khối cơ bản ban đầu của chúng), các bản sao chết (các bản sao giả của các khối cơ bản không bao giờ được thực thi, nhưng bắt chước và có thể bị nhầm lẫn với mã sẽ được thực thi . Sự kết hợp của các kỹ thuật này làm tăng thêm độ phức tạp tổng thể của mã bị xáo trộn Một cách tiếp cận đáng chú ý khác để che giấu là sử dụng tính đa hình. Làm xáo trộn JavaScript đa hình là một kỹ thuật độc đáo được Jscrambler sử dụng để đảm bảo rằng mỗi lần xáo trộn mã mới đều dẫn đến mã hoàn toàn khác Hãy xem một ví dụ. Hãy tưởng tượng bạn đang triển khai các bản dựng mã bị xáo trộn mỗi tuần một lần. Những kẻ tấn công có thể bắt đầu cố gắng giải xáo trộn mã ngay khi bạn gửi một phiên bản mới. Giả sử họ đã đạt được một số tiến bộ trước khi bạn phát hành bản dựng mới, nếu mã bị xáo trộn của bản dựng mới tương tự như mã trước đó, kẻ tấn công có thể tận dụng hầu hết tiến trình của chúng để tiếp tục kỹ thuật đảo ngược của chúng. Với giải mã đa hình, bản dựng mới hoàn toàn khác, điều đó có nghĩa là hầu hết (nếu không phải tất cả) tiến trình giải mã mã hóa trước đó trở nên vô dụng Ví dụ về mã hóa JavaScriptOk, đã đến lúc tạm dừng lý thuyết và hãy chuyển ngay sang một ví dụ thực tế về mã hóa JavaScript Hãy xem xét đoạn mã bên dưới, đây là một thuật toán được sử dụng để giới thiệu sản phẩm cho người mua hàng trên một trang web thương mại điện tử. Nó tạo ra một danh sách các đề xuất sản phẩm cho một khách hàng nhất định dựa trên lịch sử mua hàng trước đó của khách hàng đó Đây có vẻ là đoạn mã khá bình thường, nhưng hãy tưởng tượng rằng đây là một thuật toán độc quyền do công ty này phát triển. Nếu chúng tôi là đối thủ cạnh tranh truy cập trang web của họ, chúng tôi có thể nhanh chóng tìm thấy mã này và làm những gì chúng tôi muốn với nó Là chủ sở hữu của mã này, chúng tôi hiểu rủi ro này và muốn bảo vệ nó. Trước khi chúng ta đi vào quá trình mã hóa JS thực tế, hãy xem việc thu nhỏ sẽ làm gì với mã  Thoạt nhìn, bạn sẽ nói code khó đọc hơn. Nhưng chỉ mất một giây để nhận ra rằng tất cả các hàm, đối tượng và biến của chúng ta đều ở đó. Một lần nữa, thu nhỏ không cung cấp bất kỳ loại bảo vệ mã nào Bây giờ hãy xem mã trông như thế nào sau khi chúng ta thêm một kỹ thuật che giấu duy nhất Trước hết, đây thậm chí không phải là mã JavaScript dễ nhận biết. Nó đã bị xáo trộn với một thứ gọi là làm phẳng luồng điều khiển—một phép biến đổi Jscrambler độc đáo giúp làm phẳng luồng chương trình và che giấu mọi cấu trúc điều kiện tự nhiên đơn lẻ giúp mã dễ đọc hơn phụ lục. nếu bạn muốn kiểm tra quá trình chuyển đổi che giấu này trong mã của riêng mình để xem đầu ra trông như thế nào, bạn chỉ cần tạo một tài khoản Jscrambler miễn phí Đoạn mã trên chỉ hiển thị một vài dòng mã đầu tiên nhưng toàn bộ nội dung dài gần 700 dòng. Và nếu chúng tôi chạy mã này, trình duyệt sẽ chạy nó giống như ban đầu Bây giờ hãy xem một ví dụ về che giấu cực độ Đây là một đoạn mã có khả năng che giấu không phải chữ và số mà bạn không thường tìm thấy ngoài tự nhiên. Đối với mắt người, điều này dường như không thể thiết kế ngược. Nhưng nếu chúng tôi chạy mã này thông qua một công cụ kỹ thuật đảo ngược tự động, chúng tôi sẽ nhận được mã gốc gần như ngay lập tức Trên thực tế, sự che giấu có vẻ cực đoan này là một ví dụ tuyệt vời về việc che giấu yếu có thể trông như thế nào Vì vậy, làm thế nào chúng ta có thể phân biệt giữa che giấu yếu và mạnh? Số liệu làm rối mã JSMột trong những cách giải thích rõ ràng nhất về số liệu che giấu mã nguồn JS được cung cấp bởi Collberg et al. trong bài viết của họ “A Taxonomy of Obfuscating Transformations” Như các nhà nghiên cứu này đã nói, có 3 chỉ số chính. hiệu lực, khả năng phục hồi và chi phí hiệu lựcTiềm năng là thước đo trả lời câu hỏi “Người đọc bị nhầm lẫn ở mức độ nào?”. Nhìn lại 3 ví dụ trước của chúng tôi, chúng tôi có thể tự tin nói rằng ví dụ #1 (thu nhỏ) có hiệu lực thấp, trong khi ví dụ #2 có hiệu lực cao và ví dụ #3 có hiệu lực cực cao bạn có thể tự hỏi. làm cách nào để tính toán chỉ số hiệu lực? . Vì vậy, bạn thường sẽ không tự mình tính toán tiềm năng Nói như vậy, có một số đặc điểm cụ thể của phép biến đổi mà bạn có thể sử dụng để đánh giá hiệu lực của nó dễ dàng hơn. Vì vậy, một chuyển đổi tiềm năng cao thường
Tuy nhiên, một sai lầm chính khi đánh giá mã JavaScript bị xáo trộn là chỉ xem xét tiềm năng của nó. Và như chúng ta đã thấy trước đây, một phép biến đổi có hiệu lực cao có thể rất dễ bị đánh bại. Đó là lý do tại sao chúng ta cũng phải xem xét một số liệu khác. khả năng phục hồi khả năng phục hồiSố liệu về khả năng phục hồi trả lời câu hỏi “Các cuộc tấn công giải mã mã nguồn tự động được chống lại tốt như thế nào?” Ví dụ: chúng ta có thể thêm một câu lệnh if giới thiệu một biến giả vào mã của chúng ta. Có thể mất một lúc để con người xác định mã là mã giả, nhưng bộ giải mã mã nguồn sẽ xóa câu lệnh ngay lập tức Đây là lý do tại sao khả năng phục hồi được tính bằng cách xem xét hai khía cạnh khác nhau
Đây là số liệu mà hầu hết các công cụ mã hóa đều thất bại, đặc biệt là các công cụ mã hóa JS miễn phí. Họ có thể xuất ra những gì trông giống như mã bị xáo trộn cao, nhưng thường khá đơn giản để giải mã bằng các công cụ có sẵn. Khi so sánh các kết quả che giấu khác nhau, chúng ta không thể đơn giản tin vào mắt và nhận thức của chính mình Tuy nhiên, các phép biến đổi của Jscrambler được xây dựng để đạt được khả năng phục hồi tối đa bất cứ khi nào có thể. Cụ thể, Jscrambler bao gồm một tính năng Code Hardening được tích hợp vào mọi mã obfuscation. Tính năng này cung cấp cho mã khả năng phục hồi cập nhật được đảm bảo chống lại tất cả các công cụ và kỹ thuật đảo ngược tự động. Vì vậy, khi các công cụ này cố gắng đảo ngược mã được bảo vệ bởi Jscrambler, chúng thường sẽ hết thời gian chờ hoặc bị treo, buộc những kẻ tấn công phải thực hiện thủ công và đối mặt với các biến đổi hiệu lực cao đáng sợ bằng tay. Trị giáCuối cùng, chúng ta có chỉ số chi phí, đại diện cho tác động của việc chuyển đổi trong thời gian thực thi của ứng dụng được chuyển đổi cũng như tác động đến kích thước tệp của ứng dụng Điều này rất quan trọng vì bạn sẽ không muốn hiệu suất ứng dụng của mình bị hủy hoại do bị xáo trộn, đặc biệt là khi bạn có ứng dụng dành cho khách hàng và có thể bị mất tiền nếu ứng dụng bắt đầu chạy chậm Một công cụ che giấu tốt phải luôn cung cấp các tính năng cụ thể để giảm thiểu các lần truy cập hiệu suất và cũng cho phép bạn tinh chỉnh các biến đổi trong toàn bộ mã của mình. Đây lại là một thiếu sót khác của các obfuscator JS miễn phí, thường cung cấp rất ít hoặc không có khả năng tinh chỉnh bảo vệ. Ngược lại, khi sử dụng Jscrambler, bạn sẽ tìm thấy một số tính năng tự động tinh chỉnh biện pháp bảo vệ để tối đa hóa hiệu suất, chẳng hạn như Lập hồ sơ và Phân loại ứng dụng Hiểu ba số liệu che giấu này là rất quan trọng để đảm bảo rằng mã của bạn thực sự được bảo vệ và không giống như vậy Chương 3. Làm xáo trộn & SDLCViệc làm xáo trộn JavaScript không nên dẫn đến chi phí xử lý và làm phức tạp quá mức SDLC của bạn. Để đảm bảo điều đó không xảy ra, điều quan trọng là phải giải quyết vấn đề hai chiều. khả năng tương thích và tích hợp Khả năng tương thích của mã JavaScript bị xáo trộnKhi nói đến khả năng tương thích, trước tiên, vấn đề cần hiểu là mã nguồn của bạn có tương thích với một công cụ che giấu cụ thể hay không. Một số trình mã hóa JS thiếu khả năng tương thích với một số phiên bản ECMAScript và có thể yêu cầu bạn dịch mã như một bước bổ sung trước khi bảo vệ mã. Thường xuyên hơn, chúng có thể thiếu khả năng tương thích với một số thư viện và khung JS nhất định, yêu cầu những thay đổi đáng kể để kích hoạt tính năng bảo vệ mã Một khía cạnh quan trọng khác là khả năng tương thích của mã bị xáo trộn. Quay trở lại định nghĩa ban đầu của chúng ta về mã hóa JavaScript, nó được “dùng để biến đổi (. ) mã số". Mặc dù mã bị xáo trộn của bạn phải luôn chạy giống như mã gốc, nhưng việc xáo trộn có thể dẫn đến một số thay đổi về tính tương thích, cụ thể là với các phiên bản trình duyệt cụ thể Là một sản phẩm dành cho doanh nghiệp, Jscrambler đảm bảo khả năng tương thích với tất cả các phiên bản ECMAScript và cung cấp các tính năng như Khả năng tương thích với trình duyệt để cung cấp khả năng hiển thị và kiểm soát tính tương thích của mã được bảo vệ. Vì vậy, bạn luôn có thể đảm bảo rằng mã được bảo vệ sẽ tương thích với các phiên bản trình duyệt mục tiêu. Ngoài ra, nó đảm bảo khả năng tương thích với tất cả các thư viện và khung JS chính Làm xáo trộn, tích hợp CI/CD và làm cho các kỹ sư hài lòngTrong trường hợp bạn muốn đảm bảo rằng tất cả các lần triển khai ứng dụng của mình đều được làm xáo trộn, bạn có thể muốn tự động hóa quy trình này. Ở đây, điều đặc biệt quan trọng là phải xem xét bạn đang sử dụng khung JavaScript nào và quy trình xây dựng của bạn được cấu trúc như thế nào Như đã đề cập trước đây, một số obfuscator cung cấp khả năng tương thích rất hạn chế với các khung JavaScript, đặc biệt là với React Native và Ionic. Vì vậy, họ thường sẽ không làm xáo trộn mã hoàn toàn Trong trường hợp của Jscrambler, quá trình xáo trộn được thực hiện tại thời điểm xây dựng và hoàn toàn tương thích với mọi khung JavaScript chính. Jscrambler có thể dễ dàng tích hợp vào quá trình xây dựng React, Angular, Vue, Node. js, React Native, Ionic, NativeScript và nhiều framework khác. Việc tích hợp Jscrambler vào quy trình CI/CD của bạn rất đơn giản và thậm chí còn có các tích hợp cho các quy trình xây dựng cụ thể. bạn chỉ cần gọi API Jscrambler và nhận phiên bản được bảo vệ của ứng dụng của bạn. Phiên bản được bảo vệ này là phiên bản bạn nên triển khai Tích hợp CI/CD mượt mà chắc chắn sẽ mang lại nụ cười trên khuôn mặt kỹ sư của bạn, nhưng vẫn còn một tính năng “chất lượng cuộc sống” khác đặc biệt phù hợp khi đề cập đến việc làm rối. Sau khi xem các ví dụ trước về mã bị xáo trộn, bạn có thể tự hỏi “làm cách nào để gỡ lỗi mã được bảo vệ này?”. Vì mục tiêu của việc che giấu là làm cho mã khó đọc hơn, nó có thể khiến cuộc sống của các nhà phát triển của bạn trở thành cơn ác mộng sống khi họ phải gỡ lỗi trong quá trình sản xuất. Do đó tầm quan trọng của bản đồ nguồn Mặc dù nhiều công cụ xáo trộn không cung cấp bản đồ nguồn toàn diện, Bản đồ nguồn Jscrambler cho phép dễ dàng ánh xạ mã bị xáo trộn trở lại mã nguồn ban đầu của nó—cả thông qua ứng dụng web và thông qua Jscrambler CLI Hỗ trợ và tin tưởngNhư với tất cả những thứ liên quan đến bảo mật, che giấu là một quy trình rủi ro cao. Giống như việc sử dụng trình mã hóa JS yếu có thể mang lại cảm giác bảo mật sai và nguy hiểm, việc định cấu hình sai bất kỳ công cụ mã hóa nào có thể dẫn đến các sự cố nghiêm trọng gây nguy hiểm cho tính bảo mật tổng thể và khả năng sử dụng của ứng dụng Vì vậy, nếu bạn không phải là chuyên gia che giấu JS, làm cách nào bạn có thể điều hướng cấu hình này và tránh bất kỳ cạm bẫy nào? Để tránh bị che mắt bởi cấu hình kém, hãy đảm bảo rằng bạn đang sử dụng công cụ che giấu dữ liệu cung cấp tài liệu toàn diện cùng với hỗ trợ ưu tiên. Mỗi ứng dụng đều khác nhau và obfuscation chắc chắn không phải là giải pháp một kích cỡ phù hợp với tất cả. Bằng cách tin tưởng vào một nhóm hỗ trợ chuyên dụng, bạn có thể dễ dàng tinh chỉnh quá trình che giấu để phù hợp với trường hợp sử dụng cụ thể của mình và tránh những cạm bẫy phổ biến có thể làm giảm khả năng sử dụng ứng dụng của bạn Không có cách nào xung quanh nó. bảo mật là niềm tin. Giống như việc bạn sẽ không cung cấp mã nguồn của mình (đặc biệt nếu nó chứa thông tin nhạy cảm) cho bất kỳ người ngẫu nhiên nào, bạn có thể sẽ không muốn tin tưởng một cách mù quáng vào bất kỳ trình mã hóa JS nào với mã đó. Một điều đặc biệt về che giấu là rất khó để kiểm tra kết quả cuối cùng. Đã có một số trường hợp các trình mã hóa miễn phí thêm phần mềm độc hại/phần mềm gián điệp vào mã nguồn trước khi mã hóa nó. Điều cực kỳ quan trọng là phải thực hiện sự cẩn trọng đối với công cụ mà bạn sẽ sử dụng để tránh bất kỳ bất ngờ khó chịu nào. Tìm kiếm sự công nhận của thị trường, lời chứng thực của khách hàng và sự trưởng thành của công ty/công nghệ Chương 4. Ngoài Obfuscation, Bảo vệ JavaScriptThông thường, hầu hết các hướng dẫn về mã hóa JavaScript sẽ kết thúc ngay tại đây. Nhưng chương bổ sung này là phần phải đọc vì nó sẽ giải thích lý do tại sao mã hóa JS thường không đủ để xử lý một số trường hợp sử dụng Mặc dù che giấu sẽ cung cấp một cách tốt để ngăn chặn kỹ thuật đảo ngược và khiến mọi người (kể cả kẻ tấn công) khó hiểu, nhắm mục tiêu và có khả năng đánh cắp logic của ứng dụng của bạn, các mối đe dọa nâng cao hơn như giả mạo mã, đánh cắp dữ liệu, vi phạm bản quyền và Bảo vệ JavaScript. Kiểm tra/Khóa môi trườngMột loại bảo vệ JavaScript quan trọng được gọi là kiểm tra môi trường hoặc khóa mã. Những điều này cho phép khóa mã JavaScript để chỉ chạy trong các môi trường được phép cụ thể Những môi trường này thường bao gồm hệ điều hành, trình duyệt, miền, ngày tháng hoặc một số loại thiết bị nhất định, chẳng hạn như điện thoại di động chưa được root hoặc bẻ khóa Mỗi ổ khóa này có thể giúp thực hiện các yêu cầu khác nhau. Ví dụ: nếu bạn có một ứng dụng xử lý dữ liệu rất nhạy cảm hoặc thực hiện các tác vụ quan trọng, bạn có thể ngăn không cho ứng dụng đó chạy trên các thiết bị đã root hoặc đã bẻ khóa vì những thiết bị này dễ bị tấn công hơn. Và nếu bạn muốn thực thi các thỏa thuận cấp phép, bạn có thể cung cấp bản demo sản phẩm cho khách hàng và khóa mã đó vào miền của khách hàng và tự động hết hạn sau một ngày cụ thể Thông thường, bất cứ khi nào xảy ra vi phạm khóa, ứng dụng sẽ bị hỏng. Vì vậy, những ổ khóa này có thể đặc biệt hữu ích trong việc chống vi phạm bản quyền và vi phạm giấy phép. Nhưng có một loại bảo vệ JS khác rất hữu ích trong hầu hết mọi trường hợp sử dụng. bảo vệ thời gian chạy Bảo vệ JavaScript. Bảo vệ thời gian chạyNhững kẻ tấn công có động cơ có thể không dễ dàng bị ngăn cản chỉ bằng cách che giấu. Trong một số kiểu tấn công nhất định, chẳng hạn như đánh cắp dữ liệu và lạm dụng tự động, lợi ích tiềm năng của một cuộc tấn công thành công có thể biện minh cho một nỗ lực lớn để thiết kế ngược mã Bước đầu tiên phổ biến nhất của kỹ thuật đảo ngược là cố gắng hiểu logic của mã bị xáo trộn bằng cách gỡ lỗi và thử nghiệm với nó trong thời gian chạy để dần dần hiểu được các phần của mã Một cách tiếp cận có phương pháp cuối cùng có thể mang lại một số kết quả (sẽ thay đổi rất nhiều tùy thuộc vào công cụ được sử dụng để làm xáo trộn mã và việc sử dụng kỹ thuật xáo trộn đa hình). Bảo vệ thời gian chạy có thể làm cho quy trình kỹ thuật đảo ngược này khó hơn nhiều bằng cách ngăn chặn bất kỳ loại sửa lỗi hoặc giả mạo nào đối với mã được bảo vệ Từ góc độ kỹ thuật, điều này đạt được bằng cách phân tán kiểm tra tính toàn vẹn và bẫy chống gỡ lỗi trong toàn bộ mã nguồn Là bước đầu tiên để hiểu logic của mã được bảo vệ, những kẻ tấn công thường sẽ sử dụng trình gỡ lỗi và thực hiện kiểm tra từng bước mã. Nếu mã đã được trang bị bẫy chống gỡ lỗi, bất cứ khi nào kẻ tấn công cố gắng sử dụng trình gỡ lỗi, bẫy sẽ được kích hoạt, cố ý phá vỡ ứng dụng và khiến kẻ tấn công bị mắc kẹt trong vòng lặp vô hạn của trình gỡ lỗi, như chúng ta có thể thấy bên dưới Khi những kẻ tấn công không thể kiểm tra mã động bằng cách gỡ lỗi, thì bước tốt nhất tiếp theo của chúng là tải xuống mã để phân tích tĩnh và sửa đổi mã đó. Sửa đổi thành công mã là một bước thiết yếu đối với bất kỳ ai đảo ngược hoặc can thiệp vào một ứng dụng. Tuy nhiên, nếu mã nguồn chứa kiểm tra tính toàn vẹn, thì một khi bất kỳ thay đổi nào được thực hiện (chẳng hạn như chỉ thay đổi một ký tự), các kiểm tra này sẽ được kích hoạt, đồng thời phá vỡ mã để ngăn cuộc tấn công thành công Như bạn có thể mong đợi, tất cả các khóa và kiểm tra này sẽ bắt đầu làm nản lòng những kẻ tấn công, đặc biệt là khi chúng được kết hợp với các biện pháp đối phó bổ sung Bảo vệ JavaScript. biện pháp đối phóThông thường, bất cứ khi nào có vi phạm khóa mã hoặc khi các bẫy chống sửa lỗi hoặc kiểm tra tính toàn vẹn được kích hoạt, phản hồi mặc định là làm hỏng quá trình thực thi ứng dụng để ngăn chặn mối đe dọa có thể xảy ra Tuy nhiên, phá vỡ ứng dụng chỉ là một ví dụ về một số biện pháp đối phó có thể. Các khả năng khác bao gồm
Mức độ tùy chỉnh này chắc chắn có thể giúp tinh chỉnh bảo vệ mã tổng thể để phù hợp với trường hợp sử dụng cụ thể của bạn Bảo mật chuyên sâuMặc dù mã nguồn JavaScript thường là điểm khởi đầu cho những người tìm kiếm một số mức độ bảo vệ mã nguồn, nhưng điểm mấu chốt là mã nguồn thường là một phương tiện để đạt được mục đích. Trong khi phát triển mô hình mối đe dọa cho ứng dụng của bạn, điều quan trọng là phải hiểu các rủi ro do mã JavaScript không được bảo vệ gây ra. Trả lời những lo ngại về bảo mật này luôn đòi hỏi một cách tiếp cận chuyên sâu về bảo mật, nghĩa là kết hợp bảo vệ mã nguồn vào một chiến lược bảo mật mạnh mẽ phía máy khách Khi nói đến việc đảm bảo mức độ bảo vệ tối đa cho mã nguồn JavaScript, câu trả lời tốt nhất là dựa vào một nhà cung cấp đáng tin cậy cung cấp khả năng che giấu linh hoạt và mạnh mẽ, cùng với bảo vệ thời gian chạy và nhiều loại tích hợp Trong hơn 10 năm, Jscrambler là công nghệ bảo vệ và mã hóa JavaScript hàng đầu. Với sự đầu tư mạnh mẽ vào R&D, Jscrambler đã giới thiệu hầu hết các tính năng sáng tạo và bằng sáng chế khi nói đến bảo vệ JavaScript, bao gồm các tính năng như Tự phục hồi, Tự bảo vệ và Làm phẳng luồng điều khiển Sau hơn 700.000 bản dựng mã được bảo vệ và được công nhận bởi các công ty tư vấn như Gartner, Jscrambler là sự lựa chọn đáng tin cậy của Fortune 500 và hàng nghìn công ty trên toàn cầu, những người có phản hồi rất xuất sắc Bạn có thể thử miễn phí tất cả các tính năng của Jscrambler bằng cách tạo một tài khoản miễn phí—chỉ mất 2 phút Có thể mã hóa JavaScript không?Có nhưng không nếu bạn muốn nó chạy. bạn có thể mã hóa mọi thứ bằng say pgp . Tuy nhiên, để thực sự chạy một tệp js, trình duyệt phải có khả năng giải mã nó thành javascript hợp lệ để thực thi nó. Bạn có thể làm cho nó khó theo dõi nhưng bạn không thể làm cho nó không thể đọc được.
Làm cách nào để mã JavaScript không thể đọc được?Không thể đọc được, có thể khó đọc hơn. Cuối cùng, trình duyệt của bạn sẽ phải đọc mã JS, đó là lý do tại sao "không đọc được" là không thể. Khó đọc. Như đã chỉ ra trong giải pháp 1, thu nhỏ và che giấu là 2 kỹ thuật làm cho mã nguồn khó đọc hơn .
Làm cách nào để làm xáo trộn JavaScript?Các kỹ thuật che giấu JavaScript phổ biến nhất là kỹ thuật sắp xếp lại, mã hóa, tách, đổi tên và che giấu logic .
Mã bị xáo trộn có chậm hơn không?Càng sử dụng kỹ thuật che giấu nâng cao, mã bị xáo trộn càng được thực thi chậm . Việc xáo trộn tên không ảnh hưởng đến hiệu suất và phải luôn được sử dụng. |
