Năm câu hỏi để tự hỏi bản thân trước khi tạo một dự án web

Có hàng triệu lý do khiến các dự án công nghệ thất bại. Bạn có thể đặt tên cho các mô hình kinh doanh được tính toán sai, nhu cầu được đánh giá quá cao hoặc chi phí tăng vọt. Nhưng trong suốt cuộc đời làm nghề của mình, tôi đã chứng kiến khá nhiều dự án với những ý tưởng tuyệt vời và tiềm năng tốt đã sụp đổ vì những sai sót và sơ suất tưởng chừng như nhỏ nhặt. Và tôi nghĩ lý do này là cay đắng nhất, ít nhất là đối với tôi với tư cách là một nhà phát triển. Trong bài viết này, tôi muốn chia sẻ kinh nghiệm của mình và phân tích các vấn đề cũng như thách thức mà các nhà phát triển phụ trợ phải đối mặt khi làm việc trong các ứng dụng web. Tôi sẽ nêu bật những điểm chính thường bị bỏ qua và giải thích cách giải quyết những trở ngại này với hiệu quả tối đa. Tôi chắc chắn rằng điều này sẽ giúp bạn giảm thiểu rủi ro và tăng đáng kể cơ hội thành công cho dự án của bạn.

1. Có bí mật nào được lưu trữ trong mã của bạn không?

Cho dù điều này nghe có vẻ hiển nhiên đến mức nào thì điểm này vẫn rất quan trọng: không bao giờ lưu trữ thông tin bí mật hoặc nhạy cảm trong mã nguồn của bạn. Vi phạm có thể dẫn đến tổn thất tài chính và các vấn đề nghiêm trọng khác. Thông tin nhạy cảm không bao giờ được lưu trữ trong mã bao gồm:

• Khóa API và mã thông báo truy cập vào các dịch vụ nội bộ hoặc bên ngoài
• Mật khẩu và dữ liệu tài khoản, bao gồm cả mật khẩu cơ sở dữ liệu và hệ thống quản trị viên
• Khóa mã hóa
• Tệp cấu hình có dữ liệu nhạy cảm
• Câu trả lời cho các câu hỏi bảo mật như tên thời con gái của mẹ hoặc tên thú cưng

Thay vì lưu trữ thông tin đó trong mã dự án của bạn, hãy sử dụng các biến môi trường. Để có hệ thống an toàn hơn, hãy cân nhắc sử dụng các giải pháp lưu trữ bí mật mạnh mẽ như HashiCorp Vault . Trình quản lý bí mật AWS hoặc Bí mật GitHub cũng có thể hữu ích. Việc lựa chọn công cụ lưu trữ bí mật phụ thuộc vào các yếu tố như loại và quy mô dự án, kinh nghiệm của nhóm và ngăn xếp công nghệ.

Nếu bạn cho rằng việc lưu trữ thông tin nhạy cảm trong mã ứng dụng không phải là vấn đề nghiêm trọng, hãy xem xét điều này: chỉ riêng năm 2022, GitHub đã phát hiện ra hơn 1,7 triệu bí mật tiềm năng được trưng bày trong các kho lưu trữ công cộng. Hãy tưởng tượng có bao nhiêu mẩu dữ liệu như vậy có thể tồn tại trong các dự án tư nhân mà các nhà phát triển không hề biết về khả năng rò rỉ cho đến khi chúng xảy ra.

Giải pháp: Kiểm tra dự án của bạn ngay bây giờ

Nếu bạn đã có một dự án và hiện đang lo lắng về các bí mật trong mã của mình, thì có những giải pháp hữu ích có thể giúp bạn yên tâm. Kiểm tra thủ công có thể tốn thời gian, vì vậy tự động hóa là chìa khóa. Các công cụ hữu ích bao gồm:

• TruffleHog : Tìm kiếm bí mật trong kho Git bằng cách quét lịch sử cam kết để tìm khóa API và dữ liệu nhạy cảm khác.
• GitLeaks : Phát hiện các bí mật được mã hóa cứng như mật khẩu, khóa API và mã thông báo trong kho git.
• GitGuardian : Hoạt động trong môi trường cục bộ hoặc CI của bạn để tìm hơn 350 loại bí mật và các lỗ hổng bảo mật khác.
• Bảo mật nâng cao GitHub : Tự động quét các kho lưu trữ để tìm các loại bí mật đã biết và thông báo cho bạn nếu tìm thấy.

