Her programcı güvenlik hakkında ne bilmelidir? [kapalı]

427

BT öğrencisiyim ve şu anda üniversitede 3. sınıftayım. Şimdiye kadar genel olarak bilgisayarlarla ilgili pek çok konuyu inceliyoruz (programlama, algoritmalar, bilgisayar mimarisi, matematik, vb.).

Hiç kimsenin güvenlikle ilgili her şeyi öğrenemeyeceğinden eminim ama her programcının veya BT öğrencisinin bilmesi gereken bir "minimum" bilgi olduğundan eminim ve sorum şu minimum bilgi nedir?

Bu yolla başlamak için bazı e-kitaplar veya kurslar önerebilir misiniz?

security 
— MH
kaynak
6
— Thomas
118
Kural # 1: Kullanıcının girişine asla güvenmeyin. Büyükanneniz olmasa bile
— Anthony Forloney
2
..ve bu konu da büyük bilgiye sahip - stackoverflow.com/questions/72394/…
— Sripathi Krishnan
sorum sadece programcılar ve hataları değil, aynı zamanda BT ve bilgisayar bilimleri öğrencileri hakkında değil
— Mohamad Alhamoud
1
Hata mesajlarınızı izleyin. Kullanıcı dostu olmak isteseniz de, "Bu hesap mevcut değil" ve "Şifre geçersiz" arasındaki fark bazı durumlarda tehlikeli olabilir.
— Michael Mior

Yanıtlar:

551

Uygulamalarınızın güvenli olmasını istiyorsanız aklınızda bulundurmanız gereken ilkeler:

Uygulamalarınızı güvenli hale getirme konusunda çevrimiçi olarak bazı mükemmel kitaplar ve makaleler vardır:

Geliştiricilerinizi uygulama güvenliği en iyi uygulamaları konusunda eğitin

Kodlama (ücretli)

Güvenlik İnovasyonu (ücretli)

Güvenlik Pusulası (ücretli)

OWASP WebGoat (ücretsiz)

