Mọi lập trình viên nên biết gì về bảo mật? [đóng cửa]

427

Tôi là một sinh viên CNTT và tôi đang học năm thứ 3 tại trường đại học. Cho đến bây giờ chúng tôi đã nghiên cứu rất nhiều môn học liên quan đến máy tính nói chung (lập trình, thuật toán, kiến ​​trúc máy tính, toán học, v.v.).

Tôi rất chắc chắn rằng không ai có thể học mọi thứ về bảo mật nhưng chắc chắn có kiến ​​thức "tối thiểu" mà mọi lập trình viên hoặc sinh viên CNTT nên biết về nó và câu hỏi của tôi là kiến ​​thức tối thiểu này là gì?

Bạn có thể đề xuất một số sách điện tử hoặc các khóa học hoặc bất cứ điều gì có thể giúp bắt đầu với con đường này?

security 
— MH
nguồn
6
— Thomas
118
Quy tắc số 1: Không bao giờ tin tưởng đầu vào của người dùng. Ngay cả khi đó là Bà của bạn
— Anthony Forloney
2
..và chủ đề này cũng có thông tin tuyệt vời - stackoverflow.com/questions/72394/ cấp
— Sripathi Krishnan
Câu hỏi của tôi không chỉ về lập trình viên và những sai lầm của họ, mà còn về sinh viên CNTT và khoa học máy tính
— Mohamad Alhamoud
1
Xem thông báo lỗi của bạn. Mặc dù bạn muốn thân thiện với người dùng, sự khác biệt giữa "Tài khoản này không tồn tại" và "Mật khẩu không hợp lệ" có thể gây nguy hiểm trong một số trường hợp.
— Michael Mior

Câu trả lời:

551

Các nguyên tắc cần ghi nhớ nếu bạn muốn các ứng dụng của mình được an toàn:

  • Không bao giờ tin tưởng bất kỳ đầu vào!
  • Xác thực đầu vào từ tất cả các nguồn không đáng tin cậy - sử dụng danh sách trắng không phải danh sách đen
  • Lập kế hoạch bảo mật ngay từ đầu - đó không phải là thứ bạn có thể bắt đầu vào cuối
  • Giữ cho nó đơn giản - sự phức tạp làm tăng khả năng lỗ hổng bảo mật
  • Giữ bề mặt tấn công của bạn ở mức tối thiểu
  • Hãy chắc chắn rằng bạn thất bại an toàn
  • Sử dụng phòng thủ theo chiều sâu
  • Tuân thủ nguyên tắc đặc quyền tối thiểu
  • Sử dụng mô hình mối đe dọa
  • Ngăn cách - vì vậy hệ thống của bạn không phải là tất cả hoặc không có gì
  • Ẩn bí mật là khó - và bí mật ẩn trong mã sẽ không được giữ bí mật lâu
  • Đừng viết tiền điện tử của riêng bạn
  • Sử dụng tiền điện tử không có nghĩa là bạn an toàn (kẻ tấn công sẽ tìm kiếm một liên kết yếu hơn)
  • Lưu ý về lỗi tràn bộ đệm và cách bảo vệ chống lại chúng

Có một số sách và bài viết tuyệt vời trực tuyến về việc làm cho ứng dụng của bạn an toàn:

Huấn luyện các nhà phát triển của bạn về các biện pháp bảo mật ứng dụng tốt nhất

Codebashing (trả tiền)

Đổi mới bảo mật (trả phí)

La bàn bảo mật (đã thanh toán)

OWASP WebGoat (miễn phí)