Những công cụ này chỉ là một vài ví dụ; các tùy chọn phổ biến khác bao gồm SonarQube Và dấu kiểm . Cả hai đều cung cấp các giải pháp trả phí và miễn phí để đáp ứng các nhu cầu và ngân sách khác nhau. Mục tiêu ở đây không phải là liệt kê mọi công cụ có sẵn mà là làm nổi bật sự tồn tại của những vấn đề này và các giải pháp tiềm năng. Nhận thức được vấn đề là một nửa trận chiến. Bây giờ, điều quan trọng là phân bổ thời gian để giải quyết vấn đề đó và chọn công cụ thích hợp cho nhu cầu của bạn.

2. Bạn biết gì về giấy phép thư viện của mình?

Đáng ngạc nhiên là chủ đề này hiếm khi được thảo luận và một số nhà phát triển thậm chí không biết rằng việc sử dụng giải pháp của bên thứ ba có thể dẫn đến các vấn đề pháp lý và những vấn đề nghiêm trọng cho công ty của họ. Không tin tôi? Hãy tưởng tượng kịch bản này: một nhà phát triển trong một công ty nhỏ có một thư viện được phân phối theo Giấy phép Công cộng GNU Affero (AGPL) trong một sản phẩm web thương mại. Là giấy phép copyleft, AGPL yêu cầu mọi phần mềm sử dụng mã được phát hành theo nó phải được phân phối theo cùng các điều khoản. Điều này có nghĩa là tất cả mã ứng dụng web của bạn, bao gồm cả những phát triển độc đáo, phải mở và có sẵn để sử dụng và sửa đổi miễn phí. Vì sản phẩm ví dụ của chúng tôi mang tính thương mại nên việc cung cấp mã nguồn của nó có thể làm suy yếu nghiêm trọng lợi thế cạnh tranh và mô hình kinh doanh của công ty.

Các vấn đề nghiêm trọng cũng có thể nảy sinh với các dự án sử dụng thư viện có giấy phép cấm sử dụng thương mại một cách rõ ràng. Và mọi chuyện cũng chẳng khá hơn là bao nếu không có giấy phép nào cả: trên thực tế, việc không có giấy phép sẽ gây ra một vấn đề nghiêm trọng vì bất kỳ mã nào cũng được bảo vệ bản quyền theo mặc định. Giấy phép cấp cho người dùng quyền sử dụng mã theo các điều kiện cụ thể, nhưng nếu không có giấy phép thì sẽ không có cơ sở pháp lý nào để sử dụng mã, ngay cả khi mã đó có thể truy cập công khai.

Cần lưu ý rằng các vấn đề cấp phép có thể ảnh hưởng đến bạn theo những cách khác nhau tùy thuộc vào khu vực pháp lý của bạn: vấn đề này đặc biệt liên quan đến các quốc gia đã ký thỏa thuận bản quyền quốc tế. Ví dụ, Công ước Berne về bảo hộ tác phẩm văn học và nghệ thuật, một trong những điều ước quốc tế chính trong lĩnh vực này, hiện có khoảng 180 quốc gia thành viên. Do đó, việc sử dụng mã mà không có sự cho phép rõ ràng sẽ đồng nghĩa với việc vi phạm luật bản quyền và có thể dẫn đến các cuộc chiến pháp lý ở nhiều nơi trên toàn thế giới. Tuy nhiên, điều này không có nghĩa là bạn nên chuyển đến một đất nước “thoải mái” chỉ để vi phạm mọi quy tắc thành văn và bất thành văn. Chúng ta hãy tôn trọng lẫn nhau và nếu ai đó không muốn sự phát triển của mình được sử dụng cho những mục đích nhất định thì tốt nhất là không nên làm như vậy ngay cả từ góc độ con người.

Giải pháp: Sử dụng tính năng kiểm tra và cập nhật tự động

