Vấn đề bảo mật về việc công khai mã của tôi trong GitHub

8

Tôi đang phát triển một trang web cộng đồng / diễn đàn lớn và tôi muốn tải mã của mình lên GitHub để có ít nhất một loại kiểm soát phiên bản nào đó (vì tôi không có gì ngoài tệp .rar làm bản sao lưu, thậm chí không phải SVN ), để cho những người khác đóng góp cho dự án, và có lẽ sử dụng nó để cho các nhà tuyển dụng tiềm năng trong tương lai của tôi xem một số mã của tôi như một loại chương trình giảng dạy.

Nhưng điều tôi đang thắc mắc bây giờ và tôi cho rằng tôi chưa từng thấy ai nhắc đến nó trước đây là khía cạnh bảo mật của nó. Không phải việc xuất bản mã của một trang web là một lỗ hổng bảo mật HUGE ? Giống như cho một hacker tiềm năng hoặc bất kỳ ai muốn tìm thấy bất kỳ khai thác tiềm năng nào có thể, thậm chí xem xét rằng các tệp quan trọng không được tải lên (mật khẩu cơ sở dữ liệu, tập lệnh xác thực, v.v.).

Tất nhiên, có hàng triệu dự án được tải lên GitHub và không ai sẽ tìm thấy tôi chỉ là 'tình cờ'. Nhưng nếu họ tìm kiếm nó, nó thực sự sẽ ở đó.

Tóm lại: vấn đề của tôi không phải là về bản quyền hoặc giấy phép, mà là những vấn đề khác trong việc tìm kiếm khai thác trong trang web của tôi.

Tôi đang thiếu một cái gì đó ở đây?

open-source security github

— federico-t
nguồn

4

Bảo mật bằng cách tối nghĩa đã không hoạt động tốt cho hầu hết các phần mềm cho đến nay. Mã nguồn là một phần của câu đố!

— Martijn Pieters

2

Sử dụng BitBucket thay thế. Nó cũng hỗ trợ git.

— Công việc

Vì vậy, không có khai thác rõ ràng trong trang web của bạn để mọi người tìm thấy? Ví dụ: nếu mọi người có thể cho biết từ mã nguồn của bạn nơi có các lỗ hổng SQL tiêm thì bạn cũng có thể.

— dùng16764

Như @delnan chỉ ra bên dưới, GitHub cho phép bạn lưu trữ các repos riêng với giá. Ngoài hàng triệu dự án công cộng (nguồn mở) mà bạn thực sự có thể thấy, có lẽ hàng triệu dự án tư nhân trên GitHub mà không ai ngoài chủ sở hữu / cộng tác viên của dự án sẽ thấy.

— Suman

1

Nếu không có gì khác tạo một repo git địa phương. Bằng cách đó, bạn ít nhất có thể quay lại khi bạn mắc lỗi.

— Zachary K

24

Tôi đang thiếu một cái gì đó ở đây?

Đúng. Dựa vào những người không biết mã nguồn của bạn để ngăn họ tìm thấy các khai thác bảo mật trong đó được gọi là bảo mật thông qua che khuất .

Vấn đề: nó không hoạt động. Tin tặc có kỹ năng không cần mã nguồn để tìm và khai thác lỗ hổng. Họ sẽ làm một số fuzzing để tìm đầu vào mà gây ra vấn đề và sau đó sử dụng kiến thức của họ về cách hệ điều hành cơ bản / ngôn ngữ / khuôn khổ hoạt động để xác định một lỗ hổng.

Người ta đồng ý rằng việc mã nguồn công khai tăng cường bảo mật bằng cách cho phép những người có ý nghĩa tốt tìm ra lỗ hổng và sửa chúng , hoặc ít nhất là nói với nhà phát triển về chúng. Có hai lý do quan trọng tại sao điều này hoạt động:

Nhìn chung có nhiều ý nghĩa hơn những người độc hại
Bất kỳ lỗ hổng nào được tìm thấy bởi một người có ý nghĩa tốt sẽ được sửa chữa cho tất cả mọi người; tin tặc ít có khả năng hợp tác

Tất nhiên, nó không hoạt động với các dự án thú cưng có ít người dùng hoạt động, nhưng những dự án đó cũng cực kỳ khó bị tin tặc nhắm đến.

— Michael Borgwardt
nguồn

1

Không phải tôi đồng ý hay không đồng ý, mà là "đồng ý rộng rãi" bởi ai? Đây không phải là một tình cảm mà tôi thực sự đã nghe bày tỏ.

— Steven Evers

Cảm ơn người đàn ông phản ứng nhanh! Và thật có ý nghĩa khi tôi nghĩ về nó, đó là một sự đánh đổi giữa việc chia sẻ thứ gì đó đã được tìm thấy bởi các tin tặc lành nghề và nhận được đầu vào thích hợp từ các lập trình viên có thiện chí. Rõ ràng tôi đã không nghĩ về nó theo cách này .. Cảm ơn một lần nữa!

— federico-t

@SnOrfus: xem nguyên tắc của Linus và nguyên tắc của Kerckhoffs. Phải thừa nhận rằng, "đồng ý rộng rãi" có thể là một chút cường điệu, nhưng tôi muốn rằng phần lớn các lập trình viên có kinh nghiệm sẽ đồng ý.

— Michael Borgwardt