— bignum
kaynak
+1 "yazılımdan yararlanma: kodun nasıl kırılacağı" harika bir kitap, ancak bağlandığınız slayt gösterisi korkunç.
— kale
7
Bununla birlikte, ne yazık ki, herhangi bir modern sistemde en az ayrıcalık ilkesini somutlaştırmak neredeyse imkansızdır. Örneğin, Linux çekirdeği (şu anda kullanmakta olduğum kaynak), tümü sınırsız bir bağlamda çalışan 9.4 milyon satırdan fazla C kodu ve 400K'dan fazla montaj satırı içeriyor. Bu milyonlarca çizgiden birinde basit bir yanlış hesaplama (belki de kasıtlı olarak) tüm sistemi tehlikeye atacaktır. Belki gelecek yüzyılda ya da iki yıl içinde hiç kimse aslında güvenli işletim sistemi / diller / çerçeveler oluşturmayı ummadığı için bir çözüm ortaya çıkacaktır.
— L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳
1
Bu listeye "Web Uygulaması Hacker El Kitabı" nı eklerdim.
— outcassed
34
"Asla kullanıcı girişine güvenme!" "Asla herhangi bir girdiye güvenme!" Diğer yazılımlardan gelen girişler, kullanıcı girişiyle aynı şekilde ele alınmalıdır - örneğin, web sitesi günlüğünde çoğu kullanıcı User-Agent / tarayıcı kimliği alanını 'kullanıcı girişi' olarak düşünmez, ancak bir SQL enjeksiyonu.
— Peteris
2
@ L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳ Eh, .NET üzerinde yerleşik Microsoft Research deneysel işletim sistemi (Singularity) var, bu da güvenliği birincil hedef olarak hedefledi (arabellek taşması yok, yay!). Hiçbir işlem belleği paylaşımı, hiçbir kod kendi kendini değiştirme, hatta aygıt sürücüleri bile .NET başka bir yazılım izole işlemidir. Oldukça ilginç bir kavram, ancak bunu insanlara itmek çok zor olurdu (en önemlisi, mevcut yazılım veya hatta sürücülerle geriye dönük uyumluluk yapamaz; Linux'un ilk 10 yılı gibi: D).
— Luaan
102

Programcılar için güvenlik 1. Kural: Do rulo kendi değil

Kendiniz bir güvenlik uzmanı ve / veya şifreleme uzmanı değilseniz, işi sizin için yapmak için her zaman iyi tasarlanmış, iyi test edilmiş ve olgun bir güvenlik platformu, çerçevesi veya kitaplığı kullanın. Bu şeyler yıllarca hem uzmanlar hem de bilgisayar korsanları tarafından düşünülmüş, düzeltilmiş, güncellenmiş ve incelenmiştir. Bu avantajları elde etmek istiyorsunuz, tekerleği yeniden keşfetmeye çalışarak onları reddetmeyin.

Şimdi, güvenlik hakkında hiçbir şey öğrenmenize gerek olmadığı anlamına gelmiyor. Ne yaptığınızı anlamanız ve araçları doğru bir şekilde kullandığınızdan emin olmanız için yeterince bilgi sahibi olmanız gerekir. Ancak, kendi şifreleme algoritmanızı, kimlik doğrulama sisteminizi, giriş dezenfektanınızı vb. Yazmaya başlamak için kendinizi bulursanız, durun, geri adım atın ve kural # 1'i hatırlayın.

— Tyler McHenry
kaynak
10
Bence bu kötü bir kural. Varlıklarınıza gerçek bir ilgi göstermek yerine, yalnızca seçtiğiniz platform nedeniyle hedeflenebilirsiniz. 3. taraf platformlarında bulunan tüm güvenlik açıklarını ve yalnızca kullandıkları için anında savunmasız olan tüm ürünleri düşünün. 3. tarafa güvenliğime güvenmek o kadar hızlı olmazdı.
— Fosco
9
Bu Kripto için iyi bir kural olduğunu düşünüyorum - kendi şifrelemenizi yuvarlamak bir felaket tarifi. Ancak, kendi blog motorunuzu yuvarlamak Fosco'nun işaret ettiği gibi daha güvenli olabilir - eğer kendi başınızı döndürürseniz, wordpress kurulumlarının uğraşması gereken otomatik saldırılara yakalanma olasılığınız daha düşüktür.
— James P McGrath
5
Kripto söz konusu olduğunda, bu kural kesinlikle doğrudur. Kendi kripto para yazmayın, nokta. Üçüncü taraf platformları söz konusu olduğunda, duruma göre değişir. Bazı platformlar doğal olarak daha güvenlidir, bazı platformlar doğal olarak daha az güvenlidir ve çoğu platform muhtemelen bazı güvenlik özellikleri ancak bilinen bazı saldırı vektörleri sağlar. Github'da bir güvenlik açığına neden olan son Rails güvenlik açığını alın . Kuşkusuz Rails birçok güvenlik özelliği sağlar, ancak güvenli olmayan varsayılanlara sahip bazı güçlü özelliklere de sahiptir.
— Michael Kopinsky
7
Kripto söz konusu olduğunda, kendi paranızı döndürmeyin - ama kullandığınız şeyi anlayın. RC4 için aynı şifreleme anahtarını iki mesaj için neden kullanmanın korkunç bir fikir olduğunu anlamıyorsanız, örneğin herhangi bir akış şifresini kullanmadan önce okuyun.
— Christopher Creutzig
3
HeartBleed hatasından sonra bile bu iyi bir kuraldır. Özel veya tescilli bir projede ısıtılmış benzeri bir hata bulmanın ne kadar zor olacağını düşünün. Kendinizi yuvarlarsanız, sadece belirsizliğin ardında saklanıyorsunuz ve hangi hatalardan yararlanılabileceğini bilmiyorsunuz.
— Sqeaky
71

Her programcı istismar kodunun nasıl yazılacağını bilmelidir.

Sistemlerden nasıl yararlanıldığını bilmeden, yanlışlıkla güvenlik açıklarını durduruyorsunuz. Yamalarınızı nasıl test edeceğinizi bilmiyorsanız, kodu nasıl yamalayacağınızı bilmek kesinlikle anlamsızdır. Güvenlik sadece bir grup düşünce deneyi değil, bilimsel olmanız ve denemenizi test etmeniz gerekir.

— kale
kaynak
10
Bunun hiç gerekli olmadığını iddia ediyorum. Sadece ilkeye uyun: eğer saldırgan herhangi bir tür bellek bozulmasına neden olabilirse, kendinize ait olduğunuzu düşünün. İstismarları gerçekten yazma (çalışma) ayrıntılarına girmeye gerek yok.
— newgre
6
@newgre her güvenlik açığı arabellek taşması değildir. Ortak Zayıflık Numaralandırma sistemi kapsamında birkaç bin güvenlik açığı bulunmaktadır. Bir programcının saldırganın zihnini anlaması gerekir, aksi halde hata yapmadan bilmez.
— kale
1
Her birinin bir arabellek taşması olmadığını biliyorum, ancak genellikle "istismar" olarak adlandırılan her şey bir tür bellek bozulmasına dayanır: arabellek taşmaları, çift serbestlik, yığın taşmaları, tamsayı ile ilgili taşmalar, biçim dizeleri Elbette mantık böcekleri gibi başka şeyler de var, ancak bu cevabın konusu bu değildi.
— newgre
5
@newgre Bu bir tür istismar, ancak bugün web uygulama hatalarından yararlanmak için bellek bozulması sorunlarından daha fazla istismar yazılıyor. Exploits, SQL Injection, Local File include, CSRF ve XSS'den yararlanarak yazılır, bunlar yaygın sorunlardır. (Kaynak: exploit-db.com )
— kale
1
Bunu kabul ediyorum, eğer kendiniz istismar yazabiliyorsanız, bilgisayar korsanlarının zihnine en fazla neyin gidebileceğini anlayabilirsiniz!
— linuxeasy
42

Güvenlik bir ürün değil, bir süreçtir.

Birçoğu bu açık gerçeği unutuyor gibi görünüyor.

— ericteubert
kaynak
23

CWE / SANS TOP 25 En Tehlikeli Programlama Hatalarını gözden geçirmenizi öneririm . Gelecekte düzenli güncellemeler sözü ile 2010 için güncellendi. 2009 revizyon da mevcuttur.

Gönderen http://cwe.mitre.org/top25/index.html

2010 CWE / SANS En Tehlikeli 25 Programlama Hatası, ciddi yazılım açıklarına yol açabilecek en yaygın ve kritik programlama hatalarının bir listesidir. Genellikle bulmak kolay ve sömürmek kolaydır. Tehlikelidirler çünkü saldırganların yazılımı tamamen ele geçirmesine, veri çalmasına veya yazılımın çalışmasını engellemesine sık sık izin verirler.

İlk 25 listesi, programcıların, yazılımın gönderilmesinden önce meydana gelen çok yaygın hataları tespit ederek ve bunlardan kaçınarak, yazılım endüstrisini rahatsız eden türdeki güvenlik açıklarını önlemelerine yardımcı olacak bir eğitim ve farkındalık aracıdır. Yazılım müşterileri, daha güvenli bir yazılım istemelerine yardımcı olmak için aynı listeyi kullanabilir. Yazılım güvenliğindeki araştırmacılar, bilinen tüm güvenlik zayıflıklarının dar ancak önemli bir alt kümesine odaklanmak için İlk 25'i kullanabilir. Son olarak, yazılım yöneticileri ve CIO'lar, Top 25 listesini yazılımlarını koruma çabalarında bir ilerleme çubuğu olarak kullanabilirler.

— jschmier
kaynak
1
Bu listedeki ilk 4 hatanın (ve diğer grupların da) aynı hataya güvenen girdi olduğunu unutmayın.
— Chris Dodd
13

İyi bir başlangıç ​​kursu Bilgisayar Ağları ve Güvenlik MIT kursu olabilir . Önerebileceğim bir şey de gizliliği unutmamak. Gizlilik, bazı açılardan, güvenliğin gerçekten temelidir ve genellikle güvenlikle ilgili teknik kurslarda yer almaz. İnternet ile ilgili olduğu için Etik ve Hukuk üzerine bu derste gizlilikle ilgili bazı materyaller bulabilirsiniz .

— tvanfosson
kaynak
MIT kurs bağlantısı çalışmıyor
— AntonioCS
1
Bağlantılar düzeltildi (şimdilik). Teşekkürler.
— tvanfosson
8

Çerçevelerde ve API'larda güvenli varsayılanların önemi:

  • Birçok erken web çerçevesi şablonlarda varsayılan olarak html'den kaçmadı ve bu nedenle XSS sorunları vardı
  • Çok sayıda erken web çerçevesi, SQL'i birleştirmeyi çok sayıda SQL enjeksiyon hatasına yol açan parametreli sorgular oluşturmaktan daha kolay hale getirdi.
  • Erlang'ın bazı sürümleri (R13B, belki diğerleri) varsayılan olarak ssl eş sertifikalarını doğrulamaz ve muhtemelen SSL MITM saldırılarına duyarlı birçok erlang kodu vardır
  • Java'nın XSLT transformatörü varsayılan olarak keyfi java kodunun yürütülmesine izin verir. Bunun sonucunda birçok ciddi güvenlik hatası oluştu.
  • Java'nın XML ayrıştırma API'ları varsayılan olarak ayrıştırılan belgenin dosya sistemindeki rasgele dosyaları okumasına izin verir. Daha fazla eğlence :)