Như bạn có thể thấy, vấn đề cấp phép và bản quyền rất phức tạp. Để bảo vệ trước cho bản thân và công ty của bạn, tốt nhất bạn nên kiểm tra giấy phép của các thư viện và phần mềm bạn sử dụng. Đối với các thư viện, điều này không quá khó; các nhà quản lý gói hiện đại đã có các công cụ cho việc này. Ví dụ: trong trình soạn thảo PHP, bạn có thể thực hiện việc này bằng lệnh ` giấy phép soạn nhạc `, trong Python xuyên qua ` giấy phép pip `, và ở Golang, bạn có thể lấy thông tin này thông qua ` giấy phép đi `.

Và đừng quên gọi các lệnh này khi bạn cập nhật các phần phụ thuộc (tốt hơn nữa là tự động hóa các bước kiểm tra này), vì giấy phép của thư viện được kết nối có thể thay đổi trong các phiên bản mới.

3. Quyền truy cập phiên bản phát triển của bạn có bị hạn chế không?

Trong quá trình phát triển web, thông thường có nhiều phiên bản của một dự án, chẳng hạn như phát triển (dev), đảm bảo chất lượng (QA), dàn dựng và sản xuất. Tôi thường xuyên gặp phải các tình huống trong đó bất kỳ ai trên Internet đều có thể truy cập được các phiên bản dev/QA và staging của một trang web hoặc dự án web. Điều đáng báo động là các phiên bản thử nghiệm đôi khi có thể được các công cụ tìm kiếm lập chỉ mục hiệu quả hơn phiên bản chính, điều này thường gây hại cho sản phẩm.

Vấn đề chính ở đây là các phiên bản thử nghiệm có thể chứa lỗi hoặc nhạy cảm, thậm chí có thể xâm phạm thông tin. Ngoài ra, các phiên bản beta thường dễ bị hack hơn so với phiên bản cuối cùng. Điều này có nghĩa là tính khả dụng của chúng làm tăng nguy cơ kẻ tấn công giành được quyền truy cập vào dữ liệu nhạy cảm, mã nội bộ hoặc thậm chí chính máy chủ. Điều này đặc biệt đúng nếu bạn đang phát triển chương trình phụ trợ cho thứ gì đó giống như ứng dụng di động, vì việc truy cập trái phép vào các phiên bản thử nghiệm của API có thể cực kỳ nguy hiểm.

Ngoài rủi ro bảo mật, các trang web trùng lặp có thể tác động tiêu cực đến thứ hạng của công cụ tìm kiếm. Các công cụ tìm kiếm như Google có thể coi những bản sao này là nội dung không mong muốn, có khả năng làm giảm thứ hạng của các trang gốc trong dự án của bạn hoặc thậm chí xóa chúng hoàn toàn khỏi chỉ mục.

Giải pháp: Đưa ra chiến lược bảo mật của bạn ngay từ đầu

Đừng tiết kiệm tên miền. Nếu bạn cần một phiên bản thử nghiệm có thể truy cập trực tuyến, hãy mua một miền riêng dành riêng cho phiên bản đó. Biện pháp đơn giản nhưng hiệu quả này giúp giảm rủi ro bảo mật vì những kẻ tấn công thường sẽ kiểm tra tên miền phụ trước. Việc lưu trữ phiên bản thử nghiệm của bạn trên bất kỳ tên miền phụ nào của tài nguyên chính sẽ khiến nó trở thành mục tiêu dễ dàng.

Hạn chế quyền truy cập vào tất cả các phiên bản thử nghiệm. Đảm bảo rằng phiên bản dev, QA, staging và các phiên bản khác không thể truy cập công khai. Ví dụ: định cấu hình chúng để chỉ có thể truy cập được thông qua VPN. Điều này làm giảm khả năng truy cập trái phép, ngay cả khi miền thử nghiệm bị các tác nhân độc hại biết đến.

Bảo vệ các phiên bản thử nghiệm khỏi bị lập chỉ mục. Ngay cả khi các phiên bản thử nghiệm của bạn chỉ có thể truy cập được qua VPN và được lưu trữ trên các miền bí mật riêng biệt, hãy bảo vệ chúng khỏi việc lập chỉ mục của công cụ tìm kiếm bằng cách sử dụng tệp `robots.txt` hoặc thẻ meta `noindex`. Bước này rất quan trọng vì các công cụ tìm kiếm đôi khi có thể tìm và lập chỉ mục các trang này theo những cách không ngờ tới.