— bignum
nguồn
+1 "phần mềm khai thác: cách phá mã" là một cuốn sách tuyệt vời, tuy nhiên slide trình chiếu mà bạn liên kết đến thật kinh khủng.
— rook
7
Tuy nhiên, thật không may, gần như không thể khởi tạo nguyên tắc đặc quyền tối thiểu trong bất kỳ hệ thống hiện đại nào. Ví dụ: nhân Linux (nguồn tôi hiện đang sử dụng) chứa hơn 9,4 triệu dòng mã C và hơn 400K dòng lắp ráp, tất cả đều chạy trong bối cảnh không bị hạn chế. Một tính toán sai lầm đơn giản (có lẽ là cố ý) trong một trong hàng triệu dòng này sẽ thỏa hiệp toàn bộ hệ thống. Có lẽ trong một hoặc hai thế kỷ tới, một giải pháp sẽ xuất hiện, có lẽ là không, vì thực tế không ai quan tâm đến việc tạo ra các hệ điều hành / ngôn ngữ / khung an toàn.
— L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳
1
Tôi sẽ thêm "Sổ tay hacker của ứng dụng web" vào danh sách đó.
— vượt qua
34
Thay thế "Không bao giờ tin tưởng đầu vào của người dùng!" thành "Không bao giờ tin bất kỳ đầu vào nào!". Các đầu vào đến từ phần mềm khác phải được xử lý giống như đầu vào của người dùng - ví dụ: trong nhật ký trang web, hầu hết mọi người sẽ không nghĩ trường ID của Tác nhân / trình duyệt là 'đầu vào của người dùng', nhưng nó có thể dễ dàng chứa SQL tiêm.
— Peteris
2
@ L̳o̳̳n̳̳g̳̳p̳o̳̳k̳̳e̳̳ Vâng, có là Microsoft Research thử nghiệm hệ điều hành (Singularity) xây dựng trên .NET, mà mục tiêu an toàn như một mục tiêu chính (không có đệm tràn, yay!). Không chia sẻ bộ nhớ quá trình, không có mã tự thay đổi, ngay cả các trình điều khiển thiết bị chỉ là một phần mềm được phân lập trình trong .NET. Khá một khái niệm thú vị, nhưng nó sẽ rất khó khăn để đẩy này để mọi người (quan trọng nhất, nó khá nhiều không thể làm tương thích ngược với trình điều khiển phần mềm hoặc thậm chí hiện có; một chút như trong 10 năm đầu tiên của Linux: D).
— Luaan
102

Quy tắc số 1 về bảo mật cho lập trình viên: Đừng tự cuộn

Trừ khi bạn là một chuyên gia bảo mật và / hoặc nhà mật mã học, luôn luôn sử dụng một nền tảng bảo mật, khung hoặc thư viện bảo mật được thiết kế tốt, được kiểm tra tốt và trưởng thành để thực hiện công việc cho bạn. Những điều này đã mất nhiều năm để được suy nghĩ, vá, cập nhật và kiểm tra bởi các chuyên gia và tin tặc. Bạn muốn đạt được những lợi thế đó, chứ không phải sa thải họ bằng cách cố gắng phát minh lại bánh xe.

Bây giờ, điều đó không có nghĩa là bạn không cần phải học bất cứ điều gì về bảo mật. Bạn chắc chắn cần biết đủ để hiểu những gì bạn đang làm và đảm bảo bạn đang sử dụng các công cụ một cách chính xác. Tuy nhiên, nếu bạn đã bao giờ thấy mình sắp bắt đầu viết thuật toán của riêng bạn mật mã, hệ thống xác thực, khử trùng đầu vào, vv, dừng, lùi lại một bước, và ghi nhớ quy tắc # 1.

— Tyler McHenry
nguồn
10
Đây là một quy tắc xấu theo ý kiến ​​của tôi. Bạn về cơ bản có thể được nhắm mục tiêu chỉ vì nền tảng mà bạn chọn, chứ không phải bất kỳ sự quan tâm thực sự trong tài sản của bạn. Hãy suy nghĩ về tất cả các lỗ hổng bảo mật được tìm thấy trong nền tảng của bên thứ 3 và tất cả các sản phẩm dễ bị tổn thương ngay lập tức chỉ vì chúng sử dụng nó. Tôi sẽ không nhanh chóng tin tưởng bảo mật của mình cho bên thứ 3.
— Fosco
9
Tôi nghĩ rằng đây là một quy tắc tốt cho Crypto - cuộn mã hóa của riêng bạn là một công thức cho thảm họa. Nhưng việc cuộn công cụ blog của riêng bạn có thể an toàn hơn khi Fosco chỉ ra - nếu bạn tự lăn, bạn sẽ ít bị bắt bởi các cuộc tấn công tự động mà cài đặt wordpress phải đối phó.
— James P McGrath
5
Khi nói đến tiền điện tử, quy tắc này là hoàn toàn chính xác. Đừng viết tiền điện tử của riêng bạn, thời gian. Khi nói đến việc sử dụng nền tảng của bên thứ 3, nó phụ thuộc. Một số nền tảng vốn đã an toàn hơn, một số nền tảng vốn đã kém an toàn hơn và hầu hết các nền tảng có thể cung cấp một số tính năng bảo mật nhưng cũng có một số vectơ tấn công đã biết. Lấy lỗ hổng Rails gần đây đã gây ra lỗ hổng bảo mật tại github . Không nghi ngờ gì nữa, Rails cung cấp nhiều tính năng bảo mật, nhưng nó cũng có một số tính năng mạnh mẽ với các mặc định không an toàn.
— Michael Kopinsky
7
Khi nói đến tiền điện tử, đừng tự lăn lộn - nhưng hãy hiểu thứ bạn đang sử dụng. Nếu bạn không hiểu tại sao sử dụng cùng một khóa mã hóa cho RC4 cho hai tin nhắn là một ý tưởng khủng khiếp, hãy đọc trước khi sử dụng bất kỳ mật mã luồng nào, chẳng hạn.
— Christopher Creutzig
3
Ngay cả sau lỗi HeartBleed, rõ ràng đây là một quy tắc tốt. Hãy tưởng tượng mức độ khó như thế nào khi tìm thấy một lỗi giống như bị nung nóng trong một dự án tùy chỉnh hoặc độc quyền. Nếu bạn tự lăn, bạn chỉ đang ẩn đằng sau sự tối nghĩa và sẽ không biết những lỗi nào có thể bị khai thác.
— Sqeaky
71