— benmmurphy
kaynak
5

Üç A'yı bilmelisin. Kimlik Doğrulama, Yetkilendirme, Denetim. Klasik hata, bir kullanıcının kimliğini doğrulamaktır, ancak kullanıcının bir eylem gerçekleştirme yetkisine sahip olup olmadığını kontrol etmez, böylece bir kullanıcı diğer kullanıcılara özel fotoğraflara bakabilir, Diaspora'nın yaptığı hata. Çok, çok daha fazla insan, kimin ne zaman ne yaptığını söyleyebilmek için, güvenli bir sistemde Denetim'i unutur.

— rapadura
kaynak
1
Tüm yetkilendirmeler kimlik doğrulaması gerektirmez. "ABAC'dan ZBAC'a", NBAC (kimlik doğrulama tabanlı) erişim kontrolünü, kimlik doğrulama gerektirmeyen çözümlerle karşılaştırır. "IBAC, RBAC, ABAC ve hatta CBAC - Talebe Dayalı Erişim Kontrolü hepsi kimlik doğrulamaya dayanıyor ... Basit olması açısından, bu belge tek bir çözüm olarak ele alınmakta ve ZBAC mimarisinin özelliklerini uygulayan sürümleri göz ardı etmektedir. Tabanlı Erişim Kontrolü (NBAC). "
— Mike Samuel
4
  • Sizin (programcı) tüm parçaları güvence altına almanız gerektiğini unutmayın, ancak saldırgan zırhınızda sadece bir bükülme bulmayı başarmalıdır.
  • Güvenlik "bilinmeyen bilinmeyenler" in bir örneğidir. Bazen olası güvenlik kusurlarının ne olduğunu bilmeyeceksiniz (daha sonraya kadar).
  • Bir hata ve bir güvenlik deliği arasındaki fark, saldırganın zekasına bağlıdır.