4. Địa chỉ IP thực của bạn có bị ẩn không? Các cổng không sử dụng của bạn có bị đóng không?

Có những quy tắc bảo mật mà nhiều nhà phát triển có xu hướng bỏ qua, mặc dù chúng cực kỳ quan trọng và đã được thiết lập qua những bài học dày dặn. Một quy tắc như vậy là luôn ẩn địa chỉ IP thực của dự án của bạn. Nếu địa chỉ IP của máy chủ của bạn có thể được xác định thông qua tên miền, điều đó có thể dẫn đến một số vấn đề như:

• Tấn công DDoS: Biết địa chỉ IP thực của dự án của bạn, kẻ tấn công có thể khởi động cuộc tấn công Từ chối dịch vụ phân tán (DDoS) trên máy chủ của bạn. Ví dụ, một Khuếch đại phản xạ DNS cuộc tấn công có thể khiến máy chủ của bạn choáng ngợp với khối lượng phản hồi khổng lồ từ các máy chủ DNS công cộng, khiến dịch vụ của bạn không được cung cấp cho người dùng và gây ra tổn thất tài chính đáng kể.

  
  

• Xác định các lỗ hổng tiềm ẩn: Các tin tặc nghiêm túc, không chỉ nghiệp dư, có thể quét các cổng mở và phần mềm tiếp xúc với mạng để tìm và khai thác điểm yếu. Ngay cả các dịch vụ nổi tiếng như MongoDB cũng có những vụ vi phạm dữ liệu nghiêm trọng do cấu hình sai. Nhiều vấn đề trong số này có thể tránh được bằng cách ẩn địa chỉ IP thực.

Giải pháp: Làm cho cuộc sống của kẻ tấn công tiềm năng trở nên phức tạp hơn

Bằng cách che giấu địa chỉ IP thực của máy chủ, bạn sẽ khiến những kẻ tấn công nhắm mục tiêu vào hệ thống của bạn khó khăn hơn nhiều. Sử dụng Mạng phân phối nội dung (CDN) hoặc dịch vụ bảo vệ DDoS có thể rất hiệu quả ở đây. Các tùy chọn phổ biến bao gồm Đám MâyFlare , cung cấp miễn phí cả khả năng CDN và bảo vệ DDoS, cũng như các dịch vụ như không thấm nước (trước đây là Incapsula) cung cấp các chức năng tương tự và Trình kiểm tra chất lượng , chuyên bảo vệ các ứng dụng Web bằng Tường lửa ứng dụng web, nhưng việc này có thể phát sinh chi phí.

Mặc dù những công cụ này có thể tăng cường đáng kể tính bảo mật nhưng vẫn có những điểm cần lưu ý bổ sung:

• Rò rỉ IP tiêu đề email: Nếu bạn sử dụng máy chủ chính của mình để gửi email, địa chỉ IP thực có thể bị lộ trong tiêu đề email, khiến nỗ lực bảo mật của bạn bị giảm sút.

  
  

• Lịch sử IP và Yêu cầu Whois: Các dịch vụ như Lịch sử DNS hoặc Yêu cầu Whois có thể tiết lộ các địa chỉ IP lịch sử được liên kết với một tên miền. Nếu IP thực của bạn đã từng được liên kết với miền làm việc của bạn, bạn nên thay đổi nó.

  
  

• Bảo vệ DDoS và Điểm cuối API: Hãy thận trọng khi sử dụng bảo vệ DDoS cho các miền đóng vai trò là điểm cuối API. Hệ thống bảo vệ có thể đưa ra các bước xác minh người dùng có thể làm gián đoạn hoạt động của các ứng dụng phía máy khách của bạn bằng cách thay thế phản hồi JSON/XML bằng mã HTML.

  
  

• Yêu cầu API gửi đi: Khi máy chủ của bạn gửi yêu cầu đến API của bên thứ ba, nó có thể vô tình tiết lộ địa chỉ IP của mình. Việc sử dụng máy chủ proxy cho những yêu cầu như vậy có thể hữu ích vì việc thay đổi proxy dễ dàng hơn việc giải quyết hậu quả của một cuộc tấn công.