Mỗi lập trình viên nên biết cách viết mã khai thác.

Mà không biết làm thế nào hệ thống được khai thác bạn đang vô tình dừng lỗ hổng. Biết cách vá mã là hoàn toàn vô nghĩa trừ khi bạn biết cách kiểm tra các bản vá của mình. An ninh không chỉ là một loạt các thí nghiệm nghĩ, bạn phải là khoa học và kiểm tra thử nghiệm của bạn.

— rook
nguồn
10
Tôi cho rằng điều này không cần thiết chút nào. Chỉ cần tuân thủ các nguyên tắc: nếu kẻ tấn công có thể gây ra tham nhũng bộ nhớ của bất cứ loại nào, hãy xem xét chính mình sở hữu. Không cần phải đi vào chi tiết khai thác thực sự bằng văn bản (làm việc).
— newgre 26/03 '
6
@newgre không phải lỗ hổng nào cũng là lỗi tràn bộ đệm. Có một vài ngàn lỗ hổng được bảo vệ bởi hệ thống liệt kê điểm yếu chung. Một lập trình viên cần phải hiểu tâm trí của kẻ tấn công nếu không anh ta sẽ không biết mắc lỗi.
— binh
1
Tôi biết rằng không phải mỗi một trong số chúng là một lỗi tràn bộ đệm, nhưng bất cứ điều gì thường được gọi là "khai thác" đều dựa trên một số loại hỏng bộ nhớ: tràn bộ đệm, giải phóng kép, tràn heap, tràn liên quan đến số nguyên, chuỗi định dạng , v.v ... Tất nhiên có những thứ khác như lỗi logic, nhưng đó không phải là chủ đề của câu trả lời này.
— newgre
5
@newgre Đó là một loại khai thác, nhưng ngày nay nhiều khai thác được viết để tận dụng các lỗ hổng ứng dụng web hơn là các vấn đề tham nhũng bộ nhớ. Khai thác được viết bằng cách sử dụng SQL Injection, Local File bao gồm, CSRF và XSS, đây là những vấn đề phổ biến. (Nguồn: exploit-db.com )
— rook
1
Tôi đồng ý với điều đó, nếu bản thân bạn có thể viết khai thác, bạn có thể hiểu những gì có thể đi đến tâm trí của tin tặc ở mức tối đa!
— linuxeasy
42

An ninh là một quá trình, không phải là một sản phẩm.

Nhiều dường như quên đi vấn đề rõ ràng này của thực tế.

— ericteubert
nguồn
23

Tôi khuyên bạn nên xem lại 25 lỗi lập trình nguy hiểm nhất của CWE / Sans . Nó đã được cập nhật cho năm 2010 với lời hứa sẽ cập nhật thường xuyên trong tương lai. Bản sửa đổi năm 2009 cũng có sẵn.

từ http://cwe.mitre.org/top25/index.html

25 lỗi lập trình nguy hiểm nhất của CWE / Sans năm 2010 là một danh sách các lỗi lập trình phổ biến và nghiêm trọng nhất có thể dẫn đến các lỗ hổng phần mềm nghiêm trọng. Chúng thường dễ tìm, và dễ khai thác. Chúng rất nguy hiểm vì chúng sẽ thường xuyên cho phép kẻ tấn công chiếm quyền hoàn toàn phần mềm, đánh cắp dữ liệu hoặc ngăn chặn phần mềm hoạt động.