@MichaelBorgwardt, tôi muốn rằng phần lớn các lập trình viên có kinh nghiệm sẽ không đồng ý . Cái gọi là "nhiều nhãn cầu = ít bị tổn thương hơn" không dựa trên nghiên cứu thích hợp thực tế . Heartbleed không phải là người đầu tiên và sẽ không phải là người cuối cùng. Ngoài ra, hãy xem blog.codinghorror.com/given-enough-money-all-bugs-are-shallow

— Pacerier

@Pacerier: Tôi sẽ đưa bạn vào cuộc cá cược đó bất cứ lúc nào. Lưu ý rằng tuyên bố là nguồn mở làm tăng tính bảo mật, không phải nó dẫn đến bảo mật hoàn hảo. Bạn có thể trích dẫn các ví dụ về lỗi trong OSS cho đến khi những con bò về nhà và nó chứng minh hoàn toàn không có gì ngược lại. Thực sự có nghiên cứu thích hợp: archive.wired.com/software/coolapps/news/2004/12/66022 - vâng, nó đã hơn 10 tuổi, nhưng cho đến khi bạn có thể tìm thấy thứ gì đó cụ thể với những phát hiện trái ngược, nó vẫn tồn tại.

— Michael Borgwardt

6

Trước hết, bạn có thể sử dụng kiểm soát phiên bản (phân tán) mà không công khai kho lưu trữ. Bạn chỉ có thể tạo một repo trên máy tính cục bộ của mình và đẩy / kéo từ các máy tính khác. Bạn cũng có thể tải lên kho lưu trữ (cung cấp cho bạn nhiều bản sao lưu hơn và cộng tác dễ dàng hơn) mà không cần công khai. GitHub cung cấp các repos riêng với một khoản phí, Bitbucket cũng làm như vậy và làm cho các repos riêng nhỏ (5 người hoặc một cái gì đó) miễn phí. Tất nhiên, sau đó bạn không nhận được những lợi ích khác mà bạn đề cập.

Các khía cạnh bảo mật là khá nhỏ. Có rất nhiều vectơ tấn công đáng giá có thể được kiểm tra dễ dàng mà không cần nhìn vào mã nguồn (phía máy chủ) (như chú ý đến các tham số GET và POST, kiểm tra cookie và xử lý phiên, thêm các đầu vào phải thoát và kiểm tra nếu có, v.v.). Nếu bạn dễ bị tấn công bởi bất kỳ ai trong số họ, kẻ tấn công quyết tâm có thể khai thác chúng một cách hợp lý nhanh chóng mà không cần nhìn vào mã nguồn. Các lỗi khó hiểu hơn và khó khai thác hơn (có lẽ) cũng khó phát hiện hơn trong mã nguồn, vì vậy, một lần nữa, bạn không mất nhiều.

Mặt khác, công khai và chấp nhận các đóng góp có thể thu hút những người có thể phát hiện ra các hoạt động khai thác mà không có ý nghĩa xấu và cho bạn biết về chúng (hoặc thậm chí tự sửa chúng). Điều này gấp đôi nếu nó thực sự phổ biến nhưng bạn không phải là chuyên gia bảo mật (không vi phạm, nhưng bạn không giống ai; ví dụ: bạn đã không đề cập đến bảo mật thông qua che khuất và làm thế nào mối quan tâm của bạn không phải là trường hợp của nó) .

Giống như tôi đã nói với @Michael Borgwardt điều này hoàn toàn có ý nghĩa. Tôi đoán lợi ích của việc xuất bản mã thậm chí còn lớn hơn khi nhiều người biết về dự án và cung cấp các đóng góp để sửa chữa khai thác. Và nếu nó không phổ biến, rất có thể các tin tặc tiềm năng cũng sẽ không quan tâm đủ về nó. Cảm ơn câu trả lời!

— federico-t

Theo như tôi có thể nói, github không cung cấp repos riêng miễn phí (một sự điều chỉnh nhỏ, không phải là nitlog).

— Scrwtp

@scrwtp: 'có tính phí' không giống như miễn phí.

— Martijn Pieters

À, đúng rồi, tôi đọc nhầm.

— Scrwtp

3

BitBucket có repos riêng miễn phí và hỗ trợ cả git và mercurial.

— vui vẻ
nguồn

2

Đặt vấn đề bảo mật sang một bên và liệu công khai mã của bạn có cải thiện nó hay không, bạn có thể tự thiết lập một hệ thống kiểm soát nguồn trên máy của mình. Trong trường hợp git nó không quan trọng, chỉ cần khởi tạo một kho lưu trữ cục bộ và bạn đã hoàn thành, nhưng thiết lập SVN cũng không phải là một nhiệm vụ khó khăn. Có thể một hoặc hai giờ theo hướng dẫn, nếu bạn có ít kiến thức trước về cách thiết lập SVN.

Vì vậy, bạn vẫn có thể hưởng lợi từ kiểm soát nguồn, bất kể bạn có sử dụng dịch vụ trực tuyến hay không.

— chà
nguồn

0

Hầu hết các hack độc hại được thực hiện ẩn danh. Một số người ở Nga đang chạy một kịch bản quét các máy chủ lưu trữ cho các cổng mở hoặc những gì bạn có. Không ai sẽ rõ ràng đổ mã của bạn chỉ để tìm cách hack vào để gây hại. Không, trừ khi bạn thực sự làm phiền ai đó.

— nbv4
nguồn