— Rory
kaynak
4

Aşağıdakileri eklerdim:

  • Dijital imzalar ve dijital sertifikalar nasıl çalışır?
  • Korumalı alan nedir

Farklı saldırı vektörlerinin nasıl çalıştığını anlayın:

  • Yerel kodda arabellek taşması / taşması / vb.
  • Sosyal mühendislik
  • DNS sahteciliği
  • Ortadaki adam
  • CSRF / XSS ve diğ.
  • SQL enjeksiyonu
  • Kripto saldırıları (ör: DES gibi zayıf kripto algoritmalarından yararlanma)
  • Program / Çerçeve hataları (ör: github'un en son güvenlik açığı)

Tüm bunlar için kolayca google. Bu size iyi bir temel sağlayacaktır. Web uygulaması güvenlik açıklarını görmek istiyorsanız, çalışan bir web uygulamasından nasıl yararlanacağınızı gösteren google gruyere adlı bir proje var .

— Miguel Ping
kaynak
4

herhangi bir girişim veya kendi yazılımınızı oluştururken, sadece bir hacker gibi düşünmelisiniz. şeyler ve nihayet bizim yazılım saldırı. bu tür saldırıları önlemek için gibi bazı iyi bilinen kurallara uymalıyız:

  • her zaman kodlarınızı kırmaya çalışın (daha fazla bilgi için cheatheets & google şeyler kullanın).
  • programlama alanınızdaki güvenlik kusurları için güncellenecektir.
  • ve yukarıda belirtildiği gibi hiçbir zaman herhangi bir kullanıcı veya otomatik girişe güvenmeyin.
  • açık kaynak uygulamalarını kullanın (en güvenlik kusurları bilinir ve çözülür).

aşağıdaki bağlantılarda daha fazla güvenlik kaynağı bulabilirsiniz:

uygulama satıcısının güvenlik akışları hakkında daha fazla bilgi için google.

— rahul_pratap
kaynak
3
  1. Neden önemlidir.
  2. Her şey değiş tokuşlarla ilgilidir.
  3. Kriptografi büyük ölçüde güvenlikten uzaklaşıyor.
— Richard
kaynak
3

Ayrıca OWASP Top 10 Listesini de kontrol ettiğinizden emin olun. , tüm ana saldırı vektörlerinin / güvenlik açıklarının sınıflandırılması için .

Bunları okumak büyüleyici. Bir saldırgan gibi düşünmeyi öğrenmek, kendi kodunuzu yazarken ne hakkında düşüneceğinizi eğitecektir.

— Michael Kopinsky
kaynak
2

Tuz ve karma kullanıcı şifreleri. Bunları asla veritabanınıza düz metin olarak kaydetmeyin.

— abdull
kaynak
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.