Danh sách Top 25 là một công cụ giáo dục và nhận thức để giúp các lập trình viên ngăn chặn các loại lỗ hổng bảo vệ ngành công nghiệp phần mềm, bằng cách xác định và tránh các lỗi quá phổ biến xảy ra trước khi phần mềm thậm chí được xuất xưởng. Khách hàng phần mềm có thể sử dụng cùng một danh sách để giúp họ yêu cầu phần mềm an toàn hơn. Các nhà nghiên cứu về bảo mật phần mềm có thể sử dụng Top 25 để tập trung vào một tập hợp con hẹp nhưng quan trọng của tất cả các điểm yếu bảo mật đã biết. Cuối cùng, các nhà quản lý phần mềm và CIO có thể sử dụng danh sách Top 25 như một thước đo tiến bộ trong nỗ lực bảo mật phần mềm của họ.

— jschmier
nguồn
1
Lưu ý rằng 4 lỗi hàng đầu trong danh sách đó (và một loạt các lỗi khác) đều là cùng một lỗi - đầu vào đáng tin cậy.
— Chris Dodd
13

Một khóa học khởi đầu tốt có thể là khóa học MIT về Mạng máy tính và bảo mật . Một điều mà tôi muốn đề nghị là đừng quên sự riêng tư. Sự riêng tư, trong một số giác quan, thực sự là nền tảng cho bảo mật và thường không được đề cập trong các khóa học kỹ thuật về bảo mật. Bạn có thể tìm thấy một số tài liệu về quyền riêng tư trong khóa học này về Đạo đức và Luật vì nó liên quan đến internet.

— tvanfosson
nguồn
Liên kết khóa học MIT không hoạt động
— AntonioCS
1
Liên kết cố định (bây giờ). Cảm ơn.
— tvanfosson
8

Tầm quan trọng của mặc định an toàn trong khung và API:

  • Rất nhiều các khuôn khổ web đầu đã không thoát khỏi html bởi mặc định trong các mẫu và có vấn đề XSS vì điều này
  • Rất nhiều khung web ban đầu giúp việc ghép SQL dễ dàng hơn so với việc tạo các truy vấn được tham số hóa dẫn đến nhiều lỗi tiêm SQL.
  • Một số phiên bản của Erlang (R13B, có thể các phiên bản khác) không xác minh chứng chỉ ssl ngang hàng theo mặc định và có thể có rất nhiều mã erlang dễ bị tấn công SSL MITM
  • biến XSLT Java theo mặc định cho phép thực thi mã java tùy ý. Đã có nhiều lỗi bảo mật nghiêm trọng được tạo ra bởi điều này.
  • API phân tích cú pháp XML Java theo mặc định cho phép các tài liệu phân tích cú pháp để đọc các tập tin tùy ý trên hệ thống tập tin. Vui hơn :)
— lành tính
nguồn
5

Bạn nên biết về ba chữ A. Xác thực, Ủy quyền, Kiểm toán. Lỗi cổ điển là xác thực người dùng, trong khi không kiểm tra xem người dùng có được phép thực hiện một số hành động hay không, vì vậy người dùng có thể xem ảnh riêng tư của người dùng khác, lỗi mà Diaspora đã làm. Nhiều, rất nhiều người quên đi Kiểm toán, bạn cần, trong một hệ thống an toàn, để có thể nói ai đã làm gì và khi nào.

— rapadura
nguồn
1
Không phải tất cả các ủy quyền yêu cầu xác thực. "Từ ABAC đến ZBAC" tương phản kiểm soát truy cập NBAC (dựa trên xác thực) với các giải pháp không yêu cầu xác thực. "IBAC, RBAC, ABAC và thậm chí CBAC - Kiểm soát truy cập dựa trên yêu cầu đều dựa vào xác thực ... Để đơn giản, bài viết này coi chúng là giải pháp duy nhất và bỏ qua các phiên bản đã triển khai các khía cạnh của kiến ​​trúc ZBAC. Chúng được gọi chung là tự động hóa Kiểm soát truy cập dựa trên (NBAC). "
— Mike Samuel
4
  • Hãy nhớ rằng bạn (lập trình viên) phải bảo mật tất cả các phần, nhưng kẻ tấn công chỉ phải thành công trong việc tìm kiếm một nút thắt trong áo giáp của bạn.
  • Bảo mật là một ví dụ về "ẩn số chưa biết". Đôi khi bạn sẽ không biết các lỗi bảo mật có thể xảy ra là gì (cho đến sau đó).
  • Sự khác biệt giữa một lỗi và lỗ hổng bảo mật phụ thuộc vào trí thông minh của kẻ tấn công.