Điều quan trọng cần nhớ là việc ẩn địa chỉ IP thực của dự án của bạn không phải là biện pháp chữa khỏi hoàn toàn. Việc đóng các cổng được phần mềm của bạn sử dụng từ mạng bên ngoài là điều quan trọng bất cứ khi nào có thể. Thay đổi cổng tiêu chuẩn là một thực tế gây tranh cãi; một số chuyên gia cho rằng nó làm phức tạp quá trình thiết lập của bạn mà không mang lại lợi ích đáng kể. Thông thường, nên định cấu hình phần mềm để tương tác qua ổ cắm Unix thay vì kết nối TCP mạng (nếu cả dự án và phần mềm của bạn đều chạy trên cùng một máy chủ). Cách tiếp cận này không chỉ giúp tăng tốc độ tương tác mà còn tăng cường bảo mật bằng cách loại bỏ nhu cầu về các cổng mở.

Đối với hệ thống quản lý cơ sở dữ liệu (DBMS) hoặc các dịch vụ nội bộ khác trên các máy chủ riêng biệt, hãy đảm bảo quyền truy cập được giới hạn ở các địa chỉ IP cụ thể mà bạn kiểm soát chặt chẽ. Thiết lập này ngăn chặn truy cập trái phép vào các hệ thống quan trọng, thêm lớp bảo mật bổ sung và giảm thiểu rủi ro bị tấn công từ bên ngoài và rò rỉ dữ liệu.

5. Bạn có cập nhật phần mềm và phần phụ thuộc của dự án không?

Lời khuyên này khá đơn giản nhưng một lần nữa lại thường bị bỏ qua: thường xuyên cập nhật các phần mềm máy chủ và phần phụ thuộc của dự án của bạn. Mã lỗi thời và dễ bị tổn thương là giấc mơ của những kẻ tấn công có thể dễ dàng khai thác nó.

Giải pháp: Tự động cập nhật của bạn

Bạn không cần cập nhật mọi thứ theo cách thủ công; nhiều công cụ tự động hóa có thể trợ giúp. Ví dụ, phụ thuộc trên GitHub tự động phát hiện các phần phụ thuộc lỗi thời hoặc dễ bị tấn công và đề xuất cập nhật.

Tự động hóa việc gia hạn chứng chỉ bảo mật cũng rất quan trọng. Nếu bạn dùng Hãy mã hóa chứng chỉ, bạn có thể tự động gia hạn chúng bằng chứng nhận . Chứng chỉ hết hạn có thể gây ra một số khó khăn thực sự, nhưng việc tự động gia hạn chứng chỉ là một nhiệm vụ đơn giản.

\Nguyên tắc tương tự cũng áp dụng cho phần mềm máy chủ. Nếu bạn đang làm việc với Linux, đặc biệt là các bản phân phối dựa trên Debian/Ubuntu, Nâng cấp không cần giám sát có thể dễ dàng xử lý công việc. Đối với các dự án lớn hơn có nhiều máy chủ, các công cụ như Ansible , đầu bếp , con rối , hoặc Muối có sẵn.

Suy nghĩ cuối cùng

Các mẹo được cung cấp ở đây chỉ là một phần nhỏ những điều mà nhà phát triển phụ trợ cần nhớ. Tôi chọn nêu bật những chủ đề quan trọng nhưng ít được thảo luận thường xuyên hơn so với những chủ đề phổ biến như SQL tiêm hoặc CSRF các cuộc tấn công.

Để hiểu sâu hơn về bảo mật ứng dụng web, hãy xem xét việc khám phá Quỹ OWASP , một tổ chức phi lợi nhuận cung cấp các nguồn tài nguyên có giá trị. Các Top 10 của OWASP tài liệu có sẵn trên trang web của họ, liệt kê các rủi ro bảo mật ứng dụng web phổ biến và nghiêm trọng nhất. Bạn cũng sẽ tìm thấy thông tin về các cuộc tấn công ít được biết đến hơn nhưng cũng không kém phần nguy hiểm.

Tôi tin rằng cộng đồng nhà phát triển phải vừa có kiến thức vừa hỗ trợ trong việc chia sẻ hiểu biết và kinh nghiệm. Vì vậy, tôi mời mọi người chia sẻ những quan sát và nhận xét của họ, những điều này có giá trị đối với tất cả những người làm việc trong lĩnh vực phát triển phụ trợ!