— Rory
nguồn
4

Tôi sẽ thêm vào như sau:

  • Chữ ký số và chứng thư số hoạt động như thế nào
  • sandboxing là gì

Hiểu cách các vectơ tấn công khác nhau hoạt động:

  • Bộ đệm tràn / tràn / vv trên mã gốc
  • engineerring xã hội
  • Giả mạo DNS
  • Người đàn ông ở giữa
  • CSRF / XSS và cộng sự
  • SQL tiêm
  • tấn công Crypto (ví dụ: khai thác các thuật toán mật mã yếu như DES)
  • Lỗi chương trình / khung (ví dụ: lỗ hổng bảo mật mới nhất của github )

Bạn có thể dễ dàng google cho tất cả những điều này. Điều này sẽ cung cấp cho bạn một nền tảng tốt. Nếu bạn muốn xem các lỗ hổng ứng dụng web, có một dự án có tên google gruyere chỉ cho bạn cách khai thác một ứng dụng web đang hoạt động.

— Miguel Ping
nguồn
4

Khi bạn đang xây dựng bất kỳ doanh nghiệp hoặc bất kỳ phần mềm nào của riêng bạn, bạn chỉ nên nghĩ như một hacker. Chúng tôi biết rằng tin tặc cũng không phải là chuyên gia về mọi thứ, nhưng khi họ tìm thấy bất kỳ lỗ hổng nào, họ bắt đầu đào sâu vào nó bằng cách thu thập thông tin về tất cả những thứ và cuối cùng tấn công vào phần mềm của chúng tôi. Vì vậy, để ngăn chặn các cuộc tấn công như vậy, chúng ta nên tuân theo một số quy tắc nổi tiếng như:

  • luôn cố gắng phá vỡ mã của bạn (sử dụng cheatsheets & google những thứ để biết thêm thông tin).
  • được cập nhật cho các lỗi bảo mật trong lĩnh vực lập trình của bạn.
  • và như đã đề cập ở trên, không bao giờ tin tưởng vào bất kỳ loại người dùng hoặc đầu vào tự động nào.
  • sử dụng các ứng dụng mã nguồn mở (hầu hết các lỗi bảo mật của chúng đều được biết và giải quyết).

bạn có thể tìm thêm tài nguyên bảo mật trên các liên kết sau:

để biết thêm thông tin google về các luồng bảo mật nhà cung cấp ứng dụng của bạn.

— rahul_pratap
nguồn
3
  1. Tại sao là quan trọng.
  2. Đó là tất cả về thương mại-offs.
  3. Mật mã học phần lớn là một sự phân tâm từ an ninh.
— Richard
nguồn
3

Để biết thông tin chung về bảo mật, tôi khuyên bạn nên đọc Bruce Schneier . Anh ta có một trang web, bản tin mật mã , một vài cuốn sách và đã thực hiện rất nhiều cuộc phỏng vấn .

Tôi cũng sẽ làm quen với kỹ thuật xã hội (và Kevin Mitnick ).

Đối với một tốt (và khá thú vị) cuốn sách về cách an ninh diễn ra trong thế giới thực, tôi muốn giới thiệu tuyệt vời (mặc dù một chút ngày) 'của Cuckoo trứng' bởi Cliff Stoll.

— Dan Esparza
nguồn
3

Ngoài ra hãy chắc chắn kiểm tra Danh sách Top 10 của OWASP để phân loại tất cả các vectơ / lỗ hổng tấn công chính.

Những điều này là hấp dẫn để đọc về. Học cách suy nghĩ như một kẻ tấn công sẽ đào tạo cho bạn những gì cần suy nghĩ khi bạn viết mã của riêng mình.

— Michael Kopinsky
nguồn
2

Muối và băm mật khẩu của người dùng của bạn. Không bao giờ lưu chúng trong bản rõ trong cơ sở dữ liệu của bạn.

— Bùn
nguồn
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.